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

On Wed, Feb 6, 2013 at 2:56 PM, Nathanael D. Jones <
nathanael.jones@gmail.com> wrote:

> Thanks Yoav, I guess I can stop rushing this proof-of-concept webkit
> branch now :) I'm quite slow at C++.
>
> I have verified that Chrome performs a layout pass immediately after CSS
> parsing finishes, *prior to loading or executing any scripts*. This
> appears to be where background-image usage analysis and prefetch begins,
> and seems to be an ideal implementation point for a non-optimized pre-fetch
> algorithm.
>
>
That highly depends on the location of the scripts in the page. Scripts
without `async`/`defer` *must* be executed before parsing and layout can
continue (since they may inject document.write to the document, and may
rely on a fixed state of the page's DOM tree)
CSS background images are being fetched according to MQs, similar to the
current `<picture>` proposal. They do not need Layout and their fetching
can start once they are parsed from CSS (i.e. once the entire CSS was
downloaded)
In any case, as I said, your proposal can also use inline CSS, which means
(at least in theory) that it doesn't need to delay image fetching at all.


> *Width/height in markup*
>
> The W3C and others have been training authors to specify image
> width/height values for over a decade:
>
> http://www.w3.org/wiki/Images_in_HTML#Faster_image_display_by_defining_the_dimensions_using_width_and_height
>
> I don't think this is much of a regression in terms of maintenance or
> dependencies; it's been well communicated to authors over the years, and is
> trivial to implement at the CMS/WYSIYG editor level.
>
> It should also speed up display time, as layout can occur before images
> are loaded, which is important on slow connections.
>
> There's a big difference between adding display width/height and adding
the resource's width/height to the HTML. If at some point you modify the
image resource with a different one (while keeping the same proportions),
you would have to modify your markup, where otherwise you wouldn't.
Also, pixel based markup display height/width are actually an anti-pattern
nowadays, since these image can't be fluid across different viewport sizes.


> > Also, I'm not sure how your proposal can enable the browser to
> distinguish between art-direction and resolution switching (which is an
> important part of the `srcset`/`<picture>` proposal combination) nor how
> should the UA calculate DPI based resolution switching in your proposal.
>
> *Resolution switching summary:*
>
> 1. UA has density multiplier (1.5, 1.6, 2, etc). If running in
> low-bandwidth mode, it may use "1" instead.
> 2. UA divides all width/height values  on each `source` element by the
> adjusted density multipler from #1.
> 3. UA selects first matching, supported image based on size constraints.
>
> So, in your example, if the UA has a viewport width of 400px(25em) and x2
screen density, the `<picture>` max-width is defined as 320px, "corrected"
max-width is 640px and the chosen image is the "large" image with a 1200px
width?

I guess it could work, with the price of adding external resource
dependency. I still don't think it is better than current `srcset`, though.
Can you please explain what are the problems that you see in `srcset` for
resolution switching?


> *Resolution switching vs art-direction:*
>
> As I understand, the use case for providing two images of the same size
> with different content is so users with higher-density, physically smaller
> displays don't need to zoom to see the 'primary content' in the image.
>
> I don't think this level of control will be exercised frequently, but it
> could be handled via Solution B (allow 'media="" attribute, but discourage
> use).
>
> <source src="/full-image.jpg" width="640" height="480"
> media="(min-width:640px)" />
> <source src="/zoom-image-hires.jpg" width="640" height="480" />
>
> I know some people that will strongly disagree with you on this :)
For small screen layouts, you'd often want the main "subject" of the image
to stand out and fit the rest of the layout. In some cases, the image
proportions may be different. In any case this is a *major* use case of the
`<picture>` specification. Certainly not something we want to discourage
its use.


> *MQ DRY:*
>
> I would also like to see a global MQB (media query breakpoint) solution.
> However, it would seem strange if said solution wasn't in CSS. And if it
> was in CSS, it would mean deferred MQ evaluation for markup references -
> including CSS includes! I really don't think it's likely that we could get
> such a solution passed. A meta-tag based approach could meet the
> performance requirements, but wouldn't meet markup/presentation separation
> requirements.
>

I agree that such a solution will most probably be in CSS, but it can be in
inline CSS, with no network performance trade-off.

Yoav