meta: the role of stark & bartik in Drupal8 twig [#2277913]

we need to align what the role of stark & bartik is in drupal8
right now were adding in classes n markup n stuff into stark, that maybe should be in bartik (or create a bartik2)

My suggestion:
stark as naked as possible that means no classes no markup no nothing besides of variables (well kinda)

Bartik: default markup with a set of classes etc.

"DrupalBase" theme:
if its gonna be to much of a pita to cleanup bartik. we should really start out a drupalbase theme that created a "good base to build on" with a set of classes & markup structure so we have a theme thats easy to start out on from a css & markup perspective.

Comments

Comment #1

RainbowArray

she/her

English

Twin Cities, Minnesota

CreditAttribution: RainbowArray commented 1 June 2014 at 19:12

The way things currently work is that Stark is the output for all of Drupal's core templates and css, while Bartik modifies those templates and css to create a more aesthetically appealing theme.

If we're saying that Stark should be "naked" with no classes or css, then there are two routes on how to do that.

1) Create a separate set of templates for Stark which override the templates defined in core, and which strip down to barebones markup as well as removing all css.

2) Strip down all of Drupal's markup in core templates and remove css files from Drupal core. In theory those templates with classes could be recreated in the DrupalBase theme you're suggesting.

A lot of work went into creating the CSS architecture for Drupal 8, and the subsequent markup to make that a reality. Stripping that out of Drupal's core templates and CSS files means that essentially Drupal 8 has no CSS architecture: instead it's just a mess of difficult to style HTML elements with no real structure. Even if all of that is moved to DrupalBase, then it still means that Drupal 8 has no CSS architecture, but it does have a theme with some architecture if somebody wants to use that as a base for their theme.

Personally I think it probably makes sense to define the class-based markup for templates closer to the modules that define them, rather than in a separate theme. If that's the case, then what you could do instead is have:

1) Stark, which outputs the core template markup with the classes based on Drupal 8's CSS architecture. The primary purpose of Stark has always been to see what Drupal 8's core templates is outputting by default, and this would continue to do that.

2) Bartik, which overrides some of the core templates and CSS to create a more aesthetically pleasing theme.

3) SuperStark, which overrides core templates to strip out classes and CSS to create a "clean" baseline to start from.

This is late in the process to start a complete overhaul of every template in Drupal core, so the benefit of the latter approach is that if you want to work on templates for SuperStark, you totally can, Morten, and if you get through all of them, then you have a Drupal base theme that you can use as a base for any themes you want to develop. If you're not able to get through all the templates in time for 8.0 launch, then this is still something that could be included in a future feature release of Drupal 8. So this avoids a holdup of Drupal 8's launch just because a potentially consensus reworking of all of Drupal's templates is going on.

I appreciate where you're coming from here, and I'm sure there are some themers who agree with the approach you'd like to take with markup and CSS. I think the above is the most realistic way to make that happen.

Comment #2

alexrayu CreditAttribution: alexrayu commented 5 June 2014 at 18:50

For me, the 3 default themes - one naked theme demonstrating the core (stark), one nice functional theme (Bartik), and one admin theme (seven) is quite enough to go with Drupal out of the box. 3 is enough for me.