1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Some elements of
[HTML5](http://www.whatwg.org/specs/web-apps/current-work/multipage/) can be
safely supported by ikiwiki. There are [several differences between HTML4 and
HTML5](http://www.w3.org/TR/html5-diff/).
[[!template id=gitbranch branch=hendry/html5 author="[[Kai_Hendry|hendry]]"]]
* [HTML5 branch](http://git.webconverger.org/?p=ikiwiki;h=refs/heads/html5)
* [ikiwiki instance with HTML5 templates](http://natalian.org)
* [HTML5 outliner tool](http://gsnedders.html5.org/outliner/) -- to check you have the structure of your markup correct
> Kai, thanks enormously for working on this. I switched a page to
> the html5 doctype today, and was rather pleasently suprised that it
> validated, except for the new Cache-Control meta tag. Now I see you're
> well ahead of me. --[[Joey]]
>
> So, how should ikiwiki support html5? There are basically 3 approaches:
>
> 1. Allow users to add html5 tags to their existing xhtml pages.
> What has been done so far, can be extended. Basically works
> in browsers, if you don't care about standards. A good prerequisite
> for anything else, anyway.
> 2. Have both a html5 and a xhtml mode, allow user to select.
> 3. Switch to html5 in eg, ikiwiki 4; users have to deal with
> any custom markup on their pages/templates that breaks then.
>
> The second option seems fairly tractable from what I see here and in
> your branch. You made only relatively minor changes to 10 templates.
> It would probably not be too dreadful to put them in ifdefs. I've made a
> small start at doing that.
>
> Some of your changes are obvious, like using the new `time` and
> and `article` elements. Others less so, and I'm particularly
> puzzled by these:
>
> * Removing the value="Submit" from the button on the
> commentmoderation form.
> * Removing feedlink.tmpl. What?!
> * Using a `h2` for the header of inlinepage.tmpl and page.tmpl, rather
> than the styled span. Ikiwiki has
> [[a_reason|todo/Option_to_make_title_an_h1?]] for not
> using real `hN` for the header atop a page and here.
> AFAICS, html5 does not invalidate that.
> * Removing Editurl from inlinepage.tmpl actions. I assume
> this is your own preference, needs to be removed from branch
> before I can use it.
> * Removing the pageheader, content, and footer divs
> which are all used by style.css.
> Perhaps, the style sheet needs to be updated to use
> the new elements, like the `footer` and `header`.
> * Removal of the favicon from page.tmpl. Surely html5 supports?
> * Removal of BASEURL from page.tmpl, apparently a mistake.
> * Removal of the `/` between wiki title and page title.
> Personal preference.
> * Removal of `comments` div, which is there to be styled.
> * Why use a `p` rather than the `div` for `addcomments`?
> * Moving the action bar to the bottom of the page.
> Personal preference.
> * Clearly searchquery.tmpl has no business using bad old `center`
> tag, but something should still be done to replace it.
>
> (BTW, it would be helpful if you could re-merge master into your branch
> as it is a bit diverged now.)
>
> Other ideas:
>
> * Use aside for the sidebar? Or for the [[templates/note]] template?
> * Use nav for the actionbar
> * Use details tag instead of the javascript in the toggle plugin.
> (Need to wait on browser support probably.)
>
> --[[Joey]]
# htmlscrubber.pm needs to not scrub new HTML5 elements
* [new elements](http://www.w3.org/TR/html5-diff/#new-elements)
> Many added now.
>
> Things I left out, too hard to understand today:
> Attributes contenteditable,
> data-\*, draggable, role, aria-\*.
> Tags command, keygen, output.
>
> Clearly unsafe: embed.
>
> Apparently cannot be used w/o javascript: menu.
>
> I have not added the new `ping` attribute, because parsing a
> space-separeated list of urls to avoid javascript injection is annoying,
> and the attribute seems generally dubious.
> --[[Joey]]
# HTML5 Validation and t/html.t
[validator.nu](http://validator.nu/) is the authorative HTML5 validator,
however it is almost impossible to sanely introduce as a build dependency
because of its insane Java requirements. :( I test locally via
[cURL](http://wiki.whatwg.org/wiki/IDE), though Debian packages cannot be built
with a network dependency.
In the future, hopefully ikiwiki can test for valid HTML5 using [Relax NG
schema](http://syntax.whattf.org/) using a Debian package tool
[rnv](http://packages.qa.debian.org/r/rnv.html).
> Validation in the test suite is nice, but I am willing to lose those
> tests for a while. --[[Joey]]
# HTML5 migration issues
# [article](http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-article-element) element
This element is poorly supported by browsers. As a workaround, `style.css` needs:
article {
display: block;
}
Internet Explorer will display it as a block, though you can't seem to be able to further control the style.
## Time element
The [time element](http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element) ideally needs the datatime= attribute set by a template variable with what [HTML5 defines as a valid datetime string](http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-global-date-and-time-string).
As a workaround:
au:~% grep timeformat natalian.setup
timeformat => '%Y-%m-%d',
> Also, the [[plugins/relativedate]] plugin needs to be updated to
> support relatatizing the contents of time elements. --[[Joey]]
> Done and done; in html5 mode it uses the time tag, and even
> adds pubdate when displaying ctimes. --[[Joey]]
## tidy plugin
Will reformat html5 to html4.
|