HTML5ify block.tpl.php

Bumping this up to the top. This needs a look. There's a whole new block.tpl file from which to start now.

Blocks are just so general I have a hard time justifying imposing semantic markup here. Maybe there's justification for writing a semantic_blocks module?

maybe we should replace the H3 with an H2 tho. I don't see any H2's in the page.tpl.php. Of course with the new outline system they could be H1's, so there's really no right or wrong.

Yeah, I think the big question here is what element to wrap the block container in.
div?
article?
section?

I think a serious argument could be made that each block is an article — all wrapped in an aside that wraps the whole sidebar.

My two cents - Given the wide variety of uses for blocks in Drupal, I don't think we can say for sure that blocks will always be "independent, self-contained" chunks of content. To me, that argues for wrapping them in section, rather than article.

I can think of just as many cases where blocks would appropriately be placed in section and article. My leaning is to leave them in divs until we can find an efficient way to allow admins to choose.

I'd lean towards disagreeing with 4.
Blocks, for me, are pretty much always self-contained items of content.
My vote is for <article>.

Well since we're all chiming in here, I agree with #4. I know for a fact that I've had blocks that I would not classify as an ARTICLE. I think SECTION is more generically appropriate.

cross-post.

I'm all for minimizing markup, but the patch in #7 is empty

@bleen, :-D lol.

Disregard blank patch.
Once a decision is made, a patch can be rolled [if needed at all].

Just because we have new elements doesn't mean that everything we do will simply map to one of them. I'm seeing enough variance among us to show that there's not a clear choice between SECTION and ARTICLE. I'm sure a case could also be made for ASIDE. Therefore I think it's still reasonable to use DIV.

However, my leaning between the two is for SECTION. But that's because I use blocks as containers a lot.

Hi,

I'm working on a HTML5 Theme for D7 for our new drupal consulting company and it will have some menus e.g in the footer as blocks, so I decided to place a condition in the block.tpl.php, that could be implemented for other conditions also:

<?php
// use the appropriate tag for custom menus as well as for system menus, if it is not a menu it's probably a section
if($block->module == "menu" || in_array("block-menu", $classes_array)) {
  $blocktag = "nav";
}
else {
  $blocktag = "section";
}

?>
<<?php print $blocktag ?> id="block-<?php print $block->module . '-' . $block->delta; ?>" class="<?php print $classes; ?>"<?php print $attributes; ?>>
...
</<?php print $blocktag ?>> <!-- /.block -->

I'm not done thinking about this, but this is my first approach.

Speaking of ASIDE, I personally think, that that would most of the times be provided by the surrounding element in page.tpl.php. I can not think of the case you would have these nested, except may be in cases where you use nested layouts (GO panels GO! ;) ).

@pixelmord, that's a nice Idea. I believe me and Jen where discussing something similar to this. But we where thinking more generic and I think only for menus. So our Idea was something like a checkbox in the block configuration or menu configuration that allows a user to select where this block should get a nav tag or not. Then we can have different tpl for those blocks that want nav tag.

I don't remember what the conclusion was but this implementation can probably go in a module and doesn't really have to be a theme specific implementation.

Just thinking out loud here :-)

This doesn't have to do with HTML5 per se, but I thought it was a good place for it.

• Added CVS ID
• Added PHPDoc. I find these useful, and they're in Zen and Bartik, among others
• Removed !empty(). While technically correct, I've never seen it used on a string in another theme
• Removed $edit_links, this was brought over from Basic, but the actual variable was removed from template.php

Duh.

+++ templates/block.tpl.php	18 Oct 2010 23:47:50 -0000
@@ -8,6 +46,4 @@
-</div> <!-- /block -->
\ No newline at end of file
+</div> <!-- /block -->

needs a new line at end of file...

Other than that, the patch in #17 is RTBC

Powered by Dreditor.

Actually, the one in CVS has no EOL, my patch adds it (thanks vim!). RTBCing from bleen's review.

Committed to HEAD

keeping this open for the discussion about which wrapping element to use (eg section, div, article)...