[META] The plan for Bartik

I think this is a major issue because it can harm the initial perception of Drupal for frontend developers. Feel free to discuss the priority.

I am happy to weigh in on my perspective from the Seven development progress on 8.0.x

Please make accessibility a part of the plan. 'Looking good' should not trump usability.

Then perhaps an issue title that better matches your intent here? "Make bartik meet D8 coding standards"?

Good looks, coding standards, accessibility, and reliability are separate issues.

1. Reliability first because it should work out of the box. Zen and the other base themes can offer the complications that might not work.
2. Accessibility next because Australia's largest shopping organisation is going through a court case on this issue. Now is the time to present Drupal as the solution out of the box.
3. Coding standards could be copied from Seven by a new developer with a mentor. I would mentor someone if they are in Sydney.
4. Good looks is something everyone will argue forever so let the discussion run out of steam before changing it. I do like the new logo proposed in a different issue.

For looks, I would change only two things, move all menus in all themes to blocks we can move to different regions and offer alternative CSS/examples of Bartik with different menu styles. The examples could be in documentation pages instead of distributed.

Is Seven complete or still in progress?

Then perhaps an issue title that better matches your intent here? "Make bartik meet D8 coding standards"?

We can discuss the plan in the comments, including the scope of the plan.

I don't see any point in hashing out a new design for Bartik, we should create a new theme if we want a new design.

Is Seven complete or still in progress?

Seven is not perfect but I think the main architectural changes are all there. We still have a fair amount of non-component CSS in Seven.

I think this issue is important and yeah - if you ask me, we should scrap the old Bartik and make it again. Using sass. Huge amount of work but in a perfect world that would be the best solution in my opinion =)

@teroelonen, Sasstik would be a nice additional theme followed by Sasstik960. I still vote for at least one theme out of the box without all the additives.

If there is a rewrite planned, can we adopt some of the low fat from Mothership?

Bartik is not really a base theme and is rarely extended. If there is no use in Bartik for three divs nested, could we remove them? they are usually used for something odd, vertical centering or similar, and could be dropped if not specifically needed.

Using Sass is absolutely needed to achieve modern, modular and most importantly maintainable front-end architecture.

Most important thing is to have good documentation -> in order to do anything in a proper way, everyone contributing should understand how and why. When we do have good architecture, Bartik should become and prime example of how themes should be done in a maintainable way. There is of course A LOT of work. Architecture should focus on how we can isolate template / sass and whatever into bite size parts that are easy to just throw away or refactor, without affecting anything other in the theme.

So yea, we have to rewrite it.

I think that Bartik should not use Sass, because you will not be able to use it in a lot of shared hosting environments.

It's impossible to get group of talented people to work on theme now days, if we are locked in using just plain css, as it's not effective way of doing things. And compiling Sass in final environment should not be how Sass should be handled either. And when we add the fact that bartik is core base theme, there shouldn't be need for compiling the theme css assets in order to get Drupal to work properly either. Compiling Sass core sass should be done by contributing parties.

The issue with Sass isn't in compiling. As jussil said, the CSS would be precompiled and committed into Drupal. The issue with using Sass is that it might be difficult to get people to agree on libraries, versions, methods, etc. And it would likely involve adding things into the theme than we haven't had before. Things like sass files, probably config,rb, maybe even gem and gem lock, etc. We'd have to make sure core committers are ok with adding those files, and supporting them.

