Mothership's markup reset is pretty inspired. However, I'd like to see it usable with other base themes, which implies a module rather than a theme. I'd be interested in collaborating on that count, or at least discuss the advantages and/or disadvantages of that approach with you.
Thoughts?
Comments
Comment #1
mortendk commentedyou can just preload n preload as much as you want to so you can do a:
mothership -> myepicbasetheme -> the real theme
if you look at template.php you can see that everything is written into mothership_preprocess();
so a theme can do theme_hook_preprocess( );
To be honest i dont really see any reason to make this into a module.
The mothership is agressive & wants to change the fundemental way that drupal think the markup & css. That cant really be done if we also have to calculate whatever another basetheme (that dont care about markup or 432 css classes)
If it have to support all kinds of basethemes that are happy with the css & markup that drupal produces, then theres isnt really a reason to begin to support them, it would just mean a ton of new problems to fix (and afaik theres more in drupal all ready ;))
98% of the themes out there is also only a couple of preprocess function & a little change in page.tpl, node.tpl then the rest is css & youre ready to Rock.
Comment #2
srjoshI think you're making an assumption regarding whether other base themes are happy with the css and markup. My observation is that, by and large, they don't address the issue at all one way or the other. The issue seems to be in the markup that core drupal provides; the base themes in general don't delve to that deep a level.
Which, in my experience, means that there's a disconnect happening, which a module would be poised to take advantage of. Since the problem exists with the core markup code (and many modules as well), but the themes are simply passing that through without really changing it or using it to create styles, then changing the markup before it gets handed off to the theme seems both mostly harmless and logical.
Given all that, it seems to me that a module that could:
a) apply to more than one theme,
b) be easily adopted to core
c) be easily turned on and off without nuking the entire theme
would be a win.
Comment #3
mortendk commentedYes i am making that assumption, after 6 years in the drupal theming world no other basetheme have ever thought about doing about the markup.
Besides of accepting whatever it is that drupal is putting out - sorry it may seems harsh, but that makes me assume that other base themes & many themers are pretty okay with the staus quo & divitis that drupal suffers with (here comes the flamewar) ;)
You will end into a lot of problems in getting a module to overwrite markup thats coming from themes, that was once of the probs i faced at least back in d6
The idea here is that the theme should always get the last touch on any markup thats coming out of the modules & mothership is also a resource to find the tpl files easier instead of walking through a ton module folders.
A: the functionality is already there you can just add basetheme= mothership to whatever basetheme you want & you golden.
B: this can be easy adopted to core its just theme function overwrites - but getting the "no div" thinking into core is a thing i have given up on all ready, theres simply to much love for for divitis and using classnames as hooks. Dont get me wrong i would love to see my way of thinking markup to be the way drupal works out of the box, but atm its up hill & i have better things to do than convince 1.00.000 users about why a html class in the body tag has no use for me & why i want to have it in by an option ;)
- core is not willingly gonna accept this, sorry but thats just how it is :/
C: the major elements can now be turned on n off (class names wrappers etc) by each element. and if your theme dont like the basic markup well just remove the basetheme
If you wanna start up a module that does the exact thing as the mothership well go ahead the more the marrier, we need more focus on the markup & how Drupal behaves especially now the html5 are coming to us, but i must admit i have a hard time to really see the benefits about it, But go ahead if you can see big wins about a module way- I want my theming in the theme layer ;)
I will offcourse gladly help out, this have been a thing i have been screaming about for years :)
If all we win is a button that a user can click to clean up the crufty markup instead of writing basetheme=mothership then we have a sad state in the world of frontend developing
The whole thing here is that the mothership is a rethinking about what we want with our markup, its not just a quick on off switch - cause it changes a lot of things & might even break them. If a themer really dont care about the markup & are happy with the class names etc, then its all good, he can go with whatever other system he likes
So to make it short, i will keep my focus on mothership as a basetheme with the options settings & markup changes that i think are supersexy (and hopefully with the help of other theming pirates)
If you can se big wins with turning it all into a module, well go ahead, i still cant see the big win about it, besides of a lot of work that will end up with an on/off switch
Comment #4
srjoshThat's the thing - I have another system I like (specifically Omega) however I'm not thrilled with Drupal's output regardless of the theme layer, particular in light of mfer's sessions on front-end optimization for mobile, and lukew's keynote on the importance of mobile.
However, your point about keeping theming in the theme layer is well taken.
Much to ponder.
Thanks for the input.
Comment #5
mortendk commentedwell mixing mothership & omega is like getting a donkey to make sweet love to a chicken ;) - their basic concepts are miles apart.
me & jake have talked about this and basically found out that it woudnt make sense atm to go down that way
i sure hope though that the mothership will be an inspiration & documentation for Drupalcore of how you can minimalize drupals markup
Comment #6
mortendk commentedclosing this