Cascading Style Sheets (CSS) Working Group Teleconference

Meeting minutes

<TabAtkins> fantasai: some constraints. a circle shoudl shadow a circle, a square shoudl shadow a square

<TabAtkins> fantasai: and third, there's continuity between the two

<TabAtkins> fantasai: after that it's just, what looks good

https://people.igalia.com/obrufau/testcases/shadow-radius/

<TabAtkins> fantasai: oriol made a pile of test cases

<TabAtkins> fantasai: as long as your new formula looks at least as good as what else we've tried, i'm happy to change the spec

<TabAtkins> fantasai: but yeah, a box with sligihtly rounded corners should continue to look like slightly rounded

<TabAtkins> fantasai: so my suggestion is to take the test case page, add your formula to it, and if it looks good we can resolve on it

<TabAtkins> astearns: you opened with "no reasoning beyond it looks good" and that is indeed why we resolve don the current

<TabAtkins> astearns: so applying your algo and comparing to the testcase page is probably the way to go

<TabAtkins> noamr: okay, that explains the reasoning

<TabAtkins> astearns: it took us a while to get to this, and if you ahve a better algo, i'm all for it

<TabAtkins> noamr: yeah, i think i do, and it also looks good with the various corner shape

noamr: I have some good tests for weird shapes internally

fantasai_: It's fine as long as squares are squares and circles are circles and in between is in between in a nice-looking way

oriol: Here's a testcase, I'm testing in Canary

oriol: I would expect the shadow and top/bottom be (?) so I don't think I understand what you are proposing

fantasai: Send a patch to Oriol so we can look at the testcases

fantasai: Then we can look into it

Selectors

[css-selectors-4] CSS reflection of HTML parsing state

<TabAtkins> noamr: this is part of making navigation smoother and more declarative, rather than with manual JS

<TabAtkins> noamr: specifically, streaming navigation and same-doc navigation

<TabAtkins> noamr: part of that is desire to expose better states of the parser

<TabAtkins> noamr: in this case, it's about elements that are opened but not yet done parsing

<TabAtkins> noamr: while you're streaming html, you might open an <article> with a lot of text, it's starting to display but there's still content streaming in

<TabAtkins> noamr: some issues in the past with wanting an element to only appear when it's done, or have some indication

<TabAtkins> noamr: this is a very specific thing in the html parser spec

<TabAtkins> noamr: so the idea's pretty simple, a pseudo-class for whether an element is still open

<Zakim> fantasai, you wanted to ask if this should be distict from whether stuff is loaded

<TabAtkins> fantasai: are the use-cases different from those for querying an elemetn is loaded?

<TabAtkins> noamr: like an image?

<TabAtkins> fantasai: any element, you want parsed and all its resources loaded

<TabAtkins> fantasai: do you want a query distinct from that? parsed and not yet loaded?

<TabAtkins> noamr: a lot of things can be parsed and dont' have laoded resources

<TabAtkins> fantasai: yeah, those'll be done loading immediately

<TabAtkins> fantasai: but for something that has loaded stuff, do you need to distinguish?

<TabAtkins> noamr: unsure. it's a level of granularity down. don't mind starting from something a little more general like :loaded

<TabAtkins> noamr: and then taking it down if needed

<TabAtkins> noamr: if you think aobut containers, or things parsed in a chunked way, often the sub resources arne't loaded, lots of child elements

<TabAtkins> noamr: does "loaded" mean all the hcildren are loaded?

<TabAtkins> fantasai: is that what you want?

<TabAtkins> fantasai: specifically, what's the use-case you're trying to solve

<TabAtkins> noamr: people want to control their progressive loading experience better. articles coming in, but don't want it to show while it's mid-loading

<TabAtkins> noamr: want to either indicate it's loading, or make it invisible until it's loaded

<TabAtkins> astearns: looking thru web components issue, i don't see any discussion about the current :loaded trigger we have

<TabAtkins> astearns: i think it woudl be good to see if our existing :loaded selector woudl be sufficient

<TabAtkins> fantasai: so q is, rather than using a new selector, is it good to reuse the existing selector?

<TabAtkins> fantasai: if you haven't thought about this yet, coudl be worth thinking about

<TabAtkins> fantasai: so do users *want* to distinguish between parsed and loaded?

<TabAtkins> emilio: to impl this, you need add a [??] notification that elements have loaded, which some elements alreayd have

<ydaniv> this one is somewhat related, w3c/csswg-drafts#8175

<TabAtkins> emilio: when previously discussed, i think there were perf constraints with doing this for all elements

<TabAtkins> emilio: there's a similar thing with... like having this pseudo-class - presumably if element is empty this'll never apply, only while getting chidlren

<TabAtkins> emilio: i'm a bit concerned about the number of style changes it adds to page loads

<TabAtkins> emilio: like :has(:parsing) suddenly invalidates constantly

<TabAtkins> emilio: my udnerstanding is in the past, blink folks objected to the more general idea here

<TabAtkins> emilio: in the html discussions

<TabAtkins> noamr: that was a JS thing, this is a style thing

<TabAtkins> emilio: at least for us, the "children are done" thing is an extra operation the parser send to the dom

<TabAtkins> emilio: i think rn we only use that for select and textarea, maybe two or three more

<TabAtkins> noamr: from chromium perspective, we do that- it's expensive, but we can do it based on existing selectors

<TabAtkins> emilio: there could be a stylesheet loading in flight, don't think you can do it conditionally

<TabAtkins> emilio: just saying, this has been dsicussed in the past. doesn't necessarily block, but would be good to have more feedback

<TabAtkins> emilio: but my udnerstanding is our parser folks wouldn't be very happy with this

<TabAtkins> noamr: i'll check, i have more parser knowledge than i did a year ago, not too concerned

<TabAtkins> noamr: when we added blocking for link rel=expect, similar thing

<TabAtkins> emilio: yeah, that's conditional tho

<TabAtkins> emilio: something that might be interesting is restricting this to elements the page cares about

<TabAtkins> emilio: so that might be good to investigate. you usually care about just one or two elements, not all sub-children

<TabAtkins> emilio: just like a main article

<TabAtkins> emilio: would be good to get some hint from the page about what elemens i care about

<emilio> TabAtkins: was going to suggest exactly that

<emilio> ... it's not a state we care about for ~all elements

<emilio> ... so maybe we can opt in at the markup level

<emilio> ... with an attribute or so, which would opt into the pseudo class

<emilio> ... that'd make me happier with reusing :loading/:loading

<emilio> ... usually that's a thing that applies more to images / videos

<emilio> ... but if it's just a handful of articles you have marked or so it seems fine

<TabAtkins> github-bot, take up w3c/csswg-drafts#12579

[css-selectors-4] CSS reflection of "patching"

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

<TabAtkins> noamr: anothe rintro topic

<TabAtkins> noamr: working with the whatwg on a new ability we're calling "patching"

<TabAtkins> noamr: letting you stream content into an element while or after it's loaded

