inuitcss / CONTRIBUTING

[DEPRECATED] [go to intuitcss/inuitcss]
https://github.com/inuitcss/inuitcss
11 stars 0 forks source link

Consider Separation Of Default Element Tweaks And Default Styling #7

Closed Undistraction closed 10 years ago

Undistraction commented 10 years ago

I really love the approach you've taken to separating the different aspects of this framework out. I'm generally someone who likes to pick and choose exactly what I want for a project and it's surprising how difficult this is in the current Sass eco-system. There are some great stand-alone projects like Breakpoint and Susy and some great focussed utility libraries, but beyond that, most frameworks don't separate elements to a degree that they can be mixed and matched easily.

A large part of this is caused by the necessities of configuration. Lots of otherwise incredibly useful files become tied to the framework by references to $button-paddding or whatever.

Pretty much everyone (rightfully) uses Normalise nowadays, but it seems to me that there is a strong case for a separate layer between normalisation and component configuration which involves altering defaults to make them more useful. This might be removing margin, padding and list-style from a list, setting html and body to 100% width and height, vertically aligning images to remove whitespace or whatever. In all cases, they are not adding new classes or introducing mixins. They are simply tweaking browser defaults to more sensible values.

In my own work, I have a set of tweak files for each element that I include before the more comprehensive default element styling files and I really like this separation. This way as little code as possible is polluted by configuration variables making it more portable. Looking at Intuit's atomic structure, and given its obvious push for separation of concerns, I think it would be great to split this default tweaking out from the default styling. This would create a thin but incredibly useful layer that could be used with or without the configured-styling.

Inuit is halfway there, separating object and base, but the separation currently comes from base elements vs composed elements instead of tweaks to base elements vs configured-styling. Something like:

- tweaks
   - page
   - images
   - lists

- base
    - page
    - images
    - lists

- objects
     - list-inline
     - media
     - flag
csswizardry commented 10 years ago

Hi,

This tweaks layer (reset-like stuff) is the generic layer that exists already, or maybe the base layer (type selectors such a a {}, img {}, blockquote {}, etc.).

Adding another layer isn’t really necessary (when we have layers that could quite easily cover it) within the framework, however…

I'm generally someone who likes to pick and choose exactly what I want […] most frameworks don't separate elements to a degree that they can be mixed and matched easily.

Given inuitcss’ focus on separating stuff out into modules, you can really easily create your own tweaks layer in inuitcss compatible modules in the format _tweaks.<module>.scss.

The layers will become a lot more apparent when ITCSS is fully written up :)

Undistraction commented 10 years ago

I appreciate that this is early days. Just wanted to flag it as it is something I see time and time again.

you can really easily create your own tweaks layer

My point is exactly that. I have to create my own layer because the frameworks all mix the tweaks to the generic elements in with the configured styling that the framework provides to these same elements. If these sensible unconfigured tweaks are separated they become useful in their own right and portable. Even if I do create my own base layer, it would sit below the framework layer and risk being overridden. If there was a clear separation of concerns between setting up generics and applying styles, this would not be the case.

csswizardry commented 10 years ago

I have to create my own layer…

You don’t have to; layers for the type of styling you’re talking about already exist. The layers aren’t split on role, but on specificity and explicitness. Reset-like styles are generic, type selectors are base—you can choose which layer is most suitable for ‘tweaking’ stuff.

Undistraction commented 10 years ago

I guess I'll have to wait and see what ITCSS looks like. I'm sure it will be grand ;)

Undistraction commented 10 years ago

I've just found the old version of Inuit, so what you're saying makes more sense.