– DRAFT –
(MEETING TITLE)

<bramus> (chat only)

<rachelandrew> irc only for first half

<bradk> I’m going to be in and out of the call today

Agenda Bashing

astearns: Most of the nesting issues are fine to take up and are ready, but I'm just not seeing consensus on the blocking issue 8249.

astearns: Not sure we need to spend call time on it until we get to a better situation in the issue itself

TabAtkins: Safari and Chrome are both interested in shipping very soon

TabAtkins: If we defer until the logjam resolves itself, it's going to get resolved by somebody shipping

astearns: We try to address the objection

TabAtkins: That's why we didn't resolve last time

TabAtkins: but we need to discuss and resolve

jensimmons: The two color issues are important for us to get to today

jensimmons: and also nesting

jensimmons: When Peter raised the objection, there were 3 parts and we opened different issues to discuss

jensimmons: there were a lot of conversations that were had about those objections

jensimmons: and I do think we can focus our objections on that specific thing and not repeat ourselves

jensimmons: So maybe do the first two issue,s then color, then the rest of the call for nesting

Rossen_: ok, we can try that

+1

good suggestion, jensimmons

<emeyer> +1

Tim: I would like to get to #3

Tim: don't know if it will fit in this call

Rossen_: Let's see how quickly we get through the first six we have right now

Rossen_: the sooner we start, the sooner we might get to those

<lea> present_

Pseudo-class before-change style for transitions on new elements

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

flackr: when coming from display:none have no display style
… so can't define a from state
… can define in CSS animation, but less ergonomic
… so proposing we add an :initial pseudo-class which establishes the initial style
… the before-change style for CSS transitions
… in discussion, decided that if we made this a pseudo-element
… we could optimize this by preventing e.g. sibling selectors and only require occasional style calculation when it's used
… so proposal is to have ::initial establish the initial style

emilio: This would be a pseudo-element that matches against an element?

emilio: so matches element rules plus magic pseudo-element?

pseudo-element would be applied on top of element rules

emilio: that's pretty different from pseudo-element

emilio: I don't think we have a precedence for this, which is a bit tricky

emilio: I'm also confused when you want it

emilio: this is for coming back from display:none?

emilio: seems implementable, but seems tricky and weird to make it a pseudo-element

emilio: because targetting two element styles on one

emilio: weird wrt cascade

flackr: that's good feedback for pseudo-element approach

flackr: could also take pseudo-class approach, but less easily optimizable?

emilio: in what sense?

flackr: if you have combinator selectors, element showing up in the DOM can cause recalcuation

emilio: but that's the case for all pseudo-element

flackr: this is extra style recalc that doesn't normally exist

emilio: I'm a bit confused, you recalc more if you have :initial along the combinators.... depending how wel you optimize

flackr: I think given :initial is only establishing before-change style and otherwise doesn't apply to the element, not that weird that it conflicts with other styles

flackr: because those other styles can't initiate transitions from display: none

emilio: we have a similar case with pseudo-classes for links

emilio: need to resolve :visited / :unvisitied, need to do unconditionally, but dont' understand why :initial would be slower

flackr: if initial is a pseudo-class, can be used as part of combinator selectors

flackr: so have to resolve all those combinators

flackr: but if pseudo-element, can't be used in those combinators

emilio: for :visited we have special case

emilio: basically :visited on left of sibling is ignored

flackr: ah, we could do that

emilio: the way I think of implementing it is, we have this element ...

emilio: otherwise :initial only matches rightmost compound

flackr: that sounds reasonable to me

emilio: that would be less weird

+1 to emilio

futhark: ignoring the pseudo-class, when resolving selectors, would have already computed style for previous one so would have eixsting computed style

futhark: so :initial wouldn't match on those elements

emilio: Right. :initial can only match in this special case

emilio: "this element is now :initial", now compute

emilio: with :has() have similar dependency...

futhark: Similar if getComputedStyle() in display:none subtree

futhark: You need to ensure you have styles there to do inherit etc.

emilio: not for siblings, but for ancestors

emilio: I'd rather say that it only matches on the rightmost

<flackr> +1

<chrishtr> +1

fantasai: How does this interact with page loading, partly loading?

flackr: applies anytime the element first gets a layout box

flackr: this would apply any time you add element to a page

flackr: separate issue for avoiding running things during load

flackr: but this is pre-existing problem for animations, which run on page load