Visually, I would like to create a new theme. Bartik's look is stale, and Drupal could use a modern, attractive theme. However, making a new theme wouldn't fix any problems within Bartik and adding a new theme or a new design to Bartik requires a good deal of buy-in from Dries and the core committers. (Also, Bartik can't be removed.) I suggest not venturing into visual changes without first getting approval from the core committers. So, instead, concentrate on refactoring Bartik the way it is.

Looking at the maintainers file, Jen Simmons and Jeff Burnz are listed as the maintainers for Bartik. Has anyone talked to either of them about Bartik's current status? It's fine if they don't want to be as involved anymore, but they should be consulted.

Hello. I'm the person who designed Bartik for Drupal 7. And I coded up most of the initial codebase.

Jeff Burnz emerged as a leader when I was in China, stuck behind the Great Firewall, after Bartik was in core and there were bugs to fix. There were also many other great people who helped with Bartik from very early on.

I haven't been involved in Drupal 8 development, so I'm not up to speed on where things are in the development cycle, or with all the details of the improvements to the Drupal theming system.

I haven't heard that Sass is being used anyplace else in core. Is it? If not, then I think that idea can be set aside pretty quickly. While there are a lot of good reasons to consider Sass in core, there are a lot of reasons not to — and last minute Bartik improvements aren't really a good place to open that can of worms. (Unless I totally missed something, and Sass is already being used for all of the core CSS, in which case, Bartik should do what core is doing and adopt Sass in the exact same manner.)

_______________________________________________

Before getting into any details of what might be done before Drupal 8 ships, I thought I'd explain the principles on most of the decisions regarding Bartik in D7 were based:

1. Because Bartik is a core theme, it will be understood by many people as "the right way" to do things in Drupal with a theme. So it should reflect commonly-held best practices in Drupal front-end development, and in the wider front-end world.
2. Bartik should be very standard and fairly conservative. I had many ideas for Bartik D7 (in 2009, including using the HTML5 doctype and including an open-source webfont), but I didn't try any of them because I knew Drupal had to be "safe". There are many great ideas out there, but Bartik's job is to be a solid, simple example — not to push the envelope of the future of the front end. (Sad, I know. Believe me, I'm all about pushing the envelope. But this isn't the place to do it. Especially this close to D8 shipping.)
3. Bartik must reflect Drupal core. It is part of core. Bartik must be fully accessible, web-standards based, and progressively enhanced. I'm pretty sure Drupal 8 can't ship if Bartik is not fully accessible. (In fact, if you know of any specific Bartik accessibility bugs, please file those separately with the appropriate flags so they can be fixed ASAP). Bartik must reflect Drupal core's code base (for better or worse). The CSS should be organized using the systems that have been created for D8. The template files should match the new core template files as closely as possible. Bartik should not be rewritten using Mothership, or Zen, or any of the other awesome contrib base themes. Bartik must be written on top of core. And in this case, it should follow the great work of John Albin Wilkins and the folks who've implemented Twig in D8. Yes, any Bartik-specific div div div div should be removed. I'd be ashamed if Bartik is the only thing left in D8 with that markup.
4. The #1 usecase for Bartik is book screenshots, live demos in conference presentations, video screencast tutorials, etc. People say "no one uses Bartik", but *everyone* uses Bartik when teaching Drupal. It should have high contrast. Work on projectors. Work when converted to black & white. (Originally Bartik was designed with a black header specifically to work better with black & white books.)
5. The #2 usecase for Bartik is for a starter theme for people teaching themselves how to use Drupal. Now, I don't advocate for this use. There are many better base themes out there, but whether we think this is a good idea or not, it is a huge usecase. When I first started using Drupal in 2005, I created my first Drupal theme by hacking Garland. It was a natural assumption to make, why wouldn't the default theme be a prime example of a Drupal theme and a great place to start making my own theme? Well, of course I learned the hard way what a bad decision that was. But it was a natural thing to do. (Did you ever read the code for Garland? It was pretty bad by today's standards. But hey — at least it was the only core theme that used CSS for layouts instead of tables!) When I created Bartik, I set out to make sure if people do hack Bartik to make a theme, they will be in good shape. They won't get half-way in and have to throw everything away. (Hopefully, they've learned along the way to fork the theme, not hack core!)
6. The #3 usecase for Bartik is for the websites of Drupal fans. This is what people say, I think, when they say "not many people use Bartik". It's true. Actually there are few websites out there using any of the pre-fab Drupal themes. Most people building with Drupal create their own custom theme. Yet, some people do love Drupal, and love using the default theme. And so Bartik was designed to be flexible and let people do a lot of different things with it — while remembering the kinds of blogs and sites Drupal core developers and other fans like to make.
7. Bartik was originally designed to be a lot like Garland. On purpose. I set out to design a theme that would become the next default theme, and I knew the community would be shocked into saying no if my new theme was too different from the past. This doesn't apply as much now that 5 years has gone by. Bartik for D8 could have been another step in an evolution. But this principle does answer a lot of "why is this like this?" questions. For example — I knew Bartik would have to use color module. Because Garland did. So it does. And supporting color module informed a lot about the design. Bartik has the 2-3 column blog layout design because Garland did. Because everything on the web then did. So Bartik still does. I didn't want to use a gradient in the header, but I didn't dare remove it. The biggest risk I took with the header was to change the color away from blue, and in the end I lost that battle. Bartik has a blue gradient header because Garland had a blue gradient header...

_______________________________________________

That said, I think the first question to answer is — where is everything else at for the Drupal core twiggification overhaul awesomeness? There's a group that's been working very hard for several years, and I know they were thinking about Bartik too. Are you all on this thread already? Is there a place on another ticket that's just not been implemented yet? Or did that group run out of steam before getting to Bartik? I'm sure Bartik has been switched to Twig — or it wouldn't run. What about the CSS re-org? Is the rest of core CSS still being reworked? Is there a plan already for reworking Bartik's CSS? Before this thread get too deep into debates, could someone explain how this ticket fits in with all the other front-end work that's underway?

Thanks laurii for pinging me on Twitter and inviting me to comment.

Where is everything else at for the Drupal core twiggification overhaul awesomeness?

Both Seven and Bartik have had their theme functions and templates converted to twig as they have been converted in core, so they never broke.

What about the CSS re-org? Is the rest of core CSS still being reworked? Is there a plan already for reworking Bartik's CSS?

CSS organisation kind of stalled when the mobile initiative fell quiet last year, there is still a fair amount CSS cleanup to do. See #1921610: [Meta] Architect our CSS and then #1980004: [meta] Creating Dream Markup. There is no plan for Bartik but I guess the same plan as Seven would be inspiration: #2321505: Split Seven's style.css into SMACSS categories

The markup and CSS and Bartik is the 'worst' in core because the focus was on module templates before D8 release (as they affect every theme) and no one has driven Bartiks development forward.

Tacking on to Lewis' comment, I think Bartik has suffered from a lack of showrunning. I don't think anyone wanted to push for any change that would've affected markup or had any noticeable visual change, even if it was small. Any visual/design impact is something the maintainer should approve. Lewis can go wild on Seven, if he wants, because he is the maintainer. It is difficult to have that same enthusiasm (same level of decision making) when don't feel you have authority. That said, I would love to see Bartik refactored, removing all of its templates. Some of them are there just to add wrapper divs. :-(

Jen, do you approve of people going ahead with SMACSS and template refactoring, as long as everyone keeps in mind the principles you posted?

Jen, do you approve of people going ahead with SMACSS and template refactoring, as long as everyone keeps in mind the principles you posted?

Yes. If I can be of help by saying — yes, let's refactor templates as needed to improve the markup, and to refactor the CSS to match the new core OCSS plan.

Jen, do you approve of people going ahead with SMACSS and template refactoring, as long as everyone keeps in mind the principles you posted?

Yes. If I can be of help by saying — yes, let's refactor templates as needed to improve the markup, and to refactor the CSS to match the new core OCSS plan.

My 2c is that Bartik in D8 should not rely on any precompiled css implementation. Leave that to contrib please.

What is VERY good about Bartik in Drupal 8 is that it is responsive by default. I have already built a site leveraging that, using Bartik as a base theme. I would not want to see Bartik becoming unsuitable for theme inheritance, and I would not want to see Bartik requiring ANY flavour of xCSS compilation. Any Ruby/Python dependencies would be a showstopper in my book.

Bartik should be something that entry-level Drupal themers can subtheme without getting sucked into installing and managing any dependencies.

(Yes I know what SMACSS is, just sayin')

I'm going to suggest a really rough plan that I will add to the issue summary, but first:

The idea of using Sass or any preprocessor in Drupal Core has already been discussed to death. It was decided that Sass a big barrier to contribution, and given the length of Drupal's release cycle it would be difficult to say which preprocessor would be 'the best' years from now and would require us to rewrite again in another preprocess.

Even if we did decide to experiment by trialling Sass to a sub-section of Drupal:
1. It is too late in the 8.0.x release to trial something major like this
2. Bartik is under maintained and a without an active maintainer, it would be a bad section to trial this

The rough plan, which I've added to the summary:

1. Split Bartik's CSS into SMACSS style components - See #2321505: Split Seven's style.css into SMACSS categories
2. One issue for each CSS file - Clean up CSS inline with CSS standards

I suggest splitting the files first because it reduces the chances of a reroll a lot. I wish I had done this before anything else in Seven.

I think it makes sense to focus on the CSS for each issue, instead of making them template/mark up focused. If we want to write good CSS, we will have to change the mark up, and we might as well remove useless mark up while we are there. See previous similar issues:
#1190252: [573] Use csslint as a weapon to beat the crappy CSS out of Drupal core
#2041793: install-page.html.twig markup and CSS

Maybe we need another stage to ensure the bartik.theme and twig files are in good quality. How does that sound?

Lewis' multiphase approach works for me. I would love to see something done with the templates. Either not have them at all, and only deal with what comes from core/Classy, or at least make sure they are overriding for reasons that make sense. I dealt with this recently when working on search module changes. (#2358037: Add search form block Twig template file) The only reason I had to create an extra template in Bartik is because it's blocks have an extra wrapper div with container-inline. Getting rid of that kind of stuff is a win.

Lewis, do you want to create an issue and lead/co-lead getting the SMACSS phase done? As far as refactoring/removing templates, does that need to be a separate phase, or does it just need to be part of phase 2? I imagine it isn't easy to make changes to the markup without making CSS fixes at the same time.

I like Lewis' suggestion a lot. Especially since it's informed by experience with Seven.

Here's a thing to watch out for: Color Module Support.

Reading the last few comments, vague memories of cursing at Color module are coming back to me. There's a lot about how Bartik's CSS is structured that was old school in 2009, but required to make Color module work. We (and by we, I totally mean Steven Merrill) rewrote a lot of Color module in order to let us do the things we wanted to. And yet, we could only get so far, especially since it was "late" in the D7 cycle (although much, much earlier than we are now in the D8 cycle). I recommend leaving everything about Color module support as is. Curse all you want. But let's not fight it. Let's just keep things working as they do now.

Color module was written a very very long time ago. Garland used it heavily — although most of the Garland's implementation was using Color to recolor image graphics. (The gradients were images that Color would recolor to any color the user wanted. Impressive. But a hack by today's standards since CSS now has gradients). I believe that when I wrote Bartik, I ripped out everything Garland was doing with images, and converted everything Bartik did into pure CSS. If I'm wrong and there are any images being recolored, then those cannot be converted to SVG.

All the colors that can be changed by color module are written in hexadecimal. That has to stay as is. Color module can only manipulate hexadecimal numbers.

There are a lot of translucent RGBa color attributes throughout Bartik. These work because they are not changeable by Color. It's inconsistent to have both hexadecimal and RGBa. But it has to be like that. So let's leave it. The safest and easiest thing to do is to *not* change any of the colors in a "cleanup" effort. It'd just be a world of pain.

All the colors that can be changed by Color module are in a separate CSS file, sequestered from everything else. This is annoying, but is by design. Color module will hijack any CSS file in which it's going to change a value. The Color-module colors were originally mixed throughout the CSS, in whatever place made sense. But then Color module would come along and duplicate those files, hiding the new "real" files someplace secret & strange. Which makes it very hard for anyone forking Bartik and altering its CSS to understand what's going on. I remember loosing a few weeks of back and forth with Steven and others trying to understand what was happening. In the end, we put the colors for Color module in their own stylesheet. That way, if someone does use Color module & changes some colors, then the minimal amount of CSS is duplicated and hidden is off in it's own world.

I believe the Color module css file loads last as well, yes? If so, that should stay the same too.

All that is to say, hey — when reorganizing, don't reorganize the Color module stuff. It will just have to live as a deviation from the new plan. The only alternatives are to 1) remove all the Color module support, significantly changing Bartik on the eve of launch (which is not going to fly), or 2) completely rewrite Color module on the eve of launch (which is not going to fly).

Color module is a part of Drupal's legacy. Some people hate it. Maybe it's rarely used. It's built with old ideas of how to code up such a thing. I'd be fine with it's removal in Drupal 9. But since no one lobbied for such two years ago for D8, it's too late to make such a change now. And beyond the kilobytes it adds to the core download, leaving it as is really is no big deal. Well, except for the fact it'll mean not having Perfectly OCSS Core CSS in Bartik.

Make sense?

tldr: Don't Mess With Color Module.

Once Bartik's code is reorganized, I'd love to take a pass at it, and clean up any visual inconsistencies / things that look buggy.

It has been a long time since I've contributed to Bartik — in part because of some (not-public) human drama that went down that left me feeling like I was no longer welcome in the Drupal core community. Design is undervalued in Drupal. Women are sometimes treated pretty badly. Many people who contribute to core end up feeling battered. Especially when their work is unpaid. And especially if in the end you're told that you didn't work hard enough or your contribution isn't worth much. I walked away very angry three years ago. I didn't want to go, but knew I had to. Yet all the while, I'm still very proud of Bartik. I cherish the team we had going before the theme went into core. It was a huge uphill battle to dare to create a new default core theme. And we succeeded!

So I would love to have a chance to fix the little noodley things that might have emerged over the years. Themes tend to slowly unravel over time, especially when neglected. I haven't even looked at Drupal 8 or the newly-responsive, twiggified Bartik (or, er, it's been at least a year since I've seen it), but I imagine there might be a few easy tweeks that would help polish it up.

I won't start on any of this until all the conversion is done. But perhaps after, I can get in there and make some improvements.

Jen, I think we all want you to be as involved as possible. I think the easiest thing will be for everyone to use this issue as a meta, and make the re-organization metas/issues a child of this one. It should be easy to keep track of things, and people can post updates here. Are there any blockers to proceeding, concerns, with re-organization given Jen's comment on the Color module support?

Please think about accessibility. There are already issues against bartik for small font sizes.

Actually, since this is to become a meta issue, it might do well to round up all the open issues against bartik here, as some might end up being closed as duplicates or wont fix.

Proposed flexibility improvement for Bartik: https://www.drupal.org/node/2375081

@jensimmons Thanks for all your historical insight. :-) I think we will have to compromise on account of the color module, maybe in a later version we can overhaul how the color module works (css variables?!)

Jen is not proposing that she be heavily involved in this process, which is fine, and Jeff is also not very active anymore.

We need an active development maintainer for Bartik. Someone who makes the final call on disagreements and who is responsible for driving this mini-initiative forward. I'm not willing to take on another responsibility that pulls my attention away from Seven.

I have created a new issue: #2375225: Add emma.maria as Bartik maintainer

Bartik currently has 52 open issues against the 8.0.x version, the oldest opened more than 4 years ago. 14 of those have been touched in the last month. Didn't check all of them but wouldn't be surprised if they all affect markup and/or styling. So if css rework is the major first step, something should be done quickly or there are going to be a lot of toes stubbed.

@LewisNyman Don't count me out yet. I would like to be involved in making the call on disagreements that affect the look, the functionality, and the way Batiks serves as a code example. I don't have my head wrapped around Drupal's conversion to SMACSS, so I'll defer to others on that.

I don't have enough time to donate to "drive this mini-initiative", so it would be great to have help from someone who can go through the 52 open issues, closing ones that aren't relevant anymore. And organizing what's important into clear tickets, etc.

I can commit to keep an eye on issues, and jump in to answer any questions people have — much more than I was doing in the past. Thank you to those who've invited me back and offered kind words.

I will have a look through the current issues. The things I am interested in all appear to be in progress.

@LewisNyman Don't count me out yet. I would like to be involved in making the call on disagreements that affect the look, the functionality, and the way Batiks serves as a code example. I don't have my head wrapped around Drupal's conversion to SMACSS, so I'll defer to others on that.

Sounds good, I think having a design maintainer and a development maintainer sounds like a nice team. I'm assuming that worked well in the D7 cycle? We still need a development maintainer to look after the code. It also means that someone will know to contact you when you're input is needed.

I've updated #2375225: Add emma.maria as Bartik maintainer to reflect this.

I've added the splitting up Bartik into SMACSS style components issue #2375673: Split Bartik's CSS into SMACSS style components + adding file documentation issue #2376223: Add file documentation to each css file.

Let's fix Bartik people! :)

Comment from the peanut gallery

I would love to see the image float option put back into the UI. I never did figure out why that got taken out.

:)

