Related (perhaps duplicate?): Issue #614

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)

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.

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

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?

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

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.

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.

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)

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

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

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"

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:

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

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.

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

Closing, as my primary concern (to specify that even high-resolution screen media are still anchored on pixels, to match reality) is addressed.

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.

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

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.