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

MQ3 Rec update

github: https://github.com/w3c/csswg-drafts/issues/6962

florian: Elika suggests we might want an update since it's been a while

florian: We haven't touched it since 2012

florian: Presumably we thought 4 and 5 would be done

florian: Also haven't rebuilt it since then, since it's on the old preprocessor

florian: Some edits went into source, some went into output

florian: I synced them, and deleted the source since nobody uses it anymore

florian: And made a few markup fixes

florian: Also errata. Most are editorial

florian: One was later overturned, but we didn't remove it from errata

florian: One was normative, so I've included it as a candidate correction

florian: I think we're ready to publish.

florian: But if the group agrees I'd rather have it as a proposed correction rather than candidate correction

chris: don't think you can do that

chris: a proposed correction must have the same text as a candidate correction

florian: hm, you might be right, but i think we could do two pubs in a five minute span

chris: true there's no minimum review period

chris: Think it's an abuse of process, but it's not disallowed

astearns: So we could od candidate corr, let the AC know...

florian: Letting the AC know is the *proposed* correction thing

astearns: So you're suggesting do a candidate correction now, and do a proposed correction sometime later?

florian: I propose doing it immediately after since we gain nothing from a delay, but we can wait a bit if necessary

chris: you can do a proposed correction and ask the director and see what happens, but it might take more time

florian: We don't need toa sk the director, these are nonnormative until they're folded in

[missing some process discussion]

TabAtkins: Propose we resolve to publish a Proposed Correction, along with any necessary antecedents?

RESOLUTION: Publish a Proposed Correction for MQ3, along with any necessary antecedents as determined by florian/chris/fantasai

<chris> https://www.w3.org/Guide/transitions?profile=REC&rec=substantive

florian: Maybe a followup, maybe implied

florian: Once this is done we should clear the errata

chris: You automatically start with a new blank errata when3eve ryou publish a doc

input-security considered harmful

github: https://github.com/w3c/csswg-drafts/issues/6788

florian: I disagreed with just one of his statements, not all

florian: In UI4 we introduced 'input-security: auto | none'

florian: 'auto' does nothing by default, but on password fields (and other host-defined "sensitive" things) it obscures the text via *** or whatever

florian: 'none' turns that off

florian: Mats says this is a useful feature, but shouldn't be under the author's control, needing them to use JS on things.

florian: UAs are also much more likely to get a11y right on things like this.

dholbert: Also Edge already does this by default with a little button on password fields

astearns: Anyone implemented the CSS value?

TabAtkins: WebKit did, Chrome inherited it pre-fork

<fantasai> TabAtkins: Not ok to drop without a replacement

<fantasai> TabAtkins: maybe mark as deprecated and that we will remove, once HTML spec is updated to require

<fantasai> TabAtkins: No mandatory UI, but required functionality

smfr: I don't have much of an opinion.

smfr: If we need it internally we can keep it internally, don't have a strong opinion

<fantasai> florian: Can we not have the dependency on HTML?

<fantasai> TabAtkins: The functionality is useful

<fantasai> TabAtkins: optimal place is not in CSS, but if we don't have the functionality otherwise should leave it in

<fantasai> florian: I'm saying we drop it from CSS now, and encourage browsers to do the right thing

<fantasai> florian: rather than not removing it now

<fantasai> TabAtkins: That falls into the failure mode that's likely, which is that we remove it and nothing happens to HTML

<fantasai> TabAtkins: and I think this is useful enough for users that we shouldn't encourage nothing

<oriol> Firefox also has a UA button to show text (like Edge) behind pref: layout.forms.input-type-show-password-button.enabled

<fantasai> florian: Chrome has it?

<fantasai> TabAtkins: yeah

<fantasai> florian: Edge has it?

<fantasai> dholbert: Firefox also has it on Nightly

<fantasai> florian: So seems like the scenario of not having it is unlikely

<fantasai> Rossen: talking about the property?

<fantasai> florian: The behavior of being able to reveal the passwrod

<jensimmons> Issue at HTML: https://github.com/whatwg/html/issues/7293

<fantasai> TabAtkins: We don't have it in Chrome

<fantasai> ??: We disabled in Chrome because of compat issues