<TabAtkins> noamr: letting you pull in some html and direct it into an element. in JS or declaratively

<TabAtkins> noamr: like HTML with a <select> on top, the content is loaded dynamically

<TabAtkins> noamr: the options can load in later via a <template>

<TabAtkins> noamr: or a <script> it's bing discussed

<TabAtkins> noamr: and some indicator that the contents go into an existing element, via an ID or something

<TabAtkins> noamr: people obvs do this in JS a lot today, React server-side rendering

<TabAtkins> noamr: we also want to reflect this in style, React has a spinner

<TabAtkins> noamr: parts that will load later on, you want to indicate in rendering somehow

<TabAtkins> noamr: so this is opted in, a patchable element will have a special attribute

<TabAtkins> noamr: and when something is patching it's clear, not all the elements on the page

<TabAtkins> noamr: so the use-case style-wise is a loading indicator

<TabAtkins> noamr: graying out an element, enabling a spinner, something like that

<TabAtkins> noamr: maybe could also tie into loading/loaded

<TabAtkins> noamr: not wanting to reoslve, just talking about ti

<TabAtkins> astearns: have some questions

<TabAtkins> astearns: your example has bare text for the laoding state

<TabAtkins> astearns: that i assume that text will be styled, or can have elements that will be repalced

<TabAtkins> astearns: so you alraedy have a way of styling osme loading indicators

<TabAtkins> astearns: so if we already have a way of - the template's not applied yet. what's the use-case for distinguishing between "tempalte's not applied" and "template has been applied but still loading"

<TabAtkins> noamr: i'd say similar to indicating any timeline in the start or middle. pending, loading, or done

<TabAtkins> astearns: I'd like to see some more fleshed-out examples of what someone might want to do from style for these pending and patching states

<TabAtkins> astearns: not against it, just not sure it's completely motivated

<TabAtkins> emilio: for imperative patching, "pending" doesn't exist, yeah?

<TabAtkins> noamr: right

<TabAtkins> emilio: is there a use for distinguishing between pending and patching?

<TabAtkins> noamr: just more convenience, can check if you have a loading indicator

<TabAtkins> emilio: not sure i udnerstand

<TabAtkins> emilio: just not sure when you'd want to dsitinguish between "patch not applied" and "patch has just begun applying"

<TabAtkins> noamr: before it's applied, you want to show the placeholder content; different thatn partially streamed content

<TabAtkins> emilio: okay, would like to see what author use-cases would benefit

<TabAtkins> noamr: it's not novel here, frameworks do it. Suspense library exposes this

<TabAtkins> astearns: i could see some better skeleton loading, where as things are pending you get a skeleton, as they patch in some skeleton remains while it happens...

<TabAtkins> noamr: i can make more demos

<TabAtkins> astearns: and some motivation for why it's in css, rather than just relying on js

<TabAtkins> TabAtkins: part of the feature is a declarative version, where you leave open your html response and later drop in a <template>. no js involved at all

<TabAtkins> noamr: for perf reasons and bug reasons, the direction is to keep things as declarative as possible

<TabAtkins> noamr: similar to event triggers, good to know ahead of time that an event will trigger something

<TabAtkins> ydaniv: i wanna stress what noam is trying to do and giv emore emphasis to this need

<TabAtkins> ydaniv: the web looks now like ti's very flakey, comapred to native apps

<TabAtkins> ydaniv: when people try to build apps that load in async and want it robust

<TabAtkins> ydaniv: so the time we're talking about is before JS ran, the initial server response is important to get right and look right

shapes

<TabAtkins> github-bot, take up w3c/csswg-drafts#11623

[css-borders-4] corner-shape initial value ("round") is strange in some cases (e.g. bevel)

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

<TabAtkins> noamr: this was originally aobut confusion with "round" being initial value for corner shapes

<TabAtkins> noamr: but we resolved on that. the resolution led us to have a shorthand that includes both border-radius and corner-shape

<TabAtkins> noamr: which is supposedly more coherent to read, becuase it doesn't default to round

<TabAtkins> noamr: you specify the corner shape, then the radiuses

<noamr> https://github.com/web-platform-tests/wpt/blob/9a533af8ca6f850effb6df5d6ce7bfaacecb971d/css/css-borders/corner-shape/corners-valid.html

<TabAtkins> noamr: i impld behind a flag in chrome

<TabAtkins> noamr: there were a couple things to reoslve on. do we like this?

<TabAtkins> noamr: and whether it should be 'corner' or 'corners'

<TabAtkins> noamr: so the syntax is, you always need a shape and one or two radiuses

<TabAtkins> noamr: you can have 1-4 repetitions, slash-separated

<TabAtkins> noamr: standard corner copying rule

<TabAtkins> normal means radius 0

<SebastianZ> +1 on the suggested syntax

<TabAtkins> lea: why do we need a shorthand that sets everything? why is that desirable? why not us e the longhand in this case?

<TabAtkins> lea: these can get confusing to read, like border-radius with all of its values. like border shorthands can't do different borders on each side

<TabAtkins> lea: you use longhands if you try to do everything

<TabAtkins> lea: shorthands that try to do everything get confusing, even people here probably make mistakes

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

<TabAtkins> TabAtkins: I'm not sure I udnerstand what's confusing here...

<astearns> https://github.com/web-platform-tests/wpt/blob/9a533af8ca6f850effb6df5d6ce7bfaacecb971d/css/css-borders/corner-shape/corners-valid.html

<TabAtkins> lea: like, line 15, do we want to encourage this?

<noamr> notch 10px / squircle 30% 10px / 1rem bevel / 2px round

<lea> notch 10px / squircle 30% 10px / 1rem bevel / 2px round", "10px notch / 30% 10px squircle / 1rem bevel / 2px round

<lea> corners: normal / superellipse(-0.5) 30% 10px / 10px 1rem notch", "normal / 30% 10px superellipse(-0.5) / 10px 1rem notch;

<TabAtkins> fantasai: i pasted the border-radius syntax into IRC. want to emphasize that this pattern is inconsistent with that one

<astearns> lea note that there are two string values from the lines you pasted

<TabAtkins> fantasai: border-radius takes the values for every corner in sequence, 1-4, then the slash doesn't separate the sides, but to seaprate x/y coords.

<TabAtkins> fantasai: that allows you to specify one value and have it repeated up to 4 times, and can do it independently in x/y

<TabAtkins> fantasai: if we follow that pattern in the corners shorthand, the corner-shape values woudlnt' be split up by slashes

<SebastianZ> reverting my +1 :)

<TabAtkins> fantasai: slash only disambiguates x/y in border-radius

<TabAtkins> fantasai: most time, people just want to say the shape once and then give the border radiuses

<TabAtkins> fantasai: not repeat the corner just because radius is changing

<TabAtkins> fantasai: following the pattern of border-radius would make this easier

corners: <'corner-shape'> || <'border-radius'>

