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

Re: [css-values-4] String concatenation

From: François REMY <francois.remy.dev@outlook.com>
Date: Sun, 20 Jul 2014 14:33:56 +0200
Message-ID: <DUB130-DS21D540FF0B5EB7D14F2EE3A5F30@phx.gbl>
To: "Sylvain Galineau" <galineau@adobe.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Lea Verou" <lea@verou.me>, <www-style@w3.org>
>>> 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.
>> I'll admit I'm scratching my head over this one. Concatenating strings is 
>> a
>> fringe use case on a layout system like CSS, while adding numbers is
>> something really common. Optimizing one and not the other [1] looks to be 
>> a
>> huge prioritization mistake to me. If mathematics are not worth more than 
>> a
>> "calc" function, I see no reason explaining string concatenation would be
>> worth an inline syntax.

> [Sylvain Galineau:]
> I'm sorry, this isn't a good argument; that
> we give the wrong priority to something is
> no reason to give no priority to something
> else. (Assuming there was a wrong
> prioritization to begin with).

Not sure if my point went through, but what I meant is not that string 
concatenation should not be considered, but that using the bare bone "+" 
symbol for it was looking odd to me considering others and more frequent use 
cases of the "+" symbol require a wrapping.

> The decision and the design should be based
> on use-cases; in the quoted IRC thread Lea
> mentions using attr() in url() being useful for
> things like data URIs.

I agree.

>[Tab Atkins:]
>Math uses a number of symbols that are already used by CSS for various
>things; the + sign is used to start numbers, - is used to start
>numbers and in the middle of idents, / is occasionally used as a
>second-level separator.  * is the only character that wasn't already
>taken by something, and it's used so often as a "wildcard" (such as
>its current use in Selectors) that I give decent odds we use it for
>*something* in a CSS value eventually.
>Thus, wrapping math in a context-indicator like calc() helps us
>disambiguate all of those things.  However, I don't see any reason
>that + is ambiguous outside of numbers, and I don't see us using it in
>directly as a CSS value either, so it's safe to use it nakedly for
>> PS: I also believe it would be a first (in CSS) that generic tokens can 
>> be
>> combined together using a non-whitespace separator but no grouping at 
>> all.
>> That looks strange to me.
>Correct, it would be a first.

Well, it is not because we can that we should.

That being said, I think you both know that I'm just trying to share my 
thoughts here (i.e. that I would prefer a more generic "string()" or "str()" 
function which would allow to concat string values and possibly other very 
common string operations [1] to the bare bone "+" option [2]), but that's 
just a FWIW, as usual. All of this is no big deal to me, I was just trying 
to feed the discussion ;-)


[1] Sample:

    #selector { --data-uri: str(--base-uri "/" attr(data-uri)) }

We could even allow substr() right from the str() function like so:

    str("abc" 0 1 "abc" 1 "d") == "abcd"

[2] Odd-looking samples:

    #selector { content: "a" "b" "c" } // already valid
    #selector { grid-template: " a a " + " c " " b b c " } // allowed by 
this proposal, but really hard to read
Received on Sunday, 20 July 2014 12:33:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:44 UTC