RE: Adaptive Image Element Proposal

See my response to Anselm's response (to my response to his response...).

I am not opposed to @alt existing on <picture> *as well as* <img>, but I don't think it makes sense and I don't think developers will use it.

I have no data to back that up, just experience and gut feeling.


> From: Konopacki, Daniel [mailto:Daniel.Konopacki@disney.com] 
> 
> 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 [mailto:info@anselm-hannemann.com] 
> > 
> > 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:
> > > > > 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 20:15:45 UTC