[CSSWG] Minutes Telecon 2023-11-29 [css-zoom] [css-viewport] [css-values]

  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 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
  - 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)


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Nov/0007.html

  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


  Rossen: Anything to add/change?
  Rossen: Last week of December, proposing to skip the meeting due to
  Rossen: Also sent an ask for topics / areas for a long call
  Rossen: so that we can reduce backlog of issues
  <fantasai> ->
  Rossen: We'll add an extra hour before regular call on December 13th
  Rossen: December 6th will be APAC time


Where to spec zoom

  chrishtr: IIRC we resolved to put into viewport spec, wanted to
  <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

  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
  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
  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
  emilio: They zoom inherited font-size but not any other inherited
  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'
  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
  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
  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
  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
  <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:
  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
  <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