Re: [css-variables] ...let's change the syntax

On Tue, Mar 18, 2014 at 12:10 PM, Brian Kardell <bkardell@gmail.com> wrote:
>
>
>
> On Tue, Mar 18, 2014 at 3:01 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>>
>> On Tue, Mar 18, 2014 at 11:38 AM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>> > On Tue, Mar 18, 2014 at 11:29 AM, Andrew Fedoniouk
>> > <news@terrainformatica.com> wrote:
>> >> On Tue, Mar 18, 2014 at 10:55 AM, Tab Atkins Jr. <jackalmage@gmail.com>
>> >> wrote:
>> >>> That's literally the exact opposite of the intention that led me to
>> >>> start this thread.  I'm trying to make custom properties and variables
>> >>> *less* connected, not more.
>> >>>
>> >>
>> >> If they are not variables the let's use const() then
>> >>
>> >> p {
>> >>        const(company-color-1): green;
>> >>        background-color: const(company-color-1);
>> >>    }
>> >>
>> >> Or some as such.
>> >
>> > You don't seem to understand what I meant when I said that's the exact
>> > opposite of why I started the thread, because this suggestion is
>> > *still* the exact opposite.
>> >
>> >> The main goal as far as I understand is to separate standard
>> >> properties namespace from
>> >> custom ones. The only strict way of doing this in existing CSS syntax
>> >> constructs is
>> >> function notation. All these '-' and '_' tricks are really palliatives.
>> >
>> > Separating the namespace out is already done - the current spec's use
>> > of a "var-" prefix accomplishes that.  This thread is meant to explore
>> > alternatives that would mesh better with the *other* author-custom
>> > things getting added, which don't have any connection to var().
>> >
>>
>> considering that we already have things like `white-space: ...`  etc.
>> that 'var-something' is also quite an ugly palliative.
>>
>> All programming languages that have well thought syntax design
>> have special means for strict namespace separation and its use.
>>
>> I really don't see why CSS shall use hacks instead of real and stable
>> on long run solutions.
>>
>> Your proposal as far as I understand it:
>>
>> p {
>>         company_color_1: green;
>>         background-color: company_color_1;
>>         /* or (I am not sure which one is correct) */
>>         background-color: prop(company_color_1);
>>     }
>>
>> against this one:
>>
>> p {
>>         const(company-color-1): green;
>>         background-color: const(company-color-1);
>>     }
>>
>> I do not see any principal differences except of robust namespace
>> separation.
>>
>> --
>> Andrew Fedoniouk.
>>
>> http://terrainformatica.com
>>
>
> Custom pseduo-classes (filters/predicates) are another proposal, as are
> custom media queries.  How would you write them?  With this in mind?  The
> aim is to align the custom things in precisely the same kind of way that
> vendor extensions work today -- it's pretty much the same whether it's a
> vendor property, function, value, pseudo-class, pseduo-element - whatever.
> Also, they do not require significant changes to CSS parser, things authors
> already know, etc.
>
>

Vendor extensions, values and property names are not anyhow different
from standard namespace from particular UA perspective.
Internally they are treated by the UA as any other standard property/values.

But here we are speaking about quite different situation:

By having some token parsed UA shall be able to
decide if that token is user's defined one or standard one.

If internal UA implementation would allow to parse and
store any non-recognized property/value as any other
property then conceptually we can declare:
"any property that UA does not recognize shall be
stored and be accessible through CSSOM and
is able to be used through prop(name) on the right
side of property declaration".

That is ultimate solution that does not impose limitations
like "starts-with-magic",  "end-with-magic" or "has-magic-inside"

But it appears that UAs require strict
namespace separation as custom properties are treated
significantly different internally.
In this case the only reliable option in CSS notation is
function notation that may conceptually support different
naming schemas. For example:

/* with explicit namespace: */
const(jquery-ui, dialog-caption-background ): #F00;
/* in default namespace */
const(company_color_1 ): #F00;

Same should apply to var()'iables, etc. I believe.

That will be strong and reliable foundation for now
and the future. IMO of course.

-- 
Andrew Fedoniouk.

http://terrainformatica.com


> --
> Brian Kardell :: @briankardell :: hitchjs.com

Received on Tuesday, 18 March 2014 19:51:07 UTC