Discussion about the first draft of
This page is to discuss the first-draft of W3C’s <picture>-element. Discussed and voted changes will be submitted to Wiki = draft.
1) Wouldn’t we drop alt attribute from picture to make use of the full alternative content inside the <picture>-wrapper? Thought we discussed this in several threads already… I personally think this makes sense.
2) Do we really need <picture> as element-name? WHATWG mailing list and its contributors seem to have spoken that img could also work…? If it would, it would be a much smarter solution.
3) Templating ways are still missing. We never discussed this to the end…
4) Does it really make sense to provide srcset along with media attribute? I think it is much better to either use srcset and let the UA detect which one to choose or provide media and fixed source to serve as the developer wants to.
1) I agree that dropping the primary alt attribute makes a lot of sense. Per Mat’s write-up, it seems to me that if we want freedom to change source and allow for theoretical change in composition, we should move alt attribute directly on source tag itself allowing for better descriptive power for accessibility.
2) I do not agree that img should serve this purpose. IMO, img should not be extended in attributes. The img should remain untouched and used as fallback much the same way object continues to serve as a fallback for video. Picture much like video should serve as an evolution of a 20 year old tag allowing greater control for architects and developers. Are we really doing ourselves justice by trying to throw everything at img and expecting the UAs to properly degrade gracefully? Picture gives us far greater wiggle room and I think many outside the WHATWG group would agree. It makes little sense IMO to waste resources modifying img behavior when we can use the existing behavior to allow for graceful fallback and aged browser support
Discussing altering the tag came up early on, and sounded like it was technically infeasible – the FAQ indicates that it’s a no-go.
As for templating, initially I was disappointed that that wasn’t included, because I feared having lots of duplicated media queries attached to every image on a page, but after reviewing the proposal, it looks like these would only be required in editorial situations, which would need to be done on a case-by-case basis.
Although we have been discussing the picture element on this group for sometime as well, as Mat and others can attest to, it is not the only discussion on this matter.
Sadly, the WHATWG has been discussing the direct modification of img for months now. I haven’t read each post related to MQs and RespImg but srcset is one of the focused discussions for direct modification of img currently on the WHATWG mailing list.
For anyone on this group, I would make the strong recommendation to join the discussions there as well as you are only really seeing one small subset of the discussion here.
I could be misunderstanding, but I was under the impression that the issue with modifying the img element wasn’t with adding new attributes to the element, but with changing it from a self-closing tag to a tag that allows child elements due to the specification implemented in legacy browsers.
If that’s correct, what WHATWG has been proposing is in line with their initial discussions.
That said, I’m against modifying the img tag to be the container. The picture element that has been proposed is no less inherently supportable than any of the other new HTML5 elements and any new functionality would have the same issues being added to the img element.
That is correct. The objection is to the addition of child elements to the img tag.
Our misunderstanding was to believe that when people said the img tag was something browser makers wouldn’t change that it also meant no changes to attributes. That’s why the quick acceptance of srcset caught many of us off guard.
“1) Wouldn’t we drop alt attribute from picture to make use of the full alternative content inside the -wrapper? Thought we discussed this in several threads already… I personally think this makes sense.”
I disagree. The way I look at it is that if the alt description for an image changes, it is truly a different image and should have a different representation in the DOM.
Can someone describe a use case where the alt tag would change from source to source?
One change that I would like to see is the addition of the alt tag on the img tag. Not DRY, but necessary for backwards compatibility, correct?
“2) Do we really need as element-name? WHATWG mailing list and its contributors seem to have spoken that img could also work…? If it would, it would be a much smarter solution.”
We need a new element if the markup we propose includes child elements. IMG cannot support child elements.
“3) Templating ways are still missing. We never discussed this to the end…”
There were objections to this on the WhatWG list:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035839.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035843.html
It is difficult for me to tell how serious these objections are. This is the challenge we have with our discussions when the browser makers aren’t engaged in the conversation.
From a strategic perspective, I believe it is better to push forward one proposal–in this case picture–so that we can get browser makers engaged in the discussion again. I feel like bringing up templating muddies the water and makes it harder for browser makers to engage.
My strong preference would be to push forward with picture to get debate moving forward again. Florian’s compromise proposal has several things going for it:
1. It was developed by the chair of the CSS WG which means it can’t be easily ignored.
2. We haven’t received strong pushback from browser makers yet. It may be forthcoming, but so far browser makers seem open to it. In fact, we’re getting some behind the scenes support.
3. We have a proposal we can work with.
My position is that we need to move the conversation forward. Reopening the templating discussion may make sense at some point, but now is not the time IMHO.
“4) Does it really make sense to provide srcset along with media attribute? I think it is much better to either use srcset and let the UA detect which one to choose or provide media and fixed source to serve as the developer wants to.”
I will defer to Florian’s explanation in his original email to the WhatWG list:
“Leaving syntax aside, I think media queries in relation to images can be useful. Providing a different image based on aspect ratio, color depth, viewport size, etc can certainly make sense.
But I am skeptical that media queries can solve the responsive image problem well, because I don’t see how one could make a bandwidth or latency media query that doesn’t cause already downloaded content to be discarded when the conditions change, other than by making it not update to reflect the current conditions, which would make it fairly useless.”
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036160.html
I concur with his assessment.
1) No, it is not about having alt-attributes in all source-elements but about one alternative content inside the picture-element similar to the source-elements.
alternative content
2) Thanks for this. I just forgot about that. So for long-hand sytax picture-element is needed. That’s fine then.
3) I fully agree. I just wanted to ask once again because back then nearly no one replied to Matt’s questions. But let’s delay this to a point later.
4) Yes, it is or better can be useful. Thanks.