ThemeShaper Forums » Development Talk


Make Thematic use HTML5 with a plugin

(7 posts)
  • Started 11 years ago by middlesister
  • Latest reply from ScottNix


  1. middlesister

    At some point, Thematic will need to move to HTML5. We do not know exactly when this will be. There have been articles written on the interwebs (such as and as well as posts in the forum explaining some filters to use so we already now can start using the new shiny toys of the future.

    I had the idea to gather together some of the needed filters into a plugin.

    The idea is that the plugin would simply convert the markup into using the new html5 elements where applicable. Nothing fancy, styling and polyfills for older IE would be up to the child theme.

    The humble beginnings of this plugin can be found at Download the zip, rename the folder to "thematic-html5" and put it in your plugins directory. Simply activate the plugin and add


    to your child theme's functions.php file. Or fork me on github and join in!

    All it does now is:
    - change the doctype and meta charset tags
    - change the posts to use article instead of div in all the loops
    - change the navigation menu, nav-above and nav-below to the nav element
    - change the asides to the aside element, with every widget in a section element and the widgettitles using h1 headings
    - childtheme_override_* functions will still override the plugin so child themers are in control

    Plans for next steps:
    - make an option to use the boilerplate doctype for those who wants (or should it be default?)
    - move/change post title and entry-meta to header elements and entry-utility to footer elements
    - filter the search form and comment forms to use html5 form elements

    It's more of a proof of concept yet, really. I have worked with the latest svn version of Thematic (r835 as of writing), and it is untested with older versions. I wanted to see how far I could get, and also see if there is an interest from the community for this. Feedback and suggestions are most welcome.

    Posted 11 years ago #
  2. i'm curious how you plan to 'override' the <div id="header"> and turn that into <header>

    additionally, i don't think you need to add


    it seems redundant since if you've got the plugin enabled, you must want to use the functions right?

    i need to think more about your override setup. my brain is just mush right now.

    one last thing for now: i've always thought this about thematic... i like that it has a gazillion loops you can filter/override, but it seems redundant to keep redefining them as the same thing. maybe there should be a default_loop() that the category_loop(), index_loop(), etc all tap into.

    function category_loop(){

    sort of the way other themes use the loop.php

    ps- i love this:

     * testing
     * @return void
     * @author Karin
    function testfunction() {
    	echo 'bacon!';

    pps- your plugin markup is so pretty! i need to be better about that.

    Posted 11 years ago #
  3. middlesister

    Ha ha lol! Removed that now. Bacon really comes in handy sometimes, no?

    Yes I think it's a good idea about the loop. The only reason they are separated is for the child themes to be able to define their own, it's the same default loop in all of them.

    The reason I wanted to use theme_support was my idea that if/when things became satisfactory, the code could just be included into thematic core as-is. But as it already needed to swell to several files and looking to become bigger, I don't know if that would be feasible. Another thought was if someone activated the plugin on a theme that is not taking care of the other html5 considerations (meaning IE), then that theme would break. This plugin will *not* turn any child theme into the latest and greatest, so I thought this would be a safeguard for keeping eager noobs from claiming this plugin is breaking their theme. But perhaps you are right and it is unnecessary.

    The markup in the template files is the elephant in the room. It is THE big hurdle I think. I was thinking of making a feature request to add filters to all the tags à la the wrapper tag. This might lead to a severe case of filteritis, although I can see other uses for it too (like adding WAI aria roles or grid column classes). If worst comes to worst I'll need to look into injecting templates into the template hierarchy. And then a straight port/fork actually might be easier to maintain in the long run... Will think a bit more on this.

    Posted 11 years ago #
  4. was just thinking that activating the plugin AND adding add_theme_support seems like a 2-step process where it should be a 1-step.

    the elephant in the room is definitely the things that are hard-coded into the template files. i was wondering how you were going to solve them when you said you wanted to go the plugin route. and looking at it again now, makes me think a fork might be best too.

    i'm gonna fork this and post something. hopefully github and i will play nice and i won't regret not just posting it here.

    Posted 11 years ago #
  5. middlesister

    I just did a little research and it seems a fork is the only way forward.

    There is simply *no* way for a plugin to intercept the calls to get_header and get_footer. All other template calls can be hooked into but not this. The last resort is to use string replacement on an output buffer, but I don't know about the performance of that:

    Posted 11 years ago #
  6. middlesister

    Done and done!
    Using an output buffer to replace strings. We now have <header id="header> and <footer id="footer">!

    I do wonder about performance though, I don't know enough about how these things work under the hood...

    Posted 11 years ago #
  7. Finally back home after a month, guess I have to finally figure out Github so I can test/tinker with your custom plugin. ;P

    Posted 11 years ago #

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.