(welcome back Jen - I am a total fan girl of your work, and of Bartik - thank you so so so much)

Bartik is moving to all regions. One more region would fix the last major annoyance in the beta 3 version: #2376477: Provide alternative logo region to allow short header

There could be trouble trying to refactor on a per-component basis, it really depends if you will be changing specificity, if not then its probably OK. Another way would be refactor to a subset of CSS standards per patch and touch many components, to remove the need to re-roll other patches or become bound into a long chain of interdependent issues.

I would rewrite the whole shebang, its not a complicated theme to be honest, one or two days tops? Thats me though, discard all tech depth and wipe the slate, do it properly instead of the last minute rush job we were forced into in D7.

@kattekrab - core themes were deemed not allowed to have theme settings.

I agree that rewriting the whole shebang might be a lot easier. Changing the css architectural is required to be inline with the coding standards. I also feel like it's a better practice than keeping everything in one single file.

The only problem would be how? What would the plan be if we changed it into rewriting the entire theme? And what would happen to our 'beloved' color module?

Opinions?

I would think to get full compliance will amount to a total rewrite in any case.

I think Lewis plan is a good one, I would add one more iteration to remove redundant markup and you pretty much have a rewrite.

Nothing needs to happen to Color module, just smaccifiy the colors.css file like the others, I don't really get why people keep bringing up that color module is an issue?

