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