<TabAtkins> fantasai: i think that would be pretty straightforward and reduce repetition

<TabAtkins> noamr: then you can't have different corner shapes

<TabAtkins> fantasai: you can, corner-shape takes four values

<TabAtkins> line 15 would be: notch squricle bevel round 10px 30% 10px 1rem 2px / 0 10px 0 0

<TabAtkins> line 15 would be: notch squricle bevel round 10px 30% 10px 1rem 2px / 10px 10px 1rem 2px

<TabAtkins> kbabbitt: I think it was mentioned that the shapes were a required part, our usual pattern is that values not specified are inferred as defautls

<TabAtkins> kbabbitt: i think if we take elika's suggestion that's the behavior that would fall out of it

<TabAtkins> noamr: that wouldn't fix the issue this was posted for, then

<TabAtkins> noamr: the issue is that people were confused "round" is the default

<TabAtkins> noamr: with a round default, people would still be confused

<TabAtkins> kbabbitt: so it's justa bout requiring explicitness to avoid confusion?

<TabAtkins> noamr: that, plus ergonomics for putting them together

<TabAtkins> SebastianZ: elika's syntax is what jsnkuhn suggested

<TabAtkins> SebastianZ: would we really want to just let the shape be defined there? or should we alway srequire radius as well

<TabAtkins> noamr: if radius goes to zero the shape doesn't do anything

<TabAtkins> fantasai: no, you can make them both optional, it's fine

<TabAtkins> fantasai: author can be doing more specific things later, just relying on the reset behavior. i do this with borders a lot. no reason not to make it optional

<TabAtkins> lea: yeah, fantasai's point about slashes working different is great. we shoudl be consistent

<TabAtkins> lea: that said, i'm not sure expanded border-radius was godo i nthe first place

<TabAtkins> lea: if someone want to set all corners to same value, we should ahve a propery that does

<TabAtkins> TabAtkins: you can, `corners: 5px round`

TabAtkins: you can just say 'corners: round 10px'

<TabAtkins> lea: i'm not sure we *want* to allow the shorthand to set everything

<TabAtkins> lea: shorthands are about reduction of knowledge. a microsyntax makes things harder

<romain> +1

<TabAtkins> lea: experience shows authors don't use shorthands above a certain level of complexity

<TabAtkins> lea: I find it's pretty low, too. authors don't even use background shorthand fully.

<TabAtkins> lea: if we want people to set top-left corner shape together with its size, we can have a property for that

<TabAtkins> lea: or block-start corners, etc

<TabAtkins> lea: I dont' think we should stuff everything into a complex shorthand

<TabAtkins> florian: I kinda agree people will mostly use shorthands for simple things

<TabAtkins> florian: but with border-radius you already have the options, following the pattern is fine

<TabAtkins> florian: you'll always have the longhands

<TabAtkins> florian: but we already have a few reasonable syntaxes, and it's consistent with border-radius

<TabAtkins> florian: not a fan of border-radius, but would like to keep it going.

<TabAtkins> florian: also, earlier you said people found it confusing the default is round, is that because they didn't realize that with 0 it's square anyway?

<TabAtkins> noamr: part was just trying to use corner-shape for a bevel, and saying "my corner is round just because I give it a radius"...

<TabAtkins> noamr: round being the default is more historical than intentional

<TabAtkins> noamr: it's also slightly more convenient feature-detection wise to set 'corners', can use border-radius by itself for a round version then 'corners' for a better one

TabAtkins: I don't think we need to justify having a shorthand

<TabAtkins> SebastianZ: their argument was, when you don't apply border-radius, the shape is square

<TabAtkins> SebastianZ: so an initial "round" value was confusing

<TabAtkins> fantasai: I don't think... there are cases in shorthands where we default to something other than initial value, but only with very good reason, because other values are implying a different value

<TabAtkins> fantasai: not the case here, if you have radiuses, round is the right thing to default to

<TabAtkins> fantasai: because if border-radius creates rounded, but 'corners' defaults to bevel, that's confusing

<TabAtkins> fantasai: the previous shorthand syntax proposal required you to repeat your corner shape on each corner, if you want different radiuses

<TabAtkins> fantasai: but if we switch to the one that matches border-radisu, you don't have to do that

<TabAtkins> fantasai: that's why we designed border-radius the way we did

<TabAtkins> SebastianZ: Lea already brought up a good point. I think in addition to corners, we should have shorthand for the different corners. we have that for corner-shape and border-radius

<TabAtkins> fantasai: agree

<TabAtkins> noamr: just another 16 properties (corner + sides * logical)

<TabAtkins> florian: do we care about the memory cost of all these shorthands?

<TabAtkins> emilio: long hands matter, shorthands not as much

TabAtkins: I agree that complicated shorthand sare bad, but this is not a complicated shorthand itself,

TabAtkins: It just invokes existing shorthands by combining them with ||

TabAtkins: This is the simplest thing we can do

TabAtkins: Just because longhands are complicated ...

TabAtkins: Having more limited shorthand is not good

TabAtkins: We only skip the ability to represent values in a shorthand if it's really untenable

<TabAtkins> lea: it's not a design goal to expose the complexity of all long hands. borders all allow setting individual values per corner

<TabAtkins> lea: but we don't allow setting everything in the shorthand

TabAtkins: Agree, but syntax for 'border' shorthand intentionally doesn't put all 4 things together

lea: What we're doing here is very similar

lea: it's as if we were designing `border` today and trying to make it set separate color, width, style values for each side

<TabAtkins> fantasai: I agree with Tab

<TabAtkins> fantasai: if we dont' have a compelling reason to disable the ability to represent all the longhands, we try to make it possible

<TabAtkins> fantasai: and this is a case where if you want to do the simple things, it is very simple. it's *possible* to do the complex things.

<kbabbitt> +1

<TabAtkins> fantasai: it's fine if 90% of the time you just use the simple version, that's what shorthands are for

<TabAtkins> fantasai: doens't mean we should blocka syntax that allows all the values

PROPOSED: corners: <'corner-shape'> || <'border-radius'>

<TabAtkins> astearns: can we resolve to use the new proposed syntax?

<TabAtkins> astearns: any more discussion about the syntax? if we have the shorthand at all, sounds like this should be the syntax.

<florian> +1

<TabAtkins> astearns: objections?

RESOLUTION: corners: <'corner-shape'> || <'border-radius'>

PROPOSED: Add corners-* shorthands as longhands of corners

<TabAtkins> astearns: now, should we add shorthands for all the corner variations, to match border-radius

<TabAtkins> kbabbitt: not an objection, just clarifying request

<TabAtkins> kbabbitt: sounds like a tuple for each corner

RESOLUTION: Add corners-* shorthands as longhands of corners, parallel to border-*-radius/corner-*-shape

<Zakim> SebastianZ, you wanted to comment on naming the shorthand(s)

<TabAtkins> SebastianZ: I had a pragmatic reason for renaming to 'corner' rather rthan 'corners'

