For discussion: viewport and font-size data in client hints

[scottjehl]

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:

• Screen pixel density (which I'm very glad to see is included already in CH)
• Viewport dimensions (often different from device dimensions, particularly on larger screen devices)
• Default Font size (based on user preference), as this drives the active em-based media query breakpoint and layout a user receives.

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

[jessebeach]

Presumably these hints would vary against the same URL, meaning the request payload could vary for the same URL. This has big implications for cache. These hints would need to be exposed in the headers so cache proxies could be configured to respond.

In order to keep the cache useful, one would probably want to respond to ranges of hint values e.g. 0-20em viewports and > 20em viewports, creating two cache groups against the same URL.

[scottjehl]

Thanks, @jessebeach. Good points. From what I can tell reading the proposal it seems like they would be exposed in a similar way to how you describe, but I'm not positive. Would that be a separate issue? My concerns above are largely about portions of data not currently specified in the draft that I think would be most useful.

[beep]

• Screen pixel density (which I'm very glad to see is included already in CH)
• Viewport dimensions (often different from device dimensions, particularly on larger screen devices)
• Default Font size (based on user preference), as this drives the active em-based media query breakpoint and layout a user receives.

Big +1 from me on all of these.

[Wilto]

Also +1’d—viewport and the current zoom level (based on the user’s font size) are two hugely important factors in the kinds of decisions I’d be making based on client hints. I know a @viewport rule in an external stylesheet can’t really be factored into this as it won’t be available in time, but a pixel-based device-width would likely suffice for most use cases.

[bjankord]

+1 for viewport. Being able to know that on the server before hand would be so useful!

[jessebeach]

@scottjehl, this was a case of RTFM on my part:

Once the resource is optimized based on client CH hint, it can be cached through Vary: CH, or in combination with Key for fine-grained cache control.

I'm going to chat with some of our performance folks at Acquia to see what they think about having a Vary: CH.

I could see us exposing these options as conditions for rules in Drupal that would allow us to refine content delivery and theming assets.

[igrigorik]

Thanks to everyone for great feedback! I'll try to tackle it one go...

---

First off, I think it's worth highlighting that CH is not a singular or monolithic thing. As in, my primary goal for this spec is to enable and provide an extensible mechanism over which a variety of different CH values can be transferred. The provided examples in the spec (dw, dh, dpr) are initial examples, but the spec itself does not limit any other variables from being added in the future -- in fact, that's the whole point of adding the registry mechanism at the end. As a good example of this, @mnot recently shared a quick proposal he drafted where he's leveraging CH for communicating parental control information.

So with that in mind, the conversation about different values to transport here is not exclusive.. Rather, it's a question of (a) what's useful, (b) what's obtainable, (c) what's implementable, (d) can we convince the browser vendors to do it assuming we show (a)-(c). :-)

With that out of the way, I actually see three time horizons for this specification:

• Short-term: enable the CH transport as "a thing", and prove its usefulness and feasibility
• Mid-term: leverage short-term results to drive better Vary adoption + Key implementation
• Long-term: with Vary+Key in place, a new world of opportunities is there for surfacing a lot more client data

The above deserves some context... Exposing the right variables is only half the problem. The other half is then getting the browser + intermediate caches to play nicely with it. Unfortunately, many popular CDN's today simply do not respect anything but Vary: Accept-Encoding, but from talking to a bunch of them, this is something they would be willing to invest in, assuming we show that supporting Vary: CH won't render the resources uncacheable due to fragmentation of the header... This is a legitimate and a real world constraint for short to mid-term.

Put differently: to bootstrap the process, we need a CH header that minimizes the variability within the header, while providing real, tangible value to CDN's and content providers. What's a good battle to pick here? Simple: images (60% of the bytes on the wire). Hence the reason why the current spec specifically focuses on dpr + device width and height. Further, to minimize variability in the cache key, the dw and dh values are static (do not change based on orientation)... These are practical tradeoffs to meet (a), (b) and (c) against the short-term goals I've outlined above.

Much of the concerns above wouldn't exist if we had @mnot's Key:
https://github.com/mnot/I-D/blob/master/http-key/draft.md
https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-00.txt#L272

But before we get Key, we must live with Vary.. and before that, we need to get Vary to actually work. (sigh :))

---

Ok, hopefully I haven't lost you yet..

Viewport size: if you rewind the spec you will indeed see that I spec'ed vw and vh. Then after we attempted to implement this in Chrome, it turned out that it was a no-go: it required a bunch of thread hopping + complex machinery, and worse, the actual viewport data is effectively unavailable at the time of many requests when the page is just being constructed. The best example of this is the preloader -- this is a conversation we've had many times over now, but the decision within WebKit today is that the preloader won't have access to the viewport (at least for the foreseeable future). Hence, this fails the earlier "implementable" constraint (for the moment), and we reverted back to the device width and height.

I think it's also important to note that if you stick to best practices, then you already (should) have a meta-viewport tag with viewport=device-width. In which case, the viewport == device width. Yes, it is true that you can change this, but if you look at this from strictly image optimization perspective.. then device width addresses the 80%+ use case. Also, dw/dh is a directly equivalent to what you would get out of all of the device detection DB's that are currently out there (and many developers are paying for), so that also works in its favor: there are many existing apps that depend on this data and can leverage it immediately.

Long story short: I'm not making an argument against reporting viewport sizes. In fact, I wish we could get at this data and make use of it today. But in the short term, it doesn't meet the criteria. In the long term, I hope we'll see it as part of CH!

Default font size, zoom level, orientation, etc: these won't work for the short-term horizon because in the absence of Key, they would fragment the caches too much -- Vary is a very "dumb" mechanism, which does not understand the actual meaning of the header and any variation in this value would mean another copy of the item in the cache. With Key support in place, this is an entirely different conversation... Also, as a slight tangent, I'm slightly surprised nobody has brought up touch hints! From my conversations with many Google teams, that's another big one.. but it creates similar problems.

