[css-values-4]: clarification need if absolute length units are zoom independent

[clshortfuse]

spec: https://w3c.github.io/csswg-drafts/css-values/#absolute-lengths

The current implementation of absolute units in the major browsers scale with browser zoom. This makes the units density-independent pixels (dip) since they are seemingly bound by the the user preference for zoom. The definitions seem to heavily focus on print media, which gives the impression that these units should be bound to real life, tangible lengths. But when attempting to use these units, page zoom will scale them up and down.

Use case:

3.2 Touch Target Size and Spacing
The high resolution of mobile devices means that many interactive elements can be shown together on a small screen. But these elements must be big enough and have enough distance from each other so that users can safely target them by touch.

Best practices for touch target size include the following:

• Ensuring that touch targets are at least 9 mm high by 9 mm wide.
• Ensuring that touch targets close to the minimum size are surrounded by a small amount of inactive space.

https://www.w3.org/TR/mobile-accessibility-mapping/

It would be reasonable to ensure touch targets are 9x9mm because they correspond to a real, physical object (finger or stylus).

Implementation:

We should be able to create a dynamically sized touch target with the following code:

#touch-target {
  position: absolute;
  inset: 50%;

  block-size: 100%;
  min-block-size: 48px;
  min-block-size: 10mm;
  inline-size:100%;
  min-inline-size: 48px;
  min-inline-size: 10mm;

  cursor: inherit;

  z-index: 1;

  transform: translateX(-50%) translateY(-50%);
}

But in practice, this value gets computed down to pixels and scaled. For example, on my monitor, targeting 10mm, would yield fine at 100%:

The small 32x32px buttons would create a bump up to 37.78px, which is closer to ideal. But when zoomed down to 75%, the 32px (now 24x24px) has a equally shrunk down 7.5mm touch target:

Likewise, zoomed to 200%:

Yields a much larger massive 20mm touch size, now being oversized.

Browser state:

---

Chromium team hasn't addressed this for lack of clarity though specific to print:

Both Firefox and Safari do the same thing as Chrome, at least on Mac. Either we're all wrong, or the content is wrong, or this is a spec issue. Given the agreement among browsers we won't change.

https://bugs.chromium.org/p/chromium/issues/detail?id=922695#c9

It's unclear what the next step is here. Perhaps someone on the print team can chime on on the expected behavior and whether we should bring this up with the CSSWG.

https://bugs.chromium.org/p/chromium/issues/detail?id=922695#c13

---

Firefox has a bug detailing how mm in Windows isn't accurate: https://bugzilla.mozilla.org/show_bug.cgi?id=667260

Firefox used to have a length called mozmm that was eventually removed: https://bugzilla.mozilla.org/show_bug.cgi?id=1416564

---

Webkit has an issue showing absolute units are locked to 96dpi: https://bugs.webkit.org/show_bug.cgi?id=11644

[Crissov]

First see #614 and #837 for instance.

Not scaling sizes for page zoom could indeed be another bonus of proposed tip or tap units, which could finally make them interesting enough for browser makers.

[tabatkins]

The spec is very clear that all the absolute length units (in, mm, px, etc) are simple linear multiples of each other - 1in is always 96px, ~25.4mm, etc. The UA chooses what length one of them is, and the rest fall out by scaling. On browsers, it's common for the px unit to be tied to an integer number of device pixels, at least by default (this is noted in the spec) but UAs are allowed to do anything else they want, such as anchoring 1in to an actual inch. A browser is thus allowed, but not required, to do things like correctly sizing the physical units at 100% zoom when printing.

This used to not be the case - the real-world units were all coupled together, but the px unit wasn't necessarily so. This broke websites, because people used mixtures of px and other units (especially pt, which is 1/72 of an inch) and didn't anticipate the sizes scaling differently under zoom. So everyone converged on px just being a physical unit that was exactly 1/96 of an inch.

Targets being larger or smaller under zoom is very much intentional - that's the entire point of zooming, after all. Some browsers used to have a "text only" zoom that scaled font sizes but didn't change the viewport size, but that's faded from mainstream browsers, again because it reliably breaks pages. This means there are some use-cases that can't be addressed without manual intervention from the page, but that's unfortunately the result of many years of compat pain.