W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: @with -- DRY syntax for nesting selectors

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Mon, 09 Jan 2012 20:32:17 +0400
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: www-style@w3.org
Message-Id: <934551326126737@web26.yandex.ru>
09.01.2012, 19:53, "Simon Sapin" <simon.sapin@kozea.fr>:
> Le 09/01/2012 15:26, Marat Tanalin | tanalin.com a écrit :
>
>>>>  Bad idea or not, we do have it in css3-page:
>>>>
>>>>  http://dev.w3.org/csswg/css3-page/#margin-at-rules
>>  As far as I can see, compared with what I propose, margin-at-rules is
>>  a different feature for a different purpose.
>
> Sorry this wasn’t clear enough. The reference to css3-page is not about
> the feature proposal, but about the syntax detail of mixing declarations
> and at-rules.
>
> Other that not being done in standards before (which it was), is there a
> problem with such mixing?

Thanks for clarification. Nevertheless, syntax of margin-at-rules is actually similar to syntax I propose (nested @rules side-by-side with property/value declarations).

On the contrary, in SASS/LESS, _selectors_ (not at-rules) are placed side-by-side with declarations. Main problem with SASS/LESS approach, in my opinion, is some nonuniformity/inconsistence (which leads to parsing complication and potential issues with backward compatibility) due to there is no _simple_ way to differentiate selectors from declarations in case of mixing selectors with declarations: we have two different type of things that starts with just arbitrary string (as opposed to at-rules that starts from '@').

>>>>  As much as I like the idea, syntax details aside and assuming
>>>>  this is spec’d and implemented right now, it will be many years
>>>>  before we can use it on the web without fallbacks because of
>>>>  older browser versions.
>>  Base on such arguments, we could don't do anything new at all never,
>>  so such arguments are useless at all.
>
> Agreed in general, though I maintain that in this case the alternative
> is equivalent and available today.

By the way, I don't use neither SASS nor LESS (or anything similar) exactly because they are nonstandard and have no really wide support in CSS-code editors (which, in turn, is likely because they are nonstandard).

>>>>  On the other hand, pre-processors like LESS or SASS are available
>>>>  right now. They can be changed/updated/replaced without browser
>>>>  support concerns.
>>  Standard feature could be used in server-side preprocessors with the
>>  same result. While there is big fundamental difference between
>>  standard features and nonstandard ones. One of most important is that
>>  using standard feature reliably prevents syntax conflicts between
>>  nonstandard feature and standard one added later and having same
>>  syntax (or parts of syntax) but different meaning.
>
> Good point.
>
> --
> Simon Sapin
Received on Monday, 9 January 2012 16:35:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT