- From: Carlos Lopez via GitHub <sysbot+gh@w3.org>
- Date: Sat, 04 Mar 2023 15:38:28 +0000
- To: public-css-archive@w3.org
clshortfuse has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-values-4]: clarification need if absolute length units are zoom independent ==
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:
````css
#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
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8525 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 4 March 2023 15:38:30 UTC