Again, in short: for the short-term, the CH header must be kept as small and as static as possible to prove its viability. Hence, unfortunately, dynamic variables and per-user settings are out of scope.

DPR: yay. :-)

Per-request: Yep, CH header is per request.

Hope this paints a larger picture and how I've been approaching it... FWIW, there are a lot of different stakeholders here (browser vendors, caches/proxies/CDNs, web developers), and having spent a whole lot of time talking to each, I think the above is a reasonable middle road to keep everyone happy, with (hopefully) a good long-term outcome where everyone wins.

P.S. Who's volunteering to start drafting the extension proposals for above values in CH? :-)

[beep]

Thanks for the clarifying comment, Ilya. The background’s quite helpful.

Further, to minimize variability in the cache key, the dw and dh values are static (do not change based on orientation)... These are practical tradeoffs to meet (a), (b) and (c) against the short-term goals I've outlined above.

Hrm. Well, I’ll continue to watch this spec with interest, of course; but given the above, the short-term iteration of client hints won’t have much benefit to my work. Device dimensions are rarely of any value to me in the various cross-device/responsive projects I’ve worked on; much less so if they’re static, and not sensitive to resize.

[Wilto]

@igrigorik, how would this work in an environment where multiple monitors of varying resolution are connected? I assume the goal of “small and static” is to avoid the complication of questions like: would a browser on a 1x display attached to a “Retina” device still receive a 2x “hint?” (If only the 1x monitor is in use? If both displays are in use?) It seems that any resolution-based decisions would be much better handled on the client side, where we’ll have access to a great deal more information about the browsing environment than the greatest potential resolution the device supports.

Like Ethan, I haven’t really found any situations where I need a device’s dimensions rather than the viewport dimensions. If there’s anyone that understands how tricky these things can be to spec, it’s me—but, speaking strictly as a developer, this doesn’t seem like it would be terribly useful in my day-to-day work.

[scottjehl]

Thanks Ilya,

Sounds like you're juggling some complicated constraints with this.

It's a shame and also a little surprising to me that the window dimensions and font-size aren't available at request time, as to a layperson of browser implementation details, it seems like the window's size and preferred font-size would be one of few constants present at all times on a device. Given the potential value of that data to this feature, it does make me wonder if finding a way to expose those values would be worth extra early efforts to expose them (for the initial implementation). Admittedly, you're much closer to this than I am, and I understand that it's complicated.

It's particularly unfortunate that the orientation values are fixed. In that way, it sounds like CH actually does not send updated data per request, but more of a stored value that never changes - is that the case? I can't think of many responsive designs that use device dimensions as a factor in CSS layout selection, but of those that do, I'd imagine at least they'd need the device's orientation to make a semi-informed guess at the viewport size.

Given your timeline, I think the long-term is the time when this feature could become useful to those looking to optimize responsive designs with UA-agnostic server logic. I think this first pass could provide a more generic means of defining a sort of "is_handheld" property, but I'm not sure that sort of parameter is granular enough to be very meaningful in delivering an appropriate layout (as it doesn't factor in the sort of dynamic conditions that define the true size and scale of the viewport). At least for those using device-category-detection though, that value will no longer need to be inferred based on a UA, which is an improvement.

That said, I would expect device dimensions to be probably the most reliable values you could pull from a device database anyway, as they are physical and generally not subject to change (though detection problems and all that still apply). The values that are difficult to derive on the server today are the conditions that a static device database can't really know, like the user's preferred viewport size, zoom, feature enablement vs. support, etc. These conditions are unique for every user, and have become the most important factors in delivering a customized layout.

I'll look forward to seeing future extensions to CH that include the sort of dynamic values that determine layouts in responsive designs today, and when you get to the stage where they're available to implement, I'd love to be involved.

Thanks again.

[igrigorik]

@Wilto multi-screen case is indeed a tricky one - open to suggestions, although this is more of an implementation detail, not a spec concern (at HTTP level). A couple of strategies are: (a) default to primary display, or (b) default to largest size + highest DPI (to be safe).

Re: viewport. I hear you, but unless I'm missing something big here.. If you're sticking to best practices, then your viewport == device-width and the server has enough information (dpr and device width/height) to adapt accordingly.

@scottjehl I may have confused your earlier question. Window dimensions and default font-size should be available, since those are not tied to site-specific viewport. Having said that, do you (a) have any data on how frequently users change their default font size, and (b) window-size creates the same cache fragmentation problem, which is why we ruled it out for now. On mobile, window-size is fairly static, since you can't resize it.. But on desktops, this would lead to a huge amount of variability in the header and hence fragmentation for Vary (e.g., even the fact that you have some third party toolbar enabled or disabled would affect this).

Per request: I'm confused by your wording here. The header is sent on every request. How and when the specific variables are updated are a separate discussion. For orientation state, we can/should have a separate hint.

Re: RWD. See my comment above to @Wilto. You have the device width/height and DPR, hence you know the optimal viewport. This information can definitely be used to serve appropriate assets.

Re: Zoom. This seems like a misnomer. When the user loads the page the zoom is not set by the user -- unless I'm missing something here?

[scottjehl]

Hey Ilya,

Much of the reasoning behind my requests above is that it's now a common (and I'd propose, very "good") practice to build responsive designs using mostly relative units, particularly em-based media query breakpoints for min-and-max-width. For example:

@media (min-width: 25em){ ... }

