Re: Adaptive Image Element Proposal

Am Donnerstag, 6. September 2012 um 22:47 schrieb Nathanael D. Jones:
> 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.
 Fully agree to that variant.
> 
> 1) Why are we using the 'srcset' attribute name instead of 'src', like <video>? 
> 

Because src is an attribute for a single reference/source but srcset specifies more sources and gives additional parameters to it. This might cause many problems with existing browser implementations and it is not the correct semantic mark-up IMO. 
> 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.

 I am not 100% sure on that topic but I know that HTML5 dropped these type attributes for some reason. So I wouldn't differ here. I also believe that it is a servers problem to serve the right MIMEType. If I miss something here, just explain and ignore my post ;)

-Anselm
> 
> On Thu, Sep 6, 2012 at 4:29 PM, Adrian Roselli <Roselli@algonquinstudios.com (mailto: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 (mailto: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 (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?
> > > >
> > 
> > 
>