Re: [css-values-4] String concatenation

>>> 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
>strings.
>
>> 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 ;-)

François

---------------------------------------------
[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