On Mon, 04 Jun 2012 01:02:55 -0500, Anselm Hannemann Web Development
<i...@anselm-hannemann.com> wrote:
• Improved alternative text — allows structured fallback, avoids
duplication.
This is where I do not agree. If you use MQ style with <source> you
have a messy markup when writing alternative text inside the
pic-element.
Since <source> is not read nor displayed, it doesn't matter. You can
simply treat entire content as fallback.
Sure but why? It is much more clearly to use the alt-attribute than
using text between container and child elements IMO.
<object>, <iframe> and <canvas> use content as a fallback. XHTML2 was
supposed to use this fallback model for all elements (global src). It
seems that <img alt> was just a mistake made in early development of HTML.
Since it's impossible to introduce void element at this point (XML and DTD
boats have sailed …or sunk) we'll have to have </pic> anyway. At least we
can make the best of it and use it for rich fallback that wasn't possible
with <img> before, and which is harder to ignore than an attribute,
because the parser will require </pic>.
I'm trying to avoid need for yet another opt-out from the past like
doctype and <meta charset>.
It'd be great if in 10-20 years all you had to do is type <pic src>
instead of <img src> to get first-class support for hires images.
To address Tab's concern the default is connected to image-resolution
in CSS, so you can change it if you need to:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html
Yes but won't we at least dimiss img from our new code? I thought img is
only the fallback…
And then we should always serve the minimum resolution first.
Regardless which resolution this minimal file has, it should be the @1x
IMO.
Or am I missing something?
Yes, <img> is the fallback until all UAs start supporting the new element.
I'm not sure what do you mean by "we should always serve the minimum
resolution first". If alternatives are offered to the UA, IMHO it should
be up to UA whether it downloads low-res first or only high-res image.
I'm afraid that when high-dpi displays become the norm the minimal useful
HTML template will grow to be something like:
<!DOCTYPE html>
<meta charset=UTF-8>
<style>html {image-resolution:2dppx}</style>
and I'm trying to find a way to avoid having all authors add yet another
boilerplate opt-in.
I don't know what to do with default-lowres background-image, so maybe
this is an unavoidable problem :(
--
regards, Kornel Lesiński