This practice inherently ties our layout breakpoints to the size of the type, padding, margins, etc. which is great because our layouts now match the size and scale that the content itself demands, which frequently does not line up with what any particular device's physical dimensions happen to be. If you go to a responsive website that uses px media queries and bump your font size up a size or two, you'll see right away why pixel-based breakpoints that are tied to device dimensions don't work very well - they don't respond in unison to the size of the rest of the elements in a page, and elements crash into one another, or become harder to use. However, if you do the same thing on a site using em media queries, you'll see the layout switch in proportion to the layout scale (note that there's currently a bug in Chrome that prevents em-based media queries from being re-evaluated immediately after a font-size change, so you have to refresh to see the effect, but that's better than nothing and hopefully will be fixed soon - other browsers update more dynamically).

This effectively means that a person using Chrome on the desktop, with a window sized 1000x600px, can bump their font size up a notch or two and they'll receive a CSS layout similar to what a much smaller device might receive by default. It's pretty fantastic, really.

You can read up more on this practice and its benefits here: http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ .

Anyway, em media queries are great because they allow us to tie our breakpoints to the content itself, putting the control in the hands of our users for receiving a layout that meets their needs. I'd argue that it doesn't really matter how many users change their font-size, as long as we know that plenty can and do (font size adjustments are always a keystroke away (cmd-/+), and is exposed at the top-level of most browsers' preference panes as well).

So, this is why device dimensions have become less relevant in responsive designs, and why a combination of viewport (or window) size and font-size are required for making an informed decision.

This is why I and others are very excited about Client Hints' potential. One of the major downsides of User-Agent-based device databases is that they are static - they just can't know this sort of information about the browser, as it can't be generalized for all users of any particular browser (every user is unique). So window size and font size are much more dynamic than any static database can predict, yet those two factors have quickly become some of the most important factors in serving an appropriate layout to our users.

I understand that caching concerns make the inclusion of these properties less interesting from a CDN owner's perspective, but it would be a shame if these benefits to users and developers were overlooked. Including these two pieces of information would mean we could place a lot of the burden on the server for determining the assets that need to be loaded up-front, rather than letting unnecessary requests happen because we don't have enough information to do better.

[Wilto]

@igrigorik
Given the technical constraints involved I can certainly understand where varying viewport sizes aren’t covered by this first iteration on client hints. From a “best practices” standpoint, however, http://dev.w3.org/csswg/css-device-adapt/#the-atviewport-rule makes no mention of device-width being the recommended usage. device-width may be the most common usage today, but there’s a clear need to allow authors to specify disparate viewport sizes—else, I don’t assume it would have made it into the @viewport spec. It’s perfectly fair to say “this case isn’t yet addressed by client hints,” but “we don’t need to worry about it if you just don’t do that” likely won’t carry a great deal of weight with authors, given that new mechanisms are going into place to give them greater control over viewport sizing.

Acquiring the client’s calculated viewport size in a way that plays well with the preload scanner/speculative parser is something that will likely need to be solved for client hints, finer-grained control over the loading of stylesheets, and both “responsive images” extension specifications. I hope I speak for everyone when I say that no one is snapping their fingers and demanding an immediate solution, but I do hope we’re not discounting the possibility of an eventual solution—and justifying it with “maybe no one will want to do that.”

I look forward to seeing how this spec might continue to evolve.

[nhoizey]

Hi everyone, all this is really interesting, with great hopes for the future of RWD.

I have a few ideas/questions through:

Viewport size: apart from @Wilto in his last comment, you all seem to say "width=device-width" is the current best practice. To my knowledge, it was a best practice before, but now it's more "initial-scale=1.0". This french article explains the reasons, with a short abstract in english in the begining. Anyway, I agree it would be useful to get the computed viewport size in client hints, but I understand the issue with Vary:.

Base font size: I don't like to name it "default" font size, because there is a difference. Default font size is the one set by the browser before any customization. Base font size for me is the one the user can set in the preferences, or get with text only zoom. Default font size is often 16px in desktop browsers, but other devices have other default font size, such as the Kindle Touch with 26px (as said in Tim Kadlec's Implementing Responsive Design book). Anyway, I don't think this information would be really useful in client hints, because it may be modified by the user after the browser got the page.

Device orientation: Same as for the base font size, I don't see why it would be useful in client hints, because it can also change after the request. Even between the request initialization and the document complete, so the page could have been requested in portrait mode and some resources in landscape mode. I wouldn't base anything server side on such information.

RWD: as @scottjehl , "enlightened" by Cloud Four's blog post one year ago (already!), I think ems are the best way to build media queries and dimensions of most components (tried it on my own blog and client works are in progress like this). But ems are tied to the base font size, so I think client hint can not be of any help here, one again.

I may have missed or misunderstood something, but I thought I had to share these ideas.

[scottjehl]

Thanks @nhoizey. Some clarifications:

Viewport size: indeed, we can adjust the viewport size with client side tech, but the part that is beyond our control is the size of the window, and its base scale (via font-size). Getting the raw window dimensions in pixels at a 1.0 scale (the same scale at which device dimensions would be reported) would be a good start, as we could use this and the base font size to derive the base viewport dimensions that the user has set.

Base font size: I agree that "default" is a bad name for what we're talking about here. Base, or really "root" font size is maybe more appropriate, as that would take browser default and user preference into account. Many browsers default to around 16px, for instance, but it's up to each user to adjust that via browser settings, or per page view.

Device orientation: I agree. I find device orientation is rarely very useful compared to knowing the dimensions of the viewport (both width and height). I wouldn't vote for its inclusion in CH to be a high priority.

I do think "base" font size and viewport dimensions would make CH very useful, though.

[igrigorik]

Thanks guys, great feedback.

