CSS Preprocessing

[jlukic]

CSS Updates

Developing

LESS updates is a major feature for 1.0 and will be found in css branch.

Global Variables

• One global.less file will exist with global variables
• Primary Color
• Text Direction
• Secondary Color
• Page Background Color
• Positive / Negative Color
• Size Name Array -> EM
• Color Name Array -> Hex
• Default fonts (Header + Body)
• Base Font Size
• Link Color + Link State Colors

UI Variables

• Each file with variables will have a variable section at the top of the file
• Variables can either:
  • Inherit value from global
  • Have a specified value
  • Use a color mix-in (lighten etc)

Other Pre-processing Features

• Add vendor prefixes mix-ins
• Add color mix-ins for hover,down state of colors when appropriate

NO NOs

• No plans to using whitespace significant rules. Standard CSS styles whenever possible.
• No use of mix-ins unless using to modify a color or vendor prefix or perform a critical calculation impossible any other way.

[brigand]

Should variables use-hyphens or camelCase?

@linkHover: red;

/* or */

@link-hover: red;

Also applies to namespacing, which less only offers support for in nested rules.

I ask because bootstrap had an issue where about half of the variables were camel and the other half hyphenated.

[elkebirmed]

@brigand , CamelCase is better and more readable as it's so close to the Javascript style "We are JS lovers!"

[elkebirmed]

@layoutDirection will be a LESS variable that has body { text-align: left; }
I know that this is a default property, but it's useful for cssjanus to flip it for RTL layout.

[jlukic]

@brigand With regards to camel case, dashed case. I think both have their arguments.

Camelcase means that we can immediately recognize LESS variables as being different than css, since for semantic we're using lower case dashed words for css classes.

Alternatively using dashed case for variables means that it will fit in to the style of the rest of the code because everything else would be dashed words as well.

[brigand]

@jlukic personally I prefer camel, but it really doesn't matter. There just needs to be one documented correct way; and pull requests that use the other should be rejected.

[jlukic]

So this has gone full circle. After spending the afternoon experimenting I realize that real loops are not and will not be available in LESS

See the creators comments
less/less.js#249 (comment)

So i guess we either have to remove loops and create variables like @color1 @color1hex or we can use SCSS.

My buck is on swapping to SCSS/Compass. It looks like there's a lot of support, and honestly if we just use the good parts we can keep the preprocessing stuff simple so we can make adjustments in the future if we need to.

Control directives like each loops are pretty simple in SCSS
http://codepen.io/jlukic/pen/Lziuw

[brigand]

SCSS doesn't have a JavaScript port, so we wouldn't be able to use it in the browser.

[Pym]

👍 for camelCase

@jlukic where are you using loops in Semantic-UI right now?

@brigand I don't think it's a big deal.

[brigand]

@Pym, I was mostly referring to the customizer (#189); which needs to take the LESS; put new variables in; and compile. We'd have to change it to a server build tool, which well... requires our own server.

[Pym]

@brigand in that case, what about a "Preview/Edit on CodePen" button or something? (instead of generating previews ourselves)

EDIT: see http://blog.codepen.io/documentation/features/can-i-pre-fill-codepen-editors-with-code-i-send/

[jlukic]

LESS would make the build tools much easier, since there is a direct javascript port for less. It would also make an inpage customizer with preview pretty badass for UI definitions.

BUT man do i hate some of the syntax

LESS loop (Requires color Count, variables declared separately, insanely retarded esoteric mixin syntax)
http://codepen.io/jlukic/pen/fvojG

.createColor (@index,@selector) when (@index > 0) {
  @class: ~'.ui.@{color@{index}}@{selector}';
  @colorHex: ~'@{colorHex@{index}}';
  @{class} {
    color:  @colorHex;
  }
  .createColor(@index - 1, @selector);
}
.createColor (0, @_) {}

SCSS loop
http://codepen.io/jlukic/pen/Lziuw

@for $index from 1 through length($colors) {

  $color: nth($colors, $index);  
  $colorHex: nth($colorHex, $index);

  .ui.#{$color}.button {
    color: $colorHex;
  }
}

[brigand]

@Pym we're building a zip file so I don't think that really works. We'd have to set up a server, and depending on use it'd probably be about $15/mo.

It's not a terribly large amount of code to just write it out. Neither of those loops look good.

this

$colors: red blue green;
$colorHex: #AA3333 #33AA33 #3333AA;


@for $index from 1 through length($colors) {
  $color: nth($colors, $index);  
  .ui.#{$color}.button {
    color: nth($colors, $index);
  }
}

