Update to h5bp 2.0

[heygrady]

I've taken some time to update the gem to the latest h5bp that's been out for a while. I upgraded to the releases 2.0.0 even though there's some slightly newer changes in the repo.

https://github.com/heygrady/compass-html5-boilerplate

Please let me know what you think. I tried not to make any unnecessary changes but the CSS changed significantly and I too a different approach towards allowing it to be customized.

[sporkd]

Thanks heygrady. That's awesome. Let me look over it and I'll probably merge it in since I've been too busy to update this repo.

Peter

[heygrady]

Poke. Please let me know how I can help.

[sporkd]

heygrady,

I think I like what you are trying to do with the mixins that take a list of sections. My main concern is maintainability. Part of the reason I got so far behind on keeping up with the upstream html5-boilerplate master is that I extracted everything to mixins and expanded out all the classes to long format. (This kind of made sense since since h5bp v1.0 before normalize.css consisted of more hacks you might want to reuse as mixins). However, the way I did it made it very hard to use a simple diff program to merge in upstream changes. I also underestimated the sheer amount of upstream flux.

For version 2 of this gem, I decided to extract the css parts out to it's own compass extension. This is because most of the the html, javascript, assets and even directory structure is specific to the framework and language you are using, and the manifest is not flexible enough to handle those differences, especially with asset pipeline. So I already started work on a compass extension that is just the scss libraries. The most recent attempt is compass-h5bp. It is meant for anyone writing their own implementation of h5bp (Rails, Sinatra, PHP, staic sites, etc.)

And the first implementation of compass-h5bp is html5-rails, which is specific to the needs of rails 3.1+ users on the asset pipeline. However, I suspect there are still a bunch of people on compass-html5-boilerplate and older versions of rails... so the eventual goal here was to to rip out all the css, and update it use compass-h5bp as its css library dependency. That way it benefits from updates to compass-h5bp along with all other implementations.

So I'm trying to decide the best way to handle your changes, and perhaps wanted to discuss. Specifically if you could have a look at compass-h5bp and see if you think there's any advantage to a list of arguments like this...

@include html5-boilerplate-normalize((
  html5,
  base,
  selection,
  links,
  typography,
  lists,
  images,
  svg,
  figures,
  forms,
  tables
));

Versus just explicitly including each mixin like this...

@include h5bp-display;
@include h5bp-base;
@include h5bp-links;
@include h5bp-typography;
@include h5bp-lists;
@include h5bp-embeds;
@include h5bp-figures;
@include h5bp-forms;
@include h5bp-tables;

And as mentioned before, I tend to favor a solution that will allow for easier upstream merging, so in compass-h5bp I've tried to keep scss blocks inline like the h5bp upstream master for easy diff-ing.

So I do like aspects of your approach, and I could certainly use help keeping things current. Perhaps a combination of these approaches. Or maybe you would like to make this repo work with compass-h5bp instead, since it looks like you've already tackled the haml template updates.

So those are my thoughts.

[heygrady]

I hadn't seen your new gem that only had the CSS in it. But that's ultimately the way to go on this. I actually don't use Rails at all so that part was just noise to me. But really the Rails community is the only one that would really take advantage of a gem that set up the initial project for them. I can't imagine a Symfony 2 plugin for PHP for instance. Or one for Django?

Although for your simpler compass-h5bp I think having the compass create command create the JS files and the index file, etc would be a nice touch for the non-rails versions. For me the whole point of this is to accomplish 2 things: to start a project with an intact version of the latest h5bp and to fix the CSS stuff that needs customized for my project. To the extent that the H5BP CSS is broken into distinct sections and important variables are able to be customized, we'll have accomplished my goals.

Doing a ton of includes is probably better because it's simpler. I can see people getting really confused about the double parenthesis used to create the list. Although personally I was really proud of myself when I thought of using lists and was doubly pleased when it actually worked.

One place where the lists really benefit is when the individual mixins are really big but it doesn't necessarily make sense to split them up into ever smaller mixins. For instance, the typography mixin is particularly opinionated and potentially contentious for css developers but it may not be better to create something like @include h5bp-typography-pre;.

Painful merging is going to be an issue no matter what, but you could probably see changes by running the original H5BP CSS through YUI Compressor and comparing the SCSS results that way. Then you would see what mixins need tweaking.

If the compass-html5-boilerplate library is deprecated then there's probably not a lot of reasons to maintain it. I think the real question is which group is using this library more; is it more Rails developers? Or more static/php/non-rails developers? Regardless, I agree with a revised approach of simplifying the base library to offer a more pure H5BP and to allow for easier maintenance. Also, porting CSS to SCSS mixins is a little easier than trying to port HTML to HAML

I'll look at your new repo and see what I have to offer on that one.

[sporkd]

Cool. And actually I was not planning on deprecating compass-html5-boilerplate. It's still a good implementation for static sites and perhaps older rails sites... i.e. when you want to run compass create or compass init. So it would just be nice to have it use compass-h5bp as it's css library and also update all the templates.