– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

Gaps

[css-gaps-1] Grammar for expanded column-rule shorthand

kbabbitt: First issue is about gap rule shorthand

kbabbitt: In the future, I wanted to allow different parts of container ot have different gap decorations

kbabbitt: In the current version of the spec, we allow for varying gap decorations within a given region o the container

kbabbitt: For the purposes of the shorthand, specify widths styles colors ...

kbabbitt: For longhand properties to do varying decorations, can specify them all: columnrule-color: red blue ; alternate red/blue

kbabbitt: For shorthand it's more complicated because of additional values

kbabbitt: I previously used slashes to separate width/style/color groups

kbabbitt: wanted to reserve commas for future feature for regions

kbabbitt: Got feedback that slashes were not great for this particular separation

kbabbitt: subsequent discussion, several pointed out that when that feature comes along, we'll need to specify which region each set applies to

kbabbitt: identify the region of the container

kbabbitt: so we could use those indicators as the separators for this set of decorators applies to this region of the grid etc.

kbabbitt: that seems reasonable to me

kbabbitt: indicates that it's safe to use comma for separators for varying decorators within a section

kbabbitt: so that's what I would like to do

fantasai: border-radius has a similar problem trying to assign things to different positions
… It also wanted to make sure it had the ability to use repitition
… This seems like a similar problem to what you have here
… You want to be able to specify all the gaps individually, or be able to repeat them

kbabbitt: We do have a repeat pattern defined in the syntax

fantasai: I think I need to read the proposed syntax a little more closely

<astearns> `gap-rule: 1px solid red, 2px solid red [2/2/4/4] 2px dashed silver, 2px dashed gray`

fantasai: Maybe we can have an example?

astearns: Is this representative?

kbabbitt: Yes

kbabbitt: in that example you'd have 1px / 2px alternating across the grid, and then alternating silver and gray in the other section
… In that example, you’d alternate 1px/2px for most of a grid, but within that potrtion of the grid you’d alternate silver and gray
… That would be in a future version; the question here is whether we can use commans to separate portions of the grid

astearns: If I understand, I think in order to more closely follow border-radius, we should use commas to separate values within…

fantasai: border-radius doesn’t use commas, so may not be a good analogy

border-radius: <length-percentage [0,∞]>{1,4} [ / <length-percentage [0,∞]>{1,4} ]?

<kbabbitt> border-radius: 2em 1em 4em / 0.5em 3em;

fantasai: The slash in border-radius separates the X side and Y side
… I don’t know how applicable this is to gaps
… You usually want to set border and color as a set
… Useage patterns may not be the same

kbabbitt: I got feedback that caused me to raise the issue

fantasai: We could separate regions with commas, but I think it might be confusing
… Then again we do use commas to separate lists of things, so following that pattern is a good thing

astearns: I think I’m good with the current proposed PR, not as sure about the extension

kbabbitt: The PR was written assuming extensions will be needed
… Another thing I raised was that we don’t need a separator within a given region

fantasai: But then you have to fix the order of them, and everywhere else we do line styling you can mix the order of width, style, color
… I don’t think we can just use spaces
… Commas is probably the best we can do here and we’ll have to get creative with region styling

astearns: Even if we use something other than commas, commas might still not be right for the extension
… I’µ good with commas and not concerned about being backed into a corner

astearns: Proposed resolution is to accept PR

TabAtkins: I have a tiny technical nit about the grammar but not germane to this issue

RESOLUTION: accept the PR to solve this issue

<astearns> github-bot, take up w3c/csswg-drafts#11814

[css-gaps] Gap decorations with collapsed gutters

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11814.

kbabbitt: Oriol pointed out the way collapse tracks work in grid, when a track get collapsed, the gutters to either side overlap
… That’s fine if they’re empty, but will cause decorations to overlap
… I want to leave the definition of where gaps are to other specifications
… There are reasons to have overlapping gutters
… But there could be an animation of a gutter collapsing down could cause weird discontiunities
… I’m leaning to leaving the behavior as is, since it seems to cause the fewest surprises
… But wanted to open the floor

TabAtkins: I don’t recall the reasons to have only a single gutter; can you restate?

kbabbitt: The PR that landed the change was that gutters can be detected by abspos elements within the grid

TabAtkins: Ah. I think we should suppress the display of one of the gutters when they overlap
… We could do it by making all but one of the gutters transparent
… I don’t think people would like overlapping multiple decorations
… We could say that if gutters overlap, all but one are transparent in some way, and could say that if they’re animated together, the transparent ones could be faded out

kbabbitt: Your proposal is to define this in gaps to say if two gutters are exactly coincdental, draw only one decoration

TabAtkins: Yes
… When a track collapses, and gutters are coincident, only one paint

fantasai: Collapsing a gap is binary right now; you’re either collapsed or you’re not
… I don’t know how we would even define otherwise
… I agree with Tab that we should paint only one
… We should do something similar to border-collapse rules, where you use whichever is most prominent

astearns: I did not know we had those rules!

fantasai: I’m pretty cranky about the border-collapse code
… The rules about which border wins prioritize which style looks weirder
… Here, we don’t have a hierarchy for resolving conflicts
… If we ever have a region concept, we probably want the outermost border to win
… The boundary is most prominent, usually

astearns: Could there be decorations on the outside of subgrids that we should consider?

<oriol> BTW, rules for border collapsing conflicts are in https://drafts.csswg.org/css-tables/#border-specificity

fantasai: Yeah, if you have gap decorations that are more outside, they should get priority

kbabbitt: The conflicts rules in the context of tables are in the tables spec?

fantasai: They’re in CSS 2.1

https://www.w3.org/TR/CSS2/tables.html#border-conflict-resolution

kbabbitt: We’d just point to those

florian: I agree that tables got it wrong, because an edge is a specific thing
… I think saying the edges of a subgrid should win; parts that are special shoudl win over parts that are generic

astearns: Any other comments or questions?

(silence)

Proposed resolution is that we’ll suppress all but one decoration if gaps are coincident due to collapsing

kbabbitt: I’d say for any reason

fantasai: If we end up with negatively sized tracks and decorations overlap, both should be painted

kbabbitt: Fair

astearns: And amend the resolution to say we’ll use the same rules as border collapsing

Objections?

(silence)

<oriol> In fact in flexbox you can have overlapping gaps with items with negative margins, right? So better restrict to collapsed gaps.

RESOLUTION: Suppress all but one decoration if gaps are coincident due to track collapsing, and use the same rules as border collapsing

<astearns> github-bot, take up w3c/csswg-drafts#11857

[css-color-adjust-1] Forced Colors Mode support for gap decorations

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11857.

alisonmaher: The gap decorations spec define rule color, which is a shorthand, so the proposal is to add row-rule-color and rule-color to the forced colors spec

<fantasai> +1

<astearns> +1

<kbabbitt> +1

astearns: Any concerns?

dbaron: Minor nit, but the forced color spec looks a little inconsistent about listing short- or longhand properties
… Should probably be consistent about that
… The concept of what you’re proposing is fine

fantasai: The forced colors spec says to use the shorthand if there’s a shorthand

TabAtkins: We could be editorial and say “the longhands of blah blah blah”

fantasai: The real problem of the spec is that it lists properties, and it should be clear that the list isn’t exclusive, because other specs add properties all the time

alisonmaher: So just update to rule-color, then

dbaron: I think the editor of the spec can read it closely, but from a quick read it looks inconsistent

<dbaron> https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties

fantasai: I don’t see it as inconsistent

dbaron: Maybe it’ll all end up being shorthands