<TabAtkins> SebastianZ: tool completion is usually alphabetic

<astearns> we’re modeling after border-radius, not border-radii…

<TabAtkins> SebastianZ: i think shorthands will be used more than longhands, but 'corners' sorts after 'corner-'

<TabAtkins> lea: we don't usually design around tooling, tooling can change more easily than css

<TabAtkins> lea: that said, the one reason I can think of for naming it corner is it follows the prefixing practice

<TabAtkins> lea: but also, seeing "corner: ..." in a stylesheet looks a little werid

<TabAtkins> lea: there's some precedent, "columns" vs "column-width"

<TabAtkins> noamr: why I suggested corners before is, unlike border/background, you don't have a concept of "a" corner. You dont' say "what corner does it have", you say "what corners does it have". unlike "what border does it have"

<TabAtkins> noamr: so it just works better in English I think

<TabAtkins> florian: for short shorthand, 'corners' is okay either way. for the mid shorthands, the resolution says 'corners-top-left', sounds bad. want to go singular for that

PROPOSED: s/corners-*/corner-*/ on the shorthand

PROPOSED: s/corners-*/corner-*/ on the long shorthands

<Zakim> fantasai, you wanted to ask wrt the shorthands

<TabAtkins> florian: in some cases singular is obvious, in some it's arguable, but it's definitely not correct to be plural everywhere

astearns: border-radius, not border-radii

TabAtkins: People don't talk about border-radiuses of the box

fantasai: Should we resolve on the long shorthand?

fantasai: since they're singular

florian: We well have the mid shorthands, for two corners each

<TabAtkins> SebastianZ: we should be consistent across the shorthands

SebastianZ: We should be consistent across the shorthands, regarding the naming

TabAtkins: do you mean all of them, or all of the mid shorthands

<TabAtkins> astearns: all of them

<kbabbitt> +1 to singular in all the shorthands

<TabAtkins> noamr: i'm convinced consistency is more important than English practice here

<TabAtkins> astearns: sound slike consensus for 'corner' in all cases

<TabAtkins> astearns: objections?

RESOLUTION: Use 'corner' and 'corner-*' for all

I was ambivalent, but I'm convinced by the "one vs two vs four" of shorthand

<TabAtkins> lea: the tag principle does stress consistency, but says other things can take precedence

<TabAtkins> fantasai: I was ambivalent until we started talking about the longer shorthands

<TabAtkins> fantasai: corners-top-left only sets one corner, but corners-top is setting two

<TabAtkins> fantasai: corner-top-left and corners-top is confusing

<Zakim> fantasai, you wanted to respond to lea

<TabAtkins> fantasai: both singular or both plural is fine. but corner-top-left is just kinda weird anyway

<TabAtkins> lea: have we considered having a singular when setting one corner and a plural when setting multiple?

<TabAtkins> astearns: yes, we just discussed that. I agree it's too confusing

<TabAtkins> TabAtkins: agreed

<TabAtkins> ydaniv: some people look at it like 'corners' is a namespace

<TabAtkins> ydaniv: corners-top-left is like corners.topLeft

<fantasai> s/corner-to-left is just kinda weird anyway/but corner-top-left and corners-top, where one is plural and the other not, is going to be confusing for authors/

<TabAtkins> ydaniv: so it's not that weird to some people

<TabAtkins> florian: also note that a large fraction of the population doens't have native plurals

<TabAtkins> florian: if you have to already intuit English grammar when programming, not impossible, but one more thing to remember

<fantasai> s/confusing for authors/confusing for authors, and corners-top-left where we're pluralizing a singular is also weird/

<fantasai> +1 wrt i18n

<TabAtkins> astearns: cutting bikeshedding short. if someone thinks having two words for the shorthands is something to do, we can discuss it later

<TabAtkins> astearns: break time

<TabAtkins> github-bot, end topic

Reconsider <An+B># for :heading

TabAtkins: some context, what whatwg was doing regarding heading level
… this issue is about design of functional form of heading()
… per spec it takes a comma separated list of An+B
… Anne wanted to simplify this
… wanted An+B
… I pushed back and suggested to do comma separated integers
… some discussion back and forth
… Anne is pushing back on comma-separated lists for some reason
… my suggestion is to do comma separated integers

kbabbitt: wanted more details on the discussion
… it allows now 6 levels in HTML
… is this allowing more levels? or disassocating from HTML?

TabAtkins: both
… use generic tag and have it not rely on tag name
… but also to allow more levels, not arbitrary number of levels

SebastianZ: should it be restricted to just 9? or more?

TabAtkins: the pseudo class should allow you any number

<Zakim> fantasai, you wanted to respond

fantasai: we can allow any number
… we aren't going to limit it
… syntax is optimized for it

florian: I have a hard time for allowing these patterns
… would rather have comma separated to be simpler

noamr: there is precedence for comma separated
… when you have list items, you don't know how many are going to be, and relationship is linear

SebastianZ: quick idea, maybe introduce keywords?

SebastianZ: e.g. "1 to 6"

oriol: no strong opinion

<TabAtkins> If you want *all* headings, that's `:heading`. if you want several but not all, `:heading(1, 2, 3, 4, 5)` isn't bad to write

oriol: however, if we go with list the stack should be using logical OR or AND

TabAtkins: Not possible to have something be both heading 1 and heading 2,

TabAtkins: so only one possible interpretation

florian: I think we should go with list of integers, just to clarify

SebastianZ: advocate for using just numbers, but allow patterns?

florian: not object but seems unnecessary

fantasai: Agree with florian, we shouldn't bother

<kbabbitt> +1 to florian

<ydaniv> +1 to florian

<TabAtkins> +1

PROPOSED: use comma separated integers

astearns: other comments?

lea: the An+B case is one of the comlex cases, something that also come with nth-child case
… and authors have to write all sorts of weird things
… so instead of just commas is to allow ranges from a to b

TabAtkins: argument against is because the set is finite then allow just specifying it

lea: in this case yes, because it's finite
… in other cases ranges are more desirable
… then we can also fix it here and fix all

fantasai: don't disagree, but think this is not the place to fix it

lea: it's already limited to integers

<SebastianZ> lea See w3c/csswg-drafts#4140

<kizu> To crosslink stuff, SebastianZ's issue about ranges: w3c/csswg-drafts#4140

lea: I agree we should simplify, but think we also need ranges

<TabAtkins> fantasai: people don't do repeating patterns on hierarchical section levels

astearns: we're not going to discuss ranges for this issue
… was brought up before, but not for this one

florian: I think choice should be either list of integers, or straight to An+B as a list
… I think there's one impl. in ladybird?
… if we hdn't specced or implemented anything then I'd to list of integers
… given that it's already implemmented in a few places, I'm ok with list of An+Bs

astearns: we have 2 options? currently has a list of An+B, we can leave like that or change to list of integers

emilio: we can change have way
… I don't think having a list of integers is the only thing we could do

astearns: hearing slight preference to list of integers

