CSS subystem design (was: CSS reset in core?)

Posted by kika on March 8, 2009 at 11:44am

I posted a preliminary patch over issue queue http://drupal.org/node/395116 to stir a discussion whenever we need CSS reset in core and how core CSS setup -- file structure, rulesets etc -- should look like in D7. reset.css proposal is could be the first step in having decent CSS framework in core -- or if that is not gonna happen, just enforce some sensible CSS practices.

When issue queue is usually tech bound (CSS managing API, where CSS bits should live etc) perhaps this post here could discuss what is the real life impact on theming, does such harsh reset ruleset break contributed themes and does CSS reset makes sense at all.

Comments

It's interesting from an

Posted by jrabeemer on March 9, 2009 at 5:15am

It's interesting from an academic standpoint, however it will have to work, at a minimum, with the Garland theme. My gut feeling is that a reset CSS in core is useless unless it's designed to work in tandem with the core themes. I saw your screenshot and it seems there are various layout bugs to be worked out.

As someone who does themes, my concern is how does this affect custom themes? Is your reset being shoved down the throats of other themers applying a custom theme? It shouldn't.

And if it isn't, what value does it bring? Reset CSS isn't an exact science and you can't get everyone to agree on a standard.

Core themes would have to be

Posted by elv on March 9, 2009 at 1:42pm

Core themes would have to be adapted, not the other way around. They will get a big cleanup anyway, as the default html output has been revised in Drupal 7.
Custom themes also have to be reviewed and/or tweaked for each new major release anyway, so dealing with a future reset is part of the maintenance. It would be useful to give themers a clean way to avoid loading it though, so nothing will break if you use another kind of reset (espacially for "framework" themes like Blueprint, 960, BlueTrip, Yahoo UI... that have their own reset).
But I think we both agree a reset, if any (see my 2 cent in the issue queue), has to be tailored to fit Drupal's needs.

A strategy for handling CSS and theming in the future

Posted by modulist on March 9, 2009 at 3:28pm

There's a tremendous need to begin standardizing CSS approaches, especially when you start getting into the sheer economics of theming and site building. We need to drastically reduce the time that individual shops are spending in customizing CSS. Furthermore, the effort that Drupal shops are devoting to themes need to go back to the community.

new directions

Here's where things appear to be headed in the future:

Garland will live on, but only as a legacy theme. Other existing core themes will no longer be supported at some point.
Zen subthemes will be the current de facto standard for D6, but don't get too attached to it.
Stark (Drupal 7's ultra minimalist base theme) will be the foundation for other themes
960.gs and blueprint.css will emerge as the standards for grid-based themes
jQuery will be used increasingly to build rich AJAX front-end tools for novice Drupal users.

flexibility and portability

There is some vigorous debate happening as to whether the D7 core themes should be either 1) ultra lightweight or 2) class-rich and flexible for theming. My answer is that we'll need both, and that this is a pointless "taste-great-less-filling" kind of debate.

As a matter of fact, I'd strongly recommend building a core theme that's named Lightweight (or some synonym) and building another that's named Flexible. Flexible would be rich in classes, ids and selectors for every imaginable application, while Lightweight would be aimed at the CSS purists. Furthermore, the CSS structure for Lightweight would be a subset of the classes for Flexible, so that any theming assets that you build are portable from one core theme to the other.

CSS standardization

As we evaluate 960.gs and blueprint.css, we should also strive for as much portability as possible between the emerging new standards. Certainly, we want to try to avoid having a fork in the road between the two.

In parallel, there's a group of people within the Design for Drupal initiative that are getting organized to build a CSS Manual of Style. This gives us a much-needed foundation to standardize CSS practices, even beyond what's contained in the core themes. This is a really ambitious effort, and we could use all the support we can, from developers, themers and designers alike.

We're still getting organized in our post-Drupalcon afterglow, but we're certainly open to suggestions as to where we should post content, and how it should get structured.

Would you be willing to put together a first draft of the CSS and post it as a wiki page in the D4D group? Thanks so much for reach out to us. I'm sure you'll get the discussion you wanted to stir up.

@modulist

My initial gut response when

Posted by Zarabadoo on March 9, 2009 at 3:54pm

