25153 2014-03-26 10:02:58 +0000 "When a media element is created, if it has a muted attribute specified, the user agent must mute the media element's audio output, overriding any user preference." - what is intended to happen for <v [...] 2014-05-05 22:30:19 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED DUPLICATE 25460 http://www.whatwg.org/specs/web-apps/current-work/#user-interface P3 normal Unsorted 1 contributor ian annevk ian mike philipj zcorpan contributor oldest_to_newest 102908 0 contributor 2014-03-26 10:02:58 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#user-interface Complete: http://www.whatwg.org/c#user-interface Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: "When a media element is created, if it has a muted attribute specified, the user agent must mute the media element's audio output, overriding any user preference." - what is intended to happen for <video muted>.cloneNode()? (The DOM spec says to first create the element and then copy the attributes.) (Context: https://critic.hoppipolla.co.uk/showcomment?chain=3191 ) Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36 OPR/20.0.1387.59 (Edition Next) 102913 1 annevk 2014-03-26 10:56:56 +0000 What exactly is the problem? That whole clone operation is atomic. 102914 2 philipj 2014-03-26 11:13:57 +0000 It doesn't look atomic, it has steps like any other algorithm and the only way I can interpret "Let copy be a node that implements the same interfaces as node." is that this is the point where "When a media element is created" would be triggered. 102915 3 annevk 2014-03-26 11:19:30 +0000 Ah, in a web component world the "created" check would happen later in a callback. That might work well for this too. 102918 4 philipj 2014-03-26 11:39:25 +0000 I don't think it's very important how muted works with cloneNode since it's a declarative feature anyway. In Blink my interpretation was the one that came naturally, so I'd be happy if that's what the specs end up saying, but anything is fine really. 103185 5 ian 2014-03-31 17:12:57 +0000 Why does it matter if the attributes are copied after the element is created? Are you concerned about the 'volumechange' event being fired? Anne, why aren't we just create the clone with the attributes instead of as two separate steps? 103189 6 philipj 2014-03-31 18:22:37 +0000 (In reply to Ian 'Hixie' Hickson from comment #5) > Why does it matter if the attributes are copied after the element is > created? Are you concerned about the 'volumechange' event being fired? I don't think it matters much how this works, as long as the spec is clear. Alternatively, the muted (and mediagroup) attribute handling could be changed to just trigger when setting the content attribute regardless of cause. I doesn't seem to matter much to me, and it turns out that the special case for the parser caused a 1-2% performance regression when I tried implementing it: https://codereview.chromium.org/205683003/ (Possibly I just suck at programming, it's hard to say.) 103209 7 zcorpan 2014-03-31 22:20:46 +0000 (In reply to Ian 'Hixie' Hickson from comment #5) > Why does it matter if the attributes are copied after the element is > created? It matters here in that it affects whether the cloned element is muted or not (which is exposed to JS using .muted IDL attribute). If it's created without attributes, it's not muted. Adding the muted attribute afterwards does nothing. > Are you concerned about the 'volumechange' event being fired? No, that wouldn't fire either way I think. 103216 8 philipj 2014-04-01 04:04:13 +0000 At this point I think the spec should just not use the notion of attributes existing at the time an element is created. How about just "If the muted content attribute of a media element is set, the user agent must set the muted IDL attribute to true."? Same with mediagroup. 104436 9 philipj 2014-04-25 11:35:18 +0000 I filed a separate bug for my above comment: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25460 104601 10 ian 2014-04-28 22:26:51 +0000 As far as I can tell, mediagroup is just a regular non-magical attribute as far as setting vs creation goes. muted="" is special because when it's absent on creation, the browser is supposed to be able to mute the element anyway, so as to honour user preferences, but when it's present on creation, the element must be muted; in normal cases, the attribute is supposed to do nothing but change what the default is considered to be, for the purposes of the API and UIs based on the API (actually muting and unmuting is done via .muted, which doesn't affect the content attribute or the default, and can be done by the user via the UI). I don't really understand how you want muted=""/.defaultMuted/.muted to work. 104679 11 philipj 2014-04-29 13:22:09 +0000 "When a media element is created with a mediagroup attribute" is what makes mediagroup special-cased in the parser in the same way as muted. 104723 12 ian 2014-04-29 21:33:47 +0000 The rest of that sentence is "and when a media element's mediagroup attribute is set, changed, or removed", which is what makes it _not_ special cased. If it _only_ said "when a media element's mediagroup attribute is set, changed, or removed", _then_ it's be special-cased for the parser. 104734 13 philipj 2014-04-29 21:52:01 +0000 Oh, right you are. 104936 14 ian 2014-05-01 21:47:38 +0000 I've filed bug 25529 to track the DOM cloning part of this. The rest of this looks like it's just the same as bug 25460, right? 104998 15 philipj 2014-05-02 22:58:11 +0000 Yes, when I filed the bug I just wanted clarification on what cloneNode would do, then I went off-topic. 105118 16 ian 2014-05-05 22:30:19 +0000 Ok, I'm marking it as a dupe then. *** This bug has been marked as a duplicate of bug 25460 ***