evolution-ui
evolution-ui copied to clipboard
evolution-ui
Lay your own foundation instead of Reset or Normalize
Some days ago, on this thread on QA, Blake Wilson posted an interesting link by a senior-developer that talks about not using reset.css or normalize.css in our projects.
Here the link http://jaydenseric.com/blog/forget-normalize-or-resets-lay-your-own-css-foundation
What do you think if we try to adopt it?
I've read that article, and in general I agree, I liked it. We can possibly change some details if we need to.
Yea, I like this. I've used normalize.css many times but building my portfolio I've been using this foundation. It's nice because you don't notice that much of a difference and it seems a lot smaller. There are some things to be aware of. There is no default heading or paragraph stylings so that took some adjusting for me... and there might have been other things. But shouldn't be a problem since we will roll our own typography styles anyway. Hmm, I'm just only slightly concerned as how it would affect others' components that didn't build their stuff off of this. It's opinionated... well.. but still I don't think it changes stuff that much. Should be fine.
@Gruximillian @brianhernandez
I'm just only slightly concerned as how it would affect others' components that didn't build their stuff off of this
This is a thing that I was thinking about. We have to take care of this aspect because, as Richard said, each component should work fine as a standalone element.
If we look at our previous framework (seed UI), I think many elements were affected by the CSS rules provided by normalize.css. But what if the user downloads the CSS of a single element that does not contain any reset?
There is the all: initial; approach, but its not that widely supported yet: https://developer.mozilla.org/en-US/docs/Web/CSS/all
We can just remove the things we don't need from normalize.css and leave the migration to after the release.
@cbracco
but its not that widely supported yet:
This is the biggest problem. We need something more stable
@escorponox
We can just remove the things we don't need from normalize.css and leave the migration to after the release.
I agree with you.
@everyone
What about the need of giving to the users the ability to download single components? How could we do for allowing this?
Do you think it's better if the user must download at least two separate CSS files or a single one?
In the first case, we could have a base CSS file which contains reset, helpers and so on, and a specific CSS file which contains all the rules for a component instead.
In the second case, we need a way for incorporate all the necessary in a single file which is compiled just in time, when the user chooses what component wants to download.
@cbracco But aren't the initial values browser dependent? I have no idea, that's why I ask.
Hmm... yea, I'm kind of going back and forth with 'your own foundation' and normalize for this project now. I think @escorponox makes a good point. Given we have limited time now, our priority is to try and make the deadline so sticking with something that is a little more familiar or widely used might be better. We can always change and update later when time permits.
@GabrieleRomeo With regards to making this as modular as possible.... Right, I think that would be nice to have some kind of build process that fetches all the rests that a particular component is dependent on and incorporates them into the CSS for the component... I just don't know what would do that or setting that up. Perhaps it isn't that difficult to do for some components manually. Again, for now, maybe having the component html, css and js files plus the optional normalize/reset file for users to download is ok. The two css file case, normalize and component file(s) may be modular enough for now to meet the deadline. Richard said it doesn't have to be perfect.
If we look at our previous framework (seed UI), I think many elements were affected by the CSS rules provided by normalize.css. But what if the user downloads the CSS of a single element that does not contain any reset?
My vote is for normalize.css and the two files to download approach. I think it gets us to our goals quicker and hits the main point of being modular enough for now. I'm thinking in most cases, if a user downloads these components they most likely will drop them into a project that has some kind of reset. reset.css and normalize.css are the most common currently from what I understand... so that's why I am thinking, for now, this is an ok decision to take.
But what if the user downloads the CSS of a single element that does not contain any reset?
I think that it is not uncommon to declare normalize.css as a dependecy and that's it. I also think that we should not bother with this for now. Just declare it as a dependency and we'll get back to this later to see if there is a better approach.
@cbracco But aren't the initial values browser dependent? I have no idea, that's why I ask.
@Gruximillian No actually what all: initial; does is resets any default browser styles to whatever the default initial value would be for each CSS property. So for example, the <blockquote> element has an opinionated margin value set in some browsers so that it appears indented from surrounding elements. all: initial; would reset the margin property to its initial value, which is auto.
There is a PostCSS plugin that acts as a polyfill for the initial keyword:
- https://github.com/maximkoretskiy/postcss-initial
The idea is that this moves the reset into the local scope of a component, instead of having a bunch of components depend on one global reset.
Not sure we want to do this but its a neat idea.
@cbracco Thanks for this info. I think that for now we should stick with what we have, but after the release we can open a feature branch to test this technique, and if it proves to be working and to be better than using normalize.css, then we'll switch to it.