This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#the-audio-element Complete: http://www.whatwg.org/c#the-audio-element Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: new Audio(src) need not invoke the resource selection algorithm Posted from: 113.23.85.48 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.68 Safari/537.36 OPR/19.0.1326.26 (Edition Next)
"If the src argument is present, the object created must have its src content attribute set to the provided value, and the user agent must invoke the object's resource selection algorithm before returning. " Invoking the resource selection algorithm is redundant, because setting the src attribute already invokes the media element load algorithm, which invokes the resource selection algorithm as its last step.
The constructor creates the element with the attribute already set, the attribute is never actually "set" in the sense that triggers the algorithm. This is similar to the situation with the parser. Maybe I should use the word "added" instead of "set" to refer to the act of setting the attribute with setAttribute()...
The way it's implemented in both Presto and Blink is to just set the src attribute after element creation, which triggers the logic for setting/modifying the src attribute and runs the load algorithm. The same appears to be true in Gecko: http://hg.mozilla.org/mozilla-central/file/8f4ecbf938cd/content/html/content/src/HTMLAudioElement.cpp#l73 Yes, running the load() algorithm in this state is kind of pointless since it's equivalent to the resource selection algorithm, but hardly worth optimizing for. Since at least 3 implementors have interpreted in the same way, maybe just go with that?
How is that black-box distinguishable from creating the element with the attribute already set? I'm not sure how comment 3 and comment 2 relate.
This is an editorial issue since the media element load algorithm on a newly created element only invokes the resource selection algorithm. When I filed the bug I assumed that "the object created must have its src content attribute set to the provided value" would trigger the steps in "If a src attribute of a media element is set or changed" and that also invoking the resource selection algorithm is therefore redundant. You want to make it clearer that the element is created with the attribute already there so that the media element load algorithm is not run. I'm arguing that it's easier to understand the way that it's actually implemented, by simply setting the attribute.
(In reply to Ian 'Hixie' Hickson from comment #2) > The constructor creates the element with the attribute already set, the > attribute is never actually "set" in the sense that triggers the algorithm. > This is similar to the situation with the parser. If the parser should not trigger "If a src attribute of a media element is set or changed" then there is nothing that will cause media elements to start loading, since there's no longer a hook for when they are inserted into a document. Oops? (Both implementations I am familiar with treat a parser-set attribute the same way as a script-set attribute: by invoking the load algorithm.)
Wow, yeah, I totally missed that case. (You can tell that the spec intends it the way I'm describing, by the way, because it uses the _load_ algorithm when you set src="", but jumps straight to the selection algorithm when you insert a <source> into a dead <video> elmeent or create an Audio element using the constructor. The load algorithm is only useful when you're doing something and the element might already have had something loaded; in the initial case, it isn't useful and the spec skips it.) I've added a requirement for what happens when a media element is created with the attribute set, and rephrased the constructor comment to be non-normative, which hopefully resolves this. Reopen if you think it's still confusing, wrong, or redundant in some way. Thanks!
Checked in as WHATWG revision r8422. Check-in comment: Make sure newly created <video> and <audio> elements with a src='' attribute actually load the media. http://html5.org/tools/web-apps-tracker?from=8421&to=8422
Thank you, this is an improvement. To match "If a media element is created with a src attribute" I would go with "If the src argument is present, the element must be created with its src content attribute set to the provided value". You may re-resolve this bug if you don't think that's better, I can live with the current wording.
Yeah, that's a good point. Thanks. Done.
Checked in as WHATWG revision r8429. Check-in comment: Improve wording of Audio constructor further. http://html5.org/tools/web-apps-tracker?from=8428&to=8429
LGTM!