W3C home > Mailing lists > Public > public-html@w3.org > September 2012

RE: Adaptive Image Element Proposal

From: Adrian Roselli <Roselli@algonquinstudios.com>
Date: Thu, 6 Sep 2012 20:10:42 +0000
To: Anselm Hannemann <info@anselm-hannemann.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>
Message-ID: <0CB063710346B446A5B5DC305BF8EA3E274478@Ex2010MBX.development.algonquinstudios.com>

I disagree. If we are moving toward a more fluid spec (emphasis on "if"), then in 10-15 years we will have adapted this to suit changes -- perhaps even adding @alt to <picture> if the use case supports it.

I understand the concern of painting devs into a corner, but I feel there is a greater risk today of asking them to manage duplicate content and to create tools (WYWISYG, etc) that manage that duplicate content and expose it to non-technical authors in a way that they will utilize correctly.

I think you see where my risk/reward pendulum has swung (swang?).


> 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.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 20:11:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:34 UTC