]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/todo/generate_HTML5_by_default.mdwn
59726bf04b9e3ebecdc2029ff7e4fd808aaa2b8c
[git.ikiwiki.info.git] / doc / todo / generate_HTML5_by_default.mdwn
1 The `html5` option was added in 2010 and marked as "not experimental" in 2011
2 but is not the default.
4 According to <http://caniuse.com/#feat=html5semantic>, current versions of
5 all recent versions of all major browsers - even IE - support the HTML5
6 semantic elements (`<section>` etc.), except for `<main>` which IkiWiki
7 doesn't use anyway. With that being the case, I'm not sure whether we gain
8 anything from not generating HTML5 (or "HTML" as it's now labelled) all the time.
10 In particular, non-HTML5 mode uses `<!DOCTYPE html PUBLIC
11 "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">`
12 which doesn't allow newer markup like the `role` attribute, so we can't close
13 [[todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible]] while
14 remaining XHTML 1.0 Strict. The recommended pseudo-doctype for HTML5, and for
15 HTML with ARIA markup, is `<!DOCTYPE html>`.
17 (I do think we should continue to use `<xml-compatible-tags />` and output
18 well-formed XML so people who want to do XSLT tricks with IkiWiki's output
19 can do so, though.)
21 In practice, real browsers have never actually implemented a strict XHTML mode:
22 they've always parsed `text/html` as "tag soup", because they need a tag-soup
23 parser anyway, and nobody wants to maintain two parsers.
25 Options include:
27 * set html5 to 1 by default but retain the dual-mode templates
28 * remove the option and always behave as if it had been 1, simplifying
29   the templates
31 Thoughts?
33 --[[smcv]]
35 > Another possibility would be to change the doctype to `<!DOCTYPE html>`
36 > unconditionally, stop trying to limit ourselves to XHTML 1.0 Strict
37 > (use HTML5 features that degrade gracefully, like
38 > [[ARIA roles|todo/add aria landmarks to make ikiwiki websites more accessible]]),
39 > but avoid using the new elements like `<section>` that require specific
40 > browser support unless `html5` is set to 1. That would get rid of the
41 > backwards-compatibility concerns while keeping the ability to use
42 > post-2000 markup. --[[smcv]]