Jeff, please add your thoughts here, #2375225: Add emma.maria as Bartik maintainer, when you have a moment.

I'm currently waiting to continue working on issues until we've agreed on a plan. Since @emma.maria is most likely to become the new maintainer, I'd love to hear what she has in mind for the future of Bartik so Team Bartik can start working on issues! ;)

I have updated the issue summary.

Can the Twig/template experts please help me outline the work needed to improve the templates?
I know we need to see if some templates can be removed as Bartik depends on Classy now. Templates may have some markup that can be removed.

CSS work for CSS coding standards will be addressed in one issue per CSS file that we have. So "Clean up base.css to follow coding standards" etc. This is to stop us tripping up over each other and avoiding rerolls to clean up the code. However I have excluded ID cleanup from this because of the next paragraph.

Replacing IDs with classes in templates and CSS is currently here #2347751: Remove id selectors from templates of Bartik. As there are problems with the patches from this breaking things visually and making it hard for people to fix this I think this should be split into separate CSS file issues for this too. Feedback please.

Also I want to stress that we ideally need to get #2375673: Split Bartik's CSS into SMACSS style components done and committed first before we start patches that include the current CSS files. It was a lot of added work on Seven and I don't want to let that happen for all this work too.

Much of the template differences are there for wrappers and classes. I assume it will require some CSS changes.

