- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Mar 2024 17:26:00 +0000
- To: public-css-archive@w3.org
@drott said: > I suggest > > * to freeze in the `<font-format>` production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the `<font-format>` production). > > * to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned. > > * to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax. @astearns said: > The remaining question is whether format() should accept keywords in addition to strings, as WebKit and one of the spec examples does. I am seeing suggestions here to only allow strings. @litherum would WebKit be OK with making this change? to which @litherum responded > I don't see any reason to forbid the idents, and they seem very natural from an authoring point-of-view... > > "format(opentype)" seems natural... So it seems that the current proposal is to allow setting with either a string or a keyword? And then @fantasai said > * If strings are the most backwards-compatible syntax, then we must serialize as strings, not as keywords. Which is also what we [resolved on](https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-971823790) And this implies we need to mint new strings for any formats that don't already have them. Before I go making edits, does that all seem correct? -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328#issuecomment-2013124814 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 March 2024 17:26:01 UTC