HTML5

A page for ideas about what features of HTML5 we can use in MediaWiki, assuming we end up switching to it. See the spec. HTML5 was first enabled in MediaWiki by default in (July 10, 2009), and was enabled on Wikimedia sites on November 12. Then immediately disabled again because it caused problems with XMLHttpRequest not liking named entities. Yay. As of, that bug should be fixed, but it's not clear when it will be enabled again.

FAQ about MediaWiki use of HTML5

 * What exactly do you mean by HTML5?
 * This page only discusses using HTML5 for our static HTML markup, instead of XHTML 1.0 Transitional. Although HTML5 includes JavaScript APIs (getElementsByClassName, drag-and-drop, etc.) and other things too, using these is entirely uncontroversial and isn't covered here.


 * Why should we use HTML5?
 * First, HTML5 is the next HTML standard. All new HTML features will be added there, and we'll have to use it eventually if we want to take advantage of them.  Currently MediaWiki uses XHTML 1.0, which became a W3C Recommendation in January 2000 – ten years ago.  There are some modest immediate benefits to using HTML5 already (see  and  below), so we may as well switch sooner rather than later. Second of all, more idealistically, a major goal of HTML5 is to advance the open web by supplanting proprietary technologies like Flash and Silverlight.  It goes to great lengths to reduce the need for closed-source and vendor-locked software by introducing elements like and .  It also aims to drastically lower the bar to creating a new browser by specifying huge amounts of behavior that previously had to be painstakingly reverse-engineered from existing browsers.  All of this accords very closely with Wikimedia's values of "thriving open formats and open standards on the web", and both MediaWiki and Wikipedia should do what they can to be trendsetters and help advance these goals.


 * Isn't HTML5 unfinished?
 * HTML5 is a Draft Standard at the WHATWG, and is a late Working Draft at the W3C. Large parts of HTML5 are stable, and there's no reason not to use those parts.  See the WHATWG FAQ entry "When will HTML5 be finished?".  Part of the purpose of this page is to identify which parts of the spec are currently usable (and useful to us) in practice.


 * But HTML5 is tag soup!
 * HTML5 doesn't require XML well-formedness – e.g., you can omit attribute quote marks – but it does permit it. MediaWiki currently still outputs well-formed XML by default.  This means that by default, you can still (modulo bugs) parse MediaWiki pages using XML libraries, transform them via XSLT, etc.  MediaWiki administrators who want to reduce the size of output HTML can disable $wgWellFormedXml.  When HTML5 has been around for a while and HTML5 parsing libraries are as prevalent as XML parsing libraries, this benefit might not be so compelling anymore.


 * So MediaWiki outputs XHTML5?
 * According to the HTML5 spec, XHTML5 must be output with an XML MIME type. If you configure MediaWiki and/or your server to serve an XML MIME type, then it's possible you can get it to serve XHTML5, because XHTML5 is fairly close to a subset of HTML5, and it's possible by design to create documents that can be served as either HTML5 or XHTML5.  However, for practical purposes, people don't use XML MIME types much, so normally MediaWiki won't output XHTML5, but rather HTML5 that happens to be well-formed XML (if $wgWellFormedXml is true).  This gives most of the advantages of XML (such as they are), but doesn't cause minor output bugs or typos in system messages to break the site.


 * Will MediaWiki continue to support XHTML 1.0 Transitional?
 * Currently MediaWiki trunk still supports XHTML 1.0 Transitional (just disable $wgHtml5). It's not clear how long non-HTML5 output formats will remain supported, but XHTML 1.0 remains supported for the 1.16 release, and possibly many more after that if there's demand for it.

Already done
Useful things that have already been at least partially implemented in trunk, and require $wgHtml5 to be on.


 * HTML5 form attributes: required, pattern, etc. Maybe also new input types like date.  Started in.
 * Constraint validation is disabled for now due to poor browser support. See, , , .  Autofocus is still in.
 * Remove useless elements and attributes:, type="" on script/style. Started in , lots more done in later revisions but lots more still to do.
 * Use the spellcheck attribute where useful.  does this on edit summaries.

Short term
Things we can start doing as soon as we like without too much effort, without harmful side effects.


 * Support / without JavaScript.
 * Need to confirm fallback behavior on Safari w/o XiphQT, to make sure the fallback content [eg, Java player] is displayed correctly.
 * Should be possible to do with JavaScript. Currently we require JavaScript to get videos to work on any browser, so this will be a step forward!  At least Firefox and Chrome won't need it.
 * Use data-* if that's useful anywhere (HTML diffs used something like this at some point before removing them for XHTML validity reasons).
 * Use more comprehensible HTML IDs. Currently we restrict them to forms acceptable to HTML4, meaning a subset of ASCII, which results in horrible stuff for foreign languages (or even punctuation in English) with lots of dots and hex codes when we auto-generate header anchors.  HTML5 says IDs can be any Unicode string that doesn't contain whitespace, which would allow us to output much nicer-looking IDs.  (XHTML1 is more generous than HTML4 as well, but significantly less generous than HTML5: it doesn't allow most punctuation.)
 * Things to be careful of: what do browsers accept in practice? (Need to test anchors in links, in HTTP redirects, in CSS selectors, in JavaScript, anything else?)  Should we rule out some ASCII characters for the sake of better compatibility with, e.g., CSS?  (IDs with "." or ">" or such will require escaping for use in CSS.)  How should we handle backward compatibility with existing links from external sources?
 * The code for this is largely done (grep for $wgExperimentalHtmlIds), but can't be enabled until at least Opera 10.10 becomes irrelevant.

