- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Oct 2025 16:20:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom] Always return escaped idents?`, and agreed to the following: * `RESOLVED: all new OM attributes will use CSS parsing, see how much we can apply to other things` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> emilio: we feel pretty inconsistent about when cssom returns escaped or unescaped idents<br> <kbabbitt> ... tricky thing here is that if something is only an ident, it seems more convenient to return unescaped thing<br> <kbabbitt> ... but we 've had cases where something that used to be a simple syntax, or can be a mix of them, like font-face family getter and setter, can pass quoted things using css syntax or idents<br> <kbabbitt> ... in general I have a slight preference for always returning css syntax if we can get away with it<br> <kbabbitt> ... oriol had different thoughts, TabAtkins was arguing for a middle ground where we do unescaped thing if it's ?, css syntax for the rest<br> <kbabbitt> ... that's fine but we see cases where we expand to lists of things, that broke the css parser<br> <kbabbitt> ... mypreference is to always escape<br> <kbabbitt> TabAtkins: I am okay changing anything that takes literal string today to be a css processed string<br> <kbabbitt> ... so that it would be processed<br> <kbabbitt> ... and I think that's probably fine and safe<br> <kbabbitt> ... just want to make sure we don't do something incoherent like serialize a css escape for a property that doesn't understand it<br> <kbabbitt> ... so long as they roundtrip I'm happy<br> <kbabbitt> emilio: ok so we need a comprehensive list<br> <oriol> q+<br> <kbabbitt> ... I'm fine with taking that as a resolution and can take an action item for concrete changes<br> <kbabbitt> astearns: resolution would be...<br> <kbabbitt> emilio: do the css escape thing...<br> <astearns> ack oriol<br> <kbabbitt> astearns: do the new thing for new properties, see where we can apply to old props<br> <kbabbitt> oriol: in the issue I was arguing more for providing literal string instead of css syntax<br> <kbabbitt> ... in a few places we have expanded syntax to add some identifiersd<br> <kbabbitt> .... I guess I'm fine with this resolution of adding it for new things and then consider for old things one-by-one<br> <kbabbitt> ... would like to see a list of that but I'm fine<br> <kbabbitt> astearns: what is the exact resolution?<br> <emilio> Escape all new CSS ident like strings exposed in CSSOM, look at existing precedent and try to change to that<br> <kbabbitt> TabAtkins: pending a full review of all the OM attributes that take idents that need to be changed to use CSS processing, we plan to make all OM attributes use CSS parsing and thus also serialize with escapes when read<br> <kbabbitt> astearns: we are resolving that all new OM attributes will use CSS parsing<br> <kbabbitt> ... and we will see how much we can apply that to other things<br> <kbabbitt> TabAtkins: sounds fine<br> <kbabbitt> astearns: objections?<br> <kbabbitt> RESOLVED: all new OM attributes will use CSS parsing, see how much we can apply to other things<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12258#issuecomment-3357161476 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 October 2025 16:20:45 UTC