RE: Adaptive Image Element Proposal

> From: Nathanael D. Jones [mailto:nathanael.jones@gmail.com] 
> 
> Does everyone agree that, like <img> and alt="", the short description and the
> fallback content should be one and the same? (It seems obvious to me, that due
> to the often tiny size of images, only a short description will generally fit).

No, not given your examples below.


> If so, the 'default' behavior for short fallback content should be correct,
> right? 
> 
> Eventual markup:
> 
> <picture>
> My dog chasing a racoon
> </picture>
> 
> Transitional markup:
> 
> <picture>
> <img alt="My dog chasing a racoon" />
> </picture>
> 
> In both cases, the alternate text is displayed if the referenced image cannot be
> found or displayed. It is also friendly, as-is, to screen readers.

In your first example, where does the longer description go? Or is that the longer description (and if so, where does the shorter description go?)?


> I don't see a scenario in which we can transitionally implement a long
> description element (which will be more or less a counterpart to 'title', most
> likely), without some kind of javascript or CSS polyfill.

Why not @longdesc? It already works today, so there's no need for a polyfill.

See Laura's research on @longdesc support today:
http://www.d.umn.edu/~lcarlson/research/ld.html



> Without a polyfill or new browser/screen reader logic, both the long description
> AND the short description will be displayed and read. I don't think that is
> avoidable, and it's pretty pointless to discuss.

It is avoidable today, because that's how @alt and @longdesc work.


> Also, I want to mention 2 more things. 
> 
> 1) Why are we using the 'srcset' attribute name instead of 'src', like <video>? 
> 2) We absolutely need to specify handling of an optional type="" attribute. New
> image formats like WebP are already here, and I suspect we'll see a new
> streamable archive format soon that starts with a CSS file, includes all image
> variations, and supports Accept-Ranges. Without REQUIRING browsers to skip
> <source> elements with unhandled type values, we're preventing future
> improvements.

You may want to start a new thread for these. Anyone who's tired of the @alt discussion won't see these at all.


> On Thu, Sep 6, 2012 at 4:29 PM, Adrian Roselli <Roselli@algonquinstudios.com>
> wrote:
> 
> We're not at #1 yet (unless "future" means 5 minutes after you sent that note)
> and we are still sorting out the long text description. As it is, #1 doesn't
> address the short text description (think @alt vs @longdesc).
> 
> Depending on how far out that future is, there may still be devices that don't
> understand <picture> (look at how long IE6 has lasted in the wild).
> 
> For #2 you're discussing the long text description, which to me is outside of the
> scope of a discussion of a short text description (what we currently know as
> @alt).
> 
> In #2 you're not discussing the short text description and you still have @alt on
> the <img> and not on <picture>, which is the approach I am advocating and which I
> believe Mat has said he is planning to support in a revision.
> 
> I'm just trying to stay focused on the @alt. The @longdesc-level discussion is
> still percolating in my head.
> 
> 
> > From: John Albin Wilkins [mailto:john@albin.net]
> >
> > I believe the contents of the picture tag (whatever they are) should be the
> > alternative content if the picture tag isn't supported by a browser; I don't
> > think we need an alt tag anywhere in the picture element, nor do we need to
> > REQUIRE an img tag with an alt attribute. Here's my thoughts:
> >
> > 1. In the future, when all browsers support the picture element: The children
> > elements of the picture element will be the alternative content when the
> > image specified by the picture element can't be displayed. (This can be any
> > HTML.) No need for a fallback img tag or any alt attribute.
> >
> > <picture>
> >   Longer alternate content
> > </picture>
> >
> > 2. In the meantime, when not all browsers support picture element: Ditto as
> > above, but we recommend a fallback img tag IN ADDITION to other
> > alternative content. Something like this:
> >
> > <picture>
> >   <img alt="short description" class="picture-alt-img">
> >   <div class="picture-alt">Longer alternate content</div> </picture>
> >
> > To prevent the "double alt text" problem, we can leverage the "element-
> > invisible" styling (best described by this article:
> > http://snook.ca/archives/html_and_css/hiding-content-for-accessibility ).
> > The element-invisible styling gives us the ability to make things invisible to
> > sighted users, but still accessible to screen readers, etc.
> >
> > So we could use that syling on the "picture-alt" wrapper to alleviate
> > problems. It might require some JS to check if a image resource has been
> > loaded into the img tag or not; I'm not sure.
> >
> > If it wasn't 3:30am here in Taiwan I would try to work out all the edge cases.
> > But it's beyond my ability to be that coherent in a multi-step discussion.
> >
> > But wouldn't something like that be future proof as well as accessible to all
> > the right people?
> >
> >  - JohnAlbin
> >
> >
> > On Sep 7, 2012, at 2:37 AM, "Konopacki, Daniel"
> > <Daniel.Konopacki@disney.com> wrote:
> >
> > > 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>
> > > Date: Thursday, September 6, 2012 11:27 AM
> > > To: Adrian Roselli <Roselli@algonquinstudios.com>
> > > Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Laura
> > > Carlson <laura.lee.carlson@gmail.com>, Mathew Marquis
> > > <mat@matmarquis.com>, Peter Winnberg <peter.winnberg@gmail.com>,
> > Steve
> > > Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>,
> > > "public-respimg@w3.org" <public-respimg@w3.org>
> > > Subject: Re: Adaptive Image Element Proposal
> > > Resent-From: <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 21:06:14 UTC