- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 29 May 2024 19:53:15 -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 Syntax & Nesting
--------------------
- RESOLVED: 1. Introduce a CSSNestedDeclarations object inheriting
from CSSRule and having a .style accessor, and use that
to represent the declaration lists in a CSSStyleRule. It
serializes as a raw declaration list. 2. Extend
.insertRule() to parse declarations (or, if Web-compat
requires, add .insertDeclarations()) into a
CSSNestedDeclarations Object. 3. Open a new issue wrt the
first declarations block. (Issue #10234: Design of
`@nest` rule)
Anchor Positioning
------------------
- RESOLVED: anchor() arguments can be reordered (Issue #10317:
anchor() arguments should be reorderable)
- RESOLVED: Make anchor-size() default to the keyword matching the
axis of the property it's used in (Issue #10318:
anchor-size() argument should be optional)
- RESOLVED: Accept proposal in 10316 but don't change normal behavior
when not using inset-area (Issue #10316: Should alignment
safety consider the containing block?)
- RESOLVED: position-try: none | [ [<dashed-ident> || <try-tactic>] |
<'inset-area'> ]# i.e. remove the inset-area() (Issue
#10320: position-try: inset-area() does not reflect CSSWG
resolution)
==== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0021.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Paul Grenier
Brian Kardell
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Vladimir Levin
Chris Lilley
Alison Maher
Eric Meyer
Miriam Suzanne
Lea Verou
Regrets:
Rachel Andrew
Daniel Holbert
Chair: Rossen
Scribe: keithamus
Rossen: Any changes to the agenda?
fantasai: anchor positioning, compat issues there.
Rossen: Issues 3 and 4 were asked to be done from last week. We'll
have time for anchor position, we can skip 5
CSS Syntax & Nesting
====================
Design of `@nest` rule
----------------------
github: https://github.com/w3c/csswg-drafts/issues/10234
emilio: Lea added this, I can introduce it a bit
emilio: There still seems to be some disagreement on best path forward
<astearns> could we resolve on @some-long-weird-name?
<kizu> +1 to "<@astearns> could we resolve on @some-long-weird-name?"
lea: The gist is another issue we resolved to stop hosting
declarations coming after nested rules, with declarations inside
a rule coming after get hoisted to the top which results in
strange conflict resolution
lea: Tab proposed the @ rule which avoid this. There was push back as
it only exists for the purpose of the OM and has no purpose for
authors, only exists to make spec editors lives easier
lea: There are some challenges to not introducing. One proposal to
have the @nest rule but not serialize, so you only get plain
declarations.
lea: Tab's opposition is that CSSOM isn't used that much so whats the
point
lea: Another proposal to make a new object to represent the
interleaved declarations.
lea: Blink is strongly opposing not having the rule
lea: On the grounds that CSSOM is not used frequently
lea: also that syntax is pointless from author perspective
lea: What if we call it @group then extend it later with
functionality? What if we can give this rule a purpose?
lea: My position is that I tend to agree with webkit. Against
priority of constituencies. People will find some weird ways to
use it
lea: I disagree with Tab's assertion that CSSOM is infrequently used.
lea: We do plan to eventually add nesting & author styles - extremely
author facing.
lea: Many devs modify css properties on the fly, indirectly or not.
It's extremely author facing
lea: I worry if we can't reach consensus we're stuck with status quo
- the hoisting behavior, which is worse than any solutions
proposed
lea: I'd be happier with @nest vs hoisting
lea: even though I'm opposed
<miriam> +1 current behavior is worse than any of the proposals
Rossen: We can bikeshed later on naming. Prefer path forward
suggested by Alan with @some-long-weird-name and bikeshed
later
fantasai: webkit is opposed to new @ rule for the purpose of making
it easier to specify CSSOM. Only reason this rule is being
proposed. We don't think that's good for authors
fantasai: flexible to what form the OM does take.
fantasai: We posted one that we think gives some useful interfaces
for authors. If people don't like it we're flexible
fantasai: but one thing we're opposed to is this thing that gets
parsed out
TabAtkins: lea's characterization of my position is incomplete.
Creating things in the OM is vary rarely used. Crawling
via .style or other - there's no meaningful difference.
Creating an OM from scratch is only where you'd see the
difference. That's incredibly rare to do. Only CSS tooling
does it
TabAtkins: The set of authors we're effecting positively or
negatively is minuscule, and these authors are advances.
We don't want to give them bad stuff just because, but we
trust them to navigate this
TabAtkins: webkit proposal give us genuinely worse tradeoffs. When
you serialize you get something useful but insert rule or
manipulate gets magical in a bad way, where insertrule
might merge or insert before or after. Deleting rules has
odd behavior as well
TabAtkins: two declarations next to each other need to be resolved.
TabAtkins: Unexpected tree structure munging is difficult to work
with as a user of the API
TabAtkins: Bikeshed represents HTML structure of the doc with a well
used XML library but it sucks for HTML. APIs are hard to
predict and has inconsistent behavior with text nodes as
you're moving around element nodes
TabAtkins: I used to have bugs in bikeshed due to this. I
reimplemented the DOM and used the DOM wrapper just
because DOM treats text and other nodes the same, a
predictable behavior.
TabAtkins: similar using an @ rule of some kind means we don't do any
weird magic with OM manipulation.
TabAtkins: We have consistent behavior, nothing weird needs to happen
with add/remove. No cleanup
TabAtkins: simplifies impl and specs. Importantly it makes
manipulation predictable for the author which is far more
important to maintain
TabAtkins: If necessary we're fine with having a serialization rule
which most of the time omits @ nest. Anything you parse in
can always serialize back out without showing the rule. It
just relies on adding one serialization quirk, which
you'll never notice unless you're creating rules which
couldn't be produced by the parser.
TabAtkins: in all other cases it'll be invisible. This is acceptable
to us
TabAtkins: I think it's a bad idea to complicate the data model with
magic.
emilio: I wanted to say similar. What lea said implied the model
consistent only helps browser/spec editors, I don't think
that's true. Let's not over-complicate the solution.
emilio: extra @ rule vs having to invent weird stuff... the trade-off
is clear for me.
<fantasai> https://github.com/w3c/csswg-drafts/issues/10234
fantasai: Tab is referring to this
<fantasai> https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2116380146
fantasai: which is one proposal which we suggested as a possibility.
We clearly said we're flexible how it's represented in the
CSSOM
fantasai: so the long spiel about merging, that's objectionable, we
can drop it
fantasai: What we were proposing is that we introducing a CSS Nested
Declaration object inherit from CSSStyleRule, it has
accessors... when you use insertrule, and there happens to
be an adjacent rule, you'd merge the declarations into that.
fantasai: if that's a problem we don't have to do that.
fantasai: The only thing we're stating is that it serializes without
an at-rule. Consequence is not merging in CSSOM when you
serialize and parse it back in 2 objects get merged
together.
fantasai: We think this is acceptable vs a new at-rule to avoid it.
<fantasai> "We would also be OK with alternative solutions that don't
introduce an at-rule"
<fantasai> idk how to get more explicit than that
TabAtkins: If that's the constraint it would be good to express it.
It seemed like it was requiring more magic. Serialization
& reparsing.. I don't care too much about that, as long as
tree manipulation doesn't do unpredictable magic
TabAtkins: Changing behavior of insert rule to allow declaration
lists... currently it throws but the OM API is old. It's
always unpredictable if things like this are compat issues.
TabAtkins: If it's purely a matter of producing some sort of object,
call is CSSDeclarationList, and it serializes
declarations, and you're ok with it changing structure
when you roundtrip, I'm okay with that
TabAtkins: but all the magic proposed in thread was what I was
objecting to
emilio: I still prefer avoiding rounttripping. Apple's proposal
without the extra magic is basically @nest without saying
@nest.
emilio: That's not amazing but that seems way better than the
original tree-monkeying stuff
<TabAtkins> Note again that "just doing an at-rule" also always
serializes as bare declarations *as long as you haven't
used OM manipulation to do something funky*.
<TabAtkins> Or network packet delays can cause separate text nodes, I
think, directly from the parser.
dbaron: Wanted to point out the idea you get a different OM when you
serialize and reparse is something we already have with HTML:
empty text nodes or adjacent text nodes. DOM has an API to
normalize these.
<dbaron> https://developer.mozilla.org/en-US/docs/Web/API/Node/normalize
Rossen: Are we getting close? The original proposal in IRC seems to
be landing okay?
<fantasai> PROPOSAL:
<fantasai> 1. Introduce a CSSNestedDeclarations object inheriting
from CSSRule and having a .style accessor, and use that to
represent all the declaration lists in a CSSStyleRule. It
serializes as a raw declaration list.
<fantasai> 2. Extend .insertRule() to parse declarations (or, if
Web-compat requires it, add .insertDeclarations()) into a
CSSNestedDeclarations object
<fantasai> 3. Open question about the first declaration block.
fantasai: we should handle 3 as a follow up
emilio: To be honest I still prefer a regular rule than bare
declarations, but this is a fine compromise if people are
unwilling
TabAtkins: I don't think first declaration block is an open question.
We still have weird magic behavior. The first block of
stuff is definitely put in a stylerules.style not
reflected in child rules
fantasai: 100%. I think there's a question about if its also
represented in CSS rules.
emilio: I don't think putting it in 2 places is great
TabAtkins: I don't think we can. If you delete the first block you'll
be invoking magic behaviour
TabAtkins: we'll have to re-create at some point. Exactly the magical
behavior I want to avoid
emilio: That's true.. calling delete rule would be weird
fantasai: If we do this authors can have a single consistent API for
all of the contents of the style rule
TabAtkins: If we were designing these from scratch I'd agree
TabAtkins: but with history, the only way to maintain it safely would
be additional magic with delete rule. I want to avoid the
tree magic as much as possible
fantasai: Can we open that conversation separately?
TabAtkins: I can guarantee my position but the others, mild
objections, but this is acceptable
Rossen: Can we summarize the compromise?
TabAtkins: In the proposal
Rossen: All 3?
fantasai: 3rd isn't really a thing
<fantasai> 1. Introduce a CSSNestedDeclarations object inheriting
from CSSRule and having a .style accessor, and use that to
represent all the declaration lists in a CSSStyleRule. It
serializes as a raw declaration list.
lea: can someone restate the proposal?
<fantasai> 2. Extend .insertRule() to parse declarations (or, if
Web-compat requires it, add .insertDeclarations into a
CSSNestedDeclarations object
Rossen: Any additional points or objections?
lea: That seems great
Rossen: I'll call this resolved
RESOLVED: 1. Introduce a CSSNestedDeclarations object inheriting from
CSSRule and having a .style accessor, and use that to
represent the declaration lists in a CSSStyleRule. It
serializes as a raw declaration list. 2. Extend
.insertRule() to parse declarations (or, if Web-compat
requires, add .insertDeclarations()) into a
CSSNestedDeclarations Object. 3. Open a new issue wrt the
first declarations block.
Anchor Positioning
==================
anchor() arguments should be reorderable
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10317
fantasai: Anchor arguments are custom-ident and keyword. We normally
allow them to be re-ordered. Proposal to re-order.
Rossen: hearing no objections, calling this resolved.
RESOLVED: anchor() arguments can be reordered
anchor-size() argument should be optional
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10318
fantasai: Often allow dropping args with obvious default. anchor-size
has obvious default of dimension in same axis as the one
you're using it on, so height is top, width is other axis.
Straightforward to do automatically. Proposal to make it
optional
TabAtkins: Only objection is that anchor-size has reasonable
extension points in future. eg referring to size of tracks
of inset areas.
TabAtkins: might be less clear what the appropriate defaults are for
those
TabAtkins: right now very clear with width/height. In the future it
might be somewhat less.
TabAtkins: Don't object necessarily as it's quite clear for
reasonable defaults.
TabAtkins: but wanted to make sure we felt decent about that.
emilio: Can this be used in min/max properties?
emilio: Should it use regular size?
fantasai: This is just to drop the axis keyword. Doesn't change what
you're referencing in terms of size
emilio: Right but it makes it more confusing? Also what happens if
anchor is orthogonal to the thing you're using it on?
TabAtkins: That's in the spec it makes the function invalid, resolves
to fallback size
emilio: That's not what's expected but okay
fantasai: This is literally just a default keyword
<TabAtkins> https://drafts.csswg.org/css-anchor-position/#anchor-size-valid
Rossen: Any other points or objections?
PROPOSED: Make anchor-size() default to the keyword matching the axis
of the property it's used in
Rossen: I'm calling this resolved.
RESOLVED: Make anchor-size() default to the keyword matching the axis
of the property it's used in
Should alignment safety consider the containing block?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10316
fantasai: This is a fun one, tackles two issues. Both anchor-center
currently defined to changed the size, as well as to shift
the alignment.
fantasai: So, the proposal is to remove the special sizing behavior
from anchor-center. When neither unsafe nor safe is
specified in the alignment property - in other words by
default. And only when its not normal
fantasai: When the object is larger than the container we overflow
away from the scrollable region
<fantasai> https://github.com/w3c/csswg-drafts/issues/10316#issuecomment-2125437844
fantasai: So you're using the inset properties to create a containing
block. If you're in abspos is small enough to fit in the
IMCB you just do alignment as you specify
fantasai: If its larger than the IMCB we don't make it start aligned.
If you hit the edge, say the right edge, the point were
it's big enough to break out of the containing block we
overflow in the opposite direction
fantasai: we overflow away from the scrollable region
fantasai: What this does - it gets you a very nice behavior for
anchor center
fantasai: that you keep the item visible. Try to center as much as
possible but don't overflow unless you overflow the entire
containing block
fantasai: shift the area as much as you can
<fantasai> https://github.com/w3c/csswg-drafts/issues/10315
fantasai: the other issue is this one
fantasai: a nice illustration somewhere
<fantasai> https://github.com/w3c/csswg-drafts/issues/9960#issuecomment-1944518084
fantasai: Una made a nice example of this
fantasai: the second behavior, not the one that resizes
TabAtkins: The only thing is you can't apply to normal. So locked in
on compat. We might try to not do this on start/center/end
TabAtkins: There's large amounts of content that applies center to
abspos things
TabAtkins: we might need to disallow on those based on compat
TabAtkins: we'll see how it goes when we deploy
iank: A little concerned web devs will get confused
iank: They say anchor center and the CB for some reason or another is
small... I guess we might just have to teach webdevs to use
unsafe anchor center
iank: which probably isn't the worst
iank: but be prepared for likely recommending that heavily
TabAtkins: If you have a weirdly small CB the position try stuff will
be affected to. So they'll have to learn
fantasai: The behavior we ideally wanted is you do safe centering if
you're overflowing the edge of the scroll container
fantasai: but nobody has implemented that subtlety.
iank: That is long sailed
iank: means you invalidate a bunch of engine optimizations
fantasai: But if we think people will want unsafe align for CBs not
in viewport we could do that
fantasai: but this is probably a good starting point
iank: The problem with that is you'll need some way to expose magical
default for those cases
iank: If we go down that path you'll need some magic alignment like
overflow alignment
iank: I'm fine with this proposal but I suspect we might... people
might be reaching for unsafe more.
iank: We should be cognizant that we might need to recommend it a lot
more.
Rossen: Any other opinions?
fantasai: PROPOSED: Accept proposal in 10316 but don't change normal
behaviour when not using inset-area
RESOLVED: Accept proposal in 10316 but don't change normal behavior
when not using inset-area
position-try: inset-area() does not reflect CSSWG resolution
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10320
fantasai: When we discussed position-try proposal we talked about
inlining inset area syntax in the list of things to try
fantasai: for a lot of simpler cases you only need to set inset area
fantasai: you wouldn't need a position try rule and manage
namespacing etc
fantasai: Edited in the spec is a new inset-area function
fantasai: not generally how we pull syntax from one area into another
fantasai: We've never created a function with a syntax that maps to
that property
fantasai: not necessary here
fantasai: I think the change should be reverted. inset-area value
space should be in the position-try list as discussed when
we resolved on this
TabAtkins: As I said in the issue - the precise syntax wasn't
significantly discussed
TabAtkins: it was introduced in an IRC comment. Not meaningfully
picked over
TabAtkins: The resolution was weak on syntax
TabAtkins: editors have had similar leeway
fantasai: Not really. If it's ambiguous you should come back to the WG
TabAtkins: In any case it was ambiguous so I found it not to be the
most readable. I found a decent change we'd want to inline
more stuff in the future
TabAtkins: The syntax space might overlap with future extensions
TabAtkins: so that with the readability right now... I thought the
function made it much easier to understand
TabAtkins: the function, dashed ident... three distinct syntaxes
TabAtkins: the flip keywords, the inset-area function, the dashed
ident naming the position try block
<fantasai> position-try: top, bottom, left span-bottom, right
span-bottom; seems perfectly readable to me
TabAtkins: I'm comfortable with other syntaxes, making it clear the
inset-area keywords are specifying that. Maybe the
keyword, or area, or whatever
TabAtkins: I'd like something to indicate what the value is doing
fantasai: I think we haven't ever done this before. Inlining the
syntax is perfectly reasonable
fantasai: I'm not sure why listing a bunch of values is unreadable
fantasai: They're not generally combined with the other aspects
fantasai: If we want to intro alignment keywords later we can
disambiguate
fantasai: e.g. with a slash
fantasai: This syntax is unprecedented. I'd prefer not to introduce it
kizu: I think I incline towards fantasai's proposal. Later alignment
with slash will sound better. Especially if we want to allow
using these properties in the try block
kizu: if you have some specific case
kizu: New syntax that is unprecedented, authors could later think
other properties could have the same thing
kizu: maybe a separate issue if we want to use it in more properties
<florian> I am weakly in favor of fantasai's position in theory, but
I haven't tried to use it practice, so I don't know that my
opinion should weigh much here.
TabAtkins: I can live with it
<TabAtkins> (I'm not sure what you mean by "allow in the try block"
fwiw, kizu. inset-area *is* allowed in the try block)
<kizu> (TabAtkins, I meant self-alignment properties, but I forgot
that they're already allowed, yes)
<fantasai> PROPOSED: position-try: none | [ [<dashed-ident> ||
<try-tactic>] | <'inset-area'> ]# i.e. remove the
inset-area()
RESOLVED: position-try: none | [ [<dashed-ident> || <try-tactic>] |
<'inset-area'> ]# i.e. remove the inset-area()
Received on Wednesday, 29 May 2024 23:53:47 UTC