For example, the only difference between the core block template and Bartik's is this wrapper div that adds the 'content' class:

    <div{{ content_attributes.addClass('content') }}>
      {{ content }}
    </div>

The system-branding-block template is there for this wrapper:

<div class="site-branding-text">

Structurally/functionally, page might be the biggest difference, but again I'm seeing a lot of wrapper divs and "clearfix". Each template would have to be evaluated, and see how CSS can possibly be adjusted to account for markup changes.

Is there a move away from content_attributes.addClass('content') to specifying the classes in a list outside the template and using only the list here?

I've hesitated to respond to the beginnings of Shit Being Said About Me Again, but I'm simply tired of letting people say bad things. So even though it's a bit of a derail, I'm going to publish a comment I wrote over a week ago to respond to Lewis, but hesitated to publish. And I'll write a more direct response to Jeff's accusations in the other thread at https://www.drupal.org/node/2375225. If people want to keep talking about this, let's have the discussion elsewhere, not on this ticket. Maybe I'll finally write something on my blog, and start a real public discussion. I just at least want to stick up for myself inline:

In #38... @LewisNyman said

Sounds good, I think having a design maintainer and a development maintainer sounds like a nice team. I'm assuming that worked well in the D7 cycle?

Uh, well, just for the historical record... that's not really how it worked in the D7 cycle. I was the designer. I was also the primary developer. (I design in code, not Photoshop. I've been coding websites since 1996.) I evangelized the project and gathered a team to work together on parts. We shared code in Git on GitHub (at a time when Drupal was still all CVS, and being on GitHub was seen as controversial — so long ago!). There were many people who helped by giving feedback, finding bugs, and polishing up all the noodley bits that take forever to track down. A few people worked on big components, like altering Color module so Bartik could transform more than 5 colors, etc. But mostly it was my project. I was the leader of it. I made decisions. People yelled at me. And long before Bartik went onto GitHub, before I showed it to anyone, I worked alone for many, many months.

