Right now the section elements are coded in to page.tpl.php. Could this be moved into configuration at the theme settings? See attached screenshot. By doing it this way the themer would not have to go through all tpl.php files to change the for example the sidebar to aside instead of section.

In the example screenshot I've had this code to generate the theme settings.

  $form['html5_base_regions'] = array(
    '#type'          => 'fieldset',
    '#title'         => t('Region elements'),
    '#description'   => t('Set elements for theme regions'),
  );

  $regions = system_region_list('html5_base');
  foreach ($regions as $key => $value) {
    $form['html5_base_regions']['html5_base_regions' . $key] = array(
        '#type' => 'select',
        '#title' => t($value),
        '#default_value' => theme_get_setting('html5_base_regions_' . $key),

        '#options' => array(
            'div' => t('<div>'),
            'section' => t('<section>'),
            'nav' => t('<nav>'),
            'aside' => t('<aside>'),
            'header' => t('<header>'),
            'footer' => t('<footer>'),
        ),
    );
  }
CommentFileSizeAuthor
theme-settings.png10.88 KBpontus_nilsson

Comments

Jeff Burnz’s picture

Totally doable, however this is making the assumption that sectioning is coming at the region level, however this is unlikely in most cases, rather to come at the block level. Rarely would a sidebar, for example, be a section (regions NEVER have titles), instead a block would be a section, nav or aside content.

Regions are simply dumb containers used for layout, it makes many presumptions to make them semantic containers, far to many to be proper sectioned content (to generate a proper, accurate document outline). There are several possible exceptions to this, but for the most part regions should be divs.

If this theme is using section on sidebars (or any other region), well, that is very poor use of HTML5 sectioning, it makes the classic mistake of mixing layout with outline, whereas these are two different things entirely.

The block is the place where this should happen - never on a region.

pontus_nilsson’s picture

Thanks for your input, yes let's move this kind of feature to block level.

idflood’s picture

Title: Configurable elements for regions » Configurable elements for blocks

So this could be a feature for the html5_foundation subtheme. I'm really not sure this is a good idea/usefull to have those settings. In some cases theme will require deeper changes and in most situation the outline/semantic should be good without having to change anything.

adrinux’s picture

I'd +1 idflood. We need to keep in mind that html5_base is supposed to be an example of what will go into D8 core, as well as a base theme for D7. This feature might be good for the proposed html5_foundation sub theme ( http://drupal.org/node/1036574 ), not but not html5_base. Certainly generic semantic tags on blocks isn't going to work, they either need to be configurable or left as div's.

adrinux’s picture

Status: Active » Needs work

Actually, thinking about this a bit more. I think this feature belongs in a contrib module for now: 'Semantic Blocks'. That way it doesn't need to be in html5_base or core, and it'll work for more than just html5_foundation. A theme would need to add support for it however, since we can't yet pass elements the way we can attributes.

Jeff Burnz’s picture

@#5, no we can't pass elements like attributes can we... wouldn't it be interesting if we could...

adrinux’s picture

:)
Drupal-8?

Seriously. Don't we need to be able to pass elements like attributes if we're going to be able to take advantage of semantic elements? Or is that just an array too far?

Snowballing idea's…all these semantic this and semantic that modules…is a semantic api insane? something for all these modules to build on, be it passing in attributes(id/class/role etc) or elements?

Jeff Burnz’s picture

Well the most powerful semantic module is already in core, RDFa. I think its likely HTML5 elements and attributes will get sprinkled right through core (eventually), not really seeing how it call all tie together at the moment (aka an API).