emilio: might save a couple of bytes

SebastianZ: once we discuss the issue about ranges and come to a solution on that
… I would apply that to all the other places

florian: but that remains open regardless
… we're still open to doing that

<astearns> 1) list of An+B 2) list of integers

<TabAtkins> 2

astearns: let's draw a poll

2, but also ok with 1

<kbabbitt> 2

<lea> 2

<andruud> 2

<astearns> no preference

<emilio> weak preference for 1, also fine with 1

<SebastianZ> No preference

<diekus> 2

<oriol> abstain

<emilio> with 2*

<alisonmaher> No preference

<kizu> 2

<florian> ok either way

proposed resolution: change spec to list of integers

astearns: objections?

RESOLUTION: change spec to list of integers

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

[css-anchor-position][other] Handling popover default styles

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

TabAtkins: quick intro, popovers and dialogs in general have some default styling that centers them
… in both they're positioned elements and uses auto margins to do the centering
… this is not consistent when you need to have anchor pos
… and you should be able to easily use anchor positioning
… it trips authors up
… so fantasai and I tried to find a solution
… we think we have it, adding a new alignment value called dialog, which either centers or acts as "normal"
… this lets you overide default stuff from UA
… only thing is that you have to use a special keyword which is strange

Tab is summarizing w3c/csswg-drafts#10258 (comment)

TabAtkins: use case for it is that it's generic enough for exposing
… had a few objections about this, lea had some
… we discussed this previously
… yesterday iank_ said we could auto coarse margins to 0 if popover uses anchor pos
… I really disagree because it's purely magical and canot be done other way
… it pevernts authors from setting their own margins
… also note that iank_ expresed some concern about compat for changing this
… talked about this internally, there's stuff we could do, perhaps ignore compat for now
… opening for discussion, hoping we can add the alignment value, this is my preference

fantasai: one thing about the margin 0-ing, with alignment don't need to fit content if it's auto
… but with the margin 0-ing won't work

astearns: other comments?

fantasai: a 3rd option would be to recast the way anchor position area works
… instead of setting the alignment value to something magical, to make inset auto to be something magical

TabAtkins: would prefere to minimize magic as much as possible

lea: agree

TabAtkins: we already have some behavior switching, but we already have precedence

Proposed changes to the UA default stylesheet

[popover] { position: fixed; place-self: dialog; /* new */ /* deleted X inset: 0; X width: fit-content; X height: fit-content; X margin: auto; */ border: solid; padding: 0.25em; overflow: auto; color: CanvasText; background-color: Canvas;

}

lea: been a while, we have this conditional branching if you're using anchor pos you have normal, otherwise center

w3c/csswg-drafts#10258 (comment)

lea: it's still a black box
… could we break out some of the magic? e.g. a conditional around whether an element is anchored? Possibly only allowed in margin for now? At least then there is a path for making it more general later, whereas a keyword that encapsulates all the magic has no such path

TabAtkins: I argued against a general form of that
… just using anchor pos for that is interwoven with other features
… doing something so core to layout would be a large distinction on how we do it
… having a specific keyword for specific case it ok here
… a more generic for would make it so complex to where it's possible to use, so may not be worth doing

fantasai: there's too many things that are affected
… don't think there are more use cases
… mostly trying to fix the badly designed defaults, if authors were doing it they wouldn't write this badly

lea: not suggesting we add new deps. there are solutions that involve different synrtax
… this is not part of the UA stylesheets, so ergonomics is part of the concern
… special casing a syntax that could be come more general

lea: means we don't have to maintain this magic keyword forever, we have a path to a more general feature for down the line

<Zakim> fantasai, you wanted to say we should avoid designing something overcomplicated and overgeneral for a very specific problem

lea: it's conceivable that authors or the UA stylesheet will want to branch depending on whether an element is anchored

fantasai: trying to spend the time effort to define a generic syntax
… is not worth doing
… not worth doing now that we need this for compat now
… I don't see us generalizing this
… we have one thing for a very niche problem

lea: in that case, is it possible to restrict this value to the UA stylesheet so we don't have to maintain it forever? It seems of very limited utility to authors

lea: that way later we can swap it in without having to worry about webcompat

fantasai: it's a keyword, if we want it to make it compute to something else later we can

astearns: might be on lea's side here, is there any problem with restricting it to UA sheet
… it's a bit harder to implement but seems it'd be better for authors

fantasai: I think the easiest way is to compute to normal or center depending on whether you're author positioned?
… not sure how easy to implement would that be
… it's not a complicated behavior tho
… its be centered if you're not anchor positioned otherwise normal

lea: there are other cases where we want to not expose certain values to authors and only allow them in the UA stylesheet, e.g. allowing authors to set `overlay: none` without setting overlay in general, so having a way to do this seems useful beyond this

fantasai: which itself behaves differently when anchor positioned

emilio: Lea that's different, because they can set it, it just won't have an effect because it gets by a declaration in the UA !important origin

<TabAtkins> emilio: that's different. authors can set it, it's just overriden by the UA !important rule

emilio: You can set 'overlay: auto', and it'll create a declaration, it just won't have an effect

fantasai: I really think we're spending a lot of time trying to overgeneralize here
… this is just trying to fix a very specific problem
… we're certainly not going to move forward on anchor pos if we can't solve this and we don't get to the other issues

TabAtkins: yeah it might also be useful for authors

astearns: what's the current proposal

TabAtkins: dialog, open to other names

astearns: so proposal is to add a dialog value to alignment properties that computes to normal or center

emilio: computes or behaves as?

astearns: computes does more hiding

perhaps a better name could improve on how weird and overfit this feels

emilio: How many properties are we talking about here?

<lea> +1 astearns

fantasai: align/justify-self and it'd depend on position / position-anchor, and maybe the inset properties

TabAtkins: right we have a breakout on what "using anchor positioning" really means

emilio: I think it would be easier to make it behaves as

emilio: that doesn't add lots of inter-property dependencies that we may have trouble with

emilio: If depends on just one property is easy, six can get tangled

astearns: OK, can we resolve to add a 'dialog' value, name tb bikeshed, behaves as 'normal' or 'center' depending on layout mode

astearns: details TBD

fantasai: and use it for [popover] as described in w3c/csswg-drafts#10258 (comment)

RESOLUTION: Add 'dialog' value for align/justify-self, behaving as normal or center as appropriate, and rewrite [popover] UA styles per w3c/csswg-drafts#10258 (comment)

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

[css-position][css-anchor-position] Splitting Scrollable Containing Blocks

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

fantasai: [whiteboard time]

