Add CSS resets to core

An interesting topic, that will probably bring lots of contrasted opinions (remember the topics about a grid system in core?).

Let's give mine straight away: I'm generally againt the whole idea of a "reset", and I think Meyer's approach is wrong.

The promise of such a reset is more consistent styles across browsers. Great!

So what's wrong with Meyer's reset (and most resets, including Yahoo's)?

- Lots of useful properties are zeroed, so you have to set them again in your own theme or in Drupal core css. And this includes tags you usually don't use or care about. When was the last time you didn't want margins above and below all your paragraph tags? Do you really want to set the margins and paddings again on every form element? It gives themers a lot more work.

- You obviously can't use the reset as is, you *have* to set the properties again to sensible values, or your pages will be less usable. Otherwise they won't look like "normal" pages by default. You lose font sizes for titles, heavier weight for strong... Some are obvious, but you may overlook less obvious elements. Kika's screenshots are a good showcase of what is lost in legibility if new base styles are not added.

- Properties end up being overwritten several more times (Drupal is already often guilty of this), it's often said it's more overhead for the browsers. Not only when the page is rendered, but also when you change the styles with jQuery. It also makes css "debugging" harder.

People will either have to:
- Spend time writing their own styles to be applied after the reset.
- Use some kind of "base" stylesheet (a job for drupal.css?) that will be yet another layer of styles that adds to the complexity.

In the end with resets there are three steps :
Browsers default styles -> zeroed styles -> "good" styles.
The second step is useless! We can directly set the properties to "good" values instead of zeroing it first. Which brings us to my favorite "reset":

Only two steps with Faruk Ateş' initial.css base styles: http://kurafire.net/log/archive/2005/07/26/starting-css-revisited

The idea is that browsers default styles *have* differences (there's a comparison here: http://css-class.com/test/css/defaults/UA-style-sheet-defaults.htm), but overall they are pretty similar. So you only need to set a handful of properties to obtain very similar renderings. It's not exactly a *reset* actually, it's rather a light set of carefully chosen default styles.
If you create a *web app* with a tight design and really need a lot of control, Meyer's approach would suit best. But I think for most Drupal *websites* a few pixels here and there doesn't matter much. At least it doesn't for me, and I'm a design/themer who tends to be a perfection freak when it comes to css. I've been using variants of this initial.css for years in every site I've been building and found it to give far enough control and consistency.

So does it have it's place in core?

That's a tricky question (why the hell did I ask? :) The idea with *initial* is that you tweak it to your needs, it's not meant to be used as a "one reset to rule them all". Instead you tweak it for the for the particular theme you're working on. By the way, we wouldn't use it as is in Drupal anyway because some of the choices Faruk Ateş made wouldn't suit: we wouldn't set the paddings and borders on fieldsets to zero because we use them a lot in the admin and need them to be visible.
If it's part of Drupal core you can't modify it, you have to overwrite parts of it and it becomes a two steps process like with any other reset. I think it's still better, as it needs far less styles rewriting and creates less overhead, but a part of it's beauty would be lost.

Does any reset have it's place in core?

I think so, even if it's Meyer's reset. I also think that like Drupal's default css, it should be optionnal so we can avoid the "override the overrides" madness if we prefer another reset flavor.

Subscribe

OK the point of resets is to zero things out so ALL BROWSERS display css the same, especially on different OS's. If you don't reset, then all of the browsers do different things and your site will be messed up. I have been tacking styles for a long time and take my word for it if you don't reset, there will be a site that doesn't look right and is pixel perfect in all browsers. My clients expect pixel perfect as do I, Drupal needs to get with the ballgame or amateurish sites will be strewn about the web with the name "Drupal" attached to it.

I think for most Drupal *websites* a few pixels here and there doesn't matter much. At least it doesn't for me, and I'm a design/themer who tends to be a perfection freak when it comes to css.

I recall requests for professional mock-ups requiring "up to the pixel" fidelity to what was provided by designers

OTOH, the last time I checked Seven theme had a reset.css
which BTW was messing with dblog filters' css, since theme css were loading "after" module's css discarding all the tweaks residing there

EDIT: last statement is false (reported at #674354)

just for reference http://drupal.org/project/issues/drupal?text=reset.css&status=All&priori...

Although I really like the idea of using reset, I don't think it should appear in Drupal core. A good place for it, however, is in a base theme.

Usually when you use reset.css, you also give it base.css to bring all the browsers back to a reasonable standard. If you neglect to do this, then all your base elements have non-standard and ugly margins. You can read more about Reset, Base, Fonts and Grids on the Yahoo's CSS pattern. The general idea behind it is that the Reset brings all browsers back to ground 0, Base will bring all the browsers back to the same reasonable standard, Fonts introduces some standard font classes and line spacing, and then Grids introduces a standard set of classes to help in recreating grid systems using CSS.

This is not a place for system.module; I do believe it's a good place for a base theme in core however. If we were to bring these patterns into Drupal core, I'd opt in for 960. Also, themers don't like to be forced into a certain way of theming, and I think we should respect that. The theme should have reset, not system.module.

enforcing a reset.css and/or base.css will improve module's styling, which most of the cases aim Garland (and now D7 Seven) and brake with other themes

Abstracting from the discussion whether reset.css is useful or not, I don't see the point of this patch if:
1. reset.css is not loaded before all other core stylesheets.
2. other core stylesheets are not rewritten to make use of it

The current patch makes it no different than adding reset.css using info file. It just adds another unnecessary assumption. If we want to add reset.css properly then all core stylesheets need major refactoring. I will be working on that during Drupal 8 development cycle.

In the end, everyone "resets" browser default styles, but everyone does it differently. Some very aggressively and others very minimally.

You can't satisfy all CSS coders with one reset. Imagine themers who don't agree with Drupal's reset, resetting Drupal's reset in their own theme. (Eek.) Ideally, core CSS is written in a way no themer will ever need to touch/override it. (Ideally.)

Eric Meyer's reset was originally meant as a simple starting point that should be tweaked and extended for your own projects. If you'd put this reset in core, away from a theme, it cannot be tweaked. Well, unless you override reset.css in your own theme. But what would the point be of a reset.css in core if everyone overrides it anyway? (Resetting a reset ...)

If I (as a themer) want paragraphs with 1.5em margins, who's Drupal to say that they should be 1em? Or even 0? The same goes for the gray table styles currently in Drupal; I don't want or need those because they don't look gray in my design. So I override them. In about every theme I build, actually. In fact, I created my own base theme for it; it strips all unwanted presentational styles from core so I don't need to do it separately for every theme. I don't think this should be necessary. I personally hope that future Drupal releases will focus more on functional styles (such as #autocomplete and fieldset.collapsible) and remove the presentational stuff. Presentational stuff should be in themes.

Themers who want ready-to-use resets for Drupal would be better off using a base theme. There are base themes for about every reset out there; Eric Meyer's but also YUI's and some less famous ones. Only problem is that these themes don't get much attention. So, a CSS coder just starting with Drupal thinks he's got to implement the reset himself (which can be a bit more difficult with Drupal; styles from system.css conflict with the Meyer reset for example) and complains that there's no Drupal-optimized implementation of it in core. Perhaps these base themes should just be given a more prominent place that is easier to find for new themers; a better taxonomy structure for themes on Drupal.org comes to mind.

I do not see a need for having a reset stylesheet in the core. One wonderful thing about Drupal is how it can be used out of the box. Drupal themers generally are so involved in markup and style coding that it takes little effort to include one of the many reset stylesheets from the web (Eric Meyer, Yahoo, etc, etc).

still... modules come before theme, and module developer provide (out of the box) support for the default core theme only,
which usually includes counteracting styles not present in other themes, and not needed in core themes if they would have a reset.css
thus the proposal to standardize one of the available resets

of course, other radical themes might still confront issues,
but most of them won't

resets are intended to unset default browser's styles, therefore they bring more normalization than we currently have

I'm not convinced that this is a good idea. Totally not, actually. But let's first move this issue to the proper component, and discuss...

Well, I never came across this issue before ...that is till I was actually faced with trouble and needed a solution. Here's my two cents on the subject...

The following are facts:

- Nobody argues that this is an issue faced by many (not saying: "by most"), so a proper solution would benefit them.
- Modules' css is favored over themes' css (or so I guess from what Antonio says in #15)
- Some say this should be taken care in core, while others think it shouldn't.
- Lots of modules that happen to be used by the majority of drupal users tent to eventually get merged in core (think cck, poormanscron etc.).
- This issue is differed for D8 (and still not sure if it will ever be decided to be implemented in the end).
- If a feature needs/is to be implemented earlier than next major release, then a new project is the only way I've seen it happen.

...you see where I'm getting at ;)

If this was implemented as a contrib module, then:

- We wouldn't have people arguing if it should happen or not - it would be a matter of choice.
- It could be ported to any version of drupal - be it D6, D7, D8
- The sooner this would get realized, the more users you'll have, thus more testing and feedback, thus faster development/realization.
- The more users we'll have, the more chances this gets in core ;)

If this was implemented as a contrib module, then:

I must say:
- it would be such a tiny (wretch) module that it wouldn't worth it, thus, no one would have it
- it would certainly break a lot of themes, due to modules having CSS rules addressing default core themes; not to provide, but to neutralize some specific effects (paddings, margins, line-heights, whatsoever) and themes being built on top of that...

this is a matter of good practice,
have a CSS reset before modules start fighting and tweaking to address minor tunings for particular themes

where does a reset.css belongs to?
AFAIK it is intended to be the first CSS

...it would be such a tiny (wretch) module that it wouldn't worth it, thus, no one would have it

I won't argue further, but you won't be able to see unless you actually do create a project for this.

...it would certainly break a lot of themes, due to modules having CSS rules addressing default core themes

I am sure it would break a lot of themes. I am also sure that the people using this module would do so because they were creating their own theme and are looking for an easy way to make sure they have a *really* clean start, ...so not an issue. Of course one might argue that then they should implement the reset directly in their theme then ;)

...I do realize though that most modules are built based on these core css rules and that this might mean potential extra work (trying to theme the modules too).

Bottom line is that if you keep it here as a core feature request/task it will take ages till it gets implemented -if ever- and in the meantime the best we'll have will be another core patch to (remember to) maintain. Just saying...

...btw the patch is against D7. Did anyone try it in D6?

Edit: I think it would do fine since all it does is create a reset.css file + add the code in system.module to make sure it loads *first*.

1. CSS like this belongs to themes, not modules.
2. The proper place would be a base theme. But only if that reset.css can be re-used without modifications by other themes.
3. We still don't seem to have a fundamental agreement on whether a reset.css is used by all designers/themers, and, in case really everyone uses one, which one to use.

I'm with sun on this one. It should be used on base themes rather then in the module namespace. Modules should not force themes into a given CSS pattern... I pinged Jen Simmons on IRC for her thoughts on this hitting Bartik.

I don't see a compelling reason being offered here for why we need to add a reset stylesheet to core. This issue is two years old, and seems to have only been reopened by people saying no and cleaning up old issues.

1) Many front end developers either don't like reset css or have a particular one they want to use. Why force something on people?

2) Everyone can put whatever reset css (or not) into their custom theme or base theme. There is nothing in core that prevents people from doing so or makes it harder to do so.

3) There is a movement in the Drupal front end developer community to remove as much CSS as possible from core. This is adding more. Without a good reason.