My initial gut response when I saw the headline is "hell, no". As we discussed at Drupalcon, there should be no styling whatsoever in the core of core, and reset.css would be a form of styling. That should all be left to the theme layer of things. So one of the core theme could have it in there.

I personally use a reset.css in my own work, but I know of others that absolutely hate it. So I feel it is up to the designer/themer to use it as they see fit and not have it forced upon them. I feel this is the same for any of the css frameworks that are out there.

I agree

Posted by jrefano on March 9, 2009 at 4:24pm

I'm definitely part of the camp that feels core is for data only, while the theming layer handles all presentational markup. Core should ideally output no css whatsoever, and anything currently being output by core should be moved into a default system theme or something like that, and designers can use that theme as a base if desired.

This is obviously meant to apply to D7, I think for D6 we should all stick with Zen for the time being, as it's the by far the best option available (IMHO, of course).

twitter: threehz
d.o: jrefano

Drupal core outputs CSS in

Posted by jrabeemer on March 9, 2009 at 4:36pm

Drupal core outputs CSS in half of the core modules. I don't see that going away anytime soon.

explain why it should stay this way

Posted by jrefano on March 9, 2009 at 4:53pm

Why would it be bad to move all core css to some kind of base theme, creating true separation between the theming layer and everything else? As far as I could tell, there was pretty strong consensus on this amongst designers at DCDC. I am of course talking about D7.

twitter: threehz
d.o: jrefano

I'm not saying it's bad. All

Posted by jrabeemer on March 11, 2009 at 1:41pm

I'm not saying it's bad. All core modules are in /modules have their specific CSS in their module folder.

In terms of implementation, how & where would you move the CSS?

In any case, a patch in the issue queue would go a long way to proving that.

agreed: separation of data and presentation

Posted by mason@thecoding... on March 9, 2009 at 6:12pm

There needs to be a separation of data and presentation. If we let core (and contrib modules eventually) stick to giving us the data as cleanly as possible is will make it much much easier for designers and themers to bring their "A" game to the graphics, markup, and css. Let us choose what css to use, and not force any more clumsy defaults and overrides into every project.

As of D6 we have parent and child themes. This is the building block we can use to give much more power to the front end folks. We can have a beginning and advanced (and intermediate?) base theme ship with core that lay the groundwork for the final presentation themes. One might have a beautiful, fully realized design that is overly robust with markup that looks more like current drupal. Others can set up css frameworks and stop there for experienced themers and css wizards to build upon. Still another might add nothing at all and let you have total control.

--
d.o: canarymason
twitter @canarymason

Another in favor of no CSS

Posted by sheena_d on March 9, 2009 at 6:59pm

Another in favor of no CSS being output by Core. I think it would be great to have a reset.css file included in a Core theme, but not by Core itself.

There are some issues with

Posted by kika on March 9, 2009 at 9:21pm

There are some issues with no-CSS-in-core idea:

We have some UI functional components (tabledrag, password checker etc) what just do not work without assitive CSS. These components need to work always and in every theme and overriding the functional part of the CSS styling in contrib modules does not make sense at all.

As I mentioned in issue http://drupal.org/node/395116#comment-1332002 it's about time to look at core CSS and figure out how to break it into proper chunks. Should we separate functional and aestethic CSS in drupal core -- and where the split between them lies (example. green and red in password checker)? Should be create modular CSS pieces per component? Should we learn from http://jqueryui.com/docs/Theming/API ?

There is another issue: the starting point for themers. There are several points in our theme/CSS pipeline what theme can set as a basis:

pure CSS theme based on core CCS
subtheme of core theme
new theme from scratch and use core CSS
new theme from scratch but throw core CSS out of the window (or parts of it)
subtheme of contrib theme (what itself can be any of the above)

When there is no core CSS, there will be options:

subtheme of core theme
new theme from scratch (no core CSS, remember)
subtheme of contrib theme (what itself can be any of the above)

CSS in core please

Posted by elv on March 9, 2009 at 10:39pm

I also think some css in core is good. Kika is right about the javascript components, grippies, collapsibles. They should look good from the start, and they need some styling.

Some css is also good to make the admin pages at least legible by default, and I think I'm mostly ok with admin.css.