astearns: First thing is, add appropriate shorthand to the list to fix this issue
… Thus, resolution is to add `rule-color` to the list in the forced colors spec

kbabbitt: And delete `column-rule-color` since it’s covered

astearns: Hearing no objections…

RESOLUTION: add `rule-color` to and remove `column-rule-color` from the list in the forced colors spec

astearns: I agree with Elika that listing shorthand is sufficient, but I agree with David that it’s not necessarily clear to people not used to specs

I would argue that it's clearer to people not used to specs than to people used to specs :)

astearns: So I’d like to explicitly call out in the relevant section that shorthands apply to all encapsulated longhands
… So I’d like to take an explicit resolution to that effect

<dbaron> That might depend whether people are more familiar with the shorthands or the longhands, which might in turn depend on whether the shorthands or longhands are older.

(no objections)

RESOLUTION: add explicit text to the forced colors spec to make it clear shorthands also apply to their longhands

astearns: There should be an explicit criteria in the spec that says why these properties are in the list, so we know that new color propoerties should go onto the list

fantasai: Do we need a list?

TabAtkins: Yes, we need a list

alisonmaher: There is an additional list that has box-shadow and other things
… The main list is all colors
… For the main list, we might be able to do something to make that more clear

astearns: Actually, never mind; what’s in the spec seems good for this
… I thus drop my third proposal

kbabbitt: I was going to ask Elika’s question about whether we need a list
… I guess we can say any color component of a property is force-adjusted; for example, these properties

fantasai: Unless otherwise called out

kbabbitt: Yes

astearns: Do you feel strongly about omitting the list

fantasai: I feel it would be better for maintenance going forward to not have an explicit list
… I wouldn’t mind having a list in a note that’s noted as examples

<bkardell> that seems sensible to me

<bkardell> +1 to fantasai's comment

kbabbitt: I do agree that we shouldn’t have to update this spec every time a color property is added

florian: It makes sense having the general principle
… Otherwise, if the list is normative, that’s a maintenance burden

alisonmaher: Question on that note; in the list we don’t have some colors, but they’re in a second list as exceptions

florian: Color-related properties not affected, or affected in a special way; those should be in a normative list

alisonmaher: Sounds good

astearns: I think the proposed resolution is to take the list of affected properties and put them in a note saying, at the time of note-writing, here are the affected properties

Objections?

(silence)

RESOLUTION: put the list of affected properties in a note saying at the time of note-writing, here were the affected properties

<astearns> github-bot, take up w3c/csswg-drafts#6900

Republishing Tasks Permathread

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900.

astearns: Any concerns about FPWD for this module?
… Or anyone who’d like to take time to review the edits before moving on?
… Objections?

(none)

RESOLUTION: public First Public Working Draft of CSS Gaps

<astearns> github-bot, take up w3c/csswg-drafts#11999

[css-cascade-7] @sheet - allow nested @sheet statements?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11999.

kurt: For @sheet, should we allow sheets to be nested? It would be similar to @layer
… They should also be delimited with a period, like with layers
… My proposal is that we allow this for consistency

TabAtkins: This sounds reasonable; what’s the complexity about @import?

kurt: The behavior of @import in @sheet isn’t well defined yet

TabAtkins: Do you foresee any extra complexity?

kurt: I don’t

astearns: It makes sense to me to follow the layers model

<bramus> +1

astearns: Proposed resolution is to allow nested @sheet statements and follow the nested layer syntax

RESOLUTION: Allow nested @sheet statements and follow the nested layer syntax

<astearns> github-bot, take up w3c/csswg-drafts#12000

[css-cascade-7] Should anonymous @sheets be explicitly disallowed?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12000.

kurt: You can have anonymous layers, but for sheets, rules don’t apply until they’re imported but you can’t import an anonymous sheet
… So I think we should disallow that

TabAtkins: Agreed

<bramus> +1

astearns: Any reason someone might want to set up a bunch of sheets and then add a name later?

TabAtkins: No
… We’d have to make the rule mutable, and we aren’t consistent about that
… Worst case, you can put in a dummy name

kurt: If a sheet could have wildcards, maybe, but we don’t

kbabbitt: It does imply that when we write the CSSOM, the sheet name should be immutable

TabAtkins: We could make it mutable but a DOM string, but I don’t think there’s a great reason to make it mutable

astearns: Proposed resolution is to require a name for every @sheet rule
… Objections?

(none)

RESOLUTION: Require a name for every @sheet

<astearns> github-bot, take up w3c/csswg-drafts#11998

[css-cascade-7] CSS @sheet - is there a need for an @sheet statement (in addition to block)?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11998.

kurt: Another divergence from @layer: you can have a statement without any rules
… The difference is that in @sheet, there are no explicit priorities

TabAtkins: I agree
… The @layer is a completely different construct that just has a similar pattern
… If you need an empty sheet, just put empty braces after it

astearns: If the only purpose is avoid writing open-close brackets, that’s not worth the effort

TabAtkins: Right

astearns: Proposed resolution is that bare @sheet statements are invalid; block is always required

RESOLUTION: bare @sheet statements are invalid; the following block is always required

<astearns> github-bot, take up w3c/csswg-drafts#12001

[css-cascade-7] What happens with duplicate @sheet identifiers?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12001.

kurt: Yet another @layer divergence, which I used as imspiration for @sheets
… In @layer, duplicate names cause rules to be merged, but here this is up for interpretation
… Other name-defining rules are, last one wins, and I think that makes sense here

TabAtkins: I agree with the points in the thread
… @layer is setting an aspect of specificity, and not an independent construct
… @sheet does create a construct, and thus last shoudl win

astearns: Is that okay with you?

kurt: Yes

<bramus> (I’m undecided on it)

astearns: So @sheet conflicts go with last-defined wins

bramus: I’m just not sure which way this should swing, but Tab makes a good point

astearns: So your concern is more why @layer does this?

bramus: More that if @layer does this, why doesn’t @sheet? Authors might not see the technical different underneath the two things

astearns: How about a resolution to have @sheet use last-definition-wins for now, without prejudice; we can raise again later if the need arises
… Any objections?

(silence)

<kurt> w3c/csswg-drafts#11980

RESOLUTION: WHere @sheet names conflict, the last one delcared wins

kurt: Feedback welcome on #11980 as well

<kurt> Formatted version here: https://kurtcattischmidt.github.io/kurtspublishedw3cdrafts/AtSheet.html

<astearns> github-bot, take up w3c/csswg-drafts#11859

[selectors][css-scoping] Should :host(:has()) match?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11859.

alisonmaher: We previously resolved to allow host:has(), matching against shadow DOM descendants

