RE: CSS Variables

Actually, I think your lack of concern is my worry. Were
vendor-prefixed feature intended for production use ? No.
But in the real world, they are. (And not just border-radius).
It did not happen overnight; for a long time, that knowledge
was arcane and somewhat limited. Not anymore. I do not,
as of yet, see a reason to believe that this process avoids this
outcome in the long run.

It's one thing if one has to know about, and deal with, individual
nightlies. One can argue this constitutes a barrier to entry. Or,
in IE's case, that you have to use bits with no UI, address bar,
back button etc.

It's another if all the developer has to do is do a one time opt-in
and have said newfangled features pushed to them regularly and
nearly silently. This imo increases the odds that over time Joe Author
- whom you can count on to be perfectly confident in his own
judgment and abilities - will use said features on his blog or home
page to add some pizzaz and show off. And he will tell his peeps to
subscribe to the dev channel to get the new and shiny.

Eventually, the rest of us will get bug reports that will be harder to
resolve than they are now as the only clue something Chrome-specific
is going on will be the investigator's knowledge of what CSS is experimental.
(Or, heaven forbid, which CSS is experimental in which browser...)

Note that I fully support the general goal and motives here. They're good.
Not so confident it'll work beyond the short term.

Last, I suspect being able to turn these features on/off in the stylesheet
would help your debugging too.

This being said, I won't add more in this thread. It's a separate discussion
from CSS Variables.




From: Alex Russell [mailto:slightlyoff@google.com]
Sent: Wednesday, February 09, 2011 12:06 PM
To: Sylvain Galineau
Cc: Boris Zbarsky; Tab Atkins Jr.; Daniel Glazman; www-style list
Subject: Re: CSS Variables

On Wed, Feb 9, 2011 at 9:37 AM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote:
[Boris Zbarsky:]
> The idea is to not put the experimental features out to a wide testing
> audience, thus limiting their use to experimental, non-production
> situations (because they will only work in browsers used by a few hundred
> thousand people at the most).
>
> This setup gives authors a chance to try the feature out and report
> feedback without having to deal with pages that actually depend on the
> feature.
So what I am missing is that these do not make it into public releases,
Betas and other bits generally downloaded by large populations so that
web authors cannot rely on them in their pages ?

In the case of IE, Previews are actually downloaded by large samples
but I'd assume they qualify since they have no chrome and really
targeted at developers. What would be the vehicle for Firefox ?

I'm still not quite sure I like the idea of releasing experimental features
completely unmarked as such - i.e. they look, smell and act like 'real'
features - and then pull them out later. I would suggest some kind of
explicit opt-in in the stylesheet letting the author declare 'yes, turn
on the experimental stuff for browser X'.

The explicit opt-in is the Dev channel restriction, but we've considered something like an "about:flags" toggle until things are more broadly agreed. In either case, no developer is going to be able to target a sizable population of users with these experimental features so long as the dev-channel restriction is in place, meaning the fear of it "leaking out" into the public web isn't really a problem.

At a minimum it'd help spot the
problem when such pages make it to the public web and someone reports a bug
against them (you can count on that happening).