Re: CSS Mixins proposal

On 22/03/2011 4:33 PM, Tab Atkins Jr. wrote:
> 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.


Tab, I have look at HTML and CSS code on a diversity of sites. Some of 
this code is built by people who do not understand that things can be a 
little simpler. I have spent 4 years on CSS discuss and have ripped 
apart code which is much larger then my code and made this code simpler 
so an author (who wrote a query on CSS discuss) could themselves 
understand it. SASS maybe one solution but that doesn't mean there are 
not other solutions.


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


That is not why I raised the IE7 issue (see below).


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



> The fact that IE7 has buggy
> error-recovery behavior should not hold back the evolution of the CSS
> language.
>
> ~T


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.



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Tuesday, 22 March 2011 09:13:58 UTC