RE: Adaptive Image Element Proposal

Agree 100% that @alt on <picture> shouldn't be required. I also agree that it'll be misused, but when isn't this the case? :)

-----Original Message-----
From: Adrian Roselli [mailto:Roselli@algonquinstudios.com] 
Sent: Thursday, September 06, 2012 1:56 PM
To: Konopacki, Daniel; Anselm Hannemann
Cc: Leif Halvard Silli; Laura Carlson; Mathew Marquis; Peter Winnberg; Steve Faulkner; HTML WG; public-respimg@w3.org
Subject: RE: Adaptive Image Element Proposal


To me, the @alt-like solution for <picture> is <img> @alt. I understand that in the future that can be annoying, but I foresee the spec adapting before that comes to a head (or rather, browser support/interpretation of the spec).

I am not opposed to @alt on <picture>, but I don't think it needs to be a requirement. I do think it will be mis-used.

I also understand that far to few people use @alt properly today.


> -----Original Message-----
> From: Konopacki, Daniel [mailto:Daniel.Konopacki@disney.com]
> 
> Just for clarity's sake, mine isn't an explicit advocacy for @alt on 
> <picture>, simply an @alt-like solution for <picture> outside of <img>.
> 
> Back to your point, however. I fully agree that there will be 
> developers who would not use this approach; the same can be said about 
> @alt in general, however. There are extensive examples today where 
> current <img> elements contain no @alt. Just because some choose not 
> to use it shouldn't be a basis for dismissal.
> 
> Further, I would argue that having the option gives a developer 
> greater flexibility. If I have a site I'm deploying that I feel 
> confident the majority of my target market audience - to what my 
> business feels is an acceptable level of tolerance - has the <picture> 
> element, why should I be forced to include <img> simply to provide a 
> textual short description? This makes less sense to me than having an option for employing a short descriptor.
> 
> 
> -----Original Message-----
> From: Adrian Roselli [mailto:Roselli@algonquinstudios.com]
> Sent: Thursday, September 06, 2012 1:15 PM
> To: Konopacki, Daniel; Anselm Hannemann
> Cc: Leif Halvard Silli; Laura Carlson; Mathew Marquis; Peter Winnberg; 
> Steve Faulkner; HTML WG; public-respimg@w3.org
> Subject: 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
> > > > > > .h
> > > > > > tml
> > > > > >
> > > > > 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 21:19:36 UTC