Re: [css-values-4] String concatenation

On Sat, Jul 19, 2014 at 4:21 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> 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.

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.

~TJ

Received on Saturday, 19 July 2014 21:42:54 UTC