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/embedded-content-1.html Multipage: http://www.whatwg.org/C#the-img-element Complete: http://www.whatwg.org/c#the-img-element Comment: The srcset attribute is poorly conceived and much inferior to the proposed <picture>-element. Posted from: 92.62.32.132 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.3 Safari/534.53.10
This bug was cloned to create bug 18164 as part of operation convergence.
Could you elaborate on how it is inferior?
I’m seeing a number of bugs like this one appear in the tracker. While I don’t think they’re especially helpful in and of themselves: since the question was raised, I’m happy to respond. As things stand today, the extended `srcset` syntax covers only a fraction of the use cases covered by the `picture`/`srcset` markup proposed here: http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html This is, of course, to say nothing of the fact that this siloed microsyntax will either require ongoing development in parallel with media queries, or will only ever the use cases that it covers today. In the case of `picture`, the element’s usefulness could continue to expand as media query specification is expanded—for example, the recently-proposed “high contrast mode” media query could be used to serve more context-appropriate images to users browsing by way of assistive technologies. This is something `srcset` cannot provide today, and will likely never provide in the future—unless developed independent of media queries. In terms of author preference, well, I’ve repeated myself more than enough on that subject and I think the bugs like this that have been appearing here — while I do discourage them — will speak to that. A brief skim through the comments on http://www.w3.org/community/respimg/2012/05/11/respimg-proposal, or even a Google or Twitter search for “responsive images” will prove authors’ sentiment better than anything I could say here. I have yet to see a provable user benefit cited for the extended `srcset` syntax. It plainly covers less use cases than the `picture` proposal, and has very limited potential for future use cases. The only arguments I’ve consistently seen in favor of the extended `srcset` syntax is that it’s preferable for implementors, and nebulous promises of author preference. However, to continue insisting that its terseness implies a future author preference, well, I think we can safely discard that argument. In fairness, I’ve actually asked them. We’re left only with implementor preference for `srcset`, which certainly shouldn’t trump a number of additional use cases, “future friendliness,” and strongly-voiced author preference. So, all things considered: could you elaborate on how it’s superior?
(Please reopen bugs when adding comments, or they run a high risk of being missed.)
(In reply to comment #3) > I’m seeing a number of bugs like this one appear in the tracker. If you could give their numbers in the "See Also" line (or in a bug comment) that would be really useful. > As things stand today, the extended `srcset` syntax covers only a fraction of > the use cases covered by the `picture`/`srcset` markup proposed here: > http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html If there are specific use cases that aren't addressed, please send feedback to the WHATWG list (or file bugs) on those use cases. > This is, of course, to say nothing of the fact that this siloed microsyntax > will either require ongoing development in parallel with media queries, or will > only ever the use cases that it covers today. That's not a big deal, adding a new feature to this syntax is easy. > So, all things considered: could you elaborate on how it’s superior? These e-mails detail the reasoning behind the current specification text: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0064.html
@hixie, all, we have started collecting the use cases here: https://github.com/Wilto/draft-prop/blob/master/UseCaseComparisons.md For cases where img@srcset is "N/A", we were not able to come up with a sensible solution. Can you show us how img@srcset would be used to meet those cases? We can add you on Github and you can edit the use case document directly. If you prefer, we can file them as separate bugs here.
Filing them as separate bugs would be awesome. Note that use case descriptions need to also have some measure of _why_ the problem exists. For example, rather than just "water needs to be cleaned", you would say "dirty water leads to disease and health risks, so water needs to be cleaned". Rather than "assuming three image breakpoints based on maximum widths", you would say "a single page should work on devices with different widths, and so you may have a page whose layout and images need to change based on the width of the viewport" (which doesn't say whether they should be maximum or minimum breakpoints; if there's a reason to prefer one or the other, you'd have to elaborate the use case to explain why only one of the two would solve it).
(The key being, a use case / problem description should not assume a solution.)
(In reply to comment #8) > (The key being, a use case / problem description should not assume a > solution.) Agree completely. We will do our best to make sure the use cases and requirements remain neutral.
FYI, we've now made a separate document which is independent of any solution. http://responsiveimagescg.github.com/ri-usecases/UseCases.html Over the next week, we will continue to edit the use casesto make sure they are written correctly and then send them to the HTMLWG for review. If you have some more examples of well-written use cases, please let me know. Or if you see any further deficiencies with the ones in the document, let me know and I can do my best to fix them. After we are sure the use cases are ok and all requirements are captured. I'll file them as individual bugs. HTH!
Thanks. I've assigned this bug to you for now since there's nothing for me to do until those bugs are filed.
Done. Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20172 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20173 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20174 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20175 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20176 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20177
Those are all filed on the HTMLWG; if you meant for them to be WHATWG bugs let me know and I can move them over.
We’ll be cloning them to the WHATWG tracker shortly. (Per https://twitter.com/hober/status/273890295605760000 )
Cool, thanks.