This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #26949 +++ There is a conflict between this restriction "Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. To change what is playing, just use the src attribute on the media element directly, possibly making use of the canPlayType() method to pick from amongst available resources. Generally, manipulating source elements manually after the document has been parsed is an unnecessarily complicated approach." and the shadow DOM distributions spec http://w3c.github.io/webcomponents/spec/shadow/#distributions that results in the video tag not being able to be constructively used inside a web component Example here: http://jsfiddle.net/n88owmop/4/
Can you elaborate? The non-normative text you quoted is talking about that, once the resource selection has selected a video, changing the attributes etc on the <source>s will not do anything automatically. However you can call .load() to make the load algorithm start over. But I don't see how any of this is relevant to your example.
Shadow tree distribution affects the layout tree, not the DOM tree, and therefore nothing is modified and the algorithm works just fine.
(In reply to Anne from comment #2) > Shadow tree distribution affects the layout tree, not the DOM tree, and > therefore nothing is modified and the algorithm works just fine. So is the jsfiddle that Dylan provided supposed to work?
I doubt that should work. 1) It uses <source> outside of where it is allowed. 2) Algorithms for media elements and <source> do not cross shadow tree boundaries.
On your point #1 - here is an example that does not use source outside of where it is allowed. http://jsfiddle.net/6gvtwoz3/ Surely this should be a valid use of a video element - especially if the shadow DOM were to contain custom UI controls. Your #2 point below is precisely the problem I am pointing out
Sorry, that version was a bit polluted, use this http://jsfiddle.net/6gvtwoz3/1/
*** Bug 26949 has been marked as a duplicate of this bug. ***
So I guess this amounts to a feature request for the resource selection algorithm to consider <source> elements over the shadow DOM boundary.
It seems unlikely to me that this will be the only situation where an algorithms might not work across shadow DOM boundaries so I think the following things should happen: 1) A declaration should be made in the normative part of this spec (or the web components specs or both) that states that all algorithms must work on the composed tree in the same way that they would work if that tree had been part of the standard DOM (with a statement about how to treat the shadow DOM nodes so that they do not cause problems - e.g. all children of Shadow DOM nodes should be treated as if they are the direct children of the shadow DOM node's parent node in the composed tree), 2) All the algorithms should be evaluated for potential changes, and 3) Any algorithms (including the one you mention) should be amended so that they work in the appropriate way
I don't understand why this should work. The spec is clear that it refers to the regular DOM, not the composed DOM. Why would we want to make <video> look at the composed DOM? The <source> element is for <video> and <audio> elements, not <video-player> elements.
Are you saying that this spec should not apply for <video> specifically or for all parts of the composed tree?
Why? If you want regular DOM operations to work, use the regular DOM.
The composed tree is used for rendering, accessibility, sequential focus, and event dispatch. That's basically it.
And playing a video as part of a composed <video> element is not considered "rendering"?
Playing the video might be, but the resource selection algorithm is definitely not rendering.
This may sound logical to you implementors, but as a user of these specs, I can only say that it makes absolutely no sense to me. I am not the only person who has come to this conclusion. The polymer example of a video player tries to do exactly the same thing and hence does not work in Chrome. So, while you are the ultimate arbiters, consider this: if the users of your system find it confusing but you find it logical, what is the right course of action?
Dylan, if you use the DOM to iterate over nodes, would you expect shadow tree nodes to show up?
I don't think you are asking the right question, but I will answer it and then give you my opinion as to what question I think you should be asking. There are multiple answers to the question, the first answer is "before having read and understood the shadow DOM spec, what would I have expected to happen?" The answer to that question is, I would have expected there to be a way to be able to traverse the composed tree using the standard DOM APIs. "After having read the spec, what would you expect to happen?" The answer is that I would not expect that to happen, and I now understand that you manipulate the shadow DOM and the regular DOM independently and the browser takes care of composing. However the relevant question should be: If it is possible to compose a list item from a custom element in the regular DOM into an unordered list in the composed tree and have it rendered as a list item within an unordered list, would you expect it to be possible to compose a source element from a custom element in the regular DOM into a video element in the composed tree and have it rendered as the video's source? My answer to the above is "yes" http://jsfiddle.net/Ln4oe387/
Part of shadow tree's concept is that it provides some form of encapsulation. So you don't get into it by accident. (Even more different is <input>, which has a shadow tree that is completely isolated, you cannot get in.) Now the question is whether algorithms that operate on trees should instead operate on composed trees (though still lacking the isolated trees) and whether that is a change worth making. And that very much depends on use cases and requirements, and is not a simple question and answer game.
https://github.com/addyosmani/video-js/issues/2
There is the overall question of ease of use too and one component of ease-of-use is logical consistency. By constraining what works and what does not work, you are placing a high burden on the user to understand details of the implementation. With a clear understanding that this is a sweeping generalization, I will say that good designs should hide complexity
By making the convention be that you have to walk the composed tree, we're putting a high burden on component authors also (since now they have to have tons of logic for handling the composed tree changing, rather than being able to just use mutation observers to handle the actual DOM changing). I think this is working as intended. <video> uses its children. The composed tree is used for rendering, accessibility, sequential focus, and event dispatch (all of which are basically "rendering"), but element logic still uses the core DOM.
Is that the same reason that this example using the details element also does not work? http://jsfiddle.net/Ln4oe387/1/ If this is going to be a reality, then it seems to me as though there needs to be some documentation in the spec(s) that lists the set of elements that are not going to work in this way.
Yeah, that's not the way to do that. If you want to create a custom <details>, you either use is="" on a real <details>, or you build it from scratch, including all the accessibility logic, rendering logic, etc. There is documentation that lists the set of elements that are going to work this way: none of them. The composed tree is used for rendering, accessibility, sequential focus, and event dispatch. That's basically it. It is not used for semantics.
No discussion for over a year, and AFAIK we haven't had this request repeated elsewhere, so I'll close this as WORKSFORME.