- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 7 Nov 2021 17:08:28 -0500
- 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 Contain
-----------
- RESOLVED: Elements with ancestors of content-visibility:hidden will
have no boxes while in top layer. If removed from top
layer they get their box back (Issue #6728: Top layer
interactions with content-visibility: hidden)
- RESOLVED: If the subtree of an element contains a top-layer element
it is relevant to the user (Issue #6727: Consider top
layer elements 'relevant to the user' for
content-visibility: auto)
- There is agreement that issue #4598 (Static ranges and css-contain) is
a problem that should be solved and the solution should be as
limited in scope as possible. The result would need to be
observable to the author so they can respond and the current
proposal doesn't have that observability. The discussion will
continue on github to develop a solution.
- RESOLVED: Accept iank's proposal (
https://github.com/w3c/csswg-drafts/issues/6426#issuecomment-941205671
)
to guarantee full layout algorithm is always forward
moving (Issue #6426: Ancestor Layout Loops with
Single-Axis Containment)
- Once the edits for issue #6426 are in the spec, a request will be
made for FPWD of Contain 3.
CSS Transforms
--------------
- RESOLVED: Publish WD for Transforms L2
- RESOLVED: Add dbaron as co-editor of Transforms L1
CSS Cascade
-----------
- RESOLVED: Add the cssom rules as .name and .namelist (Issue #6576:
Cascade Layers need CSSOM support)
- RESOLVED: It [revert-layer] would revert the style attribute and
nothing else (Issue #6743: revert-layer keyword in style
attribute)
- RESOLVED: revert-layer reverts animation origin and nothing else
(Issue #6749: revert-layer keyword in keyframes)
CSS Highlight API
-----------------
- RESOLVED: Republish Highlight API
CSS Values
----------
- RESOLVED: Punt attr() and toggle() to Level 5 (Issue #6753: Punt
attr() and toggle() to Level 5)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/25
Scribe: dael
CSS Contain
===========
Top layer interactions with content-visibility: hidden
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6728
vmpstr: Content-visibility: hidden skip their contents meaning they
don't paint. When element is in top layer changes topology of
the tree so element is hoisted to root level
vmpstr: Proposal is we should say it doesn't paint or generate layout
box
vmpstr: Could ensure it does generate and paint, but precludes a lot
of the optimization
vmpstr: Another is we refuse to allow in top layer, but also seems
inconsistent
smfr: The top layer spec says that top layer elements, containing
block is initial contain block. Hoisted out of anything they're
inside of. Why is content-visibility different?
vmpstr: It's hoisted out of all containment. There's no way to
optimize performance of this because then have to always keep
rendering up to date. Not sure how common case is. I was
hoping this could have the same rule as display:none
smfr: That means we need a new concept in css that not containing
block or z-order
TabAtkins: Just say descendants don't generate boxes liked
display:none.
smfr: How does that impact rest of the dialog?
TabAtkins: You can't focus something that doesn't have a box. That
gets skipped
smfr: I guess same as calling show dialog on display:none
TabAtkins: yes
TabAtkins: I put a comment in the issue. Except explicit difference
in spec, anything that diverges from display:none should
be looked at with suspicion. If there's no reason for
difference should be same as display:none
chrishtr: I agree with that outcomequeue
chrishtr: Wanted to clarify tricky situation is you have an element
skipped by virtue of having and ancestor. You have a
skipped thing with an unskipped ancestor which is bad.
That's why Vlad said we'd lose optimizations. If you treat
like display:none where it has a box but if in top layer it
becomes like display:none
chrishtr: Consistent and simple. I don't think there's a concept to
hoist something to the top of tree and make it visible
Rossen: Validating an assumption, none of the content elements are
a11y, right?
vmpstr: Correct. Can be targets of aria label, but not exposed
Rossen: Cool
Rossen: Sounds like a good approach. Other thoughts?
smfr: content-visibility: auto implications?
vmpstr: That's the next issue
Rossen: What is resolution?
Rossen: Option 1?
vmpstr: Yes
chrishtr: If there is a content-visibility ancestor there is no box.
It's in the top layer, but has no box
Rossen: Prop: Elements with ancestors of content-visibility:hidden
will have no boxes while in top layer. If removed from top
layer they get their box back
Rossen: Objections?
<smfr> is the “it’s in the top layer” observable?
Rossen: smfr does the irc question you have need to be covered?
smfr: chrishtr said in the top layer, is that observable? If so,
through dom?
chrishtr: Discussed if it was observable, but not sure
vmpstr: Right, I don't know the answer to this
chrishtr: Might be if you try...don't know
smfr: If it has a backdrop is that display:none too?
vmpstr: yeah, it would be same
chrishtr: Backdrop pseudo spec has an immediately proceeding box. And
there's not box. Might need to clarify text but should be
same
Rossen: Objections?
RESOLVED: Elements with ancestors of content-visibility:hidden will
have no boxes while in top layer. If removed from top layer
they get their box back
Consider top layer elements 'relevant to the user' for
content-visibility: auto
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6727
vmpstr: Text says we skip the contents if the element is not relevant
to user. Defines relevant as things that have focus or
selection
vmpstr: Proposal is add if content-visibility:auto descendant is in
top level it is relevant and not skipped
chrishtr: Unskips content?
vmpstr: Yeah, if you have offscreen content-visibility:auto it would
appear in the top layer and the subtree would be rendered
chrishtr: Entire tree including offscreen is relevant and not skipped
vmpstr: Can't optimize out because have to display in top layer.
Can't use same detection for visibility because escapes paint
containment
vmpstr: If it escapes top layer assume it will be visible
chrishtr: If you have description of content-visibility:auto and you
full screen the entire subtree will be made visible
vmpstr: Correct
chrishtr: Including recursive ancestors. Okay. I think it's fine
Rossen: Any other comments?
Rossen: What's the proposed text?
vmpstr: If the subtree of an element contains a top-layer element it
is relevant to the user
Rossen: Objections?
RESOLVED: If the subtree of an element contains a top-layer element
it is relevant to the user
Static ranges and css-contain
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4598
dandclark: The problem that this issue is trying to address is if I
have a highlight with a static range that crosses a
contain boundary, if I remove a node holding one boundary
point it causes entire highlight to not paint because it's
not valid
dandclark: Proposed solution is not to paint highlights that cross
contain boundaries. Assumption is it's not a thing authors
want
dandclark: My understanding is some agreement from editors. Would
like to confirm. Also suggestion from sanket this perhaps
have same behavior for range to make it consistent to
prevent dev confusion
dandclark: Proposal would be highlights backed by rangers or static
ranges should not be painted if cross a boundary
florian: Good summary. Initial was just static but going for
consistency why not. This could be paint containment only,
but given no use cases we can make it all for simplicity
fantasai: Wanted to ask what we'd do about when highlight is similar
to selection which frequently crosses the tree
fantasai: Contain is used for a lot of things and not clear to me we
want to disallow selection type highlights. Something to
consider
florian: Good point. Need to look into in practice where is contain
used. It's component-y. Probably not sprinkled through
textual elements. But you're right selections cross
boundaries.
fantasai: I think you should not restrain for simplicity. I think you
should if it's necessary for impl reasons to restrict
<fantasai> minimal necessary restriction
Rossen: dandclark to confirm, are you saying if I construct the range
as you described in which case it will not be painted. From a
dev PoV the range is observable; I can inspect it. But
visually that is not going to paint based on circumstances
range falls into
Rossen: Sounds to me pretty unstable approach. To fantasai's point I
can imagine flickering if I move the ranges. Would be great
if there's a CSSOM or other eventing that interacts or
rejects ranges. Strong rejection than avoid paint
Rossen: That was it could be handled by author. It will be within the
hands of developers
<fantasai> +1 to Rossen's point, if we are rejecting a range it needs
to be made obvious to the author
<fantasai> not just a failure to paint
Rossen: From user PoV agree with fantasai that selection today is
doing this quite a bit
florian: Two things we could do. 1: go back to having minimal which
is static range only on paint containment only is invalid
florian: On top of that we might want to add an event or observer
that lets you discover something has happened. Hard to
design that on the fly
Rossen: Shouldn't. I think the feedback here is enough to go back and
design stronger.
florian: I think we could resolve on the type of range and
containment, but not the whole story
dandclark: I think we're coming to resolve on minimal restriction.
For highlight backed by static ranges that cross a paint
containment boundary are not painted
Rossen: Opinions?
florian: Support and then I think there's more to look into
Rossen: I wouldn't object, but unsatisfying because opening a problem
that makes the discovery of these ranges less obvious to
author
florian: There is an inherit contradiction between range and
container. Not a problem in both direction, but range that's
outside to inside a containment boundary and then you make
the range not meaningful you want to stop painting. There is
a contradiction somewhere
Rossen: Yeah. A little unsatisfying. Consider you're the dev on this
editing app with ranges and users are complaining they don't
see highlight. How do you chase that? If not observable it
will be hard to fix. Even if it's legitimate.
fantasai: Author will be able to reproduce the error if they select
the same range because would refuse to paint. But on the
fly can't tell via JS
florian: Another approach, though heavy, is if an author tries to
create a range crossing an boundary or restyles to create
boundary we forcibly split the range to outer and inner
Rossen: It's a little better
Rossen: But then again not sure a misspelled word is good if you
highlight half of it
florian: You wouldn't highlight half, but do both with separate
ranges. Selection use case is more likely for this. Range
for outer part of selection and range or inner part. If you
change inner part to no longer make sense you would no
longer highlight inner
Rossen: I'm with you. Feels like we're designing on the fly. Authors
will have all kinds of collections and if you create ranges
under you need discoverability. I think there's work to be
done here
Rossen: Fine with the problem and recognizing we don't want to have
these ranges. But if we resolve on something that's strictly
worse perhaps we should work more
florian: I want to preserve containment invariance. But how we do it
needs more thinking
Rossen: What if we put it back onto GH and when you work it out,
sounds like you're starting to come up with solutions, work
it out and then come back
Rossen: Sound reasonable?
florian: Think so
dandclark: Want a gauge on dom observably vs UA trying to be helpful
with console warnings. Are we feeling have to be dom
observable?
florian: I think it's not inherently wrong to want static ranges.
Highlight can be anywhere. We should do something that lets
author react when it happens
Rossen: And being observable through script is key so they can take
an action
Rossen: Let's end here. I think there's good next steps.
<br type=until 22 minutes after the hour>
Ancestor Layout Loops with Single-Axis Containment
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6426
miriam: It turns out this is hard. We knew that
miriam: I tried to document 4 known instances where content changing
size on 1 axis, generally block, has impact on available size
for inline. So if we try and contain inline only get a loop
miriam: Generally have a pattern where outer ancestor, element
contained on inline axis, inside of that contents responding
to container query
miriam: With those three nested bits, a few of the issues are
orthogonal writing modes. 2 other cases that are common.
Ancestor is overflow scroll and the contents can trigger
scrollbar on ancestor which changes inline space available
miriam: Another is floats as they get taller or shorter how they
stack might change
miriam: In my first document I wrote out the brute force solutions.
They're not ideal for users. iank's idea is better
iank: I need to study one of these a bit more but they all fall into
effectively we layout a child once with given space, read child
height, and based on that give it a new available space.
iank: Fundamentally need to make sure we never walk backwards. This
is true today
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9775
iank: I pasted in irc an example ^
iank: Orange box and inside it has a child with an aspect-ratio.
Consider width first, get height where we can't fix. Then
consider second of 50px. All engines walk forwards like that.
iank: We don't try and say now that I'm this height maybe I could fit
back here after all
florian: Do you mean this is the end of the line principle we don't
need the pieces miriam highlighted or that it solves them
all?
iank: I think we state it and it solves them all. Orthogonal. We
layout with one set of constraints, layout, adjust. We move
forward.
florian: I'm a bit concerned this is different than float. We should
avoid making css accidentally stateful
florian: Float, ancestors are not effected by float in the same way
florian: Roughly I feel the way miriam proposed is annoyingly
specific but need to do it to avoid vague or stateful
iank: I don't think it's stateful. We have a bug on orthogonal, but
with that case to compute intrinsic size for the orthogonal
child we need to lay it out with some available size.
iank: We layout with that size. May effect size of the parent. Now
when we do layout pass we give orthogonal child different
constraints and it lays out differently
florian: That sounds true
iank: If you can come up with a case you think is stateful happy to
access
iank: Orthogonal is hard because engines have a lot of bugs. miriam's
example shows a bug
florian: For scrollbar and padding do you think we can get away
without hatchet miriam proposed?
iank: I think so. Aspect-ratio is fine, floats is fine, I think
classic scrollbars is fine as long as you add them in a
particular way. We'll slowly add scrollbars to get to a state.
I think it should be okay
florian: I thought if you didn't have miriam's approach you would get
a different result if you start on a 800 px window different
result then if you start bigger and shrink
iank: No, shouldn't be an issue. That's a browser issue and should be
fixed.
iank: If there is an ambiguous set of steps where we need more
specific order we should do that
iank: When forming a new context in relation to floats we had a
specific order on how people should walk through. Pretty much
everything else falls into that
florian: If we go that way we can have a spec that's less magic but
we need to be very precise so it's stable and interop
iank: yes
florian: Can someone implementing list the steps? Undefined would be
bad
iank: Depends what you mean by define
iank: We don't have a spec for block layout but we have resolved how
floats behave.
iank: I can describe how this works for orthogonal children, I think
that's well defined
florian: My ask would be for the 4 cases miriam highlighted which I
think are specific enough, could you either point to the
spec language that make them non-problematic or propose
sufficient spec text?
iank: I can work with miriam on that
Rossen: Sounds like we're forming consensus around going forward with
reasoning captured in the issue by iank. Additional exercise
to figure out where changes have to land
Rossen: Anything else to add here? I see people on this issue chimed
in
florian: Great if we can go there. The things proposed are cludges we
thought unavoidable. If they're avoidable, great
Rossen: In terms of solution anything else to add here?
dholbert: I think your example with aspect-ratio is a good case for
something that behaves like this without needing container
queries. Good extension of that
iank: I think I can create examples as well with time
Rossen: We call them test cases; please add them :)
Rossen: Let's resolve on path forward. And it'll be iank for you to
figure out where edits should go
Rossen: Proposal: Accept iank's proposal to guarantee full layout
algorithm is always forward moving
florian: Sort of important to get to this in a timely manner. This
discussion has been going on for years in GH. If there is a
solution, great, but I'm worried we will force other
browsers to reverse engineer Chrome or do something else if
we don't write it
chrishtr: Resolution to go with iank proposal?
iank: Write it down at least for the examples. Part of the problem is
large parts of some algorithms are undefined. Can spec how
things should walk forward
chrishtr: So parts of algo that intersect need to be written
iank: Part of issue is float not well defined. List of side effects.
Most recent for float layout is in a GH issue but not in spec.
Pointing to the various places we've resolved
iank: For intrinsic size we have it written
florian: I don't think iank proposal is not self contained enough.
It's an approach we need to look into more details.
Rossen: Yes. We don't have specifics
florian: We agree to try and solve that way. And we go that way and
we come back to resolve on details
Rossen: Have proposed path forward. Don't have details about
specifics, but approach makes sense. You've made your point
and people agree.
fantasai: We had previously declined to publish fpwd because of this
issue. If we get to a point we're okay with the issue we
should publish fpwd
previous proposal: Accept iank's proposal to guarantee full layout
algorithm is always forward moving
Rossen: That's the proposed resolution. Objections?
RESOLVED: Accept iank's proposal to guarantee full layout algorithm
is always forward moving
FPWD for contain 3
------------------
florian: We haven't done it yet, though
iank: We've done it in that this is what chrome impl does today
florian: Which is what I'm a bit uncomfortable with. Spec says do it,
people have to guess
Rossen: Let's not publish fpwd yet
chrishtr: Once there's text in the spec that encodes the proposal in
an algorithm is that sufficient?
fantasai: I think we should put what iank described in contain 3. I
think if dbaron signs off we can likely all be happy. I
propose iank drafts text with florian help and have dbaron
review
florian: Agree. Even if we state as high level principles let's do
that
CSS Transforms
==============
Republish transforms
--------------------
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2021OctDec/0037.html
dbaron: I sent a long message to group list pointing to changes and
calling out 2 aspects
dbaron: One was that one of the edits is only half done and I'd like
to publish anyway because other half is complicated
dbaron: Other is the set of changes that don't have WG resolution. I
listed and described them.
dbaron: Given those things in my email wanted to know if group was
comfortable resolving to agree on the things there without
resolutions and to publish a new WD
<florian> looked good to me
<astearns> +1 to publishing
<smfr> i am fine with it
Rossen: See a bunch of +1 to publishing
Rossen: Objections?
<fantasai> +1 to publishing, given smfr's approval
RESOLVED: Publish WD for Transforms L2
<chrishtr> congratulations!
dbaron: Second thing is to ask to be coeditor of transforms L1. I am
not currently
Rossen: Ask and you shall receive
RESOLVED: Add dbaron as co-editor of transforms L1
CSS Cascade
===========
Cascade Layers need CSSOM support
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6576
<fantasai> https://github.com/w3c/csswg-drafts/issues/6576#issuecomment-943858864
miriam: My understanding is we wanted 2 interfaces, one for statement
and one for block rules
miriam: block rule has read only attribute of the name of the layer.
statement would have read only frozen array of strings
miriam: Does that cover it?
fantasai: Question was what to call them: .name or .nametext vs
.namelist
TabAtkins: .names
fantasai: .name and .names seems tricky
TabAtkins: yeah
fantasai: .namelist regardless of the other being .name or .nametext
Rossen: .name is shorter
fantasai: Great. resolve on that
Rossen: Objections or suggestions?
RESOLVED: Add the cssom rules as .name and .namelist
revert-layer keyword in style attribute
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6743
miriam: Similar. Question is what does it do in context where layer
is not clear. In this case in style attribute. What happens?
fantasai: Had recently switched style attribute to be its own origin.
Natural fallout is it would revert the style attribute and
nothing else.
Rossen: Sounds reasonable
chrishtr: Is that option 1?
TabAtkins: Yes
Rossen: Other ideas or objections?
RESOLVED: It would revert the style attribute and nothing else
<TabAtkins> basically same as doing 'revert-layer' in unlayered
author styles
revert-layer keyword in keyframes
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6749
fantasai: Same question. Animations are their own origin
fantasai: We have a special rule for revert keyword that causes
animation origin to be part of author origin. For
revert-layer makes sense to say it reverts animation origin
and nothing else
Rossen: opinions? objections?
chrishtr: This is the recommendation from xiaochengh?
chrishtr: Seems like?
Rossen: He said he doesn't have strong opinion
chrishtr: Okay
Rossen: Not hearing objections
RESOLVED: revert-layer reverts animation origin and nothing else
CSS Highlight API
==================
Publication
-----------
<fantasai> https://www.w3.org/TR/css-highlight-api-1/
fantasai: We should publish since haven't since last year. Good to
get it published
<fantasai> last publication December 2020
Rossen: Sounds great
astearns: Needs changes?
florian: I think we had a resolution and I didn't follow up. Okay to
double resolve
RESOLVED: Republish highlight API
CSS Values
===========
Punt attr() and toggle() to Level 5
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6753
fantasai: We think we should drop from L4. attr() and toggle() not
quite solid. A bunch of the rest of the spec has been impl
fantasai: Narrowing spec to prepare for CR
Rossen: Objection?
oriol: Question on this. I wonder if mix() should also be deferred.
Added recently and issues about syntax
fantasai: I think problem with mix() is need it to serialize
interpolation of certain transforms. I think we should keep
it and work out the issues
oriol: Okay
Rossen: Hearing no objections
RESOLVED: Punt attr() and toggle() to Level 5
Received on Sunday, 7 November 2021 22:09:11 UTC