RE: CSS Variables

> From: Jon Rimmer [mailto:jon.rimmer@gmail.com]
> Sent: Wednesday, February 09, 2011 2:21 PM
> To: Sylvain Galineau
> Cc: Boris Zbarsky; Tab Atkins Jr.; Daniel Glazman; www-style list
> Subject: Re: CSS Variables
> 
> On 9 February 2011 17:37, Sylvain Galineau <sylvaing@microsoft.com> wrote:
> >
> > 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 ?
> 
> For IE, would Microsoft's HTML5 labs (
> http://html5labs.interoperabilitybridges.com/ ) initiative not be a better
> place to put such experimental and exploratory work, if possible? That way
> it could be run separately from the actual IE release track. The developer
> previews seem more suited to work that is an implementation of a stable
> standard, that is planned to go into a release. Whereas, variables are far
> from that point at the moment.

To be discussed at a future date. This was not intended as a plan or a statement 
of intent, just an example.

> 
> Having read what you said in your other reply to this thread, I'm slightly
> confused. You seem to be in favour of some kind of explicit opt-in within
> the stylesheet for experimental features, but then you point out that this
> hasn't prevented vendor prefixed properties from becoming adopted in
> mainstream CSS development.

Simple: I am assuming these things can in fact leak over time. If so, I want
the stylesheet to reflect what is going on, just as they do today with all
those vendor prefixes. Today, I can look at a stylesheet and immediately see 
whether experimental features are being used, and which are being used. As much 
as we all love to hate vendor prefixes, I don't find that to be a bug day-to-day.
It's very useful information. And because I think such things will tend towards
leaking eventually, I believe removing vendor prefixes entirely could make our 
lives harder.

As Chrome has imo the lowest barrier to using the latest code (which is fine btw)
their dropping prefixes entirely for new features seems more likely to result in 
unintended consequences.  (I may still be misunderstanding the plan here, btw; see
below).

[snip]
> Ensuring experimental properties remain in development versions and hidden
> behind flags will, in my opinion, be far more likely to prevent them being
> used on real sites, 

I'm not sure what a 'real site' is. A corporate site ? The blog of an influential
designer? A cool demo he built for #sxsw ? All of these use prefixed features
today.

> because it will make it very difficult for them to reach the kind of critical 
> mass of adoption that makes using them viable, something that vendor prefixes 
> do nothing to prevent. But what will really help to avoid this situation is if 
> browser vendors ensure that features do not linger for years in unfinished 
> states, but are instead progressed in a timely fashion to completion and 
> standardisation.

If we're saying they're unlikely to leak because they're hard to get to, that 
would also suggest fewer people will be using them for real-world scenarios. 
Which certainly doesn't explain how using this scheme accelerates the standardization
process in any way. We still need multiple implementations and exposure of the
result to the real world. Less exposure does not speed things up or improve quality.
 
It's also imo not unreasonable to imagine that some of the developers who 
make the effort of testing these experimental features will be even more 
comfortable using them 'out there' and leave them lying around *because* they 
believe it's safe and harmless to do so. ('Only other people with Chrome dev 
channel and the flag set can use this so why not have it on my home page; can't 
bother anyone !') 

So maybe the intent here - and the part I'm missing - is not to replace the current
vendor prefix convention but to establish an earlier stage one i.e. 'we don't have
a spec yet, we don't even know if there'll be a standard for this and for that this
is how we play with it; once there is a spec and wider interest then you get it with
a vendor prefix'. If so, my bad, I misunderstood the scope.

But it intends to replace the -webkit/-moz/-o/-ms baggage we have now, I'm not convinced 
this is an improvement.

Received on Wednesday, 9 February 2011 23:10:34 UTC