or this:

@red: #AA3333;
@green: #33AA33;
@blue: #3333AA;

.ui.red.button {
  color: @red;  
}
.ui.green.button {
  color: @green;  
}
.ui.blue.button {
  color: @blue;  
}

How often are we really going to be changing the way colors work?

[Pym]

@brigand as @jlukic, I prefer the SCSS loop :)

But I still doesn't really know how much loops are used in Semantic-UI right now...

Anyway, if you plan to build a zip, you'll have to compile either with LESS or SCSS. So, why not compile also for the preview? I mean, is a "live" preview really necessary?

[brigand]

@Pym the builder works like this:

1. Download the ZIP
2. Extract the ZIP
3. Join the .LESS files
4. Add the users variables to the top
5. Compile using the less.js parser
6. Put the compiled file in the zip so the user can download it

Everything would be fine with SCSS except for steps 4 and 5. There's no way to compile SCSS in the browser currently.

[jlukic]

Man looking at all these css preprocessors makes me want to write my own. They just seem like really lame versions of other templating languages with a few extra built-ins for understanding color manipulation.

I kind of feel like compiling all our css with handlebars instead. It can be parsed in the browser, and everyone knows it really well already.

Ideally the names of colors and other groups of variations should be user defined and have arbitrary length.

colors: {
  blue: '#2c72b3',
  turquoise: '#2cb38b'
}

sizes: {
  minute: '0.0001em',
  small: '0.5em',
  medium: '1em'
}

So if i generate a palette i get to name my own colors and those colors are used throughout all UI elements with the names i've given them.

<div class="ui minute turquoise button"></div>

[brigand]

@jlukic that would kill portability of HTML. You should be able to change the stylesheet without losing styling. People can change gray to eggshell; but still call it gray.

Yeah, CSS processors are somewhat lame. Go for it!

[Pym]

@brigand I missed the JSZip part... I had no idea that you were planning to build the zip from the browser ;)

They just seem like really lame versions of other templating languages with a few extra built-ins for understanding color manipulation.

@jlukic I couldn't agree more!

[jlukic]

@brigand I guess you're right. The issue though is most color palettes use similar colors. Just browse through Kuler

I guess in English color names are a pretty arbitrary anyways, so perhaps getting too serious about them in the library could be a fairly frustrating and fruitless task.

Maybe we should just limit the number of colors of elements to a reasonable amount and use ordinality.

Primary - Strongest brand color
Secondary - Supplementary brand color

<div class="ui primary button"></div>

Then just migrate away from using named colors since they promote crazy rainbow sites anyways.

[brigand]

One option is to use other blue, etc. So if the user needs more colors, those can be included. If someone loads this element on their page (without extra colors), it just renders as a blue ui button

<div class="other blue ui button"></div>

That's require a much more complicated system (or a ton of code), which LESS doesn't really provide. Maybe 2.0.

[jlukic]

Yeah, either way we're running into the same issue with loops not being great in LESS.

I think for 1.0 lets just go with named colors

pink
red
orange
blue
green
yellow
gold
silver
white

then

light gray
gray
dark gray

[jlukic]

I'm going to use autoprefixer for vendor prefixes from Grunt.

This way we can just use W3C values in src and it will compile correctly and without using mix-ins (which will keep us tied to LESS in the future)

[elkebirmed]

LESS is popular than SCSS, it will helps growing up the community, the problem of LESS is in the syntax but it will serve the package more than SCSS (specially when talking about the package generator)

I'm with LESS 👍

[Pym]

@jlukic and what about something like Bootstrap for colors?

brand-primary
brand-success
brand-warning
brand-danger
brand-info

They're reusing those for buttons, labels and progress bars.

This is definitely more maintainable and evolutive to me. Imagine if you decide to use red and blue as main colors in your brand new website. And one day you want to replace red with yellow.

You'll have 2 "bad" choices then : set red value as something like #FFFF00 or replace every 'red' classes in your HTML.

[jlukic]

The config list is going to probably be much more extensive.

Semantic uses positive negative for many ui elements, like tables, buttons, inputs and also uses infoand warning and error for ui messages and some others

Here's the global variable lists so far.. and this is just starting
https://gist.github.com/jlukic/bcf78f566203a0006c74

[seven-phases-max]

@jlukic. Just in case, with LESS 1.5.0 you can write your #26021333 color loop this way:

@colors:   'red'   'blue'  'green';
@colorHex: #AA3333 #33AA33 #3333AA;

.ui {
    .-(length(@colors));
    .-(@i) when (@i > 1) {.-((@i - 1))}
    .-(@i) {
        @name: e(extract(@colors, @i));
        &.@{name}.button {color: extract(@colorHex, @i)}
    }
}

(It is also possible to get for and for-each like syntaxic sugar via an utility mixin that wraps over recursive loop).

---

p.s. Of course I don't mean one should go that way in the library, I just felt I need to mention that LESS loops (when you need those) are not so very different by now.

[brigand]

For the sake of readability (both human and computer), please don't use a loop unless it's really really important. I'd rather write that handlebars stylesheet thing (stylebars?). It actually sounds like something id'd use so I might anyway...

[ProjectCleverWeb]

My 2 Cents:

@jlukic It actually makes more sense to do SCSS instead of LESS, beyond what has already been discussed. Since SCSS doesn't have an official JS component, no one will try to render it in browser, which is really just a waste of resources when it comes to production sites. Also, this is something that should always be done prior to upload to a server, thus the "pre" in "pre-processing"

@brigand as far as setting up a server, if you don't mind using PHP, give Pagoda Box a try. You should be able to easily handle 50k+ hits per day on their free plan.

[ProjectCleverWeb]

@airtonix

Actually no, I have never used Heroku. Not that Heroku isn't good, I just simply have had more efficient alternatives for my specific applications in the past. By my definition of a web worker, it should have access to the same scripts as the main application, though it should not require them for the most part.

Also your description of scalable app is accurate, though in my description the workers have dedicated resources and complete jobs as resources become available (rather than on a schedule)

For this application, we should easily be able to get away with a single database and avoid the whole master/slave thing. (mostly because the database would be almost exclusively for jobs)

Finally, I would opt for a MySQL database simply because I more familiar with it, though I am open to the idea of Redis. The reasons why I suggested a web worker in the first place, is to keep from bogging down the web node, keep the app scalable, and possibly even have it hosted for free (given resource requirements are low enough).

[airtonix]

@nicholas Jordon

Just clearing up some confusion

... it should have access to the same scripts as the main application,
The way Django and Celery work is that the tasks you have your celery
workers perform are described uniquely for celery, you won't use them
anywhere else in your application because it doesn't make sense to. I mean
you've come to a point where you say to yourself "this bit here, doesn't
need to block the response flow". At that point the use for it is as a
worker task, and the only reason that most people deploy the entire
application to each worker node is to simplify their deployment strategy.

Also your description of scalable app is accurate, though in my
description the workers have dedicated resources and complete jobs as
resources become available (rather than on a schedule)

1. Celery workers can be on their own nodes (machines), therefore have the
   entire machines resources at their disposal. A typical and very basic
   Django site would have the web application, uwsgi, nginx, redis, postgres,
   celeryd, and one celery worker on the same machine. But using a deployment
   tool like Ansible, it's trivial to scale this so that your workers can have
   a machine of their own.

Dotcloud support the use of Django with Celery:
http://docs.dotcloud.com/tutorials/python/django-celery/

On Tue, Nov 12, 2013 at 5:05 AM, Nicholas Jordon
notifications@github.comwrote:

@airtonix https://github.com/airtonix

Actually no, I have never used Heroku. Not that Heroku isn't good, I just
simply have had more efficient alternatives for my specific applications in
the past. Also, by my definition of a web worker, it should have access to
the same scripts as the main application, it should not require them for
the most part.

Also your description of scalable app is accurate, though in my
description the workers have dedicated resources and complete jobs as
resources become available (rather than on a schedule)

For this application, we should easily be able to get away with a single
database and avoid the whole master/slave thing. (mostly because the
database would be almost exclusively for jobs)

Finally, I would opt for a MySQL database simply because I more familiar
with it, though I am open to the idea of Redis. The reasons why I suggested
a web worker in the first place, is to keep from bogging down the web node,
keep the app scalable, and possibly even have it hosted for free (given
resource requirements are low enough).

—
Reply to this email directly or view it on GitHubhttps://github.com/jlukic/Semantic-UI/issues/216#issuecomment-28226030
.

*I must not fear. *
Fear is the mind-killer.
http://github.com/airtonix/
http://zenobi.us/
+61 451 075 636

[airtonix]

@nicholas Jordon

additionally, a celery worker isn't limited to a schedule based approach.
you have time limiting, rate limiting, autoscaling... if you host on amazon
ec2 and include the boto library, you could spool up more machines
programatically (and securely).