Please no. No. No.

For example, Bartik has some CSS resets in html-elements. I put the ones I wanted in there. I didn't use the rest. If you toss Eric Meyer's resets at Bartik, you are going to break a lot of it.

Let's spend our time on other things.

Actually, this is a good discussion to have. Perhaps not ready for core yet, but that's exactly the point where the Design project should come into the game. I think it would be tremendously useful and helpful if the Drupal community was able to agree on one, or perhaps even three reset.css approaches to focus on. That would allow us to improve and recommend best practices for theming with Drupal, help with support issues, and similar stuff. Thus, moving this issue to the Design project and hoping to see some more discussion, conclusions, and code here.

I don't think adding a CSS reset to core is a good idea at all. Which reset to use is a personal decision and Drupal shouldn't have anything to do with it.

Also, Seven uses a reset. It didn't make things better IMO, it made them worse. As far as I'm concerned it was the source of quite a few issues during the development cycle of Drupal 7.

I can't say in any stronger words — there is no need for the Drupal front end developer community to spend time trying to agree on one way to do CSS resets. We do not need one in core. We do not need all base themes to be the same. And there is no way we are going to agree. Why start the fight, sun? Let's put our energy into more productive places.

In terms of the opinions above, I wonder why there is even a discussion about this.

If a core theme wants to use a reset -> so be it. But Drupal Core should have neither CSS or Markup in it. Leave it up to individual themers/ themes to add what they want.

