W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] [css-values] String concatentation (#542)

From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
Date: Fri, 30 Oct 2020 21:06:00 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-719799408-1604091959-sysbot+gh@w3.org>
> Not sure how `innerText` demonstrates the difference between "text" and "string", since there's no `innerString`. Also note that `innerText` was never the output of a rigorous consensus-driven process, but a Microsoft extension that was later standardized to pave the cowpaths.
> Do note that in spreadsheets, it's a [`text()` function that converts to a string](https://support.google.com/docs/answer/3094139?hl=en).
In spreadsheets and in other places, yes. In the web, my connotation of the word 'text' is more about text that is accessible to users (like `innerText` and text nodes) or about encoding/decoding, while `string` is usually neutral about its content.
I don't totally object to `text`, but saying that e.g. `JSON.stringify` and `Object.toString` are closer to what this function does than `TextEncoder`, `createTextNode` and `innerText`.

> I don't think adding string concatenation on a case by case basis is a good idea at all. It makes each individual property more complicated, it makes the language less consistent (which properties support concatenation and which don't?) and adds overhead to learning each property, since each property does concatenation differently (lack of internal consistency). Also it would mean that authors need to wait for the full standards lifecycle (proposal + draft + implementation + test) for **every single concatenation use case** that we did not foresee early on.> 

I'm not suggesting to add concatenation on a case by case basis, but rather attempt to solve the problems that require concatenation in a case-by-base basis, without using strings if possible (e.g. what we're doing with paths).

> Also note that `font-family` doesn't support concatenation. If you have a variable with `"Times"` and another one with `" New Roman"`, you cannot turn them into a single font family by just placing them next to each other. The only property that currently supports actual concatenation is `content`.

This is where I think this feature might become more powerful than we realize, and can change CSS and the web in unpredictable ways.

For example:

- you could start to be able to write full SVGs with CSS custom properties and inheritance and concatenate them in a `data:` URI.

- If you have a font used somewhere, you wouldn't be able to statically analyze which stylesheet it came from, as it might be a concatenation of many CSS properties, inheritances and `calc`s.

- I can see how people would start creating CSS uglifiers, that turn readable CSS into CSS that you can't understand with a whole bunch of variable-concatenated URLs, background SVGs, font-families, and clip-paths.

I'm not against any of the above, but I think that we should give them a consideration. This feature enables a lot more than meets the eye.

GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/542#issuecomment-719799408 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 30 October 2020 21:06:03 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC