- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Oct 2018 16:49:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Serialize all keyframe names as strings`, and agreed to the following: * `RESOLVED: serialize all keyframes as identifiers` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Serialize all keyframe names as strings<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2435<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/2435<br> <dael> fantasai: Question about...as we were going through c omputed values do we need to preserve a distinction between animation names that are strings and ones that are identifies<br> <dael> fantasai: You can use either for keyframes<br> <dael> fantasai: Main issue afaict is we can't serialize things as strings. They have to fundimentally be identifiers. One case we can't treat them to compute as the same there's CSS-wide identifiers like 'none' where if you wanted to name your animation that you can't refer to it in the property<br> <dael> fantasai: I don't think it's an issue.<br> <dael> fantasai: Nice if we didn't have to maintain the difference<br> <dael> myles_: Web compat risk?<br> <Rossen_> 'auto'<br> <dael> fantasai: If someone relies o n web animation name as 'initial' 'inherit' or 'none' yes. Otherwise no.<br> <dael> Rossen_: Any other concerns, comments, suggestions?<br> <dael> Rossen_: Objections?<br> <dael> fantasai: Proposal is serialize all keyframes as identifiers<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: serialize all keyframes as identifiers<br> <dael> dbaron: Somethinggs wouldn't round trip?<br> <dael> fantasai: CSS wide things. I propose we make them invalid and that's why they don't round trip.<br> <dael> dbaron: Is someone volunteering to change first?<br> <dael> Rossen_: I don't hear any. Are you dbaron ?<br> <dael> dbaron: Not particularly<br> <dael> fantasai: I believe current behavior was a recent change. 2016.<br> <dael> fantasai: Before 2016 you could not have a keyframe name that is a string. That was a webcompat problem because webkit supported a string in that position as animation name. We changed to allow strings or idents but decided to keep them distinct. Only reason is if you have 'initial' or one of those values.<br> <dael> fantasai: It's r eally about will wemaintain that if you put in a string or an ident both end up as an ident<br> <dael> fremy: We still don't support strings in Edge. If someone is using 'none' they're doubly failing. I don't feel like making the change is end of the world<br> <dael> dbaron: Other question; are you proposing this for values of prop, @keyframes or both<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/118<br> <dael> fantasai: Anywhere accepting a string as an animation name.<br> <dael> fantasai: Proposal is everywhere issue #118 says we can accept a string we treat it at parse time as an ident<br> <dael> myles_: Do we need a rule for idents that aren't 'auto' and the list?<br> <dael> fantasai: Have that rule already.<br> <fantasai> https://www.w3.org/TR/css-values-3/#custom-idents<br> <dael> fremy: Yes, because you need it for font-family<br> <dbaron> font-family is extra-weird<br> <dael> Rossen_: Still not hearing reason to change resolution<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2435#issuecomment-428646888 using your GitHub account
Received on Wednesday, 10 October 2018 16:49:33 UTC