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.

[arschmitz]

One thing I would be interested in with normalize.css is how much ( if any ) of it is to fix browsers we will not support. Browsing over the code quickly for support comments. Everything i saw seemed to be up through current version or at least include browser versions we are likely to support.

One other thing I notice glancing over normalize again is the much ( though by no means all ) of it is resets for element types I would say ( at least any time soon ) we are unlikely to style. So much of the benefit of something like this seems like i would be to users of the framework ( not to make anything any easier for actually making the framework ).

Also if we do want to include something like this I think choosing something like normalize and making it a dependency would make sense precisely to make make sure we do stay up to date. It is a very actively maintained project. Andy by using something like bower or npm make it very easy to update versions.

[kristoferjoseph]

👍 On very thin normalize. I agree with @arschmitz in that we should cherry pick the relevant parts to normalize as we add styling of elements. Normalize has a broader target than we do so we can focus a bit more. This way we could minimize the amount of bloat and necessary overrides.
@sfrisk is right on about normalizing enabling people to get styling in a more reliable way. Such a headache for most folks without it.
Separate opt-in files of styles like the beautiful defaults @cbracco added above would be very kind of us to include as well. Possibly separate ones as you all discussed above for Typography etc.
Ideally we would go a bit farther and add variables for the default styles, but that could be getting ahead of ourselves :)

[jslegers]

@cbracco :

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

Resets made a lot sense in the pre-CSS-preprocessor era, as they offered a quick but effective boilerplate for your projects on top of which you build your websites or applications.

In this age of CSS preprocessors, resets are no longer needed. Using conditional styles and configuration, you can skip the bottom layer of your architecture and integrate it with (configurable) higher layers.

Just because most people haven't moved on yet, that doesn't mean we shouldn't.

[cbracco]

That's fine by me, we will need to figure out what is and what isn't essential for this particular framework, and make the "non-essentials" configurable (similar to what @kristoferjoseph was saying above, re: opt-in).

[jslegers]

@cbracco 👍

[MichaelArestad]

I would strictly use a normalize (with only the bits for supported browsers) and a light reset. I would put everything else (base typography styles, etc) in their own module structures (which is a slightly different discussion).

[sfrisk]

Definitely. I prefer to keep base typography and everything like that separate from the normalize and reset.