- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 Oct 2021 11:48:42 +0000
- To: public-css-archive@w3.org
> There is `string()` function here: [w3.org/TR/css-gcpm-3/#using-named-strings](https://www.w3.org/TR/css-gcpm-3/#using-named-strings). > > Some printing tools have already [implemented](http://www.princexml.com/doc/paged/#content-copying-text) the behaviour from that working draft. I believe it's not really a good idea to have some new `string()` meaning. But it will be awesome to have a concatenating function named like `text()` or `concat()`. If we do decide that `string()` is a better option, I don't think this conflict makes it a dealbreaker, given that no browser has implemented this. Print formatters are like preprocessors in the sense that they are upgraded explicitly and run explicitly, so they *can* deal with a migration. They could even detect these cases and print out a warning, since the ident used in this function needs to be defined somewhere else via `string-set`. I think we should name it `string()` and rename the GCPM one to `string-get()`, which complements `string-set` nicely. [I was against `string()`](https://github.com/w3c/csswg-drafts/issues/542#issuecomment-383728441) in 2018 when we started discussing this, because I felt CSS authors would not necessarily understand what strings are. However, `@property` brings CSS types front and center, so CSS authors *need* to become familiar with the concept of strings anyway, so calling this function `text()` or whatever other things is doing them a disservice. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/542#issuecomment-939283883 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 9 October 2021 11:48:44 UTC