<fantasai> astearns: Issue in HTML spec?

astearns: That issue mentions something I'm concerned about, which is the HTML spec might need a CSS definition in order to say "here's what happens"

astearns: with this attribute or UI

florian: OK, maybe let's go back to what Tab suggests

florian: Resolve, we would like to remove this, would like it to be in HTML

astearns: So adding an issue to draft, we'd like to remove pls don't implement?

dholbert: My concern is that if we leave it, HTML spec might point at CSS for how to do it, and then JS can set in buggy ways

astearns: Note would say we'd like to remove, pls don't implement property, and HTML should define in a way that doesn't depend on CSS

florian: Tess is arguing for what we are saying to not do

astearns: Which is we should make it an issue and get Tess's input

Tim_Nguyen: Issue on our side was that inputs tend to have buttons for e.g. password autocomplete, and would need UI that wouldn't interfere

astearns: Sounds like we're not going to resolve any spec edits today, but let's add an issue to the draft saying we'd like to remove this

astearns: Proposed resolution is to put our recommendation into an issue in the draft, and come back to it later when we can get more discussion on it

astearns: Objections?

how does top-layer interact with ancestors

RESOLUTION: Put an issue in the draft saying we'd like to remove

SHIT

GOOD JOB

how does top-layer interact with ancestors

github: https://github.com/w3c/csswg-drafts/issues/6939

smfr: top-laye ris used by <dialog>, ::backdrop,e tc

smfr: They generate new stackign contexts, escape ancestor opacity, other graphical effects

smfr: 'visibility' is a bit different

smfr: It's inherited; as specced, a visibility:hidden ancesotr will hide a dialog

[simon was dropped]

smfr: Tab responded with a confusing comment

TabAtkins: ...

smfr: he said top-layer things are reparented in the box tree

smfr: so that doesn't affect inheritance

smfr: I think people might be confused about that effect with visibility

smfr: Maybe UA stylesheet should put visibility:visible on the dialog?

ntim: Worth nothing - display:none on the ancestor propogates to the top-layer element

emilio: unsure to what extent display and visiblity work together

emilio: was going to suggest Simon's UA stylesheet tweak to make it work

TabAtkins: That seems fine to me. I don't see a particular issue to set 'visiblity' in the UA stylesheet

TabAtkins: I think it is surprising that a dialog would stay hidden if the ancestor is hidden

emilio: Seems like a special case, yeah. But other than that, no strong feeling.

TabAtkins: I guess 2 resolutions

TabAtkins: a) Top-layer elements are essentially reparented in the box tree, so visual effects from containers don't apply, but inheritance applies as normal

TabAtkins: b) We add rule to UA stylesheet that dialog is visibility: visible

emilio: I'm not super convinced we should add it

emilio: could argue the same for a ton of other properties

emilio: but not strong, so won't object

astearns: what other properties?

emilio: everything that inherits, like pointer-events

emilio: anything that inherits thru could potentially be weird

astearns: And we're onlyt alking about setting visibility and not display

TabAtkins: display is consistent with what I said because it can't be reparented in the box tree, because it's not in the box tree

astearns: So first proposal from tab is top-layer elements are reparented in teh box tree, and point out that inheritance isn't affected by that

smfr: The "etc" in the spec text needs clarification

TabAtkins: agree, can do that

emilio: related to 'display' issue, something came up recently while triaging

emilio: Blink will create a box if the dialgo is a child of the replaced element

TabAtkins: I probably agree with you, decided on that in my comment too quickly. Because affects box generation, dialog shouldn't display at all

astearns: So any more discussion on the "reparenting in box tree" portion?

smfr: do we need to be that specific?

TabAtkins: You asked a bunch of questions, need to have consistent answers

TabAtkins: and having this conceptual model gives us consistent answers

ntim: I think stacking context/containing block dfns are enough to cover those cases

TabAtkins: Possibly

TabAtkins: I can review and see if that's enough

astearns: So why don't we not take that resolution for now, and you cna review

astearns: Okay so the etc

ntim: pointer-events

TabAtkins: It's an inherited property, so will just inherit. Unless we want to do a reset in the UA stylesheet

