HTML5

A page for ideas about what features of HTML 5 we can use in MediaWiki, assuming we end up switching to it. See the spec.

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.
 * HTML 5 form attributes: required, pattern, etc. Maybe also new input types like date (is this workable in the short term?).
 * Started in
 * Remove useless elements and attributes:, type="" on script/style.
 * Started in
 * Use data-* if that's useful anywhere (HTML diffs used something like this at some point before removing them for XHTML validity reasons).

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. 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.  :)
 * 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 HTML 5.)

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 HTML 5 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 HTML 5 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?).

Validity issues
Once we're sure we're going with HTML 5, we need to start handling validity issues. One validity checker is at http://validator.w3.org/ (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)
 * 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 HTML 5?