All through this time there was no "official maintainer", because the project was not official. We had no blessing from Dries, the way he's appointed folks to lead initiatives in D8. I'm not sure he even knew what I was doing. I kept in touch with Angie, lobbying heavily for the theme to be accepted, and asking for guidance and feedback. It wasn't until the day Bartik was added to core that I knew for sure that Bartik would be added to core.

I don't remember how or when Jeff became an official maintainer. We never "shared" the duty. He kinda just took over at some point. I don't remember anyone talking to me about it.

So no, we didn't have a "design" person and a "development" person. No girl job and boy job. I did both.

@peterx re #55 For a bit of history on why those classes are moved to the template please take a look here #2322163: [meta] Consensus Banana Phase 1, move CSS classes from preprocess to twig templates. There was a consenus by a number of themers in Austin that this approach would help give more control to themers by providing the classes and building them up in the template.

@jensimmons I doubt @LewisNyman meant anything like this at all

So no, we didn't have a "design" person and a "development" person. No girl job and boy job. I did both.

Though I side with you in that there are people like you and a few others that are good at design and development and I put myself in that boat too. There are lots of people these days that take their strongest suit and run with it. And more importently there are MUCH more people that silo themselves in either these camps than live in both so I only have to assume @LewisNyman was trying to pull on strengths and specialties by that comment. Please take these comments with the best of intentions as we are all trying to further and improve Drupal the best we know how.