I just had a look at default.css again, almost everything in this surprisingly small file could be deleted and few people would notice. Given the state of browsers the clearfix is mandatory, the rest is tiny conveniences that make things a bit more legible by default, but are probably set again in most themes anyway. Actually even Garland overwrites all default.css styles except the clearfix (of course) and the border-collapse on tables.
I guess we can say clearfix is functionnal, the other styles here are aesthetic/legibility.

My thinking isn't that these

Posted by mason@thecoding... on March 10, 2009 at 3:09am

My thinking isn't that these styles should go away. I think they should be cleaned up and moved to one of the base themes that come in core. When you want them all you'll have to do is extend that theme with a subtheme. And you'll also have the option not to, thus avoiding the hunt and peck game of css overrides. I think this will be a benefit to novice themers as well since they won't be left wondering where all these styles are coming from.

This really should change your original list of theming approaches much. We'd just be establishing parent/child theme hierarchy as the 'standard' way and making it less ambiguous where the css is coming from.

--
d.o: canarymason
twitter @canarymason

functional components

Posted by kika on March 9, 2009 at 11:12pm

As in opposed to slim defaults.css, system.css is a monster, a mashup of everything imaginable. Amongst the mess there are functional components mentioned above:

autocomplete
fieldsets
textarea grippie
password confirmation
table sticky headers + tabledrag
progressbar
teaser splitter (boo!)

and some non-js UI components too:

tabs
drupal_set_message styles
tree menus (it's actually in system-menus.css, a first step towards modularization!)
misc form elements (required signage etc)

OMFG yes, system.css is the spawn of Satan

Posted by modulist on March 10, 2009 at 12:02am

If you only knew the person-months that my firm has wasted on trying to overwrite poorly chosen defaults! Was it built by the Drupal for Evil folks?

@modulist

So

Posted by elv on March 10, 2009 at 12:26am

Should we keep only js-related styles on system.css? Where would we put the other styles then? Tabs, dsm and others are still useful.

I agree that js-related css

Posted by mason@thecoding... on March 10, 2009 at 3:35am

I agree that js-related css presents some issues. Ideally I think they can move to a core theme as well, but perhaps there's a case for keeping them. Either way they should make use of a namespace so it's easy to find/use/overwrite/remove them. We're thinking about css namespaces for the manual of style. http://www.mindmeister.com/maps/show/17044081

--
d.o: canarymason
twitter @canarymason

correct, non-member link:

Posted by kika on March 10, 2009 at 9:23am

correct, non-member link: http://www.mindmeister.com/17044081

The only problem I have with

Posted by Zarabadoo on March 10, 2009 at 4:42pm

The only problem I have with the JS related css in core is that it is all lumped into on gigantic file. So if you wanted to tweak one effect, you either override the existing css or you replace the whole file. I would like it if each effect was it's own file. The number of css files in core should be going down as long as our recommendations go through, so it should not pose too much of a problem I would think.

agreed, modularization of

Posted by kika on March 10, 2009 at 5:15pm

agreed,

modularization of JS/functional CSS is mentioned here several times. Number of CSS should not be a problem when CSS aggregation is in place.

There is just not a problem of "gigantic system.css", CSS for UI components tend to scatter in between many files. Random example: node.css now hosts partials of fieldset CSS and also input format CSS -- in my view textareas and input formats attached to them are generic form widgets, not just node-related. The list goes on. Let's clean this up.

No reset.css, please!

Posted by geerlingguy on March 10, 2009 at 3:41am

I am opposed to reset.css, or any other non-functionality-related CSS in core. I would much rather have a solid base theme (like Zen) from which people can grab the CSS they want/need. If we want reset.css, stick it in that base theme, but definitely not in core.

To summarize

Posted by kika on March 10, 2009 at 3:26pm

We deal with different types of core CSS:

Functional CSS:

there are functional CSS pieces for UI controls -- usually JS-related -- what need to be present in any theme: pure core, core themes, contrib themes. Disabling and overloading that CSS should be very rare. Examples include autocomplete, fieldset -- more listed here http://groups.drupal.org/node/19817#comment-68602 but there are likely more elements.
styling these elements requires defining a common, agreed CSS base to build on top to. It can either be default browser styles; a separate reset.css what is invoked before UI controls CSS or a hybrid where reset and UI control CSS are present in same CSS (file(s)).
in some cases some core or contrib themes want to introduce theme-specific, aesthetic styling of these elements (custom progressbar background, custom throbber etc).
last point is still pretty uncharted territory but some advanced themes may also overload functional CSS and JS for these components (yellow fade technique or closable checkboxes) etc.

Quasi-functional CSS:

there are CSS pieces in core what fall into gray area of functional/aestetic split. Some of them improve accessibility / legibility of UI and typography, some of them contain just CSS "every theme always has anyway". Examples include form styling, clearfix, ul/ol/dl/blockquote styles etc.
styling these elements also requires defining a common, agreed CSS base to build on top to. It can either be default browser styles; a separate reset.css what is invoked before quasi-functional CSS or a hybrid where reset and quasi-functional CSS are present in same CSS (file(s)).
big number of themes do not need this styling at all, some of them try to replace some of it with CSS frameworks (their own resets, typography.css, plugin/forms.css and likes) and surprise -- SOME themes are really dependent on this CSS provided by core.
being so loose and replaceable this CSS raises the a lot of questions whenever it should be in "pure core" or in core themes (or not exist at all).
When being only in core themes, is there are a subset of this CSS what is the virtually same in all core themes, meaning it could be separated and moved alongside proper functional CSS?

Aestetic/custom CSS:

provided by core themes. Not too many problems with it, maybe just a question "what makes a theme suitable to build a subtheme on top of it".

Actions

Posted by kika on March 10, 2009 at 5:31pm

So proposed actions:

Let's identify functional UI CSS from system.css, node.css etc first and move it to a separate file / set of files per component (up for discussion which files we need)
Take a hard look what's let's of default.css and system.css and decide what to do with it ;)

