Filing a separate bug since I left this as a comment only:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25153#c8

> 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.

With the parser special case, it's not clear how to implement the current spec without a slight performance regression. Maybe it can be done, but at least I'm not clever enough to implement it.

Note to future self: https://code.google.com/p/chromium/issues/detail?id=350303 is the Blink bug blocked on this spec bug.

I don't understand how this differs from bug 25153.

(In reply to Ian 'Hixie' Hickson from comment #3)
> I don't understand how this differs from bug 25153.

That bug is about how cloneNode should work with the muted attribute.

In reply to https://www.w3.org/Bugs/Public/show_bug.cgi?id=25153#c10

> 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.

Simply setting the muted IDL attribute to true whenever the muted content attribute is set (to anything) would work. Since defaultMuted reflects the content attribute setting defaultMuted to true would also set the muted IDL attribute to true.

Currently, Blink/WebKit check the muted content attribute as part of the resource selection algorithm, setting muted to true if it is present. That kind of works, but I don't like that the muted IDL attribute is a lie up until that point.

I'd probably be fine with any solution that doesn't differentiate between parser-created and otherwise-created elements, because that's something I don't think I'll be allowed to land in Blink.

So you're proposing that when the page changes the muted="" attribute, it also changes the .muted attribute, but not vice versa?

When would the user's preferences be applied?

(In reply to Ian 'Hixie' Hickson from comment #6)
> So you're proposing that when the page changes the muted="" attribute, it
> also changes the .muted attribute, but not vice versa?

Yes, that's the sanest suggestion I've been able to come up with, it's the closest to the current spec that doesn't have a parser special case.

> When would the user's preferences be applied?

That could simply be done when the element is created, since the attribute will be set later and would override the user preference. (The spec talks about attributes existing when elements are created, but in an implementation a parser still has to first create the element and then set the attributes.)

From the spec point of view, elements are created by the parser with their attributes. (And indeed, that's certainly how I'd implement it. The parser would construct the attribute table and then hand the pointer to the table to the element constructor so that the attribute table wouldn't have to be copied.)

So the only difference really is that you're saying that setting the .defaultMuted attribute to true later should change .muted to true, but setting it to false should not? That seems very unintuitive. It's not how .checked and .defaultChecked work, for example, IIRC.

(In reply to Ian 'Hixie' Hickson from comment #8)
> From the spec point of view, elements are created by the parser with their
> attributes. (And indeed, that's certainly how I'd implement it. The parser
> would construct the attribute table and then hand the pointer to the table
> to the element constructor so that the attribute table wouldn't have to be
> copied.)

OK, but that isn't how it's implemented in Blink or Gecko at least. Gecko has a special hook (DoneCreatingElement) for this. Blink doesn't, and adding one caused a performance regression.

(I think the parser just sets the attributes one-by-one as it finds them, it doesn't need to create and copy a table. It's pretty much the same code path as when you create an element and add attributes in a script.)

> So the only difference really is that you're saying that setting the
> .defaultMuted attribute to true later should change .muted to true, but
> setting it to false should not? That seems very unintuitive. It's not how
> .checked and .defaultChecked work, for example, IIRC.

"When the checked content attribute is added, if the control does not have dirty checkedness, the user agent must set the checkedness of the element to true" means set setting defaultChecked would also set affect checked. Here's a test case:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2993

Every browser I tested logs true and false. The latter doesn't seem per spec, but in any case the checked content attribute doesn't need a parser hook AFAICT.

HTMLOptionElement selected also doesn't need a parser hook, because "Except where otherwise specified, when the element is created, its selectedness must be set to true if the element has a selected attribute. Whenever an option element's selected attribute is added, if its dirtiness is false, its selectedness must be set to true. Whenever an option element's selected attribute is removed, if its dirtiness is false, its selectedness must be set to false."

But we don't have a "dirtiness" equivalent here. I guess we could introduce one? When would it get set and reset?

What would a dirty flag be used for? To make sure that adding the muted content attribute only sets the muted IDL attribute to true the first time?

Something like that, I guess. I'm not really sure I understand what we're trying to do here. I don't understand why what's in the spec isn't implementable in an efficient manner. The element is created, the "muted" state is set accordingly, then defaultMuted is just a dumb reflection of muted="" and neither has any interesting effect, and .muted controls whether the element is muted. This is equivalent to <input type=checkbox checked> and .defaultChecked/.checked, in a world where the element is immediately implicitly modified on creation, basically.

*** Bug 25153 has been marked as a duplicate of this bug. ***

The implementation of HTMLInputElement checked is actually a bit of a hack. Instead of setting the IDL attribute when the attributes have been set by the parser (there is no such hook) it does it when its children finish parsing. This is indistinguishable in HTML because <input> is a void element. However, you can tell the difference using XHTML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title></title></head>
<body>
<input checked=""><script>alert(document.querySelector('input').checked);</script></input>
</body>
</html>

This will alert false in Blink/WebKit, but true in Presto and Gecko.

I've asked some of the more experienced Blink developers to comment on this bug to see how we can resolve this.

Given that this affects more than just media elements, maybe the solution is just for there to be a hook to do this?

How do other browsers (especially Firefox) handle this?

(Filed https://github.com/w3c/web-platform-tests/issues/1044 .)

Raised https://github.com/w3c/web-platform-tests/pull/1047 to add the test case to the repo.

I guess this should be WONTFIXED?

I guess so, perhaps the <input checked> XHTML case and <video muted> together are enough to justify the change in Blink despite the performance regression.

I don't see why it would have to have a perf regression.