fantasai: we have several different concepts of containing blocks
… position: fixed is the viewport, outside of the scrollable area
… position: absolute positions relative to the ICB
… for a scroll container we have the ICB behavior
… you can't get the fixed behavior unless you attach it to a wrapper around the scroll container
… when we were discussing anchor pos, and your anchor is towards the bottom
… the bottom of the icb is up there
… we floor it at the anchor which ends up with a containing block rect which is zero-height
… what you want is to create the nine-grid to create the thing to the whole scrollable area
… and we resolved to do that (use a representation of the 'in-flow scrollable area')
… for other scroll containers we don't have the ability to switch to the scrollport itself
… for anchor positioning this is particularly important
… because you want to trigger fallback
… so we need some kind of distinction
… there are other use cases for this outside of anchor pos, it's just a more pressing issue with it because of fallback
… so tab and i discussed syntactic switches, for {scrollport, icb-equivalent-thing, in-flow-scrollable-area}
… in order to allow the author to distinguish this we need new syntax
… we automatically decide on this for anchor pos
… would be nice to allow authors to change it, also we can't for other absposes r/n
… our proposal is to split `position` into three: `position-type: static/relative/sticky/absolute`
… `position-attachment: auto | local | fixed | scroll;` (local is icb, fixed is scrollport, scroll is in-flow-scrollable-area)

<astearns> (all of these details are in the first comment in the issue)

fantasai: `position-container: nearest | furthest | <custom-ident>;`
… `nearest` gets you to nearest positioned element (abspos behavior), farthest is root (except when transformed) (fixedpos behavior)
… `position: absolute` would expand to `absolute auto nearest`
… `auto` behaves as `local` or `scroll` depending on whether you're anchor positioned
… `position: fixed` would expand to `absolute fixed farthest`
… that's the outline of the proposal

<TabAtkins> emilio: I wanted dto double-check some eof the shorthand expansions, but I think it looks reasonable overall

<TabAtkins> emilio: if you have position-attachment:scroll and your CB isn't a scroll container...

<TabAtkins> fantasai: the attachment values only change things for scroll containers. any other element, it does nothing

<TabAtkins> emilio: i'd probably start without the container custom-ident, seems a bit complex

<TabAtkins> fantasai: yeah, that's just from another issue. don't need it in the syntax right this moment

<TabAtkins> emilio: and presumably these are paired..

<TabAtkins> emilio: position-attachment and container are useless unless you specify pos:absolute

<TabAtkins> emilio: but no reason to do them with position:relative

emilio: I find it weird that position:fixed expands to container
… breaks my mental model

<TabAtkins> emilio: my mental model of position-fixed is about the container rather than attachment, but that's because in impl we parent it to a box outside the root scroller

<TabAtkins> emilio: if we impl this proposal we might change internally how we do pos:fixed to match this

<TabAtkins> emilio: in general this makes sense tho

<TabAtkins> emilio: probably want to leave out the custom ident stuff for now

<TabAtkins> SebastianZ: [somewhat missed]

<TabAtkins> emilio: you have the root scroller, it's a box outside of that which is the viewport

<TabAtkins> emilio: we parent a fixpos to that "box"

<TabAtkins> emilio: this changes it to instead attach to the scroller itself

<TabAtkins> emilio: rather than a pretend ancestor

astearns: Couple things
… you've raised the posibility of this isn't implementable because of the shorthandifying

TabAtkins: iank_ says it's not so bad to avoid shorthanding
… but I don't think it addresses the issues we've hit in the past when shorthandifying

TabAtkins: ian wants to not shorthandify, and says that is not so bad

astearns: the other thing is that ian suggested for position container we could have just `auto | <custom-ident>`, but if we don't have the `<custom-ident>` we could leave that right?

fantasai: it's useful to attach to the root regardless

TabAtkins: being able to be at the root without being fixed
… is useful for anchor pos to be in the top layer

emilio: but the top layer doesn't scroll with the document right?

SebastianZ: I think this could also solve changing the sticky position container
… regarding the default position-container is weird, is there an auto?

fantasai: you don't need that. Assuming we can shorthandify then the expansion takes care of selecting the right default
… we could make it auto, but it'd be nice to be avoid automagic where possible

emilio: you don't really need to shorthandify, and you could still not have auto
… you'd omit the default

SebastianZ: re. nearest and farthest I was thinking viewport. For fixed positioned it's the viewport

fantasai: you can get trapped by a transform

SebastianZ: fair

SebastianZ: regarding custom-ident you'd need a separate property for that

fantasai: yeah that'd be nice if we go down that path, and we'd need a separate

SebastianZ: why custom-ident and not dashed-ident?

fantasai: that's what we meant, should be dashed-ident

SebastianZ: finally do we want to extend position shorthand?

fantasai: yeah it should take the combination of all keywords

TabAtkins: assuming that we can't shorthandify for a moment
… we could add an auto value that keys off the position property
… so position would remain as is, but `position-{container,attachment}` would have an auto value
… which would choose the right default

emilio: I thought not shorthandifying would just expand the position syntax

TabAtkins: while I agree having the shorthand would be more ideal, I agree with iank_ that not shorthanding would be not as bad

<TabAtkins> emilio: want to confirm whether fixpos behavior includes the scrollbars gutters

<TabAtkins> emilio: rn we have weird inconsistent beahvior

<TabAtkins> emilio: should be sorted out

<TabAtkins> emilio: assuming mostly what pos:fixed is doing...

<TabAtkins> fantasai: should probably just match position:fixed yeah

<TabAtkins> bramus: issue 8099 is concerned with that

<TabAtkins> bramus: effect of scrollbar-gutter on the viewport

w3c/csswg-drafts#8099

<TabAtkins> emilio: regarding shorthand vs not

<TabAtkins> emilio: imagine we would expand 'position' longhand to just contain these extra values

<TabAtkins> fantasai: they have to cascade and interact

<TabAtkins> TabAtkins: you misunderstand, Emilio proposed putting the entire syntax into 'position'

<TabAtkins> emilio: yeah, I think I kinda prefer that

<TabAtkins> fantasai: so we'd have these "conceptual" longhands

<TabAtkins> emilio: yeah, like display-inside vs outside

<TabAtkins> fantasai: yeah that sounds better than independent properties that cascade badly

<TabAtkins> bramus: also wanted to point to issue 7475

bramus: I also wanted to point to 7475
… flackr filed it to give authors an option to where to pos-fix your elements
… would this solve it?

fantasai: it's a different thing
… but if we fix that it could be part of these properties

fantasai: I'd be ok with proposing the syntax model without the longhands, just all into position for now, then decide if we can/want to split it
… so just the `position` syntax without the longhands

Proposal would be `position: <type> || <attachment> || <container>`

without the longhands possible

astearns: I'd be uncomfortable resolving on it r/n, let's take it back to the issue

lunch

<TabAtkins> github-bot, end topic

Image Animation

[css-images] Disabling image animation

<florian> https://webplatform.design/talks/image-animation

florian: Image animation on the web needs some control

florian: Animated images, there are GIFs, APNG, WebP, etc. Not specific to a format.

florian: These are everywhere and here to stay

florian: Not just Geocities, but people love animated memes and emojis

florian: OSmetimes used for animated icons

florian: Diagrams can be animated, or maybe you have animated backgrounds

florian: In many cases even user-generated content

