Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-values] clarify that most (all?) high-dpi devices anchor on pixel, rather than physical, unit #708
The section on absolute lengths https://drafts.csswg.org/css-values/#absolute-lengths currently contains the following:
In essence, this splits devices into "print and high resolution" on one side, and "lower-resolution and unusual viewing distances". However, most (all?) high-dpi devices (including recent desktop monitors, laptops, mobile/tablet devices) currently also anchor on the pixel unit. It seems that it's really only print media that (try to) anchor on physical units (unless I'm missing some non-print device that does this?).
I think it would be important to either rewrite this section to change the distinction, or to leave the above as is but then include a note straight after clarifying that currently even high-resolution desktops/laptops/mobiles/tablets are anchored on the pixel unit.
The reason for bringing this up is that this issue seems to constantly rear its head in discussions around being able to use absolute measures like "mm" to actually map to physical size of elements as rendered on a device (most recently I had this discussion in the mobile accessibility task force https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Summary_of_Research_on_Touch/Pointer_Target_Size#Comparison_of_web_content_sized_in_px_and_physical_size_of_rendered_content_on_common_device_screens which led to having to demonstrate this practically using http://codepen.io/patrickhlauke/full/zqabMR/ ... and I'm aware of similar discussions under WICG in relation to large screen / TV environments)
Happy to draft a PR if this sounds like a reasonable request.
I agree with this. This isn't really changing how things work, a the way units are anchored to eachother stays the same, and the recommendation to anchor the whole system to either the physical units is only a recommendation, not a requirement. But it is indeed a recommendation that does not match reality, and I don't think it is particularly good advice: what browsers do today is the right thing to do.
referenced this issue
Nov 15, 2016
Wrt the PR here (which, btw, fails to edit css-values-3), it seems to categorize print media with unusual viewing distances into the physical-anchor category, whereas before they were grouped with the pixel-anchor category. If this was an intentional change, I would like a clear resolution on that change from the WG. If that is not an intentional change, then I intend to revert it.
@patrickhlauke can you clarify your intent?
oh, does that mean this PR targetted the wrong branch or file? should i resubmit the PR targetting the right one (which one?)
@fantasai as the second part of that section even in the original didn't explicitly say "print", it didn't occur to me here that it even covered "print media with unusual viewing distances" (and i struggle to think of such a device to be honest). But thinking about it now I'd say that once it's print, shouldn't it still be anchored to physical size regardless of what viewing distance the end result is then intended to be viewed at (since the author would presumably account for this, and do so by specifying sizes again with an expectation of them being anchored on actual physical sizes). Also, to make a simplistic analogy, how would a UA/printer know if something's intended to be viewed at a "usual" or "unusual" distance?
in short, it was not my intention of redefining the anchoring of "print media with unusual viewing distances" when I made the PR, as it was not clear to me that this text implicitly covered it. but i'd say print should always be anchored on physical units regardless
No worries, I can port it over. (css-values-3 was forked out, so edits needed to go to both css-values-3/Overview.bs and css-values/Overview.bs)
Non-electronic billboards and signage? :)
On the one hand, there's that. And on the other, wouldn't you want electronic and non-electronic signage to behave the same? There's a huge gulf between 1/96in in physical units and 1px in angular units at far distances.
Anyway, I'll Agenda+ to sort this out then.
My take on this is that we shouldn't obsess to much, since this is only a should. As print media with unusual viewing distances are not the typical case, it's perfectly fine to deviate from the recommendation when you have better knowledge of what this is actually for.
ah, good point.
while i can see both sides of this, my (purely personal of course) view here is that for a designer, when they work on paper/print, they have a stronger expectation that setting something in physical units will also match real-world physical units, whereas when designing for screen (knowing that screens have all sorts of variables like resolution etc) there's perhaps more of an expectation that everything anchors to the CSS pixel (which ideally should be close to the reference pixel, but even that varies across devices/OSs/UAs). also, purely empirically, i don't know many designers who use physical units like
referenced this issue
May 24, 2017
The CSS Working Group just discussed
The full IRC log of that discussion<zcorpan> Topic: [css-values] clarify that most (all?) high-dpi devices anchor on pixel, rather than physical, unit
<dbaron> that went to the wrong github issue
<zcorpan> Github topic: https://github.com//issues/708
<zcorpan> fantasai: PR for ???
<zcorpan> fantasai: reviewing the changes to update V&U spec
<zcorpan> fantasai: one implemented the resolution here
<zcorpan> fantasai: also switch the ... anchor category
<zcorpan> fantasai: 2 categories for anchor units
<zcorpan> fantasai: pixel viewing angle unit
<zcorpan> fantasai: other is physical unit
<zcorpan> fantasai: css is based on 96 DPI and px is viewing angle
<zcorpan> fantasai: used to be independent but changed due to web compat
<zcorpan> fantasai: when you print, 12pt is actually 12pt
<zcorpan> fantasai: on screen we do the 96DPI thing and round to actual pixels to make it look nice on the screen
<zcorpan> fantasai: print and high-dpi together...
<zcorpan> fantasai: the change also moved devices with unusual viewing distances
<zcorpan> fantasai: so for print with unusual viewing distance, which category?
<zcorpan> fantasai: now it's in the physical category
<zcorpan> fantasai: do we want to revert the change?
<zcorpan> Rossen_: So, going to echo florian's point...
<zcorpan> Rossen_: since this is a SHOULD, do we need to change?
<dbaron> seems like if you're taking content written for another device and print it on a billboard, you want your "12pt" font to be bigger than 12pt
<zcorpan> fantasai: if we don't have anything we want to change we shouldn't change from the previous PR
<zcorpan> dbaron: the change seems reasonable to me
<zcorpan> dbaron: if you take content designed from a different device and print to a billboard you may want the viewing distance thing
<zcorpan> dbaron: OTOH if you design for the billboard you may want physical units
<dbaron> plinss: seems like this should be a choice when you're printing
<zcorpan> plinss: not happy with either change
<tantek> where is the change?
<zcorpan> plinss: it's a print-time choice based on the content, device, etc
<zcorpan> plinss: shouldn't mandate from the spec
<zcorpan> Rossen_: right, that's why it's a should
<astearns> tantek: https://github.com//pull/713/files
<zcorpan> Rossen_: might be enough
<fantasai> tantek, https://github.com//pull/713/files
<zcorpan> plinss: I think that's not what should means
<zcorpan> bradk: seems like a viewing angle situation
<zcorpan> bradk: language an opt-in, in ebook(?) you can go either way
<zcorpan> fremy: can't you leave it as choice per device?
<zcorpan> plinss: need all devices to be consistent
<zcorpan> tantek: i'm confused by the example of billboard vs print
<zcorpan> fantasai: it's an example of a device with an unusual viewing distance
<zcorpan> tantek: looking at the diff in github... billboard can be print or screen
<zcorpan> dbaron: the PR changed printed billboard because of the way it worded it
<zcorpan> fantasai: [citing spec?]
<zcorpan> fantasai: not a subset of screen media
<zcorpan> fantasai: 1 category is high-res, second is low-res and unusual viewing distance
<zcorpan> fantasai: before you could interpret print with unusual viewing distance as either
<zcorpan> fantasai: now it can only be that for screen media
<zcorpan> fantasai: becomes ???
<zcorpan> someone: sounds sensible
<fantasai> Proposal is to move the lcose parentheses after "including high-resolution devices"
<Rossen_> For screen media (including high-resolution devices), lower-resolution devices, and devices with unusual viewing distances,
<zcorpan> Rossen_: sounds pretty good
<astearns> s/, /, /
<bradk> I agree
<zcorpan> fantasai: ok, i will make the change
<zcorpan> plinss: happy with the change
<zcorpan> plinss: maybe provide an opt-in later
<fantasai> ScribeNick: fantasai
<zcorpan> Proposed resolution: move the lcose parentheses after "including high-resolution devices"
<tantek> +1 to proposal
<fantasai> RESOLVED: Move the close parens afte r"including high-resolution devices"
<myles> scribenick: myles
so if a physical printer is deemed "low resolution", using physical CSS units will actually have them anchored on px rather than trying to reflect their real physical size? and same for large scale print? can't say i'm exactly thrilled by this...so a printer will use physical units only if it falls between "not low resolution, not aimed at large print"?
@fantasai also, simply moving the parenthesis won't be enough if your intention was to cover print at unusual viewing distances like poster/billboard, because otherwise now you have two conflicting sentences:
which would imply ALL print media, followed by
which, in light of the preceding sentence, would suggest that it doesn't apply to print media regardless of resolution or viewing distance
Taking just one OS as an example, does Android provide exact measurement in physical units of the screen as an API/value that can be queried by native apps? as far as I'm aware, a native app can query "Screen Size", but the return values from the OS are only "small, normal, large, and extra-large".
Assume now a browser gets downloaded from Google Play and installed (so it's not preinstalled by the manufacturer/OEM) . How can the browser know what the actual physical dimension of the screen of that particular device is?
Extending this to other scenarios: what about a set-top box connected to a TV. How can the set-top box know the actual physical dimensions of the TV? It may be able to detect what resolution (HD, 4K, etc) it can send a signal at, but the TV could be any dimension (from a small 20" high-density 4K monitor to a low-resolution giant billboard at the side of a building).
In short, there are too many variables at play here. IF it's a completely closed environment (for instance, a TV browser that's integrated directly in the TV by the manufacturer/OEM), then sure there's a chance that the manufacturer could set the explicit screen dimensions as one of the variables for the browser engine and burn it into the firmware. And, as the spec here is only a suggestion for UAs, they're quite free to do it. But for general purpose browsers/devices that may be installed on devices with/connected to a variety of unknown and unknowable display sizes, anchoring to the CSS pixel is the most sensible approach (leaving it up to devices/OSs to at least set a sane CSS pixel mapping/ideal viewport).