- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Aug 2023 19:21:03 -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
------------------
- RESOLVED: Add border, padding, and margin properties to position
fallback rules (Issue #9195: Allow more properties in
position fallbacks)
- RESOLVED: Make the anchor-name property a comma-separated list of
idents (Issue #8837: Ability for a single element to have
multiple anchor names)
- RESOLVED: Add a separate property (can bikeshed name in future),
not merely a shorthand, but interacts with inset
properties in current draft (Issue #9145: Grid-based
anchoring syntax?)
- RESOLVED: inset-area causes 'auto' keywords of inset to resolve to
appropriate anchor() functions (TBD at computed or used
value time) (Issue #9145)
- RESOLVED: Accept proposal in the draft with details to be worked
out over time (Issue #9196: Alternative syntax for auto
position fallback)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Aug/0010.html
Present:
Tab Atkins
David Baron
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Mason Freed
Chris Harrelson
Daniel Holbert
Xiaocheng Hu
Ian Kilpatrick
Florian Rivoal
Jen Simmons
Alan Stearns
Nicole Sullivan
Miriam Suzanne
Lea Verou
Chair: astearns
Scribe: dbaron
Anchor Positioning Breakout
===========================
Allow more properties in position fallbacks
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9195
astearns: See if we can resolve this in 5 minutes?
TabAtkins: Currently position fallback has a limited set of things
you can put in it. There are use cases for more properties.
TabAtinks: Originally limited for simplicity of implementation.
Original goal of things that could be done late in layout
cycle, without changing overflow.
TabAtinks: border/padding/margin don't cause new problems that
changing positioning properties do already. Also seem
necessary for many things.
TabAtinks: different margins or different borders depending on
alignment.
TabAtinks: So we're suggesting to add the box properties (border,
padding, and margin) into list of allowed properties.
dbaron: All border properties, including stuff like border-image?
TabAtkins: Yeah
astearns: Any objections to adding border padding and margin
properties to position fallback rules?
emilio: Not an objection, but doesn't that mean that you can trigger
image loads as a result of this?
emilio: Either need to load the border-image eagerly or it flickers
TabAtkins: Known issue with background image that only triggers on
:hover
TabAtkins: We should probably do something about it, but doesn't need
to be addressed now
emilio: Fair enough
astearns: Any objections to add these properties?
RESOLVED: Add border, padding, and margin properties to position
fallback rules
Ability for a single element to have multiple anchor names
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8837
TabAtkins: Right now spec is written so an element can only have
anchor name. Might want to allow something to be multiply
named for different contexts. You *can* work around it,
but it can be annoying. No reason to not allow multiple
anchor names, not difficult in any way. So want to make
anchor-name property a comma-separated list of names.
TabAtkins: fantasai said comma-separated
fantasai: Yes, we should try to be consistent
RESOLVED: Make the anchor-name property a comma-separated list of
idents
TabAtkins: There's a sub-discussion: at the moment, with only one
possible anchor name, it's unambiguous dealing with
implicit anchors. If you give something an anchor name....
er, wait. There's something at the end of Roman's issue.
It's either invalid or we'll deal with it later.
Grid-based anchoring syntax?
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/9145
TabAtkins: One of the interesting parts of alternative proposal was
grid-based syntax for positioning things. Some folks on
our team found that more understandable at least in simple
cases. I don't have a problem with this, easy to map in to
existing model. Uses one of four easily-addressable lines
you can get with inset and anchor properties.
TabAtkins: So proposal here is to add a new 'inset-area' property
that's a pure shorthand property, taking the grid syntax
from the proposal (without the extra fallback bit), and
expands into the four insets that would correspond to.
TabAtkins: So saying 'top center' would expand to (missed)
TabAtkins: A few other options we could go for. Could merge it into
the inset syntax itself. Should be grammatically distinct
from 1-4 anchor values. Wouldn't be able to serialize it
back out in that case which might be annoying.
TabAtkins: Maybe less of a problem than a shorthand-only property
though.
florian: In terms of translating to inset properties this seems to
work. One thing I'm not sure about: in the grid-based
proposal there were align-content/justify-content keywords
resolving differently depending on which grid area you slot
into. Does that still work?
TabAtkins: That still works fine. The default one is you want to be
flush to the anchor if you're in one of the outer cells.
You get that behavior by default... because top was auto
and bottom was 0 you get positioned flush with the anchor.
The same applies all the way around.
TabAtkins: I don't believe we end up needing any special alignment
behavior... I think everything we need pops out.
TabAtkins: But if necessary we could add more magic to alignment
properties.
fantasai: I'm ok with trying to do this. I don't think it gets all
the usability advantages of the other proposal. Just making
it a shorthand doesn't give you the ability to list
fallbacks; you just get one position out of it. That was an
easy way to do fallback behavior in the other proposal.
fantasai: Another issue is that align-self and justify-self have both
a start and a self-start keyword. Writing mode of self
versus containing block. Usually want the containing block.
When resolving shorthands during the cascade, we don't know
what the containing block is. Cascade mapping always done
using writing mode of element itself. So don't have ability
to position based on container's writing mode (or, in
theory, even anchor's writing mode). Could do that in a
keyword-based syntax.
fantasai: In a keyword based syntax resolve the value at computed
value time. But when resolving the directional properties,
in the cascade, we don't have the full style information so
the only writing mode we can reference is the element
itself.
fantasai: That's one thing that doesn't work with shorthanding.
fantasai: Third thing this doesn't address is the ability to
conditionally style absolutely positioned element or its
contents.
fantasai: Because there's a concept of which slot you're in that's a
higher level concept than which coordinates you end up,
that allows conditional styling using either pseudo-classes
or @container rules.
fantasai: That allows styling depending on where it ends up. Even if
you specify a logical position you can select based on a
physical position.
fantasai: Can style based on left/right/bottom/top even if it was
specified as 'start start'.
fantasai: That was an advantage of having something conceptual in the
other proposal rather than being syntactic sugar.
fantasai: That allows some of the extra power in that proposal.
TabAtkins: First and third points about fallback and conditional
styling would be downstream issues. I want do solve those
as well...
TabAtkins: For number 2, being able to expand based on container
rather than self writing mode -- that's a good point and a
little problematic.
TabAtkins: I wonder if we want to solve that instead by having
inset-area not be a shorthand, but instead be preserved,
and have it provide different anchor values when the
anchors are auto.
TabAtkins: This can be late enough that we'd have appropriate writing
mode information.
<florian> +1
TabAtkins: The author experience should be essentially identical
astearns: Would that also solve the fallback thing?
TabAtkins: It could, but I want to address fallback separately as a
different issue. I want to make sure we have a fallback
story for anything. Open to idea of inset-area doing
fallback, but want to make sure we're not inconsistent
with rest of fallback.
<iank> likely should be fine to resolve insets based on an additional
property during layout time.
fantasai: I didn't quite understand what TabAtkins is proposing.
TabAtkins: inset-area no longer a shorthand, just a separate property
(same grammar). Effect would be that if insets are auto,
it provides insets. So by default you'll be put in the
right grid cell. In theory you could override them. If you
want to put something roughly in this grid area and then
tweak, I think it's useful to say 'right' is this
expression.
fantasai: Brings up another issue with other proposal... select a
grid area, and insets would inset in *from that*. Allowed
for a lot less math for common/intermediate cases.
fantasai: ... this allowed making percentages relative to the outer
track, which gave some abilities that are possible to do in
your proposal but messier to express.
fantasai: ... lets you do many things with less fussing with math
expressions.
fantasai: ... Not saying we shouldn't do this... seems like it's an
improvement over what's there. Happy to accept the changes,
but not sure it's solving the whole question.
TabAtkins: Can tweak the position with margin rather than insets.
TabAtkins: or if you want to rejigger can use calc() of a margin
minus a value.
<iank> some of the cases for using insets in the Alt. Proposal aren't
needed, e.g. can do `left: anchor(center);` , vs. `left: 50%`
jensimmons: I wonder if it would help if you looked at the code ... I
think there is something about having a margin and having
an inset, and having inset insetting from the area that's
been chosen. E.g., a margin of 1em and an inset of 50%.
So it fills 50% of the column *and* has a 1em margin so
it never touches the edge of the viewport. Could use more
thinking about how to maintain advantages of other
proposal.
TabAtkins: I think that case is easy to express in either proposal.
TabAtkins: doc... hasn't explored (missed)
astearns: We have a queue... I don't think we're going to get to
(missed) in the breakout today.
emilio: I was going to argue against the shorthand, because it needs
to be parse time rather than cascade time... but that point
is moot now. I think making it a longhand an affect auto
inset resolution seems fine.
emilio: I think a bunch of inset cases that Jen and Tab were talking
about can be margin: calc(50% + 1em)
fantasai: They can't
jensimmons: TabAtkins, can you say more about why inset-area is a
good name?
TabAtkins: No strong opinion on the name, first name that came to
mind.
jensimmons: We used position-area. Two thoughts about that: would be
a longhand (?) within position. What surprises me about
inset-area as a name is that it ties back to points
fantasai was making:
<iank> I don't think we should shorthand `position`
jensimmons: Ties to a different mental model: I'm going to put thing
in these cells, and then apply an inset on top of that.
Whereas inset-area is saying "here's my inset", so you
don't get inset on top of that. So different
interpretation for web developers.
jensimmons: So not sure inset-area is the right name
TabAtkins: I wanted to keep it under inset since it affects inset
properties, but not strongly attached.
fantasai: I think for the definition you're giving it, inset-* makes
sense, but for the definition we gave I think a non inset-*
name makes sense.
xiaochengh: There's an issue if we make inset-area not just shorthand
but a standalone property: interaction with animations.
If it's standalone then it's not going to animate at all.
With anchor functions developers have made demos with
animations. If we introduce inset-area we'll end up in
weird situations where you can animate with anchor
functions but can't animate when inset-area is used.
TabAtkins: That's true
fantasai: I don't think that's true -- Tab's proposal was that auto
keywords of inset would compute differently. Animations is
based off the computed value. So you'd have auto compute
through to the correct anchor function, so I think it would
animate correctly.
TabAtkins: Yeah, it works if we do it at computed value time -- I
think we could make that work.
astearns: Yeah, would need to be specified how animations work with
values of inset-area
TabAtkins: Not specifically, just would need to be specified that it
happens at computed value time so animation behavior falls
out
emilio: Not sure how the auto behavior works at computed value time
fantasai: Not computed to a fixed offset, but compute to an anchor
function that's specified as something that you can calc()
TabAtkins: Yeah, every auto anchor will either remain auto, become 0
or 100%, or become anchor(left/right/top/bottom).
TabAtkins: Those are values that are interpolable via animations
emilio: And the anchor() function can be interpolated via calc()?
TabAtkins: Returns a length
emilio: Seems sketchy to make computed values of the properties
depend on each other.
emilio: Needs to be spec'd really carefully
emilio: Right now inset:auto always computes to auto always.
Introducing property dependencies is tricky but not super
tricky.
flackr: I think computed value interpolation would be helpful for
other auto animation cases as well. +1 to pursuing it.
emilio: Isn't a more general fix making auto interpolable and in
calc().
fantasai: Wouldn't solve this problem because we're trying to make
the inset-area values interpolable. They're keywords that
put you into positions in gridded model of relationships to
anchor. They're keywords and don't compute through to
anything. By making them influence the inset property's
auto keyword that's what makes them interpolate.
fantasai: So if you're partway through a transition between 2 keyword
values of inset-area, your left value is not auto and
therefore doesn't reference inset: auto when you're halfway
between... it's an expression with anchor(left), etc. and
progress.
emilio: Does this mean to animate the inset area you need to set
transition: inset instead of transition: inset-area? That's
weird.
fantasai: Yeah... or both
TabAtkins: You want to immediately transition the inset-area so that
you can get a transition-able change to the insets.
astearns: We should say we need to solve the animatability and move on
TabAtkins: Remember the alternate proposal doesn't have animation
behavior
astearns: Back to the queue
florian: I don't quite know what we'll land on eventually, but in
spirit of iterating seems like a good idea. One thing that
seems to have been dropped: in the Apple proposal this
changed how percentages are resolved. I suspect we can't do
that on margins. One reason to use insets rather than
margins is that you can resolve percentages differently on
them. That seemed useful, but not sure how to resurrect in
this model.
florian: ... worth figuring out how.
TabAtkins: All the examples can be done pretty trivially with inset
manipulation. I think the percentage behavior was strange
-- depended on where positioned and I think on what the
value (?) was.
<iank> florian: some of the cases which require alt. percentage
resolution, are easier expressed as `left: anchor(center)` in
the current proposal
TabAtkins: Say something was positioned in top center, left: 50% was
relative to width of the one of the cells... 150% was ...
transitioned?
fantasai: No
TabAtkins: Ah, ok, just left and right relative to different things.
TabAtkins: If we can avoid bespoke percentage behavior I'd
appreciate it.
florian: I think we should log this and come back to revisit later,
and see whether we caught all the things in the other model
that could be done with percentages to make sure we didn't
drop something.
iank: Should make sure cases where you needed left: 50% versus left:
anchor(center). So cases where you don't need specialized
percentage resolution.
fantasai: Works for 50% but not for other values.
iank: But I think that's the main use case
jensimmons: Speaking of use cases: a little earlier at the f2f we
agreed we'd create a shared doc with use cases and code.
I think somebody at Google started a doc but we couldn't
find. But we created a new doc on Monday, with just what
we had collected, so it's quite sparse.
nsull: I shared an example doc with you last night.
jensimmons: So we should work on this doc... good idea.
nsull: I think each model was good at some things and harder to
express other things.
nsull: ... and other places where room for improvement. Neat to see
examples written out.
fantasai: Just want to +1 to florian. A lot of things to work on but
happy to make incremental progress. Should be clear that
we're still exploring how this works, but happy to draft
exploration into the draft.
astearns: I think consensus on adding a separate property (can
bikeshed name in future), not merely a shorthand, but
interacts with inset properties in current draft. Is that a
good summary?
<fantasai> I think for the definition we're discussing here,
'inset-area' is a reasonable name. Depending where we end
up, might need to rename.
<florian> +1
RESOLVED: Add a separate property (can bikeshed name in future), not
merely a shorthand, but interacts with inset properties in
current draft
astearns: Any other things we should resolve on now?
fantasai: The current definition is that it causes the auto inset
keywords to compute to anchor functions
proposed: The values of this new property cause the auto inset
keywords to compute to anchor functions
emilio: I think this is very weird. I think an alternative is if you
want animations, just use anchor() inside 'inset' properties
TabAtkins: The reason we shifted away from parse time was to use
writing mode information. Reason to shift to computed
value time was for animation.
TabAtkins: Do you want late but after computed value? Parse time,
computed value time, or layout/used value time?
emilio: I'd prefer used value time
<iank> we can try the used value time initially then see if we get
author feedback
TabAtkins: I think they're equivalent in all cases except for
animation
florian: Inline issue for this: either computed value time which is
complicated and solves animations, or used value time and we
need to find another solution for animations
TabAtkins: Can resolve that it happens at computed value time or later
<flackr> +1
astearns: ok, so no resolution on this right now
<fantasai> PROPOSED: inset-auto causes 'auto' keywords of inset to
resolve to appropriate anchor() functions (TBD at computed
or used value time)
<fantasai> And we might change that definition later, but for now,
that's what we're at
<florian> +1
<emilio> +1
RESOLVED: inset-area causes 'auto' keywords of inset to resolve to
appropriate anchor() functions (TBD at computed or used
value time)
fantasai: Not 100% sure we want to stay here, but it's where we're
going now
TabAtkins: Yeah
<nicole> Here is a doc of examples we worked through (you'll need to
ask for access)
https://docs.google.com/document/d/1Dsu91zGfhG-qBbZvwOz13SS_m5dTb_ZHbDbonUf1qnM/edit?usp=sharing&resourcekey=0-8b2dD7pNg1Ruovm0QlhNkA
Alternative syntax for auto position fallback
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9196
TabAtkins: xiaochengh was exploring space for position stuff. While
thinking about use cases brought up for alternate
proposal, realized the current stuff we have in the spec
for auto fallback isn't sufficient. auto and auto-same
keywords. Current behavior is that they resolve to
appropriate side of anchor and auto-generate try blocks
that flip to other side. Only thing changed in try blocks
are side -- margins don't change as well.
TabAtkins: That seems less than useful.
TabAtkins: xiaochengh's alternate proposal is to separate the
automatic try block generate to an explicit fallback
property that has keywords that say how to generate the
fallbacks, a bunch of keywords listed in proposal.
(flip-both and compass try all 4 possibilities)
TabAtkins: This affects more than just the inset properties. Also
affects other box model properties. So margin-bottom after
a flip-y ends up as a margin-top.
TabAtkins: This seems substantially better to me.
TabAtkins: In the simplest cases it's identical, but in nontrivial
cases it does much better behavior. I'm happy to accept
these.
TabAtkins: Other use for auto and auto-same keywords -- automatically
resolving to the appropriate side -- can use in the inset
shorthand and get all the sides specified. Can keep that
behavior and rename the keywords to not imply
auto-fallback.
TabAtkins: I think this opens up possibilities for more fallback.
Could build some position-area stuff in here. Could
specify position-area spots and it could do appropriate
flipping as well. I think it has growth area to fill in
remaining fallback cases.
fantasai: I think this is interesting. I find the auto keywords
inside ?? to be confusing. I can never remember what the
auto thing does. Can we use more descriptive keywords?
TabAtkins: Suggested keywords are same and opposite. So top:
anchor(same) means top.
<TabAtkins> top: anchor(same)
<TabAtkins> means top: anchor(top)
<iank> we can bikeshed with authors
fantasai: another idea would be 'inside' and 'outside'
<fantasai> top: anchor(inside) is top: anchor(top) -- it anchors it
inside the anchor box
<fantasai> top: anchor(outside) is top: anchor(bottom) -- it anchors
it outside the anchor box
jensimmons: Comparing this idea to current spec, not much to say. But
comparing to proposal we presented at f2f, the
higher-level idea of fallbacks. In the position-area/
inset-area model, where you say you want above, in both
right and center columns... at the bottom do you want it
right and center. What if you want above all the way
across, falling back to just center if below. But maybe
just flipping is what people usually want. No opinion on
whether a good iteration on current spec.
TabAtkins: Three levels of fallback precision: (1) is simply mirror.
(3) is arbitrary things in next fallback, can use try
blocks in @position-fallback. (2) between those is to
adjust as necessary, mostly just moving to different area.
I think this syntax is extendable to take position-area
keywords as well.
TabAtkins: So you could start out as top center and move to bottom
all and have it work out appropriately, with the necessary
flips.
TabAtkins: I think that ends up addressing your concern.
jensimmons: I'm not a fan of the try blocks, but maybe a discussion
for a different day.
<fantasai> +1
<nicole> +1
TabAtkins: We have use cases that you need the try blocks for, but
ideally we should make it so 80% of cases don't need to
touch that.
jensimmons: I wonder if we can iterate to something where people can
do the complicated stuff without try blocks.
xiaochengh: Wanted to add something to Tab's second case: a little
more complicated but not arbitrary: This property can
also be used in try blocks so that we can auto-generate
fallback from try blocks. It doesn't eliminate all the
try blocks but it can significantly reduce the length of
the try list.
fantasai: Relationship of this to position-fallback property? Should
this be a longhand of this or separate properties?
TabAtkins: What position fallback property?
TabAtkins: If you don't specify position fallback, these entries get
auto generated, if you do specify then you ignore it.
fantasai: Should they then be the same property?
TabAtkins: Maybe
xiaochengh: I don't think so -- position-fallback property cannot be
used in a try block but this property can
<lea> in general we should avoid designing syntax that just ignores
specified values, as that tends to lead to author confusion.
Maybe if we combine both somehow?
TabAtkins: Setting up one try block with the things you need and then
saying auto to generate a couple more, that's fair.
<fantasai> yeah, maybe make position-fallback for both
astearns: Can we resolve to add to the draft, and add issues such as
one property or two, how it works in try blocks?
<lea> I can easily see the auto values being useful both by
themselves, as well as fallbacks to more specific fallbacks
specified via @try blocks
fantasai: I think that's fine if we make it clear there's open
questions.
RESOLVED: Accept proposal in the draft with details to be worked out
over time
Received on Wednesday, 23 August 2023 23:21:38 UTC