HTML5 support for specific features doesn't work.

[nathanrice]

The check for the second parameter in current_theme_supports() in [24417] is irrelevant.

Unit test here:
​https://gist.github.com/nathanrice/6143003

There is no exception in the switch statement for html5 support, so the function just returns true (early) if html5 is supported at all. The second parameter is essentially ignored.

So, if you intend to turn on html5 output for just 1 of the 3 options, it doesn't matter. All 3 will output in html5.

Which is, perhaps, intentional. I'm really not sure.

If not, I'm prepping a patch to correct it.

[nacin]

Going to remove the whitespace changes from a commit to 3.6.1. Looks good, thanks.

[nacin]

24932.diff​ makes two functionality changes:

• Calling add_theme_support( 'html5', array( 'comments-list' ) ); add_theme_support( 'html5', array( 'comment-form' ) ); should merge. If a theme wants to replace, they need to do a remove_theme_support( 'html5' ) first. This is a change in behavior that we can really only get away with now, in 3.6.1. Reasoning is the mess that is #22080.

• add_theme_support( 'html5' ) (no arguments) no longer works. This was never supposed to work, as it would prevent us from adding future types in the future. current_theme_supports( 'html5' ), however, does continue to work, and will return true if *any* feature is supported. This might help a plugin author decide what markup to serve, but core should never check for this.

In both cases, this is how the functionality was designed. It just wasn't implemented correctly.

Also adds some unit tests.

[nacin]

In 25193:

Fix 'html5' theme support.

• Require it to have a second argument when adding.
• Merge, rather than replace, on second add.
• Make current_theme_supports() work when two arguments are passed.

Adds unit tests.

props nathanrice for initial patch.
see #24932 for trunk.

[SergeyBiryukov]

24932.2.diff​:

• Enables the existing three types if no second argument was passed (per the ​IRC discussion).
• Adds a _doing_it_wrong() notice for an empty or non-array argument.
• Updates the tests and fixes a few typos in [25193].

[nacin]

Alas, I'm fine with 24932.2.diff​. I've updated it with more tests, see 24932.3.diff​. It now tests that A) a non-array is invalid, and B) passing nothing gives you all three existing types and nothing wrong.

Also updated the _doing_it_wrong() to reflect 3.6.1 and added some context for the first parameter there. Agree with not translating the string for 3.6.x.

[nathanrice]

If I could, I'd like to formally request that this NOT return false if no array of types gets passed.

Short story, this will break Genesis child themes, which we can't push updates to address.

In Genesis, we only define HTML5 as being on or off. We have no need to specify types, since if html5 theme support is added, we don't want anything outputting in any other format except for html5.

I understand the "intended" behavior from the core perspective, but it's silly to assume that the following would somehow return false.

add_theme_support( 'html5' );

return current_theme_supports( 'html5' ); // false?

I'm not trying to pull special privilege here or anything ... but I can't stress enough how a 3.6.1 update that includes this short circuit will immediately and catastrophically damage the look of sites running Genesis 2.0 and a child theme that supports HTML5.

[nathanrice]

Good grief, nevermind. I see in 24932.3.diff that you haven't let it return false if no types array is passed. My mistake.

Obviously, we'll still get a warning, and we'll have to deal with that at some point, but at least it's not going to bork a site.

Might I still recommend that JUST enabling theme support for html5 with no types array isn't necessarily doing it wrong? It's more like a universal "html5 everything" directive.

[nacin]

Replying to nathanrice:

Might I still recommend that JUST enabling theme support for html5 with no types array isn't necessarily doing it wrong? It's more like a universal "html5 everything" directive.

So, this is to prepare you for the fact that if/when we add additional values (there are more template tags that could probably get this treatment?), you won't actually opt-in by specifying only html5. The problem here is if we add a future type, we might completely break a site and/or its CSS by pulling the rug out. That's why it was meant to be explicit. I don't want to hamstring us from future changes. As you said, overhauling markup suddenly could "catastrophically damage the look of sites".

[nacin]

We also possibly don't need to add the _doing_it_wrong() until we actually add new markup somewhere, or at least confirm there is new markup to be added somewhere, but we have a lot of template tags and I'm sure there will be something.

Quick search finds some could-use-some-modernization markup in wp_login_form() (and eventually, #17948), maybe get_calendar(), some page menu / page links / nav menus stuff (and other walkers), term/cat/tag lists and such, using dropdowns as jump fields in widgets, maybe some other default widgets. The point is, let's make sure themes are explicit now, for forwards compatibility purposes.

[nacin]

I'm also fine with waiting until 3.7 for the _doing_it_wrong().

[SergeyBiryukov]

Replying to nacin:

We also possibly don't need to add the _doing_it_wrong() until we actually add new markup somewhere

I tend to agree.

[SergeyBiryukov]

We should update Codex to clarify that passing an array of types is recommended.

The list of pages where add_theme_support( 'html5' ) is mentioned:

• ​http://codex.wordpress.org/Function_Reference/get_search_form
• ​http://codex.wordpress.org/Semantic_Markup

[andrewryno]

Updated documentation to mention the changes from this ticket. I didn't mention 3.6.1 since it hasn't been released yet, but I think the docs should mention the version once released.

[nacin]

In 25235:

add_theme_support( 'html5' ) now defaults to comment-list, comment-form, and search-form.

This was the implicit case in 3.6.0, modified in [25193].

see #24932.

[nacin]

In 25236:

Fix 'html5' theme support.

• Merge, rather than replace, on second add.
• Make current_theme_supports() work when two arguments are passed.
• Require the second argument to be an array.

Merges [25193] and [25235] to the 3.6 branch.
fixes #24932.