@jensimmons moving to github again sounds like an awesome suggestion to me, may be a more efficient and effective approach to this cleanup, what do you think @emma.maria? We could try it out for a couple weeks and see how it takes? Then maybe move those fixes in to patches as you suggested above after we get say 90% to the goal?

@jensimmons Sorry in advance, I re-read that and didn't mean to take it out of context, I don't know the whole story behind and I also don't know when not to comment:(

I know it's awesome to have your perspective on bartik and glad you are sharing your experience in how it was developed as that is invaluable!

@peterx in #55. As Joel pointed out, much of this happened as part of the Consensus Banana stuff, and adding the class to an attribute in the template file is the preferred way to handle this now. In my comment I was just pointing out the difference between the two templates was the wrapper div that adds the 'content' class. If there is a way to achieve the desired visual result without this div, we should be able to remove the template.

@David, I read through the links and follow the logic. I like the assembling of lists of classes at the head of a template so the logic is separate from the HTML bit. My next step will be experiments with beta 3 Views and Bartik. Views lets you add extra classes for rows etc. Will be interesting to see how they pass through to the template.

@joelpittet re #57:

I doubt @LewisNyman meant anything like this at all

I agree with you.

I did not think when I wrote those words that Lewis was consciously implying I could only do "the girl job". It's just that the whole rest of the industry does think things like that. I am constantly pigeon-holed as someone who doesn't have the qualifications to do what I claim I do. So I wanted to point out the undercurrent that can happen when roles are divided up along certain lines — yes, in the larger context.

It's a weird dance we do. Believing two things at once that seem to contradict each other. I fully believe that the person at hand, in this case Lewis, has only good intentions, and harbors not even a tiny bit of ill will or prejudice. And simultaneously, that someone, (likely several someones), is absolutely acting from a place systemic sexism and misogyny, whether conscious or unconscious. I may not yet know who that is, but they are there and their beliefs will affect what happens, especially if not made conscious. And maybe it's the person at hand — but I won't assume that until something specific happens. This duality may make no sense, but after 28 years of being treated like an idiot by computer science nerds, even as I wrote better code then them, it's the only reality that exists.

And thanks for your follow up comment in #58. I'm glad you are willing to talk about these things. I know it can seem tricky and dangerous, but it's only through openly hashing through the sexism & racism crap that we can change our industry.

@54 agree, taking markup out shouldn't really be that difficult and just requiring some CSS changes, the theme had to support old IE etc in the past but now were are free to use more advanced selectors etc. we can lever up CSS3 much more this time around and just get rid of a lot of crap.

I will argue for that we basically take bartik out and into contrib for drupal8 and start all over - here is a couple of reasons for that:

1. The codebase (markup & css) is at least 4 years old, lets say 5 just to be on the save side (D7 released in january 2011)
Theres more of less nothing we would write the same way today, cause html5, css3 & the death of ie8 etc.
So alone getting that up to speed is gonna take forever in core - unless its done in a mega patch where everything is ripped out & put into place again as jeffburnz suggest.

2. The design is just as old - Do we really wanna keep the same design in core for 5 more years ?
This will be an issue that will happen to any design after X years, no matter what it is. Garland had the exact same problem, blue marine had it the day it was created ;)
I know its a timesuck to get a new one in, but we can introduce a new design later on -> 8.1 ?

3. Its the starting point for any new themer.
For the last 8 years new themer's that came into Drupal have been thinking that they should just look at the default theme and build from there. (copy & paste)
It happen with bluemarine, garland & now bartik. None of those themes have been good to build anything new on (cause drupal sucked) - and have cause a ton of pains for new themers. Fortunately now we have classy in core - the start for a new world for themer. But whatever we pack Drupal with out of the box will be looked upon as "the best way of doing it", so lets try not to deny reality, the theme also needs to work for that.

