Closed Boldewyn closed 9 years ago
Looping in @stevefaulkner
Manuel/Boldewyn beat me to the bug report, but provides a very valid use case.
Here's another (and the one I am working with): A town photo, it is a wide ranging shot with a castle on a hill above the town. The initial caption reads something like "The town of Saumur, with a medieval castle and church tower its most prominent features". A smaller image is then used for smaller screens which only features the castle or perhaps the church, and the previous caption needs to be changed to reference what is contained within the new image.
This is also a problem for alt attributes.
The problem with @alt
may be solvable by allowing @alt
on the <source>
elements. I'd be surprised, though, if that hadn't come up before. (...digging through the list archive...)
I raised this concern I think years ago (was still in the beginning right after picture was proposed initially) and back then we kind of agreed that art direction shouldn't alter the alternative text of an image itself. I though still can imagine (as the examples of use cases show) that this could be useful sometimes.
I'm not familiar to the @alt
CSS property but I could imagine this can help here if allowed by spec. Ultimately, back then I proposed to allow the alt
-attribute on each source element which is, I think, not ideal as source needs to be altered and is not really thought to handle that.
Yeah, I mentioned that also on Twitter (https://twitter.com/iandevlin/status/538314872149540864), should have repeated it here, or perhaps create a new bug!
The idea is that all images should express the same information. Therefore alt should be the same for all images, since alt should also express the same thing.
Here's another (and the one I am working with): A town photo, it is a wide ranging shot with a castle on a hill above the town. The initial caption reads something like "The town of Saumur, with a medieval castle and church tower its most prominent features". A smaller image is then used for smaller screens which only features the castle or perhaps the church, and the previous caption needs to be changed to reference what is contained within the new image.
This is invalid since you don't express the same thing. If you want to show the town, don't crop away the town.
If you want to show different information for different environments, that is not what picture
is intended to do.
The use case: A photo of 5 people, art direction cuts off the left-most human for some variants. Then a
<figcaption>John Doe, 2nd from left</figcaption>
is not possible reliably.
This might be reasonable. If you find yourself needing this, I recommend doing it with javascript. You can listen for load
events on img
and check currentSrc
. If this is a common problem then it could make sense to introduce something declarative, but right now we need to wait for browsers to catch up with the existing feature set.
It's easy for you/us to say that what I gave as an example above is invalid, but what if it's not? Why should we force people to art direct so that the image shows the same thing?
"Do it with JavaScript" is not a valid answer in my opinion, there should be a native way of doing this, otherwise why bother with a native method for responsive images?
We can't force people much of anything. What I meant is that the use case in this bug was not in the original set of use cases (http://usecases.responsiveimages.org), so it is quite intentional to not address it. If it turns out that many use it for something it was not intended and it's missing something important, we can re-evaluate, but it's not clear to me that we're there yet.
HTML is not about giving a declarative solution to 100% of use cases. More like 80% of use cases. The remaining should be implemented with javascript. This is the case for any given feature set in HTML, e.g. forms.
As to why we bother at all, this is discussed in the spec's introduction (mainly because a JS solution to responsive images means the author has to choose between double download or no image when the script doesn't run).
On 1 December 2014 at 10:04, Ian Devlin notifications@github.com wrote:
It's easy for you/us to say that what I gave as an example above is invalid, but what if it's not? Why should we force people to art direct so that the image shows the same thing?
specs describe conformance requirements (I think) intended to constrain author use to practical application of the feature, given its limitations.
Well, it would surely be possible:
<figcaption class="wide">Foo</figcaption>
<figcaption class="narrow">Bar</figcaption>
@media (min-width: like <source id="wide">) {
.narrow { display: none; }
}
@media (max-width: like <source id="wide"> - 1) {
.wide { display: none; }
}
But you'd bind your markup semantics to the stylesheet...
For a JS solution: Is there no other way than inspecting img.currentSrc
to tell which <source>
is selected at the moment?
currentSrc
is currently the only way to look into what was picked (and is changed after the image started downloading and its dimensions are known).
Is it not sufficient to cover the above use-case?
I agree with @zcorpan that if different alt are absolutely necessary than you can provide that with JS (e.g. hang a data-alt
on each <source>
and have JS inspect currentSrc
, find the source used, and switch the alt text).
I would also argue that there's no reason not to provide the user with the most descriptive alt
on all viewport dimensions. The reason for art-direction is that the physical dimensions of the device the user is viewing the content with are limited, and we need to focus on the image's subject. That is not true for the text alternative. If you're using a screen reader to browse the content, your "physical dimensions" are identical regardless of the viewport dimensions.
That is not true for the text alternative. If you're using a screen reader to browse the content, your "physical dimensions" are identical regardless of the viewport dimensions.
True, but just for the record, a screenreader is only one of many accessibility use-cases. Thinking of contrast issues and similar I would still see it as helpful to provide different alt texts. But I can also agree with Steve that we probably shouldn't make the spec more complicated right now—and if it's just for the moment to get people used to the current spec.
I think Yoav has the right idea. Changing the viewport dimensions doesn't change the purpose of your web page. In my case, I want to display customized auto license plates. On wide screens, I show the license plate mounted on the back of the car, and on narrow screens I show just the license plate. What I want people to notice - what I want to say to them - doesn't change and neither should my alt="Custom license plate on Jeep Challenger"
.
When you crop an image of "The town of Saumur," that doesn't change the fact that "a medieval castle and church tower are the town's most prominent features". I don't see a typical accessibility use case for alt="John Doe, 2nd from left"
(it wouldn't help screenreader users) so that may be solely a figcaption
question.
Dear @mdmcginn: Your first example doesn't relate to the use cases, it clearly isn't one that is meant here. It's all around the person containing stuff or if you want to describe something additionally as it's shown to the user. It's also not only about the alt text here but about captions which don't mean the image is not shown but means the image is shown. And as said, the accessibility use case doesn't only relate to no image is shown but to users that need assistance recognizing things viewing the image. To be clear: I think it's an edge-case and we shouldn't bother at the moment but state that it's doable via JS but it is a use-case and should be allowed, maybe also supported later on by spec and maybe even natively.
To conclude:
alt
shouldn't be altered when the resource change, but even if there's a legitimate use-case for that, it can be resolved using a JS prolyfil.<figcaption>
changes per source, but they're most probably not the typical-case. They can be resolved using a JS prolyfill or CSS hacks, and if we'd see they're wide-spread, we can consider adding a native solution for that use-case.Closing, but feel free to open if you feel this needs to be further discussed.
Ok, for now.
I will build said polyfills and see how they go.
@iandevlin did you (or someone else) write a polyfill?
There's a new issue about this here: https://github.com/whatwg/html/issues/6627
Based on this tweet: https://twitter.com/iandevlin/status/538313179450060801
The use case: A photo of 5 people, art direction cuts off the left-most human for some variants. Then a
<figcaption>John Doe, 2nd from left</figcaption>
is not possible reliably.Possible fix: Re-use the
for
attribute: