If Drupal provided a blank base starting theme in D7 would it be more important as a designer that it:

Please visit http://drupal.org/node/382870 for more context on this. It's kind of a blocking issue for the further development of the new Stark theme in D7.

Eclipse

I completely disagree with this poll. First of all, those two options are not independent of each other, in any way shape or form. Following standards and adding classes does not hinder "making it easier to style for legacy browsers" just as coding for legacy browsers does not mean you cannot have standard classes.

Now, I think the real questions that need answers are really about core, not a base theme.. but anyways, if we are talking about base themes, then the questions that should be asked are:

• How much HTML should a base theme output (tons of wrapper divs, no wrapper elements of any sort, or somewhere in between)?
• How many classes should be applied to elements (tons of classes *think zen*, no classes, or somewhere in-between)?
• How much CSS should come pre-packaged with a base theme (a perfectly styled site, absolutely no css, a reset css, or none)?

Each one of these questions is better answered first for core, then for a base theme.. but regardless. That's my two cents.

--
-- matt tucker
pingVision

Ok, so thinking out loud for once, dangerous I know:

1. Class attributes are little more than dumb tokens with no semantic value.
2. Drupal is contextually rich with class attributes.

The first premise I raise in order to pose a question: if the argument for standards is not about semantics then what is it about?

Secondly, Drupal is contextually rich in attributes—we have page $body_classes, wrappers with id's and classes around nodes, blocks and comments and so on. This rich context makes it It is entirely possible to style Drupal content based on context alone, without the need to add classes to POSH markup. E.g.:

The only definitive reason, afaikt, to to add classes to POSH elements is for style. To make it easier to apply styles to this or that heading, item list or what ever, perhaps even, regardless of the context.

IMO the idea that designers want node, block and comment h2 headings to inherit the same attribute values is an assumption contrary to the rich context that Drupal templates possess. Are we going to argue that all those classes are purely for positioning? I don't think so.

As I have stated previously, to me this is all or nothing. Either we do not add class attributes to headings and get on with much more important task of arguing about semantic markup, or follow through and deliver class attributes that fully support the designer, after all that's the only dam reason to add them in the first place.

I've probably said enough on this subject, so I'll leave it at that, for now;)

After much gnashing of teeth I think we've come to a really elegant conclusion on IRC:

(1) Stark means stark. It will be as semantically valid and lovely as possible. All of Stark's tpl.php files will be pulled from core and will not include the current classes which exist only because of limited support for the child selector ( > ) in browsers such as IE6.

(2) Drupal core means more than the modules folder. We need to be careful about language. People get stressed out about "into core" and forget that core includes a whole OTHER sub-directory called "themes."

(3) We need better base themes for IE6 too (you poor suckers) aka "legacy" browsers. A new core theme will be created that alters the Stark (read: core modules folder) tpl.php files and includes the necessary classes to make IE6 output easier. tha_sun/sun will be the lead for this theme as he already has a LOT of experience supporting this browser and is comfortable providing the best starting template for themers working with IE6.

Thanks to EclipseGC for leading the charge on this one! You're helping to make theming the rox0r!!

@whatdoesitwant

There's already a jquery package that does this making IE6 css standards compliant, however it's not a small amount of code, I don't know what it's licensing is, and I doubt we'd ever get it into core (of course, I'm nothing close to the final arbiter of that decision it's just my suspicion, I've been known to make mistakes).

With that said, the "IE6 business environment" argument is getting tired (though it's admittedly true). 37signals didn't think it was that big of a deal:

http://37signals.blogs.com/products/2008/07/basecamp-phasin.html

All we're doing is providing a base template for css savvy designers to work from instead of needing to learn phptemplate inside and out. This means that it should have a very small effect on businesses of these sorts as they'll have a choice to NOT utilize stark. Other themes will ultimately still do what they feel is right, and most provide their own tpl files to support their own css, etc already. We're not screwing IE6 users with this move, we're simply saying we won't dumb down every single core tpl file for their use (garland's tpl files for example will stay largely, perhaps even completely, the same as they are currently).

Since the theme we're "providing" here doesn't even utilize more than a very minimal css footprint, which is already crossbrowser compatible, this is the right move, and should have little to no impact.

Bottom line, we are tired of holding back progress in this area for businesses that are vendor locked with Microsoft on IE6 and Windows 2000... this is 2009 after all.

Eclipse