RE: CSS Mixins proposal

[Tab Atkins:] 
> On Tue, Mar 22, 2011 at 9:46 AM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:
> > [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'.
> 
> I agree; I didn't mean to imply anything other than what you are saying
> here.  In particular, I object to using an obsolete browser as a reason to
> block a new feature entirely; by similar reasoning, Flexbox and Grid
> Layout are bad, because no current browser supports them, and a page
> authored to take advantage of them (particularly Grid
> Layout) can end up pretty badly styled in a browser that doesn't
> understand them (it's easy to author such that your page looks fine both
> with Grid and totally unstyled; hitting that middle target of some-
> styling-but-no-Grid will be much more difficult).

The latter is something that does concern me a bit re: feature adoption,
by the way. Otherwise generally agree.

 
> > 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 ?
> 
> They both can and do discriminate based on user-agent and send down
> different code depending; they'd either use that ability to serve the good
> stuff to modern clients, or just avoid the feature until the downlevel
> clients faded away sufficiently to be ignorable.

Let me refine the question: given the choice, wouldn't these teams prefer a
feature design that doesn't require some form of browser sniffing ? The
answer in Google's case may be that they're already sniffing and segregating
their markup and CSS so they don't care either way. In that case we shouldn't 
really care or worry about them either.

 
> I don't expect a feature like this, which is primarily for authoring
> convenience and code simplification, to see significant usage in large-
> scale production for several years.  It needs significant browser-share
> before it's useful to use in production, since adding fallback defeats the
> purpose of using it in the first place; I do expect, however, a limited-
> functionality version to be usable from server-side CSS compilers in the
> near future (we've written one ourself to play with the features, and SASS
> expects to pick up whatever syntax the CSSWG agrees on).

Speculative expectations of the future should not - imo - feature prominently in 
design decisions affecting standard features that will be around far longer than 
any given browser version (even IE6...). Just read back your own earlier post and 
compare the world as it looked like from the vantage of 2006 vs. now. Five years
*is* forever.

Finally, assuming you do want feedback and aim for your fellow browser vendors to 
implement Mixins and converge on an interoperable implementation, is the catchiest 
pitch you can give them - and authors out there - that 'I don't really care about 
adoption now or next year, I think this will take many years to happen' ? Ahem :)

Received on Tuesday, 22 March 2011 17:52:27 UTC