On Tue, Nov 12, 2013 at 8:40 AM, airtonix airtonix@gmail.com wrote:

@nicholas Jordon

Just clearing up some confusion

... it should have access to the same scripts as the main application,
The way Django and Celery work is that the tasks you have your celery
workers perform are described uniquely for celery, you won't use them
anywhere else in your application because it doesn't make sense to. I mean
you've come to a point where you say to yourself "this bit here, doesn't
need to block the response flow". At that point the use for it is as a
worker task, and the only reason that most people deploy the entire
application to each worker node is to simplify their deployment strategy.

Also your description of scalable app is accurate, though in my
description the workers have dedicated resources and complete jobs as
resources become available (rather than on a schedule)

1. Celery workers can be on their own nodes (machines), therefore have the
   entire machines resources at their disposal. A typical and very basic
   Django site would have the web application, uwsgi, nginx, redis, postgres,
   celeryd, and one celery worker on the same machine. But using a deployment
   tool like Ansible, it's trivial to scale this so that your workers can have
   a machine of their own.

Dotcloud support the use of Django with Celery:
http://docs.dotcloud.com/tutorials/python/django-celery/

On Tue, Nov 12, 2013 at 5:05 AM, Nicholas Jordon <notifications@github.com

wrote:

@airtonix https://github.com/airtonix

Actually no, I have never used Heroku. Not that Heroku isn't good, I just
simply have had more efficient alternatives for my specific applications in
the past. Also, by my definition of a web worker, it should have access to
the same scripts as the main application, it should not require them for
the most part.

Also your description of scalable app is accurate, though in my
description the workers have dedicated resources and complete jobs as
resources become available (rather than on a schedule)

For this application, we should easily be able to get away with a single
database and avoid the whole master/slave thing. (mostly because the
database would be almost exclusively for jobs)

Finally, I would opt for a MySQL database simply because I more familiar
with it, though I am open to the idea of Redis. The reasons why I suggested
a web worker in the first place, is to keep from bogging down the web node,
keep the app scalable, and possibly even have it hosted for free (given
resource requirements are low enough).

—
Reply to this email directly or view it on GitHubhttps://github.com/jlukic/Semantic-UI/issues/216#issuecomment-28226030
.

*I must not fear. *
Fear is the mind-killer.
http://github.com/airtonix/
http://zenobi.us/
+61 451 075 636

*I must not fear. *
Fear is the mind-killer.
http://github.com/airtonix/
http://zenobi.us/
+61 451 075 636

[slavcodev]

@jlukic If you decide to make your own preprocessor, look at this one

[ProjectCleverWeb]

@airtonix To say the least we have traveled a distance from the original issue. If you want to continue, I would be more than happy to by email.

[RayoGundead]

@brigand what i meant was using absurd

[brigand]

@gundead222 yeah, I know. I think the gist of the conversation so far is "We want plain CSS, plus variables and loops".

[jlukic]

I've started to implement a theming structure that should allow per-ui element theming that can be safely used without interfering with package management / version updating.

Its using a similar set-up to sublime text where all user settings are kept in a separate file that overrides the package default, which lets you keep your settings between version updates. It will also have built in support for CSS overrides for themes.

See the css branch for the current draft form.

[brigand]

Cool, I'm interested in that for something as soon as you can share it
(even a draft)

On Tue, Nov 12, 2013 at 6:02 PM, Jack Lukic notifications@github.comwrote:

I've started to implement a theming structure that should allow per-ui
element theming that can be safely used without interfering with package
management / version updating.

Its using a similar set-up to sublime text where all user settings are
kept in a separate file that overrides the package default, which lets you
keep your settings between version updates. It will also have built in
support for CSS overrides for themes.

—
Reply to this email directly or view it on GitHubhttps://github.com/jlukic/Semantic-UI/issues/216#issuecomment-28355769
.

[vladcosorg]

no ruby dependency anymore, pure C !
http://libsass.org/
Zurb Foundation 5 is already using it in production

also nodejs integration
https://github.com/andrew/node-sass

+1 for SASS at some point in the future

[jlukic]

There will be native SASS and LESS support for themeing!

I haven't had reliable enough connection yet to push to github, but will be sharing more related to this shortly. Still a lot of work to do, but inheritance will work with

Package defaults --> theme defaults --> user overrides

Each level is per element and consists of both (css overrides + variable overrides)

Will be doing a couple basic themes to give a better sense of the capability (github style buttons for one)

This is a similar structure to sublime text with user settings. Pretty excited!

[BigBlueHat]