In parallel let's discuss further of "CSS in core in general" issue. There could be interesting approaches, such as providing a meta/root theme located in, say "themes/core" or "themes/system" where all core .css files (and tpl.php files?) live. All themes are based on this by default, all theme .info files have property "base theme = system" or "base theme = core". If you delete it in your theme, you are on your own in vast wilderness -- but you can always hand-pick some core CSS files you you want to. This could greatly improve the visibility of core theme subsystem but in the same time breaks one of the house rules of drupal: each module should self-contain all the files it needs and uses.

"providing a meta/root theme"

Posted by elv on March 10, 2009 at 5:44pm

I like this idea! But maybe it's better to add an optional variable in .info files to explicitly say "I don't want to use core styles", rather than setting "base theme = core"?
If I create a Zen subtheme, can it have two base themes, Zen and Core?

I tried to follow standard

Posted by kika on March 10, 2009 at 5:57pm

I tried to follow standard subtheme flow. http://drupal.org/node/225125
Zen has to pick first what it's base theme (core or NULL). If you base your work on zen, you are dependent on that decision.

first proposal

Posted by kika on March 10, 2009 at 9:53pm

After discussion in IRC, root/metatheme idea evolved into a file layout proposal. We take advantage of already existing subtheme flow http://drupal.org/node/225125 but we introduce a first ancestor to a cascading theme chain, a "core theme" what contain all the css and tpl.php files extracted for current /modules and /misc folders.

This brings visibilty to core-provided markup and styling and explains theme chaining system with a concrete example.

Buy default all themes should be based on core theme, but there is way for seasoned themers to ignore it and base their theme on nothing eg clean state. Note: this only works for CSS, for tpl.php Drupal system still needs default implementation, meaning files in theme/core/templates still are used even then theme is not based on core. (TODO: this is weird, no?)

Note: this file layout below is based on what we currently have, the proposed CSS cleanup / split into modular components / introducing reset ;) needs to be done too.

So, a proposed file layout:

Core theme: a root/metatheme:

# almost an empty file. no "base theme" line!

theme/core/core.info

# Core theme: a generic theme what provides the default implementation for  
# all CSS/XHTML Drupal generates. The rest of core themes are based on
# this theme. You can base your theme on this by having a line 
# "base theme = core" in your theme .info file.
# To start with clean state with no core-provided markup, uncomment that
# line. + ...warning about functional ui CSS...

theme/core/README.txt 

# we need this, right? It's kinda like Stark's one.

theme/core/styles/layout.css

