Page MenuHomePhabricator

Enable, whitelist, and incorporate semantic HTML5 elements
Open, LowPublic

Tokens
"Love" token, awarded by ToBeFree."Love" token, awarded by Liuxinyu970226."Love" token, awarded by Danny_B."Love" token, awarded by Volker_E."Love" token, awarded by Ricordisamoa."The World Burns" token, awarded by Bennylin."Love" token, awarded by Kulla.
Assigned To
None
Authored By
bzimport, Jun 12 2010

Description

Author: michael

Description:
article, aside, figcaption, figure, footer, header, main, mark, nav, picture, progress, section, time

Many of these tags are a natural compliment or enhancement to the structure of Wikipedia's and Wiktionaries. Levels of support:

  • Whitelist, to allow use in wikitext.
  • Enable for non-supporting browsers (Internet Explorer 6, 7, 8).
  • Add HTML5 elements to wikitext rendering.
  • Incorporate HTML5 elements into Vector skin.

There's already some support in Mozilla 3.6 and Safari 5. An enabling script is required for IE 6-8 to enable applying CSS styles to these elements.

References

W3C: HTML5
http://www.w3.org/TR/html5/

WHATWG: HTML5
http://www.whatwg.org/specs/web-apps/current-work/

Wikipedia: HTML5
http://en.wikipedia.org/wiki/HTML5

New semantic elements in HTML5
http://diveintohtml5.org/semantics.html#new-elements

HTML5 enabling script
http://remysharp.com/2009/01/07/html5-enabling-script/

See also T2671 - Whitelist more HTML tags: abbr acronym address dfn kbd q samp

Support status as of 2016-03-18 (1.27)

iconmeaning
invalid (aka not a part of <body>)
disabled for security reasons
disabled for security reasons (scripting)
disabled for security reasons (interactive form control)
handled or overrided by MediaWiki core
handled or overrided by MediaWiki extension
enabled
enablable - semantic markup
enablable - tables enhancement
enablable - needs some work though
enablable - form control without interaction, for semantic markup
tag?notes
<a>via discussion with @tstarling doable (in favour of enabling various relevant attributes rather than expanding the current [[..|..]] syntax) [there might be a task for it]
<abbr>
<address>old HTML spec, not a new feature
<area>handled by ImageMap (<imagemap>)
<article>
<aside>T104770: HTML5 Semantic element <aside></aside> not seemingly parsed.
<audio>
<b>
<base>
<bdi>
<bdo>
<blockquote>
<body>
<br>
<button>
<canvas>
<caption>
<cite>
<code>
<col>old HTML spec, not a new feature; T2986: [tables] Please implement COL, COLGROUP
<colgroup>old HTML spec, not a new feature; T2986: [tables] Please implement COL, COLGROUP
<data>
<datalist>
<dd>
<del>
<details>
<dfn>
<div>
<dl>
<dt>
<em>
<embed>T18316: Tags like <embed> are needed
<fieldset>old HTML spec, not a new feature; with <legend>
<figcaption>
<figure>
<footer>
<form>
<h1>
<h2>
<h3>
<h4>
<h5>
<h6>
<head>
<header>
<hr>
<html>
<i>
<iframe>T18316: Tags like <embed> are needed
<img>
<input>
<ins>
<kbd>
<keygen>deprecated now (see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen)
<label>
<legend>old HTML spec, not a new feature; with <fieldset>
<li>
<link>
<main>
<map>handled by ImageMap (<imagemap>)
<mark>
<meta>
<meter>T211259 fallbackable [ 1, 2 ] to its content: <p>Disk usage: <meter min=0 value=170261928 max=233257824>170 261 928 bytes used out of 233 257 824 bytes available</meter></p>
<nav>
<noscript>T47731: Allow <noscript> tag
<object>T18316: Tags like <embed> are needed
<ol>
<optgroup>
<option>
<output>
<p>
<param>
<picture>
<pre>
<progress>fallbackable [ 1, 2 ] to its content: <p>Progress: <progress id="p" max=100><span>0</span>%</progress></p>
<q>
<rb>
<rp>
<rt>
<rtc>
<ruby>
<s>
<samp>
<script>
<section>handled by MediaWiki-extensions-LabeledSectionTransclusion T32597: <section> tag name collides with HTML 5 <section> tag
<select>
<small>
<source>handled by SyntaxHighlight T39042: Remove <source> syntax from SyntaxHighlight (GeSHi)
<span>
<strong>
<style>T52644: Support <style scoped> as HTML element in wiki source; in favour of Accessibility and T89134: Removing inline CSS/JS from MediaWiki, T37704: Drop support in wikitext for inline styles and others
<sub>
<summary>
<sup>
<table>
<tbody>old HTML spec, not a new feature; T6740: thead, tbody, tfoot for wikitable syntax T5156: Request not to filter <tbody> and </tbody> codes
<td>
<template>
<textarea>
<tfoot>old HTML spec, not a new feature; T6740: thead, tbody, tfoot for wikitable syntax T5156: Request not to filter <tbody> and </tbody> codes
<th>
<thead>old HTML spec, not a new feature; T6740: thead, tbody, tfoot for wikitable syntax T5156: Request not to filter <tbody> and </tbody> codes
<time>
<title>overridable by {{DISPLAYTITLE:}}
<tr>
<track>
<u>
<ul>
<var>
<video>
<wbr>