florian: Typically embedded with <IMG>

florian: However, uncontrollable animations are a WCAG violation

florian: can trigger motion sensitivities, cause attention problems, or generally be annoying

florian: UAs have a pref to turn all animations off, unconditionally, everywhere -- but sometimes you want them

florian: Authors need to accommodate for user needs/preference, but doing that depends on the use of the animation

florian: Disabling animated background vs animated meme vs contentful image, differs

florian: Then there's question of is it new content, old content, user-generated content, etc.

florian: Authors do care: see stack overflow, reddit, polls by Lea, etc.

florian: There are some workarounds, but not perfect

florian: Can do server-side to create set of frames and convert to mp4, but this is expensive

florian: client side extraction into <canvas>, but then only possible same-origin

florian: in any case, these are complicated options

florian: Very simple solution would be 'image-animation: normal | pased | running'

florian: Put it on the root depending on prefers-reduced-motion, and let it inherit

florian: then select the ones you want to enable and flip it to 'running'

florian: "prefers-reduced-motion" isn't "never-animate"

florian: so, e.g. could be running on focus or hover

florian: (but then focusability of images is an issue)

florian: But for images with meaningful content, authors likely want to provie play/pause controls

lea: One idea is to allow images in <video>. This doesn't require any new API surface. Just a video with no audio track.

lea: Allowing images in <video> give syou full playback control, have a JS API to control, can enable looping, disable autoplay, even adjust speed

lea: Designed to be extensible, so will benefit from future extensions

lea: Proposed to WHATWG, initial reactions are promising

lea: But doesn't solve everything because a lot of existing content and infrastructure that uses <IMG>

lea: and also controlling via selectors is not possible

lea: So another idea is what if adding control attributes to <img>

lea: Can have same element as before (<img>), and tailor the UI to images rather than video

lea: But then we have to introduce new API surface, and awkward interface for boolean attributes that is opposite default of <video>

lea: Also can't respond to media queries

lea: or use selectors to control

lea: One idea is very high-level solution, to add a 'controlled' value to image-animation

florian: If we have the CSS property we discussed earlier, and we have images in <video>, and we have <img> + CAS, we are solved

florian: but CAS is specifiction right now

florian: Setting up <img> for controls is also not easy

florian: May or may not fly, so what else?

florian: So 'controlled' is a solution

florian: For background images etc. no effect, but for content <img>, would provide a play/pause controls *if* it's an animatable image

florian: responds to selectors, media queries, can work on older sites and user-generated content

florian: But if down the line we have images with controls, interactions between the two might be odd, and weird layering of things

lea: Another option is to expose lowlevel primitives, so authors can do it

lea: If you want control over playback, use a video

lea: but could also expose low-level primitives like an image::overlay pseudo-element to paint stuff over the image

lea: or img:static to target non-animated images from animated ones

lea: or connect into CSS Animations machinery, e.g. animation triggers

lea: These would be more useful more broadly

lea: We do have general tendency of generalizing, e.g. can play audio in <video>

lea: so unifying image is along these lines

lea: But simple things would not be easy with primitives

lea: and you can mess up author interactions, e.g. forget to put tabindex to make it focusable

lea: would be handled automatically if we had a controls attributes

lea: For CSS images, could have image-frame() to extract frames. But ocntrol over playback is tricky

lea: and e.g. pausing all images, you would need ability to style them all, which is not so simple for e.g. background imgaes

lea: Suppose if we went down the @image path for determining image tweaks, calling it with image(src options-name).

lea: Then you could attach animation controls.

lea: Or maybe we could hook up image animations to animation properties by using an image-animation() function to "name" the animation in animation-name and control it with animation-play-state

lea: But then everything becomes a list, it's maybe a bit awkward.

lea: Anyway, these are the thoughts.

florian: What we are most likely to pursue is what everyone else is interested in

florian: But images in video definitely given response in WHATWG

florian: But we are also considering proposing image-animation property for CSS

florian: Independently of that, whether Cascading Attribute Sheets becomes a thing, might determine the next steps

florian: But anyway, let us know which ideas you're interested in

lea: wrt resolutions, maybe just "we want to solve the problem"...

ydaniv: All of this is awesome. Lots of good ideas.

ydaniv: Currently animated images is a child that nobody wants, because it hurts performance so much

ydaniv: Animated images are very eager. Can cause everything on the page to freeze.

ydaniv: That's one of the biggest issues, so maybe going through the medium direction and somehow make them streamable...

florian: Is the heaviness due to inefficiency of image format and it overhwelms the page or ....?

ydaniv: sometimes ppl make an animated sequence from a video, and then put it into ??

<Zakim> lea, you wanted to react to bramus to reply to ydaniv

lea: A lot of animated images are inserted by users *because* they loop and autoplay. Once websites have control over this, it could remove one of the motivations for using gifs

lea: Unsure if webP is as inefficient as e.g. GIF

ydaniv: Issue about hooking video playback to animations, so allowing for animated images, people would be very happy

SebastianZ: Reporter of the issue related to this is one of the Firebug contributors

SebastianZ: Wrt animations, good idea to allow users to get some control over the animations

SebastianZ: Presented solutions are not necessarily exclusive

SebastianZ: One thing I was missing in the presentation was the idea of having a param for the url() functions to control it

SebastianZ: e.g. to extract one frame from the image

lea: Mdia fragments are about getting a subresource

lea: extracting one frame might be seen as that, but playback control isn't

lea: Also, media frags isn't under charter atm...

emilio: I see a lot less problems with the video approach

emilio: Making that apply to the CSS images is a bit more complicated

emilio: wrt pseudos, e.g. adding ::overlay would be OK if you only do for HTML images, not CSS images

emilio: ...

florian: In theory youc could have longhands for image-animation, but I think it woudl be rare to want to animate e.g. border but not background

emilio: Some precedent for having a property affect both content and style images

emilio: pseudo-element stuffs eems too limited to me

emilio: Controlling email animations would be helpful maybe

florian: the parts we're reasonably confident about are image-animation and <vedo>

florian: everything else, all of them can sort-of solve it, but different tradeoffs

florian: I like tihs one is the easiest

florian: but from layering, maybe it's the worst and other thing is better -- but then not responding ot MQ

florian: full of tradeoffs for the rest, unsure

[missed]

lea: one question is do we design this very simple image-animation property, or do we find some way to hook into CSS animations and make use of all the elaborate playback controls we have for them?

emilio: track of time that's not continueous... feels more exploratory

SebastianZ: Not totally convinced imgae-animation is right, because it's affects all CSS images

florian: Only a problem if you have multiple animations you want to control independently

florian: I'm not convinced, seems theoretical

florian: We could expand into longhands if becomes necessary

florian: if you have multiple images you want to control independently...

emilio: Never got this issue with image-orientation

ydaniv: wrt loading, if we put this in CSS it doesn't affect loading of the images

ydaniv: would be nice to say "load this images, but only load the first frame"

