- From: Adrian Roselli <Roselli@algonquinstudios.com>
- Date: Thu, 6 Sep 2012 21:05:45 +0000
- To: "Nathanael D. Jones" <nathanael.jones@gmail.com>
- CC: John Albin Wilkins <john@albin.net>, "Konopacki, Daniel" <Daniel.Konopacki@disney.com>, Anselm Hannemann <info@anselm-hannemann.com>, 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>
> 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:15 UTC