Repository navigation
[css-values] clarify that most (all?) high-dpi devices anchor on pixel, rather than physical, unit #708
Description
The section on absolute lengths https://drafts.csswg.org/css-values/#absolute-lengths currently contains the following:
For print media and similar high-resolution devices, the anchor unit should be one of the standard physical units (inches, centimeters, etc). For lower-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.
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.
Activity
nicksherman commentedon Nov 14, 2016
Related (perhaps duplicate?): Issue #614
patrickhlauke commentedon Nov 14, 2016
related yes. not duplicate though, I'd say (as #614 is proposing a change in what UAs do / new units of measure, while here I'm proposing making the spec match/describe reality as it stands a bit more closely)
frivoal commentedon Nov 15, 2016
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.
patrickhlauke commentedon Nov 15, 2016
@frivoal cool i'll draft a PR in the coming days and fling it over
fantasai commentedon May 17, 2017
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?
patrickhlauke commentedon May 17, 2017
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
fantasai commentedon May 17, 2017
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.
6 remaining items
css-meeting-bot commentedon May 24, 2017
The CSS Working Group just discussed
[css-values] clarify that most (all?) high-dpi devices anchor on pixel, rather than physical, unit, and agreed to the following resolutions:RESOLVED: Move the close parens afte r"including high-resolution devices"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
<bradk> s/ebook/e-paper
<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"
<fantasai> s/someone/tantek/
<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
patrickhlauke commentedon May 24, 2017
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"?
patrickhlauke commentedon May 24, 2017
@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
[css-values] Move parentheses and forward-port fix for #708.
[css-values] Address conflict between clauses per #708 (comment)
fantasai commentedon Jun 21, 2017
Okay, checked in some wording tweaks' per @plinss’s advice. Let me know if this is sufficient. Keep in mind these are recommendations: a UA can do something different if it has a reason for it.
[css-values] Address conflict between clauses 他
patrickhlauke commentedon Jul 1, 2017
While I still think that print should always be anchored on physical sizes regardless of viewing distance etc, I agree the rewritten section are now clearer without conflict. Thanks @fantasai and @plinns
patrickhlauke commentedon Jul 1, 2017
Closing, as my primary concern (to specify that even high-resolution screen media are still anchored on pixels, to match reality) is addressed.
Crissov commentedon Jul 1, 2017
It makes no sense whatsoever that browsers on highly integrated devices like phones, tablets and TVs with known fixed screen dimension and resolution do not anchor on physical units.
patrickhlauke commentedon Jul 1, 2017
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).
Crissov commentedon Jul 1, 2017
I was indeed thinking of highly integrated devices, e.g. iOS ones and TVs (not STBs), although Android should be able too provide reliable information to apps as well.