W3C home > Mailing lists > Public > www-style@w3.org > August 2021

[CSSWG] Virtual F2F 2021-07-29 Part I: CSS Scrollbars, CSS Overflow [css-scrollbars] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 16 Aug 2021 18:16:20 -0400
Message-ID: <CADhPm3tNivHAa66QNtgMDAkArzHBoTg9SiZ5jdRcV8-epStfwg@mail.gmail.com>
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.
=========================================


CSS Scrollbars
--------------

  - RESOLVED: With acknowledgement of the use-case, we still reject
              exposing a large set of pseudos for scrollbars
              (webkit-prefixed or otherwise) (Issue #1969: Real-world
              scrollbar usage)
  - RESOLVED: No change, happy to have discussion continue in-thread or
              elsewhere [for inclusion in a future level] (Issue #2252:
              Is it possible to have a position: sticky horizontal
              scrollbar?)
  - RESOLVED: Close no change (Issue #6351: Add `wide` value to
              `scrollbar-width`)
  - RESOLVED: Publish new WD of Scrollbars, issue call for comments

CSS Overflow
------------

  - RESOLVED: Go with Firefox's behavior - no elements cause the scroll
              container's inline-end padding to be used (Issue #129:
              Clarify padding-bottom in overflow content)
  - The suggestion to address the multiple scrollbar issue in #5403 (Is
      it necessary to support nested scrollers for html and body?) is a
      good one, however it seems to be a high risk change with a lower
      value to authors so the group will not act on the suggested
      change.
  - RESOLVED: Move scroll-behavior from cssom-view to css-overflow-3
              (Issue #6482: Move scroll-behavior from cssom-view)
  - RESOLVED: Accept the Note [overflow:hidden on the root might not
              clip everything outside the ICB if the ICB is smaller
              than the viewport, which can happen on mobile]. (Issue
              #5646: Clarify what rect clips the root element with
              overflow:hidden on mobile environments with dynamic
              toolbar)

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/20

Present:
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  L David Baron
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  David Grogan
  Daniel Holbert
  Daniel Libby
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Myles Maxfield
  Cameron McCormack
  Cassondra Roberts
  Jen Simmons
  Alan Stearns

Scribe: TabAtkins
Scribe's scribe: fantasai

CSS Scrollbars
==============

Real-world scrollbar usage
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1969

  florian: At a high level, both these issues [#1969 & #2153] are
           looking at what's in Scrollbars and saying "controlling width
           /color is nice, but we want way more, can we have a bunch of
           pseudos to control things"
  florian: Precisely how they justify it is a little different, the
           exact set they're asking for is a little different
  florian: One is following the existing webkit pseudos, the other isn't
  florian: But both are complaining they're too simple and they want
           access to the deep structure
  florian: I believe we've already resolved not to do this, for several
           reasons
  florian: Not least that scrollbars are UI and OSes want control over
           this
  florian: And OSes have different scrollbar structures, so one way of
           exposing won't work right for another
  florian: So we've rejected in the past for these reasons
  florian: I suggest doing so again
  florian: We have an intro in the spec explaining why we're not doing
           this
  florian: fantasai and I are iterating on it a little
  florian: But preferred action is making the intro clearer as to why
           we're rejecting, then close as WONTFIX
  <emilio> +1
  <castastrophe> +1 to wontfix
  <smfr> +1 in support of what florian proposed
  florian: Counter-argument is that if we do this, we might end up with
           authors not using scrollbar properties at all, and instead
           using JS scrolling, which is less accessible
  florian: But still I think the right way is to close and hope that
           OpenUI helps us with advanced use-cases
  <TabAtkins> +1

  fantasai: If we're deciding not to fix this, but webkit continues to
            ship the pseudos, does that mean we'll eventually need to
            spec those anyway? or is webkit planning to remove?
  smfr: webkit is phasing them out - we don't support them on iOS
  smfr: And generally slowly removing webkit-prefixed things. At some
        point in the future these'll probably go away

  astearns: Wonder if we're not quite closing wontfix, but "wontfix now"
  astearns: Argument is that people will adopt these properties, and
            won't see a boost in the number of custom scrollbars
  astearns: If in the future we see that happening, we can revisit. So
            slightly moderated response

  emilio: We haven't gotten any compat reports about webkit scrollbars
          for quite a while.
  emilio: Pages use them, but for now Firefox hasn't gotten compat
          issues

  florian: Back to astearns's point, the use-case of having *some*
           control over scrollbars isn't being ignored; we're taking
           steps toward that
  florian: The idea of a whole pile of pseudos is being rejected
  florian: The idea of doing more than today isn't rejected; we're
           pretty sure that a bunch of pseudos will never be workable,
           though
  <astearns> +1
  florian: I neither want to make these people believe we're rejecting
           their use-case, nor let them believe if they push a little
           more we'll relent

  smfr: emilio said firefox hasn't had compat reports about not
        implementing, but a lot of Google properties are using custom
        scrollbars
  smfr: Would like info from Chrome people about why they're still
        used, if it's not important on Firefox
  emilio: They use the scrollbar-color as well
  smfr: Ah, good. They currently show the scrollbars always next to
        videos on safari, which looks quite bad.

  emilio: Note that a bunch of pseudos has some performance
          implications. We have some internal pseudos that we use, but
          we'd like to stop that, too.

  Rossen: So it sounds like the path forward is to acknowledge the
          use-case, but this isn't the path to pursue
  Rossen: Looks like a lot of +1s in chat for that
  Rossen: Anything else?
  Rossen: Objections?

  RESOLVED: With acknowledgement of the use-case, we still reject
            exposing a large set of pseudos for scrollbars
            (webkit-prefixed or otherwise)

Is it possible to have a position: sticky horizontal scrollbar?
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2252

  florian: Suggested solution is probably wrong, but use-case is
           interesting
  florian: Say in middle of a scrollable document, you have a large
           scrollable element (larger than screen)
  florian: The scrollbar for the element might be off-screen
  florian: So you can't scroll it or even notice it's scrollable maybe
  florian: Suggestion is to make the scrollbar sticky somehow, so it
           sticks to the edge of the screen
  florian: If a UA wanted to have an overlay scrollbar that did this, I
           don't think we ban this currently, so maybe it's just a
           quality of implementation
  florian: But we haven't seen any UA attempts in that direction. So if
           we're not solving this, how are we letting authors solve it
           themselves?
  florian: Don't have an answer yet

  smfr: We talked about this a few days ago, any new info?
  florian: 8 days ago the clock ran out
  florian: Roughly, do we expect this'll be solved by UAs? Will we give
           tools to authors? Or not address it?
  smfr: I think I said this would be hard to be QoI, because would be
        hard for UAs to know when they're sticky
  smfr: But since they don't have boxes, authors couldn't directly
        style scrollbars either
  smfr: would have to invent new primitives

  dbaron: Other hard thing is the bounds of the sticky area
  dbaron: Probably don't want the sticky scrollbar right next to the
          other scrollbar - don't want it right next to the other
          scrollbar
  dbaron: positioning seems context-dependent
  florian: Should we state that we're open to specific suggestions?
  florian: And since scrollbars aren't boxes, I presume not a selector,
           but rather a property to make them do the right magic?

  smfr: off-the-cuff suggestion last time was a proxy scrollbar you
        could just make and tie it to scrolling a box
  fantasai: Wouldn't the obvious container be the scroll container?
  fantasai: You don't want it outside the scroll container
  <emilio> `scrollbar-position: auto | sticky <margin>?` or something?
  dbaron: With sticky there's multiple bounds, I think I'm thinking
          about another set
  dbaron: Say horizontal scrollbar on a large table that's partially
          scrolled off
  dbaron: You want it to be on the bottom of the table but sticky to
          the screen
  dbaron: If the whole page has a horizontal scrollbar, you might not
          want these next to each other
  dbaron: Might want a slight separation
  dbaron: Two scrollbars adjacent to each other is generally bad, and
          this makes that easier to do
  florian: Also if your scroller is bigger in both dimensions, when you
           float it in it's still bigger; if they both float do they
           cross? dunno

  emilio: Any platform with a primitive like this?
  Rossen: Outside of panning, don't know of any
  Rossen: but outside of that, not sure what it means to have the ui
          primitive magically show up when you need it
  Rossen: So the magic seems the bottom of the problem so far
  florian: Possibly something to have a community iterate on proposals
           and then come back
  Rossen: To emilio's point, we don't know of native platforms that
          solve this in a graceful way today
  Rossen: And that's usually where these start
  Rossen: behaviors catch on from there
  Rossen: I'm more aligned with smfr here to just say "show us prior
          art" so we don't end up breaking things
  <emilio> +1 to Rossen

  TabAtkins: Sounds reasonable to just close this down no change right
             now, and let conversation continue if it comes up with
             something
  Rossen: Yeah don't want to disparage the use-case
  dholbert: Maybe suggest to the OP to make sure that approaches make
            sense if things are nested multiple deep
  dholbert: Want to make sure they stack in a coherent way
  Rossen: Right, there's so many questions in this user interaction,
          I'm not gonna guess yet
  flackr: Is this possibly something scrollbar customization might let
          you do?
  Rossen: [repeating]
  Rossen: Objections?

  RESOLVED: No change, happy to have discussion continue in-thread or
            elsewhere

  florian: Leaving issue open so people can have good ideas
  fantasai: So marking as deferred for this level then

Add `wide` value to `scrollbar-width`
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6351

  fantasai: There was an issue where the commenter was unsatisfied
  fantasai: Request was for an explicit "wide" value for scrollbar-width
  fantasai: Argument was that people want wider scrollbars for a11y
            reasons
  fantasai: florian said that's a good reason for a UA control, not an
            author control
  fantasai: Commenter responded the author may know more about their
            audience. That's where we ended
  fantasai: So what does the WG want?
  TabAtkins: I agree with Florian's reasoning
  <florian> https://github.com/w3c/csswg-drafts/issues/6351#issuecomment-877496097
  TabAtkins: which fantasai just summarized
  TabAtkins: The needs for wide is something that can be controlled at
             the UA level
  TabAtkins: Whereas need for narrow is depending on the content on the
             page, might be a small element
  florian: Also commenter said "just because I don't have a use-case
           doesn't mean there's not one somewhere", but we don't
           usually add features without a known use-case
  Rossen: Objections?

  RESOLVED: Close no change

Publication
-----------

  fantasai: At this point we have no open issues besides some minor
            editorial work
  fantasai: So I think we'll start horizontal review before CR, if
            anyone has concerns let us know
  florian: Do we want an explicit resolution for WD?

  RESOLVED: Publish new WD of Scrollbars, issue call for comments

CSS Overflow
============

Clarify padding-bottom in overflow content
------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/129

  <fantasai> https://github.com/w3c/csswg-drafts/issues/129#issuecomment-887901550
  florian: We've been working for a while on what does and doesn't
           count as scrollable overflow
  florian: This is one of few remaining
  florian: When you have an inline that pokes out of the scrollable area
  florian: For most things that poke out, you add the scroll
           container's padding at the end edge, so when you scroll all
           the way you still have padding between the poking thing and
           the scrollbar
  florian: but in this case, in the inline case, there's not interop
  florian: In firefox if your inline pokes out in the inline direction,
           firefox doesn't add padding
  florian: Chrome and WebKit do *some* of the time
  florian: Clarification: in the inline direction, in firefox, whether
           it's an inline or block poking out doesn't matter; it
           doesn't get padding
  florian: For chrome/webkit, if a block pokes out in the inline
           direction it does not get padding
  florian: For inlines poking out in the inline direction, it gets
           padding if it's a direct child of the scroll container, but
           not if it's nested
  florian: So initial though is that 'padding' means you want it, so
           having as much padding as we can is nice
  florian: But also if we start adding padding where we didn't before,
           we're likely to make scrollbars that don't exist right now
           start to exist
  florian: And that usually makes authors unhappy
  florian: So "as much padding as we can get" is probably what we have
           today

  florian: Was initially tempted to spec chrome/webkit behavior, but
           it's too weird
  florian: So even though I think we should have padding, I think we're
           compat constrained. We should pick something reasonable,
           which means Firefox's behavior
  emilio: I agree.
  <fantasai> testcase:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/9521

  emilio: Curiosity question - do chrome/webkit use layouttree parent,
          or dom parent? does shadow dom matter?
  florian: [shrugs]
  emilio: Yeah exactly. I'm in favor of something simple

  Rossen: Thoughts?
  TabAtkins: Other than agreeing with Florian that we should have had
             padding, I think his current idea is good
  <flackr> +1
  myles: Reason we implemented this originally was we wanted visual
         area to look more symmetrical
  myles: I think the resolution would stop that?
  myles: If you scroll down you're likely to get something not matching
         the top?
  fantasai: The block axis already respects padding, this is for the
            inline axis
  fantasai: We also resolved earlier that if you set justify-content to
            anything not 'normal', we apply the padding
  fantasai: So there's an opt-in in the spec
  florian: Right, forgot to mention that. This is only for
           justify-content:normal
  <argyle> made this when i learned about this
https://codepen.io/argyleink/pen/vYNYVOB
  myles: The reason we didn't do it in inline axis was it was
         inconvenient to implement in the beginning. wasn't an
         intentional design choice. horizontal scrollbars are fairly
         rare anyway

  RESOLVED: Go with Firefox's behavior - no elements cause the scroll
            container's inline-end padding to be used

  <br dur=10min>

Is it necessary to support nested scrollers for html and body?
--------------------------------------------------------------
  scribe: fantasai
  github: https://github.com/w3c/csswg-drafts/issues/5403

  florian: If html has a value other than visible, we propagate that
  florian: If it's visible, we propagate from body
  florian: If both are scrollable, we get two scrollbars
  florian: Person filing issue suggests that's not very helpful
  florian: Maybe it's better to just accept one of these two values,
           whichever is not visible
  florian: but the current behavior has been interop for a long time
  florian: so there's a compat risk to changing
  <smfr> +1 to worry about the compat risk
  florian: Question is to ask WG whether it wants to try to make such a
           change
  TabAtkins: Do we have usage numbers on overflow on both html and body?
  florian: Optimistically, might be possible
  florian: but would have to fetch data to prove it

  TabAtkins: I can't see any way for the page to be depending on this
  TabAtkins: What content would you put outside the body?
  florian: Maybe ::before/::after
  florian: or maybe multiple bodies
  TabAtkins: Can't do that due to HTML parser, unless you're injecting
             via script

  <heycam> also doesn't seem like a big enough simplification to
           warrant the risk
  <astearns> +1 heycam
  emilio: Agree with heycam that this doesn't seem hard, but it's not
          much of a simplification
  emilio: if it helps authors, maybe then worth doing
  emilio: Case of overflow:auto on the root and overflow:hidden on the
          body to clip that... maybe not very useful
  <dbaron> I think Tab was talking about Chromium's
           kBodyScrollsInAdditionToViewport use counter.
  <dbaron> yeah, the code for that use counter looks wrong

  Rossen: I'm hearing most people align with worry of compat risks
  Rossen: compared to minimum benefit that we get
  Rossen: We can close this as by design for now, and if anyone wants
          to fetch data to show that this design is bad and it is easy
          and low-risk to change
  Rossen: Without that data, seems high risk for low benefit
  fantasai: This seems like a good idea, but since we have interop on
            current behavior and it's not too bad, don't think it's
            worth the opportunity cost of implementing the change
            even if it doesn't cause webcompat issues

Move scroll-behavior from cssom-view
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6482

  florian: We realized that CSSOM-view doesn't only contain OM stuff,
           but a property definition... that relates to overflow
  florian: So maybe that property should be moved to the overflow spec
  florian: is scroll-behavior property
  florian: Putting in OM spec makes not very discoverable
  Rossen: Seems like a righteous and easy resolution
  Rossen: Any objections?

  RESOLVED: Move scroll-behavior from cssom-view to css-overflow-3

  florian: Just want to note that we have both scroll-behavior and
           overscroll-behavior, maybe not ideal
  myles: wfm

Clarify what rect clips the root element with overflow:hidden on
    mobile environments with dynamic toolbar
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5646
  scribe: TabAtkins

  <fantasai> https://hiikezoe.github.io/overflow-clip-on-root.html
  fantasai: There's a testcase which makes this clearer...
  fantasai: On mobile when we have dynamic toolbars there's a small and
            large viewport
  fantasai: the ICB, the size of the document when it's height:100%, is
            the small viewport size
  fantasai: But when the content retracts you see more than that
  fantasai: This isn't interesting for long scrollable docs
  fantasai: But if it's overflow:hidden and you're expecting a clipped
            rectangle equal to the ICB (so stuff outside the rect isn't
            visible), but it is indeed visible in these cases
  fantasai: If you load it in a mobile browser, there's a red bar below
            the ICB. Can't see it in desktop browsers, but it's visible
            in all mobiles when the UI retracts
  fantasai: So since we have compat, do we need to spec this?
  fantasai: Or do we have concerns?

  florian: I think it's weird, but it's interoperable
  fantasai: And I also can't think of a better idea
  fantasai: I suppose you could clip the content but extend the canvas
            area...?
  Rossen: Thoughts?
  TabAtkins: Since we don't have a better idea, and it's interop
             already, suggest we go for it
  Rossen: Proposed resolution?
  Proposed resolution: the ICB is the small viewport, but the viewport
      clip rectangle is the large viewport
  Rossen: So if I have position:fixed with bottom:0, and I zoom out,
          will it stick to the viewport or not?
  flackr: In impls it does
  flackr: But it sounds like that would disagree with the spec
  emilio: Can we resolve on aligning to the interoperable bits?
  emilio: And figure out exactly what those bits are?
  florian: That's what we tried to do; seems we failed to consider
           zooming
  Rossen: Yeah that's where ICB and visual vs layout viewports make the
          most difference

  Rossen: Given decent interop, I suggest diving into details and
          documenting the status quo better, rather than resolving now
  florian: So if we just talk about the clipping of overflow:hidden
           using the large viewport - is that incompatible with reality?
  Rossen: It would be inconsistent with what I said about
          position:sticky to the bottom
  Rossen: Spec'll stick it to the ICB bottom, if I zoom it *currently*
          sticks to the screen bottom
  fantasai: Florian's just talking about the clip rectangle, not the
            position of anything
  fantasai: Issue here is that if you have overflow:hidden on the root,
            it might still not clip everything on the screen
  florian: I think what I'm hearing is we might have the right answer,
           but more research is needed
  Rossen: I think something must be missing, happy to be wrong
  florian: We should take the time to get our terminology exactly right
  smfr: I'd appreciate more time to look at this to understand iOS
  fantasai: We also don't have a spec that describes visual vs layout
            viewport, and small vs large viewport, and what's tied to
            what
  fantasai: Like is bottom:0 and top:100% the same? dunno
  Rossen: And when you add zoom and transforms, might end up with
          clipping, or sticking to the wrong thing, both are unexpected

  fantasai: What we can say for this specific issue is that
            overflow:hidden on the root might not necessarily clip to
            the ICB rect
  TabAtkins: That sounds like a Note, not normative text.
  Rossen: so what's the note?
  fantasai: proposed note: overflow:hidden on the root might not clip
            everything outside the ICB if the ICB is smaller than the
            viewport, which can happen on mobile
  Rossen: objections?

  RESOLVED: Accept the Note above.
Received on Monday, 16 August 2021 22:18:00 UTC

This archive was generated by hypermail 2.4.0 : Monday, 16 August 2021 22:18:01 UTC