- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 5 May 2022 06:13: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 Variables 1
---------------
- RESOLVED: Move CSS Variables 1 to CR Snapshot after May 9
Media Queries
-------------
- RESOLVED: In all levels of MQ we will make 'layer' syntactically
invalid media type (Issue #7225: Restrict 'layer' from
the <media-type> production?)
Flexbox
-------
- RESOLVED: Not required to re-wrap from column flexboxes in order to
avoid overflow (Issue #6855: Multi-line column flexbox
fragmentation)
CSS Colors and Filter Effects
-----------------------------
- chris will write up text for the proposal to add new color
interpolation and change the default and add it to issue #7100
(Should no-op filters produce different output from no filter?)
for further discussion. They'll also pull in more implementers to
ensure the proposal can be implemented.
Selectors
---------
- RESOLVED: Name is :modal for pseudo-class. It is defined as the
element/dialog that restricts interaction to everything
as described in the issue (Issue #6965: Add :modal-dialog
pseudo-class)
CSS Text
--------
- RESOLVED: Text area will rely on text-space collapse and break and
those properties will be defined in Text 4 (Issue #6309:
whitespace inside text areas)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0000.html
Present:
Rossen Atanassov
Tab Atkins Bittner
Elika Etemad
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Dael Jackson
Ian Kilpatrick
Daniel Libby
Chris Lilley
Peter Linss
Alison Maher
Florian Rivoal
Regrets:
Delan Azabani
Jonathan Kew
Miriam Suzanne
Sebastian Zartner
Scribe: dael
Rossen: 2 minutes past. Still a little lite on attendance but should
try and get going
Rossen: As usual, first is any changes to the agenda?
Rossen: I saw a request to skip item 4 which we will do
Rossen: Anything else?
CSS Variables 1
===============
Horizontal Review #6808
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/6808#issuecomment-1114959228
Rossen: Transition to CR snapshot. Understanding we're ready by end
of this week
Rossen: Anything else you want to talk about before resolution?
chris: Not really. Went through horizontal review including TAG so
all ready
Rossen: Awesome. Everything but security review is done; security
review times out on 8 May
chris: Correct
Rossen: Then in position to move to CR snapshot
Rossen: Additional comments or concerns? Otherwise will call for
objections
Rossen: Objections to Move CSS Variables 1 to CR Snapshot after May 9?
<florian> go for it
RESOLVED: Move CSS Variables 1 to Snapshot after May 9
Rossen: chris will you handle?
chris: I will
Rossen: Thanks
CSS Lists
=========
counter-reset in UA sheet causing some compat issues
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7227
Rossen: fantasai can we do this without emilio?
fantasai: Better to have him
Media Queries
=============
Restrict 'layer' from the <media-type> production?
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7225
florian: We have a syntax ambiguity. When you do @import if you write
@import <url> layer it could either mean import layer or it
could be a MQ for a media type called layer
florian: TabAtkins suggests in MQ 4 spec we declare layer cannot be a
media type so if you try and parse that way it's a syntax
error. When used in MQ it wouldn't work and when in @import
it's a layer
florian: Mostly doesn't change anything because layer isn't a valid
media type and is not proposed. Error handling is slightly
different. If you do @media not-layer it would handle
differently. Unlikely this is being done
florian: I think TabAtkins suggestion is good and we should go for it
Rossen: Process question- MQ 4 is a CRD. How close are we...would
that reset anything in terms of MQ 4 process?
florian: I don't think it would. MQ 4 is largely waiting on tests and
impl. It's not really a new feature, it's error handling.
Adding it to 5 would make 5 incompat with 4 and we'd have to
patch 4 eventually.
florian: Possibly want to add an errata in MQ 3
Rossen: Yeah, do we need to?
florian: Probably in ED at first, let it sit to make sure we don't
change our mind, then include as a correction
Rossen: Sounds good. Let's proceed with MQ 4
Rossen: Additional suggestions or ideas?
Rossen: TabAtkins is trying to join
florian: We're taking his proposal anyway
<TabAtkins> yeah, no need to comment
Rossen: Not hearing anything else
florian: Prop: In all levels of MQ we will make 'layer' syntactically
invalid media type
Rossen: Objections?
RESOLVED: In all levels of MQ we will make 'layer' syntactically
invalid media type
Rossen: We'll worry about errata later
florian: I'll put in the ED for now
Flexbox
=======
Multi-line column flexbox fragmentation
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6855
alisonmaher: I think fantasai put this on the agenda so could do a
better job summarizing
fantasai: We were gonna spec the behavior but had questions about
exactly what to spec in terms of fragments influencing
sizes of boxes
fantasai: Let's say you have 4 boxes inside container and splits
across pages. Point it fragments can cause flex items to
get taller which changes alignment and space distribution
fantasai: Ideally no overflow. Author doesn't expect overflow because
said to wrap
<Rossen> example being described -
https://github.com/w3c/csswg-drafts/issues/6855#issuecomment-1102928864
fantasai: Question is do we want to put an algorithm that requires
passing info and possibly re-wrapping or do we want to have
overflow? What are the consequences of fragmenting that
we'll accept
iank: I can touch on this for grid since has similar problems
iank: Grid will run the full layout algorithm, get where everything
is and size. Then it will perform fragmentation step
iank: There's just small adjustments when it makes sense. If a grid
item is auto-height then we will grow out that item and shift
things below it down. Try not to cause overlap. Similarly will
stretch other grid items
iank: When looking at flex wanted to follow similar. When you try and
rerun is a problem. Similar where you run algorithm once and do
fragmentation fixups seems good solution
fantasai: Difference between grid and flexbox, grid you placed the
items in the rows. If the author has over-constrained then
you overflow, but if it will fit there is no problem.
Flexbox you run for a column, see what fits, and then wrap.
If you grow because the stacking you will overflow the box
iank: Unless box is auto height
fantasai: In which case you wouldn't wrap
iank: Right. I think this is relatively rare for flexbox columns.
Fundamentally issue with fragmentation is in order to fragment
you need to place in fragmentainer. Codependency on position
and size
iank: I don't think it's bad...most of the time if opt for new column
there may be space under. Most of the time expansion is small.
Don't know if it's much of a problem in practical
fantasai: Could be an image. Point is are we going to overflow when
frag and is that acceptable
iank: I think cases would be rare and it's acceptable
iank: alisonmaher did you want to add anything?
alisonmaher: Not much to add. Agree. Note for out of flow frag we'd
overflow or go past the end if end aligned. Doing
similar is not too big a problem
fantasai: I don't think overflow bottom aligned stuff is great idea.
Authors bottom align a lot and don't expect overflow when
print. Case with columns and wrapping you don't have a
choice, but for alignment there's all that space you could
have used to fit the item. Overflow doesn't make sense
iank: Alignment topic has same problem in grid. If you center or
bottom align have potential to overflow. If you don't do that
algorithm becomes impossible to impl
iank: In order to know how large something is you have to place, if
you change placement need to resize
fantasai: Not impossible, but really unpleasant if layout from top to
bottom. Could do from bottom to top, but I don't expect that
fantasai: More important to align correctly or not have overflow when
print? Or a way to not have either problem
Rossen: It's important to make sure we have a stable algorithm so we
don't run into performance clips that would be terrible when
not printing
Rossen: With infinite time we can compute beautiful layouts, but want
to make sure this is close to linear
fantasai: I don't think linearity is problem there. I can accept
fixed height column wrapped fragmenting is rare. I don't
think that is true for alignment in general. I don't think
we should overflow content when printing things bottom
aligned. More complicated and simpler ways to avoid, but
shouldn't cause overflow on layouts that should never be
overflowing in the common cases
fantasai: But that is separate issue
iank: Yeah. Happy to discuss more
iank: When I experimented with grid only happens when item itself
fragments. Mitigation is something like break inside a void
fantasai: People do entire page layouts in grid, though. A lot of
grid layout where you don't want to break, but a bunch
other with flow content that expects to break across
multiple pages
Rossen: How do we want to move forward?
florian: Seems to me we have multiple similar but distinct situations
here
florian: fantasai argument makes sense, but there is question of
implementation complexity. Are there subcases in here where
we can decide or do we need it all in one go?
iank: Fragmentation has codependency on position. For block and table
always know position before layout. When introduce alignment in
grid and flex sometimes have this not typically
iank: When you position it effects size, sometimes in large and
unpredictable ways. Moving one px might be drastic because have
a 100px monolith in it. Without testing every px can't know
size at a position
iank: I'd be against saying test every position, but that's the impl
complexity
fantasai: You don't have to do that to prevent overflow. You could
say that if it fragments such that it will overflow, you
don't align but instead start-align so it fits.
fantasai: If you want lots of work but great you can frag
bottom-aligned containers separately, but wouldn't recommend
iank: Can't do if content has overflowing content inside
iank: I think this is slightly separate from the issue
fantasai: Yeah.
fantasai: For case of column wrapping stuff I think it is rare enough
that if it overflows and looks like a mess the user will be
unhappy but it's rare. If we want to cause overflow I'm
willing to accept for this one. not willing to accept for
normal alignment and common things. It's more important to
avoid overflow than to honor alignment
<florian> +1
Rossen: So, iank or alisonmaher what's your position? Continue
thinking more?
iank: For alignment should open separate issue. This is complicated
stuff. We should discuss separately
Rossen: If we open the alignment issue, what can we resolve for this
issue?
iank: I don't think we need to resolve on anything. Maybe wrong
Rossen: fantasai anything to keep this issue open?
fantasai: Need to resolve that fragmentation algorithm for
column-wrap flex containers can cause items to overflow
even if would not have overflowed otherwise
Rossen: I think that's an easy resolution to take
fantasai: Specifically to avoid re-wrapping the columns
fantasai: Not required to re-wrap the columns
fantasai: to avoid overflow
plinss: Can live with that. but I don't want spec language to say you
must overflow. If you can do better want to make sure you can
<fantasai> plinss++
Rossen: Sure. Can resolve as may overflow
plinss: Generally reluctant to have attitude that fragmentation is
hard so let's do what's easy. Have been doing that for 25
years and fragmentation has been broken. Rare is not
justification to do wrong
Rossen: Agree, but think you're overstretching. Everyone is trying to
make fragmentation as good as possible. Edge cases we'll do
in performant way
plinss: Saying people can do simple because rare. Not happy with that
iank: Yeah. We're focusing a lot of time to have a high quality
baseline engine. Number of bug reports for fragmentation is
very high so we see it's important use case
plinss: I accept that and accept that impl is hard and bugs need to
be prioritize. Impl won't always get it right. Want to be
careful not to spec bad behavior
Rossen: Fair. I think proposed resolution here for the described case
it should be may overflow
florian: We've had other cases where spec may where no one felt they
could do good thing at the time and then we could eventually
remove it. Let's keep the door open
Rossen: And I think great work happening across the board on
fragmentation so hopeful we'll get there
fantasai: Proposal: not required to re-wrap from column flexboxes in
order to avoid overflow
Rossen: Additional comments?
Rossen: Objections?
RESOLVED: Not required to re-wrap from column flexboxes in order to
avoid overflow
Rossen: Let's open new issue for alignment case
CSS Colors and Filter Effects
=============================
Should no-op filters produce different output from no filter?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7100
smfr: This is the problem where filter like blur-0 flattens p3 colors
to srgb per spec but impl, chrome always and some webkit, will
propagate p3 colors through filters
smfr: chris suggested new value for color interpolation, but doesn't
solve problem I'd like. Spec doesn't match impl and I'd like
them not to flatten P3 colors
chris: Suggestion seemed to be compositing is in device color space.
All filter operations or just compositing?
smfr: I believe impl are running filter operations in display color
space which is P3 and close to srgb
chris: Looks okay but is wrong. What I suggested would fix that but
doesn't fix existing issue
chris: Slightly concerned about making it do what you want because
makes it hard to test if it's behaving correct. Not completely
opposed but want to get it right
smfr: svg filters are spec in srgb color space and all constants work
in srgb. One approach would be how to spec those in lab color
space so impl can filter in that
chris: lab not good choice. svg are linear srgb not gamma encoded. I
suggested an extended linear srgb. Outside P3 clor would be
fine. If want to upgrade whole thing to another color space
then xyz would be a better choice then lab.
chris: Doing in extended linear srgb would give you same result if
not clipping
smfr: Might be possible
chris: You and I are attacking different bits of problem and maybe
can do both
smfr: You mean add new color interpolation and change default?
chris: Yeah
Rossen: Possible in current impl or compat issue?
smfr: Won't match what impl do. Would be significant work in one
webkit codepath
Rossen: Academically good, but would be avoided by impl
smfr: Our slow path, CPU based which is 8-bit unsigned. We'd have to
change that to floating point or non-8bit
smfr: Our codepath with GPU is assuming srgb so applying that to
values in P3 which happens to work most of the time. Probably
what Chrome does too
Rossen: chrishtr do you know if that's what you're doing?
smfr: For GPU accelerated you're feeding through P3 color values when
using srgb matrix?
chrishtr: Not sure, need to talk to Chris Cameron (?)
smfr: Would be good to see if willing to change to chris suggestion
chrishtr: Is that in the issue?
smfr: Yes, thing so
chrishtr: I'll re-read and ask Chris
chris: Please also get back to me in issue if something not clear.
linear srgb extended should be GPU friendly
smfr: This should come up with canvas filters too so someone should
think about that case too
Rossen: Sounds to me like we need to have more eyes on the problem
chris: Agree
Rossen: Want to capture proposed combined solution
<chrishtr> +1 to issue
chris: I'd rather write it on the issue instead of try and word on
the fly
Rossen: Alright, please add to issue
Rossen: Anything else on this?
Selectors
=========
Add :modal-dialog pseudo-class
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6965
chrishtr: We discussed at length, almost resolved on modal or
modal-dialog. Question if modal is well defined or slightly
different.
chrishtr: Spoke offline and now agree modal or modal-dialog
chrishtr: I propose we try and resolve on one of those two names
Rossen: Do you have a favorite?
chrishtr: Mine is modal and I think TabAtkins is modal-dialog
TabAtkins: I prefer mine, but okay with other. Temp check of group
would be fine with me
<fantasai> I agree with chrishtr's comment
https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1115460853
Rossen: If this is only about naming I would straw poll. But I see a
queue
fantasai: I agree with chrishtr suggestion to define modal rather
than modal-dialog and define using concept of modal as
defined in comment. Not about being top-layer but about
being a UI that limits interaction to dismiss pr interact
with that thing
fantasai: Can craft a definition that's clear when applies and
doesn't so doesn't need to limit to just dialogs
Rossen: Reasonable. Other opinions?
<masonf> +1 to fantasai's comment
Rossen: Objections to accepting modal?
TabAtkins: Would still like straw poll
Rossen: Okay, let's type opinions
<chrishtr> :modal
<fantasai> :modal
<Rossen> :modal
<smfr> :modal
<plinss> :modal
<dholbert> no preference
<TabAtkins> :modal-dialog
<masonf> :modal
<dlibby> slight preference for :modal-dialog
masonf: Can we also make the resolution that it's as defined in
comments?
Rossen: Yes, modal as defined in the issue
Rossen: Sounds like besides TabAtkins there's only 1 slight
preference for modal-dialog
<fantasai> proposal: :modal defined in terms of limits on interaction
as defined in chrishtr's comment
RESOLVED: Name is :modal for pseudo-class. It is defined as the
element/dialog that restricts interaction to everything as
described in the issue
CSS Text
========
whitespace inside text areas
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/6309
fantasai: This was filed and I wanted to close it out. florian and I
think that there's not really a problem with having
whitespace apply to text area as everything else. A bit
weird how it applies, but author shouldn't ask if they
don't want.
fantasai: Prop: No whitespace magic on text areas, whitespace defines
as on other elements
fantasai: Then Chrome would need to do a slight change for that
iank: History where this came from; I think it was a user affordance
that some websites placed whitespace on text areas and
difficult for users to edit those. That's the history.
iank: Won't object to changing it
Rossen: Other opinions?
Rossen: Prop: Text areas whitespace behaves as it does on any other
element
Rossen: Objections?
smfr: Concerned. Historically this tried to match OS conventions. I'm
a bit concerned about a blanket make it behave like others, but
don't have context to know good or bad
iank: We were trying to match Microsoft Edge
smfr: If I hit space multiple times that means I don't want it
collapsed so have to but multiple nbsps. Does that get rid of
this?
iank: Yes, whitespaces would collapse
smfr: Let's not get rid of that,then.
smfr: I think users expect if you keep pressing space in text input
you get multiple spaces
fantasai: Alternative is in css text 4 proposed to split whitespace
into 2 longhands. One for wrap and the other for collapse.
That text is still under development, but could define the
behavior here and saying UA has an important rule that
prevents collapsing of whitespace and that way it's not
magic
<iank> Our mapping is normal->pre-wrap, nowrap->pre,
pre-line->pre-wrap
Rossen: How far is that definition. Can we resolve here and point to
that? Or still pretty early?
<fantasai> https://www.w3.org/TR/css-text-4/#white-space-collapsing
fantasai: What we've got so far is there text-space-collapse
property. Naming not sure if that's what we want. And
break-spaces doesn't have a setting and need to make that
work. Shouldn't be very difficult
Rossen: Would that be fine if we define the behavior as split control
between collapse and text-wrap.
fantasai: Whitespace sets collapse and wrap at same time. And we
would prevent collapse using UA !important rule
iank: That's fine. We also do this in non-standard plaintext mode
Rossen: That level of control can handle all permutations. Then it
becomes UA specific if you want to match OS or anything else
florian: One thing to check on. If we don't enforce through UI
stylesheet there used to be a spec that claimed UA was
supposed to let user press spacebar repeatedly and treat as
space then nbsp, then space. Are we giving up on that?
Rossen: We treated it as a preserve in Edge. I don't believe we
flipflopped
florian: I know it used to be spec
iank: I don't think we implemented
<smfr> i have a vague memory that Netscape 4 did
<space> <space> ….
Rossen: We're overtime. Happy to resolve or we can do more discussion
Rossen: Objections to resolve this as text area will rely on
text-space collapse and break and those will be defined in
Text 4
RESOLVED: Text area will rely on text-space collapse and break and
those properties will be defined in Text 4
Rossen: We will have enough capabilities to preserve existing
behavior and come closer in terms of impl
Received on Thursday, 5 May 2022 10:14:00 UTC