IRC log of css on 2023-04-19
Timestamps are in UTC.
- 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