Rossen_: So based on description, this would not fire on display:contents ?

Rossen_: since it doesn't have a box?

flackr: that sounds right

<Zakim> fantasai, you wanted to ask how this interacts with loading

emilio: I think I'd rather special-case it to display:none since that's the actual thing

<futhark> +1 to emilio.

emilio: at least, I don't think display:contents stops animations in the subtree, whereas display:none does

PaulG: If we're leaning towards pseudo-element, how would that affect AX tree?

PaulG: if not supposed to be animated at that time, just want to make sure we consider that

flackr: don't think we're leaning towards the pseudo-element approach

flackr: but not intenteded to establish a separate elmeent, just style the real element in the before-change state

fantasai: Suggest maybe flackr and emilio can come back with a revised proposal, and we can move to other issues

flackr: fwiw, AX should be equivalent to animations

Rossen_: ok, let's end here

Rossen_: come back when you're ready, thanks for introducing

Entry and Exit Animations for top-layer elements

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

flackr: When certain elements go in/out of top layer

flackr: if devs want to have an naimation on the, they need the element to remain in the top layer for duration of the animation

flackr: so proposal is that we allow specifying top layer in the transition properties

flackr: but that it's otherwise not a developer-stylable property

flackr: essentially, you can specify transition: top-layer

flackr: and give it a duratoin

flackr: and this is the duration during which the element stays in the top layer

ntim: I've always been against the top-layer CSS property concept

ntim: The concept should really stay abstracted away from the developer

ntim: even just introducing this property is a bad first step, I think

lea: I wanted to as ntim why he thinks this concept should be abstracted away from the developer

lea: there's a lot of reasons it should controllable in CSS

lea: we keep seeing use cases that could be solved if could be controlled in CSS

ntim: If you allow controlling top layer with CSS, you end up with same issues as z-index

ntim: the appeal of top layer right now is that it's controlled by order of JS API calls

ntim: but once you start allowing random elements to put top-layer, then what order is actually used in the end?

lea: I think that depends on how we design the feature

lea: maybe it's a property that just the UA controls

lea: though I hope to avoid that

ntim: I think it needs a real design

ntim: just exposing this concept...

<chrishtr> Note that the proposal is not incompatible with ntim's concern. I agree with his concern.

lea: yes, absolutely, does need design work to do it properly to not have problems of z-index

lea: total +1 to that

emilio: I don't think I have a strong feeling wrt top layer property

emilio: but basically the use case seems to be transitioning modal dialogs and so on when opening and closing

emilio: and I assume other elements in the top layer

emilio: to me that seems like a use case that non-modal dialogs also need

emilio: there are dialogs that may not be in the top layer

emilio: so feels to me that this is a clever hack to avoid having closing/closed state on the dialog and fullscreen things

emilio: not sure if that's been considered

emilio: so why is this property better

emilio: why not say that it goes from open to non-open, have an intermediate state, and define that intermediat state transition as when all its transitions have finished

flackr: Wrt tim's concern about exposing top-layer to the user, we have these stackign questions

flackr: this proposal nicely avoids, because things remain in their current stacking position

flackr: so we don't have to change any of that or figure out those definitions yet

flackr: I don't understand what non-modal dialogs have a problem, they can continue to apply their desired z-index

emilio: but you still have the issue of if you want a close animation on a dialog, you need to do it manuall

flackr: dialog element, which is top-layer?

emilio: dialog may or may not be top layer depending on show vs showModal

<masonf> If the dialog isn't modal, it isn't in the top layer, and you don't need this.

flackr: It would maintain its top layer state during transition, but still have to define the animation

emilio: idea is you can do opacity or transform or whatever to hide the dialog, right?

emilio: right now that's not easy to do with non-modal dialogs either

emilio: why not have ...

emilio: Firefox has all its panels as well, we have animations when you use menus

emilio: and those are just web elements

emilio: internally we have 5 states

emilio: open, opening, closing, closed

emilio: we ahve intermediate states so that the front end can actually use transitions for this stuff

emilio: my question is, why is this specific to top-layer and not to elements that pop in and out

flackr: you can't reasonably establish entry animations is resolved by setting inital styles

flackr: with that, should be possible to do on non-modal dialogs

flackr: top-layer is the only thing they don't have access to

flackr: the model is consistent with other things taht have a state change trigger an animation

