Re: CSS Mixins proposal

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).


> 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.

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).

~TJ

Received on Tuesday, 22 March 2011 17:13:56 UTC