RE: CSS Mixins proposal

[Tab Atkins:]
> IE7 is now two versions obsolete, and over 5 years old.  That's
> *forever* in web years.  In 2006 Firefox was still on version 2, Opera had
> just released 9, and Chrome hadn't even been started yet.  It is
> completely a non-goal for me personally, and I believe the WG generally,
> to hobble CSS due to the buggy parsing of an obsolete and fading browser.

IE6 is 10 years old; when it came out Firefox, Chrome and Safari didn't
exist. Neither did Ubuntu. But if you don't test for it in China, you're
going to miss a lot of people. IE7 is certainly still out there in numbers.
(Although, thankfully, it doesn't seem to have acquired IE6's stickiness)

Now, I don't think anyone is suggesting to design features *for* those 
browsers but the number of authors who have to deal with them is still large 
enough that a feature that fails badly on older platforms may end up being
either avoided or require significant benefits to justify the expense of 
deploying it. It's one thing to tell readers of your personal blog to upgrade 
already and too bad if they don't. It's another entirely to say so to a customer 
who wants to give you money, or to an entire government agency. So if there *is* 
a way to minimize the damage and allow the feature to be used broadly without 
making the lives of users and authors harder, I don't think it should be 
considered a non-goal. You can't both argue that specs ought to reflect the 
real world - which they should - and then ignore the latter when it makes your 
life as an editor easier.  

Users, over authors, over implementors etc. Right ?

So the argument shouldn't be 'This thing is so old it shouldn't be out there anymore
so I won't care that it actually still is', it should be 'I don't care because the change 
required to accommodate this older browser will make authors' life harder and/or will make 
it harder to implement/maintain/extend the feature for the following reasons'. 

Fwiw, Google Maps and Gmail support IE7. What would they make of a new CSS feature that
makes writing CSS easier but breaks those clients ? 

> 
> 
> > Look at this.
> >
> > @trait bar($one, $two) {
> >  prop: $one;
> >  prop: $two;
> > }
> >
> >
> > I rejected your proposal regarding variables because they behaved like
> > other @rules ending with and a semicolon. I look at the above syntax
> > and I seeing declaration blocks in between curly braces {...}. I do
> > not support your syntax since it move away from core grammar.
> 
> There is absolutely nothing wrong with @trait from a Core Grammar
> perspective (or @var, for that matter).  The @mixin rule inside of a
> declaration block violates the Core Grammar, but it fails in a way that is
> still forwards-compatible for any parser that properly implements the
> error-recovery rules.  The fact that IE7 has buggy error-recovery behavior
> should not hold back the evolution of the CSS language.
> 
> ~TJ
>

Received on Tuesday, 22 March 2011 16:46:59 UTC