Which means that some elements inside the shadow DOM subtree can be styled by targeting them via their associated pseudo-element. We need to be able to style the controls which are part of the shadow DOM, but how do we do that if the regular CSS selectors we know can’t access Shadow DOM elements?Īfter reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which allows shadow DOM subtrees to associate an arbitrary pseudo-element identifier with an element in the subtree.” So we know now that the controls added to the video tag are just part of the shadow DOM sub-tree generated for this tag by the browser. Also, as James Edwards also said in his article:īecause it’s isolated, users can’t accidentally break it, there’s no possibility of naming conflicts with any classes or IDs you use, and the CSS on the main page won’t affect it at all. The reason why browsers do this is because browser developers decided to encapsulate some DOM elements to hide them from us developers so we’re not concerned with the implementation details of these elements, in an attempt to make things easier for us to work with. In fact some browsers already use this to render some of their native widgets. Effectively, the content of a Shadow DOM is a different document, which is merged with the main document to create the overall rendered output. The Shadow DOM encapsulates content by creating document fragments. James Edwards summarizes the function of the shadow DOM perfectly in his article for SitePoint: Plainly speaking, it’s a bunch of DOM elements, the same as the ones you’re already familiar with, like s and s, which are added by the browser as a document fragment, and are rendered on the page just like the main DOM tree. The subtree of DOM elements generated by the browser is what we call the “Shadow DOM”. Note that the technique explained in this article to hide the native controls works only in browsers that support the Shadow DOM. But what about the first point? How can we hide elements that the browser adds but we can’t see in the DOM tree we’re working with? We do that all the time in our stylesheets. The second point is easy: just override the user agent stylesheet. How do we make this work? How do we prevent the native controls from appearing in full-screen mode and show our own custom-styled controls instead? The high z-index applied by Chrome’s user agent stylesheet Inspecting the controls with the dev tools showed that the reason the controls were hidden below is because the user agent’s style sheet (in this case Chrome’s style sheet) was overriding the styles applied to the controls, with a very weird z-index value, I must say! The custom controls were hidden below the video in the full-screen mode.By setting the controls attribute of the video element to false, we are able to hide the controls but for some reason, when entering full-screen mode they reappear, despite being hidden in normal screen mode. (Update: this bug is filed in the Chrome bug tracker).Īfter some inspection in the dev tools, I found that: Like so many others, I searched around for answers to this problem but had no luck finding any. Instead of displaying the custom controls I was working on, native browser controls appeared on the video when it entered the full-screen mode. While working on a custom HTML5 video framework lately, I stumbled upon an issue which a lot of designers and developers stumble upon in this area. The problem of HTML5 video controls in full-screen mode These elements (buttons, sliders, etc.) are part of the DOM, but you can’t actually see them in the main DOM tree, you only see them rendered onto the page. Where did all these control elements come from?īrowsers add these controls as a “sub-tree” of the video tag into the rendering of the document. If you’ve ever worked with HTML5 video then you have probably wondered how you get a bunch of control buttons, sliders, and slider thumbs on your page, when you’ve only added a single tag to the DOM.
Digging into the shadow DOM, Sara finds a solution…
#VIDEOCANVAS CONTROLS FULL#
She was working on some custom HTML5 video controls and noticed that the customizations were lost when the video went into full screen mode ( example of that happening).
I know Sara through all her excellent work on CodePen. The following is a guest post by Sara Soueidan.
0 kommentar(er)