astearns: Do we need to resolve on resetting visibility?

TabAtkins: OK, let's do that

astearns: Proposed to have UA stylesheet reset visibility for dialog ... what about other top-level elements?

TabAtkins: Can't for other elements, can be arbitrary elements

TabAtkins: so can only do for dialog

astearns: OK, so proposed is that UA stylesheet sets 'visibility' on dialog

smfr: when they are in the modal state

fantasai: I believe there's a :modal pseudo-class in HTML

ntim: we have a pseudo-class, but internal, not exposed in CSS

iank_: I wrote that internal class

iank_: Wording is there, but not actually in the HTML spec

astearns: Anything else we can use to select?

TabAtkins: reasons we don't want to go into, are they blockers to putting in HTML spec or historical?

iank_: There was pushback to adding as an actual pseudo-class

iank_: HTML spec didn't want to define pseudo-classes itself

TabAtkins: put it in Selectors

ntim: UA stylesheet, should have a statement about it

smfr: Comment about ::backdrop

smfr: current behavior, if have visiblity:hidden ancestor on dialog

smfr: is that dialog is hidden but backdrop shows up

smfr: because backdrop not affected by inherted visibility, that's not great

TabAtkins: right, because ::backdrop inherits from the root

emilio: I thought it didn't inherit, which causes problems with system properties

rune: ...

<iank_> https://html.spec.whatwg.org/#phrasing-content-3 and scroll up

emilio: Which is something we may want to consider fixing

TabAtkins: That can be done in today's CSS by setting 'all: initial' in the ::backdrop stylesheet

TabAtkins: so explainable in current CSS

emilio: is it though?

<iank_> "The dialog element, when its is modal flag is true, is expected to act as if it had a user-agent-level style sheet rule setting the following properties:"

emilio: all doesn't reset custom properties

emilio: We have an agenda item about selection, e.g. new ::selection model not inheriting from original element which causes other issues

iank_: Quoted the prose from HTML

TabAtkins: HTMl spec says "pretend there's a pseudo-class, and apply these properties"

TabAtkins: let's just define the pseudo-class

iank_: Pushback was exposing the internal pseudo-class to web developers

astearns: Is there a concern about exposing to web devs?

emilio: I think Gecko was the first to implement via internal pseudo-class

emilio: Everyone converged on that model

emilio: I think at first there was some resistance to expose a pseudo-class because not how some browsers work

emilio: but at this point, given we have interop in that sense, all browsers have internal pseudo-class

emilio: maybe makes sense to expose it

iank_: Agree it makes sense, but think we'll still get pushback from WHATWG

iank_: Another thing that could be internal class but isn't

TabAtkins: we don't have to invoke WHATWG, we just put it in Selectors

TabAtkins: as long as browsers want that, not a jurisdictional problem

emilio: ...

TabAtkins: To change the styling of a dialog based on whether it's open in a modal style or not, if UA wants to do it don't see why authors wouldn't want to do it

ntim: I don't see much use case for it

ntim: Unlikely that someone will call showModal() and show() on the same dialog

astearns: I suggest we separate out whether propertly-defined pseudo into own issue

astearns: but whether or not we do that, we should define certain things for dialog using existing internal pseudo-class

astearns: so have some changes mentioning that you set visiblity and perhaps pointer-events

astearns: using same handwavy definition that HTML currently has

astearns: and separately figure out whether we need an exposed real pseudo-class to put into Selectors

astearns: does that sound reasonable?

TabAtkins: OK, opening issue

astearns: So can we resolve to set visiblity using internal pseudo-class?

astearns: Anyone want to continue discussing? Anyone have an objection?

[continued silence]

RESOLUTION: Set visiblity:hidden on modal dialogs

astearns: Any other property to resolve now, or continue discussing in the issue?

ntim: Pointer-events maybe?

ntim: Idk if it should be auto or all ...

astearns: In interest of time, let's punt to issue

astearns: and find out what the value should be and figure out any other properties that should be set in this way

astearns: Done with this issue for today

astearns: bit about box-tree reparenting, should that be a separate issue so don't lose track of it?

