- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Nov 2022 18:54:19 -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.
=========================================
Administrative
--------------
- The next long-form meeting will be November 30th starting a few
hours before the normal meeting time.
CSS Align & Multicol
--------------------
- RESOLVED: We define the first baseline as the highest baseline in
all the columns and spanners of the multicol (Issue
#7856: First baseline of a multicol)
- Text will be added to make sure we define that relpos doesn't
affect baseline alignment
CSS Grid
--------
- RESOLVED: Change the spec to simplify this sizing and figure out
what tests we need (Issue #7465: How to properly
accommodate margin/border/padding of a subgrid with no
item on the edges)
CSS Align
---------
- RESOLVED: Take the changes listed in
https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091
(Issue #7612: *-items properties might need to resolve
directions early)
- RESOLVED: Use the writing mode of the parent's formatting context
for staticpos (Issue #7599: align-self / justify-self on
abspos elements isn't back compatible?)
- RESOLVED: Align justify axis of non staticpos use writing mode of
their containing block (Issue #7599)
CSS Flexbox
-----------
- The recommendation for issue #3052 (Investigate applying
align-content to single-line flex containers) is to close no
change based on use counter data from Chromium. Before resolving
to close fantasai will verify that accepting the proposal would
cause a different to a sample of the sites found in the use
counter.
CSS Contain
-----------
- RESOLVED: Add a SHOULD requirement for considering the filter
effect extent and interaction with UA margin (Issue
#7711: filter effects and "relevant to the user")
View Transitions
----------------
- RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6
(Issue #7960: CSS selector keywords)
- Property used on DOM elements to tag them for independent
animations: view-transition-name.
- The pseudo-element which directly originates from the root
element and is the ancestor for all container elements:
html::view-transition
- The pseudo-element which animates the size and position for
tagged elements: html::view-transition-group(*)
- The pseudo-element which displays snapshot from the old DOM
element: html::view-transition-old(*)
- The pseudo-element which displays snapshot from the new DOM
element: html::view-transition-new(*)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Nov/0000.html
Present:
David Baron
Elika Etemad
Simon Fraser
Daniel Holbert
Dael Jackson
Ian Kilpatrick
Vladimir Levin
Alan Stearns
Miriam Suzanne
Eric Willigers
Matt Woodrow
Regrets:
Yehonatan Daniv
Jonathan Kew
Bramus Van Damme
Lea Verou
Sebastian Zartner
Chair: astearns
Scribe: dael
Administrative
==============
astearns: On fantasai rec we're going to skip items 5 & 7. Any other
changes?
astearns: chris reminded us that our charter is up for a vote
astearns: Please ask your AC rep to go vote. We need some engagement
there to keep the lights on
astearns: Please everyone on the call or reading the minutes go bug
your rep
astearns: Second thing is another long form meeting Nov 30. A couple
extra hours before the regular time.
<@fantasai> ->
https://lists.w3.org/Archives/Public/www-style/2022Nov/0001.html
astearns: I'll set up a calendar invite and we'll get a meet link soon
CSS Align & Multicol
====================
First baseline of a multicol
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7856
iank: Basically currently the spec says to take the first baseline
from the first column
iank: This has a couple of poor side effects
iank: Came up while Morton reviewed new last baseline behavior
iank: What can happen now is that if there is no content that
produces a baseline in the first column it has no first
baseline but might have last from another column
iank: Two potential solutions. First is mirror last baseline and take
highest of all content
iank: Second is take the first baseline of the first non-empty thing.
First thing that produces a baseline
astearns: And we are taking the lowest baseline for last baseline
because it's often the case the first column has a much
lower baseline
iank: Correct. Not always, quite common for it to come from later
astearns: For symmetry taking highest baseline seems like might be
better. No strong opinion
dholbert: I was going to say roughly same. Like simplicity of first
that exists but asymmetry unfortunate
iank: Pros and cons. First baseline if you're trying to align it will
roughly give you always first line on first column. Highest if
you switch to smaller font size in another column that would be
first highest. So pros and cons. Happy with either
dholbert: Do we generally have symmetry between first and last
determined in other layout modes?
iank: We broadly have symmetry.
iank: Ignoring some convoluted table case. But wouldn't be an issue
to break here. We found this because writing last baseline
logic, noticed the asymmetry and went that's weird
astearns: In terms of what effect you want to have, presumably you're
trying to align some other element with first baseline.
First column will often be taller in a heading. If we take
first baseline of column with a baseline the thing outside
will align with the title. If we take highest it will align
with first body text. I can see either being useful
fantasai: I think you described what is the most likely scenarios
fantasai: We have an issue open on selecting which element you want
to take baseline on. If we went highest and you wanted
first you would be able to request that. That might be a
reason to take highest
iank: Fine with that
<@miriam> I like that approach
astearns: And that way we get symmetry.
fantasai: We haven't worked out how this interacts with splitting
element but can define to work
astearns: Proposal: We define the first baseline as the highest
baseline in all the columns and spanners of the multicol
astearns: Objections?
dholbert: This is symmetrically defined with last baseline. Does that
take relpos into account?
iank: It does not. Out of flow it does not and baselines are
pre-relpos
dholbert: No objection. Just wanted to check
astearns: Good to check we're defining as in-flow
iank: Probably don't have language but all engines are same
RESOLVED: We define the first baseline as the highest baseline in all
the columns and spanners of the multicol
ACTION: fantasai to make sure we define that relpos doesn't affect
baseline alignment
CSS Grid 2
==========
How to properly accommodate margin/border/padding of a subgrid with
no item on the edges
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7465#issuecomment-1265913276
astearns: Can you take fantasai?
fantasai: Yep. For subgrids layout we have a bunch of rules for
laying out stuff within a subgrid as part of parent
fantasai: We figure out which columns and rows items in subgrid
assigned to and layout as if in parent
fantasai: Difference is how we handle margins and padding. Figure out
total amount of margin padding border for items at edge of
subgrid and add as magic margin to inflate auto-sized
fantasai: When you layout in grid takes into account extra margin and
padding I should stay away from
fantasai: In order to do that accurately we have a bunch of rules to
insert hypothetical items at edge of subgrid to make sure
even if it's empty it's sized
fantasai: Spec rules and browser impl are different. We had a complex
rule to insert item with span of one then with span of two
and however many we need to cover the spans and make sure
there's enough space
fantasai: Problem is that it creates a bunch of space and when you
put items down ones in second column don't have magic
margin. Doesn't work out to match up in that way
fantasai: Browsers don't do complex spanning. Only put items in first
and last track. If you have fixed width 20px first track
and second is auto and subgrid has 40px of padding the
padding crosses into second track and items don't know
about it.
fantasai: If we wanted to figure that out it's quite complicated to
figure out the margin you want to add. None of the browsers
are doing it and not sure it's necessary to do the complex
thing
fantasai: Question for WG is do we simplify spec down to only look at
first and last or investigate what we can do to try and
make it work for inner tracks?
fantasai: Our suggestion is simplify down and see what happens, but
open for questions and comments
astearns: Test cases we removed because missing spec text. Would
those become valid?
fantasai: Don't know. I think whatever we do we'll want the test
cases but maybe different references
iank: I support removing hypothetical item concept. I believe MS
folks studied this and super hard to get correct
mattwoodrow: Also support simplifying it. I spent a bit of time
trying to figure out how to impl and very complex when
you nest grids
fantasai: Will still need some margin padding added, it's just not
leaked to multiple tracks
astearns: Is there interop in browsers? Or are we coming up with
something that might need bug fixes?
iank: From what I've seen broadly speaking subgrid is lightly tested
in some areas so wouldn't shock if there are subtle differences
between browsers
fantasai: Either way should make sure have enough tests. Might be
some bug fixes but closer to interop on simplified version
astearns: Proposal: Change the spec to simplify this sizing and
figure out what tests we need
astearns: Objections?
RESOLVED: Change the spec to simplify this sizing and figure out what
tests we need
CSS Align
=========
*-items properties might need to resolve directions early
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091
fantasai: There was an issue raised against how we interpret various
items on abspos
fantasai: Alignment spec says when you abspos a box with specific
offsets alignment prop apply in inset rectangle.
fantasai: You can stretch, center, left align in inset box.
fantasai: None is impl yet, but that was the direction
fantasai: What we were saying is when you abspos the box you're in a
formatting context that's not your parent's that you're out
of flow from
fantasai: Spec that align items property of parent don't effect your
alignment as an abspos
fantasai: Problem we ran into is when staticpos there's existing
behavior where alignment prop do effect your position
fantasai: Seems like we're at the summary we linked to
<@fantasai> https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091
fantasai: If you are abspos and not staticpos the align- and
justify-self properties align you in inset box. If you're
static they align you in staticpos rectangle
fantasai: If you're align or justify-self is auto and you're not
staticpos you ignore parent. If you are staticpos we look
at -items of your parent and use alignment based on that
fantasai: [reads out comment]
fantasai: That's my understanding of where we're at. Bringing to WG
to ask for review and decide if that makes sense
iank: One thing good to clarify is what writing mode does
align-self:start operate in when insets are set?
fantasai: I think that's the next issue
iank: This is just about staticpos rectangle?
fantasai: That's the focus
iank: Proposal is staticpos rect operates in writing mode direction
of parent?
fantasai: Yeah. I think it would need to for flex stuff follow parent
formatting context
iank: Okay. So if it's staticpos it's within the writing mode of the
parent. I think that's probably fine.
iank: Side note- do we have an open issue for when staticpos
rectangle is fragmented?
fantasai: I don't believe we do I think fragment like whatever it's
derived from
iank: There's complexities I can add to an issue
astearns: What we're talking about would apply to current grid and
flex children but the rest is waiting on impl for other
formatting context?
iank: As far as I understand this is broadly status quo for grid and
flexbox
fantasai: I believe so. Might be clarifying for grid but this is for
flex
astearns: As much as I followed it seems good to me
astearns: Other comments?
astearns: Shall we resolve on taking the changes in
https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091
?
astearns: Objections?
RESOLVED: Take the changes listed in
https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091
align-self / justify-self on abspos elements isn't back compatible?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7599
fantasai: This is how do we resolve the axis it operates in. When
staticpos we use axis as defined by the formatting context,
the parent formatting context
fantasai: I think we can resolve on that and then address what to do
for non-staticpos
astearns: Proposal: Use the writing mode of the parent's formatting
context for staticpos
astearns: Sounds like that's what we need for web compat?
iank: I don't have data but I would wager people are relying on this
working as is
astearns: Objections?
RESOLVED: Use the writing mode of the parent's formatting context for
staticpos
fantasai: Follow-up for non staticpos. Spec says for abspos you
resolve justify and align based on containing block's
writing mode. Rather than checking parent. Reason is
pulling from deeper context and trying to layout with other
things should use same reference axis
fantasai: That's why we defined it that way. Is that fine or do
something different?
iank: Broadly fine. For clarification if you've got a line item on
containing block does that effect out of flow element?
fantasai: If out of flow is not staticpos it does not look at align
items on anything
iank: Makes sense
iank: The quirk that falls out is align-self:center if you're
staticpos in one axis and not in the other axis it will effect
both axis
fantasai: Yeah. I think it's a little weird but anything else is
weirder in more common cases
iank: Yeah, fine with that.
fantasai: Align justify axis of non staticpos use writing mode of
their containing block
RESOLVED: Align justify axis of non staticpos use writing mode of
their containing block
iank: Clarification- when doing this you need to say staticpos in a
particular axis
fantasai: Yeah
CSS Flexbox
===========
Investigate applying align-content to single-line flex containers
-----------------------------------------------------------------
Proposed Resolution: close this as Rejected due to web compat
github: https://github.com/w3c/csswg-drafts/issues/3052#issuecomment-1226112918
astearns: Proposed resoution is no
fantasai: When flex was released we defined align content only
applies to multiline. Aligns the flex lines. Could apply to
single line in which case you could top align a bunch of
flex items and then center align the line
fantasai: Seems there are enough web pages expecting it to not have
an effect that we could not change based on chrome data. We
think we can't fix this and should add to list of mistakes
iank: I looked last week quickly at use counter. It will over-count
potentially. But it's high enough that there are sites that
will rely on this so I'm fine. Could do a sample of sites but
it's fine
astearns: If you're worried about over-counting by an order of
magnitude...
iank: Even if it is it's a large number of sites
fantasai: Yeah. I think it's unfortunate but we may have to live with
it. Curious to know what's being over-counted and if
use-counter could tweak
iank: Not easily. Would have to run the scenario where not stretching
items to container which is not easy. That's how I thin it's
over-counting. Would need to layout twice.
iank: I think way forward to investigate is look at sites and see
which flexboxes have this and if they would change
fantasai: Is there a way to get a sample of the list?
iank: Go to the issue on the chrome status page. Below the graph
there will be a list of urls that triggered the counter
fantasai: I'd be down to check the first 20 or something and see
astearns: If you want to do that it would be great. Would you like to
keep issue open until you do it? Or resolve?
fantasai: Sure, I'll need something to track.
fantasai: So just load these pages and look at it?
iank: Yeah, so it will be...it's by origin. What I find when doing
this is if you hit the home page and have some JS to query
elements more or less the home page will have it.
<iank> https://www.chromestatus.com/metrics/feature/timeline/popularity/4057
fantasai: If I find most of these don't hit a change we can revisit.
If not I'll close out
astearns: Okay, leaving this as is
ACTION fantasai look at effect this
https://github.com/w3c/csswg-drafts/issues/3052#issuecomment-1226112918
would have on actual websites
CSS Contain
===========
filter effects and "relevant to the user"
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7711
florian: Discussed similar for contain 1. Filter effects can be
non-local. Like blur can draw from broader area to render
what you want. Kind of defeats containment a bit. Was
limited enough it was fine.
florian: Similar issue on content-visibility:auto
florian: Effects of content-visibility:auto change depending on if
it's relevant to user. And one of the ways is if it's on
screen.
florian: Spec has provision to not be considered if it's close to
onscreen by a margin. Not clear how it's defined, but text
anticipates it's a fixed size
florian: For filter-effects there is no bound for how far reaching it
might be. Very large is unusual but not impossible.
Depending on how big the UA margin and filter effect are it
might have a slightly offscreen element have an effect on
the filter.
florian: Probably negligible effect, but tiny is not none.
florian: Suggest a small alert to spec that not only is the element
relevant when it's close to onscreen but also that rendering
it is necessary to do filter effects
florian: It's probably a small error but need to decide if have small
error or complete correct
astearns: Long range filter effect will blink into existence once
small threshold is hit?
florian: Let's say you have bright red thing offscreen in
content-visibility:auto and a blur. Without the change the
element could come close enough that it should bleed red but
doesn't impact filter. But instead it doesn't render until
it gets close enough and then it blinks into sight
dbaron: I wanted to say I think even if it may or may not be impl
this way I think the spec should describe them additively.
content-visibility being in range of the screen is you want
it ready in case it scrolls on. I think better to describe
additively but allow flexibility
florian: Makes sense.
dbaron: By additive if what you're trying to say is if scroll within
50% of screen, but you want it to be if you're in 50% or
relevant to some filter pixels onscreen...
vmpstr: A little concerned about impl efficiency for this. In order
to know about content under a stack of pixels will effect on
screen doesn't seem trivial
vmpstr: To run that on every scroll would be potentially slow. A
little concerned about spec being strict on this
dbaron: I don't think it should be strict. But I think most impl have
this sort of code because needed for invalidation. But code
can be conservative and make approximations
vmpstr: Typically done in graphics stack. This would then cause us to
go back to style when we detect it and decide you need to be
rendered. I don't think at the time when intersectionObserver
determines intersection I don't think we have good
information about filter effects
dbaron: That's certainly believable. I know Gecko code better then
chromium though have forgotten some
florian: When we resolved for containment we said it was easy enough
to track. If we could allow something to spec to allow the
correct and encourage. Maybe require is nice.
florian: That said, number of cases where it's user important will be
rare. Maybe okay to sacrifice accuracy
dbaron: I think reasonable for should
vmpstr: Agree with that
astearns: Only concern I have is testing if it's a should
florian: Hard to test regardless because not only is it a should
there's UA defined fixed-size margin. How far offscreen you
should be is hard
astearns: Proposal: Add a SHOULD requirement for considering the
filter effect extent and interaction with UA margin
dbaron: One comment on testing. SVG filters has things easier to see
than blur, but I don't think there are css versions
iank: But can reference svg filters. But I think they'll make it more
complex
<@dbaron> (displacement map)
florian: Interestingly that makes it more relevant. If it's just blur
you don't get much color but displacement moving pixels you
would see it
astearns: Any concerns?
RESOLVED: Add a SHOULD requirement for considering the filter effect
extent and interaction with UA margin
View Transitions
================
CSS selector keywords
---------------------
github: https://github.com/w3c/csswg-drafts/issues/7960
fantasai: This is about naming various pseudo elements for view
transitions. Proposal for almost all in the issue. Could
probably resolve all except 4
astearns: Proposal is take proposals for items 1, 2, 3, 5, 6 in the
issue
astearns: Objections on those names?
RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6
fantasai: Item 4. view-transition-group we just accepted gives a
grouping mechanism with a hierarchy. In item 4 it's a leaf
with one or two images
fantasai: It exists because need isolation for blending. Item 4 is to
name that almost leaf grouping. List of names is the
proposed ones
fantasai: Names fall into two sets. Ones that include image, ones
that have grouping word, and ones with both
astearns: And this will not be used as much as rest?
fantasai: Yes
PaulG: Confirming these are pseudo element images snapshotted and
will not hit ax tree or carry content?
fantasai: Right
PaulG: Thank you
astearns: We're at time. We'll come back to the issue for the one
remaining thing
astearns: Thanks everybody for calling in. We'll talk next week
Received on Thursday, 3 November 2022 22:54:58 UTC