Any plans to write a Sass version?

[mrcasual]

Re,

A Sass version would be extremely helpful. If anything, the following clutter:

<div class="ink-l50 ink-m50 ink-s50"></div>

Can be replaced with:

<div class="section"></div>

and Sass:

.section { 
  @include ink-l(50);
  @include ink-m(50);
  @include ink-s(50);
}

Cheers.

[pedrocs]

Hi, Ink uses LESS, instead of SASS as we felt it was simpler to learn and keep track of for people who already knew CSS.

Your example is not very clear as you are using layout classes to keep everything the same in three different screen sizes. A more usual approach would probably include varying the widths along with the screen size, in multiple combinations, making a single overarching declaration useless.

Pedro Couto e Santos

[mrcasual]

Re,

My example was taken straight from your page on Layouts (http://ink.sapo.pt/index.php/layout) under the Columns section. The Sass rules were used to demonstrate how a simple inclusion of "mixins" (provided that ink-l, -m, and -s are made as mixins) could replace the semantic clutter inside HTML.

While I will not argue the cons and pros of using Sass vs. Less, this was just a suggestion, since the general trend these days seems to be towards Sass.

Cheers.

[pedrocs]

Hi,

We get it, nothing against SASS or in particular favor of LESS, it was just a choice we made early on. Perhaps our examples need to be improved, we'll look into that. Thanks!

[pedrocorreia]

About a SASS version, yes. I personally have that in my todo list. I think all would benefit if Ink is as "multilingual" as possible and believe me i'd love to have proper control structures (if,else,for,while) in LESS.

The real issue here is that we have to cater for people who don't want to use either LESS or SASS, and that leaves CSS, so we really never meant to have the use of any css pre-compiler as a requirement to use Ink.

As to semantic clutter inside HTML, i have to strongly disagree with you here.

Even though the HTML5 Specification on the class attribute says "The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to. ... There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.", there is nothing, other than our opinions, setting that the class attribute in HTML elements adds or should add meaning to the content.

Any chosen class name will impart the content with some form of meaning and in our case we chose to have class names that are meaningful to both users as the people authoring the pages.

Anyhow, exposing the grid css generation as individual mixins is a great idea and could really help people in the customization process and if they choose to take the approach you described in your example.

Cheers, Pedro

[mrcasual]

Re,

Fair comments. As someone who has extensively used Zurb Foundation, which is available both in vanilla CSS and Sass, Ink would definitely benefit from what you refer to as "multilingualism".

I am not arguing against using semantic class names, but isolating them into CSS has some merits. Using Foundation as an example, things can get really messy:

<div class="row">
  <div class="four mobile-three columns offset-by-two hide-for-large-up"></div>
</div>

Now imagine you have 20 rows; that's almost a whole essay of class names :) Anyway, glad to hear that you're considering further improving Ink and I look forward to future releases.

Cheers.

[pedrocorreia]

Thank m8.