# Styles. Put styles and tpl.php to separate dirs. 
# do not have to but is a bit cleaner

theme/core/styles/admin-rtl.css 
theme/core/styles/aggregator.css
theme/core/styles/block.css
theme/core/styles/book-rtl.css
theme/core/styles/book.css
theme/core/styles/color-rtl.css
theme/core/styles/color.css
theme/core/styles/comment-rtl.css
theme/core/styles/comment.css
theme/core/styles/dblog-rtl.css
theme/core/styles/dblog.css
theme/core/styles/defaults-rtl.css
theme/core/styles/defaults.css
theme/core/styles/farbtastic.css
theme/core/styles/field.css
theme/core/styles/forum-rtl.css
theme/core/styles/forum.css
theme/core/styles/help-rtl.css
theme/core/styles/help.css
theme/core/styles/locale.css
theme/core/styles/maintenance.css
theme/core/styles/node-rtl.css
theme/core/styles/node.css
theme/core/styles/openid.css
theme/core/styles/poll-rtl.css
theme/core/styles/poll.css
theme/core/styles/print-rtl.css
theme/core/styles/print.css
theme/core/styles/profile.css
theme/core/styles/search-rtl.css
theme/core/styles/search.css
theme/core/styles/simpletest.css
theme/core/styles/system-menus-rtl.css
theme/core/styles/system-menus.css
theme/core/styles/system-rtl.css
theme/core/styles/system.css
theme/core/styles/taxonomy.css
theme/core/styles/tracker.css
theme/core/styles/update-rtl.css
theme/core/styles/update.css
theme/core/styles/user-rtl.css
theme/core/styles/user.css

# Templates

theme/core/templates/aggregator-feed-source.tpl.php
theme/core/templates/aggregator-item.tpl.php
theme/core/templates/aggregator-summary-item.tpl.php
theme/core/templates/aggregator-summary-items.tpl.php
theme/core/templates/aggregator-wrapper.tpl.php
theme/core/templates/block-admin-display-form.tpl.php
theme/core/templates/block.tpl.php
theme/core/templates/book-all-books-block.tpl.php
theme/core/templates/book-export-html.tpl.php
theme/core/templates/book-navigation.tpl.php
theme/core/templates/book-node-export-html.tpl.php
theme/core/templates/box.tpl.php
theme/core/templates/comment-folded.tpl.php
theme/core/templates/comment-wrapper.tpl.php
theme/core/templates/comment.tpl.php
theme/core/templates/field.tpl.php
theme/core/templates/forum-icon.tpl.php
theme/core/templates/forum-list.tpl.php
theme/core/templates/forum-submitted.tpl.php
theme/core/templates/forum-topic-list.tpl.php
theme/core/templates/forum-topic-navigation.tpl.php
theme/core/templates/forums.tpl.php
theme/core/templates/maintenance-page.tpl.php
theme/core/templates/node.tpl.php
theme/core/templates/page.tpl.php
theme/core/templates/poll-bar-block.tpl.php
theme/core/templates/poll-bar.tpl.php
theme/core/templates/poll-results-block.tpl.php
theme/core/templates/poll-results.tpl.php
theme/core/templates/poll-vote.tpl.php
theme/core/templates/profile-block.tpl.php
theme/core/templates/profile-listing.tpl.php
theme/core/templates/profile-wrapper.tpl.php
theme/core/templates/search-block-form.tpl.php
theme/core/templates/search-result.tpl.php
theme/core/templates/search-results.tpl.php
theme/core/templates/search-theme-form.tpl.php
theme/core/templates/user-picture.tpl.php
theme/core/templates/user-profile-category.tpl.php
theme/core/templates/user-profile-item.tpl.php
theme/core/templates/user-profile.tpl.php

2. Builder theme, based on core

# With "base theme = core" line

theme/builder/builder.info

# Builder theme: a modern building-block theme...
# ...
# You can base your theme on this by having a line 
# "base theme = builder" in your theme .info file.

theme/builder/README.txt 

# Styles, usual CSS framework stuff

theme/builder/styles/grid.css
theme/builder/styles/typography.css

...rest of styles...

# Templates

...