flackr: state changes immediately, even though animation continues to run

<masonf> non-modal dialogs need the ability to animate to/from display:none, but that's a separate issue.

emilio: when non-modal dialog closes, you want to ?? animation to displaY:none

emilio: you transitoin display, which we resolved to do but don't yet do

emilio: so your proposeal would be to animation display directly and also transition opacity

flackr: I have proof of concept for Chrome

emilio: so this proposal is to explicitly allow z-order to remain while transitioning

emilio: like transitioning display

emilio: on one hand, I thin it would be less weird to have these intermediate states

emilio: when you open dialog, you transition to opening state

emilio: when you update style and don't have transitions running you're open

emilio: etc.

emilio: when no pending ransitions transition to closed

emilio: only targetted to dialogs/popovers/etc. but I think that's the main use case

emilio: I think that would be slightly less weird for authors

emilio: rather than transitioning display ...

emilio: having magic property seems weird

emilio: I guess this proposal weird, but I think maybe having intermediate pseudo-classes could be more elegant and usable for authors

flackr: I think this is more consistent with other state changes for the Web

fantasai: why not have things just stay in the top layer until their transitions are done automatically?

ntim: That seems to make sense

chrishtr: Having a transitioning state and this automatically detect what they're happening and preserve top layer during UA was thoroughly explored during popover design

chrishtr: and prototyped in Chromium

chrishtr: was specific to popover and dialog, and why not have a generic mechanism in animations

chrishtr: this is what lead to these proposals for display:none animations and specifying top-layer duration

chrishtr: without specifying UA magic to detect length of animations

chrishtr: discussed at length in popover API proposal

lea: firstly, it seems weird to have a property that only works in transitions

lea: if devs want to put things in the top layer, what prevents them from adding an animation that puts them in the top layer?

emilio: ....

lea: so only available in transitions?

lea: what prevents having a transition that lasts 999999s?

emilio: you'd need to call modal

lea: trying to prevent devs by adding only to transitions, it's a hack and can be worked around

emilio: I agree

emilio: internally, how we implement top layer

emilio: I'm not sure how I feel about this

[missed]

Rossen_: let's end this topic right here

Rossen_: we coered quite a bit, but this doesn't seem ready for resolution

Rossen_: was well articulated and proposed, and good path forward for addressing some of the TAG review comments

Rossen_: shoudl take conversation back to GH, and should bring it back when it's more developed

Agenda

Rossen_: Two nesting and two color issues, top priority. Order?

chris: would like to suggest the color issues, think there's consensus

chris: if agreed, we can close rapidly

Relative Color Syntax

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

chris: problem was specifying base color as currentcolor

chris: I added spec text similar to color-mix()

chris: if that's okay by everyone we have solved the issue

TabAtkins: Great for me

Rossen_: Anyone else?

RESOLUTION: Accept Chris's proposal

<lea> +1

channel keywords

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

chris: main issue raised was that the keywords could have two possible types, doesn't work

chris: either number or percentage

chris: went with number to be consistent with serialization

TabAtkins: nit, you accidentaly did percentage for wmb, but otherwise it's great

chris: It's because color-4 it only takes a percentage

TabAtkins: Ah, in that case it's completely fine

chris: any other comments?

chris: anyone need more time?

ntim: didn't have a chance to look at it

lea: does that mean for rgb they resolve to 0-255 range?

chris: yes, but remember it's 0.0 to 255.0 so you don't lose precision

lea: but inconsistent with rgb models

chris: because it was invented poorly

lea: I agree but does that mean we don't need relative color syntax for rgb?

chris: I have a lot of trouble coming up with use cases

chris: I haven't found a good example

lea: I think it's primarily for completeness, but we don't generally do things just for completeness

lea: restrict to color()?

chris: I wouldn't go that far

chris: let's resolve this and deal in other issues?

chris: get consensus on going to number?

Rossen_: So do we have enough consensus?

lea: consensus is about every component that's "number or something else" resolves to number?

lea: so hues resolve to numbers?

chris: yeah, all examples treat hues as number

chris: so I think most ppl are treating as numbers

lea: yes, that's what authors do

[...]

<argyle> +1 to number

chris: Proposal, keywords with multiple specified types result in number

Rossen_: Any additional feedback or objections?

jensimmons: this is fine with us from Apple

RESOLUTION: keywords with multiple specified types result in number

