I'm guessing it is mostly the idea that IE8 and lower users will not be able to utilize these new tags.

<time> and <mark> were whitelisted in 1.21 however, so I'm not so sure IE≤8 support is still a valid issue.

Plus you've linked the shim solution for that concern just above anyway not to mention official support for IE8 ends on January 12, 2016 to boot.

The other reason is probably concern over the other HTML5 introduced tags like section or figcaption and how they'd fit-in or conflict-with other parser or extension generated tags. Still, that has more to do with the blocking tasks than it does with this one specifically.

At the very least you'd think they'd whitlelist some or all of these HTML5 tags on test.wikipedia.org & test2.wikipedia.org at this point in time - I don't see any good reason not to given the coming date dropping IE8 support is unavoidable.

<time> and <mark> were whitelisted in 1.21 however, so I'm not so sure IE≤8 support is still a valid issue.

IE8 doesn't crash when unknown elements are used. It just displays them as regular text. Which for content such as time and mark is a perfectly acceptable fallback in this case.

However using them for critical parts of the layout is a separate issue that has a potentially much larger impact. For those one or two elements I think we can stick with a <div> for simplicity sake. Relevant role="" attributes are available for accessibility. If there are any substantial gains from using the elements we could even consider using both (as long as we're talking about no more than a handful of central elements part of the skin layout).

. . . If there are any substantial gains from using the elements we could even consider using both (as long as we're talking about no more than a handful of central elements part of the skin layout).

Its wise to be cautious given the risk but supporting all the tags in question is going to happen someday (like it or not; IE8 still supported or not).

The only tag that I'm pretty sure is going to be a headache is HTML5's <section> tag versus the current LST extension's use of a self-closing <section begin= /> and <section end= /> tags. (exampled here; tags & content between <section> and </section> being stripped?)

Otherwise, I don't see the harm in activating (whitelisting) the ones without such "controversy" on at least test2.wikipedia.org for starters -- how else can we begin to discover those substantial gains and the crippling pitfalls?

@Jdlrobson As I understand it the IE8 RFC is not blocked on this skin change, and the opposite neither. Using HTML5 in production has had a go-ahead for 3+ years, since we shipped the html5shiv on all page views.

Once this rolls out, be sure to also test "Reader" mode in Firefox, Safari and Mobile Safari. Not just locally or beta, but also in production. Wikipedia's domain name quite regularly gets special-cased to optimise or fix things they run into.

Over-qualified CSS selectors of portals in Wikimedia skins have been changed. <code>div#p-personal</code>, <code>div#p-navigation</code>, <code>div#p-interaction</code>, <code>div#p-tb</code>, <code>div#p-lang</code>, <code>div#p-namespaces</code> or <code>div#p-variants</code> are now all removed of the <code>div</code> qualifier, as in for example it is <code>#p-personal, #p-navigation …</code>. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them.