Problems:
- what about .js for functional UI components?
- CSS and tpl.php inheritance work a bit different. tpl.php absolutely needs default implementation when CSS does not always have to (pehaps just functional/js css). So so even when you base your theme on void, you still get your themes/core/templates/ tpl.php files loaded. this breaks the mental model.

"So even when you base

Posted by elv on March 11, 2009 at 12:22am

"So even when you base your theme on void, you still get your themes/core/templates/ tpl.php files loaded. this breaks the mental model."
Not really, even if you include absolutely no core styles, you still get the browser's default ones :) You never really have no styles, so it seems logical to also always have default html.
This difference doesn't bother me because there are other ones anyway. Correct me if I'm wrong, but you can't avoid loading an inherited template, only override it, while you can simply avoid loading a core css file with something like stylesheets[all][] = system.css in the .info file.
Regarding .js for UI components, I'd generalize and consider we always need them. Re-theming things like the throbber or the grippie is an edge case imho. Just by putting them in a separate file, we could avoid loading them in the .info file.
Or do we need a drupal_remove_css function for advanced theming?
So would you group tpl and css from modules in the same directory only for core modules? A different organization between core and contrib modules seems a bit odd.

Possible suggestion

Posted by wretched sinner... on March 11, 2009 at 12:42am

wretched sinner - saved by grace's picture

