- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Mar 2024 19:42:53 -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.
=========================================
+++Anchor Positioning Breakout+++
Containment makes it difficult to use anchor positioning with
container queries (Issue #10040)
-------------------------------------------------------------
- RESOLVED: Undo the previous resolution - anchor names are not
blocked by any form of containment. But they *are*
blocked from escaping a "skipped content" element
- RESOLVED: And if a positioned element is "relevant to the user",
any element it's anchoring to remains "relevant to the
user" as well
Define interaction with the cascade in `@position-try` (Issue #9149)
--------------------------------------------------------------------
- RESOLVED: Fallback styles live in a new "Position Fallback Origin".
They revert like Animation styles (back to User origin)
Is !important allowed in @position-try (Issue #10058)
-----------------------------------------------------
- RESOLVED: !important is not allowed within position-try
When to invalidate "last remembered position-try option"?(Issue #10099)
-----------------------------------------------------------------------
- RESOLVED: Forget if position-try CSS changes or any of the try
blocks change
border-radius and border-image should be "border properties"
(Issue #9245)
------------------------------------------------------------
- RESOLVED: No change to spec
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0019.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins Bittner
David Baron
Kevin Babbitt
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Chris Harrelson
Jonathan Kew
Ian Kilpatrick
Roman Komarov
David Leininger
Vladimir Levin
Rune Lillesveen
Peter Linss
Khushal Sagar
Miriam Suzanne
Bramus Van Damme
Scribe: chrishtr
Scribe's scribe: TabAtkins
Anchor Positioning
==================
Containment makes it difficult to use anchor positioning with
container queries
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10040
miriam: Right now CQ relies on on side effects from anchor
positioning, because anchor names are contained by style
containment
miriam: This will also likely cause a problem for other areas such as
names for scroll-driven animations
miriam: Developers will be frustrated if one stops the other from
working
chrishtr: Proposed resolution (from the issue) is undo the previous
resolution, and have anchor-names no longer be contained by
style or layout or size
chrishtr: So that anchor positioning and CQs can work well together
chrishtr: However, we still need skipped subtrees (from
content-visibility: auto) to block those anchor names
<vmpstr> auto or hidden, presumably
chrishtr: Because when such content is offscreen and skipped, we want
the UA to be able to skip rendering entirely, which
requires not doing the layout necessary to position the
anchor
chrishtr: That's fine because the content is offscreen anyway, so
anchoring to is isn't useful.
miriam: Wonder if layout containment is also an issue
chrishtr: My proposed resolution also has it escape layout
containment, which I think addresses your concern
kizu: Some of the cases we'll be fixed by popover in the top layer,
it'll escape containment
kizu: But I think escaping via fixpos escape
TabAtkins: It's just that anchor names escape, not the positioned
element
kizu: Okay, I thought there were other cases talked about in the
thread, but if it's just anchor names that's okay
chrishtr: Right
miriam: But my issue is if an element inside a container is able to
position relative to an element outside the container; that
violates layout containment of the container for the abspos
chrishtr: Yes, it would be contained.
emilio: I misunderstood Chris about whether this affects layout
containment
emilio: I'm confused - would the anchoring work?
emilio: Wouldn't this mean you can't anchor anything outside your CB
chain, right?
emilio: And if you hit a fixpos CB that prevents you from going
further up, right?
chrishtr: The case we're addressing is an element outside the CQ
being able to anchor to something inside the CQ
iank: Right, it's not an OOF inside the subtree beign able to escape,
it's about being able to anchor to something inside the
container
emilio: Okay, yeah, I was talking about the other way, with the
positioned element inside the container
TabAtkins: Remember that top layer pulls it out of the tree, and you
can move it further up.
miriam: I don't think you can always move it further up the tree. I
want to see if we can solve that half of the problem, too.
miriam: Containers created a fixpos CB is, as far as I can see,
always a footgun, it's not something people want from
containers.
miriam: So if we can remove that limitation from CQs that would be
excellent
kizu: For the second part, an element inside a container and you want
to position it outside without the top layer, the only thing I
can think of is position-container, which lets you position to
a different block
TabAtkins: Position container can't be used, because it uses the same
scoping as anchor names
TabAtkins: for the same reasons that the restrictions are applied in
the first place
TabAtkins: and changing that would amount to the same thing as
pulling something up in the tree, which is a separate
feature possibility
TabAtkins: The top layer is the best solution for all this
TabAtkinss: If we want some other more general thing we can solve it
in the position spec
TabAtkins: Propose we not try to solve that problem here
khush: Responding to comment about anchor being on screen causing the
anchored element being relevant to the user
khush: not sure how to implement that
vmpstr: If on screen and scrolled offscreen, won't stop being relevant
TabAtkins: There'd be a hysteresis
khushal: Right, would need to bring an offscreen thing back to the
screen for it to take effect
vmpstr: Minor clarification. Chris mentioned content-visibility:
auto, but shouldn't we include hidden?
chrishtr: Agreed
chrishtr: hidden should be skipped
TabAtkins: This falls out of the definition of skipped
RESOLVED: Undo the previous resolution - anchor names are not blocked
by any form of containment. But they *are* blocked from
escaping a "skipped content" element.
RESOLVED: And if a positioned element is "relevant to the user", any
element it's anchoring to remains "relevant to the user" as
well.
Define interaction with the cascade in `@position-try`
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9149
TabAtkins: We resolved earlier that rules from position fallbacks
interact with the cascade in some way
TabAtkins: Now we want to define that
TabAtkins: Propose that rules applied by a position-try have a new
origin after author origin and before animation origin
TabAtkins: This lets such rules win over all author rules but lose to
animation, important etc
TabAtkins: Revert keyword would also revert to user origin, just like
animations
emilio: Can can rules in this origin change transition?
TabAtkins: Yes
TabAtkins: Only once all of the cascade has finished is there a
transition to start
emilio: Details of that seem fiddly. Seems the right behavior but
needs edge case testing and spec text to make sure it's clear
TabAtkins: Current spec says to go through them in sequence and only
declare the element's real style once all have done
emilio: These things used to not be done until after layout?
TabAtkins: These are inputs to layout and so are used styles
emilio: But how does that cause transitions?
TabAtkins: Uses the same mechanism we discussed before
<TabAtkins> > These modified styles are applied to the element via
interleaving, so they affect computed values (and can
trigger transitions/etc) even though they depend on
layout and used values.
emilio: That causes interleaving then?
emilio: Performance may be an issue, but if that's what we want ok
futhark: It's quite similar to container queries - might need to
repeat style multiple times due to interleaved style and
layout across containers
futhark: ... before starting transitions
chrishtr: emilio was asking about performance concerns also?
emilio: My question was about remembering rules from before and how
are we supposed to do that?
futhark: In Chromium that is part of the cascade implementation
generally
futhark: We need to handle that regardless for regular animations
futhark: I forget the exact way that important overrides animations?
emilio: Animations override important. but if we're just reusing the
regular cascade then it's fine
futhark: What we do is to insert these trys into the cascade as
appropriate and re-run it
emilio: Still a bit concerned about performance, but it's fine
futhark: Some optimizations can be applied since the try blocks are
more scoped
emilio: Haven't read the exact spec text but seems fine to me
<astearns> let's try to get as much of these fiddly details into a
spec as we can
fantasai: Wanted to say that this is the most reasonable place in the
cascade to put these rules, other than possibly somehow
inlining them where the position-try declaration that
sources them lives, not sure
fantasai: but that possible alternative sounds complicated
fantasai: We should minimize what goes into these try blocks and put
other declarations elsewhere
fantasai: this way we can maximize the % of styles that end up in
their regular place in the cascade
fantasai: For inset and margin it's reasonable to put them in
position-try, but for more stylistic items they should go
in the cascade proper outside of a position-try rule
whenever possible
<TabAtkins> proposed resolution: fallback styles live in a new
"Position Fallback Origin"
<TabAtkins> proposed resolution: They revert like Animation styles
(back to User origin)
RESOLVED: Fallback styles live in a new "Position Fallback Origin".
They revert like Animation styles (back to User origin)
Is !important allowed in @position-try
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10058
TabAtkins: Are !important rules allowed in position-try?
TabAtkins: If they are then we'd have to define a new origin and not
clear where that would go or what the use case is
TabAtkins: Propose the answer to the question is no
<fantasai> https://www.w3.org/TR/css-animations-1/#keyframes
fantasai: Agree it doesn't make sense, but we should be consistent
with animations and how it's disallowed there
TabAtkins: It falls out of the way to say it's not allowed in the
syntax
proposed resolution: !important is not allowed within position-try
RESOLVED: !important is not allowed within position-try
When to invalidate "last remembered position-try option"?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10099
TabAtkins: There is a "last remembered position" try option if you
previously did something and now the try blocks fail, to
allow users not to see something jump around.
TabAtkins: but what if there are various kinds of changes that more
explicitly invalidate those try blocks that previously
applied?
TabAtkins: In service of a simple rule, consistency and ease of
implementation, we should remove the previously remembered
size if try blocks are added, removed or mutated, or
properties that specify the try blocks changed
TabAtkins: Proposed resolution: forget if position-try CSS changes or
any of the try blocks change
<fantasai> +1
RESOLVED: Forget if position-try CSS changes or any of the try blocks
change
CSS Box
=======
border-radius and border-image should be "border properties"
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9245
TabAtkins: We have a list of properties allowed in position-try. As
fantasai said, we want to keep that list as short as
possible
TabAtkins: One of the currently allowed properties is border. This is
in order to do things like thickening borders when
adjacent to the anchor.
TabAtkins: Right now this is specified as "the border properties".
Which in the other specs says "border width, style" but
not border-radius and border-image.
TabAtkins: Should we include border-radius and border-image?
TabAtkins: Makes sense to me to include border-radius.
TabAtkins: No opinion about border-image, but can just skip it
fantasai: My inclination would be to exclude both on the principle
that we'd need to solve conditional styling on sides for
these to be useful.
fantasai: On the other hand inset, margin, width and height are more
about positioning on the screen than styling visually
iank: Agree. Allowing these additional properties would be invasive
and more complex.
<kizu> +1
fantasai: Better to focus on positioning only when possible
fantasai: Can see how people would want to include border though,
because it affects the box
Rossen: Border box sizing is still prevalent in terms of use
<miriam> box-sizing only helps if you set an extrinsic size - it
doesn't help with intrinsic size boxes + padding/borders
Rossen: Wouldn't be happy as a user to anchor to a corner of a box
and based on the box sizing property it may or may not
include padding / border
Rossen: not totally sure if it makes a difference?
TabAtkins: Regardless of box sizing, you're not changing the border
at all, but just the content box?
iank: Don't think the box sizing property doesn't matter too much.
Some layout modes may change the internals though. e.g. tables
differs.
kizu: My +1 is for what fantasai said for not including border at all
in try blocks
kizu: For most use cases it should be possible to move the element
via other positioning to make room for borders, without
allowing borders in position-try
kizu: everything else in position-try positions only but border may
affect colors which is not a great fit for position-try
<iank> https://github.com/w3c/csswg-drafts/issues/9195#issuecomment-1942297101
chrishtr: TabAtkins can we just exclude border?
TabAtkins: Yes, and in fact I got confused and border is already not
in the spec. Ok to resolve no change to spec.
<TabAtkins> https://drafts.csswg.org/css-anchor-position/#accepted-position-try-properties
RESOLVED: No change to spec
Received on Wednesday, 20 March 2024 23:43:26 UTC