Normalization Decisions

[sfrisk]

We talked in the meeting about including normalization. However, there were certain elements regarding normalization that were still up in the air. Specifically the use of tech like box-sizing and how that may break some sites that decide to use css-framework if they weren't already using the box-sizing model.

Creating this issue mostly as an area to discuss how we feel about including box-sizing in normalization, and anything else that should be included.

[imaffett]

Scott showed me a neat little snippet yesterday. This allows any element to override the value easily.

http://css-tricks.com/inheriting-box-sizing-probably-slightly-better-best-practice/

[sfrisk]

Ooo, nice!

[jzaefferer]

That looks good. Including that in the framework should make workarounds for something like Google Maps a lot easier.

[cbracco]

I vote for a combination of normalize.css, the box-sizing reset, and a thin base-layer reset, something like

EDIT ( @arschmitz ): moved code to gist for better issue readability
https://gist.github.com/arschmitz/682e92eb472ba75bc3f4

[jslegers]

I would go for a mixture of features of Normalize.css and Blueprint. Any HTML5 element should be supported, albeit with a focus on HTML4 elements.

With regards to look-and-feel, I would opt for something not very different from the Github look-and-feel. Github is rather minimalistic and clean and at par with modern design standards.

Also, I believe that users should be able to cherrypick which features they want and/or customize them on a per feature basis, using SCSS.

[arschmitz]

normalize.css seems pretty standard at this point its part of html5 boilerplate and i'm good with something like this. The box-sizing reset is also worth looking into too. Blueprint adds a lot of style which i don't see as being part of normalization. To me normalization means just normalizing default browser styles for consistency so it involves no classes or actual styling see http://necolas.github.io/normalize.css/

I think the github approach would be to add normalization with something like normalize.css and then add a separate layer of typography on top. These should be separate modules. Then through a build system and online download builder people can include or exclude whatever they like as far as modules.

[cbracco]

So normalization + thin reset seems to be somewhat of a consensus here...?

[jslegers]

@cbracco & arschmitz :

I think the github approach would be to add normalization with something like normalize.css and then add a separate layer of typography on top. These should be separate modules.

I do think a layered implementation makes a lot of sense (Cascade Framework takes a similar approach), but I don't see the point of having a layer at the bottom that consists of styles that won't ever be used in any project. IMO, even the bottom layers should actually consist of styles that people can actually use in their projects.

So normalization + thin reset seems to be somewhat of a consensus here...?

Not really. IMO normalizing and then overriding those normalizations always results in unnecessary bloat.

I don't see the point of normalizing HTML elements to default browser styles when those default browser styles will be overridden for 99% of all projects using the framework. IMO it makes more sense to normalize behavior to an set of minimalistic but attractive styles that people can actually use in this projects.

[cbracco]

@jslegers normalize.css only addresses a very specific set of element inconsistencies, what I mean by "thin reset" is similar to what you do when saying "separate layer of typography", though I am not limiting it to just typography. There are a lot of small "nice-to-haves" that are not addressed by normalize.css because it is outside the scope of that project, that I like to place on top of it to provide further consistency in behavior of elements across browsers (and also provide a solid base for typography). See my code in my above comment.

This is a fairly common practice, even done by the creator of normalize.css himself:
https://github.com/suitcss/base
https://github.com/inuitcss/generic.reset

[sfrisk]

The whole point of normalize is to get all the browsers behaving the same way before you start in on typography or form elements or anything like that. Otherwise elements might be displayed quite differently from browser to browser, since they all have their own rules about default width, padding, margins, colors, etc. Skipping normalize, which would make sure all elements were starting at the same baseline, would clutter up later css as we attempted to get all elements to behave the same way in other browsers, instead of ensuring consistency at the very beginning. This could possibly make things harder to customize later.

So I agree with @cbracco, that a normalization with a thin reset is a good idea.

[arschmitz]

👍 for normalization and thin reset

[scottgonzalez]

I find that any time I use something like normalize.css, I end up deleting a lot of it because the rules get overridden by real styles, and then it never ever gets updated for new versions of normalize.css. If Sass can do the removing for us, that's great. If not, I think we'll want to pick and choose what we keep base on other styling that we apply at the base layer.

[cbracco]

normalize.css is a very small dependency, I don't see a problem with a few rulesets being overridden by a thin, custom reset layer that is specific to this framework. This way we can keep the library unmodified and boxed in, and we can update it as necessary. The performance gains by cherry picking rulesets out of normalize.css are very trivial, especially after minifying and gzipping the CSS. Optimizations could be made elsewhere in the interest of maintainability.