Closed paulirish closed 12 years ago
as part of this the build script would run a compass compile
command for sure.
Another possible advantage would be splitting everything into partials, so you could mix and match the parts of the boilerplate you want.
Not only that but using Compass Browser Configuration, even included parts can be trimmed down for specific projects using these flags: http://compass-style.org/reference/compass/support/
I think this is a really good thing too. I use partials a lot to keep small files & accelerate maintenance. (btw I'm working on a repo of sass "recipes", using compass https://github.com/MoOx/compass-recipes )
Why SCSS over LESS?
richer css3 support via compass. also less has too much ambiguity about clientside vs serverside.
I totally agree moving towards .scss
Hmmm. not sure I completely agree with this. One of the main appeals for HTML5BP is it's ease of use for noobs & pros alike - introducing a dependance on an external library may confuse matters, even with the CSS source on the repo.
Honestly I think the BP should continue to encourage designer/devs to write CSS in CSS, and use SCSS/LESS in their own time.
Fully agree with Daneden, for me, taking the Compass step is a rung to high.
(Compass != Sass) The thing can be designed to be not mandatory. How do you use the predefined css ? Sass produce a valid css, you can start from that right ?
Both the .scss source and css file can be included, makes no difference.
@paulirish I've actually been working on something similar for my own use, and while not strictly boilerplate it uses many of the styles from it. https://github.com/davidrapson/scss-toolkit
Might be of some use?
thx @davidrapson we'll take a look! :)
There is interesting code in this gem https://github.com/sporkd/compass-html5-boilerplate I think here we have almost of the job done : https://github.com/sporkd/compass-html5-boilerplate/tree/master/stylesheets/html5-boilerplate
Edit: Compass.app use this fork https://github.com/heygrady/compass-html5-boilerplate
i think you should ask the community about scss vs less. there is NO js implementation for sass so you are dependent on the ruby compiler. think this is not good for the boilerplate. less could be dynamically compiled with less.js-compiler or built into build-script with node.js.
LESS is also it's own name, by which it's doesn't try to be everything, like SCSS which is almost a programming language in it self.
how much of this still needs to be done?
Seriously Less ? Using javascript compiler is a bad thing (very ugly?)... Btw, Ruby is really easy to install (when it's not already)
I think @paulirish want this enhancement to be just "optional".
Anyway, asking the community is a good idea.
@MoOx I think if the project were to be written in LESS, users would be encouraged to compile before deployment. LESS is a lot more user-friendly too (speaking as a SASS/LESS noob)
We're definitely not using LESS. For one, it is too ambiguous about the use of Less.js (which should not be used).
We're considering using Scss (and not Compass) and providing the compiled CSS too. Using Scss is pretty easy and there are several cross-platform Apps that can help with compiling if people don't want to install Ruby.
@necolas How come not Compass? IMHO I can't imagine not using Compass when working with Sass. Is it just the extra requirement? I'd love to hear your reasoning.
If it you want to use Compass when working on your own project, then of course do so. But there is no reason why it should be included by default.
@necolas Makes sense, there's nothing in H5BP that would greatly benefit from Compass. Theres some good stuff you can set in Compass' config.rb
for making the compile process easier, but they're nice to haves not requirements. Thanks Nicolas.
Thanks @necolas. It's now clear for everyone. Does somebody already start to work on the css to scss conversion ? Can I if nobody had ?
At the moment, we're still just considering the change.
I like the idea very much! I am just starting with sass and compass. My problem is that I don't know (yet), how to include both into the html5 template. So if you are thinking about working on this: go Paul!
i like LESS because i can use the JS-compiling "on the fly" during developement independent from any build process or other ruby based compilers. later in productive environment i can use a compiled version or use node-js + caching to get better performance.
@lhwparis There are several apps available (e.g. Less.app) to do that for you without having to rely on Less.js. That means you never have to include a .less
file or less.js
in your HTML at any stage.
i know but the less.js is why i love LESS. i can test my templates after each small change in the LESS file and see my changes directly in my preview because of using "on the fly" compilation by less.js i do not need a build process i am not depending from any other language or tool just javascript available in my browser thats great for fast and easy developing without dependencies.
When my site is ready i compile the LESS and include it in my productive site or use node-js or something like that. so of course i will never use less.js in a productive website but for fast developeing its perfect in my oppinion.
Never forget Boilerplate != Framework!!! So the Boilerplate should never contain anything from compass. you can use it in your projects based on boilerplate...
Sass command have two command sass watch
& sass compile
for all stage.... With something like livereload, it's really more powerful than a less.js...
And do not mix up Sass & Compass there are not the same thing. Sass is not a framework. It's like Less, a CSS pre-processor.
yes but livereload is another tool i have to use and its mac only not realy much freedom:(
sorry i dont want to mix up sass & compass i just said this because some people mentioned compass in this discussion and i do not think compass should be discussed here in context of the boilerplate
Sass watch is faster than less.js "on the fly". As soon as you save your file (CTRL/CMD+S) CSS is updated. There is no javascript involved during browser rendering.
yes but ruby dependency and starting sass watch every time starting to work or switching project :(
I've created an implementation: https://github.com/mostly-magic/html5-boilerplate
Here are the key points:
How will the CSS output look like? If it's still humanly readable, like in @mostly-magic's version, why not.. people can still decide if they wanna edit the CSS or the SCSS to their likings. But if the output gets hard to edit or understand and you're dependent on SCSS.. hmm.. I'm not sure if that's a good idea.
With Sass you can completely control the output of your CSS http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#output_style
@simurai it will definitely be human readable. Definitely not going to be hard to edit or understand.
What @MoOx said. I usually output compact which is pretty readable and low on kB.
I'll +1 this. I recently started a small project and wanted to use H5BP w/ Rails & SCSS & Compass. As far as I could tell, none of the projects listed in this thread are fully up to date w/ the latest H5BP, so safest thing to do was to integrate manually (which took all of 5 minutes at best).
If we include the compiled CSS, nothing is stopping you from still writing CSS, and SCSS users have a head start.
But since it takes 2 mins to drop the simple, default H5BP CSS into a .scss
file, why should we include both by default in the repo when the majority of H5BP users aren't going to use Sass?
@necolas I didn't take the time to optimize the h5bp for scss/compass in the ways @paulirish is talking about.
Thinking about real life use tho. I usually don't touch much in h5bp after its implemented. SCSS is easy to write and maintain, but if I'm not doing either to the H5BP what's the point?
I also learned a lot just from reading the comments in the H5BP CSS. Wouldn't want those to become harder to grok.
@simurai With the SCSS expanded output style we can be pretty sure it will be as if there was no pre-compiler and make it easy to start either from the CSS or the SCSS.
In that case, why not?
Love sass but @ericdfields make's a good point, there isn't much to change in H5BP's CSS - Although I do like the idea of making the hot pink color a variable ;-)
I encourage things like this, but please keep in mind that not everybody using h5bp is either using OSX or Linux.
It's true that there is very little advantage to the core CSS by re-writing it in Scss. The advantage is primarily in integrating the compilation of custom Scss files into the build process. Instead of making H5BP dependant on Sass, would it be better to add to the H5BP docs instructions for adding Sass or Less into your build?
Move on to sass or less. Both are timesavers
@MoOx as far as I remember :compact makes multiline comments unreadable.
Whatever will be the decision, please leave the main .css file to be manually maintained, easy to work with, and nicely readable version of stylesheet as it is now. Let the .scss file be the bonus!
If I choose so, I want to have an option to delete it and ignore all those Sass/Less shenanigans, while not feeling that I'm loosing something :)
For example: the difference between the current .css, and @mostly-magic's version generated from .scss is unacceptable for me.
i'm definitely in favor. i'm assuming this means including some css3 mixins by default. some of the compass mixins are pretty handy, like generating inline svg as data uris from gradients to get around the ie9 rounded corners not clipping bug.
If you're going to move to SASS be unapologetic about it; don't use the bullshit SCSS syntax. Opt for the simpler and more terse syntax. It is easier to maintain over time and it really is not difficult to understand. There are no advantages to using the bulky CSS-like syntax.
Existing CSS is valid SCSS, which means it's easier for people to jump into than straight SASS. I think that's a pretty important advantage. There's a reason SCSS is the primary syntax nowadays.
i don't think defaulting to the sass syntax is in keeping with the spirit of a project with boilerplate in the name. if you really want to use sass instead of scss you can use sass-convert.
It'd be better for us to author the styles in scss.
We can still host the css in the repo for newbs that can't be bothered with a
compass compile
stepoverall advantages:
individual advantages
:selection
styles DRYd upinput[type=search]
disadvantages