15:08:25 <RRSAgent> RRSAgent has joined #css
15:08:29 <RRSAgent> logging to https://www.w3.org/2023/04/19-css-irc
15:08:29 <jensimmons> jensimmons has joined #css
15:08:32 <fantasai> Topic: Nesting
15:08:35 <changseok> changseok has joined #css
15:08:38 <jensimmons> present+
15:08:43 <github-bot> Subtopic: [css-nesting-1] Can we relax the syntax further?
15:08:51 <fantasai> astearns: We looked at lookahead possibilities
15:09:03 <fantasai> ... and discussion in this issue about relaxing syntax further to take advantage of lookahead proposed
15:09:24 <fantasai> ... question of whether to do in this level and update current draft, or create new level for lookahead
15:09:28 <oriol> oriol has joined #css
15:09:28 <fantasai> ... so that's what I wanted to get to first
15:09:49 <fantasai> TabAtkins: As plinss said in the comments at the bottom, there doesn't seem to be a path for the current spec to reach REC
15:09:55 <fantasai> ... might have only one implementation, not more
15:10:01 <fantasai> ... since we'll all be moving to the new option
15:10:16 <fantasai> ... so there wouldn't be 2 impls of what's in the current draft, except as historical artifact
15:10:17 <oriol> present+
15:10:39 <fantasai> ??: For Safari, we are on the path to release the current implementation
15:10:43 <fantasai> ... so there will be two implementations
15:10:57 <fantasai> astearns: Point is not two implementations of the limited syntax that requires recasting certain selectors
15:11:07 <fantasai> jensimmons: idk if it matters if it's two levels or one level
15:11:29 <fantasai> ... when we last discussed, ppl were talking about deleting all of the current text about what to do without lookahead and how the ampersand will function etc.
15:11:34 <fantasai> ... and that's what I believe is not a wise thing to do
15:11:51 <fantasai> ... if things had played out differently, might be reasonable to throw out text that wasn't shipping in any browser
15:11:56 <fantasai> ... but in this case we have two shipping implementations
15:12:05 <fantasai> ... nevermind about REC, but Chrome has already shipped and Safari is going to ship
15:12:18 <fantasai> ... and doesn't seem wise to me to completely delete the spec text that describes what two browsers have done along this complicated path
15:12:30 <fantasai> ... It could be a Note, could be somehting to say that this existed at some point, here's the description
15:12:41 <fantasai> ... Once zero browsers have it in their implementation could delete it
15:13:06 <fantasai> ... but going back on this path that was promised and act as if such implementations are off spec / non-compliant is not helpful
15:13:17 <fantasai> astearns: not illegal, just not required once implementations update
15:13:31 <fantasai> jensimmons: Fine that never required, Firefox is not required to do this implementation of course
15:13:35 <fantasai> ... whatever written down should say that
15:13:49 <fantasai> astearns: Could have a historical note saying, this is a thing that we had a long the way, and acknowledge it
15:13:55 <fantasai> jensimmons: Yes, that's my preference over deleting it all
15:14:03 <fantasai> TabAtkins: I'm fine with moving to historical appendix
15:14:08 <fantasai> plinss: What's the benefit to authors?
15:14:21 <fantasai> astearns: not memory-holing the previous discussion
15:14:31 <fantasai> plinss: we have plenty of minutes, online discussions, not pretending it never happened
15:14:46 <fantasai> astearns: Not talking about specifying, just having a note
15:15:01 <fantasai> TabAtkins: I think it's useful to have a description of what some implementations are doing, at least until they disappear into obscurity
15:15:08 <fantasai> scribe+ TabAtkins
15:15:17 <dbaron> Scribe+ dbaron
15:15:47 <dbaron> fantasai: In terms of process, unwise to put things that were on the REC track into a NOTE.  We created a new status called discontinued draft.  Keeps things on patent policy.
15:15:59 <dbaron> astearns: I think we're talking about putting an informative note in the current draft, not making the draft a note.
15:16:08 <dbaron> fantasai: I'm fine with having it in an appendix.
15:16:15 <astearns> ack fantasai
15:16:16 <astearns> ack dbaron
15:16:37 <fantasai> dbaron: My reaction to putting the old thing in a historical appendix is that maybe that is spec versioning done right, where what we normally do is spec versioning done wrong
15:16:48 <fantasai> ... because currently people land on the wrong version of a spec
15:17:24 <fantasai> ... but sticking things in as a historical note is maybe a better way of describing history over time than separate documents
15:17:24 <fantasai> astearns: I'm a fan of documenting how a decision has been arrived at
15:17:25 <fantasai> ... instead of having to dig through minutes, or do discussion spelunking of your own
15:17:34 <fantasai> astearns: Any other comments on what to do with the current draft of Nesting?
15:17:47 <fantasai> plinss: Not strongly opposed to having this as a note in the draft
15:17:55 <fantasai> ... not opposed to better changelog or history
15:18:05 <fantasai> ... should we do this as a general policy
15:18:25 <fantasai> ... personally this strikes me as, reluctant to say this, but I think the reality is that implementations shipped prematurely
15:18:32 <fantasai> ... and this seems like a way of washing over the fact that they did that
15:18:52 <fantasai> TabAtkins: benefit to users is that at least one version of Chrome and Safari are shipping with a behavior that is not what's in the spec we want
15:19:07 <fantasai> ... and it's good to have documentation on what's doing, people can understand that it's legacy behavior and it's how it works
15:19:22 <fantasai> plinss: We have old versions of the spec, but I'm not going to die on this hill
15:19:28 <astearns> ack fantasai
15:19:55 <dbaron> fantasai: Keeping in appendix given multiple shipping impls is a good idea.  Wouldn't be opposed to ? a section befor eth spec is concluded saying what browsers shipped.
15:20:11 <dbaron> fantasai: ... then it's not implied that ? is what was intended by CSS WG.  But I think appendix is a good idea.
15:20:54 <TabAtkins> Sounds good to me
15:21:11 <fantasai> astearns: So conclusion seems to be that we will update the draft to use the more relaxed syntax, and we will put the limitations we're removing from draft into an informative appendix
15:21:39 <fantasai> plinss: My main concern is putting stake in the heart of Option 3
15:21:48 <fantasai> ... and not going with that as the specced behavior
15:22:20 <fantasai> jensimmons: If you want to think about it that way you can, but I do not believe we're putting a stake in the heart of Option 3, I believe we're continuing to evolve Option 3 in the direction that authors want
15:22:30 <fantasai> ... but not going to to debate that semantic with you
15:22:44 <fantasai> plinss: I just want that ampersand is no longer required in certain situations
15:22:59 <fantasai> TabAtkins: yes, we are abandoning the spec text for that and going with the lookahead/reparse that was decribed in the issue
15:23:26 <fantasai> plinss: Desire to keep the ampersand behavior, it sounds like Safari might not implement the lookahead option, and I hope that's not the case
15:23:42 <fantasai> TabAtkins: not relevant for us to discuss Apple's shipping schedule, WG is deciding for the future
15:23:54 <fantasai> jensimmons: You should take nothing that I'm saying as anything about our plans or shipping schedules
15:24:03 <TabAtkins> Can we please resolve and stop talkingv sideways about things that aren't the issue
15:24:14 <fantasai> plinss: I'm interpreting that from your desire to keep this behavior in a spec somewhere
15:24:18 <fantasai> astearns: I think it's time to move on
15:24:32 <fantasai> astearns: We have a proposed resolution, any objections?
15:24:55 <fantasai> RESOLVED: Keep the current spec parsing behavior in an Appendix, update the spec to use the lookahead option
15:25:23 <fantasai> astearns: There are other parts of this issue, TabAtkins you have a long comment on the ways in which we're going to be able to loosen restrictions, would it be productive to go into details?
15:25:27 <fantasai> TabAtkins: sure
15:25:43 <fantasai> TabAtkins: Using the behavior described in the issue, where we first parse as declaration, see if it's valid, and then go back and parse as rule
15:25:52 <fantasai> ... is super flexible except for two restrictions on future syntax
15:26:18 <fantasai> TabAtkins: One restriction is that we never put a semicolon in the prelude of a rule; which is already the case for at-rules, which will end the block early
15:26:34 <fantasai> ... as long as we never put a semicolon as part of a selector we're good; and I doubt we'll ever want to do that
15:26:46 <fantasai> TabAtkins: The second is protecting against misparsing as a rule
15:27:05 <fantasai> ... rules can end earlier than a declaration: they go until a semicolon *or a {}-block*
15:27:26 <fantasai> ... If parse as a rule, then there could be content after the {} which gets parsed as a new item
15:27:48 <fantasai> ... to avoid that, if we ever do top-level {} in a property, we put it at the end
15:28:11 <fantasai> ... Ideally we put it as the whole property value, since that hits invalid selector as soon as you get to the ": {" combination
15:28:39 <fantasai> TabAtkins: If we adopt that future restriction, then we will have effectively future-compatible parsing
15:28:52 <fantasai> ... 1. No semicolons in selectors
15:29:03 <fantasai> ... 2. Nothing after {} in a declaration.
15:29:30 <fantasai> TabAtkins: We don't control custom properties, and you screw up a var() statement (which is the only thing that can be invalid in a declaration)
15:29:38 <fantasai> ... then could have some problem of it reparsing as a rule
15:30:29 <fantasai> TabAtkins: The fix for that is, if the parser sees something that looks like a custom property, it is guaranteed to parse as a declaration. We will not reparse as a rule
15:30:36 <fantasai> ... This avoids corner case of producing an unexpected parse
15:30:51 <fantasai> ... This does mean that you can't have a selector tag name that starts with --
15:30:56 <fantasai> ... but in HTML that's not a valid name anyway
15:31:28 <fantasai> ... in rare case that you need this, you can use the "wrap in an :is()" trick from Option 3
15:31:44 <fantasai> ... that's the one case where ppl might need to worry about it, and it would not be relevant to the Web only some weird esoteric language
15:31:48 <fantasai> plinss: You could escape the dash?
15:32:04 <fantasai> TabAtkins: no, because it'll still be an ident. Not based on raw text lookup
15:32:15 <astearns> ack fantasai
15:32:16 <fantasai> ... e.g. if you escape a custom (or not custom) property name, it's still recognized as such
15:32:31 <plinss> q+
15:32:39 <dbaron> fantasai: The first 2 make sense to me.  The last one... we had some discussions about custom selectors or something like that... will that interfere?
15:32:58 <fantasai> TabAtkins: No. We can't have custom selectors that are just an ident without a prefix anyway, because they will clash with type selectors (at a grammar leve)
15:33:04 <fantasai> ... so already not in a syntax space that we can get into
15:33:19 <astearns> ack plinss
15:33:34 <fantasai> plinss: In general, I'm happy with this. Just to confirm, you always try to parse as a declaration right?
15:33:37 <fantasai> TabAtkins: yes
15:33:58 <fantasai> plinss: Concern is if we add further symbols to selectors as combinators and/or start adding symbols to properties to do interesting tricks
15:34:11 <fantasai> ... do we have possibilities of collisions? I think we're okay?
15:34:29 <fantasai> TabAtkins: Depending what we do, possibility of clash exists, but in practice it's hard to design a syntax that would be both a valid declaration and a valid rule
15:34:36 <dino7> dino7 has joined #css
15:34:45 <fantasai> ... something to keep in minde as we design any new thing in property names
15:34:59 <fantasai> plinss: The real restriction is using braces in the property name part of the syntax?
15:35:04 <fantasai> ... though I don't see us doing that much
15:35:12 <fantasai> plinss: [missed too fast]
15:35:36 <fantasai> TabAtkins: If we never touch curly braces in properties, we have to be careful, but otherwise we're good with anything
15:35:39 <fantasai> astearns: Any other comments?
15:35:49 <gtalbot> gtalbot has joined #css
15:36:02 <fantasai> astearns: Are you porposing putting these future restrictions into the draft? Or just adjusting parsing
15:36:14 <fantasai> TabAtkins: These are restrictions we should document for us, maybe put it in the wiki
15:36:24 <fantasai> ... not relevant to authors or implementers
15:36:33 <fantasai> astearns: So we need resolutions on ???
15:36:49 <fantasai> TabAtkins: I think we resolved on those last week, but if you think we need a separate resolution that's fine
15:36:55 <fantasai> astearns: Happy to go with previous if that's sufficient
15:36:55 <miriam> present+
15:37:12 <astearns> ack fantasai
15:38:07 <fantasai> fantasai: I would like us to resolve on the restrictions we just discussed, and to put them in a <details> note in the spec
15:38:16 <fantasai> TabAtkins: sounds fine to me, would but it into the Syntax spec
15:38:25 <fantasai> astearns: ok, so in syntax spec, but linking back to nesting
15:38:40 <fantasai> astearns: Proposed that we document these restrictions on future synax in Syntax, and link back to Nesting. Objections?
15:39:35 <fantasai> RESOLVED: Document restrictions on future syntax in Syntax, linking back to Nesting: 1. No semicolons in selectors 2. Nothing after {} in a declaration. 3. --ident always kicks off declaration (not rule) parsing.
15:39:55 <github-bot> Subtopic: [css-nesting-1] consider dividing future selector syntax and future declaration syntax differently
15:40:26 <fantasai> TabAtkins: I think this one is moot given previous resolutions, but if dbaron has anything to discuss
15:40:29 <fantasai> dbaron: I'm fine with moot
15:40:35 <fantasai> astearns: Anyone else with concerns?
15:41:15 <dbaron> astearns: no change?
15:41:18 <fantasai> RESOLVED: Close as no longer relevant.
15:41:22 <dbaron> TabAtkins: changes already made in other issues
15:42:15 <github-bot> Subtopic: [css-nesting] Require `div&`, disallow `&div`, for Sass compat
15:43:01 <fantasai> TabAtkins: In previous version of Nesting, we relaxed restriction to starting with a tag selector in order to allow & at the front
15:43:13 <fantasai> ... which was required for previous parsing solutions
15:43:47 <fantasai> TabAtkins: SASS uses & as a textual substitution, so if you write &div, you're asking SASS to append the letters "div", so if your parent selector was ".foo" you get ".foodiv"
15:44:07 <fantasai> ... having this mismatch would be an annoying upgrade story for them, because this sort of concatenation is very heavily used
15:44:17 <fantasai> ... due to object-oriented class naming patterns
15:44:35 <fantasai> ... On the other hand, putting additional type selectors on the compound selector is exceedingly rare
15:44:46 <fantasai> ... she's heard the request only a few times
15:44:55 <fantasai> ... So this is very low priority for them
15:45:07 <fantasai> ... upshot of all this, is I suggest we remove the relaxed restriction that allows type selectors to not be at the front
15:45:30 <fantasai> ... restoring us to previous restriction, which requires the tag selector in front
15:45:39 <fantasai> ... then you can write div& but not &div
15:45:47 <fantasai> ... which protects that syntax space for SASS and related languages
15:46:02 <fantasai> TabAtkins: This also helps with some degree of migration
15:46:15 <fantasai> ... if they know it's an error, they can autocorrect to the right form
15:46:33 <fantasai> TabAtkins: I was initially uncertain of specifying this, if there is already usage of &div in Chrome or Safari
15:46:49 <fantasai> ... but apparently Chrome's implementation never relaxed that restriction so &div has been invalid this whole time
15:47:11 <fantasai> TabAtkins: so at least for Chrome, this isn't an issue, so making this invalid again would be fine
15:47:17 <fantasai> ... unclear about Safari I couldn't test
15:47:30 <fantasai> TabAtkins: So I propose to revert the syntax restrictions
15:47:37 <fantasai> ??: [missed]
15:47:49 <fantasai> ??: We don't have the same behavior as Chrome, so it would be a breaking change for us
15:48:16 <fantasai> astearns: Given that there is likely not that much content targetting Safari's current implementation, would you be ok with this change?
15:48:27 <fantasai> ??: Pretty sure there are zero websites targetting it, so won't break the Web
15:48:30 <oriol> q+
15:48:32 <fantasai> TabAtkins: Then I ask for a resolution
15:48:41 <dbaron> s/??/matthieu/
15:48:42 <fantasai> s/??/mattieu/
15:48:43 <fantasai> s/??/mattieu/
15:48:44 <astearns> ack oriol
15:48:44 <emilio> +1 to keep that restriction, fwiw on Firefox's impl I never implemented it either
15:49:10 <oriol> Lety me reconnect
15:49:27 <fantasai> jensimmons: Curious to know what miriam thinks about this issue
15:49:44 <fantasai> miriam: I think this is a good idea, for the reasons Tab listed
15:50:11 <fantasai> ... I am not on the internals of everything that Natalie is conerned about here, but was part of the conversation with Tab and agree this is the direction to go to minorly limit a problem
15:50:33 <astearns> ack oriol
15:50:56 <fantasai> oriol: I'm opposed to the restriction, but not clear to me how exactly it's helping. In SASS the behavior is something else, and ppl are using that behavior, if they switch to Nesting they will have to adapt somehow anyway
15:51:07 <dbaron> s/mattieu/matthieu/
15:51:08 <fantasai> ... I'm not sure whether it's invalid or it means something different, if it is that relevant to people
15:51:13 <dbaron> s/mattieu/matthieu/
15:51:30 <fantasai> TabAtkins: As much as possible, SASS tries not to interpret valid CSS differently as how browsers would interpret it
15:51:51 <fantasai> ... It is helpful if we put it as invalid syntax, so it is definitely not something that would mean something in the browser
15:52:16 <emilio> q+
15:52:20 <fantasai> ... It's not strictly necessary, because they'll have compat pain anyway, but a long-term goal here, is that as long as author is not using SASS-specific features, they want to emit native CSS in the future
15:52:37 <astearns> ack emilio
15:52:40 <fantasai> ... being certain about using CSS-compatible syntax or invalid syntax that is SASS-interpreted is a goal
15:52:54 <fantasai> emilio: If we ever expose the final selector somehow, it would be weird if this couldn't be serialized in anyway
15:52:59 <fantasai> ... so I support not allowing &div
15:53:19 <fantasai> emilio: In particular, if devtools wanted to show the final selector that this element matched, you want to see something useful
15:53:34 <fantasai> ... if you write &div, you can't just expand it
15:53:40 <fantasai> emilio: so I would prefer to avoid this special case
15:53:49 <fantasai> astearns: Other comments or conerns?
15:53:53 <fantasai> s/conerns/concerns/
15:54:44 <fantasai> TabAtkins: Proposed to remove relaxation of type selector rules, keep current rule that type selector must be first in a compound selector
15:54:49 <fantasai> astearns: objections?
15:54:57 <fantasai> RESOLVED: type selector remains required first; &div is invalid
15:55:24 <github-bot> Subtopic: [css-conditional-5][css-nesting-1] Feature detection for nesting
15:55:52 <fantasai> astearns: We have a feature-detection story, question is how to detect browsers that support nesting vs don't support nesting?
15:56:06 <dbaron> astearns: Is that what's remaining in this issue?
15:56:07 <fantasai> TabAtkins: unsure... someone else should take this
15:56:46 <fantasai> SebastianZ: We need some way to migrate and have fallbacks for old browsers
15:57:12 <fantasai> SebastianZ: so the question is how to allow feature-detection, and at the same time do it so that all the browsers don't fail completely
15:57:23 <ydaniv> ydaniv has joined #css
15:57:27 <fantasai> SebastianZ: Of course they don't support nesting, but we need some way to handle that case
15:57:40 <fantasai> ???: We need more than just selector(&)?
15:57:49 <dbaron> s/???/matthieu/
15:57:50 <astearns> s/???/matthieu/
15:58:00 <fantasai> SebastianZ: selector(&) does work, but it focuses on style rules. Doesn't target whether other rules can be nested, or media rules, or something else
15:58:45 <PaulG> PaulG has joined #css
15:58:45 <fantasai> astearns: Given that we have not much time yet, does it make sense to continue the discussion of this upgrade strategy in this issue, or should there be a separate issue just on the path we want authors to take when they don't know whether the browsers supports nesting or not?
15:58:49 <fantasai> SebastianZ: I think there's an issue targetting the author experience... not sure which one it was
15:59:13 <GameMaker> GameMaker has joined #css
15:59:15 <fantasai> astearns: Since this feature is titled Feature Detection, should we close this issue and find or create an issue about the author experience?
15:59:27 <fantasai> SebastianZ: Hard to say
15:59:42 <fantasai> SebastianZ: you want feature detection for author so that they can migrate to nesting, so they're both entangled
16:00:03 <fantasai> ACTION: astearns to find path forward for this author-experience issue, whether to continue with this issue or make a new one
16:00:16 <emeyer> emeyer has joined #css
16:00:38 <fantasai> dbaron, can I poke you about https://github.com/dbaron/wgmeeting-github-ircbot/issues/71 ? :)
16:00:48 <jfkthame> jfkthame has joined #css
16:01:47 <astearns> astearns has changed the topic to: Apr 19 agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0011.html
16:02:23 <futhark> futhark has joined #css
16:02:29 <emeyer> present+
16:02:37 <jensimmons> present+
16:02:38 <dbaron> Present+
16:02:38 <jfkthame> present+
16:02:41 <masonf> masonf has joined #css
16:02:49 <ydaniv> present+
16:03:20 <futhark> present+
16:03:24 <castastrophe> present+
16:03:29 <flackr> present+
16:03:36 <masonf> present+
16:03:39 <fantasai> Topic: Administrative
16:04:13 <fantasai> astearns: Agenda bashing?
16:04:28 <fantasai> fantasai: would like to discuss F2F planning after the call with whoever wants to stick around for a few more minutes
16:04:34 <alisonmaher> alisonmaher has joined #css
16:04:36 <alisonmaher> present+
16:04:37 <emeyer> Scribenick: emeyer
16:04:44 <dholbert> present+
16:05:07 <emeyer> astearns: Should we consider the topic Lea raised or wait for her?
16:05:16 <emeyer> TabAtkins: We should probably wait for Lea
16:05:36 <emeyer> astearns: All right, we’ll skip this week and get on next week’s agenda
16:05:47 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/8174
16:05:47 <github-bot> Topic: [selectors-4] Add pseudo-class to establish before-change style for css-transitions on new elements.
16:05:47 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8174.
16:06:11 <emeyer> flackr: We were looking at using a pseudo-class to establish a before-change style
16:06:27 <emilio> present+
16:06:39 <emeyer> …We’ve proposed `add-initial` (bikeshedding to come) that defines a block used for before-change styles
16:06:46 <vmpstr> present+
16:06:54 <emeyer> …This is implemented, working well, doesn’t have weird edge cases
16:07:02 <emeyer> …Tab nicely summarized all the semantics
16:07:29 <emeyer> TabAtkins: It’s `@initial` used whenever an element doesn’t have a before-change style
16:07:31 <fantasai> s/add-initial/@initial/
16:07:45 <emeyer> …In particular, it answers all the weird questions from doing this as a pseudo
16:07:53 <emeyer> …@rules behave a lot better
16:08:00 <emeyer> …This also works a lot better with nesting
16:08:13 <emeyer> …I’m good with this
16:08:30 <emeyer> astearns: Commetns or questions?
16:08:53 <emeyer> dbaron: Are there cases where y ou want to write both for @initial and for something else?
16:09:01 <emeyer> TabAtkins: Possibly but only incidentally
16:09:18 <emeyer> …Sometimes you’ll want to write so that normal style is the same as initial styles
16:09:33 <emeyer> …But with a different class you’ll want different stuff
16:09:48 <emeyer> …Doing it this way means you can’t easily combine them, you’d have to write the styles twice
16:10:05 <emeyer> dbaron: That’s my concern; I had a colleague who had to repeat styles
16:10:25 <dbaron> s/repeat styles/repeat styles to make the entry and exit transitions match/
16:10:29 <emeyer> flackr: I think that might be the common case if you want something to fade out when it goes away and fade in when coming back
16:10:47 <gtalbot> gtalbot has left #css
16:10:48 <emeyer> TabAtkins: One sets opacity 0 and another doing the same, yeah
16:10:49 <tantek> tantek has joined #css
16:11:03 <emeyer> flackr: Haven’t thought this deeply but we could consider… never mind
16:11:13 <emeyer> TabAtkins: Yeah, I couldn’t make that make sense either
16:11:38 <emeyer> astearns: Is this a blocking concern, dbaron?
16:11:51 <emeyer> dbaron: I think it’s something we should pay attention to
16:12:09 <emeyer> …The particular pattern I saw looked pretty ugly, but then the other proposals here also had significant issues
16:12:24 <emeyer> …We could maybe change the rules around this to ameliorate in some way
16:12:49 <tantek> RRSAgent, make logs public
16:12:50 <emeyer> TabAtkins: If we do pursue the mixin idea, we could write styles once in the mixin and call it from both spots
16:13:08 <emeyer> astearns: Any other discussion?
16:13:19 <emeyer> (silence)
16:13:58 <masonf> +1
16:13:58 <emeyer> astearns: Sounds like the proposal is to specify `@initial` as defined in this issue and open another issue about the duplication problems with entry and exit styles
16:14:03 <emeyer> …Objections?
16:14:14 <emeyer> RESOLVED: specify `@initial` as defined in this issue and open another issue about the duplication problems with entry and exit styles
16:14:27 <emeyer> flackr: There‘s also a question on the issue about the actual name
16:15:46 <tantek> present+
16:16:07 <emeyer> astearns: While this isn’t a keyframe, this is tied to animations
16:16:13 <emeyer> TabAtkins: Transitions, not animations
16:16:36 <emeyer> flackr: If you have an implicit `from` keyframe, it animates from there, not the initial style
16:16:55 <emeyer> TabAtkins: `@initial-style` is fairly reasonable
16:17:04 <emeyer> …It’s a little generic but not so generic it doesn’t mean anything
16:17:39 <emeyer> astearns: Would it be bad to make it longer for clarity?
16:17:50 <masonf> `@initial-state` maybe?
16:18:07 <emeyer> flackr: If we’re exploring long names, `@before-change` is very specific to what this is
16:18:15 <masonf> `before-change` is the same length as `initial-state`
16:18:16 <emeyer> …That’s what we call it in the spec
16:18:21 <emeyer> TabAtkins: Not opposed to that
16:18:37 <emeyer> …It’s weirder to puzzle out what it does, but it’s weirdness speaks to specilaized nature
16:18:43 <emeyer> s/it’s/its/
16:18:48 <emeyer> astearns: I like that
16:19:02 <masonf> s/its/it's
16:19:06 <emeyer> dbaron: One thing that bother me about before-change is that it omits it’s only for when the element appears
16:19:16 <fantasai> “before construction” ?
16:19:28 <emeyer> …Maybe replace `initial` with `start`
16:19:36 <masonf> `@starting-style`?
16:19:41 <fantasai> +1
16:19:56 <emeyer> TabAtkins: Maybe we should take bikeshedding back to issue; we need more percolation
16:20:06 <emeyer> fantasai: I like mason’s proposal
16:20:12 <miriam> +1
16:20:13 <emeyer> …`@starting-style`
16:20:28 <emeyer> astearns: Given we’re coming up with multiple good options, we should take it back to the issue
16:20:37 <emeyer> flackr: My concern is delaying too long over the name
16:20:55 <emeyer> fantasai: I think we shoudl conclude on another call but we could bikeshed in the issue
16:21:03 <emeyer> flackr: Sounds good
16:21:09 <emeyer> s/shoudl/should/
16:21:22 <fantasai> fantasai: And start with `@starting-style`, rather than `@initial`
16:21:25 <flackr> +1
16:21:26 <emeyer> fantasai: I suggest we start with `@starting-style` for now
16:21:42 <emeyer> astearns: Are you asking for a resolution?
16:21:53 <TabAtkins> +1
16:21:56 <emeyer> fantasai: Yes, that we call it that until bikeshedding is concluded
16:22:08 <masonf> +1
16:22:12 <emeyer> astearns: Any objections?
16:22:22 <emeyer> RESOLVED: start with `@starting-style`
16:23:10 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7795
16:23:10 <github-bot> Topic: [cssom-view] checkVisibility and filter:opacity(0)
16:23:10 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7795.
16:23:53 <emeyer> vmpstr: We’ve added `check-visibility()` which considers a few styles like opacity
16:24:09 <TabAtkins> q+
16:24:14 <emeyer> …If we’re considering that, why aren’t we considering `filter` opacity 0?
16:24:32 <emeyer> …It’s hard to do this, and it was commented if we have other filters that make things invisible
16:24:37 <emeyer> …I propose to close with no change
16:24:41 <astearns> ack TabAtkins
16:24:51 <emeyer> TabAtkins: I concur
16:25:01 <fantasai> +1 to close no change
16:25:02 <dbaron> +1
16:25:03 <emeyer> astearns: Any concerns here?
16:25:17 <emeyer> RESOLVED: close issue with no change
16:25:29 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/8259
16:25:30 <github-bot> Topic: [css-images-3] Define optimizeSpeed as nearest neighbor
16:25:30 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8259.
16:26:28 <emeyer> fantasai: We have SVG values that correspond to SVG keywords
16:26:41 <emeyer> …It was observed browsers might be able to use better algorithms
16:27:00 <emeyer> …Should optimizeSpeed be the same as crispEdges?
16:27:16 <emeyer> TabAtkins: These legacy values are only around because I’m reusing names from SVG
16:27:25 <emeyer> …As far as I know, no browser ever did anything with them
16:27:33 <emeyer> …Other renderers might, not sure
16:27:43 <emeyer> …For the web, it doesn’t seem like it matters what we map them to
16:27:51 <emeyer> …I do object to adding bespoke behavior for these values
16:28:06 <emeyer> …If we want to do something with nearest-neightbor, we should do that
16:28:24 <emeyer> …If we do want to do that later, it would be fine to swap mapping
16:28:36 <emeyer> …For now, what exact value we define isn’t important
16:28:43 <emeyer> …I suggest we close, no change
16:29:11 <emeyer> fantasai: I think it’s an okay state for now, but is risky in the long run
16:29:34 <emeyer> …If there are people who would want nearest-neighbor, maybe we should add a keyword specifically for that
16:29:50 <emeyer> TabAtkins: I’m happy to switch the alias over in that case, but don’t want to do anything special for it now
16:30:04 <emeyer> fantasai: Seem fine; do we need a `nearest-neightbor` keyword?
16:30:09 <emeyer> TabAtkins: That woul db e a different issue
16:30:42 <emeyer> astearns: Proposed resolution is close, no change for now; can discuss separately if we need `nearest-neighbor` or any other
16:30:58 <emeyer> …At that point we could discuss whether to change the alias for `optimizeSpeed`
16:31:07 <emeyer> astearns: Objections?
16:31:12 <emeyer> RESOLVED: close, no change
16:31:26 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/8266
16:31:26 <github-bot> Topic: [css-images] Define what happens when all image-set options are invalid
16:31:26 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8266.
16:31:33 <bkardell_> bkardell_ has joined #css
16:31:57 <emeyer> emilio: If you specify an invalid type that the UA doesn’t understand, we don’t have a good answer for what happens
16:32:05 <emeyer> …Does the UA try to load and then discard?
16:32:16 <emeyer> …Tab put in the spec we render an invalid image
16:32:43 <bkardell_> present+
16:32:48 <emeyer> …The difference is that if the type function ends up invalid, like say it’s PNG in the CSS but then serve a JPEG, it’s a problem
16:32:55 <emeyer> …I think what Tab put in the spec is fine
16:33:29 <emeyer> astearns: Proposed resolution is to accept what’s been added to the spec?
16:33:32 <argyle> argyle has joined #css
16:33:51 <emeyer> TabAtkins: More specifically, if there are no valid options, it rendered as an invalid image
16:33:53 <fantasai> +1
16:33:56 <emeyer> astearns: Objections?
16:34:07 <emeyer> RESOLVED: if there are no valid options, render as an invalid image
16:34:18 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7964
16:34:18 <github-bot> Topic: [css-fonts-4] Unclear serialisation of calc expressions in `@font-face` font-stretch/style/weight descriptors
16:34:18 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7964.
16:35:17 <emeyer> TabAtkins: Fundamental issue is that simplification rules for math functions refer to resolution stages
16:35:33 <emeyer> …Those don’t apply in descriptors
16:35:38 <emeyer> …So what are the rules for serialization, and do they match?
16:35:53 <emeyer> …Apple wants serialization to be the same as CSS properties, which makes sense
16:36:03 <emeyer> …Not sure if we’re compat-constrained or not
16:36:19 <emeyer> dbaron: The one thought I have is that descriptors seem a lot like specified values
16:36:21 <emeyer> TabAtkins: Agreed
16:36:26 <emeyer> emilio: Agreed
16:36:46 <emeyer> TabAtkins: I think it’s reasonable to say we treat things the same
16:36:59 <emeyer> astearns: We could resolve on that and see if anyone complains
16:38:03 <emeyer> TabAtkins: proposed resolution: math function simplifcation for descriptors as if they were specified properties, and descriptors with math functions use the same serialization rules as properties
16:39:17 <emeyer> RESOLVED: math function simplifcation for descriptors is as if they were specified properties, and descriptors with math functions use the specified-value serialization rules
16:39:35 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/8506
16:39:35 <github-bot> Topic: [css-ui] Consider removing slider-horizontal from <compat-auto>
16:39:35 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8506.
16:39:52 <emeyer> emilio: Firefox never supported this
16:40:10 <gtalbot> gtalbot has joined #css
16:40:21 <emeyer> …Recently, I found three keywords where there are problems in WPT
16:40:28 <emeyer> …Usage is pretty low
16:40:42 <emeyer> …We also have no compat issues about this
16:40:44 <masonf> q?
16:40:45 <masonf> q+
16:40:52 <astearns> ack masonf
16:41:00 <emeyer> masonf: We don’t object to this
16:41:29 <emeyer> astearns: What are we resolving?
16:41:53 <emeyer> emilio: Drop slider-horizontal, square-button, and push-button
16:42:09 <PaulG> q+
16:42:14 <astearns> ack PaulG
16:42:54 <emeyer> PaulG: slider-vertical has native semantics around orientation
16:43:10 <emeyer> …If there is usage, we should communicate that ARIA values need to be used
16:43:27 <masonf> q?
16:43:32 <emeyer> emilio: Right now, the spec says it does nothing special
16:44:01 <emeyer> dbaron: I don’t think there a history of appearance changing accessibility rules, is there?
16:44:32 <emeyer> PaulG: In Chromium, (scribe got lost)
16:44:49 <emeyer> dbaron: I don’t think the CSS `appearance` property affect accessibility
16:45:20 <emeyer> PaulG: I’m looking at the demo in the issue, in Chromium, the vertical slider renders with orientation: vertical that nothing else set
16:45:27 <emeyer> dbaron: That’s surprising to me
16:45:41 <dbaron> masonf: me too (but confirm it)
16:45:51 <bkardell_> Is it bad? Seems good?
16:46:44 <emeyer> PaulG: Concern is if it’s dropped, anyone depending on that orientation needs to know they need to replace that with ARIA
16:46:51 <dbaron> s/rules/roles/
16:46:58 <emeyer> astearns: Given that usage is very low, is this a big concern?
16:47:22 <emeyer> PaulG: This is in no way a reason to stop, but this is a concern APA will probably voice
16:47:39 <masonf> q?
16:47:46 <emeyer> …I’m guessing where this is used, understanding of accessibility is low
16:47:56 <emeyer> …I’ll help smooth that over with APA, I’d just like numbers
16:48:29 <emeyer> masonf: We’re speaking just about slider-horizontal, yes?  Not slider-vertical
16:48:43 <emeyer> …Is it an accessibility problem for horizontal?
16:49:00 <emeyer> PaulG: No, only concerned with vertical and that semantic meanings are conveyed in other ways
16:49:12 <emeyer> masonf: We should open an issue about vertical
16:49:27 <emeyer> …I think we’re okay horizontal, but need to discuss more about vertical
16:49:43 <emeyer> astearns: So proposed resolution is to remove slider-horizontal, square-button, and push-button
16:49:55 <emeyer> PaulG: I might need to check push-button
16:50:12 <emeyer> …Does ARIA pressed get added?
16:50:46 <emeyer> astearns: What if we resolve to do the removal, then Paul, can you open an issue on slider-vertical and push-button on possible ARIA concerns?
16:50:50 <emeyer> PaulG: Yes
16:51:01 <dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_slider.cc;l=47-83;drc=5a252fef36aced8857912a7eba43dad5590cb54d
16:51:36 <emeyer> RESOLVED: remove slider-horizontal, square-button, and push-button from <compat-auto>; PaulG will open an issue about ARIA roles and concerns about slider-vertical and push-button
16:51:54 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7745
16:51:54 <github-bot> Topic: [css-scroll-anchoring] Consider adding an opt-in way of avoiding scroll anchoring suppressions
16:51:54 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7745.
16:52:23 <emeyer> emilio: Scroll anchoring spec has a bunch of heuristics about when to apply or stop applying scroll anchoring
16:52:52 <emeyer> …We found some cases where pages rely on scroll anchoring to happen, and depending on timing of style changes, page may misbehave
16:53:00 <emeyer> …When you fire scroll events
16:53:16 <emeyer> …Seems to be no way for devs to say “I really really want scroll anchoring to happen”
16:53:54 <emeyer> …I think adding a way to opt into ignoring suppressions and in this scrolling, we’re going to do anchoring regardless of other things
16:54:10 <emeyer> …I think it’s moderately trivial to implement, but is it a good idea?  Or reason it’s a bad idea?
16:54:36 <emeyer> astearns: Any thoughts on adding a way to require scroll anchoring?
16:54:56 <emeyer> (silence)
16:55:06 <emeyer> astearns: Shoudl we add an `always` value and see how it goes?
16:55:28 <flackr> q+
16:55:37 <emeyer> emilio: If there’s no anchor you don’t do anchoring, so maybe that name doesn’t quite make sense
16:55:44 <astearns> ack flackr
16:55:46 <emeyer> flackr: What is `always` specified on?
16:56:04 <emeyer> emilio: overflow-anchor works on the scroll container, I believe
16:56:24 <emeyer> flackr: overflow-anchor I thought is applied to any element to prevent any element within to be selected as an achor
16:56:25 <SebastianZ> q+
16:56:46 <emeyer> emilio: Right, I guess should always have an effect on non-scroll containers
16:57:02 <emeyer> flackr: I was wondering if `always` would be a way of saying “this is the element to which I want to anchor”
16:57:21 <emeyer> emilio: Then we’d need another way to specify that an anchor should never lose the anchor even if there are suppressions
16:57:32 <emeyer> flackr: What do you anchor to?
16:57:38 <emeyer> emilio: Whatever you were anchoring to before
16:57:59 <emeyer> …What the suppression triggers do is prevent going back
16:58:12 <emeyer> flackr: The suppression trigger rpevent selecting an anchor within a given subtree
16:58:24 <emeyer> …You need to know which element should stay in the same position after anchoring
16:58:34 <emeyer> emilio: I’m not proposing to change anchor selection
16:58:53 <emeyer> …In my head, suppression triggers don’t affect anchor selection
16:59:04 <emeyer> flackr: Are we talking about overflow-anchor?
16:59:25 <emeyer> emilio: What I’m talking about it, the spec has heuristics that don’t affect anchor selection but do affect adjustments
16:59:43 <emeyer> …overflow-anchor seemed an obvious property to add this exception
17:00:07 <emeyer> flackr: I know anchor selection is a big problem and maybe overflow-anchor: always means you must selecto something in here as the anchor
17:00:19 <emeyer> emilio: This seems like an orthogonal problem
17:00:46 <emeyer> …I’m just trying to bypass the heuristics
17:01:02 <astearns> ack SebastianZ
17:01:33 <emeyer> SebastianZ: Quick note: overflow-anchor is targeting elements while something is targeting the scroll container, os maybe it should be another property in the end
17:01:50 <emeyer> astearns: Let’s take this back to the issue and come up with a proposed solution that can be agreed upon there
17:02:12 <emeyer> …Maybe we can get this and the linked issue on a near-future call
17:02:31 <emeyer> astearns: That’s time; anyone who wants to stay to talk about a summer FTF, please stay on
17:02:38 <emeyer> Topic: end of meeting
17:02:52 <TabAtkins> I'm around
17:03:34 <dbaron> (I've only been to one prior W3C face-to-face at a beach!)
17:04:28 <emeyer> emeyer has left #css
17:04:34 <emeyer> emeyer has joined #css
17:06:13 <changseo_> changseo_ has joined #css
17:07:20 <gtalbot> gtalbot has left #css
17:07:22 <TabAtkins> My only input is that G did the last meeting and if like someone else to fund this one
17:14:38 <TabAtkins> I think our limits for G are still just "keep it low, almost certainly in-country"
17:17:30 <dbaron> https://www.w3.org/2004/CDF/Group/meetings/2006/Jan-Sydney/
17:19:03 <TabAtkins> Me too, I have a meeting starting now
17:25:10 <emeyer> emeyer has left #css
17:44:58 <changseok> changseok has joined #css
18:01:24 <changseok> changseok has joined #css
18:03:51 <changseok> changseok has joined #css
18:03:55 <changseok> changseok has joined #css
18:08:15 <changseok> changseok has joined #css
18:39:02 <kashirin> kashirin has left #css
20:06:22 <Zakim> Zakim has left #css
23:17:16 <danial19951103> danial19951103 has joined #css
23:44:02 <coool> coool has joined #css