(new issue for :modal-dialog https://github.com/w3c/csswg-drafts/issues/6965)

astearns: OK, we'll keep this issue just about properties to set in UA stylesheet

astearns: separate issue on modal pseudo-class

astearns: and separate issue on reparenting

[css-conditional-4][selectors-4] How should selector supports test react to partially-implemented selectors?

github: https://github.com/w3c/csswg-drafts/issues/3936

fantasai: So it's about how supports() should work for "partially-implemented" selectors (only implemented in some contexts)

fantasai: And if we need a separate supports*() function to differentiate them.

TabAtkins: :has() psueudo-class, was suggested could be implemented just in .querySelector and not in CSS

TabAtkins: Question about whether @supports/.supports() return true fo rsupport in that case

TabAtkins: Conclusion was that only true if supported in CSS

TabAtkins: and can tell if .querySelector supports by whether or not it throws

TabAtkins: So shouldn't need additional work

astearns: So anyone interested in keeping the issue open, or okay with closing?

astearns: Objections to closing?

astearns: I trust if Amelia disagrees we'll hear about it

RESOLUTION: Close no-change

proposed: .supports/@supports checks for support in CSS, use .querySelector throwing to check for support there, close no change

can we ship hyphenate-character?

jfkthame: Question in the title

jfkthame: webkit and blink have this, but -webkit- prefixed

astearns: And Firefox has this unprefixed?

jfkthame: Yes, behind a nightly flag

jfkthame: So quesiton is whether we can ship it unflagged

fantasai: I think so. I don't remember there being any issues against this particular property for the many years it's been around

florian: Agree. You noted there might need to be extensions later to be smart about some details, but they can be put on top of the current value set

astearns: What's state of the spec?

florian: WD, this is level 4

astearns: So we resolve this is okay to publish, and add this to the snapshot list of things that are shippable ahead of process

astearns: objections?

RESOLUTION: hyphenate-character is shippable; we'll add it to the Snapshot 2022 list of exceptions

fantasai: Do we want to resolve to publish a Draft Note 2022 with this change?

astearns: I think we should publish as needed, yes.

chris: Seems much better to publish as we ahve updates, yes

astearns: So proposed reoslution is we publish a Draft Note for 2022

(Now that we have a Draft Note)

chris: since /TR/CSS goes to the snapshot, why don't we publish a NOte series with "css" as the shortname, so every time it's not the first draft, but just an update?

fantasai: I didn't like this; I think it's useful to have snapshots on a yearly basis

fantasai: Just walking back thru publish history isn't the same

chris: If you follow history right now, it'll say "css 2022 has been published once", and you can't go back to 2021 from there

fantasai: I think your point is valid but it is true for all leveled/versioned things

fantasai: That's an issue for the templates

astearns: So no reoslution, we'll break

<dbaron> github-bot, end topic

<emilio> https://github.com/w3c/csswg-drafts/issues/6939#issuecomment-1016671534

top-layer stuff

github: https://github.com/w3c/csswg-drafts/pull/6537

RESOLUTION: Set visibility: visible on modal dialogs

end

Kind of widget for an element

github: https://github.com/w3c/csswg-drafts/pull/6537

florian: haven't looked into this recently

astearns: I think we should accept the edits and file issues if there are remaining problems

fantasai: I'd like that to be conditional on florian's approval

florian: Can we defer this to next week? Need to check changes were made

Rossen_: yeah, that's fine, don't want to get that landed and then review it

conditionText setter interop

github: https://github.com/w3c/csswg-drafts/issues/6819

fantasai: there's a lot of failures when I was testing this. Firefox was the most correct on @media but fails on @supports. WebKit / Blink doesn't support either
… do we want to file impl bugs or call them readonly?

TabAtkins: I know setting media attributes on link is useful
… and used by some tooling
… so I think it's useful to continue supporting it
… but I wouldn't shed too many tears if we call it readonly

<fantasai> emilio: I'd like to say that making conditionalText in the OM is different from what tooling does changing medi aof link

<fantasai> emilio: latter depends on ... stylesheets

<fantasai> TabAtkins: I was talking about toggling an @media rule

<fantasai> emilio: But not supported by WebKit and Blink

<fantasai> TabAtkins: Toggling *conditionText* isn't supported. But toggling mediaText *is*, though essentially a synonym

<fantasai> emilio: The media attribute on link or style element toggles the DOM attribute

<fantasai> TabAtkins: not talking about that

<fantasai> TabAtkins: talking about @media rule

<fantasai> emilio: ah, ok, that's weird

<fantasai> TabAtkins: Jonathan Neal has exploited that to toggle entire sets of rules before

<fantasai> Rossen_: So if we move to resolve on making this readonly

<fantasai> Rossen_: would there be any objections to it?

<fantasai> fantasai: I suspect in either case we need changes in implementations

<fantasai> fantasai: just a question of which way we want to go

<fantasai> Rossen_: Forcing a normative change here would be encouraging something to change

<fantasai> fantasai: I have a PR adding tests, just haven't merged because opened this issue

<oriol> Reconnecting headset

oriol: conditionText seems analogous to selectorText for style rules and that's not read-only
… in the past it was not interoperable but it got fixed

<fantasai> emilio: Counter-example, we made layerName readonly

<fantasai> emilio: and generally leaning towards making OM readonly

oriol: so counter-examples in both directions which is not a great state of affairs

Rossen: So options are leave as-is and hoping tests cause browsers to change
… or resolve on making read-only
… should we do a straw-poll?

TabAtkins: I'd prefer to make stuff consistently mutable, given this is analogous to existing htings which are mutable

<bradk> +1 As is, but encourage browsers to change

<TabAtkins> emilio: Making @supports mutable would be a change

<TabAtkins> emilio: @media dynamically changes but @supports doesn't currently

<futhark> Existing issue for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1210073

emilio: so that might be why Firefox doesn't support mutating it. In general readonly is going to be easier to get interop on
… but not super-strong feelings either way

bradk: I think it should be mutable

smfr: from an implementor perspective we'd like to CSSOM be more readonly, we don't have many incentives to fix these bugs

<TabAtkins> I suppose the fact that @media *does* have the .media mutable means it's okay for the .conditionText to be a readonly version that covers everyone

<bradk> A

<fantasai> 0

strawpol: A - as-is, B - read-only

<oriol> A

<florian> 0

B

<smfr> B

<TabAtkins> B

<futhark> B

<miriam> 0

<dholbert> 0

<jensimmons> B

<astearns> 0

<jfkthame> 0

<bradk> I don’t feel super strongly about it

<lea> Α

<delan> 0

<TYLin> A

<Morgan> 0

<rachelandrew> B

<tantek> B until there's a use-case described (didn't see it)

