[css-viewport] [cssom] [css-typed-om] Consider adding a way of exposing the effective zoom.

[emilio]

Without it, translating global to scaled coordinates is error prone (have to walk the DOM tree upwards multiplying getComputedStyle(el).zoom).

My preference would be a member in the computed CSSStyleDeclaration (might need a CSSComputedStyleDeclaration?) for simplicity, and / or in the computedPropertyMap (which IIUC would also need a new interface), but happy to hear other alternatives, maybe just Element.prototype.effectiveZoom or such.

Thoughts?

cc @saschanaz @chrishtr @tabatkins

[Loirooriol]

Would this be settable?

[emilio]

I don't see a reason to make it settable, a readonly attribute would work.

[chrishtr]

Sounds fine to me.

[css-meeting-bot]

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

The full IRC log of that discussion

<fantasai> emilio: while prototyping zoom, the effective zoom is trivially accessible to the engine
<fantasai> emilio: but there's no way as an author to compute it, other than walking the entire ancestor chain
<fantasai> emilio: but you often need it for JS interactions
<fantasai> emilio: Does it seem fine to expose it?
<fantasai> emilio: if it seems fine, where do we expose it?
<fantasai> emilio: maybe just in Element is fine?
<fantasai> emilio: could put it in CSSComputedStyleDeclaration but we'd need a separate interface
<fantasai> emilio: already have the computed value of zoom
<bramus> q+
<fantasai> emilio: so maybe effectiveZoom? But not a page zoom so effectiveCSSZoom?
<TabAtkins> q+
<Rossen_> ack bramus
<fantasai> bramus: I like not exposing through getComputedStyle because that would be confusing
<fantasai> bramus: so other property seems reasonable to me
<Rossen_> ack fantasai
<TabAtkins> fantasai: would it make sense to call it "usedZoom"?
<fantasai> fantasai: isn't it the used zoom value?
<dholbert> TabAtkins (IRC): it's not the used value, it's the collective value from all the ancestors
<dholbert> fantasai (IRC): it's different from the computed value?
<dholbert> emilio (IRC): it's also different from the zoom property value
<dholbert> TabAtkins (IRC): we don't usually do that with used value. You could make the same argument about transform
<dholbert> TabAtkins (IRC): transforms accumulate, but we don't expose that in this way
<chrishtr> +1 to effectiveZoom on Element
<Rossen_> ack TabAtkins
<fantasai> TabAtkins: Do you have an example of how you would use this?
<fantasai> emilio: [gives an example]
<fantasai> emilio: to compare them you need to multiply by effective Zoom
<schenney> q+
<nicole> q+
<fantasai> emilio: it's the way to convert between local coordinate and global coordinate
<fantasai> TabAtkins: ok
<fantasai> emilio: same for scroll positions. scrollTop is in the local space
<fantasai> emilio: There's a lot of APIs that use local space, and some in global. To convert between them you need something
<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
<Rossen_> ack schenney
<fantasai> schenney: in Chrome, would device scale factor be included?
<fantasai> emilio: no, you only want the effective zoom property
<fantasai> emilio: not device-pixel-ratio
<TabAtkins> yeah, you just walk the ancestor chain and multiple zoom values
<Rossen_> ack nicole
<fantasai> nicole: what about currentZoom, like currentColor
<matthieud> q+
<fantasai> emilio: I think I'd like currentCSSZoom, to differentiate from browser/viewport zoom
<fantasai> chrishtr: does "CSS" appear in other APIs?
<fantasai> TabAtkins: yes. bad ones
<bramus> q+
<Rossen_> ack matthieud
<fantasai> matthieud: If this isn't the used value, shouldn't we define what it is ?
<fantasai> chrishtr: Spec says it's the used value
<fantasai> emilio: It's not. Like if you nest transforms your used transform is just the one on your element.
<dholbert> fantasai (IRC): I agree with chris
<dholbert> fantasai (IRC): transforms don't collapse in the same way as zoom does
<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
<fantasai> dbaron: I think maybe used values round-trip, and this wouldn't round-trip
<fantasai> dbaron: there are some exceptions, but they should be weird
<Rossen_> q?
<fantasai> TabAtkins: Most, possibly all, places where we don't strictly round-trip will round-trip the second time
<fantasai> dholbert: current has a lot of temporal implications
<fantasai> dholbert: there's just currentColor which is weird
<dbaron> dbaron: though a counter migt be current transform matrix
<fantasai> dholbert: we also have currentTransformMatrix
<Rossen_> ack dbaron
<Zakim> dbaron, you wanted to comment about https://drafts.csswg.org/cssom-view-1/#the-geometryutils-interface
<fantasai> s/dholbert/dbaron/
<dbaron> https://drafts.csswg.org/cssom-view-1/#the-geometryutils-interface
<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
<fantasai> s/dholbert/dbaron/
<fantasai> dbaron: roc proposed a decade ago
<fantasai> dbaron: Also, do the differences in coordinates here require flags in these interfaces?
<fantasai> emilio: I think box quads returns in client coordinates, so actual pixels not including zoom
<fantasai> chrishtr: it's same coordinate space as getBoundingClientRects
<dholbert> s/box quads/getBoxQuads/
<fantasai> emilio: depends what you mean by "include current zoom"...
<Rossen_> ack bramus
<fantasai> bramus: accumulatedCSSZoom
<fantasai> TabAtkins: Quick, Bramus, spell "accumulated", is it two "c"s, two "m"s?
<fantasai> TabAtkins: it's hard to spell even for native English speakers
<Rossen_> q?
<bramus> fair point
<emeyer> Seems like a great opportunity to teach a generation of coders how to spell the word!
<fantasai> abbreviate to aCSSZoom :)
<matthieud> renderedZoom() ? (is it 2 R ? )
<fantasai> Rossen_: Not hearing pushback on proposed behavior, good understanding of what we're exposing and where, just bikeshedding
<emilio> currentCSSZoom / effectiveCSSZoom?
<chrishtr> currentCSSZoom
<chrishtr> ccZoom
<bradk> zzzzZoooom
<fantasai> fantasai: lengthZoom, because it only multiplies lengths?
<dholbert> spelling-wise, �CSS� vs �Css� could be confusing
<dholbert> if this is a JS API
<dholbert> (authors might trip over �currentCssZoom� not working, maybe)
<dholbert> (but not an objection)
<fantasai> Rossen_: Let's call it currentCSSZoom and bikeshed it later
<emilio> PROPOSED: Accept the proposal for Element.prototype.currentCSSZoom
<fantasai> RESOLVED: Add Element.currentCSSZoom into CSSOM-view as proposed in #9809; bikeshed later as needed
<TabAtkins> (I don't remember where the style guide is that defines it, but it's definitely capital `CSS` in camel-case like this.)
<dbaron> https://www.w3.org/TR/design-principles/#casing-rules