Medium term
Things that will take more care or effort, or will require broader browser support to be useful.


 * Remove closing tags, attribute quotes, etc. Need to be careful: breaking XML well-formedness might break bots.
 * The potential benefit here is reduced HTML output size, thus reduced bandwidth usage and faster page loads. (Hypothetically, inconsistent use of quotes might increase gzipped HTML size, but testing on a sample page gave 4061 bytes gzipped when always using quotes and 4045 when not.) Gains will be moderate, but they add up. The downside noted is that client-side tools doing UI screen scraping with an XML parser would fail; scrapers would need to use a proper HTML parser instead or move to using the API... worst case would be that they switch to regex-based scraping. :)
 * Also note that some devs have expressed strong objections to moving away from well-formed XML. This will need some arguing over.  :)
 * This is now controlled by the $wgWellFormedXml setting, defaults to true (keep outputting well-formed XML).
 * Embed MathML and SVG inline, at least for some users. We'd have to be very careful about sanitizing this to avoid XSS ― especially in the case of a browser that doesn't support inline MathML/SVG, and so will treat the contents of the tags as HTML.  (We could do this with XHTML 1 too, but only if we serve content with an XML MIME type, which we probably don't want to if we can avoid it.  So it would be more convenient with HTML5.)

Long term
Things that we can't do without more browser support. Not much point in working too much on this; too much will depend on how browser development progresses.


 * Start using semantic HTML5 tags like, , etc., and allow (some of) them in user input. This doesn't work acceptably in IE right now without JavaScript hacks: the elements can't be used for styling, so are mostly pointless.
 * Use new HTML5 functional tags like (in addition to / ). Long term because this doesn't seem to be possible to do usefully in a backward-compatible manner without script (is it?).
 * Yes, it is: the contents of and and such are available as fallback. But it's hard to think of uses for these.

Validity issues
Once we're sure we're going with HTML5, we need to start handling validity issues. One validity checker is at http://html5.validator.nu/ (although of course, like any validator, it will not catch all errors). Bugs should be filed on these, but here are some that are already known:


 * There are likely still places where the software outputs deprecated stuff like cellpadding, align, font, etc.
 * Line-initial : without a ; is usually used for indentation, and creates a &lt;dl> without any &lt;dt>'s. We need to make this output &lt;div class=indent> or something, if we can't persuade people to use semantic markup instead.
 * Might be a bad idea, seeing how this is being used on talk pages. —Ms2ger 14:23, 17 July 2009 (UTC)
 * That's why we can't just make it invalid. (It's used in articles too, to indent quotations and such.)  We can still change the markup generated so it's clearly presentational rather than pretending to be a definition list, while maintaining the current visual effect. —Simetrical (talk • contribs) 16:52, 17 July 2009 (UTC)
 * You could use  instead of   on Talk pages. 90.135.214.11 11:47, 18 September 2009 (UTC)
 * No we can't, it was removed three days ago. It would probably have been inappropriate anyway; the recommended way to do stuff like blog comments is nested &lt;article> tags, or maybe nested &lt;section>.  See the article element section. —Simetrical (talk • contribs) 18:05, 18 September 2009 (UTC)
 * Users can currently still input now-invalid elements/attributes like &lt;font>, cellpadding, etc. We could try to automatically translate these, but it would be tricky in some cases.  Also, maybe it's better to give the validation errors and encourage users to use semantic HTML instead of auto-translating their presentational garbage?

Also note Manual:$wgValidateAllHtml, but is tidy ready for HTML5?

Compatibility issues

 * There is no transitional doctype and hence no limited quirks mode (also called almost standards mode) in HTML5. With a strict doctype, some elements (notably inline images, but also elements whose  propery is   or  ) have descender space that they don't have when they appear within table cells with the current transitional doctype. The real fix for this is , but that is highly problematic for the content area because it can break things.   mostly hides the issue (except for images that are smaller than the current line-height) and Monobook and Vector do this anyway, but the Modern skin breaks. --Entlinkt 18:48, 8 August 2010 (UTC)
 * Investigation shows that the difference between limited-quirks mode and no-quirks mode is actually larger: inline images, inline-blocks and inline-tables don't create line boxes in quirks mode unless there is also a text node on the same line; this is true even outside tables. I have raised this issue at dewiki and nobody seems to care as long as it's not visibly broken. Maybe we should break it rather sooner than later, so people can bring themselves to fix it. --Entlinkt 21:37, 11 August 2010 (UTC)
 * People should be able to fix it pretty quickly. I don't think there's any better transition plan than just breaking it.  This is all held up on the fact that we're running months-old code on Wikimedia, trunk has been HTML5 by default for ages.  There are some fixes for XML well-formedness on trunk that need to be deployed before we can switch Wikimedia. —Simetrical (talk • contribs) 23:25, 11 August 2010 (UTC)
 * Not strictly HTML5 related because HTML4 already allowed colons in IDs, but still: These need to be escaped in CSS, but only Internet Explorer >= 8 allows the nice and easy way . IE 6 and 7 need the more complicated   syntax. IE <= 5.5 does not support escaping in CSS at all. --Entlinkt 18:48, 8 August 2010 (UTC)
 * Did some more testing on problematic characters and found these so far:
 * Section 3.5 of RFC 3986 contains harsh restrictions about fragment identifiers. See this thread, and also another one about  issues. --Entlinkt 17:07, 20 August 2010 (UTC)
 * RFC 3987 is more relevant. But the worst we have to do is URL-encode the fragment, then it's fine.  (pchar includes pct-encoded.)  In practice we probably don't even have to do that, browsers will handle the encoding for us if it's unambiguous. —Simetrical (talk • contribs) 17:20, 20 August 2010 (UTC)