- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 29 Nov 2023 19:33:16 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Zoom
----
- Zoom will be specified in the Viewport spec
- RESOLVED: getComputedStyle() returns unzoomed value so that it
round-trips (Issue #9398: Zoom and CSSOM)
- RESOLVED: APIs that return bounding boxes such as getClientRects
and getBoundingClientRect and IntersectionObserver return
values in page-global px unit coords (Issue #9398)
- RESOLVED: font-size is not special wrt zoom (Issue #9397: Zoom and
inheritance)
- RESOLVED: All computed absolute lengths are zoomed when inheriting
(Issue #9397)
CSS Values
----------
- RESOLVED: 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 (Issue #6026: Use of 100vw is
causing pointless horizontal scrollbars on some websites)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Nov/0007.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Jonathan Kew
Vladimir Levin
Chris Lilley
Peter Linss
Alison Maher
Florian Rivoal
Alan Stearns
Brandon Stewart
Miriam Suzanne
Bramus Van Damme
Lea Verou
Sebastian Zartner
Chair: Rossen
Scribe: fantasai
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
<fantasai> ->
https://lists.w3.org/Archives/Member/w3c-css-wg/2023OctDec/0094.html
Rossen: We'll add an extra hour before regular call on December 13th
Rossen: December 6th will be APAC time
Zoom
====
Where to spec zoom
------------------
chrishtr: IIRC we resolved to put into viewport spec, wanted to
confirm
<Rossen> https://github.com/w3c/csswg-drafts/issues/5623#issuecomment-1646125737
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
Zoom and CSSOM
--------------
github: https://github.com/w3c/csswg-drafts/issues/9398
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
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
RESOLVED: 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
emilio: If the position is relative to something 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> I think the general point is that people shouldn't be
using zoom anyway...
<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]
<vmpstr> can we think of good terminology for these spaces?
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.
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
RESOLVED: 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 visible 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
RESOLVED: s/ResizeObserver/getBoundingClientRect/
Zoom and inheritance
--------------------
github: https://github.com/w3c/csswg-drafts/issues/9397
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
*fantasai agrees with not having an exception for font-size
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 unavoidable
perf problem, can discuss again
emilio: I'm ok with that
emilio: Can we resolve in any case, don't make font-size special
RESOLVED: font-size is not special wrt zoom
scribe: dholbert
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
fantasai: Relative lengths are all absolutized before they're
inherited
fantasai: If your font size changes and you wanted ems, then you
wanted ems and they'll get converted to absolute size
emilio: I think it's ok
<fantasai> PROPOSED: All computed lengths are zoomed when inheriting
fantasai: More precisely, when you absolutize a length to make a
computed value, you apply a zoom. You have to undo that for
getComputedStyle
fantasai: This is needed for animation to work
emilio: That's how impls work now
emilio: Tricky thing is when you're inheriting into a thing with a
different zoom
emilio: then you apply the zoom of the thing you're inheriting to on
top, and that's this resolution
fantasai: That seems like the right thing to do
emilio: I agree from a user perspective. skeptical that we can make
it fast but happy to try
chrishtr: Proposed resolution is all computed lengths, but we should
exclude percentages
emilio: All computed absolute lengths, let's say
vmpstr: Concretely, if I have width:100px and zoom:2 and a child that
inherits that width, it would inherit 200px?
emilio: That already happens
emilio: The issue is when zoom is specified on the child. then what's
the width of the child
emilio: with this resolution, it would be 200
RESOLVED: All computed absolute lengths are zoomed when inheriting
CSS Values
==========
Use of 100vw is causing pointless horizontal scrollbars on some
websites
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6026
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/5254
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1766
TabAtkins: This is an issue that crosses a few related issues
TabAtkins: 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: Obviously overflow:auto is cyclic and not usable
TabAtkins: 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: 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: But we need to be consistent. Want scrollbar-gutter and
forced scrollbars to behave the same
TabAtkins: Can we revert the old issue? And have forced scrollbars on
the root scroller subtracted when resolving 100vw,
TabAtkins: In webkit and chrome, the width of scrollbars is
controllable via scrollbar pseudos. We'd ignore that since
that produces another cyclic issue
TabAtkins: We'd subtract the default width of scrollbars
TabAtkins: 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: Two things. First: do you recall what's the status of
propagation of scrollbar-gutter to the root
TabAtkins: Not sure. I suspect we don't do additional propagation.
Try not to do propagation on new things
emilio: 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: In general seems like it'd be nice to fix this. I agree it's
unfortunate that it doesn't work
emilio: I'm skeptical of making it implicitly depend on the body's
computed style, because then you end up with funny cycles
emilio: style container queries, etc. stuff gets messy real fast
emilio: 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: Agreed. It'd work the same as font-size where it takes
some initial value that disregards styles on the page
<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"
<chrishtr> https://drafts.csswg.org/css-overflow/#scrollbar-gutter-property
florian: 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: Main difference between scrollbar-gutter and overflow is the
propagation stuff, impl-complexity wise
emilio: It was messy when gecko was trying to account for this with
overflow propagation from body
florian: 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
<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
bramus: I want to underline what Tab said; authors are really bitten
by this. Longstanding problem, would be so helpful for authors
<fantasai> +1 bramus
fantasai: 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: i.e. we don't account for scrollbars propagated from body
to root
emilio: and should this account for scrollbar-width on the root (not
the webkit scrollbar pseudos)
<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.
<fantasai> nice, TabAtkins
TabAtkins: My proposed resolution agrees with that, yeah
chrishtr: (talks through resolution)
chrishtr: This would apply to iframes?
TabAtkins: Correct
bramus: Not sure about scrollbar-gutter:stable scenario; then you
reserve space on left edge as well
bramus: then you might get an overlay that doesn't paint on the left
side despite 100vw
TabAtkins: That's what you're asking for if you use that value
florian: Yup, that's what it does
florian: if you use "stable both", that is
<bramus> Screenshot:
https://user-images.githubusercontent.com/213073/202724538-b20f14bd-489e-4e6f-a9df-519d4a11e617.png
chrishtr: But if you don't use "both", it just goes on the side where
it normally appears
bramus: See screenshot. Then you can't paint something in the left
there? your overlay won't be entirely overaying
TabAtkins: That's because you're explicitly asking for that space.
width:100% won't fill that space either
TabAtkins: there are other ways to handle this.
emilio: fixed-pos would handle this too
fantasai: 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: 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
<emilio> +1 TabAtkins
florian: 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
bramus: 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: Do we need viewport units, when used on the root, not to
account for the scrollbars?
emilio: Generally we wouldn't need this restriction, with new fancy
calc and stuff, it seems like it might not be needed?
emilio: Similar to root em units and root line height; we avoid them
introducing a dependency...
TabAtkins: Giving access to full viewport width, ignoring scrollbars
emilio: 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: Some truth to if you set 'stable' you're asking not to use
that space
miriam: 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: So the variable would be the gutter size? right
bramus: You could use it to see if the scrollbar is there... an
automatic solution here is way better
TabAtkins: 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: 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: As an issue in the scrollbar spec maybe
Rossen: And the 'both always' issue will be an open issue
emilio: Can we include "...and also ignore all of these when using vw
units on the root element, if necessary"
Rossen: Objections?
<chrishtr> great! developers will be thrilled
<TabAtkins> And note: explicitly reversing the resolution from 1766
RESOLVED: 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
<tantek> TabAtkins++ nicely done
Rossen: Look for topics for long call please
TabAtkins: Meeting: Feb 12-14, in MV, on Google Campus
Received on Thursday, 30 November 2023 00:33:50 UTC