- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 23:25:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-viewport] [cssom] [css-typed-om] Consider adding a way of exposing the effective zoom.`, and agreed to the following: * `RESOLVED: Add Element.currentCSSZoom into CSSOM-view as proposed in #9809; bikeshed later as needed` <details><summary>The full IRC log of that discussion</summary> <fantasai> emilio: while prototyping zoom, the effective zoom is trivially accessible to the engine<br> <fantasai> emilio: but there's no way as an author to compute it, other than walking the entire ancestor chain<br> <fantasai> emilio: but you often need it for JS interactions<br> <fantasai> emilio: Does it seem fine to expose it?<br> <fantasai> emilio: if it seems fine, where do we expose it?<br> <fantasai> emilio: maybe just in Element is fine?<br> <fantasai> emilio: could put it in CSSComputedStyleDeclaration but we'd need a separate interface<br> <fantasai> emilio: already have the computed value of zoom<br> <bramus> q+<br> <fantasai> emilio: so maybe effectiveZoom? But not a page zoom so effectiveCSSZoom?<br> <TabAtkins> q+<br> <Rossen_> ack bramus<br> <fantasai> bramus: I like not exposing through getComputedStyle because that would be confusing<br> <fantasai> bramus: so other property seems reasonable to me<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: would it make sense to call it "usedZoom"?<br> <fantasai> fantasai: isn't it the used zoom value?<br> <dholbert> TabAtkins (IRC): it's not the used value, it's the collective value from all the ancestors<br> <dholbert> fantasai (IRC): it's different from the computed value?<br> <dholbert> emilio (IRC): it's also different from the zoom property value<br> <dholbert> TabAtkins (IRC): we don't usually do that with used value. You could make the same argument about transform<br> <dholbert> TabAtkins (IRC): transforms accumulate, but we don't expose that in this way<br> <chrishtr> +1 to effectiveZoom on Element<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: Do you have an example of how you would use this?<br> <fantasai> emilio: [gives an example]<br> <fantasai> emilio: to compare them you need to multiply by effective Zoom<br> <schenney> q+<br> <nicole> q+<br> <fantasai> emilio: it's the way to convert between local coordinate and global coordinate<br> <fantasai> TabAtkins: ok<br> <fantasai> emilio: same for scroll positions. scrollTop is in the local space<br> <fantasai> emilio: There's a lot of APIs that use local space, and some in global. To convert between them you need something<br> <bramus> s/[gives an example]/example: getBoundingClientRect values don’t take zoom into account, so you have to multiply their values such as clientWidth by the effective zoom<br> <Rossen_> ack schenney<br> <fantasai> schenney: in Chrome, would device scale factor be included?<br> <fantasai> emilio: no, you only want the effective zoom property<br> <fantasai> emilio: not device-pixel-ratio<br> <TabAtkins> yeah, you just walk the ancestor chain and multiple zoom values<br> <Rossen_> ack nicole<br> <fantasai> nicole: what about currentZoom, like currentColor<br> <matthieud> q+<br> <fantasai> emilio: I think I'd like currentCSSZoom, to differentiate from browser/viewport zoom<br> <fantasai> chrishtr: does "CSS" appear in other APIs?<br> <fantasai> TabAtkins: yes. bad ones<br> <bramus> q+<br> <Rossen_> ack matthieud<br> <fantasai> matthieud: If this isn't the used value, shouldn't we define what it is ?<br> <fantasai> chrishtr: Spec says it's the used value<br> <fantasai> emilio: It's not. Like if you nest transforms your used transform is just the one on your element.<br> <dholbert> fantasai (IRC): I agree with chris<br> <dholbert> fantasai (IRC): transforms don't collapse in the same way as zoom does<br> <dholbert> fantasai (IRC): this is like you're multiplying a bunch of numbers, and taking that final number and multiplying it by all the length values<br> <fantasai> dbaron: I think maybe used values round-trip, and this wouldn't round-trip<br> <fantasai> dbaron: there are some exceptions, but they should be weird<br> <Rossen_> q?<br> <fantasai> TabAtkins: Most, possibly all, places where we don't strictly round-trip will round-trip the second time<br> <fantasai> dholbert: current has a lot of temporal implications<br> <fantasai> dholbert: there's just currentColor which is weird<br> <dbaron> dbaron: though a counter migt be current transform matrix<br> <fantasai> dholbert: we also have currentTransformMatrix<br> <Rossen_> ack dbaron<br> <Zakim> dbaron, you wanted to comment about https://drafts.csswg.org/cssom-view-1/#the-geometryutils-interface<br> <fantasai> s/dholbert/dbaron/<br> <dbaron> https://drafts.csswg.org/cssom-view-1/#the-geometryutils-interface<br> <fantasai> dholbert: a bunch of the use cases you were talking about seem slightly related to this mostly-unimplemented section of CSSOM that maybe we shoudl think about implementing<br> <fantasai> s/dholbert/dbaron/<br> <fantasai> dbaron: roc proposed a decade ago<br> <fantasai> dbaron: Also, do the differences in coordinates here require flags in these interfaces?<br> <fantasai> emilio: I think box quads returns in client coordinates, so actual pixels not including zoom<br> <fantasai> chrishtr: it's same coordinate space as getBoundingClientRects<br> <dholbert> s/box quads/getBoxQuads/<br> <fantasai> emilio: depends what you mean by "include current zoom"...<br> <Rossen_> ack bramus<br> <fantasai> bramus: accumulatedCSSZoom<br> <fantasai> TabAtkins: Quick, Bramus, spell "accumulated", is it two "c"s, two "m"s?<br> <fantasai> TabAtkins: it's hard to spell even for native English speakers<br> <Rossen_> q?<br> <bramus> fair point<br> <emeyer> Seems like a great opportunity to teach a generation of coders how to spell the word!<br> <fantasai> abbreviate to aCSSZoom :)<br> <matthieud> renderedZoom() ? (is it 2 R ? )<br> <fantasai> Rossen_: Not hearing pushback on proposed behavior, good understanding of what we're exposing and where, just bikeshedding<br> <emilio> currentCSSZoom / effectiveCSSZoom?<br> <chrishtr> currentCSSZoom<br> <chrishtr> ccZoom<br> <bradk> zzzzZoooom<br> <fantasai> fantasai: lengthZoom, because it only multiplies lengths?<br> <dholbert> spelling-wise, CSS vs Css could be confusing<br> <dholbert> if this is a JS API<br> <dholbert> (authors might trip over currentCssZoom not working, maybe)<br> <dholbert> (but not an objection)<br> <fantasai> Rossen_: Let's call it currentCSSZoom and bikeshed it later<br> <emilio> PROPOSED: Accept the proposal for Element.prototype.currentCSSZoom<br> <fantasai> RESOLVED: Add Element.currentCSSZoom into CSSOM-view as proposed in #9809; bikeshed later as needed<br> <TabAtkins> (I don't remember where the style guide is that defines it, but it's definitely capital `CSS` in camel-case like this.)<br> <dbaron> https://www.w3.org/TR/design-principles/#casing-rules<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9809#issuecomment-1942836691 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 23:25:28 UTC