Add a new base theme called HTML5 Foundation

Looking at your patch, this is what I see:

1. Changing <meta>

We are doing that in the HML5 Tools module. #1036766: Override Meta

2. Forcing older IE browsers to render in Chrome Frame.

Might be a cool thing to do, but not in Drupal core. So not in HTML Base. This could be an approach for another contrib theme, but we are intending HTML Base to be a representation of everything that we want in core, and Chrome frame isn't it.

3. HTML5 Base Mobile viewport

Will you explain this?

4. Return a themed breadcrumb trail. Zen tabs.

I don't think we want to alter the way Drupal core does breadcrumbs (or maybe we do — but that's a Drupal core issue, separate from HTML5.) We (team HTML5) just want to HTML5ify breadcrumbs. But do we need to do anything for them? Are they a nav?? If there is HTML altering we want to do, we should do so in HTML Tools. (Add an issue). We don't need HTML5 Base to do anything with breadcrumbs. Same with Zen tabs. Let's let Zen be Zen and us focus on core.

5. Add Modernizr

I haven't heard anyone aruge that Modernizr should be added to core. We can discuss it, but I don't think it's a done deal for wanting to add to core — so let's not drop it into Base without a lot of discussion first. On a separate issue!

6. Theme settings to turn these things on & off

Again a great idea for a more complex HTML5 parent theme — but we are focusing on things we want to get into core. This kind of stuff will never be allowed, even for an individual core theme. Needs to live in contrib.

I don't think there's anything in the D6 template.php or theme function files that we want.

I agree with jensimmons that we don't want any of the theme settings or preprocess functions from D6.

But I am totally in support of a sub-theme.

HTML5 Base Proper should just be what we think should be changed in core. The sub-theme can hold all the extra goodies.

Yeah, I do love the idea of a theme with all those settings. HTML5 Base would make a great parent for that theme! And I bet many of us would use such a theme... :)

Not only would we use it, but I'm planning to start a theme that incorporates many of these techniques and uses html5_base as its parent theme. I hope and expect many other experienced themers will want to do the same for their own preferences. I'd like for this project to be as clean as possible and therefor encourage all people interested in using HTML5 to use this as their starting point.

I *really* like this idea, and the more I think about it, the more I support it. Let's make the HTML5 Base project contain two themes — the parent "Base", is everything we think core should change, and the child, "Foundation" add spiffy stuff for theming — Modernizer, the works. All configurable (or not) from theme settings. Then we don't have to agree about extras — we put them in, and people use what they want. AND once the code from Base gets into core (ftw), we continue our project with just the stuff from Foundation.

+1

+1 from me as well.

I'm doing some active work w this code right now, and I'll flow that into the project.

In the interests keeping the focus of HTML5_base on what would go into core - I think it's very wise to keep things clear - wouldn't it be better to put 'HTML5 Foundation' in a separate project? There is no reason a child theme has to be in the same project. It would allow better separation of issues, separate documentation and allow Foundation to persist easily once HTML5_base is absorbed into core (yeah I know, long way off :).

Not so sure about better visibility, essentially it will be hidden inside another project. I can't see how it's any better than mentioning it on the project page.

"HTML5_foundation will allow us to keep cutting edge practices, that might be a bit 'too much' for Drupal core" *that* is exactly my point. It's hard enough getting core devs on board (though we made good progress on that yesterday), without clouding the issue with cutting edge stuff. You *know* you're going to have to explain repeatedly that foundation isn't intended for core, and that it will be used to spread FUD about HTML5.

I just think a clear dividing line between the "this stuff might work well in core" and "this is a cool contrib theme based on it" would be good. I can appreciate having it all in one repo is a little easier for hacking on, especially when you think in terms of moving functionality between them. I certainly wouldn't bother splitting them before the git migration goes live.

I guess I'm thinking slightly politically about this, rather than purely code development, but at the end of the day its your choice. :)

I re-rolled alanburke's patch from #8, I had some issues applying it (admittedly via drush_make) due to the hunk to change the contents of foundation.info coming before the one that created it!

Yet to do actual testing.

My first thought though is that there is already a foundation theme http://drupal.org/project/foundation so the name html5_foundation could be misleading. Maybe we should come up with something different.

I set html5_foundation as default theme after applying patch above. I noticed none of the tpl files are inherited, including html.tpl.php (so don't even get an html5 doctype). Looks like it's just using core tpl's. hmmm...

html5_foundation getting weirder. anon users get inherited tpl files and css, logged in users don't, they get core.

OK, logged in vs logged out was just a cache issue I think. Ignore that.

The real problem is the use of "base_theme" in the info file, change that to "base theme" and it works \o/

Attached is a revised patch. html5_foundation now correctly inherits from html5_base.

To what extent do you want to keep making this patch bigger - I thinking some of the css needs to move into the sub-theme too, layout.css in particular - vs separate patches for css etc.

subscribe

Subscribing.

I really like the idea of a new base theme. Here is a patch that change a couple of things:
- some spacing
- viewport and chrome frame option grouped under "Meta tags" fieldset ( chrome frame was the only option outside of a fieldset, was odd )
- fix a typo in template.php ( was checking "html5_base_mobile_viewport" instead of "html5_foundation_mobile_viewport" )

It also create the html5_foundation folder inside html5_base directory. I had some difficulties to apply the patch in #18. Here is the exact method I used to create this one: http://drupal.org/node/864350/git-instructions

I think this should be commited as soon as possible instead of waiting for a perfect patch. The code looks ok and it doesn't break anything. This would also make it easier to maintain/track issues/patch/...

Patch in #22 is missing much from that in #18, (and when applied via drush_make created the sub theme inside a folder called b - might be drush_make's fault not the patch). #22 seems to add the necessary stuff to html5_foundation, but doesn't remove it from html5_base, which is why it's half the size.

#18 is pre git migration, and pre many other patches being applied to

I agree with idflood about this issue though. Practically every other patch in the html5_base queue will need to work with this patch - it needs polishing and applying, or a decision made not to do the split.

I'll work on an improved patch shortly :)

This is basically patch from #18 with some additional changes suggested by idflood #22

- I didn't like the way idflood put the chrome frame setting in with the viewport settings in a meta tags fieldset, but he's right that chrome frame setting looks out of place. So I added a fieldset around the chrome frame setting
- spacing: I think idflood is wrong about the theme-settings spacing needing to change, have left it grouped by fieldset as before
- includes the typo fix idflood made in template.php

plus:
- tweaked a comment reference to zen theme, now says html5_foundation
- fixed the links for more info in the viewport fieldset

Attached patches: the first is generated with git diff, the second (-gfp tagged on the end) was generated with git format-patch as per http://drupal.org/node/1054616 and thus includes author info.

Well, everything is changed now.