HTML5 full-screen API

ArticleDirectory

• I. Preface
• II. Specific Use of fullscreen javascript API
• Iii. Solutions
• Iv. Summary
• V. Reference Documents

Note: HTML5 only indicates that it is a new feature. Should browser JavaScript APIs be a complementary feature of HTML5? We don't have to worry about it. Let's take a look at what this interface can bring to me and think about how to enhance the web page experience.

I. Preface

In fact, it is just a new javascript API that allows HTML elements to be displayed in full screen. However, this is enough to make us excited. What is it? In fact, this feature can be used in <video> from IOS and Safari 5.0. Take a look at this and access a video on Youku on the iPhone:

You can click the large Show button in the middle. safari in IOS will display the video in full screen. This interface is used. It is just an API implemented by safari. Still not W3C standard. For example:

II. Specific Use of fullscreen javascript API

1. javascript API

The fullscreen javascript API is still draft. To implement this API, the browsers with this function are chrome 15/Firefox nightly/Safari 5.1. For front-end calls to JS APIs, let's take a look at the followingCode:

// WebKit (works in safari5.1 and chrome 15) element. WebKit Request Full S Creen (); document. WebKit Cancel Full S Creen (); // Firefox 10element. Moz Request Full S Creen (); document. Moz Cancel Full S Creen (); // W3C proposes element. Request Full S Creen (); document. Exit Full S Creen ();

There are only two methods. When you need to call the full screen element to call the requestfullscreen () method, you need to call the exitfullscreen () API for document when you need to exit. The problem is not big, but the name is different.

However, the vendor prefix, the implementations of various browsers are different from those of W3C, and the code has to be written like shit. I specifically marked different colors. Green indicates the same vertex, while red indicates different vertices. At this point, W3C is a bit strange. It's hard to say that WebKit and Mozilla are consistent. Why should we change the name. Since the request is sent, why not send the request to enter corresponding to exit ?!. In any case, at least it can be implemented. At present, ie has not decided whether to implement this draft. johndyer said: "I have an email from a ie team member saying they are discussing it, but have not made any decisions. ". Er ~

It is useless to speak out here. We will return to the topic. Browser supportFullscreenchange event. So that you can do more for full screen. The official draft has not been mentioned much, but I just skipped it. This section of code from johndyer uses the Mozilla proposal. The specific use of this Code also needs to be taken into account:

 
// WebKit-base: element. OnWebkitfullscreenchange// Firefox: element. OnMozfullscreenchange// W3C method: element. addeventlistener ('Fullscreenchange', Function (e) {If (document. fullscreen) {/* make it look good for fullscreen */} else {/* return to the normal state in page */}, true );
 

2. CSS selector: fullscreen/: fullscreen-ancestor

The two selectors serve the following purposes:

• : Fullscreen-current full screen element
• : Fullscreen-ancestor elements of all full-screen elements

it is better to understand fullscreen, but it does not seem to be understandable that fullscreen-ancestor wants to select its family, not just its parent node. In fact, let's take a look at the demo Code provided by the official draft and you will know: what can be hidden or something. But why not set the full screen content to the top element of the highest level? This W3C option seems to be quite confusing. Check the official css demo code:

: Fullscreen {position: fixed; top: 0; left: 0; Right: 0; bottom: 0; Z-index: 2147483647; Background: black; width: 100%; height: 100%;}/* if there is a fullscreen element that is not the root then we shoshould hide the viewport scrollbar. */: fullscreen-ancestor: Root {overflow: hidden ;}: fullscreen-ancestor {/* ancestors of A fullscreen element shocould not induce stacking contexts that wowould prevent the fullscreen element from being on top. */Z-index: auto;/* ancestors of A fullscreen element shocould not be partially transparent, since that wocould apply to the fullscreen element and make the page visible behind it. it wocould also create a pseudo-stacking-context that wocould let content draw on top of the fullscreen element. */opacity: 1;/* ancestors of A fullscreen element shocould not apply SVG masking, clipping, or filtering, since that wocould affect the fullscreen element and create a pseudo-stacking context. */mask: none; clip: none; filter: none; transform: none ;}

3. html tag attribute: allowfullscreen

For example, the <Object> and <embed> used by flash can be used to set whether to allow full screen. This feature can also be applied to the <IFRAME> label. You only need to add the allowfullscreen attribute:

 
<! -- Content from another site that is allowed to use the fullscreen command --> <IFRAME width = "640" Height = "360" src = "http://anothersite.com/video/123" allowfullscreen = ""> </iframe>
 

Iii. Solutions

Generally, full screen is mainly used in videos and games. Of course, it can also achieve full screen display like Mac lion, just like preview. App. It is very nice to use in full screen. Games and videos can use flash to be compatible with old browsers and browsers that do not support fullscreen JavaScript APIs. Like Firefox nightly (supported by V10), chrome 15, Safari 5.1 can use the jquery plug-in of johndyer: https://gist.github.com/1354468

Iv. Summary

The current problems may be:

1. IE has no arrangement for the implementation of this function
2. Is full screen implemented in the browser or built-in full screen on Mac? Chrome implements the full screen built in lion, while safari implements the full screen of the browser.
3. Security Question: Is a system login box forged in full screen?
4. Should all elements be covered by full screen content?

It seems that we are paying more attention to points 1st and 3rd, and we also need to pay attention to them. On the contrary, it is relatively simple to call APIs, so you do not need to think so much.

Reference Demo: fullscreen javascript API

V. Reference Documents

1. Handle the reference event: let your content do the talking: fullscreen API
2. Most code references this article: Native fullscreen javascript API (plus jquery plugin)
3. History and discussion: fullscreen HTML5 video
4. Comparison between standards and vendors: W3C draft: fullscreen