Identify and modify areas that need to be HTML5

[justintadlock]

I think we've all moved to HTML5 as theme developers now. Any HTML in Hybrid Core should be HTML5 by default. So, we need to identify all code that needs to change.

[jayj]

Here's my list:

• [entry-published] (abbr to time) - see #13
• [comment-published] same
• Breadcrumbs Trail: I don't know if the breadcrumb code is using Rich Snippets/microdata but that would be nice http://support.google.com/webmasters/bin/answer.py?hl=en&answer=185417
• Cleaner Caption: Maybe <figure> instead of <div>
• Custom Field Series: Allow the wrapper to be <aside> instead of <div>
• Entry Views: Remove type="text/javascript" from the entry_views_load_scripts() function
• hybrid_comment_form_args(): HTML5 input types (https://github.com/justintadlock/hybrid-core/blob/1.6/functions/comments.php#L186-L190)
• [nav-menu]: <nav> as container instead of <div>
• Maybe the default sidebar arguments in sidebars.php
• hybrid_site_title: Always use a <h1>
• hybrid_site_description: Always use a <h2>

[ryanve]

@jayj Nice list.

• The structured data testing tool is useful for checking/improving data of all types (microdata, rel, hatom, etc.)
• Using <nav> where appropriate seems relatively important and the best place to start.
• If the site-title/desc uses h1/h2, use hgroup for proper outlining. Update: Strike this. hgroup is obsolete.
• Since [type] is added by wp_enqueue_script() and is still valid, it makes sense to leave that as is, until/unless WP provides a clean way, like trac #22249.
• All default markup should validate. Avoid adding invalid <meta> tags like "revised" and "copyright"

[justintadlock]

Thanks for identifying some major areas. Just some thoughts on the feedback thus far:

hybrid_site_title and hybrid_site_description

These were never intended to be used with HTML5. Honestly, there's no point in using the functions in an HTML5 theme. Their purpose is to output h1 and h2 tags when appropriate pre-HTML5.

[nav-menu]

I'll probably continue using a 'div' instead of 'nav' here. This should reflect the WordPress default and not make the assumption that the menu is not just a regular list.

Maybe the default sidebar arguments in sidebars.php

I'd really love some feedback on the best structure for sidebars. I've seen varying uses. It's something I'll be researching more myself too.

[jayj]

In Cakifo, I use aside for the widgets in the sidebars but div for some of the other widget-areas. I don't know if the aside would be more appropriate for the others. The default themes and _s use asides for the widgets.

aside is now acceptable for secondary content when not nested within an article element."

• http://html5doctor.com/aside-revisited/

[justintadlock]

The more I look at it, the more this seems to be the best way to mark up a sidebar:

<aside id="sidebar">

    <section class="widget">

        <h1 class="widget-title">
        </h1>

        <!-- widget content -->
    </section>

    <!-- repeat for each widget -->

</aside>

Or:

<aside id="sidebar">

    <div class="widget">

        <h1 class="widget-title">
        </h1>

        <!-- widget content -->
    </div>

    <!-- repeat for each widget -->

</aside>

[madalinignisca]

I vote for this one:

2013/1/14 Justin Tadlock notifications@github.com

Madalin Ignisca frontend web developer http://imadalin.ro/

[ryanve]

Use h3 for the .widget-title. Using "headings of appropriate rank for the nesting level" is more resilient than using h1 everywhere. Hierarchy should be apparent without CSS. Ranked headings facilitate screenreader tabbing.

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level.

I agree about using <section class="widget"> rather than <div class="widget"> based on the rational that it is an explicit section. I'd wrap the .widget-content and add .sidebar for easier styling.

<aside id="sidebar" class="sidebar">
    <section class="widget">
        <h3 class="widget-title"></h3>
        <div class="widget-content"></div>
    </section>
</aside>

[jayj]

I think I agree with option 1 as well. While I don't think the section is the best option for all widgets it's the best option as I see it.

Option 1 gives the following document outline:

• Site name
  • Untitled ASIDE
  • Widget title
  • Widget title 2

Option 2:

• Site name
  • Widget title
  • Widget title 2

The Navigation Menu widgets gives the option to set a container (div or nav). Would it be possible to use this choice in before_widget and after_widget for that specific widget?

[justintadlock]

For now, we'll agree on this structure:

<aside id="sidebar">
    <section class="widget">
    <h3 class="widget-title"></h3>
    </section>
</aside>

Of course, <aside> is handled by the theme itself.

The Navigation Menu widgets gives the option to set a container (div or nav). Would it be possible to use this choice in `before_widget` and `after_widget` for that specific widget?

I wish I'd thought of that. It makes total sense and should definitely be doable similar to how the Bookmarks widget is done.

[justintadlock]

Proposed [gallery] shortcode default markup (Cleaner Gallery extension):

<div class="gallery">

    <!-- repeat for each row -->
    <div class="gallery-row">

        <!-- repeat for each image -->
        <figure class="gallery-item">

            <!-- probably need this wrapper for back-compat -->
            <div class="gallery-icon">
                <img />
            </div>

            <figcaption class="gallery-caption">
            </figcaption>

        </figure>

    </div>
</div>

[dronix]

@jayj has a nice list. I use my own version of hybrid_site_title and hybrid_site_description.

For the sidebar I use the same markup as the Twenty Twelve theme and _s theme as @jayj mentioned.

<section id="sidebar" class="widget-area">
    <aside class="widget">
      <h3 class="widget-title"></h3>
    </aside>
</section>

The [gallery] shortcode markup looks good.

[samikeijonen]

This is interesting conversation. And as @dronix pointed out Twenty Twelve is using kind of opposite markup what is suggested to use in Core. What is the reason Twenty Twelve is using it that way?

[pdewouters]

have you seen this http://html5doctor.com/downloads/h5d-sectioning-flowchart.png

[pdewouters]

sidebar widget should be an article element comments should be article elements

could use 'keywords' for tags (http://schema.org/BlogPosting)

[samikeijonen]

@pdewouters yes I have but it really doesn't answer to my question. Atleast not for me if it's ok to use markup in both ways. Just trying to understand the HTML5 definitions and they are not 100% clear to me yet.

[pdewouters]

@samikeijonen I wasn't replying to your question, just posting that as a reference :)

[pdewouters]

seems there's a new

element http://www.sitepoint.com/html5-main-element/

[justintadlock]

I think most of the things brought up in this ticket dealing directly with Hybrid Core have been addressed. Some things, we'll have to do on a theme level.

Please do let me know if you run into anything else. I'll leave this ticket open for now.

[justintadlock]

I just pushed an update for HTML5 input types in the comment form. That should be the last of the things I plan on updating mentioned in this ticket.