- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 22 Jul 2021 06:51:50 -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.
=========================================
Republishing
------------
- RESOLVED: Republish CSS Fonts L4 and L5 (Issue #6462)
- RESOLVED: Republish CSSOM (Issue #6446)
Highlight API
-------------
- RESOLVED: Highlights associated with creator document. Throw on
mismatches when registering ranges/etc. (Issue #6417:
Specifying behavior for Highlights involving multiple
documents)
- RESOLVED: UA does not add any default styles to custom highlights
(Issue #6375: Need clarification on expected default
values for style properties)
CSS Flexbox
-----------
- RESOLVED: Move order property to Display module (Issue #5865: Order
property definition only mentions "flex items")
- RESOLVED: Close no change, Firefox is correct (Issue #4852:
Indefiniteness when sizing grid tracks in a flexible flex
item)
- Discussion will continue on github for issue #4311 (Should a
definite flex-basis always make the main size be definite?) to
determine if the proposed behavior is followed by all browsers or
if Firefox is doing something different.
Scrollbars
----------
- RESOLVED: Defer [scrollbar-color accepting a single color] to L2
(Issue #5651: Using scrollbar-color to tint the scrollbar)
- The group began to discuss issue #2252 (Is it possible to have a
position: sticky horizontal scrollbar?) and came to a common
understanding of the problem. However, there wasn't time to
discuss possible solutions so the topic will continue on github.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jul/0010.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Christian Biesinger
Oriol Brufau
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Sanket Joshi
Brian Kardell
Brad Kemper
Jonathan Kew
Daniel Libby
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Morgan Reschenberg
Cassondra Roberts
Miriam Suzanne
Lea Verou
Scribe: fantasai
<Rossen> https://wiki.csswg.org/planning/virtual-july-2021
Rossen: Reminder about the vF2F
Rossen: Please add yourself to the wiki
Rossen: and add items for agenda
Rossen: Any changes to agenda?
lea: Reminder that Color API breakout is right after this call
CSS Fonts
=========
Republishing
============
CSS Fonts
---------
github: https://github.com/w3c/csswg-drafts/issues/6462
Rossen: css-fonts-4 and css-fonts-5
Rossen: I looked over changes, seems fine
Rossen: Any objections?
RESOLVED: Republish CSS Fonts L4 and L5
CSSOM
-----
github: https://github.com/w3c/csswg-drafts/issues/6446
Rossen: Next is updated WD for CSSOM
<chris> note some broken link issues that need to be fixed before
publication https://github.com/w3c/csswg-drafts/issues/6463
Rossen: some PR merged recently
Rossen: emilio, chris any thing holding back?
chris: Some broken links, don't know what to replace with
* emilio can look into that
[emilio and chris will look into it]
Rossen: Any objections to republishing?
RESOLVED: Republish CSSOM
Highlight API
=============
Specifying behavior for Highlights involving multiple documents
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6417
dandclark: Issue is Highlight API doesn't do cases where multiple
highlight trees and multiple documents interact
dandclark: e.g. in same-origin iframes, ranges can be passed back and
forth
dandclark: Should we be allowed to have highlight covering ranges in
different windows?
dandclark: Can a single highlight cross documents?
dandclark: Could reject these cases by throwing
dandclark: I would propose something different
dandclark: I have a 3-part proposal
dandclark: 1st, should allow highlight to contain ranges from
multiple trees
dandclark: 2nd, allow highlight to be added to multiple registries
dandclark: might mean tracking multiple highlight registries for each
highlight
dandclark: When a highlight registry painting, will only paint
highlights associated with that document
dandclark: If it finds a range in another window/iframe, it does not
reach over there and paint there. Only paints within its
own document
dandclark: Wanted to get people's thoughts on this proposal
smfr: Proposal seems to be the most complex version of the solution,
allowing highlights to involve multiple documents and allowing
them to live in multiple registries
smfr: What's the reason to avoid the simpler solution, of restricting
to single document and single registry
dandclark: Philosophical whether to reject early or to be more
permissive
dandclark: If I create a highlight but don't give it any ranges, is
it associated with that document?
dandclark: ...
dandclark: Do I need to do comparison whether new ranges in another
document?
dandclark: Some interesting cases there I don't know how to work
through
dandclark: We could say something like highlight is associated with
document that created it
dandclark: and registry associated with that document
dandclark: and if try to insert range from another document, throws
smfr: That would be my preference for the first version
sanketj: Seems fine, preference for the first version. If necessary
could add these abilities later.
sanketj: Need to define which exception to throw
sanketj: Different documents, multiple registries, and multiple
ranges to single highlight, need to define exception for
each of those
sanketj: Might be simpler to allow those cases and don't paint the
ranges in different document
<emilio> (sorry, no mic) Strongly prefer associating it with the
creator document and throwing on mismatches. There's
precedent for this w/ constructable sheets, FontFace, etc
<TabAtkins> Agree with emilio - we already have a decent precedent to
only allow same-document usage.
<GameMaker> I also agree et. all with throwing
Rossen: Any other comments/feedback?
sanketj: If we are throwing, do we want just one exception or
separate exceptions for each case? Seem like slightly
different operations
TabAtkins: I think they all boil down to same category
TabAtkins: using something in a wrong context
Rossen: If this proposed path forward works for you, suggest go back
to GH and work out the details in terms of exceptions
Rossen: Once all happy, come back and we can resolve
Rossen: Unless you feel strongly on resolving this path forward now
dandclark: Sounds good, thanks
Rossen: Proposal is that we associate with creator document and throw
on mismatches
<sanketj> SGTM
Rossen: Any objections?
<dandclark> +1 to resolution
RESOLVED: highlights associated with creator document. Throw on
mismatches when registering ranges/etc.
Need clarification on expected default values for style properties
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6375
sanketj: CSS Pseudo specifies default values for certain native
highlights. Should there be any defaults for custom
highlights?
sanketj: Since these are author-defined highlight, don't think should
define any styles in UA styles
sanketj: Also no way to do this
sanketj: Seems better to let it just inherit from originating element
sanketj: Might want to make explicit that UA should not give default
styles
fantasai: I agree with this
fantasai: Doesn't make any sense for UA to add default styles to
custom highlights
Rossen: Any objections?
RESOLVED: UA does not add any default styles to custom highlights
CSS Sizing
==========
Compressible Elements with Aspect Ratio
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6341
TabAtkins: Forgot to discuss this last week...
iank: I won't be around next week
Rossen: Anything urgent?
iank: patch waiting in my queue is all
TabAtkins: I just haven't had a chance to think through it. Though
you're probably right anyway
CSS Flexbox
===========
Order property definition only mentions "flex items"
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5865
TabAtkins: Brought up that the definition of order only mentions flex
items, but also applies to other layout modes (grid at
least)
TabAtkins: so we should be generalizing this property, but then where
should it live?
TabAtkins: We think Display is the most appropriate place for it
TabAtkins: Would like resolution to move it to Display, unless
someone has a better idea
<rachelandrew> +1 for display
Rossen: Feedback or other opinions?
smfr: Seems fine
<emilio> Display or maybe position sounds good
Rossen: Objections?
RESOLVED: Move order property to Display module
Indefiniteness when sizing grid tracks in a flexible flex item
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4852
oriol: Case where we don't have interop between FF and Chrome
oriol: When have column flex container which has for example height
set to some value bigger than the content
oriol: This flex item has a flex that causes it to expand
oriol: and this flex item is also a grid container
oriol: which contains an auto row
oriol: Usually auto rows, if you have free space at end of track
sizing, they are expanded to cover this extra space
oriol: Specifically for the case where we set the height property, we
have interop
oriol: but instead of setting height on flex container you set
min-height, in Chrome the auto height doesn't grow
oriol: At first I was confused and thought Chrome was right, but
actually after some feedback from iank I think it's actually
Firefox which follows the spec
oriol: iank also said that he's willing to change Chrome to adapt to
what FF is doing
oriol: So I guess we can close this no change, agreeing that Firefox
is the right behavior
Rossen: comments/objections?
iank: ...
fantasai: I think authors would be happy with this resolution
RESOLVED: Close no change, firefox is correct
Should a definite flex-basis always make the main size be definite?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4311
TabAtkins: There's an example in the issue
TabAtkins: Column flexbox with a flexible child
TabAtkins: child has a definite height, but it is flexible so can
become larger or smaller
TabAtkins: Flex item has a child with a percentage height
[TabAtkins has connection issues]
fantasai: Spec says this case is indefinite, and percentage won't
resolve
fantasai: But implementations do resolve
fantasai: so should we change the spec to match implementations?
iank: I think all of the implementations are following the spec here
iank: in that they are not resolving ...
cbiesinger: Not true
cbiesinger: Testcase is red, which means it is resolving
cbiesinger: Interesting thing here is that the percentage would
resolve outside a flexbox
cbiesinger: it doesn't resolve if you put it inside the flexbox (per
spec)
cbiesinger: I doubt authors expect that
fantasai: Originally definiteness was identifying cases where
percentages are very simple to calculate
fantasai: and we restricted percentage resolution to these cases
fantasai: but authors would be happier to resolve more often
fantasai: so if implementers are already doing it, might as well
match the spec
iank: This seems fine to me
fantasai: Does mean that concept of definiteness is more complicated
cbiesinger: Want to mention, in Chrome we only take into account the
width/height property, not the flex-basis. But that's
probably a Chrome bug
Rossen: Do we know if this is safe to change?
fantasai: Planning to match spec to implementations, so shouldn't
have any concerns
jensimmons: Seems folks doing a good job of raising flex bugs and
addressing them
jensimmons: Would love to ask if filing bugs against WebKit as well,
seems our implementation is same as Chrome
iank: No bug required here, spec is aligning to implementations
jensimmons: on this issue, but not last one
cbiesinger: Should be a wpt test also
Rossen: WPT tests should raise to webkit
<jensimmons> no
dholbert: Wanted to clarify what the proposed change is here. Are we
making the spec match implementations in this case?
<cbiesinger> I think change is: definite flex-basis makes the size
definite, even if the item is flexible
dholbert: I think that doesn't match what we do
dholbert: It might be that this case is triggering a more subtle
situation
fantasai: That's interesting, we should investigate
dholbert: I think intent of our behavior is to match the spec
dholbert: We do check if flex item is flexible when testing for
flexible flex-basis, to see if we want to make item definite
cbiesinger: I feel like you and I had a discussion about this years
ago and you were going to match our behavior
dholbert: We fixed a number of bugs in last 6 months also
dholbert: so maybe previously did something more esoteric
fantasai, rossen: Maybe need to go back to GH to figure out
Scrollbars
==========
Using scrollbar-color to tint the scrollbar
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5651
fantasai: So one thing discussed is whether scrollbar-color should
accept a single color, auto-generating the second color
from the first
fantasai: another is around allowing 'auto' as a keyword in the
two-value syntax, explicitly triggering auto-generation of
the other color
fantasai: We put it on the agenda to ask if there was interest in
allowing this
<emilio> I'd prefer not to add this unless there's strong author
demand for it
<emilio> Not opposed per se but...
lea: I think there should be some defined algorithm for UA to
generate other color
lea: Reasonable for authors to define which color they want to alter,
and UA to define other color
lea: Would prefer that option rather than specifying only one color
and having magic other color
TabAtkins: Note that the spec currently requires two colors, so we'd
first have to agree to allow only one color before the
rest becomes relevant
lea: Should be possible to specify one color
smfr: Wanted emilio to clarify, want single color to be invalid?
emilio: So far, Firefox requires 2 colors, and I haven't seen anyone
particularly complain about that
smfr: I'm not opposed to a single color, but some ambiguity around
whether lightening or darkening to generate the other color
smfr: especially with dark mode
smfr: Might need to specify somehow
lea: With regards to dark mode and whether UA darkens or lightens
lea: that has to depend on the color as well
lea: Defined which direction to go, then what do you do when author
specifies black?
smfr: That's my point, there has to be a defined threshold where UA
flips lightening vs darkening
smfr: Maybe dark mode is not relevant, maybe authors provide
different colors
<TabAtkins> I'm on the side of "just have the author provide both"
(aka no spec change), I think
lea: I think we're discussing minutiae of specifying a single color
lea: but there's no consensus on whether this is desirable
emilio: Same issue that smfr mentions is already a thing with
accent-color
emilio: Scrollbar-color already needs to synthesize other colors,
e.g. for :hover effects
emilio: If there's a strong desire to auto-generate track color...
I'd rather not
emilio: Authors might get what they want in some browsers and
something different in other browser
smfr: Ideal way to specify would be to just use color-5 functions
smfr: Similar to ridge/groove situation
<TabAtkins> Yeah, unlike accent-color, this is a place where we
absolutely know where and how each color is going to be
used. Auto-generating colors would be purely a
convenience, not a necessity like in accent-color.
fantasai: Main question is, do we want to do this or do we want to
defer
Rossen: What's the consensus?
smfr: I think it's nice to have, but fine to defer to scrollbars-2
emilio: Same
Rossen: proposed to defer to l2, any objections?
RESOLVED: Defer to L2
Rossen: Encourage folks to engage on the issue and continue
discussion there
Is it possible to have a position: sticky horizontal scrollbar?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2252
Rossen: Asking if possible to have position:sticky horizontal
scrollbar
fantasai: This issue is a clear case of an unfortunate user situation
fantasai: Very large code block, with overflow:scroll so you can
scroll horizontally, but it's also tall enough that the
horizontal scrollbar is off the screen
fantasai: Person trying to read has to scroll down to reach the
scrollbar, scroll horizontally, then scroll up to see the
content
fantasai: Which is a very bad UX
fantasai: So wondering if there's a way to make a horizontal
scrollbar stay "above the fold"
fantasai: florian and I discussed this; you can't just
position:sticky the scrollbar (it doesn't exist)
fantasai: Maybe we can do something else
fantasai: Or maybe it's just quality-of-implementation, and browsers
could handle this themselves
smfr: Seems only case for ...
TabAtkins: No, if the box is tall enough, this is a problem
smfr: That's 2 separate scrollers right? Document scroller and inner
scroll container
TabAtkins: Right, but document scroller isn't causing it
TabAtkins: The problem is the inner scroller is too tall to be
visible within outer scroller
smfr: I understand the problem
smfr: Quality of implementation seems difficult
smfr: UA wouldn't know whether to add sticky scrollbar, might obscure
some other content
smfr: Other solution might involve...
smfr: Need to think about it
Rossen: Maybe continue conversation back in issue, come back to it
next week or afterwards
Received on Thursday, 22 July 2021 10:53:30 UTC