Found my way here from the website's [Contributing] page, and it looks like you've landed on LESS with only variables--which is cool. 😸

If you do start looking around again--and want to keep it simpler still--you might take a look at Myth. It uses the CSS3 for the language and pre-processes that "down" to something that works in current browsers.

If you're sticking with just variables, Firefox 29 will have support for var() in CSS: http://caniuse.com/#feat=css-variables

It seems pretty nice to know you're "coding for the future" and only dependent on a pre-processor for the time being.

Just an idea 💡

[ahmadseleem]

+1 for SASS ;)
I know people just did not use Bootstrap, because of LESS! and Foundation made them happy
because of SASS! then, Bootstrap lately made an official port for SASS!

Don't do it like Bootstrap!
Rails developers will love it and people who use Compass, too!

[jlukic]

I'm developing with LESS, using imports and variables only.

You can see a live example here

Example var definition

Variables are per element, with global inheritance for things like border-color, `text-colorandfont-family``. The port to any pre-processing language should be very easy.

[niallobrien]

Libsass solves your problems. You guys need to forget about reinventing the wheel & focus on the important issues. I use gulp-sass with Foundation 5 with no problems.

[cowwoc]

@brigand Maybe I missed something, but couldn't you guys use https://travis-ci.org/ as your build server (it's free and excellent from what I hear) and have it compile SCSS to CSS on your behalf?

[brigand]

@cowwoc the problem is more about integration with nodejs and browser tools for users.

I don't have much experience with SCSS, but things like taking a JSON configuration file and using it to set variables when building the stylesheet are important to do. And like @jlukic said, you can easily convert it to a language that works for you.

[cowwoc]

@brigand Maybe I missed something, but I thought that the SCSS files were just used internally (by the authors of Semantic-UI) to generate the final CSS files, and end-users were supposed to override values by declaring their own CSS files (as opposed to editing those belonging to Semantic-UI).

[brigand]

@cowwoc currently, yes. For 1.0 there's going to be variables which can be changed to create themes; and users will often want to create their own themes to reflect branding, etc. This can be done with a web GUI, or in your build system (grunt, gulp, make, etc.).

[ahmadseleem]

@cowwoc SCCS is just a syntax for Sass.
and I think you should check it here:
http://sass-lang.com

And tell us what you can't make with sass ? even with grunt or whatever.

[cowwoc]

@brigand I don't see why end-users need their own theme server. I'm expecting http://semantic-ui.com/ to offer something like http://jqueryui.com/themeroller/ which compiles SCSS, LESS or whatever in the background and sends the compiled CSS files to the user.Anyone wanting to run this themselves (and I don't see why they would) should expect it to be a non-trivial process.

@ahmadseleem You're preaching to the converted. I'm arguing for SCSS, not against it.

[brigand]

@cowwoc I guess the point is: all semantic-ui uses from the preprocessors is variables; so there's no gain in switching to any particular one. LESS works fine, and has the benefit of being compatible with a GitHub hosted customizer tool. Ports are simple if your workflow requires a certain preprocessor.

I don't even like LESS; it's just good enough for this use case.

[ahmadseleem]

@cowwoc I'm sorry my last message was meant to @brigand !
I don't quiet understand why is he die hard for LESS. If all you use now is variables you never know what this project needs in the future if you guys expecting people to drop Foundation or bootstrap for this. I personally don't know who used LESS other than bootstrap and now they use SASS officially as well. It's like pointless argument.

[ahmadseleem]

You guys have just about 57 contributors but 797 fork!!
you need more contributors to get things done faster and Sass is getting to be a standard for front-end developers obviously. so these people can contribute with Sass mixins and other advanced Sass goodies. it's up to you guys. I have nothing to say more in this argument.

[jlukic]

No one is die hard for any framework here. LESS is being used because something has to be used, and it is a good, lightweight choice with widespread community support.

Novice users will be more comfortable setting up LESS compilation then SCSS, although SCSS has more features and in my opinion is the better framework for experienced developers. That being said, I think getting into a flamewars about the relative amazingness of different pre-compiled CSS languages is a bit ridiculous and tangential from the project's goals.

We are only using a limited feature-set of the language, as previously discussed. Other language features like control structures, nesting, and mix-ins are not part of our requirements.
People will most likely compile our project once, through our website, or on their own, then only on infrequent occasions recompile the project when they want to revise their UI.

As previously stated, it will also be relatively easy to write ports for SCSS, although the most up to date version will always be released in LESS first.

[jlukic]

Marking this off as completed.