igrigorik
commented
10 years ago No open bug that I'm aware of. The issue was discussed on www-style in a couple of threads a few months back. Going back to that thread, seems like some extra attributes were proposed to overcome the past's baggage and authors assumptions. Still needs to be specified AFAIK.
Well, that was a fun read. As a tl;dr, this seems to capture it: http://lists.w3.org/Archives/Public/www-style/2013Feb/0142.html
- "Essential stylesheet" case is already covered.
- "Low-priority", I believe, is covered by ResourcePriorities spec.
- "Optional stylesheets" - as Boris pointed out, rel=alternate could do the trick? You would have to add some logic to trigger the downloads, but that seems solvable?
There may be cases where the destined resource doesn't need to change, even if the resource or viewport dimensions have changed , so "Vary" may not be optimal here (the browser's cache will be invalidated, but the resource may not need a re-download but a 304, e.g. in the case of a small viewport width change).
That wouldn't work. Vary simply appends the string to its cache key. Returning 304 doesn't magically select some other resource -- what would be the logic if you have 3 variants, which would you choose? What you're describing is Key.. :)
That works great for images (at least for now), but won't necessarily work for other types of resources. I think we may be better off postponing non-image resource handling for now, and gather use-cases for them before complicating things for their sake.
First: https://github.com/igrigorik/http-client-hints/commit/1f9dcbf5017edfc6f68586925546431be8b12014 (DW > RW). Second, let's continue this discussion in a separate bug: https://github.com/igrigorik/http-client-hints/issues/18
yoavweiss
Hey Ilya,
So, I'm very excited about Client Hints, and am glad to see you're pushing it towards implementation. I'm also wary of it for a couple of reasons.
My main concerns are that, at least in my experience and in what I've observed in "responsive" asset delivery lately, device dimensions are rarely the most important factor when determining the CSS and JS that is applicable at load time. I'm glad that this information is included in Client Hints, but it seems less important than a few other factors. These are:
I understand that client-side deliverables can affect the reported viewport size, and that may be the reason you cited their removal from client hints. That said, the information that an author needs to know up-front may not need dynamically-calculated viewport dimensions to be useful anyway.
If client hints sent the pixel-based dimensions of the viewport at the same scale as the device dimensions (so, iPhone would be something like 320px by 420px height, or the opposite if it was in landscape orientation), that would be very helpful on its own. In addition, if client hints sent the default font-size of the browser (16px or otherwise), then that value could be used to calculate an em-based viewport dimension, which is what authors would need when deciding which stylesheets to serve up-front in a blocking manner, and which stylesheets are inapplicable at load and could safely be loaded at a later time, perhaps at the bottom of the document or something.
Also, it'd be ideal if Client Hint data were fresh per request, as device conditions can change regularly with orientation changes, preferences, font-size shifts, zoom, etc.
It'd be great to hear about your thoughts about the issues above. Thanks!
Scott Jehl