<Rossen_> B

<castastrophe> A

<chris> 0

<lea> Reasoning: Readonly puts undue burden on authors when they need to modify these rules to make things easier for implementors

RESOLUTION: Make conditionText readonly

feature detection for descriptors

TabAtkins: seems reasonable to ask for this given we can do it for properties
… as @rules grow you might want to be able to test for given descriptors
… there's a suggestion that we add a new @supports query to test for descriptors

<lea> github: https://github.com/w3c/csswg-drafts/issues/2463

TabAtkins: I'd describe the two that I think we should add
… and lea has other ideas
… I think we should test for general @-rule support
… so "can you identify this rule at all"
… the other one should be a more complex one for testing for a whole @rule

<TabAtkins> @supports (@rule) {...}

<TabAtkins> and @supports (@rule { desc: value; }) {...}

<fantasai> TabAtkins was summarizing https://github.com/w3c/csswg-drafts/issues/2463#issuecomment-1015709662 right?

<TabAtkins> yes

lea: I think the only additional thing I proposed is that we shouldn't have to add random descriptors to see if the browser supports particular descriptors or what not
… so test for support for e.g. @property or so

<TabAtkins> emilio: Regarding testing the whole rule

<TabAtkins> emilio: It's a bit weird, because we don't track parse errors, we just drop

<TabAtkins> emilio: We could od that potentially, but it goes against th eprinciple

<TabAtkins> emilio: I think it would be nicer to do somethign else, but not sure what else could be

<TabAtkins> emilio: Don't have a generic idea for it

<TabAtkins> emilio: Like would great for `font-face-descriptor(desc: value)` but then you'd need it for each