florian: I think this would be possible if you go through the the HTML route

<astearns> fantasai: agree with florian you’re unlikely to want to independently control …

fantasai: if we really need to do that, put parameters into image()

fantasai: HTML only every produces one image per element

astearns: roposed to resolve ot solve this problem

RESOLUTION: Try to solve this problem

astearns: Where should people contribute into?

florian: This is an old issue that discusses the issue, and proposal being discussed is similar to this idea

Process

<TabAtkins> github-bot: end topic

process update

<TabAtkins> florian: short heads up

<TabAtkins> florian: process 2025 went live on Monday

<TabAtkins> florian: not a revolution

<TabAtkins> florian: ther'es a changes section

<TabAtkins> florian: from a WG perspective, Proposed Rec no longer exists

<TabAtkins> florian: criteria for CR -> Rec didn't change

<TabAtkins> florian: there's just no intermediate step

<TabAtkins> florian: PR -> Rec was AC voting, now they'll just vote on the CR trying to go to Rec

<TabAtkins> florian: there's some nuances about going from CRD to Rec, that's allowed as long as it's only editorial changes

<TabAtkins> florian: so that's the only main update

auto publishing

<TabAtkins> ChrisL: most groups at w3c use auto-publishing

<TabAtkins> ChrisL: once they merge a PR it triggers a GitHub action and auto-publishes

<TabAtkins> ChrisL: for the classes of spec that it's allowed

<TabAtkins> ChrisL: we dont' do that, and that's now unusual

<TabAtkins> ChrisL: we also have some embarrassing cases like "spec last updated in 2013"

<TabAtkins> ChrisL: or people taking Flexbox /TR as authorative because it's 7 years out of date

<TabAtkins> ChrisL: so I propose we auto-publish specs in the appropriate classes

<TabAtkins> fantasai: I think we need to do this on a document-by-document basis

<TabAtkins> fantasai: a number of specs in a messy state that shouldn't be auto-pubbed

<TabAtkins> fantasai: possible we want to pause auto-updates while we re-hash and enable later

<TabAtkins> fantasai: as long as we can do that, sounds okay

TabAtkins: could put it into GitHub actions

TabAtkins: file listing which specs are auto-published

<TabAtkins> astearns: we'd only need to do this for specs getting updated, anyway. won't autopub until PR

<TabAtkins> astearns: well, no, not the case, we refactor things sometimes

<TabAtkins> astearns: so better to have a master list

<TabAtkins> ChrisL: yeah we regularly do small wide-ranging editorial changes

<TabAtkins> florian: this seems generally useful, with elika's caveat

<TabAtkins> florian: if we don't have that we'd have to change the way we work and only do work in PRs

<TabAtkins> florian: that would be uncomfortable

<TabAtkins> florian: so without the ability we'd probably have mistakes

<TabAtkins> florian: having a single repo probably means everything that's auto-published gets repubbed every time

<TabAtkins> florian: might be annoying

<TabAtkins> astearns: Chris, is it smart enough?

<TabAtkins> ChrisL: It usually triggers on "Bikeshed file has changed"...

<TabAtkins> fantasai: florian means, because we're a monorepo, doe supdating something else cause Flexbox to repub.

<TabAtkins> TabAtkins: you can tell what paths are changed in a commit, it's doable

<TabAtkins> fantasai: so turning on auto-publishing, with configuration

<TabAtkins> fantasai: and it autopubs if that directory changes, not anything in the repo

<TabAtkins> fantasai: and if we set that up, default them to off with some turned on

<TabAtkins> fantasai: a lot of specs that i dont' want autopub yet, but will have them synced next publication

<TabAtkins> ChrisL: one change if an see, normally when I publish I update the Changes list

<TabAtkins> ChrisL: with auto-publish you don't necessarily do that, you just say "since last CR snapshots" or something

<TabAtkins> ChrisL: rather than specifically since "last publication"

<TabAtkins> astearns: by default that's what will happen, but it would be up to editor discretion to make a new section on significant milestones

<TabAtkins> ChrisL: right, just clarifying I don't expect people to start a new subsection for each pub

<TabAtkins> fantasai: for CRs, I think natural milestone is the snapshot

<TabAtkins> fantasai: for WDs not so much

<TabAtkins> fantasai: but can have editors decide on it

<TabAtkins> fantasai: can have WD snapshots

<TabAtkins> astearns: so this would be turned on for WDs and CRDs?

<TabAtkins> ChrisL: yes.

<TabAtkins> ChrisL: fpwd and crs and rec can't be auto-pubbed anyway

<TabAtkins> astearns: and that's all we've got now

<TabAtkins> ChrisL: I've been talking about other groups and PRs

<TabAtkins> ChrisL: our specs aren't edited like that

<TabAtkins> ChrisL: I don't know if we want to revisit it or not

<TabAtkins> ChrisL: I'd want to see how the tooling can work

<TabAtkins> TabAtkins: I'm confident we don't need to, we can just rely on commits

PROPOSED: Allow individual specs to opt into autopublishing WD or CRD, make sure we don't republish everything anytime one thing changes.

<TabAtkins> ChrisL: okay, don't want to change our work mode then if we dont' need to

<ChrisL> https://github.com/WebAudio/web-midi-api/blob/gh-pages/.github/workflows/auto-publish.yml

<TabAtkins> SebastianZ: what about Notes?

<TabAtkins> fantasai: we can put Notes in there

<TabAtkins> astearns: it would be good to autopub Notes too

<TabAtkins> astearns: objections to the proposed resolution?

RESOLUTION: Allow individual specs to opt into autopublishing WD or CRD or NOTEs, make sure we don't republish everything anytime one thing changes.

<TabAtkins> fantasai: if you're making big changes and think they need review, turn off autopub

<TabAtkins> astearns: we'll get some new processes in place to adapt to this

<TabAtkins> TabAtkins: how easy is it to unpublish?

<TabAtkins> fantasai: if it's still the same day, you can revert and republish

<TabAtkins> ChrisL: as long as it's within the same (GMT) day, they only keep the latest version

explainers workshop

<TabAtkins> fantasai: raise hand if you've written an explainer for a CSS feature

<TabAtkins> fantasai: if all your explainers are in the CSSWG repo

<TabAtkins> fantasai: you can stop

<TabAtkins> fantasai: I fyou have explainers elsewhere, how many?

<bramus> There’s about to be one 😅

<bramus> (see next topic)

<TabAtkins> [answers]

<bkardell> I have a few things that could be considered explainers, maybe 2

<kbabbitt> one of my 2 is in need of significant changes after discussion yesterday

<TabAtkins> fantasai: we should spend the next few minutes moving the explainer into csswg

<TabAtkins> florian: what if the spec didn't end up existing?

<TabAtkins> fantasai: it can still go in the repo

<TabAtkins> TabAtkins: an "unknown spec" folder

<TabAtkins> ydaniv: I complained about this to Tab a few years ago

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

21 August 2025

Attendees