W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-values-4] String concatenation

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 17 Jul 2014 10:35:33 -0700
Message-ID: <CAAWBYDCLDpo71i4CAYUAr7Eq9kxpPvjoMb5+VfNriK9r+O=Hag@mail.gmail.com>
To: Lea Verou <lea@verou.me>
Cc: www-style list <www-style@w3.org>
On Wed, Jul 16, 2014 at 10:50 AM, Lea Verou <lea@verou.me> wrote:
> We just had a discussion with Tab and fantasai in #css about adding string concatentation to CSS, either through a concat() function, or a plus (+) operator. Here’s a transcript, heavily edited for readability:

I'm in favor of adding something like this, as we add more things that
can validly produce parts of a string you want to display (attr() and
var() are the big examples so far), and more things that can take
strings.  (Especially now that url() has been shifted into being a
function that takes a <string>, so you could build urls dynamically
from attr() or var() and that sounds pretty cool.)

I'm weakly in favor of a concat() function, but given that we already
have math relegated to the calc() function, I don't think I'm opposed
to a naked + character doing string concatenation, as it won't be
ambiguous.  It would need to be strict about its types; that is,
actually requires <string> values on either side, but I think that's
just fine.

We'd basically just define that "<string> '+' <string>" is a <string>
for grammar purposes, no different from defining that concat(<string>,
<string>) is a <string>.

I'm opposed to forcing this to handle a vastly more generic expression
language: XPath is effectively dead on the web, we're already looking
at JS-backed functions for CSS, and creating a new expression language
is just right out.  We should focus on solving specific use-cases that
we can do well with native syntax, and assume that JS-backed functions
can fill in the rest.

~TJ
Received on Thursday, 17 July 2014 17:36:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC