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