W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: CSS Mixins proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 21 Mar 2011 22:33:33 -0700
Message-ID: <AANLkTi=sNOXYd9eVRRjpm46e9YUePZiTwFZ+c2h4Rgd3@mail.gmail.com>
To: Alan Gresley <alan@css-class.com>
Cc: www-style list <www-style@w3.org>, Shane Stephens <shans@google.com>, Nathan Weizenbaum <nweiz@google.com>, Chris Eppstein <chris@eppsteins.net>
On Mon, Mar 21, 2011 at 8:06 PM, Alan Gresley <alan@css-class.com> wrote:
> On 22/03/2011 6:55 AM, Tab Atkins Jr. wrote:
> [snip]
> Mixins are used in, for example, SASS
>> <http://sass-lang.com/tutorial.html#mixins>.
>> (Why can't you just add a class to these elements and put the
>> "reusable" CSS in a ruleset targetting that class?  While this
>> strategy does the job, it requires you to alter your HTML and sprinkle
>> otherwise-meaningless classes around your page.  If you want to change
>> what elements receive the special CSS, you have to change your
>> document, which is an anti-pattern that CSS and Selectors were
>> supposed to solve.
> The last time I looked, all recent implementations supported attribute and
> structural selectors and negation. I may have cause some ire in recommending
> reducing 'classes' and 'id' in HTML and adopting these very powerful
> selectors. I have basically advocated simple coding methods [1].

Simple web-pages don't need these sorts of things, though they can
still benefit from them sometimes.  However, more complex webapps and
large websites have significantly greatly complexity and thus
different needs - some tools that seem more complex on their face can
actually reduce the aggregate complexity of the application a great
deal.  I believe that the experience of SASS over the last several
years has shown that these sorts of tools (Variables, Mixins, Nesting)
are of great help when designing even moderate-size sites.

> You recent proposals are suggesting changes to CSS core grammar that has
> been there since the introduction of CSS in the 1990s and these changes
> actually makes CSS more complicated for the average author. I also think
> introducing CSS that IE7 can trip over is very wrong. Additions to CSS
> should not cause IE7 (which came out only in 2006) to choke. I thought my
> reply to you about this issue [1] had some merits.

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.

> 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

Received on Tuesday, 22 March 2011 05:34:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC