Meeting minutes
<emilio> If there's no other person I can scribe, but might have a baby interrupting
Administrivia
Rossen_: Anything to add/change?
Rossen_: Last week of December, proposing to skip the meeting due to holidays
Rossen_: Also sent an ask for topics / areas for a long call
Rossen_: so that we can reduce backlog of issues
https://
Rossen_: We'll add an extra hour before regular call on December 13th
Rossen_: December 6th will be APAC time
Zoom
[css-zoom?] Zoom and CSSOM
none
Where to spec zoom
chrishtr: IIRC we resolved to put into viewport spec, wanted to confirm
<Rossen_> w3c/
fantasai: Not sure what's state of device-adaptation, might need to rip stuff out, but that should be the right spec
[discussion of organizing info in the spec]
emilio: we moved device-adapt to viewport, and ripped out all the things we didn't want
Rossen_: will bring for review before next WD anyway
[css-zoom?] Zoom and CSSOM
emilio: Variety of things in current browsers consistently account for zoom
emilio: I think we have consensus that anything with a position and getComputedStyle shouldn't account for zoom
emilio: would like to resolve on that
<chrishtr> +1 to that proposed resolution
emilio: some smaller things like clientWidth can multiple zoom
emilio: my feeling is, the less APIs account for zoom the better
emilio: It seems getClientRect and ResizeObserver don't have a lot of compat constraints
chrishtr: My guess is compat restrictions are low
chrishtr: most users not using these APIs
Rossen_: starting with a more restricted set is easier to expand than the other way around
chrishtr: WebKit and Chromium both implement the undesired behavior that emilio wants to change in this resolution
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
emilio: if unzoomed size is 100px, and zoom is 2, gCS will return 100px to preserve round-tripping
RESOLUTION: getComputedStyle() returns unzoomed value
so that it round-trips
Rossen_: next, the rest of the APIs will return zoomed values
flackr: I think that makes sense for things like getBoundingClientRect
flackr: not so sure about offsetTop
flackr: typically those are used to position things within the same parent, which has the zoom applied
flackr: so maybe it should apply any zoom that exists on that element, but not the zoom all the way to the screen
emilio: problem is that positions cross zoom boundaries
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.
emilio: whatever you do, if it crosses the zoom boundary, it's going to be wrong for some use cases
emilio: so I'd like to not unzoom stuff that contains positions at all
flackr: so to make sure I understand, you're saying it'll apply all of the ancestor zooms
emilio: it would return unzoomed CSS px, depends what it's relative to
emilio: it would return zoom-independent CSS pixels, if that makes sense
emilio: we don't have that concept in the spec... but that's effectively the thing that gets stored in the computed style
flackr: same true of offsetWidth/Height ...
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...
emilio: if the position is relative to somehting with a different effective zoom, it's wrong either way
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.
emilio: Idk how you'd return sensible values if you're crossing a zoom boundary
emilio: returning unzoomed values is returning in a coordinate space that the whole page understands
flackr: My proposal would be that it returns in the element's own coordinate space
flackr: developer could determine what conversion is necessary if moving to a different space
flackr: but if e.g. applying to sibling with same ancestor zoom, can use the styles directly
flackr: e.g. set style.left = otherElementOffsetWidth
emilio: [missed]
flackr: [missed]
flackr: if multiplied by the zoom of the parent, but global zoom seems hard to work with
[flackr said something about how people write code with this]
Rossen_: [repeats Tab's comment about analogy with scale()]
Rossen_: seems like this needs more discussion?
flackr: I still have some concerns
emilio: can we resolve on things that return client rects [missed]
chrishtr: I agree that we should resolve on things that return client rects returning those in the physical pixel space, considering zoom
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?
chrishtr: I think this feature has direct value to developers, and we shouldn't consider a sad compat compromise
Rossen_: 100% agree
Rossen_: proposed resolution is, apply unzoomed value results to all bounding-box returning APIs
fantasai: this is the global coordinate system?
emilio: yeah. Let's call it global px values or something
Rossen_: page px values
RESOLUTION: APIs that return bounding boxes such as getClientRects and ResizeObserver and IntersectionObserver return values in page-global px unit coords
PaulG: I'm concerned, if a dev wants to assess if an element is covered or visibible in the viewport, will struggle with that
PaulG: if they get it wrong, has a11y impact
emilio: for that use case, what we just resolved on is what we want
PaulG: I think so too, will review with APA
chrishtr: Checking in on ResizeObserver, that returns offsetWidth-ish things?
chrishtr: should we exclude from resolution?
emilio: is content box relative to the element?
chrishtr: I think it is
RESOLUTION: s/ResizeObserver/getBoundingClientRect/
[css-zoom?] Zoom and inheritance.
emilio: This one is tricky
emilio: mostly due to the way zoom implemented, inheritance behaves really oddly
emilio: webkit and blink have a special case, if you apply zoom to an element
emilio: they zoom inherited font-size but not any other inherited property
emilio: seems the consensus is either zoom all the inherited lengths or we don't zoom any of them
emilio: I think it's clear that ideal behavior is zooming all inherited lengths
emilio: but I am worried, especially about perf cost, when you have lots of tiny elements with zoom
emilio: which I have seen in the wild while working on this
fantasai: [example of p { font-size: 10px; zoom: 2; } ]
fantasai: if inheriting unzoomed font-size, as soon as I put a SPAN in the paragraph, it will have 10px font-size
emilio: that works due to UA magic
emilio: what you inherit is 20px
emilio: if you have a span inside that has zoom as well
emilio: that will get font-size of 20px, instead of 40px as you expect
emilio: right now WebKit and Blink will zoom font-size correctly, but not e.g. line-height
emilio: that's messed up
emilio: so it's edge-casy but... on the other hand it's unfortunate that it doesn't work
emilio: I'd rather remove the font-size special case
emilio: no property does magic inherited value
emilio: I'd be fine with zooming every inherited length, just concerned about performance
Rossen_: Not understanding perf issue, let's make sure we have at least the right user-expected behavior before considering potential perf
Rossen_: prefer to measure and then discuss
Rossen_: I am unclear with your proposal what would happen to 'em' resolution
emilio: it has no effect from existing behavior
Rossen_: so if I have a 1em height, it'll be 40px or 20px or 10px?
emilio: it would be whatever the font-size is
Rossen_: what do we want to have, from user PoV
emilio: relative lengths reflect final zoomed font-size
Rossen_: I didn't want to make font-size exceptional here
emilio: that's my proposal
chrishtr: I feel like from the user point of view, making it apply to all inherited lengths makes sense
chrishtr: so I do think I would recommend resolving to do all inherited value
chrishtr: if during implementation we come up with an unaviodable perf problem, can discuss again
emilio: I'm ok with that
emilio: can we resolve in any case, don't make font-size special
RESOLUTION: font-size is not special wrt zoom
emilio: other issue with chrishtr's proposal to zoom all computed values is
emilio: you need to figure out what to do with all those, whether it's fine if those px values came from relative lengths
emilio: assuming fine, then seems fine
<dholbert> fantasai (IRC): relative lengths are all absolutized before they're inherited
<dholbert> fantasai (IRC): if your font size changes and you wanted ems, then you wanted ems and they'll get converted to absolute size
<dholbert> emilio (IRC): I think it's ok
<fantasai> PROPOSED: All computed lengths are zoomed when inheriting
fantasai (IRC): more precisely, when you absolutize a length to make a computed value, you apply a zoom. You have to undo that for getComputedStyle
fantasai (IRC): this is needed for animation to work
emilio (IRC): that's how impls work now
emilio (IRC): tricky thing is when you're inheriting into a thing with a different zoom
emilio (IRC): then you apply the zoom of the thing you're inheriting to on top, and that's this resolution
fantasai (IRC): that seems like the right thing to do
emilio (IRC): i agree from a user perspective. skeptical that we can make it fast but happy to try
chrishtr (IRC): proposed resln is all computed lengths, but we should exclude percentages
emilio (IRC): all computed absolute lengths, let's say
vmpstr (IRC): concretely, if I have width:100px and zoom:2 and a child that inherits that width, it would inherit 200px?
emilio (IRC): that already happens
emilio (IRC): the issue is when zoom is specified on the child. then what's the width of the child
emilio (IRC): with this resolution, it would be 200
<chrishtr> thanks!
RESOLUTION: All computed absolute lengths are zoomed when inheriting
<chrishtr> I don't see the resolution recorded in the issue yet?
[css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites
<chrishtr> ah fixed
<TabAtkins> w3c/
TabAtkins (IRC): this is an issue that crosses a few related issues
<TabAtkins> w3c/
TabAtkins (IRC): several years ago, we resolved that viewport units would not subtract the size of root scrollers' scrollbars, even when the page is explicitly overflow:scroll
TabAtkins (IRC): Obviously overflow:auto is cyclic and not usable
TabAtkins (IRC): But for overflow:scroll, due to impl complexity and various issues, we decided to not subtract that. That means width:100vw will overflow with overflow:scroll; you'll get horizontal scrollbars
TabAtkins (IRC): This makes authors confused and annoyed. Florian suggests we might want scrollbar-gutter to impact resolution of viewport units. If you know you're going to be reserving space so that a screen-filling element won't fill in that spot, presumably you want a 100vw element to fit in that width and not overflow
TabAtkins (IRC): But we need to be consistent. Want scrollbar-gutter and forced scrollbars to behave the same
TabAtkins (IRC): Can we revert the old issue? and have forced scrollbars on the root scroller subtracted when resolving 100vw,
TabAtkins (IRC): In webkit and chrome, the width of scrollbars is controllable via scrollbar pseudos. We'd ignore that since that produces another cyclic issue
TabAtkins (IRC): we'd subtract the default width of scrollbars
TabAtkins (IRC): authors continue to complain about useless horizontal scrollbars with 100vw or 99vw etc. Browser is refusing to subtract space that it knows something will never fill. Creates a problem for authors
emilio (IRC): two thigns. first: do you recall what's the status of propagation of scrollbar-gutter to the root
TabAtkins (IRC): not sure. I suspect we don't do additional propagation. try not to do propagation on new things
emilio (IRC): my gut feeling, as long as we make this dependent only on style of :root, not accounting for overflow propagation of the body, it's workable. not pretty, but workable
emilio (IRC): in general seems like it'd be nice to fix this. I agree it's unfortunate that it doesn't work
<chrishtr> "As for the overflow property, when scrollbar-gutter is set on the root element, the user agent must apply it to the viewport instead, and the used value on the root element itself is scrollbar-gutter: auto"
emilio (IRC): I'm skeptical of making it implicitly depend on the body's computed style, because then you end up with funny cycles
<chrishtr> https://
emilio (IRC): style container queries, etc. stuff gets messy real fast
emilio (IRC): the other thing: media queries right now resolve viewport units. We'd need to make sure we don't account for scrollbars in that case, or else it's trivially cyclic
TabAtkins (IRC): agreed. It'd work the same as font-size where it takes some initial value that disregards styles on the page
florian (IRC): not sure I understand impl complexity problems that came up last time. If those were in the way, are they in the way of scrollbar-gutter too?
emilio (IRC): main difference between scrollbar-gutter and overflow is the propagation stuff, impl-complexity wise
emilio (IRC): it was messy when gecko was trying to account for this with overflow propagation from body
<TabAtkins> "However, unlike the overflow property, the user agent must not propagate scrollbar-gutter from the HTML body element."
<TabAtkins> So yeah, overflow-gutter doesn't propagate
<emilio> great
florian (IRC): authors commonly depend on this. We can just tell them put it on the root directly, and I suppose that's a thing people can learn
<fantasai> +1 bramus
bramus (IRC): I want to underline what tab said; authors are really bitten by this. Longstanding problem, would be so helpful for authors
fantasai (IRC): proposed resolution is that we account for scrollbars when overflow is scroll on the root element directly, or when scrollbar-gutter is on the root element directly, and we don't handle propagation?
fantasai (IRC): i.e. we don't account for scrollbars propagated from body to root
<TabAtkins> proposed resolution: if overflow:scroll is set *on the root element* (not propagated from body), account for the default scrollbar width in the size of vw. Also take scrollbar-gutter (and scrollbar-width, the property with "normal" and "thin"?) into account on the root. Ignore all of these in MQs.
emilio (IRC): and should this account for scrollbar-width on the root (not the webkit scrollbar pseudos)
TabAtkins (IRC): my proposed rsln agrees with that, yeah
chrishtr (IRC): (talks through resolution)
chrishtr (IRC): this would apply to iframes?
TabAtkins (IRC): correct
bramus (IRC): not sure about scrollbar-gutter:stable scenario; then you reserve space on left edge as well
bramus (IRC): then you might get an overlay that doesn't paint on the left side despite 100vw
TabAtkins (IRC): that's what you're asking for if you use that value
florian (IRC): yup, that's what it does
<bramus> Screenshot: https://
florian (IRC): if you use "stable both", that is
chrishtr (IRC): but if you don't use "both", it just goes on the side where it normally appears
bramus (IRC): see screenshot. Then you can't paint something in the left there? your overlay won't be entirely overaying
TabAtkins (IRC): That's because you're explicitly asking for that space. width:100% won't fill that space either
TabAtkins (IRC): there are other ways to handle this.
emilio (IRC): fixed-pos would handle this too
fantasai (IRC): I see bramus's concern; you want your content to be inset away from the scrollers, but if you have an article with images every so often that should stretch the width of the screen, maybe you want them to cover the gutters
fantasai (IRC): you might need to set scrollbar-gutter on a more inner element to get that behavior
<chrishtr> or we could add another unit in the future if this situation is common
<TabAtkins> seriously, this is an explicit request from the author to not let them use that space
florian (IRC): auto scrollbars are weird. the traditional tradeoff is you get to use all the space, but layout is unstable. This gets you the reverse; stable layout, but you can't use all the space. Not amazing, but you have to pick
<emilio> +1 TabAtkins
bramus (IRC): maybe this is an edge case. I'm fine if we couldn't draw in that area
<fantasai> I think the issue here is that `scrollbar-gutter` only applies to scroll containers. If it applied to all elements, we could solve bramus's problem cleanly
<TabAtkins> you can absolutely fill that area with multiple methods, just something placed via normal flow with a 100vw (or 100%) width won't fill it
emilio (IRC): do we need viewport units, when used on the root, not to account for the scrollbars?
emilio (IRC): generally we wouldn't need this restriction, with new fancy calc and stuff, it seems like it might not be needed?
emilio (IRC): similar to root em units and root line height; we avoid them introducing a dependency...
TabAtkins (IRC): giving access to full viewport width, ignoring scrollbars
emilio (IRC): does that need to be the behavior to avoid cycles? The properties we're depending on are only keywords, which is ~fine, but I'm not sure if you can introduce a weird dependency with calc
miriam (IRC): some truth to if you set 'stable' you're asking not to use that space
miriam (IRC): this is why people in the threads keep asking for a gutter-end variable, so you can choose which one and use the space if you want
florian (IRC): so the variable would be the gutter size? right
bramus (IRC): you could use it to see if the scrollbar is there... an automatic solution here is way better
TabAtkins (IRC): let's not let the perfect be the enemy of the good. Don't design for the corner case of 'both always'
<bramus> +1 to what tab just said.
<miriam> +1
TabAtkins (IRC): can we resolve here and handle this corner case in another issue
<TabAtkins> proposed resolution: if overflow:scroll is set *on the root element* (not propagated from body), account for the default scrollbar width in the size of vw. Also take scrollbar-gutter (and scrollbar-width, the property with "normal" and "thin"?) into account on the root. Ignore all of these in MQs, and maybe also on the root element (we'll see).
fantasai (IRC): as an issue in the scrollbar spec maybe
Rossen_ (IRC): and the 'both always' issue will be an open issue
emilio (IRC): can we include "...and also ignore all of these when using vw units on the root element, if necessary"
Rossen_ (IRC): objections?
<chrishtr> great! developers will be thrilled
<TabAtkins> And note: explicitly reversing the resolution from 1766
RESOLUTION: if overflow:scroll is set on the root element (not propagated from body), account for the default scrollbar width in the size of vw. Also take scrollbar-gutter (and scrollbar-width, the property with "normal" and "thin"?) into account on the root. Ignore all of these in MQs. and also ignore all of these when using vw/vh units on the root element, if necessary
Rossen_ (IRC): look for topics for long call please
TabAtkins (IRC): meeting: Feb 12-14, in MV, on Google Campus