Re: [css4-color] @color Custom Color Keywords

On Thu, Sep 16, 2010 at 1:36 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> Well, sure.  The point is, though, that @font-face doesn't define
>> something that can just be substituted into a property.  It defines
>> something special in CSS.  Variables just get substituted where they
>> are used.
>
> 'The point is' that it *is* a substitution for a custom data type for
> one particular property. It doesn't make a lot of sense to plug a font
> descriptor anywhere other than through font-family but that doesn't make
> it any less of a name-based substitution. Extending the pattern to another
> data type is thus not at all illogical.
>
> Except that this one plugs in a lot of places and the proposal naturally
> takes advantage of the extra level of indirection to add all kinds of new
> capabilities. Which may create its own problems but I like the idea of
> extending existing data types into richer objects.

Fair enough.  Nothing wrong with discussing an enrichment of a value
type.  It's just conceptually different from variables, at least to
me.  ^_^


>> > But I agree that addressing variables in general seems more
>> reasonable
>> > than making something up for colors alone.
>> >
>> > Although in fairness these look more like brushes than colors. Which
>> may
>> > be of value in its own right.
>>
>> I agree; I used the term "paint servers", but overall the <image>
>> concept captures all of this, and it's different than the <color>
>> concept (though you can upgrade a <color> into an <image>).
>
> Right. While the desire to 'solve' variables generally means this proposal
> should depend on a Variables module for its syntax, I'd rather talk about
> the capabilities and use-cases being suggested.
>
> So let's keep the generic variable syntax concern separate from the ability
> to define complex color/brush objects.

Cool.  So, on the issue of brushes.  I don't personally see much in
this particular proposal that I like.  It seems to have two features
in it:

1. Color fallback.  Being able to do indirect color-fallback is
potentially nice, but it's just a convenience (you can just do the
multiple-copies-of-the-property-with-different-syntaxes thing right
now), and I don't think this is a space that will be extended very
often.  Images are a different story; our general roadmap points to
extending <image> quite a bit, from images to elements to filters.
That's why we specify an image fallback ability through the image()
function.

2. Different values for different properties, transparently.  This
part really bothers me, because it feels like indirection for no
reason, and could result in a ton of confusion.  I expect a given
token to mean the same thing wherever I use it (assuming, you know,
that it's in the same basic token-space).  Using "color:mycolor" and
"background:mycolor" and getting two vastly different results would be
*crazy*.

~TJ

Received on Thursday, 16 September 2010 21:11:36 UTC