Re: CSS Mixins proposal

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
browsers:

<!doctype html>
<style>
@trait foo {
  color: red;
}
#one {
  @mixin foo;
  color: blue;
}
#two {
  color: green;
  @mixin foo;
}
</style>
<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.

~TJ

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