Re: Adaptive Image Element Proposal

I agree with Anselm's assessment here. If there were either @alt or @alt equivalent for <picture>, I feel that devs could be given an option. For brevity's sake, a simple example:

Example 1:
<picture>
  <img src="file.jpg" alt="Some description" />
</picture>

Example 2:
<picture alt="Some description">
  <img src="file.jpg" alt="Some description" />
</picture>

In the first example we leave off the @alt attribute from the <picture> tag. Browsers requiring a short text description would then fallback to the <img> @alt value. In the second example, however, there are two @alt attributes. For browsers supporting <picture>, they utilize the <picture> tag's @alt value, while the others will fallback to the <img> @alt value. This both allows devs to write the markup in a more simplistic way (Example 1) and provides a path to future deployments (Example 2 allows the complete omission of <img>).

From: Anselm Hannemann <info@anselm-hannemann.com<mailto:info@anselm-hannemann.com>>
Date: Thursday, September 6, 2012 11:27 AM
To: Adrian Roselli <Roselli@algonquinstudios.com<mailto:Roselli@algonquinstudios.com>>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no<mailto:xn--mlform-iua@xn--mlform-iua.no>>, Laura Carlson <laura.lee.carlson@gmail.com<mailto:laura.lee.carlson@gmail.com>>, Mathew Marquis <mat@matmarquis.com<mailto:mat@matmarquis.com>>, Peter Winnberg <peter.winnberg@gmail.com<mailto:peter.winnberg@gmail.com>>, Steve Faulkner <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>>, HTML WG <public-html@w3.org<mailto:public-html@w3.org>>, "public-respimg@w3.org<mailto:public-respimg@w3.org>" <public-respimg@w3.org<mailto:public-respimg@w3.org>>
Subject: Re: Adaptive Image Element Proposal
Resent-From: <public-respimg@w3.org<mailto:public-respimg@w3.org>>
Resent-Date: Thursday, September 6, 2012 11:27 AM

Yes, you miss a point:
In 10-15 years we are not needing the img-element anymore. But then it would be required by spec.
This is what I fear of.

-Anselm


Am Donnerstag, 6. September 2012 um 20:22 schrieb Adrian Roselli:

From: Anselm Hannemann [mailto:info@anselm-hannemann.com]

Hi Lief,
Needless complexity: The complexity is related to lack of support for
<picture>

That's right. That is why Mat will be changing the draft spec to use
<img> with alt for the short text alternative not <picture> and a new
text alternative method.
http://lists.w3.org/Archives/Public/public-html/2012Sep/0016.html
What? Why do we rely on the img-fallback(!) now?
I always thought the img-element is not required but optional (for fallback
methods). If we now rely on img for alt-attribute this would require to alway
have an img-tag inside of the picture-tag. This is what I call complexity.
It might be handier to not have to specify 2 alt-attribute-values but longterm
it is bad spec. The only two valid strategies would be the long version inside
the picture-element or the alt-attribute for the picture-element.

Sorry, I speak for my own but this is a longterm consideration.

<picture> needs a fallback of some sort otherwise users in current and older browsers won't see any image at all.

<img> allows authors to specify a fallback image for those users who can see the image but don't have a <picture>-capable browser.

For users who simply cannot see images (whether vision impairment or unfortunate connection), there still needs to be a text fallback somewhere in there. If <img> will be part of <picture> and <img> already has rules for @alt, then requiring @alt on <picture> just creates more complexity (room for error, mismatches, etc). Therefore, just lean on @alt from the <img> that will already be there.

With this method the only complexity above what web developers do today is adding the <picture> and its children. And that additional complexity will only be there if a developer wants to use this new feature.

This only addresses the short text alternative, but I think that's the one you are questioning.

Is there a piece I am missing in my (attempted) logic?

Received on Thursday, 6 September 2012 18:38:26 UTC