- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 24 Aug 2023 19:33:04 -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 Transitions
---------------
- RESOLVED: CSS Transitions 2 will have a FPWD
CSS Grid & Flexbox
------------------
- Based on the discussion around issue #7387 (Providing authors with
a method of opting into following the visual order, rather than
logical order) the group is leaning toward removing
reading-order: <integer> in favor of a more simplified approach.
However, the newly proposed approach needs to be documented
further to help work through the complications around reading
order.
CSS Text
--------
- RESOLVED: text-wrap becomes a shorthand for text-wrap-style and
text-wrap-onoff, and only text-wrap-onoff is a longhand
of white-space (Issue #9102: Move "balance | stable |
pretty" out of text-wrap)
CSS Color
---------
- RESOLVED: To use the actual displayed color when calculating
contrast (Issue #8539: contrast-color() and gamut mapping)
- RESOLVED: Pursue this approach (an MVP of contrast-color()) in
level 5 (Issue #9166: `contrast-color()` MVP in Level 5)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Aug/0011.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Mason Freed
Megan Gardner
Simran Gill
Paul Grenier
Chris Harrelson
Daniel Holbert
Xiaocheng Hu
Jonathan Kew
Ian Kilpatrick
Chris Lilley
Peter Linss
Eric Meyer
Florian Rivoal
Cassondra Roberts
Jen Simmons
Alan Stearns
Nicole Sullivan
Miriam Suzanne
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: emeyer
Rossen: Any new agenda items or changes to the given agenda?
(none)
CSS Transitions
===============
Moving CSS Transitions 2 to FPWD
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6900
<dbaron> https://drafts.csswg.org/css-transitions-2/#changes-fpwd
<fantasai> ->
https://lists.w3.org/Archives/Member/w3c-css-wg/2023JulSep/0126.html
dbaron: There's a bunch of stuff sitting in it for a while mostly
about integrations with web animations
dbaron: @starting-style rule and discrete animations and the
transition-behavior property
<TabAtkins> +1
<astearns> +1 to FPWD
<flackr> +1
chris: No problem with saying FPWD is a delta
<chris> +1
Rossen: Any objections to FPWD for CSS-transitions-2?
(none)
<fantasai> +1
RESOLVED: CSS Transitions 2 will have a FPWD
CSS Grid & Flexbox
==================
Providing authors with a method of opting into following the visual
order, rather than logical order
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1640556638
rachelandrew: The link in the minutes goes to a comment from the F2F
rachelandrew: I'm proposed a simplified approach for authors to
follow the reading order rather than the document order
rachelandrew: We're suggesting to remove the reading-order integer,
written up in #8589
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/8589
rachelandrew: I got some author feedback and this seems to be good
rachelandrew: We'd keep reading-order: auto and reading-order-items
property
rachelandrew: The latter would let you explain your intention for
reading order
<rachelandrew>
https://developer.chrome.com/blog/reading-order/#proposed-solution
jensimmons: Can you summarize where we are now? How would this work?
rachelandrew: If you have a randomized layout, like dense packing,
people usually want the browser to follow the layout
rather than the source order
rachelandrew: This happens with masonry as well
rachelandrew: With auto, try to follow the reading order rather than
the DOM order
rachelandrew: For things that are non-randomized, pretty much
everything else, like grid and flex layouts with
obvious order, the idea there is to keep the reading
order auto on the items, but on the parent you do
reading-order: items
rachelandrew: So if you're reversing things in flex, you might say
reading-order-items flex-flow
rachelandrew: In grid, you could say reading-order-items grid-row
rachelandrew: We realized even if you've laid out the items, it's not
always obvious what the correct reading order should be
rachelandrew: We think this should solve both these cases
<lea> Coming to this late, but what are the use cases beyond a)
reading order = document order b) reading order = visual order.
The integer syntax seems very low-level for the vast majority
of cases to me, but again, I'm probably missing a lot as I
haven't followed this
TabAtkins: I think the presence of reading-order: auto is a leftover
from reading-order: <integer>
TabAtkins: I think we can drop that and rely on reading-order-items,
is that right?
rachelandrew: I think so, yeah
TabAtkins: Previously everything was auto by default unless
overridden with an integer
TabAtkins: Now that we don't have an everything could be
reading-order-items
rachelandrew: Yeah, I'm keen to remove things that were canned
<iank> +1 to tab
emilio: I was going to make that same point
emilio: But this also seems to conflict with making 'display:
contents' focusable
emilio: I think that needs some more thought
Rossen: Is this in the presence of reading order??
emilio: Yeah, you need to define the order display: content elements
appear
rachelandrew: I think for any of these methods, we probably need an
issue for this
rachelandrew: No matter what we do here, that's going to be a problem
Rossen: Please open an issue for this and link it to this one
<fantasai> file against display-5
emilio: Will do
emilio: This is pretty blocking for me
PaulG: A question about RTL
PaulG: Is there a plan to support RTL for reading order?
rachelandrew: I don't think this would change that, that would be the
flow order
rachelandrew: This shouldn't affect that
Rossen: Agreed, we're talking about the flex or grid direction
rachelandrew: This follows whatever the flow direction is
PaulG: My main concern was in random situations, where the assumption
seems to be LTR
rachelandrew: If you're in a flex layout, the default is LTR in an
LTR language, and RTL in RTL languages
rachelandrew: So I don't think this would be an issue as presently
laid out
fantasai: What is the value space of this property? In the writeups I
found, there were examples of values, but I didn't see a
definition
rachelandrew: We haven't written a spec yet, we're trying to see
whether we could achieve what authors want without
needing to explicitly define each item in the order
rachelandrew: There was a bunch of suggestions in the original #8589,
but I don't think we've written everything out, which
we'd need to do if this is the approach we want to take
<TabAtkins> I think proposal is `reading-order-items: normal | flex
[ visual | flow ] | grid [ rows | columns ]`
<fantasai> ok, is that written anywhere other than your IRC
comment? :)
<TabAtkins> nah, this is distilling the examples
fantasai: It will be easier to understand the proposal if there was a
little more formal writeup
fantasai: Second question, how does this interact with the `order`
property?
rachelandrew: I believe we intend to follow that property if there's
an explicit `order` value
TabAtkins: This would change the tiebreaker behavior
<TabAtkins> oh wait I think I got confused
<TabAtkins> never mind, order just changes layout, and then
reading-order keys into that layout
fantasai: Right now, `order` does NOT affect reading order, its
purpose is to allow breaking reading order from layout order
fantasai: Are you intending to break that?
fantasai: Are we using keywords that are going to implicitly change
that behavior?
rachelandrew: I think if you set the `order`, why would you use
`reading-order`? Using `order` diverges on purpose.
rachelandrew: The only reason you use `reading-order-items` is if you
want to follow the layout
rachelandrew: You can still use `order` as it is now, and wouldn't
use `reading-order-items`
rachelandrew: This is when you don't want things out of sync
rachelandrew: I don't think that's an issue
rachelandrew: We do need to define what happens if there's a conflict
here
<iank> +1 to Rachel
jensimmons: I can imagine a use case where the DOM order is great for
desktop but on mobile you use `order` to rearrange
jensimmons: You might want to apply `reading-order-items` to the
mobile layout to fix the accessibility
fantasai: or not, whether to match order depends on what you're doing
Rossen: Let's get to the queue and close this at half past
<lea> fantasai: re:order vs visual-order, what if order becomes a
shorthand of both?
<fantasai> lea, see https://drafts.csswg.org/css-display-4/#display-order
<fantasai> lea, but that doesn't fix the historic problem...
<lea> fantasai: thanks! "They are not intended (and should not be
used) to apply semantic reordering operations." I'm confused,
isn't semantic reordering the whole point of reading-order?
<fantasai> lea, e.g. don't use them for "I'm going to sort this
column by last name"
<fantasai> lea, reading order is still a _presentation order_
<lea> fantasai: in that case, I do not understand what reading-order
is, which I suspect means it will be incredibly hard to explain
it to authors :/
florian: I'm not sure here, if we only have reading-order-items, then
there's only two options: follow visual layout, or don't
florian: The proposed values are all variants of “follow the visual
order”
florian: It just depends on the direction you take in following
visual order
rachelandrew: What I would say is there are things that need to be
worked out with this
rachelandrew: What I'd like to ask is the original question, which is
do we need the reading-order integer?
rachelandrew: Are there use cases that absolutely require integer? Or
can we simplify and then start to formally define how
to resolve conflicts and such?
florian: Based on what you just said, I suspect we don't need the
integer
florian: I still think this is not going to be easy to define;
there's a lot of subtlety here
florian: There are a bunch of different ways you could iterate
through a grid
florian: Not sure if we'll only need a few values, or a whole lot of
values to handle overlaps and such, or if we actually need
integers
Rossen: Let's redirect into the issue, as there's still quite a bit
to be worked out
Rossen: Do we have enough conviction and understanding to resolve on
dropping the integer value?
rachelandrew: I don't think this is blocking, because if we drop
<integer> now, we could add it back later
rachelandrew: We could say we don't think we need it, and be open to
adding it back in
jensimmons: I think it would be really helpful to have a document
where everything's all in one place
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1690278747
<TabAtkins> (I think the above captures the rough draft proposal.)
<fantasai> -> https://drafts.csswg.org/css-display-4/#display-order
fantasai: We do have a draft in the `display` spec
fantasai: I don't want to take a resolution because I don't
understand what we're trying to do here. I would like a
description of what we're trying to do, not three examples
and "extrapolate what that means"
Rossen: Fair
Rossen: I think the conversation captures that we're leaning toward
not having an <integer>, but once the proposal is clear we
can read and take a resolution
CSS Text
========
Move "balance | stable | pretty" out of text-wrap
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9102
fantasai: Originally, text-wrap had two values, wrap and no-wrap
fantasai: Since then, we've added various values for not just whether
wrapping occurs, but what KIND of wrapping occurs
fantasai: The more we add, the worse it becomes that this is mixed
with wrapping and how
fantasai: Some of the values should cascade, and some shouldn't
fantasai: I would like to split `text-wrap` into two properties
fantasai: One takes wrap and no-wrap, and the other takes all the
others
fantasai: Since `text-wrap` is shipping, I'm happy to dedicate it to
how things are wrapped, and move the wrap/no-wrap to
another property
florian: Completely agree
florian: We do have some tension in the naming
florian: How bad is it to ask Chrome to break here
florian: When they asked about shipping, they said it would be okay
to rename later
florian: I would prefer that we kept `text-wrap` for yes/no on
wrapping at use `wrap-style` for the others
<fantasai> wrap-style vs text-wrap would indeed be more
understandable if that's possible ...
iank: I think the situation has changed from that time period
iank: I don't know if renaming is viable
florian: This is going to make it more difficult to do this sort of
thing in the future
florian: We asked explicitly if it would be okay, and now it's been
walked back
lea: I agree these should be separated, and we should have more
granular control over wrapping
lea: I don't know that we need to break backwards compatibility to
do that
lea: values like balance or pretty are useless without wrapping, so
it seems like a win if setting text-wrap to one of these values
would also enable wrapping (if you have no provided a separate
wrap/no-wrap keyword)
lea: If you say `text-wrap: balance`, we can be smart and also set
`wrap`
fantasai: What you're proposing is we keep `text-wrap` as a shorthand
that incorporates text-wrap-style and text-wrap-onoff,
where text-wrap-onoff is also a longhand of white-space?
lea: Yes
fantasai: That could work, we need a better name than
`text-wrap-onoff`
Rossen: Let's bikeshed the name offline
jfkthame: I wanted to add something slightly orthogonal
jfkthame: balance really needs to be separated from stable versus
pretty
florian: I'm unconvinced, it's not obvious to me you'd want a stable
balance that becomes stateful
<fantasai> +1 florian
florian: Balance is a style of wrapping, it's not clear that I want
greedy balancing or whatever other options we could have
jfkthame: The spec text suggests balance is only attempted up to a
limited number of lines, and it then falls back to wrap,
but what kind of wrapping?
florian: We could fix this in the spec; do you mean that if you set
balance, we ignore the style of wrapping unless we fall back?
jfkthame: You could specify stable or pretty or balance, but if you
do balance and then there's a fallback, what happens?
florian: So you're saying you want balancing, but you want to be able
to choose how you fall back.
jfkthame: I'm not entirely sure
florian: I suspect what you want is orthogonal so it's probably find
as a pullout
<lea> There is a continuum between balance and greedy wrapping.
Authors often want some degree of balancing but less
"draconian" than full-blown balance. Not sure if the solution
is to separate balance out, or to just provide more control
over exactly how the balancing happens
fantasai: I don't see that these need to be separate properties; we
could allow multiple keywords
fantasai: I think balancing is interesting because an implementation
could use different approaches
fantasai: We want flexibility for user agents
fantasai: I do really like Lea's proposal and it seems to address
cascading problems we have with the current setup
fantasai: Propose text-wrap becomes a shorthand for two properties,
text-wrap-style and text-wrap-onoff
fantasai: ONLY text-wrap-onoff is a longhand for whitespace
fantasai: (names to be bikeshedded)
<fantasai> PROPOSED: text-wrap becomes a shorthand for
text-wrap-style and text-wrap-onoff, and only
text-wrap-onoff is a longhand of white-space
florian: Is the complete value space of text-wrap the same as
currently?
fantasai: Yes
<fantasai> text-wrap: <'text-wrap-style'> || <'text-wrap-onoff'>
<fantasai> text-wrap-onoff: wrap | nowrap
<fantasai> text-wrap-style: stable | pretty | balance | auto | etc.
Rossen: Hearing no objections…
RESOLVED: text-wrap becomes a shorthand for text-wrap-style and
text-wrap-onoff, and only text-wrap-onoff is a longhand of
white-space
CSS Color
=========
contrast-color() and gamut mapping
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8539
chris: We can either say you do contrast between the color you can
see and another color, or we say it's between something that
might not be a color and some other color
lea: We need to hear from implementors whether this is possible
chris: I did touch on that in the issue; we don't expose the used
value of a color and don't need to for this
lea: Not concerned about fingerprinting, I'm concerned about whether
all ODes can do this
TabAtkins: They'll have what they used to present to the monitor
lea: Do colors get gamut-mapped to something they can present?
TabAtkins: Not sure
lea: We could conditionally resolve, saying we'll do something if
it's actually implementable
chrishtr: What's the actual proposal here?
chris: To use the actual displayed color when calculating contrast
<TabAtkins> (As much as that information is available.)
<fantasai> +1 to the proposal
chrishtr: So gamut mapping should be taken into account when doing
this?
lea: The rationale being otherwise we could get calculation between
two non-existent colors. Otherwise you might decide there's
enough contrast, but after gamut-mapping there isn't.
Rossen: It seems like this makes the most sense
Rossen: The question is whether you can get those, and how much work
it will take to do so
Rossen: In terms of intended functionality, what Chris is proposing
here makes total sense
Rossen: If implementors say this is impossible, we should drop the
entire thing
<fantasai> +1
chrishtr: I'd like to wait a week to resolve
Rossen: That objects to what makes sense
<lea> +1
Rossen: So let's resolve on what makes sense, and if it turns out to
be impossible, we revisit
RESOLVED: To use the actual displayed color when calculating contrast
`contrast-color()` MVP in Level 5
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9166
lea: contrast-color() is supposed to give an actual contrast
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/9166#issuecomment-1688124086
lea: Because there are so many issues to figure out, in practice what
happened was a year floated past and nothing really happened
lea: How about we ship a simple `contrast-color()` that take one
color, the background, and returns either black or white, as
fantasai proposed
lea: This sidesteps a number of things
lea: I think we need a number of levels to get at a full function
<TabAtkins> +1 to this scope reduction
lea: If we scope it down that far, we can get something out
lea: The only point of contention was, how predictable should the
return color be?
<chris> I strongly prefer the black-or-white MVP not the
anything-goes one
<fantasai> +1 to lea's position
lea: Should only black and white be allowed, or can UAs have room to
return other values?
<chris> +1 to lea's proposal
Rossen: We're over time, so, are there any objections to pursuing
this in L5?
<florian> +1 to do it, preference for black/white only
<fantasai> https://github.com/w3c/csswg-drafts/issues/9166#issuecomment-1666863256
<fantasai> Let's do it
(no)
RESOLVED: Pursue this approach in level 5
<chrishtr> so is the resolution to allow not black and white, but
prefer them?
<lea> chrishtr: we did not resolve on the return value yet, only that
we agree to pursue an MVP in that general direction (though in
the chat I do see some consensus for the black/white option)
Received on Thursday, 24 August 2023 23:33:39 UTC