In terms of the Display Layer, Core should be as thin as possible -> the same goes for modules. CSS as well as Markup.

Don't get me wrong, please. This is not about fighting. Many Drupal themers may not know of the best or recommended CSS resets out there, how they compare, what implications they have, why it might be a good idea to strip stuff from them (like it was done for Bartik?), what effect and impact they might have on markup/CSS/output generated by Drupal modules, why Seven's reset is bad, etc.pp. There's a lot to know and discuss here, a couple of things that could be documented, perhaps even a few things that we as a community can agree on, and collaborating on such kind of topics is one of the intended goals of the Design project - regardless of whether there will ever be productive output. Sharing insight and wisdom, instead of having everyone scratch their own itch.

It's confusing because you took a core issue about putting a rest in core, and moved it to your personal contrib project, to have a broader discussion about CSS resets in general as an educational endeavor. I recommend opening a separate issue for your project. Especially since there sadly is no unsubscribe option for issues on drupal.org.

I am confused, too. This sounds like a g.d.o or forum topic.

If we want to talk about CSS resets (personally I don't) in this project, we definitely should not hijack core issues just to get an audience. It's not fair to anyone, especially the person who initially opened the issue against core.

If we are discussing anything in the Design project, the point is to come to some sort of resolution in the form of either code or documentation. I think the only resolution we can arrive at for CSS resets is to add some documentation, but I don't think it would necessarily be helpful since it's not a Drupal-specific problem. I don't know that it's a problem period.

I'm moving this back to core, and closing it. We have consensus. Sun, if you want to debate CSS resets someplace else, feel free to open a new space. Like the groups.drupal.org group, or your own contrib project. The original issue about adding a CSS reset to core (modules) is done. Please do not reopen it.

... We have consensus. ...

Really?? ...well, since it was 'decided', might as well set it to the proper status too. Also:

...there sadly is no unsubscribe option for issues on drupal.org

I am with you on the actual essence of that horrible fact/issue, but since that sentence was -as I see it- used in an ironic tone in this issue, I might as well add that sadly the 'closed (won't fix)' issue status should be renamed to 'simply ignored' when it comes to some things.-

Thinking about this, and I think the best place for it is a contributed module that is loaded before all other css. i.e. has a lower weight. Just checking if someone has already done this but I can't se that they have. If there is enough demand this could then be incorporated into core at a later date. this approach would simply rest the browser css rather than contributed modules.

https://drupal.org/sandbox/2dareis2do/2275019