W3C home > Mailing lists > Public > public-respimg@w3.org > February 2013

Re: CfC: to publish "The srcset attribute" specification as a First Public Working Draft (FPWD)

From: Daniel Abril <daniel.abril@gmail.com>
Date: Wed, 6 Feb 2013 21:39:45 +0100
Message-ID: <CAO4OTTdB3Qe1t0yskqUVZmoAT=MLVVP-9h-2_HAb7Fi23ozDUw@mail.gmail.com>
To: "public-respimg@w3.org" <public-respimg@w3.org>
Cc: Yoav Weiss <yoav@yoav.ws>, Mat Marquis <mat@matmarquis.com>, "Nathanael D. Jones\"" <nathanael.jones@gmail.com>
I will like to participate on the solution and propose a new approach to
the problem.

I can see, as @Mat said that the problem is going in circles, that's why I
pretend give a tangent line to the problem with mi proposal. As many of
you, have already said, both proposals (picture element & srcset) present
several CONS:

   - Increment of the code that affect e.g. SEO and Performance
   - Hard to mantain
   - Need of polyfills
   - The UA can't detect the size of the images to make a choice
   - etc...

First of all...
@Fred suggest to scale the image as the layout (container) changes... but
we have to take in account that a layout will be seen static, not while is
been resized, and that an image has no need to change so often as the
layout does to show crispy cause the user will pay attention to it only
once the resize is finished.
Letting the UA change the images so often will make extra http calls and
will also make the client work for nothing, every time we resize the window.

As @Mat said, how often the image changes must be the author's decision.
Media query's do the job in that sense.

Just a while ago I comment the proposal idea to the guys in the RICG chat
and I will like to exposed a littler bit more widely for discussion. They
told me it was already existing a similar
and some experiments <https://github.com/scottjehl/Responsive-Images>done,
and I think is the right direction to solve this issue.

My first idea was to recycle the base element and add a couple of
attributes (type and media):

*<base type="media/img" media="handheld and (max-device-width:480px)"
href="/media/hh480/" />*

Then I though that with the <link media> will be easier as we just need to
add the base attribute and a new value for the type attribute, the
media/img(video, or whatever).

*<link type="media/img" media="handheld and (max-device-width:480px)"

Both ways will leave the img element clean and understandable for any
browser without polyfills or hacky stuff:

*<img src="img.jpg" alt="My Image" />*

Then I realise that looking for a way to clear code I was also adding some
extra lines for every type of element I want to load: img, js, css... Why
not recycling a single statement of the media query to load all of them if
need it?

I hardly think that being able to split calls into conditional
directories/groups based on media query will make every coders live easier
and give the Responsive Design a very powerful tool.

In that point I went back to the original base idea and add a new value to
the already added type attribute, the *All* value:

*<base type="all" media="handheld and (max-device-width:480px)"
href="/hh480/" />*

Then every link <a>, <link> or img will use the base url to locate its href
so we could have just one call of each type optimized for every media.

Here an example:


*<base type="all" media="all" href="/resources/" />*
*<base type="all" media="handheld and (max-device-width:480px)" href="
/resources/hh480/" />*
*<link type="text/css" href="hec.css" />*
*<link type="text/javascript" href="jQ.js" />*


*<img src="img.jpg" alt="My Image" />*


In the example there is given a base for the common resources and then a
base for an specific media. Also there is still being possible to overwrite
a single call to one type of resource adding a classic media query after
them as always:

*<link type="text/javascript" media="handheld"
In this case, the <link media> won't be affected by the <base media>
element as it has it's own media definition.

I will like to hear your opinions and see if we can find an optimal way of
solving RI, better than the actual proposals.

Best regards,
*Daniel Abril*
UI/UX Designer & Semantics Lover
Received on Wednesday, 6 February 2013 21:23:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:08 UTC