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

Hi Daniel,

As a former proponent of the "Let's modify the `base` tag" approach, here
are a few downsides with it:
* An MQ breakpoint change will reload all the page's resources, even if it
is not necessary (e.g. orientation change from lanscape to portrait). The
browser will not be able to optimize such reloading and avoid it in certain
cases.
* I've heard from Web developers in the past that this approach forces a
certain URL structure, which makes it limited for certain workflows.
* I'm not sure modifying the `base` tag to make it apply only to certain
tags as you propose is feasible. I'd love to hear the opinion of browser
vendors on this.

Yoav


On Wed, Feb 6, 2013 at 9:39 PM, Daniel Abril <daniel.abril@gmail.com> wrote:

> Hi,
> 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 approach<http://blog.yoav.ws/2011/07/Simpler-responsive-images-proposal> (@Yoav)
> 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)" base="/media/hh480/"
> />*
>
> 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:
>
> *<HEAD>*
>
> *<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" />*
>
> *</HEAD>*
> *<BODY>*
>
> *<img src="img.jpg" alt="My Image" />*
>
> *</BODY>*
>
> 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" href="**/resources**/handheld_jQ.js"
> />*
> *
> *
> 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:54:28 UTC