- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 May 2021 18:28:25 -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 Multicol
------------
- RESOLVED: Confirm that abspos elemetns do not create column boxes
and this adjacent spanners separated by abspos will
collapse margins (Issue #6265: Definition of adjacent
spanners, when to create column boxes)
- RESOLVED: Add the current interop situation to the spec [Out of
flow positioned elements affect the height of the
multicol container] (Issue #6279: Should contained
out-of-flow descendants affect column balancing?)
CSS Contain
-----------
- RESOLVED: Remove at-risk label for style containment (Issue #6272:
Remove "at-risk" for style containment)
- RESOLVED: Style containment will be required in order to establish
a queryable container (Issue #6213: Need style
containment for container queries)
- RESOLVED: Have unknown @supports expressions evaluate to false for
all @support rules (Issue #6175: What is the migration
path for Container Queries?)
- RESOLVED: Create a container function that can test if @supports
checks for a particular container query (Issue #6175)
CSS Color
---------
- RESOLVED: Drop lab from color() (Issue #5887: Consider removing
lab(...) and lch(...) syntax and using color(lab ...)
and color(lch ...) only)
CSS Images
----------
- RESOLVED: Make -webkit-image-set a parse time alias to image-set
(Issue #6285: Consider making -webkit-image-set a
parse-time alias to image-set)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021May/0003.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
David Baron
Christian Biesinger
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Brad Kemper
Jonathan Kew
Rune Lillesveen
Chris Lilley
Ting-Yu Lin
Ben Mathwig
Tess O'Connor
Morgan Reschenberg
Florian Rivoal
Miriam Suzanne
Lea Verou
Greg Whitworth
Regrets:
Rossen Atanassov
Cassondra Roberts
Scribe: dael
astearns: We're 3 minutes after. I think we should get going.
leaverou is running a bit late so item 3 may push down a
bit. Other changes?
CSS Multicol
============
Definition of adjacent spanners, when to create column boxes
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6265
rachelandrew: Couple of linked issue with out of flow items
rachelandrew: I think example is straightforward. Got adjacent
spanners that come directly after. Margins collapse is
in spec
rachelandrew: If you have abspos item in between which is taken out
of flow we don't have interop. Gecko is not margin
collapsing. Keeping abspos item separating. Blink and
Safari do collapse
rachelandrew: Morton brought up because new fragmentation engine
doesn't
rachelandrew: What happens if we have out of flow item between 2
column spanners. Happy with margins not collapsing or
want them to collapse
astearns: If you have non-spanning elements separated by out of flow
do margins collapse?
rachelandrew: um...I'd have to test. Not sure
fantasai: They do collapse
rachelandrew: Cool
dholbert: I posted test case on GH showing they do in the simplified
scenario
fantasai: I think this is a little...worth pointing out if you have
abspos content contained by a block-level box it gets
trapped and creates columns.
fantasai: If abspos is directly contained by multicol I don't see
that is should cause creation of margin
rachelandrew: That's what I thought. It would mean Gecko changing
what they're doing
astearns: fantasai you suggest in case where abspos is contained by
sibling it's different?
fantasai: If there's an abspos position:relative element it creates
column boxes and abspos inside it can cause a height. But
it's the block box causing the columns. When it's directly
contained no reason to create columns and therefore not
effect margins
TYLin: Reason why FF is not collapsing margin is because when it's
out of flow it still leaves placeholder which triggers column
box to be created so there is a gap between the adjacent
fantasai: But margin collapsing rules generally ignore abspos
elements. So no reason why that should be happening
TYLin: Agree
dholbert: Create the column box to create placeholder. If say abspos
placeholder don't get a box that would fix it
fantasai: Placeholders only exist in table box generation, as far as
the specs are concerned. They're otherwise an
implementation artifact.
dholbert: Yeah. Abspos elements don't cause creation of column box.
I think that's what you're proposing.
astearns: Sounds like Firefox is willing to change
astearns: It was said Morten brought this up because new generation
matched Firefox
rachelandrew: I don't think it was a conscious choice but was impl
details. I'm assuming they're happy to go back. We can
ask
iank: I didn't get to talk with Morten before meeting. I think we'd
be fine with that
astearns: Proposal: Confirm that abspos elements do not create
column boxes and this adjacent spanners separated by
abspos will collapse margins
fantasai: It think it's no change
astearns: Clarifications and some tests, I suspect
fantasai: If we call this out in the spec, that implies that margin
collapsing elsewhere might. Need tests, but no change to
spec
iank: Don't know if that's correct about don't create column boxes.
Might conflict with next issue
iank: And that issue is basically does column balancing apply when
you've only got abspos in multicol
fantasai: Not in conflict because columns not being created by
abspos in the next issue. Box with position:relative
creates it. It might be 0 height and can't see, but it's
causing creation of column row
iank: I guess this sort of gets at...need to think about it
astearns: Why don't we resolve adjacent spanners separated by abspos
elements will collapse margins
astearns: Abspos elements not creating column boxes is probably
implied. But we can go with just margin collapsing for now
iank: Re-read next issue, I was wrong
astearns: Back to original proposal. "Confirm that abspos elements
do not create column boxes and this adjacent spanners
separated by abspos will collapse margins"
RESOLVED: Confirm that abspos elemetns do not create column boxes
and this adjacent spanners separated by abspos will
collapse margins
Should contained out-of-flow descendants affect column balancing?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6279
rachelandrew: This is another one about out of flow elements. Out of
flow position box doesn't normally effect ancestor
size. It is happening in multicol
rachelandrew: We have interop, everyone does same thing. It is
different to have things behave with out of flow. Are
we happy to have multicol behave different or do we
want to change that
astearns: We have interop but not based on spec text?
rachelandrew: I think that's right
fantasai: I think we do have a use case that people use multicol to
emulate pages. That would want us to do same as paginated
which is generate more pages and take up space. given we
have interop and one reason to do it my suggestion would
be to put what they're doing in spec
astearns: Any opinions on the other side?
astearns: Or just generally against
<TYLin> +1 for current behavior
astearns: Proposal: Add the current interop situation to the spec
astearns: Objections?
RESOLVED: Add the current interop situation to the spec
Publication
-----------
fantasai: multicol should be in CR
rachelandrew: Working through wide review. I've got a11y. I think
privacy is going to review
fantasai: I see security and tag....requested and not linked?
rachelandrew: I was going to do those today
fantasai: Great. Hopefully will transition in a few months
iank: FYI we will probably follow some more issues in a few months
given what we're working on
rachelandrew: Cool. I'll try and keep up
astearns: Thanks rachelandrew
CSS Contain
===========
Remove "at-risk" for style containment
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6272
chrishtr: I think there's a use case now which people agree is
important. Have improved definition with respect to HTML.
chrishtr: Spec says HTML ordinals are implemented via CSS counters.
chrishtr: I think we're in good shape to remove those lines
florian: I wouldn't be surprised if when another browser implements
there's something we overlooked, but don't need label
anymore.
chrishtr: Agreed
florian: Have some amount of tests. Want to put it back on track
astearns: When last discussed I think one implementor was against
implementing?
chrishtr: Previously emilio but I think all issues have been
addressed
emilio: I don't object. My concern with style containment is it
wasn't clear it was useful and interacted with lists, but
since lists are now in terms of counters...still style
containment doesn't allow style system optimization but it
is needed for use case described
astearns: Process-wise I would like to see a second impl started.
Once we put at-risk it's easy to leave until we're sure
it's going to happen. I'm not absolutely sure, but it's
low risk to take off if we have to put back on
astearns: Proposal: Remove at-risk label for style containment
RESOLVED: Remove at-risk label for style containment
Need style containment for container queries
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6213
rune: Brought up in connection with container queries. Counter in a
container with container queries the counter changes there can
affect counter after and affect layout. In particular with
flexbox, but other types too. Creates circularity without
style containment
florian: I think you've proven the circularity. Can break with style
containment. I'm in favor
florian: Only concern I have is circularity is real, but not
something you'd expect authors to typically do
rune: Probably not
florian: Suspecting this is a rare weird thing to do. Wondering if
always apply style containment is more downsides then
another way to cut the loop
rune: If you have a counter which is used per container having style
containment on the container means you can't increment across
multiple components
astearns: Motivation for solving circularity in another way is if
there is a use case for not having a style containment on
container queries for a non-counter related reason. Don't
know if there is one
rune: If you don't have style containment can have hard to get
interop in this edge case. Number of ways layout will effect
result
florian: I think I withdraw suggestion for alternatives. Problem is
real and your solution is the obvious
rune: If you have style containment on container you can increment.
Just not inside the container. If you have orphans with the
container it will work
astearns: miriam are you okay requiring style containment on
container queries?
miriam: Yeah. A little downside but not very big
astearns: Proposal: Style containment will be required in order to
establish a queryable container
RESOLVED: Style containment will be required in order to establish a
queryable container
CSS Color
=========
Consider removing lab(...) and lch(...) syntax and using color(lab ...)
and color(lch ...) only
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5887
leaverou: I did not open this so not sure I should present. I could.
chris: I'm happy to present
chris: Basically issue is we have 2 ways to express lab
chris: Have to be kept separate in the implementation. Keep track of
which used. Do we need 2?
chris: Can delete either. People like lab() because brief. Only
added lab to color because sure why not when smfr asked.
Since Apple is now asking to remove easiest to remove
smfr: Talked to Sam. Didn't come to agreement. Don't think we're
arbiters of CSS. Rational to add it is wanted color function
to be superset or union of all ways to describe colors. Where
there is a color function with a color space where that space
could be used in first argument
<leaverou> +1 to smfr's reasoning for color()
<argyle> +1
smfr: Someone uses tooling doing all their colors with color
function and want roundtrip with 10bit
smfr: Okay if we remove, but for completeness it makes sense to have
chris: Understand argument. Would be nice. As someone pointed out we
missed with devicecmyk and lch. That was different a while
ago but if we wanted to do this need to add lch into the
color function so you would need to say this param is a hue.
Doable but complex
leaverou: Opposed to dropping. It's a nice readable syntax. Could
instead drop distinction and allow browsers to store
color(lab) and lab function as the same thing.
leaverou: Useful to keep distinction for srgb colors. But spec by
color isn't legacy and for lab it's the same colors. If
it's complex for impl no reason to store the syntax
leaverou: Agree with smfr there's value in color describing all
colors. Allows library to serialize whatever color without
a special case. Nice to have, not a huge need. Nice if
possible. Good to add lch and every other color we support
leaverou: Might even be value in normalizing coordinates in a 0-1
range and then color can generic spec any color supported
<chris> angles in [0..1] eww no
TabAtkins: On the idea of unifying everything into color with lch
and hsl, color only accepts numbers and not angles. I'm
not familiar with the math, but I don't think color space
ever has angle we would be special casing angle to the
pre-defined ones. Feels odd to duplicate the work to
color. Poss, but awkward
TabAtkins: On leaverou's side I would rather a single way to
represent rather then 2 ways to represent with 1
serialization. I could be okay, but don't like aliasing
to a different value then spec and since we don't have
legacy need we shouldn't invent one
TabAtkins: Support keeping lab and lch functions and if necessary
drop lab from color
florian: Wondering, if we drop the keywords for simplification we're
left with one double? Or is color with srgb keyword is that
different behavior?
chris: It is. Higher precision requirement
leaverou: Interpolates differently as well
florian: Thank you
astearns: Seems like things have gone somewhat afield. The question
of if we have lab and lch in color function or just lab?
chris: Just lab
smfr: To defend Sam's point he would prefer not to have color(lab)
and lab() so prefer to drop one. My preference is weak so
willing to drop color(lab)
chris: Can you explain why tracking which method used? Serialization?
smfr: Yep
leaverou: If they were parse time aliases would have same problem?
emilio: No, but then need to decide one
astearns: And then arbitrarily changing how things specified in
style sheet for implementation-only reason
astearns: My uninformed opinion, I kind of agree with smfr that it
would be nice to have color spec any color at all, but
sounds like problems with colors that use angle. Unclear
if we could get to a superset color function.
astearns: Sounds like a slight reason to drop lab from color. No
strong opinion
<argyle> agree with what alan just said
chris: My preference too. Can see both arguments
smfr: Can live with dropping lab from color
<chris> +1
astearns: Proposal: Drop lab from color()
astearns: Anyone arguing against?
astearns: Objections?
RESOLVED: Drop lab from color()
<chris> Thanks for the explanation @smfr helpful
leaverou: Question, I always assumed if we want to add new color
spaces we first add in color function and if we see huge
usage we might add as separate color functions
<fantasai> +1 leaverou
leaverou: Means in future might have color formats specified by both
color() and own function. Wouldn't that cause same problem?
astearns: It would
astearns: But I think argument there is this is for authors. Huge
usage is worth extra effort on impl side. Maybe we
wouldn't get to that decision unless usage is off the
charts
<chris> It would, but no clash as the custom one use dashed-ident
leaverou: chris, not talking custom color spaces, talking about new
predefined
<chris> I see
astearns: I can see if at some point we figure out how to put angle
spec colors into color function we can revisit color
function being a strict superset and re-add lab
astearns: I don't know we have a strong precedent for colors in
future
leaverou: Can have angle in color. Current grammar doesn't allow,
but not reason not to
<chris> The current grammar allows hue angles to omit a unit
TabAtkins: I don't think we can do custom colors spaces with angle
so would have to special case predefined which is weird
leaverou: It does
fantasai: Could define as 100% of at 360deg
chris: Ew. Can drop unit ID right now so can say 40 for 40deg
<faceless> +1 to "ew"
<argyle> 1 is pretty convenient to use with display-p3 tho, i know
i'm hitting max without knowing what the max number is
astearns: Is there an issue?
chris: No
astearns: Should be?
TabAtkins: No reason to yet. No color which can be spec uses an
angle yet
chris: I believe that's correct
astearns: leaverou should we revisit the resolution or move on?
leaverou: okay
CSS Contain (continued)
=======================
What is the migration path for Container Queries?
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6175
miriam: Talked a couple weeks ago. Confusion on intent. Going for
@supports should always treat unknowns as unsupported
miriam: Allows new function and testing work backward compat
miriam: 2 resolutions. 1) any unknown supports evaluates as
unsupported 2) add container function for testing support of
specific container conditions
florian: When you say treat unknown as unsupported at top level,
you mean immediately?
miriam: Yeah
miriam: Being able to negate it and have it return true is essential
here
TabAtkins: Good with this
astearns: Changing behavior for all supports rules?
miriam: Right now not interop on this
miriam: Chart in the thread of current handling
astearns: Thanks
TabAtkins: Spec is unclear. Does not define. Was intended to be
different, but Nina convinced me this is better
florian: Didn't we have a proposal for unified syntax for combo of
media and support queries?
TabAtkins: That's my when/else proposal. We'll deal with that when
it comes up
florian: Okay. Might be a problem, but not as important as containers
astearns: Proposal: Unknown @supports evaluate to false and add that
to spec for all supports rules
florian: For this use case it's right. Will it always be or should
we specialize to supports query for containers?
miriam: I can't see situation for other behavior. Any new type of
check we add to @supports to determine if supported need it
previously returning false
florian: Add new feature and query together, yes. Support syntax for
things that predated ability to detect then no.
TabAtkins: I think consider future longer than the past. A supports
query moving forward that you don't understand is for a
new feature you don't understand
astearns: A bit concerned we haven't run across this lack of
interop. Are people not using not within supports?
miriam: Ran into this with selector
florian: With selectors, do we not want opposite behavior?
astearns: In this case opposite as @supports and @supports not
evaluate to unknown
florian: An unknown stays unknown until top at which point it
becomes false
miriam: Why would we want that?
<astearns> +1 to miriam
TabAtkins: Same as a feature. If you don't understand enough to
evaluate you don't understand to use.
florian: Okay. Maybe I'm not thinking correctly. Defer to TabAtkins
astearns: Proposal: Have unknown @supports expressions evaluate to
false for all @support rules
RESOLVED: Have unknown @supports expressions evaluate to false for
all @support rules
astearns: Do we also need to resolve for the @supports for specific
features
miriam: Looking for a container function in @supports that accepts
container query query conditionals
astearns: Is it the full syntax? Or a subset?
miriam: I think it should accept any...hmmm
miriam: Maybe it should be one query at a time and you can string
together multiples of the function
miriam: Accepts single conditional
astearns: Had not thought threw this. Possible we'll have new things
you can add to function over time such that an instance
may or not evaluate based on state of impl?
miriam: I expect we will add additional feature queries over time
astearns: That seems to me argument to string together multiples.
Maybe. maybe not
miriam: Makes sense and makes simplest case simpler. @container and
a singe query. Makes sense to me
astearns: Other opinions?
astearns: Proposal: Create a container function that can test if
@supports checks for a particular container query
astearns: Objections?
RESOLVED: Create a container function that can test if @supports
checks for a particular container query
astearns: I expect once this is speced we'll have more questions
CSS Overflow
============
Scrollbar-gutter topics
-----------------------
florian: We should find a dedicated call to hash out
scrollbar-gutter. Suspect start with a side discussion
astearns: Will you organize florian?
<gregwhitworth> +1 on side chat
florian: If others are interested
<cbiesinger> I am interested
astearns: Why don't you try organizing on private list. If we get
enough people we can open a public meeting on this
florian: Works for me
CSS Images
==========
Consider making -webkit-image-set a parse-time alias to image-set
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6285
emilio: There's enough usage in the wild of -webkit-image-set it's
worth supporting
emilio: Chromium engineers skeptical of getting rid of prefix. I
think alias the 2 functions is easiest. webkit does some
aliasing. -webkit-image-set serialized as unprefixed
emilio: I think right now WebKit limits the syntax for
-webkit-image-set but they could just support whole thing. I
think that's easiest way to spec it
TabAtkins: So long as it's reasonable to Chrome and WK people to
accept full set I'm happy to put this in spec
smfr: Fine with that
rune: Without looking it much detail, sounds good
astearns: Proposal: Make -webkit-image-set a parse time alias to
image-set
astearns: Objections?
RESOLVED: Make -webkit-image-set a parse time alias to image-set
astearns: foolip mentions might be a problem with accepting full
syntax, but can check
emilio: I think it's pretty unlikely that [missed] but we can check
astearns: Might be possibility. Usage would be tiny and not sure
side effect is awful
astearns: Thanks everybody for calling in
Received on Wednesday, 12 May 2021 22:29:05 UTC