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

Re: CSS Mixins proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 22 Mar 2011 09:58:19 -0700
Message-ID: <AANLkTinEu9kQKr9xaR_susxuyYHtifZivto8C4d58Xoq@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 Tue, Mar 22, 2011 at 2:13 AM, Alan Gresley <alan@css-class.com> wrote:
> On 22/03/2011 4:33 PM, Tab Atkins Jr. wrote:
>>> 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.
> Have you tested any of this. Have you tested error recovery.

Yes.  No modern browser has any problem with mixins.  The following
document renders correctly (ignoring the @-rules) in all modern

<!doctype html>
@trait foo {
  color: red;
#one {
  @mixin foo;
  color: blue;
#two {
  color: green;
  @mixin foo;
<p id=one>blue</p>
<p id=two>green</p>

Mixins with arguments are similarly compatible and friendly.

> Can you point
> to test cases that show properly formed 'mixin' and test cases that show
> poorly formed 'mixin'?
> What should happen here?
> @mixing table-base {
>  ht {
>    text-align: center;
>    font-weight: bold;
>  /*}*/
>  TD, ht {padding: 2PX}
> }
> @mixing left($dist) {
>  float: left;
>  margin-left: $dist;
> }
> #data {
>  @include left(10PX);
>  @include table-base;
> }

This test-case has absolutely nothing to do with my proposal; it's a
generic test of mismatched braces handling, and would apply equally to
any construct with braces, such as @media or a declaration block.

(In a conformant parser, error recovery would cause the rest of the
document to be swallowed.)

>> The fact that IE7 has buggy
>> error-recovery behavior should not hold back the evolution of the CSS
>> language.
> The reason I have raised IE7 buggy behavior is to illustrate what happens
> when you change core grammar. Supporting IE7 is not my concern. I have
> always stated that CSS should been view from a pass, present and future
> perspective. There are a limited number of tokens that can be used. I think
> we should be wise when adding new tokens (or some used in a different
> manner) or new grammar rules. Making a mistake now affects the future of
> CSS.

We have parsing rules for a reason.  If a browser doesn't implement
them, that's not an indictment of the parsing rules (not necessarily,
at least).  IE7 was a non-conformant parser in quite a number of ways.

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

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