<TabAtkins> emilio: Just scares me if it gets out of sync

chris: wanted to check where we are in nested at rules

<fantasai> emilio: Another related concern, some rules are related

<fantasai> emilio: so if you parse an at-rule in an @supports block ...

<fantasai> emilio: should we consider position in the style sheet?

oriol: it seems strange to me the including-the-whole-at-rule
… because parens would accept a weird set of syntax
… and this seems a bit inconsistent / confusing to authors to me

<TabAtkins> (I'm fine with an `at-rule()` function, fwiw.)

oriol: because they might want to test for style rules
… but we're not supporting that, so I'd prefer another function
… or an option for testing general rules that could be an at-rule() or general rule
… but mixing some but not all rules, and also property-declarations in parens would be a strange mix

TabAtkins: emilio's point about the whole rule testing is a very reasonable point and I don't want to do this if it requires special cases
… I'd like to instrument the existing parser if possible

<fantasai> emilio: Even with instrumentation, it can still get out of sync

<fantasai> emilio: e.g. someone forgets to propagate the error

<fantasai> emilio: so even if set just a boolean that indicates parser error

<fantasai> emilio: if don't set it at the right time, is a problem

<fantasai> emilio: It wouldn't be a whole new parser, just concerned about sync

TabAtkins: connected to that, there's chris' question about nesting
… if you have per-at-rule descriptor function then you don't get nested at-rules for free
… the other question was about context
… I'd say we should specify what the parsing context is for this
… which would be the generic top-level stylesheet context, so @import would fail
… and re oriol's point I'm totally fine with `at-rule()` or something if you think it's less fair

<oriol> Yeah it think that's better

dbaron: I think when I wrote the @supports proposal the way I had envisioned extending them is that we'd add new functions for other points where CSS drops things
… so at the point where the CSS parser says "oh, that is invalid so we drop it as a unit", that seems sensible to add a function for
… and I think it's a bit weird to put a whole rule inside @supports
… that said I think TabAtkins' argument about nesting is interesting, because the approach I was thinking of at the time doesn't allow you to test for such things
… so I have mixed feelings about it

fantasai: regarding the TabAtkins' generic top-level context I think that'd be confusing to authors, I think it'd be more understandable and useful to authors if we allowed both that or anything that's in the prelude, so that e.g. @import would count as supported
… I think it'd be less confusing to authors
… and I can see use cases for doing that if you want to do something conditional in whether some extended at-import syntax is supported
… I also wanted to say about dbaron's comment that it would be better to have the nested syntax rather than having many custom functions per at-rule
… I'd prefer parenthesis rather than a function, I think it'd be a little bit cleaner and easier to type

<TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo, desc: value) {...}

TabAtkins: thanks dbaron for all that context. If we follow those premises we also avoid emilio's concerns. In that context perhaps we could do something like what I typed above in the chat
… it doesn't address nesting right now but we can extend it if needed
… we also don't and probably won't have many at-rules that are inconsistently nested

<faceless> Surely @supports (@import) should always fail, as @import must be the first rule? So if you precede it with @supports, it's not valid?

<fantasai> faceless, I don't think @supports queries should be sensitive to position

<lea> faceless: is there a use case for @supports(@import)? Literally every browser supports @import, no?

<fantasai> emilio: @supports(@import) { } and then not put an @import inside

<TabAtkins> Not as a positive test, as a negative test.

<fantasai> TabAtkins: My proposal is not parsing, just is this at-rule in your list of recognize at-rules

<fantasai> emilio: fantasai it might be useful to test e.g. @supports(@import "" layer) or something

<fantasai> emilio: though for layer you could check to @layer

<fantasai> emilio: I think having a generic at-rule() function is better than having function per at-rule

<fantasai> TabAtkins: The downside is it wouldn't allow testing the prelude of an at-rule

miriam: prelude seem important for several things like layers and container

<fantasai> miriam: That was my question, because preludes seem important for many things, such as @layer and @container

miriam: so it seems odd to leave it

fantasai: I see that at-rule() as an improvement to having a function per at-rule
… but I don't see how that is better than just dropping the whole css syntax

<TabAtkins> If we wanted to add it, could have the form `at-rule(@foo prelude stuff)`; when there's >1 token there we test full prelude parsing

fantasai: it'd cover handling the prelude / descriptors / nested at-rules / etc
… so I don't understand why we'd go for the function rather than the proposal that was on the issue

TabAtkins: emilio and dbaron explained why that wasn't great
… you'd need to detect whether there's a parse error somewhere in a rule needs intrumenting the parser
… whether testing whether something is dropped entirely or not is easy and can be done with no possibility of missing things
… because we definitely drop things that are invalid and is detectable, but detecting whether an inner descriptor failed to parse inside an at-rule requires special-casing

Rossen: does that answer your question elika?

fantasai: yes

<TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo, desc: value) {...}

TabAtkins: proposal is having the at-rule function with two syntax variants: `at-rule(@keyword)` and `at-rule(@keyword, descriptor)`

fantasai: not against that but I have a question about how do we extend to the prelude

TabAtkins: posted that up as well, we could have it drop the whole prelude in there or something

fantasai: but prelude might include commas
… if you want something not in the prelude you're going to need a semi-colon

<lea> what about descriptor values? at-rule(@keyword, descriptor, value)?

TabAtkins: alright let's use semi-colons

<fantasai> emilio: Meant to write descriptor:value

lea: would there be a way to test for @rule <name> or so?

TabAtkins: that's the prelude extension we were discussing above

<TabAtkins> at-rule(@keyword; desc:value)

dbaron: so to clarify you wouldn't extend it to put the whole at-rule inside right?

TabAtkins: right, or we just drop it and if we drop descriptors inside then it'd test true
… I think we should resolve on the keyword and descriptor variants and we can extend to support the whole prelude

RESOLUTION: Add an `at-rule` function with syntax `at-rule(@keyword)` or `at-rule(@keyword; descriptor: value)`

Make box-shadow a shorthand

github: https://github.com/w3c/csswg-drafts/issues/4431

TabAtkins: we've discussed about this in the past
… people want to animate one bit of a shadow, like increasing the spread etc
… you can always use custom props and so on and it seems so straight-forward that I think we could try

<TabAtkins> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613

TabAtkins: sebastian proposed a grammar (link above)

TabAtkins: (describes linked proposal)

lea: I want to express support, this is a very common thing. It's one of the first examples I use for custom props
… is there an inset prop?

TabAtkins: yeah

<fantasai> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613

lea: can we do it for text-shadow too?

<Zakim> lea, you wanted to express support

TabAtkins: yeah, also in the proposal

dbaron: I guess one of my reactions is that the stuff that background does is one of the most complicated parts of implementing value computations on CSS
… the code for dealing with that was a significant part of the old parser

TabAtkins: for this there is one controlling property

dbaron: true for backgrounds as well (for background-image)
… and you need to keep the whole list because you might inherit it somewhere where it matters

TabAtkins: isn't this a common pattern like animation?

dbaron: yeah, but it's special code every time

smfr: should box-shadow-offset be further broken down into x/y offsets?

TabAtkins: [meh reaction]

<Zakim> fantasai, you wanted to mention that -position needs renaming 'cuz it's not a <position>

<fantasai> emilio: Regarding what dbaron said, not just about parsing complexity but also efficiency

<fantasai> emilio: you need to store 5 different arrays rather than one

<fantasai> emilio: so it's also a bit more inefficient

<lea> fantasai: box-shadow-offset perhaps?

<fantasai> emilio: maybe OK if we consider these to be relatively uncommon

<fantasai> emilio: The parsing complexity is real. Background is the worst by far, but need to check also transitions/animations. It's not super amazing

<fantasai> TabAtkins: Question is, is linked list-valued properties something we want to add generally, or not

TabAtkins: the main q is whether adding more list-valued shorthands is ok, and if it's not we should not do it consistently

dbaron: I wouldn't say never do them but it's more expensive than you might thing

TabAtkins: curious, is the opinion different depending on "there's one length-controlling property vs. shortest wins"

dbaron: I don't think it makes a huge difference
… only if you truncate computed values perhaps

TabAtkins: that seems fine

Rossen: let's follow-up in the issue

end