Details

Reference
bz23932

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
TTO added a subscriber: TTO.Nov 25 2015, 2:27 AM

Stupid question: can't we just "enable" (or whitelist?) these new HTML5 elements just on test2.wikipedia.org for now?
It seems better to have a place where folks can begin to safely experiment with these new elements ahead of the formal adaptation date, no?

This isn't possible right now: the whitelist is hard-coded deep in the MediaWiki parser, so cannot be altered on a per-wiki basis. That feature is requested in T12180: Hooks needed in Sanitizer to control acceptable tags and attributes.

Volker_E renamed this task from Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, figcaption, figure, footer, header, hgroup, mark, nav, section, time to Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, figcaption, figure, footer, header, main, mark, nav, picture, progress, section, time.Dec 5 2015, 5:23 AM
Volker_E updated the task description. (Show Details)

Updated task description to reflect current state of W3C HTML5 recommendation of 28 Oct 2014 and WHATWG HTML Living Standard of 4 Dec 2015 -- removing <hgroup> and adding <main>, <picture> and <progress>,
<audio> and <video> are already supported by Extension:TimedMediaHandler

Rezonansowy added a comment.EditedDec 5 2015, 3:19 PM

Updated task description to reflect current state of W3C HTML5 recommendation of 28 Oct 2014 and WHATWG HTML Living Standard of 4 Dec 2015 -- removing <hgroup> and adding <main>, <picture> and <progress>,
<audio> and <video> are already supported by Extension:TimedMediaHandler

Why did you remove the <hgroup> element? It's present on WHATWG HTML Living Standard of 4 Dec 2015, which is newer than this from 2014 and it's a living standard. I restored this.

Rezonansowy renamed this task from Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, figcaption, figure, footer, header, main, mark, nav, picture, progress, section, time to Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, figcaption, figure, footer, header, hgroup, main, mark, nav, picture, progress, section, time.Dec 5 2015, 3:21 PM

If the T12467 has the 'Low', this should has the same as well. These bugs are strictly connected.

Rezonansowy raised the priority of this task from Lowest to Low.Dec 14 2015, 11:43 PM

@Rezonansowy You're right as there is no clear outcome of the discussion to drop <hgroup> completely from the WHATWG spec as it has implications on the (not yet supported anywhere) outline algorithm. In a side note, hgroup was dropped in popular normalize.css project days ago by a patch by Jonathan Neal. He also explains in an article, why hgroup is still around in WHATWG.

Volker_E updated the task description. (Show Details)Jan 6 2016, 11:15 PM

For completing the discussion, regarding the accessibility tag on this task, I'd like to copy a clarifying comment from T111117#1899121

A screen reader accesses the DOM in modern browsers via the accessibility tree. In Google Chrome you can see what's exposed by visiting chrome://accessibility/
It doesn't matter if you wrap the footer contents in a <footer> or a <div> element as long as the broader supported attribute role=contentinfo is available on either. There is currently no accessibility advantage on using <footer> over <div>, besides the future possibility of getting rid of the role attribute. But IE up to 11 and also older browsers need us to stay with the attribute.

Exemplified in Vector there's no advantage.

Danny_B moved this task from Unsorted to Semantic HTML on the Accessibility board.Jan 22 2016, 9:44 PM
Danny_B renamed this task from Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, figcaption, figure, footer, header, hgroup, main, mark, nav, picture, progress, section, time to Enable, whitelist, and incorporate semantic HTML5 elements.Feb 22 2016, 5:21 PM
Danny_B updated the task description. (Show Details)
Danny_B edited subscribers, added: tstarling; removed: wikibugs-l-list.
Danny_B updated the task description. (Show Details)Feb 22 2016, 5:26 PM
Dinoguy1000 updated the task description. (Show Details)Mar 4 2016, 5:28 AM
Danny_B updated the task description. (Show Details)Mar 15 2016, 6:33 PM
Restricted Application added a subscriber: Luke081515. · View Herald TranscriptMar 18 2016, 8:28 PM
MGChecker updated the task description. (Show Details)Mar 18 2016, 8:47 PM
Danny_B updated the task description. (Show Details)Mar 19 2016, 1:26 PM
Danny_B updated the task description. (Show Details)Mar 19 2016, 5:10 PM
Danny_B updated the task description. (Show Details)May 4 2016, 10:13 PM
Danny_B updated the task description. (Show Details)May 5 2016, 10:32 PM
Krinkle removed a subscriber: Krinkle.May 10 2016, 4:06 PM
Danny_B updated the task description. (Show Details)May 25 2016, 11:01 AM
Rezonansowy updated the task description. (Show Details)May 25 2016, 11:22 AM
Danny_B updated the task description. (Show Details)May 25 2016, 11:29 AM
Nirmos added a subscriber: Nirmos.Sep 14 2017, 4:40 PM