Once again, CH is a transport, so everything discussed here are legitimate extensions that can be easily registered as additional hints (ex: in spec I register an additional hint against @mnot's OH header, via similar mechanism: https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-00.txt#L342).

@scottjehl @Wilto Thanks for the link and the context - good read. A few notes while reading through the article and comments in this thread:

• zoom on desktop is different from zoom on mobile (text size + layout change vs. visual viewport zoom), the article conflates the two
• (my assumption is that) "bumping font-size" on mobile is a low frequency event because there is no "cmd+" on mobile. Instead, you have to dig into browser settings and change it there - this is not a per-page event. Rather, the user will zoom the visual viewport, which is an entirely different behavior. (I'll see if I can dig up some data on the actual % of users who change their default font size.. unless you guys have some numbers already?)
• screen width does not change on mobile because you can't resize the browser window; visual viewport changes, but screen size is always the same
• zoom factor on mobile is reset between navigations

With that in mind, the technique behind using EM's makes perfect sense. But I have a sneaking suspicion that we can arrive at very good estimate of EM's based on screen width + dpr + default font-size, and hence leverage device w/h + dpr information for asset customization (beyond images) as well.

[scottjehl]

Thanks Ilya,

I'm very glad CH is defined as a transport, and from the comments above and on Twitter, I think we see that many are excited for its potential to someday transport values that are relevant to responsive cross-device design today (viewport, root font size, and many other features).

For folks already comfortable with inferring that screen size correlates 1-to-1 with viewport, and with presuming that users don't often change font-size settings, the first iteration of CH will make things cleaner and easier. But I think the first pass mostly benefits those already in the practice of serving layouts based on stock values derived from static device databases. Admittedly, it's cleaner to poll for these units directly with CH rather than from a DB, but I doubt we'll see much variation between a db's values and those that a device reports - as you said, physical dimensions rarely ever change (I wouldn't rule it out, though!).

Looking ahead for CH, it will be the values unique to each user - not to each browser or device - that are most relevant to responsive layout, and what will prove most useful, I think. Responsive Design was born of the idea that we can build pages more, uh, responsive to the actual, live conditions in a browser, so we can meet users where they are rather than hoping they conform to our expectations.

I realize these values change frequently and are difficult to cache, but what is the value in a cached value that misrepresents a user's current browsing conditions?

To your points:

• "zoom on desktop is different from zoom on mobile" - while this may be true of some platforms today, it seems like a risky presumption to make for a forward-looking specification. That said, I'm not sure how true it is today, either, as most mobile browsers I've tested, including Chrome on my own Nexus phone make it very easy to set the font size (called "text scaling" in Chrome's user settings) to your liking.
• "'bumping font-size' on mobile is a low frequency event" - I understand the inclination to let data drive this discussion, and it would be interesting to know more about how common it is, but I worry that it's a risky bet to presume much about how people do or don't use an easy-to-find accessibility and usability feature, let alone build anything standard on the assumption that they don't.

Also, CH is intended to be implemented for all browsers, not just those installed on handhelds, correct? I agree cmd+ is very common on the desktop, and I know at least one person myself who sets her mobile font size a bit larger to make pages easier to read and use - it'd be great if this feature was usable for all of the contexts we intend to address (and not too prescriptive to be useless in future contexts).

I'm not sure how the logic would work for using CH's current screen size values to infer viewport size, not knowing whether they actually correlate to viewport size or not. Should one make the presumption that they probably do correlate to viewport unless the larger screen dimension is greater than... an arbitrary width that resembles a laptop?

• "screen width does not change on mobile" - this is true of physical device dimensions, but many tablets and phones already have viewports that don't match their screen size, as mobile browser chrome encroaches within those dimensions. On larger screens, you commonly see viewports that cover only a fraction of the available screen dimensions - the window I'm typing in right now covers half my screen. Again, viewport size and scale are the modern factors we write CSS against, as screen size is not often very useful.

Another thing to point out here is that many devices, tablets in particular, but even the Nexus, have a huge difference in screen width between portrait and landscape. This difference may mean 2 or 3 design breakpoints can apply on one device - heck, the Boston Globe site jumps from a handheld-like layout to a full desktop layout on the Blackberry Playbook when you change orientation to landscape, due to its aspect ratio - these layouts have very different assets, CSS, and scripting requirements tied to them.

Not knowing the device's orientation will mean we can safely presume much less about the layout and assets that will be needed at pageload time.

• "zoom factor on mobile is reset between navigations" - per my font scale settings in Chrome on Android, this does not appear to be true. Font settings persist across all tabs and pages that I open. Yes, the zoom factor from pinching and tapping does reset per-page, but that's not the constraint we're talking about here: root font size, not zoom. Pinching is less interesting because it physically zooms the layout itself on its own, with proportions in tact - there's not the same need to readjust the design for pinch zooming like that.

Thanks for this discussion, Ilya. I hope that the feedback above influences the future inclusion of responsive-relevant data in CH!

[igrigorik]

Admittedly, it's cleaner to poll for these units directly with CH rather than from a DB, but I doubt we'll see much variation between a db's values and those that a device reports - as you said, physical dimensions rarely ever change (I wouldn't rule it out, though!).

The critical difference here is not accuracy. Yes, the accuracy will be higher, but it's the fact that you don't have to (a) pay someone for the database, (b) integrate it into your serving path, and (c) keep it up to date afterwards, is where the real benefits are.

"zoom on desktop is different from zoom on mobile" - while this may be true of some platforms today, it seems like a risky presumption to make for a forward-looking specification.

Visual viewport was specifically introduced for mobile, and all current platforms behave in the same way. Could this change in the future? Sure, but that's speculation.. and in the meantime we have billions of devices showing otherwise.

I'm not sure how the logic would work for using CH's current screen size values to infer viewport size, not knowing whether they actually correlate to viewport size or not.

There is not one viewport, but two.. I think therein is the source of confusion. Visual viewport is adjusted by the user on mobile by zooming. Changing your visual viewport does not change the layout viewport. What I'm referring to is the layout viewport: given the device width/height (same as screen w/h on mobile), and DPR, we can figure out the (best practice) layout viewport. Once we know the layout viewport, certain optimizations can be made for size of delivered images, and other downloads -- although my focus is on images for reasons mentioned above.

Another thing to point out here is that many devices, tablets in particular, but even the Nexus, have a huge difference in screen width between portrait and landscape.

Yep, that's a good point. Existing solutions for adaptive images, etc, are "working around this" by taking the max of width/height -- this seems like a good, practical way to solve the problem.

[scottjehl]

Thanks, Ilya. I think I mistook this initial pass at CH as moving logic to the server that’s only currently possible to detect on the client, but it doesn’t sound like that’s the goal. I'll look forward to seeing how the spec is extended.

[beep]

Thanks for your time, Ilya. It sounds like I misunderstood the point of CH as well.

Personally, I will say I’d love to see more tools/specifications from Google geared toward responsive design, especially along the lines of what Scott’s outlined above. Responsive design’s "a recommended technique":https://developers.google.com/webmasters/smartphone-sites/details by Google, after all. The more options we can use to build truly UA-agnostic, cross-device designs, the better off we’ll be.

(Oh, and this is a minor nit, but: all of the better “solutions for adaptive images” I’ve used ("picturefill":https://github.com/filamentgroup/picturefill, &c.) avoid measuring the max height/width. I’m not sure what techniques Google is currently looking at, but I’m worried there’s a potential disconnect between the internal research and current best practices.)

Anyway, the above is off-topic. It sounds like @scottjehl’s initial questions/requests are out of scope for CH, and I don’t have anything to add to that.

[alastc]

Hi Scott,

I'd like to see method of the site understanding the users sizing/zoom/ preference as well, but it is worth noting that desktop webkit has a bug around pixel-based media queries and zooming: http://alastairc.ac/2012/01/zooming-bug-in-webkit/

CSS pixels are actually a pretty good relative unit, that should work well for zooming (and does in FF/IE/Op), and varying size between devices. I'm not convinced that using EMs for layout is helpful for accessibility, on most desktop and mobile browsers the default user control is either zoom, or (on iOS) nothing. At best it's an abstraction on CSS pixels, at worst it makes it harder to deal with how browsers zoom.

Also, PPK did a really good presentation on the difference between types of viewport, CSS pixels vs Device pixels, and why mobile zoom is very different from desktop. http://www.youtube.com/watch?v=4wscVOXjIzQ

With those things in mind, it would be great to see a user-set preference mechanism for default zoom level. Also, from an accessibility point of view, the ability to set a colour-scheme preference. E.g. dark on light instead of light on dark.

There was a big discussion a few years ago where the accessibility community (pretty much as a whole!) realised that to meet certain users needs (e.g. dyslexia, some sight and cognitive issues) people need different displays, especially text-size and colour scheme.

However, this is something that needs implementing by the browsers first, and then Client Hints would be the transport mechanism for the server to then deal with the preference appropriately.

Have CH would really help though, as half of the chicken and egg problem would be solved for getting user-preferences working.

-Alastair

[johnmellor]

@igrigorik wrote:

I think it's also important to note that if you stick to best practices, then you already (should) have a meta-viewport tag with viewport=device-width. In which case, the viewport == device width.

Hang on - draft 00 specifies dw as "Device width (dw) of the client, in physical pixels". In which case when you have a width=device-width viewport, the viewport width will actually be dw divided by dpr rather than just dw, since viewport width is in DIPs (density-independent pixels) not physical pixels. Similarly all the ways that device width are exposed to CSS/JS are also in DIPs, e.g. JS screen.width, CSS media query device-width, etc. It would be much more consistent with the web platform if dw was provided in DIPs (and in the rare cases you actually need physical pixels, you can still get them by multipliying by dpr).

@scottjehl wrote:

em media queries are great [...] font size adjustments are always a keystroke away (cmd-/+).

Well, most desktop browsers use cmd+/- for full page zoom, which doesn't modify the CSS font sizes, instead it makes the page (viewport) narrower/wider, then scales the entire page proportionately so it fills the same window width. So it is nice to use em breakpoints, but they shouldn't help with cmd+/-.

However you've alerted me to the fact that media query width doesn't get updated correctly in WebKit (crbug.com/86155 / wkbug.com/53186), which I can probably write a patch to fix.

@igrigorik wrote:

Further, to minimize variability in the cache key, the dw and dh values are static (do not change based on orientation)

This is a shame. Providing orientation, by swapping dw and dh in landscape, would allow sites to be served more efficiently. For example if you know that the device is initially in landscape, you could start by serving only the styles and markup that apply at the landscape width, and only load the rest later (in case the device gets rotated). And the worst it could do is double the number of variations...

[scottjehl]

@jomel thanks for the note. I disagree with your note about +/- and its effect on ems breakpoints. If you open this link (or any em-based responsive design) in Firefox or Opera, and bump your font size, you'll see the layout switch in proportion to the scale of the elements in the page, which is important because while you're correct that the content scales in unison in modern browsers, the window itself stays fixed. That's why em media queries are better at responding to the user's preferences.

If you could help fix the bug in Chrome/webkit, that'd be fantastic. Currently it only updates on refresh.

[alastc]

@scottjehl You're basing that on a webkit bug, the same should happen for px based media queries to, it's only webkit that doesn't.

[scottjehl]

Hmm. Interesting. You're right.

Even though px media queries now change in unison with font-size in many browsers too, the demand for root font size and viewport dimensions in CH stands. With those values exposed on the server, we could make reliable optimizations to asset delivery in responsive designs.

[alastc]

Phew, I sometimes feel like the lone madman ranting against an EM conspiracy! ;-)
(See the other recent article on my blog)

My background is usability & accessibility, and having done years of liquid layouts and testing with people (including many who use zoom, screenmags and readers), I'm pretty confident that with how browsers zoom now, px and em are essentially dealt with the same way. I.e. make content bigger. Media queries are a great way of dealing with expanding content when it all expands consistently.

There is definitely a need for a sizing preference, however, I would rather it be a simple "make things 20% bigger" than there being differences between text and non-text (e.g. image) sizes.

Still, sounds like all of this is unlikely to be part of CH anytime soon.

[johnmellor]

@scottjehl wrote:

If you could help fix the bug in Chrome/webkit, that'd be fantastic. Currently it only updates on refresh.

I'm not quite sure what you mean by "on refresh" (perhaps there's some other bug?). But I've landed a patch to wkbug.com/53186. Now the values of @media width and height will decrease proportionately when you press cmd+, and increase when you press cmd-.

For example with that patch, using the following media query:

body { background: red; }
@media (max-width: 700px) {
   body { background: green; } 
}

on a wide monitor the background will start out red, but it'll turn green once you zoom in sufficiently with full page zoom (without needing to reload the page).

[alastc]

@johnmellor That's great, thanks for fixing that, it's been bugging me for ages.

The refresh comment is because someone hed partially patched it for em-based media-queries, where it would re-calculate the media query on refresh (but not for px). See http://alastairc.ac/2012/01/zooming-bug-in-webkit/

[igrigorik]

Had an out-of-band chat with @johnmellor, which resulted in a few important updates.. For everyone's benefit:

I was under the impression that screen.{width,height} returns values in device pixels, but as John pointed out, that is not the case in Safari, which reports these values in DIPs. Further, as of M25, Chrome is now also reporting these values in DIPs. Hence, as John suggested, updated the spec to use DIPs.

Diff: 1995122...7be84c7#diff-3

Also, for reference:

• http://jsbin.com/urowoh/
• http://developer.android.com/guide/practices/screens_support.html#dips-pels
• http://www.w3.org/TR/screen-orientation/

[igrigorik]

• v1 draft is no longer using device width. Instead, it defines "display width" hint that corresponds to display width of the asset in dips (also see Element width/height and <img defer> #7).
• There is an outstanding bug to adjust advertised DPR value based on client zoom setting.

Working on an updated readme to explain / cover what we've covered here. Closing the issue, but feel free to reopen if needed.

[scottjehl]

Hi Ilya,

Is this issue closed because CH has no plans to report viewport size?
My concern is that viewport size (and not screen/display/device size) is typically the more relevant metric for delivering appropriate cross-device UI assets.

Thanks
Scott

[beep]

Same question/concern as @scottjehl.

[igrigorik]

@scottjehl correct, dropped device-width in favor of reporting actual display width of the asset (in dips). Just pushed an update to the readme, take a look: https://github.com/igrigorik/http-client-hints/blob/master/README.md

[ghost]

Agree. Providing the width of the image asset makes far more sense than the width of the device (which is only really relevant to full-screen images).

Ed

On 26 Oct 2013, at 00:53, Ilya Grigorik notifications@github.com wrote:

@scottjehl correct, dropped device-width in favor of reporting actual display width of the asset (in dips). Just pushed an update to the readme, take a look: https://github.com/igrigorik/http-client-hints/blob/master/README.md

—
Reply to this email directly or view it on GitHub.

[scottjehl]

Just to clarify, we're asking about viewport size (just the inside of the browser window), which is often different than screen size, particularly on larger screens like tablets and laptops

Thanks

On Oct 26, 2013, at 5:30 AM, ReSRC notifications@github.com wrote:

Agree. Providing the width of the image asset makes far more sense than the width of the device (which is only really relevant to full-screen images).

Ed

On 26 Oct 2013, at 00:53, Ilya Grigorik notifications@github.com wrote:

@scottjehl correct, dropped device-width in favor of reporting actual display width of the asset (in dips). Just pushed an update to the readme, take a look: https://github.com/igrigorik/http-client-hints/blob/master/README.md

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[igrigorik]

@scottjehl sorry, not sure if I answered your question or not then?

[scottjehl]

@igrigorik Thanks. I'm not sure if you did either. I checked out the readme. It looks great (good info about the srcN integration), but I still see information about device (or display) width but nothing about viewport width, which I think many would agree is more useful to responsive design. I can't think of many times I've written a device-width media query, while min|max-width viewport queries drive most rwd layouts out there today.

I'd imagine the viewport size would be available at request time, and it'd be awesome if that was included in CH.

Should I make a new issue to separate the viewport request from the font-size one?

On Oct 26, 2013, at 11:50 AM, Ilya Grigorik notifications@github.com wrote:

@scottjehl sorry, not sure if I answered your question or not then?

—
Reply to this email directly or view it on GitHub.

[igrigorik]

@scottjehl wait, I think I see the confusion... When I say "display width", I'm referring to "display width of the image within the viewport" (aka, the width of the image itself in DIPS), not the display width as size of the viewport or its physical pixel dimensions. It may make sense to change the name (IW for image width in DIPS) to avoid the confusion.. Does that resolve it?

[ghost]

@scottjehl not sure I understand the relevance of viewport width?, or display width? Definately relevant to responsive design/ layout yes, but not to individual http requests. can you explain?

Ed

[igrigorik]

For reference: https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L239

2.2.2.  CH-DW

   o  Description: display width of the requested resource in density
      independent pixels on the device.

[scottjehl]

Thanks Ilya. Interesting, okay maybe I've misunderstood things.

I was under the impression that the CH-DW header would specify the display width of the device screen. For example, an iPhone in portrait oriention might send a value of 320 while a Macbook laptop might send a value of 1280.

But your example sounds like CH-DW is actually describing the potential width of the resource itself, say, an image or an HTML document. Is that the case?

If so, that's neat. Would that require CSS layout to be present before an image's potential width can be calculated? Would the value of a resource's width be different if that resource is prefetched before CSS is drawn?

On Oct 27, 2013, at 11:27 AM, Ilya Grigorik notifications@github.com wrote:

For reference: https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L239

2.2.2. CH-DW

o Description: display width of the requested resource in density
independent pixels on the device.
—
Reply to this email directly or view it on GitHub.

[igrigorik]

@scottjehl right, I repurposed "DW" for asset display width, whereas previously it stood for device-width. Seeing the confusion here, I think I may change the name to "IW" for image width? "Display" is an overloaded term.

Re, size: Yes, we would need to know the viewport size to perform the calculation. Note that this is exactly the same as src-N (which is why I'm going down this route), and the assumption there is that yes, preloader would "do the right thing". /cc @yoavweiss

[scottjehl]

This is clarifying a lot, Ilya. Thanks.

A bit more if you don't mind:

I thought CH would be included in all asset requests (HTML, CSS, video, SVG), not just images. Is that no longer the case?

If it's just for images, I guess IW would make sense, but I was looking forward to this feature being useful to negotiating other assets as well (CSS especially!).

On Oct 27, 2013, at 11:51 AM, Ilya Grigorik notifications@github.com wrote:

@scottjehl right, I repurposed "DW" for asset display width, whereas previously it stood for device-width. Seeing the confusion here, I think I may change the name to "IW" for image width? "Display" is an overloaded term.

Re, size: Yes, we would need to know the viewport size to perform the calculation. Note that this is exactly the same as src-N (which is why I'm going down this route), and the assumption there is that yes, preloader would "do the right thing". /cc @yoavweiss

—
Reply to this email directly or view it on GitHub.

[ghost]

I like the idea of this applying to other assets, although I'd say there is less of a use case for CSS given there is already a solution using media queries.
Obvious advantage would be byte savings from only loading viewport relevant CSS, but would need careful consideration around what happens on a browser resize, how the new CSS asset is loaded and how long the page layout is compromised while the new asset to downloaded.

I vote keep this on images for now as not to convolute an already complicated problem. But there would be no harm in generalising the syntax. i.e. IW could be AW for Asset Width, which would make it reasonably generic and future proof.

Ed

[yoavweiss]

Re, size: Yes, we would need to know the viewport size to perform the calculation. Note that this is exactly the same as src-N (which is why I'm going down this route), and the assumption there is that yes, preloader would "do the right thing".

The preloader can be aware of the viewport size in most cases, meaning it can calculate the approximate image dimensions (as given by the Web developer) for srcN's viewport-url. So it can both pick the right resource, or send the appropriate DW/IW headers.
The preloader could also know the image dimensions for <img> resources with width attributes.

It may also be possible to correlate image requests that are in the request queue with their image dimensions once their layout dimensions are known, but that may be complicated and irrelevant for HTTP2, so I'm not sure it's a path worth pursuing. @igrigorik WDYT?

The one case that came up during the responsive image meetup where the preloader might not be aware of the viewport dimensions is when working on iframes when the parent document doesn't have layout yet. This case would need to be resolved for either CH, srcN or srcset's viewport width qualifiers.

I was looking forward to this feature being useful to negotiating other assets as well (CSS especially!).

I agree with Ed that content negotiation isn't the best approach with CSS, since MQs are better for that case. I think that CSS data savings should be tackled, but by client-side, MQ based mechanisms. IMO, Browsers should be smarter about not-loading unlikely-needed CSS, and avoid delaying onload for all non-matching CSS. But, this is an orthogonal issue.

there would be no harm in generalising the syntax. i.e. IW could be AW for Asset Width, which would make it reasonably generic and future proof

👍 for "Asset/Resource width". It might be useful for videos or iframes (and possibly other resources that have width, and I've forgotten) assuming that they're fetched after layout.

[igrigorik]

@scottjehl the logic behind when the CH hints are sent is up to the UA. The simplest strategy is, of course, to send it on every request, but this has the downside that the header might be sent to many sites which are not "CH aware". Alternatively, we can use an opt-in mechanism where the server returns an HTTP header / meta-tag which triggers CH for all of its subresources (as a result, HTML doc won't get CH hints, but all resources will).

For more background, checkout this thread: #8 (comment), and opt-in section in the spec: https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L310

[igrigorik]

It may also be possible to correlate image requests that are in the request queue with their image dimensions once their layout dimensions are known, but that may be complicated and irrelevant for HTTP2, so I'm not sure it's a path worth pursuing. @igrigorik WDYT?

The beauty of HTTP2 is that there is no client-side queue.. We dispatch requests as soon as we encounter them. That's not to say we can't re-introduce a queue, but for obvious reasons it would be nice to avoid doing so.

The one case that came up during the responsive image meetup where the preloader might not be aware of the viewport dimensions is when working on iframes when the parent document doesn't have layout yet. This case would need to be resolved for either CH, srcN or srcset's viewport width qualifiers.

Yeah, the iframe case is tricky, not sure that I have any clever solutions for it. For the general case, we're working off the assumption that the HTML doc will have a meta viewport at the head, which will allow us to get a handle on viewport size and not block on any other external resources (aka, @Viewport is an antipattern).

I agree with Ed that content negotiation isn't the best approach with CSS, since MQs are better for that case. I think that CSS data savings should be tackled, but by client-side, MQ based mechanisms. IMO, Browsers should be smarter about not-loading unlikely-needed CSS, and avoid delaying onload for all non-matching CSS. But, this is an orthogonal issue.

I know you've been working on this piece (MQ eval in preloader), what's the status there?

👍 for "Asset/Resource width". It might be useful for videos or iframes (and possibly other resources that have width, and I've forgotten) assuming that they're fetched after layout.

Resource width (RW) sounds good. Couple of thoughts: I guess I should clarify in the spec that RW should apply to resources that have a width only. OR, in principle (and despite the MQ argument), we could actually say that if width is not available, then the viewport size should be sent instead - i.e. in case of CSS, JS, etc, it would send the viewport. Hmm? Any strong arguments or use-cases for or against this behavior?

[yoavweiss]

The beauty of HTTP2 is that there is no client-side queue.. We dispatch requests as soon as we encounter them. That's not to say we can't re-introduce a queue, but for obvious reasons it would be nice to avoid doing so.

This is exactly why I think this would be irrelevant for HTTP2. Re-introducing the queue feels wrong to me.
Is there a clean way in HTTP2 to re-send previous requests with extra CH headers? That way the server logic can decide if some responses should be delayed until the resource display dimensions are known

I know you've been working on this piece (MQ eval in preloader), what's the status there?

MQs eval for preloaded CSS is working fine (with eval happening on the main thread before the request is sent out), so non-matching CSS resources are not preloaded.
The problem is that the HTML parser is loading these resources later on (with low priority), and they're blocking onload.
I know that historically, there were trouble with content breaking when non-matching CSS as not loaded at all, but I'm not sure what these trouble were, and if they're still relevant.

Resource width (RW) sounds good. Couple of thoughts: I guess I should clarify in the spec that RW should apply to resources that have a width only. OR, in principle (and despite the MQ argument), we could actually say that if width is not available, then the viewport size should be sent instead - i.e. in case of CSS, JS, etc, it would send the viewport. Hmm? Any strong arguments or use-cases for or against this behavior?

As long as viewport width is sent with it own header (to avoid confusion), that sounds like a good idea.
It can also be relevant for resources with width that are requested before layout.

One thing we should think for both RW and VW is what happens when the layout changes and the values with which the request were sent are no longer valid (e.g orientation change, style change, etc). Do we re-request? Do we need a new "if-CH-modified" HTTP request header?

[igrigorik]

This is exactly why I think this would be irrelevant for HTTP2. Re-introducing the queue feels wrong to me.
Is there a clean way in HTTP2 to re-send previous requests with extra CH headers? That way the server logic can decide if some responses should be delayed until the resource display dimensions are known.

No. There is trailer headers, but we don't want to go there.

MQs eval for preloaded CSS is working fine (with eval happening on the main thread before the request is sent out), so non-matching CSS resources are not preloaded.

Awesome, is that live?

The problem is that the HTML parser is loading these resources later on (with low priority), and they're blocking onload. I know that historically, there were trouble with content breaking when non-matching CSS as not loaded at all, but I'm not sure what these trouble were, and if they're still relevant.

Interesting. Do we have an open bug for this? What's the status?

As long as viewport width is sent with it own header (to avoid confusion), that sounds like a good idea. It can also be relevant for resources with width that are requested before layout.

My gut feel is that this is starting to get too complicated if we start distinguishing before/after layout cases.

• If resource has a width, and layout width is known, send it, and otherwise skip the width hint.
• (maybe) If resource does not have a width (e.g. script), then send viewport.

Not entirely convinced we need the latter yet...

One thing we should think for both RW and VW is what happens when the layout changes and the values with which the request were sent are no longer valid (e.g orientation change, style change, etc). Do we re-request? Do we need a new "if-CH-modified" HTTP request header?

You don't need If-CH headers, we have Vary: if the value of CH-DPR/CH-DW changes, so will the cache key. For layout changes, a couple of cases:

• if layout change triggers a new rule with different resource URL (e.g. different image in portrait vs landscape) then new request will be made with dimensions of new asset. </simple case>
• if layout change triggers new rule with same resource URL, then (I believe) the current behavior is that we will reuse the existing resource and scale it up/down to new dimensions without making a new request. However, a reload / refresh would trigger new download if new width != old width. FWIW, this is same behavior as DPR change on zoom -- quick test: http://jsbin.com/ijEqAqa/1/quiet (test on Canary) zoom doesn't change the image, but refresh after zoom does.

[yoavweiss]

Awesome, is that live?

Yeah, have been live for a while now in Blink. Also went into WebKit recently, but not shipped in Safari 7 AFAIK.

Interesting. Do we have an open bug for this? What's the status?

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.
I should probably bug @tabatkins again on this issue.

Not entirely convinced we need the latter yet...
Me neither. Use cases first?

You don't need If-CH headers, we have Vary: if the value of CH-DPR/CH-DW changes, so will the cache key.

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

For layout changes, a couple of cases:

• if layout change triggers a new rule with different resource URL (e.g. different image in portrait vs landscape) then new request will be made with dimensions of new asset.
• if layout change triggers new rule with same resource URL, then (I believe) the current behavior is that we will reuse the existing resource and scale it up/down to new dimensions without making a new request. However, a reload / refresh would trigger new download if new width != old width. FWIW, this is same behavior as DPR change on zoom -- quick test: http://jsbin.com/ijEqAqa/1/quiet (test on Canary) zoom doesn't change the image, but refresh after zoom does.

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.

[igrigorik]

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: 1f9dcbf (DW > RW). Second, let's continue this discussion in a separate bug: #18

[yoavweiss]

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.. :)

Yeah. Vary wouldn't work, which is why I thought of some "if-CH-Modified" header, but you're right that Key can solve this. Key's range modifier (http://tools.ietf.org/html/draft-fielding-http-key-02#section-2.2.5 - which I wasn't aware of) can solve it quite elegantly if only "key" was supported in browsers (even if it wasn't supported in intermediates - which is the hard part).

Do you know what's the status of the key spec? The most recent one I've seen is an expired draft :/

[igrigorik]

Yep, you can see the Key + CH examples here: https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L340

@mnot is the best person to comment on status of Key. I believe ATS / Squid teams were doing some prototyping work, and I'd be curious to know if they made any progress there.. That said, I agree, proxy/cache support for Key is only part of the equation. Once you start playing with RW, it may in fact be much more valuable on the client.. as it would allow you to skip the request entirely if the condition matches.