This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25153 - "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 [...]
Summary: "When a media element is created, if it has a muted attribute specified, the ...
Status: RESOLVED DUPLICATE of bug 25460
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-26 10:02 UTC by contributor
Modified: 2014-05-05 22:30 UTC (History)
5 users (show)

See Also:


Attachments

Description contributor 2014-03-26 10:02:58 UTC
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)
Comment 1 Anne 2014-03-26 10:56:56 UTC
What exactly is the problem? That whole clone operation is atomic.
Comment 2 Philip Jägenstedt 2014-03-26 11:13:57 UTC
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.
Comment 3 Anne 2014-03-26 11:19:30 UTC
Ah, in a web component world the "created" check would happen later in a callback. That might work well for this too.
Comment 4 Philip Jägenstedt 2014-03-26 11:39:25 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2014-03-31 17:12:57 UTC
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?
Comment 6 Philip Jägenstedt 2014-03-31 18:22:37 UTC
(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.)
Comment 7 Simon Pieters 2014-03-31 22:20:46 UTC
(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.
Comment 8 Philip Jägenstedt 2014-04-01 04:04:13 UTC
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.
Comment 9 Philip Jägenstedt 2014-04-25 11:35:18 UTC
I filed a separate bug for my above comment:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25460
Comment 10 Ian 'Hixie' Hickson 2014-04-28 22:26:51 UTC
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.
Comment 11 Philip Jägenstedt 2014-04-29 13:22:09 UTC
"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.
Comment 12 Ian 'Hixie' Hickson 2014-04-29 21:33:47 UTC
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.
Comment 13 Philip Jägenstedt 2014-04-29 21:52:01 UTC
Oh, right you are.
Comment 14 Ian 'Hixie' Hickson 2014-05-01 21:47:38 UTC
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?
Comment 15 Philip Jägenstedt 2014-05-02 22:58:11 UTC
Yes, when I filed the bug I just wanted clarification on what cloneNode would do, then I went off-topic.
Comment 16 Ian 'Hixie' Hickson 2014-05-05 22:30:19 UTC
Ok, I'm marking it as a dupe then.

*** This bug has been marked as a duplicate of bug 25460 ***