Re: Adaptive Image Element Proposal

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).

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.

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.

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.

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.





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?
> > >
>
>
>