Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-values] clarify that most (all?) high-dpi devices anchor on pixel, rather than physical, unit #708

Closed
patrickhlauke opened this issue Nov 14, 2016 · 19 comments

Comments

Projects
None yet
6 participants
@patrickhlauke
Copy link
Member

commented Nov 14, 2016

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.

@nicksherman

This comment has been minimized.

Copy link

commented Nov 14, 2016

Related (perhaps duplicate?): Issue #614

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented 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

This comment has been minimized.

Copy link
Collaborator

commented 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

This comment has been minimized.

Copy link
Member Author

commented Nov 15, 2016

@frivoal cool i'll draft a PR in the coming days and fling it over

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented 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?

@fantasai fantasai reopened this May 17, 2017

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented May 17, 2017

Wrt the PR here (which, btw, fails to edit css-values-3),

oh, does that mean this PR targetted the wrong branch or file? should i resubmit the PR targetting the right one (which one?)

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.

@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

This comment has been minimized.

Copy link
Collaborator

commented 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?)

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)

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)

Non-electronic billboards and signage? :)

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?

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.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented May 18, 2017

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.

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented May 18, 2017

Non-electronic billboards and signage?

ah, good point.

wouldn't you want electronic and non-electronic signage to behave the same?

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 mm when working for screen (though i know many designers who "discover" these physical units and are then quite disappointed that on screen it's anchored on pixel and usually they don't match up to real-world units as measured on the physical screen, as per 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)

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented May 18, 2017

we shouldn't obsess to much, since this is only a should

that's also a sensible take / get-out-of-jail card :)

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented 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

This comment has been minimized.

Copy link
Member Author

commented 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

This comment has been minimized.

Copy link
Member Author

commented 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:

For print media, the anchor unit should be one of the standard physical units (inches, centimeters, etc).

which would imply ALL print media, followed by

For screen media (including high-resolution devices), lower-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit.

which, in light of the preceding sentence, would suggest that it doesn't apply to print media regardless of resolution or viewing distance

@fantasai

This comment has been minimized.

Copy link
Collaborator

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

triple-underscore added a commit to triple-underscore/triple-underscore.github.io that referenced this issue Jun 24, 2017

[css-values] Address conflict between clauses 他
Move parentheses and forward-port fix for
w3c/csswg-drafts#708
w3c/csswg-drafts@b2f546e
f28e820c563.

Address conflict between clauses per
w3c/csswg-drafts#708 (comment)
(comment)
w3c/csswg-drafts@78ea322
5e29e48e0c8
@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented 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

This comment has been minimized.

Copy link
Member Author

commented 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

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Member Author

commented 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

This comment has been minimized.

Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.