Is there anything holding this off now that T147199 is happening?

Pcoombe removed a subscriber: Pcoombe.Sep 14 2017, 5:24 PM
BBlack added a subscriber: BBlack.Sep 18 2017, 3:09 PM

Re: T147199 , you'll probably want to re-evaluate UA stats after Nov 17 to see what the true final fallout is. It *should* significantly reduce the population of certain ancient UAs (notably, IE7-8/XP), but there are a few ways such UAs can stick around as well, and we can't readily predict what the numbers will look like:

  1. There's a complex hack (too complex and off the beaten path for us to recommend it to users, anyways) where one can get better-than-3DES crypto with IE8/XP by manually applying some registry hack to convince MS update servers that it's the POSReady commercial variant of XP, which got a longer support lifetime and some crypto DLL updates. Users who go down this road might use IE8/XP longer than others (though I can't fathom why they'd make this choice, it's still horribly insecure in all other senses).
  2. Some IE7-8/XP users might sit behind TLS-intercepting proxies which upgrade their outbound crypto. E.g. there might be software on the host, or a network appliance, which accepts their crappy 3DES TLS connection, uses a fake root installed on the host to enable TLS proxying in general, and then does better crypto on the outbound side facing our servers.
  3. IE7 (and 8 presumably?) also exists for Windows Vista, and IE7/Vista is not shut out by our crypto changes, as it supports TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA via TLSv1.0. This isn't the best crypto option in the world, but it's good enough that it's not going away this year. However, it will probably drop off significantly from whatever its current popularity level is by mid-2018, and depending on the drop in popularity, we may or may not shut it out at the crypto level when the stat drops off sufficiently. The driver here is that by mid-2018 (in many cases, it might get done earlier) all sites that accept credit cards have to eliminate TLSv1.0 to keep up with PCI-DSS standards. PCI-DSS isn't a requirement for our wikis, but it's expected that the lack of compatibility with most of the rest of the commercial internet will drive straggling users away from these older UAs for us.
Liuxinyu970226 awarded a token.

you'll probably want to re-evaluate UA stats after Nov 17 to see what the true final fallout is

If I'm reading https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-tabular-view correctly, then IE8 is at 0.5%. If we assume that 1% of those have disabled JavaScript, that makes it 0.005% of all users, or five in ten thousand. Is that good enough to start whitelisting a few HTML5 elements in wikitext?

Nirmos updated the task description. (Show Details)Dec 5 2018, 11:40 PM
Nirmos updated the task description. (Show Details)Dec 6 2018, 12:43 AM

The diff in https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-TASK-4o7rea2lrkhv4y4/ is illegible. All I did was adding <details> and <summary>.

you'll probably want to re-evaluate UA stats after Nov 17 to see what the true final fallout is

If I'm reading https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-tabular-view correctly, then IE8 is at 0.5%. If we assume that 1% of those have disabled JavaScript, that makes it 0.005% of all users, or five in ten thousand. Is that good enough to start whitelisting a few HTML5 elements in wikitext?

Wait a minute, 0.005% isn't "five in ten thousand". It's five in a hundred thousand, isn't it?

cscott added a subscriber: cscott.Jan 11 2019, 3:08 AM

Parsoid uses <section>, <figcaption>, and <figure> already in its output (and thus the main parser will too, as Parsoid is merged into core). <picture> could be considered as part of media layout, but we are using other better-supported mechanisms for responsive images at the moment. These tags should not be whitelisted in article content as they conflict with wikitext features.

A number of the remaining tags are related to overall page organization; they should be emitted by the theme, but should not be whitelisted in article content as such use would conflict with the <section> tags already emitted and with the document structure emitted by the theme: <footer>, <header>, <article>, <aside>, <main>, and <nav>.

I have no issue whitelisting the rest: <mark>, <progress>, and <time>. (Of these, <mark> seems the most obviously useful.)

I have no issue whitelisting the rest: <mark>, <progress>, and <time>. (Of these, <mark> seems the most obviously useful.)

What about <meter>, <details> and <summary>?

Cavila added a subscriber: Cavila.Jan 24 2019, 4:03 PM