srcset added to WHATWG spec
Despite significant opposition from developers, the srcset attribute has been added to the WHATWG’s HTML spec by Ian Hickson. He has written a long email to the mailing list commenting on many of the issues and explaining his actions.
As the news broke and the uproar began on Twitter, the W3C replied, saying they are “looking at this” and to “stay tuned”.
Expect more developments soon.
Yes I look forward to seeing the official reply. Although his email was very well thought out, and a lot of it did make sense… it was, in my opinion, wrong for him to ignore the work that everybody here has been doing especially when there has been so much opposition.
Hi all,
My name is Ian Jacobs (W3C). I’m in meetings this week and have not caught up on the lengthy thread.
I look forward to working with you to help connect your work with other parts of the W3C community.
I will say that your group seems already to be having an impact.
Ian
One of Ian Hickson’s main issues with the picture element seems to be how verbose it can become.
Srcset seems marginally less verbose, though I think we can do better. If we continue with the picture element, yet add an option of using meta media variables and a URI template we can continue to use the picture element in its full form, or have an option to keep it short and simple.
Here’s an excerpt from the email, Ian quotes Matt and responds with “I don’t understand what this means”
I’m pretty sure it means the srcset attribute will clash with prefetching such that UA’s wont support it.
I’m a developer and support srcset.
There may be an opposition from this self-selected group which is invested in the picture solution, but please don’t generalise that to dev community as a whole.
Kornel
I certainly didn’t intend to generalise or speak for all devs, which is why I wrote “significant” and not anything like “unanimous” or “overwhelming”.
I’ll start by saying thanks to everyone involved here, who has put in the time and energy and really pushed this forward. It won’t go unnoticed that’s for sure and definitely won’t go unappreciated.
But…
I’m not at all surprised at this turn of events.
For weeks and possibly months there has been growing concern over the picture element, as proposed, as it was exposed to more of the dev community.
Many ideas were brought forth as solutions and/or fixes/updates to the picture elements verbosity – within the comments on this group, with examples of cleaner markup and even a new polyfil as of late.
A tonne of thinking has gone into making the “proposed” picture element a more robust solution but all of this seemed to fall on deaf ears.
My question would be, why did all work on bettering the current picture proposal ceased, even with all the negative feedback?
There has been talk here and there of expanding the idea sure, cleaning it up later, but at this point that thinking has worked against the proposal to a certain degree.
When we get down to brass tax, the currently proposed picture element isn’t up to snuff, and it shows. There are weakpoints which have been pointed out on numerous occasions, which have been *noted by some but not really addressed. I’m actualy a bit surprised at the lack of understanding of why srcset was chosen as opposed to picture.
Now, the chance may present itself to muscle back in to the conversation with help from the W3C, but i’d suggest if and when doing so to come to the table with an updated version of the picture element that has taken the communities advice on slimming the verbosity down and addressing the maintenance issues head on.
Seems to me if we as a community would like to contribute to the bigger picture we should come to that table with a *bulletproof* solution, not something half assed that has holes, with verbage included like “we’ll fix it later”.
Having the concenesus from the community for picture because “it’s more like video” so it’s awesome, isn’t going to cut it — this particular point was directly brought up in the mailing list regarding the “concensus building thread” located here.
And if you cut through the bullsh*t, you’ll actually see that a good percentage of people agreeing to ‘picture’ over ‘set’ didn’t really like the idea of picture either. Given the available options though between the 2, picture was the lesser evil.
This to me doesn’t bode well for concensus from the community.
Personally,
– using the “head” seems like a good theory but really needs to hashed out. Not convinced about the {imgDirectory} bit, but a step in the right direction i think.
– srcset in theory is fantastic, but it’s current markup is just as verbose and poses alot of the same issues as the current picture element.
– maintenance of either at this point will be a disaster, unless using a “head” theory or something of the sort.
I don’t mean to ruffle any feathers right now, but heads need to get removed from sand and start moving forward with proposing a picture element that actually works.
I’m curious, what do you see in the picture element that doesn’t “work”?
Sure, it’s verbose, but news flash: it’s HTML.
In the world of semantic markup, things get verbose. We’re trying to make it clear what the structure/intent of the content is.
Access to head elements in frameworks are unreliable, and would make working in teams harder — I agree with Ian there, but I simply cannot see that srcset is a superior overall solution to the needed evolution of img than picture.
I’m curious, what do you see in the picture element that doesn’t “work”?
Media queries baked into the markup. Have you not seen some of the examples brought forth that picture could become, on this site?
Redesign a website after 4 years of hardcoding media queries into the markup. Good luck to you I say sir, as I would bet those media query values will change and you will have no other choice but to update, by hand, every value to the new.
This is a maintenance trainwreck waiting to happen. We need to remove them the markup and have a them managed in a global fashion.
There has been much talk of this for months, on this blog, in the comments, new proposals, polyfils etc.
There is a reason why Matt Wilcox has been so adament in pushing new ideas, markup patterns, proposals etc.
Media queries baked into the html is just a bad road to go down.
you’re ok with writing markup like this? https://gist.github.com/2509534
I sure as hell am not, and I’m not the only one.
Ok.
Something just clicked for me.
And why srcset fails is the exact same reasoning.
We need to be able to describe images based on the space available for the image, not the viewport, but I believe that has already been shot down because of how css is processed and such. I don’t think that means it shouldn’t be done that way or that shouldn’t be pursued as the ultimate goal, however. Any ideas on that, anyone?
Ultimately I just want a good solution.
The viewport thing is a concern for me too, unless I’m missing something I just don’t see how that will lead to a responsive image.
As far as I can see, you either size an image according to the ultimate available width (e.g. 256px width for an image intended as 25% of a 1024px display) and then the UA chooses that image as the right fit.
OR you design an image for use in a a min/max resolution, and the image is selected based on screen size (which.. actually seems a lot simpler, and more flexible – neither does it require layout processing).
Amen.
I would suggest you don’t swallow the WHATWG line that they are the owners of HTML’s future. Yes they are a powerful group, but as I have learned from 5 years in the W3C HTML working group is that people other than the WHATWG crowd can influence the development of HTML, you just have to persevere and persevere and…