This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The img src attribute and srcset behaves different when presented with spaces: for example, "Screenshot 10.2.2012 100 1x 2x Funny Cat.jpeg" in @srcset results in "Screenshot" as the candidate. However, when fed to img@src, the resource name is parsed as expected. Confirmed by: http://responsiveimagescg.github.com/picture-refimp/demo/?srcset=Screenshot+10.2.2012+100+1x+2x+Funny+Cat.jpeg
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: No spec change. Rationale: The behavior of <img src> and <img srcset> differs when they are passed nonconforming URLs, but <img src> and <img srcset> behave the same when passed conforming URLs. We can't change <img src>'s behavior due to backwards compat constraints, whereas there is no legacy content using <img srcset>.
I agree with the rationale, but would really like a non-normative notes added to the spec clarifying this (i.e., this is a feature, not a bug! :) ).
I think it would be reasonable for tutorials and other supplementary material to mention the inconsistency between src="" and srcset="" when passed non-conforming URLs. That said, I don't think the spec needs to go out of its way to point this out.
(In reply to comment #3) > I think it would be reasonable for tutorials and other supplementary > material to mention the inconsistency between src="" and srcset="" when > passed non-conforming URLs. That said, I don't think the spec needs to go > out of its way to point this out. WFM. Just wanted to make sure it was not something that was overlooked.