It was mentioned earlier by someone about maybe having two core themes which could be extended. With a push to remove all themes but Garland from core (http://drupal.org/node/315533), this could tie in quite well. (I realise some of this may be a little off the CSS topic, but I think it all ties in well)

What I see could happen is to easily have 3 levels of theme design. A beginner level would be based off Garland, and would provide a larger amount of styling of content and probably a smaller number of block regions. An intermediate level would be based off Stark, which could become more of a Zen-like theme, providing fewer styling defaults and more block regions. This could even be the level that kika has proposed, where the only inherited CSS would be the 'functional' (however that gets defined) CSS, and the whole presentation would be left to the theme designer. If the base was built correctly, it could open up the often talked about CSS only themes.

The third level would be the advanced, where themers would build completely from scratch, with no CSS at all coming in, not even functional CSS. If the CSS files were named well, and in small pieces as kika suggested, then themers could copy or include the requested core CSS files (this might need to be made easier by say expanding the scripts array to take another argument eg scripts['core'][] = forum.css - and could even possibly work for pulling CSS from contrib modules etc - totally different issue!) This would give a completely clean, un-reset state to work with, from which designers can pick their reset of choice if required.

Also, somone mentioned about the problem of not having a theme self contained with all it files - this doesn't happen now with themes, as many do not override the standard tpl.php files, and also use some of the core styles, even if they don't realise it. The only way to have themes be completely self contained would be to require that existing files which are used are copied into the theme directory. This would needlessly bloat themes, and create more work to track core changes for theme maintainers.

I hope I've made some sense with this...

ok

Posted by CZ on February 26, 2013 at 10:41am

Let's turn the proposal into a wiki, please.

Posted by modulist on March 12, 2009 at 12:30pm

I've been following along and been truly impressed by the caliber and consensus I'm seeing in this discussion. I think everyone's in full agreement that we do need to standardize CSS in order to making theming more efficient and more portable.

Kika, I really appreciate the leadership you've taken on this. Can you move your First Proposal to a wiki page, so that folks can contribute to it?

Let's keep the dialog separate here, so that someone coming late to the discussion can still make sense of it.

@modulist

More extensive/advanced theme settings

Posted by jhebel on March 12, 2009 at 3:41pm

I'm also really impressed with the quality of ideas flowing here and grateful for everyones energy going into this important area of development.

I vote NAY for reset.css in core and YAY for splitting up functional, semi-functional and functional CSS. The core/metatheme idea your putting together, kiko, looks great and a wiki page for this is a good idea.

I'd like to get your thoughts on an idea for providing acute control over which CSS files load by extending Drupal Theme settings:

On the admin/build/themes/settings/XYZ-theme page, you'd have an "Advanced Theming" fieldset that provided a dynamically generated list of all CSS files loaded by the currently enabled core and contrib modules. Every listed CSS file would have an adjoining checkbox to allow users to disable it, thus preventing it from loading. (this is along the lines of a drupal_remove_css function with an administrative application)

Additionally we could hook in and set theme-specific defaults via a themes' .info file:

css_disable_list[] = 'theme/core/styles/block.css, theme/core/styles/comment.css, theme/core/styles/search.css'

Does this sound like a viable approach to controlling which .css we want loading?

Wiki page

Posted by wretched sinner... on March 13, 2009 at 1:50am

Hi All,

I've created a wiki page with kika's first proposal posted: http://themingdrupal.info/wiki/css-subsystem-design-first-proposal.

It's my first attempt at a Drupal Wiki, so let me know of any issues!

why take the discussion out

Posted by mortendk on March 13, 2009 at 12:15pm

why take the discussion out of this group?
we have the wiki functionality right here - and we need to show the rest of the community what it is we want as front end geeks

/morten.dk king of rock
morten.dk | geek Royale

Wiki

Posted by kika on March 14, 2009 at 7:57pm

with proposal is up: http://groups.drupal.org/node/20109. Let's continue discussion here.

Flexible CSS Grid

Posted by CZ on February 26, 2013 at 10:42am

Reset: Mandatory | CSS Framework: (very, very) optional

Posted by andjules on March 27, 2009 at 5:51pm

I just wanted to add my 2¢ with regards to CSS in core/re-work of core themes...
particularly modulist's post above (http://groups.drupal.org/node/19817#comment-68511).
As far as CSS best-practices go, I think RESETs are here to stay... but I think CSS frameworks will only be adopted by some (mostly CSS geeks; I'm probably one of them).
More importantly, Drupal appeals to many different types of users - css-savvy design-oriented experts are only one subset.
Resets are generally easy to work with... if the user is unfamiliar with them, the only thing they'll have to figure out (probably through painful trial and error) is that they can delete some of the cross-browser hacks. When they figure it out, it's easier on their brains, not harder.
CSS Frameworks are an entirely different matter. I think they offer great advantages, but only to folks willing to completely relearn how they develop CSS.

In short: I think:
- no CSS reset in ('code') core
- all included/core themes should (by mandatory/default) include a CSS reset (probably Eric Meyer's is the best documented/discussed/universal standard).
- Ideally, I think the included (core) themes need to include (as always) something for non-designer/non-css-savvy folks (an updated Garland? whatever), as well as clean, best-practice, 'bare CSS' themes for designers. If there is enough demand/support/commitment from the community, I don't see a problem with including several 'bare CSS' themes for different development styles (traditional/bluetrip/960gs/etc.)

Kika already described three

Posted by Xano on April 2, 2009 at 1:16pm

Kika already described three kinds of CSS in core. I believe there should be four kinds:

Functional CSS (/css/system.css)
This is basic styling for widgets like resizable text areas, drag and drop, autocomplete fields, etc. NO AESTHETIC STYLING
Browser reset (/css/reset.css)
Core's output should be clean and look roughly the same across different browsers.
Cross-theme styling (/css/style.css)
Some things should best look the same across themes, like messages, help links, etcetera. This is to give users a consistent experience and to prevent themers from having to do reappearing things multiple times.
Aesthetic styling (/themes/X/style.css)
These are the themes themselves.

Note that I put the core CSS files in the css folder, because I believe /misc is not the right place for them. Also note that if for a certain theme you don't want the core CSS files, all it takes is one short line in your theme.info file to prevent it from being used.

Further discussion

Posted by alanburke on October 11, 2009 at 2:07pm

Has the discussion on this moved elsewhere?
The wiki at http://groups.drupal.org/node/20109
is fantastic - a great roadmap for how things should be done.
I've stumbled across a few issues
http://drupal.org/node/575294 - "Seven theme clean-up"
http://drupal.org/node/592018 - "Seperate 'functional' and 'stylish' styles in system.css and defaults.css"
which would be better handled by have this base document accepted as the standard - and then working on the implementation in separate issues.

I believe we should constantly strive to push HTML and CSS to the theme layer.

Young Hahn's proposal
http://developmentseed.org/blog/2009/mar/01/limitations-drupal-theme-layer
would even be best served by implementing the ideas in the wiki as a first step.

I believe we should constantly strive to push HTML and CSS to the theme layer.

CSS subystem design (was: CSS reset in core?)

Comments

new directions

flexibility and portability

CSS standardization

Group organizers

New groups

Group notifications

Hot content this week