<TabAtkins> :host:has() (allowed), :host(:has()) (what we're discussing here)

alisonmaher: But the spec doesn’t allow matching into the light DOM
… If we were to allow this, we’d have to change something
… I think we’d have to change what we allow by :host
… Want to open this for discussion

TabAtkins: The main objection for this was coming from Apple developers, so I’d like to have them in the room when we discuss this
… My opinion is we should allow everything because I like features, but I also appreciate performance concerns
… I can’t represent their opinion

emilio: This might not be an issue because of where Chrome stores (or maybe stored?) invalidations, but we really don’t want to do the same
… I do think it can be problematic
… I can check with the person who implemented :has() in Gecko, but I think this makes invalidating :has() rather complicated and I’m not sure how to go about it
… I can take an issue to check with David Shin, but I don’t see a great way of making this fast

astearns: I know Ryuske hosted Breakout Day sessions that were at least related to this; anyone attend those?

(no)
… I’ll look to see if there’s anything there I can bring back to the issue
… We’ll have to come back to this later

alisonmaher: Sounds good to me

<astearns> github-bot, take up w3c/csswg-drafts#10296

[selectors] Adding a `:heading()` selector for headingoffset?

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10296.

TabAtkins: There was a suggestion for adding a :heading to apply to all headings, and also to select to select things based onthe outline algorithm that eventually got dropped
… There are HTML attributes that let you adjust the level of headings in a subtree, so this is relevant again
… Anything we do here should be contigent on the HTML thing actually happens
… Proposal is to allow `:heading(an + b)` that applies to adjusted heading levels rather than tag names

kizu: I support this

<TabAtkins> (comma-separated list of an+b expressions)

kizu: Do we want to have a shortcut to allow `:heading(n)`

TabAtkins: Yes

astearns: Proposed resolution is allow comma-separated list of an+b expressions to apply to adjusted heading levels
… Seeing no objections,

RESOLUTION: Add `:heading()` that accepts a comma-separated list of an+b expressions

TabAtkins: All the UA stylesheets apply to headings by tag names, which has tag-level specificty
… A `:heading()` would by default of class specificity
… Is that a problem?
… Should we say `:heading()` has tag specificity rather than tag specificity?

kbabbitt: To the extent this would juggle rule application order, that would be confined to the UA stylesheet, right?

TabAtkins: Yes

kbabbitt: So the implementor could rejuggle styles

TabAtkins: Yes, but author styles might get overridden byu the new UA styles if this has class specificity

kbabbitt: Ah, so that’s the concern, is authors adopting the new pseudo and getting surprising results

TabAtkins: Yes, it’s representative

<astearns> change my h1, h2, h3, h4, h5, h6{} rule to :heading{}

TabAtkins: of the general class of concerns

<kurt> *:heading()?

astearns: I think there’s good reason to define this as having tag specificity

<TabAtkins> (the workaround is `:is(div:not(*), :where(:heading))`)

kbabbitt: Do we have other pseudos that do this?

TabAtkins: No; we don’t have any pseudos that stand in for tag nakmes except maybe :any-link

kizu: It’s basically an alias to the adjusted tag names, so tag specificity makes sense here

emilio: Have we checked if changing the UA style sheet will result in conflict?
… I agree that migrating to H-tags to this makes tag specificity appealing
… But having a pseudo with tag specificity is odd

<kizu> `:is(h1,h2,h3)` — also a pseudo-class with tag specificity, kinda

emilio: What about attribute selectors?

TabAtkins: They’re exactly class level

emilio: …I’d rather keep to class specificity for consistency, unless we find out it breaks lots of things

<bramus> +1 on staying consistent

emilio: I think that’s somewhat unlikely

astearns: I’m not that concerned about the user stylesheets
… There are likely to be UA rules that can’t use the new thing for whatever reason
… I’m worried about defining this thing and then making it so you can’t use it without knowing the special incantation

TabAtkins: I’m pretty evenly divided on this

<kizu> one of workarounds: `:is(:not(h1, :not(h1)), :where(:heading(1, 2, 3)))`

<lea> What about role=heading aria-level=N?

emeyer: is there a way we can make it so that... you know how :where() doesn't have specificity implications, can we do something related so it has specificity of the things inside it?

emeyer: so :heading(1) that's equivlaent to `h1`, if I have :heading(n+4), can we have the thing in the parens convey the specificity.

<lea> That’s not like :where, :where has 0 soecificity. It’s more like :is or :not

TabAtkins: Ths issue is all things you can do here, you could do with `:is()`

(it's always tag-equivalent when you desugar it)

dbaron: I worry about the cost of making rules more complex for everybody
… For implementors, for authors

<emilio> 1+

dbaron: This feels like a case of adding more magic, and probably isn’t worth more magic

<emilio> +1*

dbaron: The additional overhead of learning and understanding isn’t worth it
… I don’t feel strongly about this, but that’s where I lean

<ntim> +1 to dbaron

astearns: The sense of the room is that making an exception is not motivated enough
… So we should open this to a wider audience to see how people will use this

TabAtkins: Like IDs exist only for IDs, tags exist to apply to tags, so it’s probably unlikely to cause issues in practice
… I think having :heading() being class specificity should be safe

<kizu> `.foo { … } h1 { … } <h1 class="foo">` — replacement here will not be safe

astearns: Since that’s what falls out of the definition, do we need a resolution?

TabAtkins: Let’s record the sense of the room

astearns: Objections?

(none)

RESOLUTION: `:heading()` has the expected class-level specificity

astearns: Lea asked about ARIA heading roles

TabAtkins: That’s up to HTML, not our problem

astearns: Fair enough

<dbaron> I think in general aria attributes don't affect non-a11y things, though.

("what are headings" and "what level are they" is a host-language problem)

20 mins break

kbabbitt, w3c/transitions

github-bot, take up w3c/csswg-drafts#11969

[selectors][css-conditional] Pseudo-class or combinator that is syntactic sugar for wrapping in an `@rule`

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11969.

lea: a while back i posted a proposal for :media() pseudo-class

lea: was well received, tho didn't get finished

lea: since then i've been spotting a more general problem, not just MQs

lea: combining filterering logic from other at-ruels with selectors

lea: conditional rules in general are obvious example

<astearns> (we just added media() to @import: w3c/csswg-drafts#10972 (comment)

lea: but also @layer. use-case is you want to style regular elements by tag name, but give them lower priority by defualt, or offer a class name to apply them as well

lea: or @scope, with one selector in the scope and another selector outside

lea: @starting-style too, might want it to share some styles with a regular selector

lea: so at this point I think we need a more general solution

lea: i posted a proposal but am not married to it, just want to solve the problem

lea: proposal is a pseudo-class that is generic enough, letting people specify any at-rule

lea: it's sugar for nesting

lea: in every example i gave, the "after" version includes duplicates

lea: someone thought this was a compact way to do nesting; that's a benefit, sure, but not the point

lea: right now if you have something applied via an at-rule and a selctor, duplication is all you can do. and someontimes that can be *dozens* of declarations

lea: Oriol suggested it only makes sense for CSSGroupingRule

lea: that drops @page, but that's not a major use-case

lea: someone suggested the opposite, having an at-rule that allows combining with selector logic

lea: that could work, but it's less flexible, selectors are better known

TabAtkins: you also ccan't combine multiple at-rules that way

kizu: i think it would be great to have something like that. the problem is quite common, for darkmode for example

kizu: have a selector that applies it, and an at-rule that applies it by default

kizu: this could potentially be done with block-level mixins, but it woudln't be a sconvenient as what's expressed in this issue for one-offs

<lea> Dark mode is actually a good use case for combining the logic with `@scope`, if you have e.g. `.dark` and `.light` and `.invert` classes

kizu: you could make a mixin that wraps any number of rules and use it in multiple spots

kizu: but for one-offs, having this just live in the selector is convenient

oriol: mentioning a point i raise din the issue

oriol: this is equivalent to some desugaring, and we have options

<fantasai> I have to drop soon, but I have some concerns about using a pseudo-class here.

oriol: expand to the desugar, or say the behavior is equivalent

oriol: my concern with the first is it's easy to have combinatorial explosions

oriol: with second option it seems more complex to implement

oriol: so a bit tricky

<fantasai> Because a pseudo-class is classifying an element, and these conditions aren't connected to an element but to a selector as a whole

oriol: since the order of these things matter, i don't think a pseudo-class is right

oriol: should be a combinator maybe, use the @ as a combinator

<Zakim> lea, you wanted to react to oriol

lea: right, i forgot about the combinator idea, i do like that better. Tab will have to commont on whether it's possible grammar-wise

TabAtkins: i'll have to think about it

emilio: i'm curious about the ocmbinator idea. what does it combine with?

emilio: at least for some of these reules it's quite complicated. @media and @supprots are fine, but @laer and @scope change the cascade order

emilio: i'm just not sure how we'd define mixing multiple of these

emilio: for each rule that provides a boolean answer, that's fine. for @scope and @container, it might make sense as long as we prevent the cascade-order side effects, otherwise i don't know how it works. how does multiple @scope work

emilio: so i'd rather not start making selectors affect the cascade order other than via specificity

<ntim> Not super convinced about the cost/benefit ratio of the idea

dbaron: another concern is if we want to do this, we shoudl figure out the perf characteristic we want

dbaron: some filtering at-rules have an expectation that the filter happens at a particiular stage. when thye look like selectors, the normal expectation for selector matching is a different stage of the process; might happen later and many more times than as an at-rule

dbaron: and that's tied into the question of how they're represented in the cssom, and if this expands the way oriol said

lea: to emilio, @scope/layer/container ar emajor use-cases.

lea: just solving for conditionals would be useful, but it doesn't reach the 80% case

lea: @container is biggest from the non-conditional cases, then @scope then @layer

lea: to dbaron, i think perf should be similar to the desugared veresion or better, since we're not duplciating declarations

lea: to oriol, combinatorial is less here than regular nesting, less at-rules to combine with

lea: so even if we go that way, it's not as bad, and we cna introduce a maximum limit

lea: i think the number of at-rules in actual use is fine, two or three

lea: thinking more abou tthe combinator idea, while i like the syntax, i don't like that it muddles what a combinator is

lea: combinators get you from one element to another element

lea: here we're not doing that, at-rule can be wrapping the whole thing, or something at the end, etc

lea: not sure about this

lea: another benefit of doing this in selector land, selectors have forgiving handling for selectors we don't understand in :is()/:where()

lea: so authors could use this immediately and wrap in an :is()

lea: while an at-rule that's misunderstood gets dropped entirely

lea: last, i was thinking what if instead of a pseudoclass, could we @sheet andd import that internally?

lea: could have the style rule and at-rule, then just import the @sheet inside of each

lea: tim, you said not sure about cost-benefit. is it the cost of the syntax or the benefit of the results?

ntim: cost of the syntax, mostly, and having devs understand the syntax

ntim: i'm not convinced the current proposals are easy to understand

ntim: so those combined vs the benefit from it...

lea: fair. i htink if the syntax was as close to the at-rule as possible would help. but there might be value in two separate resolutions

lea: (a) is this a problem to solve in some way, and (b) the specific syntax

ntim: also, where the combinator/pseudo-class fits in the order...

lea: that's explained in the proposal

lea: the pseudo-class downside is the relative order of pseudo-classes mattered, which is new

TabAtkins: This is a problem worth solving. I had to do this duplication before, avoided doing somethings because of the duplication. I think the right place to solve it is on the declaration, neither the @rules or the selectors.

Combining our existing rules because they work in many ways is not super feasible in an understandable way. Giving us a mechanism to easily dedupe chunks of declarations would be good. Mixins are the obvious way, or your idea of being able to reference an `@sheet`

TabAtkins: It requires more work for one-off cases, but I think that's still justified for the overall improvement. Some way to do rule-level deduplication of contents

dbaron: i probably agree witih Tab

dbaron: i think there are widely different solutions to the underlying problems

dbaron: i'm very worried about the complexity of this particular set of solutions

dbaron: two things. first is comment about perf

dbaron: lea said shoudl be faster because less duplication

dbaron: what i meant was, if you have @media or @support that doesn't match, those rules get thrown out earlier than doing selector matching

<emilio> +1 to dbaron

<emilio> (Was on the queue for that)

dbaron: whereas if it looks like as elector, the syntax is saying "we'll try to match all of these", then we get to the top and see the :media(). we've spent all this time on selecto rmatching for rules that we could ahve avoided

lea: doesn't that depend on how it's implemented?

<oriol> This is my combinatorial explosion concern https://www.irccloud.com/pastebin/3PIUwxZd/

dbaron: yes, but if you assume it's going to be implemented by desugaring to some other syntax, you need to make sure that's practical to

dbaron: so i don't think it's trivial to say "it'll be faster", you'd need a practical proposal for the underlying model

dbaron: and ahve a plan for what to do about it

dbaron: second point, when you say "is it worth solving", i think we still need to udnerstand what cost

<ntim> +1 to dbaron

dbaron: when i look at this proposal, i ask how much complexity is this adding to selector matching. is it 20% more complex, or twice as complicated?

dbaron: i dont' know the answer off the top of my head, but I think when i look at a proposal like this, we're really asking the question "is it worth potentially doubling the complexity of selector matching to solve this", which i think is a real possibility

dbaron: while I think Tab's mixin idea is much lower cost and does get the bulk of the use-cases

<Zakim> kbabbitt, you wanted to comment on the @sheet approach

kbabbitt: wrt @sheet approach, we're very limited now in where we can put @import to reference the sheet

kbabbitt: apart from that, i tend to agree with tab adn david that i worry about the complexity this is adding

kbabbitt: i think it's worth exploring if we can solve this with mixins

lea: i agree with Tab as well. like I said in the beginning, i just want to solve the problem, not married to a solution

lea: since i've seen a lot of use-cases, their characteristics is usually you don't have a ton of them, but th eones you have are big. wrapping an entire stylesheet, an entire theme

lea: and you just want to wrap the whole thing with a selector *and* an at-rule

lea: btw to dbaron, i said we *might* gain some perf from deduplication. unsure if it's a net positive or not.

lea: but i might be convinced this can be done with mixins

lea: so, if mixins are solving this, does it chagne the cost-benefit to drop some cases? like dropping @layer and only doing conditionals or @scope

lea: is there a subset that we could carve out that makes it easier to solve with a pseudo-class?

`: if()` even

TabAtkins: [i wasn't minuted]

lea: smaller places come out of here, like @supports

<dbaron> (though on second thought, earlier filtering probably looks a bit like the bloom filter optimizations that we already have so it's probably not too hard)

lea: some new CQs like :stuck

<dbaron> (but many of the other issues remain)

<astearns> (unminuted back and forth)

astearns: i know mixins are still vague, but are there problems outlined in this issue that they're not a solution for?

TabAtkins: Mixins should be able to trivially address anything that can be nested in a style rule today

TabAtkins: Any model we're thinking for mixins allows that. Conditionals work, scope works, container works. layer currently doesn't, but should be fine to amend it to do so

TabAtkins: I think those are all the rule examples that have been given, so it should be fine

astearns: so everything in this issue should be input ot our mixins work

TabAtkins: Yes, nested @layer is the only new use case

kizu: to answer lea's q about if there's anything form what we were talkinga bout that would b euseful in a selector space, i can only really think of CQs

kizu: with CQs you can have a named container, then choose a container for which you're running the query

kizu: with selectors it could be useful as a shortcut to be able to indicate at which element you're running the querys

kizu: right now to do this you ahve to write a seaprate selector creating a named container

kizu: so kinda convenient in selectors. exception is probably not usable inside a :has()

lea: right now, proposals around mixins have been global. that works for the big-chunk use-cases, but less for the smaller use-cases

lea: liek "i just want to add two delcarations if this is supported"

lea: wonder if some small version of scoped mixins would be useful here

lea: naming things globally is hard. small targeted mixins with local names could be more lightweight

<kizu> (w3c/csswg-drafts#11798 — an issue about scoping named things)

TabAtkins: The possibilities there are interesting. Mixins will get applied before the cascade, at sheet parsing layer. We could have a notion of lexical scope, that is I think a viable thing to explore.

TabAtkins: No comment on whether we'll for that but it sound plausible

astearns: so queue is empty. close this discussion for now?

lea: yeah. fine to even close the issue. looks like we want to take this as input into mixins.

lea: so i'm hearing we're sorta in agreement about solving this as long as cost is reasonable. doing it in selector isn't reasonable in cost/complexity. so we'll take it as input to ensure mxiins satisfy these

TabAtkins: can I have lea open an issue on Mixins spec?

lea: yeah, will tag in this issue

ACTION: Lea to open issue with these use cases and ideas tagged mixins

PROPOSED RESOLUTION: We agree the problem needs solving, but doing it selectors seems too complex. We'll instead close this and make sure mixins satisfy these use cases.

astearns: objections?

RESOLUTION: We agree the problem needs solving, but doing it selectors seems too complex. We'll instead close this and make sure mixins satisfy these use cases.

github-bot, take up w3c/csswg-drafts#2425

::slotted() should full support complex selector!!

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2425.

lea: representing this since it's opened by a non-member

lea: since ::slotted() only does compound selectors, it imposes constraints on the markup that aren't good for a11y, seo, etc. forces a shallower structure than is ideal

lea: in many cases you ahve new components thata re just a div, but that way you have logic and styling in them. <carous-el> and <carous-el-item>

lea: lots of instances of this, parent control and dummy child control, just to get ::slotted access

lea: so lots of people confused

lea: usual pushback is hard to implement

lea: and pushback against ::slotted() a combinator is it doesn't support complex selectors

lea: think we'll need to do that at some point anyway, and then we'll have a pseudo-element with complex selectors, which is worse

lea: so i think this adds to the pile of reasons slotted should be a combinator (not to beat a dead horse)

lea: i hear the arguments about not breaking encapsulation, don't want a component tos tyle light dom... i disagree, but i get them

lea: but for things inside the component's own light-dom subtree, it's arbitrary to say they can style their direct chidlren but not descendants

lea: like how would we do <tab-el>? or <s-el-ect>?

astearns: in your comments you said usual complaint is hard to implement. i think keith put this on here to ask

TabAtkins: do we want to delay until Emilio returns, then?

ntim: i wanna hear from Ryosuke as well

astearns: so maybe we can take this up... would this be okay to take up in the Forms TF? can we get ryosuke to join that?

ntim: how is that forms related...

astearns: so we're closing this with "i dunno" for now

github-bot: take up w3c/csswg-drafts#6245

Interpolate values between breakpoints

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6245.

TabAtkins: we talked about this a few weeks ago. people liked -mix(), but not -map() or -scale()

lea: linked, we talked about interpolate, tween, range, scale

lea: we're looking for somethign that works for many types

lea: color-sacle is fine, calc-scale is fine, but image-scale is bad, and generic scale() conflicts with transforms

lea: i think tween() is obscure and tied to animations

lea: range() sounds like it returns a range

lea: intermediate() is as longa s interpolate().

lea: interpolate() is clearest, it's just long. but other than that i think it's best option

lea: so if we can't do scale() i think interpolate() is best

lea: confusing is worth than long

oriol: i had a minor question of what's different between mix() and interpolate()

TabAtkins: The mix functions do a weighted average, the interpolate functions take a sequence of values and an input value, like a gradient, and give you where your progress position landed on

e.g. `color-scale(30%, white, red 30%, black)` would give you red

kbabbitt: i like the name interpolate(). agree it's long but it's used elsewhere

kbabbitt: bramus pointed out we use it in color-interopolation and interpolate-size

kbabbitt: i agree clear is more important than short

dbaron: another idea (maybe a bad idea, but worth considering) is use the word tab just said, gradient()

dbaron: that's a thing people currently understand

TabAtkins: i think color-gradient() is a little funky

astearns: have there been any arguments against interpolate() besides length?

TabAtkins: no

<ntim> gradient reminds me of math gradient descent

oriol: a shorter idea, pick()?

`image-pick()`, `color-pick()`, `calc-pick()`

TabAtkins: My only worry is that it sounds like you're picking one of existing options, not interpolating

TabAtkins: we can just go for interpolate()

lea: yeah i think anything else is just unclear. saving a fe wmore characters isn't worth it

astearns: anyone who would prefer not to resolve on interpoltae() today?

ntim: what's the sytnax of this function?

TabAtkins: [summarizing] it's basically the linear-gradient() syntax, more or less

astearns: objectiosn to using interpolate()?

RESOLUTION: Rename the interpolation functions to *-interpolate()

lea: is it before or after the type particle in the name?

TabAtkins: after, like color-mix()

<bramus> Yay!

astearns: but if yo uwant the other way, open an issue

github-bot, end topic

github-bot, take up w3c/csswg-drafts#7869

[css-forms-1] `control-value()` function

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7869.

ntim: a problem devs often ahve is they want to refer to the value insdie a range or text input

ntim: for range input, you see a bubble with a number in it following the thumb

ntim: in the current Forms draft there's a control-value() function

ntim: syntax is draft-y, i think we can match attr()

ntim: i'm hoping to get a formal resolution

ntim: and maybe we want to think about the problem of, do we want to scope this to the control itself, or allow other elements to refer to the values of other elements

ntim: havne't thought too mucha bout that yet

TabAtkins: I think we should add this. Few details that I listed. Control value is just as dangerous as `attr()` but should be solvable the same way, just repeat the same handling

TabAtkins: 2. I don't think we should exactly match the attr() syntax, we're not doing arbitrary parsing of an unknown string, we have a well-known value coming from the control

TabAtkins: getting it as a string is always useful, getting it as a number also useful

TabAtkins: other than that, I think it's a good idea and we should do it

ntim: i agree we should let people switch the types. might want it as a number to use in a calc() to set a width

lea: also agree we should do it

lea: how do web components hook into this for their own values?

lea: and also, we do want it to inherit in some way. the tooltip of a slider often shows the slider value. so how does that work if it's only on the slider itself.

TabAtkins: if it's a pseudo-element it's fine, they refer to the main element

lea: yeah but that doesn't solve a custom element

ntim: yup, pseudo-elements get you part of the way, but not all the wya

lea: if it resolves at the right time it's not insumoutable

ntim: how does inheritance work?

ntim: you'd need to get the value out of the slider and pull it up?

TabAtkins: yeah that's hard

<kizu> anchor positioning and scroll-driven animations :)

ntim: the separate element reference can be another issue

dbaron: there was some discussion of security restrictions in the bug, wanted to make sure it's not lost

TabAtkins: yeah, i mentioned it should be the same as attr()

ntim: yup, to avoid exfiltration into a url

kbabbitt: i was also thinking about security issue here. wondering if it has to be stronger than attr(), like using it on a password input

kbabbitt: i don't know if attr() already addresses this

TabAtkins: it should, the attr() restriction prevents any value produced by it to be used in a url

astearns: so it sounds like we're just asking for waht's in the draft to be blessed?

ntim: yeah

astearns: proposed resolution: control-value() as described in the draft looks reasonable

RESOLUTION: Accept control-value() as described in the draft (with subsequent edits)

dbaron: also wanted to point out there's proposals to have selectors that depend on control values

github-bot, take up w3c/csswg-drafts#11164

[cssom-view] Scroll steps don't match implementations

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11164.

emilio: the cssom-view spec has a bunch of issues, it doesn't match impls in several parts and are just wrong in several

emilio: scroll events aren't fired at a specific time, scroll-snap are fired before other scroll events, there's no distinction between visual viewport and others

emilio: i posted my research on how browser behave in this regard

emilio: webkit and gecko order visual viewport and regular scroll events consistently

emilio: with addition of scrollEnd and scorllSnap, the chromium appraoch of just having them on the same separate queue and fire them in order makes sense, i think

emilio: in aprticular, i don't see a reason why scroll triggered by some events should fire on the same frame vs another

emilio: so having all scroll events in one queue, fired in order

emilio: and side effects firing in next frame. seems fine

emilio: i have a patch to fix all this, but wondered if people have strong opinions

astearns: did you do any looking back thru commit history to see why scrollsnap is sbefore all other events?

emilio: no, they were the last added and i think they were just put in the wrong place

TabAtkins: i defer to flackr, so as long as he's looked at it i'm happy to accept emilio's opinion

astearns: everyone was pinged, no comments in a few months

dbaron: flackr or skobes, i'll ping them both

astearns: do people want to wait on a positive response? i'm happy to just change the spec

TabAtkins: i think the spec is messy enough that we can just merge what we have and quibble over the details

ntim: should i ping Simon?

emilio: yes plz

astearns: do you think we should wait on resolution?

ntim: dunno

dbaron: i guess i dont' feel like we have to wait. would be nice to get thru to them at some point, but it can be post resolution

astearns: so proposed: Fix up the spec to put all scroll-related events in a single queue

ntim: one argument for waiting for simon is he's co-editor

emilio: that means he can revert my change

astearns: yeah, it's been months and i'd like to move things along

astearns: objections to the proposed resolution?

RESOLUTION: Fix up the spec to put all scroll-related events in a single queue

github-bot, end topic

<br dur=1h>

<astearns> github-bot, take up w3c/csswg-drafts#11828

[css-anchor-position] Computed value of `position-area`

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11828.

TabAtkins: the position-area property has a number of syntaxes - it has two that are exactly equivalent

<TabAtkins> start start and `block-start inline-start`

elika said they should be equivalent, tab doesn'thavean opinion

TabAtkins: which of the pair it should go to elika? opinion?

<fantasai> astearns: Should it be the shortest serialization or the most explicit one?

kiet: I opened this - It comes up because I am implementing and some of the tests are mismatched because webkit serializes one way, chrome another - if we have one way it's easier to write tests

florian: make it short if we can

TabAtkins: if it is already the case that multiple browsers do this, but just disagreeonwhich I would agree and say lets just use start start

Proposed resolution: block-start and inline-start will serialize to start start and they will compute to start start

kiet: this also applies to self block start...?

TabAtkins: yes

<TabAtkins> proposed: block/inline-start-end (and the self-* variants) compute to start/end or self-start/end

resolved

RESOLUTION: block/inline-start-end (and the self-* variants) compute to start/end or self-start/end

RESOLUTION: block/inline-start-end (and the self-* variants) compute to start/end or self-start/end

!!!!

<astearns> github-bot, take up w3c/csswg-drafts#10422

[css-anchor-position] flip should also flip safe-area-inset values

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10422.

fantasai: position-try flipping should also flip the safe-area-insets

TabAtkins: If you have left: env(safe-area-inset-left) and you flip that to become a top value, you almost certainly want to use the safe-area-inset-top instead of the left.

TabAtkins: That seemed obvious, so I edited it in.

<TabAtkins> commit is here https://github.com/w3c/csswg-drafts/commit/e143edf116418e86e6c940061515d856a70a8d2d

astearns: Does this only happen for top-level values that are the appropriate env() function

astearns: or any component of the value that might happen to be referenced

TabAtkins: the env() function itself will flip if the property flips

astearns: if it's wrapped in complicated calc()

TabAtkins: they all flip

astearns: any other questions?

PROPOSED: env(safe-area-inset-*) flip also

RESOLUTION: env(safe-area-inset-*) flip also

[css-anchor-position] Clarify computed value serialization for `anchor-scope`

TabAtkins: anchor-scope is <ident>#

TabAtkins: in practice it's a set, not a list -- order doesn't matter

TabAtkins: question was what order should it serialize in?

TabAtkins: fantasai argues that Computed value says "as specifies"

TabAtkins: Order needs to be well-defined enough to be specified

TabAtkins: so either need to define a sort order or use input order

TabAtkins: so suggestion is to use the input order

astearns: The only benefit in sorting the serialization is, if something is looking for style changes then the sorting would fail some false positives

astearns: but that's probably not useful enough to require sorting

TabAtkins: if you have allow-discrete transition, that would kick off a transition with no effect

astearns: so I'm fine with saying computed value is as specified

<TabAtkins> fantasai: yeah, i think the ideal computed value woudln't maintain the order, for this reason, but it's such an edge case to care about

astearns: Proposed resolution is the list of idents in anchor-scope are computed in the order specified

RESOLUTION: the list of idents in anchor-scope are computed in the order specified

[css-anchor-position] Naming of the `inside` and `outside` `<anchor-side>` values

TabAtkins: Right now, for generic side names, we use keywords inside / outside

TabAtkins: map to left/right/top/bottom depending on whether it puts anchored item inside the anchor or outside the anchor

TabAtkins: e.g. left: anchor(outside); puts the anchored item outside the anchor, i.e. to the right of the anchor

TabAtkins: jwatt felt these keywords were not super clear and suggested some alternatives

TabAtkins: Personally I think inside / outside are pretty fine

TabAtkins: and also these names have been deployed, so unless a strong reason to change, propose to close no change

kizu: I think I still like inside / outside more than anything proposed

kizu: given we also have interop thing, we should keep it as-is

<jwatt> I don't have a strong opinion

astearns: objections to closing no change?

RESOLUTION: Close no change

[css-anchor-position-1] `position-area`: `self` keyword inconsistency

TabAtkins: We have both normal logical keywords and self-* logical keywords

TabAtkins: using either containing block writing mode or box's own writing mode

TabAtkins: Kiet pointed out that there's an inconsistency in the keywords about the placement of 'self'

TabAtkins: This was intentional on our part, because self- is not modifying the axis, but the direction

TabAtkins: x-self-start is combining physical direction and logical direction

TabAtkins: whereas self-inline-start is using self writingmode for both axis and direction

Kiet: Wanted to understand why it's the case. once I read Tab's comment, it makes sense

Kiet: So I think it's fine to keep it like that

Kiet: Another issue which is editorial is, in some places we use self-block and other places we use block-self

TabAtkins: Oh, indeed we do!

astearns: Is it just in anchorpos spec or others?

TabAtkins: just here

TabAtkins: but that is definitely an editorial mistake

fantasai: That raised the question of what was intended.

TabAtkins: Ohh, yeah.

TabAtkins: I think it still needs to be self-block-start, since it's interpreting the axis also per the self writing mode

TabAtkins: ...

TabAtkins: We did a copy-paste error probably

<ntim> I heard block as a verb :D

<ntim> block self start

astearns: Is that an argument to make the change?

TabAtkins: just an editing error

TabAtkins: more general argument that self-{block-start} is what we have here

TabAtkins: other way around could imply you're taking the axis (block) from the container and the direction (start) from the self

RESOLUTION: x-self-start and self-block-start are correct, fix the spec

[css-anchor-position] Let more pseudo-elements have implicit anchor elements

TabAtkins: Anchor Positioning defines notion of an "implicit" anchor element, a relationship that other web platform features can define

TabAtkins: e.g. for <select> picker, the implicit anchor is the <select>

TabAtkins: We've also talked about making ::scroll-marker-group implicitly attached to the scroll container

TabAtkins: More general question is, do we want to apply this generally for pseudo-elements

TabAtkins: so for any tree-abiding pseudo, should it have an implicit anchor element of its originating element

TabAtkins: I think it's a reasonable idea

TabAtkins: That way a ::before pseudo can be automatically anchored to its element

ntim: I could see this being useful for forms

ntim: If you use ::after or ::before or whatever

ntim: Can anchor tooltips easily without extra work

TabAtkins: for forms, there might enough structure sometimes to allow someoverridden

TabAtkins: e.g. might want something to attach to thumb of a slider

TabAtkins: I suggest we define that by default, imply the originating element

<kizu> +1

TabAtkins: but other specs can override

ntim: Is this web-compatible?

TabAtkins: Right now if you don't specify a position-anchor, all of your anchor references just wouldn't work

TabAtkins: so seems pretty unlikely that ppl are depending on broken behavior for this right now

TabAtkins: we'll see, but I think this is safe

<fantasai> +1

astearns: If it was out in the wild longer, might have more worries, but

fantasai: Not even been a year since shipping anchorpos

PROPOSED: All tree-abiding pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined

fantasai: should it be all pseudo-elements?

TabAtkins: ok sure

TabAtkins: not observable

fantasai: but makes less of a maintenance problem if later it is

PROPOSED: All pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined

astearns: Other questions/comments on proposed resolution?

astearns: objections?

RESOLUTION: All pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined

[css-anchor-position] Allow a positioned el's containing block to be the anchor

TabAtkins: When I was on a podcast with Miriam, question of why can't an anchor element anchor to its own containing block.

TabAtkins: Indeed it doesn't make a lot of sense. you could for example anchor it to another abspos that's anchored to the containing block.

TabAtkins: Podcast host filed issue for us.

TabAtkins: Ian pointed out that you don't need anchor positioning in order to position relative to containing block, that's how positioning currently works

TabAtkins: Doing so would potentially limit what you can do in some cases when you've got a container that's nested inside itself

fantasai: ????

TabAtkins: ian pointed out usability issues.

TabAtkins: So I suggest we close no change. You don't need anchorpos to do this.

TabAtkins: Someone asked if that limits what you can do with position-try

TabAtkins: but that doesn't require using anchor positioning

kizu: I don't understand the argument about useful cases

kizu: My thinking generally was that, even though yes you can use just top: 0; to attach to your CB

kizu: didn't make sense that you can't use an anchor name

kizu: So you are limited by this, you cannot use anchor() to target it .

kizu: In my mind you should be able to do this

kizu: Case where inside you have element with the same name... I don't see a use case where I would want this

TabAtkins: The name of your CB is just, you spell it without the anchor() function at all. It can be addressed more simply. Means same as what you would get from anchor()

kizu: I've cases where I susbtitute dynamically the name with stuff

kizu: e.g. :hover { assign name }

kizu: Wrapper breaks this

TabAtkins: In that case, you can hack around it with a dummy abspos

kizu: I think I saw this in some other cases, like link to ??

kizu: People playing with anchor pos stumble on this limitation and wonder why they can't

kizu: It's common to run into it

<TabAtkins> fantasai: it also means you can't use position-area syntax or the combination fo that and anchor-center

<TabAtkins> fantasai: i think it's weird to exclude it

<TabAtkins> fantasai: i don't want to close this unless there's a good reason not to

iank_: I have good reasons why you can't do this.

iank_: On the surface this seems reasonable.

iank_: Part of the issue is that devtooling for abspos should show what the actual CB of an element is. Currently they don't, which creates lots of confusion about scoping.

iank_: A simple thing that browsers can do is show the IMCB

iank_: so devtooling needs to improve substantially

iank_: In no particular order

iank_: The problem with using position-area with this is that the available size is always going to be zero

iank_: E.g. position-try-options doesn't work as you might expect, for example.

iank_: Part of this is also, when you are applying scroll adjustment or scroll filter

iank_: that currently happens within the CB

iank_: So it doesn't actually work

<TabAtkins> (whereas anchoring to a a dummy abspos with `inset:0` does "work" - it scroll like any other content

iank_: Next reason is, it's got poor interaction if CB itself is a scroller

iank_: In that particular case, you might say "I want this to be right of the CB", but it's within the scrollable area. Doesn't do what you want.

iank_: We had previously talked about mode switch so that your CB rectangle would be the scrollable area

iank_: If we do that, then your position wouldn't make sense

iank_: Couple more reasons...

iank_: The component example, anchoring something to a component

iank_: put in issue. Would break this, and require wrapper elements for what I think will be a common use case.

iank_: I could understand an argument for adding convenience functions to reference CB edges

iank_: but I don't think we should do this, will have bad side effects

TabAtkins: On that note, syntax of anchor() and position-area definitely has space for predefined keywords that whatever we want. We could put container as a keyword

iank_: Part of ask here is, you want to be able to select what CB is laying you out

iank_: You provide some CB name on a CB, and then your abspos will skip up to the CB that matches its name

<TabAtkins> agree fwiw. (but definitely a seaprate issue)

iank_: this would solve a lot of problems where people are applying 'position: relative'

We already resolved to add that, didn't we?

kizu: ...

kizu: I think for ?? it might be useful.

<kizu> w3c/csswg-drafts#2406

kizu: For scroller-based, I think a better fix could be is the ??? pseudo-element that oriol proposed

kizu: I also agree that maybe having something like a named CB could be nice

<TabAtkins> yeah, being able to distinguish inside-scroller from outside-scroller is pretty important to do eventually

kizu: but my main argument is just that, we have at least 3 cases where authors stumbled across this when using anchor positoining

astearns: I confess, I didn't follow the argument that said the available space will always be zero. But if that's the case, Roman, would the cases where ppl tripped over this, would it even be useful for them even if it worked?

<TabAtkins> (if the CB *is* the anchor, then position-area's grid is degenerate; the center cell fills the entire grid

<TabAtkins> )

kizu: The available space question is only relevant for cases where you use position-try

kizu: ...

kizu: Not sure if you could use 100% as a substitute for anchor-size()

iank_: percentages resolve against the CB

kizu: but you couldn't cross axis

kizu: With anchor-size() you can do calculations based on both axes

iank_: if that's desired, we can add syntax for it

TabAtkins: In that case will want different ones for inside / outside scrollers

kizu: But definitely need devtools to help authors

iank_: 100% agree. I've been advocating to any devtools ppl that will listen that abspos needs help from devtools

iank_: I'm happy to explain what would be useful

[discussion about what to do with this discussion and the various duplicats]

astearns: So proposed resolution is we intend to allow you to target the container with a keyword?

TabAtkins: but keep not referring by name

fantasai: How does that solve the problem?

<TabAtkins> like `anchor(container)`

<TabAtkins> like `anchor(container top)`

<iank_> `anchor-size(container width)`

fantasai: not sure I understand

astearns: All sorts of things go wrong, but only if you refer to it by name?

TabAtkins: Keyword fixes one thing that's wrong. other things are still just as wrong.

TabAtkins: but ability to refer to scrollable area vs ... need keywords to refer to these things

TabAtkins: Right now no way to refer to scrollabe area of an anchor

<iank_> `anchor(container-scroll bottom)

TabAtkins: but for container, might want either one

<iank_> `anchor(container-scroll bottom)`

astearns: Is it reasonable to ask for a named ocntainer?

TabAtkins: yes, I want to think about those two together

<TabAtkins> fantasai: so we already have a resolution to add position-container

<TabAtkins> fantasai: that lets you change CB explicitly

<TabAtkins> TabAtkins: it's a little funky

<TabAtkins> fantasai: it sounds like we need that too

<TabAtkins> fantasai: you probably want a function, not a keyword, so you can pass parameters, like in/out of scrollers

<TabAtkins> TabAtkins: i want to do that for named anchor too, so it should just be a bag of keywords

<TabAtkins> fantasai: so it sounds like we're not addressing this issue in the way it's request, but there are several features that will address the use-case which we want to add

<TabAtkins> fantasai: so closing this as no change for now, investigate keywords/fucntions for referencing container scrollport vs scrollable area of container, and edit in the work for position-container

TabAtkins: We were talking about narrowing the CB. This is about expanding the CB. maybe address by same property.

<TabAtkins> (re: position-container)

ACTION: Tab and fantasai to reread these minutes and come up with a proposal

PROPOSED: Not allowing to refer to CB by anchor name

RESOLUTION: Not allowing to refer to CB by anchor name. We'll address use cases by other means (see minutes for ideas).

[css-anchor-position] Default alignment in center track.

<TabAtkins> fantasai: i think we got the default alginment wrong for the center track

<TabAtkins> fantasai: you can be in the center track, or span two, or span all three

<TabAtkins> fantasai: with all three, you want anchor-center by default so you're connected to the anchor

<TabAtkins> fantasai: but when you're just in the center track, anchor-center tries to put you centered on the anchor even if you specify an inset

<TabAtkins> fantasai: if you are using an inset, tho, usually that means you're compensating for something

<TabAtkins> fantasai:

<TabAtkins> fantasai: so i think it makes more sense to actually center when we're in just the center track

<TabAtkins> fantasai: kizu posted an example where using center looks weird with the insets, but i think that's actually another bug in chrome, where anchor-center isn't paying attention to the insets properly

This makes a difference if the author applies asymmetric insets, e.g. given a 100px anchor, suppose there's a 10px inset on the right. Should the item be centered against the entire anchor, or against the inset area?

<kizu> w3c/csswg-drafts#12020

<TabAtkins> kizu: i think i prefer to account for inset-area more

<TabAtkins> kizu: if you're compensating for the dimensions of something, we should honor that

<TabAtkins> fantasai: [example time]

<TabAtkins> fantasai: anchor element, with two bits, a main and a extra bit on the right

<TabAtkins> fantasai: i want my abspos to be below the anchor

<TabAtkins> fantasai: i want to compensate for the right bit, i'm not centering on that

<TabAtkins> fantasai: so use some `right: 10px` to shrink my area to match excluding the right bit of the anchor

<TabAtkins> fantasai: so now my IMCB is a little smaller, centered on the "main" bit of the anchor that I want

<TabAtkins> fantasai: i think it should center in that remaining space

<TabAtkins> fantasai: current spec says to use anchor-center

<TabAtkins> fantasai: which'll ignore the insets, it's caring about the anchor itself not the IMCB

<TabAtkins> fantasai: so I think if the author is explicitly using an inset we should pay attention to that. default shoudl be center, not anchor-center

sounds reasonable

TabAtkins: In the overflow case, where abspos is larger than the IMCB.

TabAtkins: you're saying that it's a chrome bug?

fantasai: Yeah, it'll center against the anchor box, ignoring the insets

fantasai: and I think it should honor the insets

<TabAtkins> (in other words, it should decenter when it's wide enough to hit one edge of the IMCB)

TabAtkins: I don't think I have a strong opinion. Ian, do you have any compat concerns?

iank_: probably compat wise is fine, early enough

iank_: people are usually using top/bottom, not center

astearns: Roman, sounds ok?

TabAtkins: we're basically showing off his example

PROPOSED: Default alignment in the center track (single track), default alignment is 'center' not 'anchor-center'.

RESOLUTION: Default alignment in the center track (single track), default alignment is 'center' not 'anchor-center'.

[css-position][css-anchor-position][css-align] anchor-center and overflowing the inset-modified containing block

<TabAtkins> fantasai: when you have an anchor-center alignment, and you're using insets, the insets reduce the space you have available to you.

<TabAtkins> fantasai: normally you'd align inside that reduced rectangle and overflow when you're too big

<TabAtkins> fantasai: we have rules now that say, by default, you can overflow your IMCB until you overflow your original CB

<TabAtkins> fantasai: anchor-center has the behavior that you can overflow the IMCB even when it's smaller than the IMCB

<TabAtkins> fantasai: [drawing example on the whiteboard]

<TabAtkins> fantasai: i have a big CB. The anchor is small and near the edge.

<TabAtkins> fantasai: on my abpos, I set `inset: 25px` (which is further than the anchor's distance from the CB edge)

<TabAtkins> fantasai: with left/right/center alignment, it's aligned inside the IMCB

<TabAtkins> fantasai: but anchor-center's desired alignment is centered right on the anchor. But the anchor is in the no-go zone (outside the IMCB)

<TabAtkins> fantasai: chrome positions the abspos outside the IMCB (even tho it could fit in there) becuase it asks to be on the anchor

<TabAtkins> fantasai: I'm arguing the author gave us insets, they're asking to stay inside this region. so we should honor that.

<TabAtkins> fantasai: anchor-center should be as close as it *can* be to the ideal position, but should stay in the IMCB until it actually overflows.

<TabAtkins> iank_: even if it's overflowing - that gets complex but we can push it to the side temporarily

TabAtkins: shift off of center but stay as close as you can is what happens if abspos is big enough to overflow CB, it will break center alignment to stay within CB but stay close enough

TabAtkins: our impl doens't do that for the IMCB, just the CB

TabAtkins: I don't recall if this was intentional or not

iank_: My initial recollection was that prioritizing anchoring, centering on the anchor, was desirable until you hit the original CB

iank_: so that's I interpreted the note in the spec

iank_: I'm fine with changing this, but I worry that we might get... people might be setting insets to reduce available space, for example

iank_: that's a side-effect that happens here

iank_: so I worry we might get some bug reports

iank_: "not actually on my anchor"

iank_: I'm not sure

kizu: I would prefer to stay in the IMCB as long as possible

kizu: basically I agree with Elika

iank_: if we go with that, what happens when the anchored element is larger than the IMCB

iank_: It'll stay locked to one side if IMCB

TabAtkins: I think it should try to grow towards centering on the anchor

iank_: My concern with that is that it creates a jump

iank_: typically want to be continuous

TabAtkins, fantasai: no jump

TabAtkins: as it grows it says as close as it can be to anchor while in the IMCB

TabAtkins: as growing past IMCB, keeps growing in the direction that puts closer to anchor-center ideal

TabAtkins: If as wide as CB, fills it.

TabAtkins: if wider, grows in direction towards anchor

TabAtkins: once it hits the edge, then starts growing towards end side

[Tab draws this]

iank_: So potentially 3 direction changes that could occur

fantasai: I believe this is what I hav implemented in webkit

astearns: compat concerns?

iank_: Not particularly

iank_: I can try behind a flag and see what happens

<TabAtkins> (actually there's four potential direction changes. it might reach its ideal position before it touches the original CB edge

<TabAtkins> )

iank_: I think changing center thing is more

iank_: but the tests will be tricky because of the 3 direction changes that can occur

iank_: But I think the spec does need to be clarified

TabAtkins: Happy to get that clarified

PROPOSED: anchor-center alignment is constrained by IMCB, similar to other alignments

astearns: Further comments or questions?

astearns: Any objections?

RESOLUTION: anchor-center alignment is constrained by IMCB, similar to other alignments

Group Photo

<TabAtkins> Hoto