[css-zoom?] Zoom and CSSOM

[emilio]

Zoom has some interesting behavior for the CSSOM, since it undoes some of its effects, but only in some APIs.

The original zoom draft by @atanassov makes sense to me:

• You want all getComputedStyle things to be unzoomed, because you want to preserve div.style.foo = getComputedStyle(div).foo round-tripping.
• You might want some of the sizes to be unzoomed.
• But you never want positions to be unzoomed, that makes no sense because the positions are meaningless if you cross a zoom boundary and you unzoom them.

However Blink and WebKit seem to unzoom in things like getBoundingClientRect, ResizeObserver rects, and so on. I don't think those make much sense for the same reason zooming positions doesn't make much sense.

My personal take is that, in general, the less APIs that account for zoom by unzooming, the better.

cc: #5623 @chrishtr @lilles @smfr @tabatkins @atanassov

[chrishtr]

However Blink and WebKit seem to unzoom in things like getBoundingClientRect, ResizeObserver rects, and so on. I don't think those make much sense for the same reason zooming positions doesn't make much sense.

I agree that it doesn't make sense and should change. My comment here says basically the same thing you're saying here.

[css-meeting-bot]

The CSS Working Group just discussed [css-zoom?] Zoom and CSSOM.

The full IRC log of that discussion

[css-meeting-bot]

The CSS Working Group just discussed [css-zoom?] Zoom and CSSOM, and agreed to the following:

• RESOLVED: getComputedStyle() returns unzoomed value
• RESOLVED: APIs that return bounding boxes such as getClientRects and ResizeObserver and IntersectionObserver return values in page-global px units
• RESOLVED: s/ResizeObserver/getBoundingClientRect/

The full IRC log of that discussion

<fantasai> emilio: Variety of things in current browsers consistently account for zoom
<fantasai> emilio: I think we have consensus that anything with a position and getComputedStyle shouldn't account for zoom
<fantasai> emilio: would like to resolve on that
<chrishtr> +1 to that proposed resolution
<fantasai> emilio: some smaller things like clientWidth can multiple zoom
<fantasai> emilio: my feeling is, the less APIs account for zoom the better
<fantasai> emilio: It seems getClientRect and ResizeObserver don't have a lot of compat constraints
<Rossen_> q?
<fantasai> chrishtr: My guess is compat restrictions are low
<fantasai> chrishtr: most users not using these APIs
<fantasai> Rossen_: starting with a more restricted set is easier to expand than the other way around
<fantasai> chrishtr: WebKit and Chromium both implement the undesired behavior that emilio wants to change in this resolution
<fantasai> chrishtr: From my perspective, chromium happy to change, don't think we have compat risk
<emilio> fantasai: just checking if i understand correctly
<Rossen_> fantasai: just to check, we should zoom or not in getComputedStyle
<fantasai> emilio: if unzoomed size is 100px, and zoom is 2, gCS will return 100px to preserve round-tripping
<fantasai> RESOLVED: getComputedStyle() returns unzoomed value
<fantasai> so that it round-trips
<flackr> q+
<fantasai> Rossen_: next, the rest of the APIs will return zoomed values
<Rossen_> ack fantasai
<Rossen_> ack flackr
<fantasai> flackr: I think that makes sense for things like getBoundingClientRect
<fantasai> flackr: not so sure about offsetTop
<fantasai> flackr: typically those are used to position things within the same parent, which has the zoom applied
<fantasai> flackr: so maybe it should apply any zoom that exists on that element, but not the zoom all the way to the screen
<fantasai> emilio: problem is that positions cross zoom boundaries
<fantasai> emilio: anything that has an offset, left or right, is not relative to a particular element. Or can be relative to elements with different effective zooms.
<fantasai> emilio: whatever you do, if it crosses the zoom boundary, it's going to be wrong for some use cases
<fantasai> emilio: so I'd like to not unzoom stuff that contains positions at all
<fantasai> flackr: so to make sure I understand, you're saying it'll apply all of the ancestor zooms
<fantasai> emilio: it would return unzoomed CSS px, depends what it's relative to
<fantasai> emilio: it would return zoom-independent CSS pixels, if that makes sense
<fantasai> emilio: we don't have that concept in the spec... but that's effectively the thing that gets stored in the computed style
<fantasai> flackr: same true of offsetWidth/Height ...
<fantasai> flackr: I think this will be hard to work with if not in the same space as the element you're working with
<TabAtkins> I think the general point is that people shouldn't be using zoom anyway...
<fantasai> emilio: if the position is relative to somehting with a different effective zoom, it's wrong either way
<fantasai> emilio: there's no good thing to return, you cannot say it's really 2x zoom 100px + ...
<TabAtkins> The closer zoom is to a scale() the better imo.
<fantasai> emilio: Idk how you'd return sensible values if you're crossing a zoom boundary
<fantasai> emilio: returning unzoomed values is returning in a coordinate space that the whole page understands
<fantasai> flackr: My proposal would be that it returns in the element's own coordinate space
<fantasai> flackr: developer could determine what conversion is necessary if moving to a different space
<fantasai> flackr: but if e.g. applying to sibling with same ancestor zoom, can use the styles direction
<fantasai> s/direction/directly
<Rossen_> q?
<fantasai> flackr: e.g. set style.left = otherElementOffsetWidth
<fantasai> emilio: [missed]
<fantasai> flackr: [missed]
<fantasai> flackr: if multiplied by the zoom of the parent, but global zoom seems hard to work with
<fantasai> [flackr said something about how people write code with this]
<fantasai> Rossen_: [repeats Tab's comment about analogy with scale()]
<fantasai> Rossen_: seems like this needs more discussion?
<chrishtr> q+
<fantasai> flackr: I still have some concerns
<fantasai> emilio: can we resolve on things that return client rects [missed]
<Rossen_> ack chrishtr
<fantasai> chrishtr: I agree that we should resolve on things that return client rects returning those in the physical pixel space, considering zoom
<fantasai> chrishtr: in addition, I think we should work through some examples in the issue to see what works best for offsetTop etc.
<vmpstr> can we think of good terminology for these spaces?
<fantasai> chrishtr: I think this feature has direct value to developers, and we shouldn't consider a sad compat compromise
<fantasai> Rossen_: 100% agree
<fantasai> Rossen_: proposed resolution is, apply unzoomed value results to all bounding-box returning APIs
<fantasai> fantasai: this is the global coordinate system?
<fantasai> emilio: yeah. Let's call it global px values or something
<fantasai> Rossen_: page px values
<fantasai> RESOLVED: APIs that return bounding boxes such as getClientRects and ResizeObserver and IntersectionObserver return values in page-global px units
<PaulG> q+
<fantasai> s/units/unit coords/
<Rossen_> ack PaulG
<fantasai> PaulG: I'm concerned, if a dev wants to assess if an element is covered or visibible in the viewport, will struggle with that
<fantasai> PaulG: if they get it wrong, has a11y impact
<fantasai> emilio: for that use case, what we just resolved on is what we want
<fantasai> PaulG: I think so too, will review with APA
<chrishtr> q+
<Rossen_> ack chrishtr
<fantasai> chrishtr: Checking in on ResizeObserver, that returns offsetWidth-ish things?
<fantasai> chrishtr: should we exclude from resolution?
<fantasai> emilio: is content box relative to the element?
<fantasai> chrishtr: I think it is
<fantasai> RESOLVED: s/ResizeObserver/getBoundingClientRect/