Re: CSS Mixins proposal

On Mon, Mar 21, 2011 at 8:06 PM, Alan Gresley <> wrote:
> On 22/03/2011 6:55 AM, Tab Atkins Jr. wrote:
> [snip]
> Mixins are used in, for example, SASS
>> <>.
>> (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