CSS Nesting Syntax

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

<chris> resolving two color issues in <10min is unprecedented

TabAtkins: I'm willing to summarize what I believe plinss's position is, he can correct

TabAtkins: fear is that the direction the spec is specifying will overly constrain future CSS

TabAtkins: certain new syntactical things in properties or selectors

TabAtkins: proposal is instead to have a dedicated syntax to mark things as a selector

TabAtkins: that way all future syntactical developments would still be allowed

TabAtkins: and future developments for selectors, which might currently conflict with properties, would also be allowed

TabAtkins: because you have a glyph to mark it as a selector

TabAtkins: related is the 8251 issue, where dbaron discusses the things that trigger selector processing and not currently used by selectors

TabAtkins: this issue accepts mixing of properties and selectors in grammar space

TabAtkins: issue is, we've already discussed previously, what peter is suggesting

TabAtkins: this was Option 1, you had to start with & or @nest or various variants thereof

TabAtkins: This was rejected by WG for verbosity and for copy-paste limitations

TabAtkins: core issue is, WG has looked over that syntax direction and rejected it in the past

TabAtkins: so I would like to re-affirm that decision, that we're not going to use a dedicated marker syntax of some kind to denote selectors and separate them from properties

TabAtkins: but rather go with current approach of mixing the space

TabAtkins: make sure the Syntax spec creates a clear dividing line

<TabAtkins> fantasai: I think something Tab didn't emphasize is the core part of Peter's concern for forward compat

<TabAtkins> fantasai: The real effect of forwards compat isn't as - we'r enot limiting as much as it seems like we are

<TabAtkins> fantasai: What we're allowing for the future is anything that's invalid, regardless fo whether it's currently property or selector

<TabAtkins> fantasai: The space of "what is invaidl junk" is actually really broad even with our current proposal

<Zakim> fantasai, you wanted to react to ntim

https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982

<TabAtkins> fantasai: The ony thing we can't expand into is a super-limited syntax space that I can't imagine us actually doing

#stuff starting with a symbol { anything in this block } valid-property: value;

<TabAtkins> fantasai: We cant' start with a symbol, *and* has a curly-brace block *and* is followed by something tha tlooks like a property

<TabAtkins> fantasai: This is the only thing you can't define in the future is a cool new feature

<TabAtkins> fantasai: If it doesn't look like that it's invalid - whether a property or style rule, we throw it out

<TabAtkins> fantasai: And in th efuture we can call it valid either way

<TabAtkins> fantasai: So for concern abou tpainting us into a corner, it's acutally a very small corner and the rest of the space is open

plinss: Just want to clarify a couple points, most of what Tab said is accurate

plinss: it's not necessarily required to have a solution that prefixes every single rule

plinss: also fine to create a new scope

plinss: just nested brackets or whatever, that also solves the copy-paste problem

plinss: just want something that delineates the syntax space

plinss: we did resolve not to do this in the past, but I'm not sure that took everything into account

plinss: not locked by previous decision

<astearns> +1 to not taking older @nest decision as final

jensimmons: I did hear plinss's concerns, and we've discussed exhaustively

jensimmons: but despite downsides, I see all the momentum going towards Option 3 including from webdevs

jensimmons: There was a lot of conversations after final December meeting, and I appreciate dbaron, fantasai, TabAtkins investigating what we would limit ourslves

jensimmons: but it seems we're not really limiting ourselves, so I think should move forward

jensimmons: want a path that moves us forward and is realistic and acceptable

lea: A lot of things I wanted to say were mentioned by fantasai, still have a lot of space for expansion

lea: but we could expand that space even further by reserving some characters

plinss: I'm not sure I buy fantasai's argument

plinss: it's not infinite, but there are cases where we wanted to do something but couldn't because shows up in the wild as some weird hack

plinss: I think it'll be limiting

plinss: example is custom properties, couldn't have done that if we had done this first

plinss: I don't want us to get into that situation

<TabAtkins> fantasai: Lets take the custom property eample

<Zakim> fantasai, you wanted to respond

<TabAtkins> fantasai: say initial hypthen switched us to selector parsing

<TabAtkins> fantasai: we could do it

<TabAtkins> fantasai: You'd throw it out as an invalid selector today

<TabAtkins> fantasai: And that means we can reinterpret it later

<TabAtkins> fantasai: Have you really looked at what the limiting case is?

<TabAtkins> fantasai: The ocnditions are really strict. anything that's currently invalid and gets thrown out, we can reinterpret

<TabAtkins> fantasai: have to keep in mind that the parsing in the nested context isnt' the same as top-level, we truncate at top-level semicolon even in selecto rparsing

<lea> *Nesting itself* is a case where past syntax limits us in what we can do syntactically (going back, maybe we should have used something other than a colon for pseudos), but it's not an insurmountable problem, we are designing around it. We'll design around these issues in the future too, if they come up.

<TabAtkins> fantasai: So there's very limited - can't think of anything you want to do that'll cause a problem

plinss: we could solve this with lookahead

plinss: also concerned that we have stuff that's valid for selectors and can't re-use for properties

plinss: selectors can be really really really long, especialy with lists of selectors

plinss: thing at the end that changes selector or property, could get into situation that we cant solve without a lot of lookahead

Rossen_: I've closed the queue, 2min past the hour

<lea> regarding exploring lookahead, I tried. Here's a summary: https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362739063

Rossen_: Strong arguments in both directions

Rossen_: alan proposed we make nesting an additional call, can make it as soon as next week e.g. 1hr before the main CSS call

Rossen_: but right now we don't seem to have consensus

<lea> +1 to Nesting breakout

Rossen_: or we can take a resolution and ask Peter to file a formal objection

TabAtkins: I would prefer to get the formal objection filed now if it's going to be filed, would rather not be in limbo

<lea> let's try to avoid a FO as much as we can, the TAG is already overworked :(

TabAtkins: fantasai and I explored the syntax space carefully, we don't think there's a real limitation there

<astearns> have to drop

TabAtkins: so I don't think further discussion will yield anything useful

<lea> we need a Nesting breakout even regardless of the FO, don't we? So let's schedule that

Rossen_: ok, we'll try to have a call for nesting, whether this topic is part of it or not is TBD

Rossen_: I will call for objections, and then have a resolution that seems supported by rest of group

Rossen_: Any objections?

plinss: I clearly object. More than happen to have the long call or breakout or sub-breakout or whatever

plinss: happy to let Tab and fantasai convince me that I'm wrong

plinss: and to change my mind

<oriol> I'm more on Peter's side on this topic

plinss: but shy of that, or changing the processing rules, I sustain my objection

Rossen_: It does seem this has been discussed over and over, and I hear support for this from many people

Rossen_: so suggest we resolve this, or take up as additional changes to the current resolution

plinss: We've resolved on Option 3 with this issue open

plinss: still saying we can discuss at the breakout call, so what's point of resolving?

Rossen_: we resolved to discount other options, not to adopt Option 3

[some discussion of what we resolved or didn't]

jensimmons: would be helpful to take the temperature of the room

<lea> fwiw, I agree with plinss that lookahead should be explored more. But not primarily for futureproofing (I think there's enough syntax space that we're not painting ourselves into a corner), but primarily for syntax ergonomics. I'm not convinced it's an unsolvable problem.

fantasai: straw poll, and then close discussion until next week?

Rossen_: A = support Option 3, and B = not support it

<argyle> A

<jensimmons> A

<ydaniv> A

<TabAtkins> A

A

<oriol> B

<bradk> A

<SebastianZ> A

<miriam> A

<plinss> B

<dholbert> A

<GameMaker> A

<flackr> A

<davidleininger> A

<futhark> A

<florian> A

<lea> I find the question unclear, so I'm not voting.

<lea> A

<Rossen_> A

Rossen_: pretty strong signal here, let's go ahead and record this as a resolution. We will try to get the extra nesting discussions, Peter I'm hoping you can proceed with next steps if you want to pursue formal objection or wait until next week

plinss: happy to discuss on breakout call, but want to actually get to it

Rossen_: we've never had a rule that we can't re-open previous resolutions :)

plinss: that's been teh arugment several times

florian: from the other angle, if you do file an FO and are subsequently convinced, you can retract it

plinss: if discusisng in a week, don't need to file an objection today

Rossen_: We'll schedule for next week then

jensimmons: please schedule for next week, it's quite importnat to us

RESOLUTION: Adopt Option 3

Rossen_: I appreciate everyone staying longer than usual, we don't almost ever, but this is an important topic to many

Rossen_: we'll schedule an additional meeting next week

Meeting closed.