A suggestion for a roadmap.

1. Use bartik now to test that classy is build right, and so the "developer" have something to work with. Its a good test for comparing bartik to seven, and its a sober look for the Drupaltwig group to keep us on our toes. It basically means rip everything out, start over reuse the design manual.
Lets pack it in with D8 to avoid any Drama & bikeshedding, but as mentioned above. Bartik is not where the future is hidden, but its what we have right now.

2. Use the group that we now have around "Drupal's core theme" that wants & can think and look forward for a new design and theme that will be released in Drupal8.2
That development & design process should be done outside of core, with multiple designer's that can battle around ideas and a couple of themer's that wanna be in that timesuck, basically the same thing we did with the DrupalTwig project. It requires a task force of some badass designers & themer's that can take a hell of a beating, create the right discussions & trust into the community, cause thats what it takes to get it into core, where everybody have an opinion, until we hopefully someday have a more clear way of taking a decision.

Lets pack it in with D8 to avoid any Drama & bikeshedding, but as mentioned above. Bartik is not where the future is hidden, but its what we have right now.

If it's released with Drupal 8, it has to meet Drupal 8's standards. It should be a good example of how to build a theme in Drupal 8.

Let's keep this plan focused on 8.0.x for now, because I know you hate bikeshedding ;-)

Sorry Morten, gotta disagree with you on this one (so what's new? I hear you say )

It's just way too late to seriously be making this kind of suggestion.

Bartik does the job. Classy alone is too raw. And seven won't do either.

The "product" side of Drupal needs a finished theme that works out of the box, and could be used by dumb site builders like me who don't know how to theme, but just want to change the colours and move some blocks around. Bartik is perfect for me, and for many Drupal users whose voice we never ever ever hear on d.o.

This is what Classy looks like

It doesn't even have a screenshot in the appearance settings yet!

@kattekrab, I don't think Morten's intention was to make Classy the default theme. Classy is not a presentation theme. It is a base theme only. Classy may have class, but it doesn't have style. (Yes, I came up with that all by myself. :) )

@morten, I agree with kattekrab and Lewis. This is just too late. We are in beta, and have to concentrate on what gets D8 out the door, not new features. I'm sure it is too late to get another theme added, and certainly too late to get the default theme removed. Many of the web tests rely on it, everyone has been using it in books and tutorials they are building, etc. We should concentrate on making it the best theme it can be, and a good example of D8's new standards.

Would I would like to see instead, is all the super enthusiastic themers start working on contrib themes for D8. We have no end to the modules available for people, but have always suffered from a lack of themes. And I don't mean another base theme, or an upgraded mothership. I want to see some really pretty contrib themes. Everyone has been really excited by the front-end changes, and how much better it will be to theme D8, so it's time to start walking the walk.

Let me quote myself as apparently nobody is reading what im suggesting for a roadmap :(

"1. Use bartik now to test that classy is build right, and so the "developer" have something to work with."

We can't put a new theme in now and as I suggest do that further down the road, when we have a design & theme that will work (8.2 or whatever)
My point is that bartik is beaten & worn out - Lets not pretend its not.

@kattekrab it might fit the purpose right now, but it dosnt make drupal look fresh, new or exciting - thats not good for a product, it makes it look old & wornout.
Classy is what used to be "stark" - Its purpose is to seperate the template files away from Drupal core.

@david yup im allready on it.

A little of topic here, but @mortendk: what are you working on?

Seems like we have the blocker #2375673: Split Bartik's CSS into SMACSS style components RTBC, so we can start working one the rest of the issues once this is committed! Nice.

This plan is already moving ahead, so this plan is no longer under discussed.

So is there anything left to do here? I don't see anything to commit. Should we move it back to active until the sub-issues are sorted out?

If there is nothing to discuss I say mark it closed or fixed.

The status list does not have a "Waiting on child issues" option. Would be useful.

This was originally a discussion issue which required a rough plan to get going with Bartik to be added to the issue summary. The discussion died out and no one currently references this issue for any current work. Also you can now see the only open issue is a specific new meta, #1342054: [META] Clean up templates and CSS where new work is now being derived from. This issue can be closed/fixed.

so then...