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

Hi,
Thanks @yoav for your answer
I comment beneath:

"* 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."
Well, that's one of the reasons why I suggest to have new types: media/img,
media/video... for the <base> or the MQ link+base attribute. That way the
author can chose what to reload for every MQ Breakpoint.

Do you have a link where those "certain cases" are specified?

I will like to add that in exchange for that problem we get less initial
load for JS and CSS resources.
Also I think there will be a huge spare of resources using the CSS-MQ
 instead of checking every resource for a device matching. Perhaps I'm
wrong... In commercial websites you can find 50-100 product images in a
single render... those are a lot of device matching queries

"* I've heard from Web developers in the past that this approach forces a
certain URL structure, which makes it limited for certain workflows."
Let's see it from another perspective: It gives an structured and standard
way of work as it happens when we work with Android XML. It's easier to
learn and to scale, and help collaborative development.
I understand there would be developers afraid of changing its original file
structure... no problem, you can use a <base> for your actual resources and
MQ base for your Responsive resources.

"* 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."
Me too, also about supporting a reload launched by a MQ breakpoint...

As I said I just want to skip this vicious circle around the <picture> and
the srcset were we just argument about which method is "less worse" than
the other instead of looking for real solutions... Is true that there is a
lot of time spent on solving this two proposals bugs, drawbacks and so...
but perhaps is time to reframe the problem and be open to new or recycled
solutions... that perhaps were no so bad...

@Yoav, the * "Let's modify the `base` tag"* approach was a beautiful idea,
please lets rethink about it... its more usable, AA friendly, pro SEO,
clean and structured than <picture> and srcset, lets the <img> untouched
for crossbrowsing, also aloud to split CSS and JS files for an optimal page
load with a minimal use of MQ...

Thanks again for your interest and hope to hear more from you and other
RICG users about this.

best regards,

2013/2/6 Yoav Weiss <yoav@yoav.ws>

> 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
>>
>
>


-- 
*Daniel Abril*
UI/UX Designer & Semantics Lover
*Tlf:* 654 99 51 68