So far everyone seems happy with the new layout, but I noticed one more problem. The top navbar (i.e. the list of links to other pages) still appears before the content of the page. This is a violation of web accessibility guidelines. The content should be the very first element on the page for maximum accesibility for anyone using a screen reader. Having to listen to 14 links before reaching the quote of the day isn't as bad as listening to the entire side bar droned out, but it's still annoying as hell. I suspect I'm going to have to absolutely postiion the header div at the top of the page. That's probably going to muck with the rest of the layout. As usual I'll post test pages for everyone to look at before doing anything too drastic. Expect more CSS shenanigans soon.

The W3C Multimodal Interaction Working Group has published the third public working draft of the Ink Markup Language. According to the abstract,

The Ink Markup Language serves as the data format for representing ink entered with an electronic pen or stylus. The markup allows for the input and processing of handwriting, gestures, sketches, music and other notational languages in Web-based (and non Web-based) applications. It provides a common format for the exchange of ink data between components such as handwriting and gesture recognizers, signature verifiers, and other ink-aware modules.

The following example of writing the word "hello" in InkML is given in the spec:

<ink>
   <trace>
     10 0 9 14 8 28 7 42 6 56 6 70 8 84 8 98 8 112 9 126 10 140
     13 154 14 168 17 182 18 188 23 174 30 160 38 147 49 135
     58 124 72 121 77 135 80 149 82 163 84 177 87 191 93 205
   </trace>
   <trace>
     130 155 144 159 158 160 170 154 179 143 179 129 166 125
     152 128 140 136 131 149 126 163 124 177 128 190 137 200
     150 208 163 210 178 208 192 201 205 192 214 180
   </trace>

   <trace>
     227 50 226 64 225 78 227 92 228 106 228 120 229 134
     230 148 234 162 235 176 238 190 241 204
   </trace>
   <trace>
     282 45 281 59 284 73 285 87 287 101 288 115 290 129
     291 143 294 157 294 171 294 185 296 199 300 213
   </trace>
   <trace>

     366 130 359 143 354 157 349 171 352 185 359 197
     371 204 385 205 398 202 408 191 413 177 413 163
     405 150 392 143 378 141 365 150
   </trace>
</ink>

<sarcasm>Gee, that's not the least bit opaque.</sarcasm>. This looks like the SVG mistake all over again. I wrote about this in Item 11 of Effective XML, "Make Structure Explicit through Markup.". The right way to solve this problem is something like this:

<ink>
  <trace>
    <coordinate><x>10</x> <y>0</y></coordinate>
    <coordinate><x>9</x> <y>14</y></coordinate>
    <coordinate><x>8</x> <y>28</y></coordinate>
    <coordinate><x>7</x> <y>42</y></coordinate>
    <coordinate><x>6</x> <y>56</y></coordinate>
    <coordinate><x>6</x> <y>70</y></coordinate>
    <coordinate><x>8</x> <y>84</y></coordinate>
    <coordinate><x>8</x> <y>98</y></coordinate>
    <coordinate><x>8</x> <y>112</y></coordinate>
    <coordinate><x>9</x> <y>26</y></coordinate>
    <coordinate><x>10</x> <y>140</y></coordinate>
    <coordinate><x>13</x> <y>154</y></coordinate>
    <coordinate><x>14</x> <y>168</y></coordinate>
    <coordinate><x>17</x> <y>182</y></coordinate>
    <coordinate><x>18</x> <y>188</y></coordinate>
    <coordinate><x>23</x> <y>174</y></coordinate>
    <coordinate><x>30 </x> <y>60</y></coordinate>
    <coordinate><x>38</x> <y>147</y></coordinate>
    <coordinate><x>49</x> <y>135</y></coordinate>
    <coordinate><x>58</x> <y>124</y></coordinate>
    <coordinate><x>72 </x> <y>21</y></coordinate>
    <coordinate><x>77</x> <y>135</y></coordinate>
    <coordinate><x>80</x> <y>149</y></coordinate>
    <coordinate><x>82</x> <y>163</y></coordinate>
    <coordinate><x>84</x> <y>177</y></coordinate>
    <coordinate><x>87</x> <y>191</y></coordinate>
    <coordinate><x>93</x> <y>205</y></coordinate>
  </trace>
</ink>

That's more verbose, but it's also much clearer. It would let the data be extracted with standard XML tools rather than requiring each user to write their own micro-parser for the trace elements. If InkML really can't afford to actually markup the x and y coordinates as x and y coordinates instead of raw text, then one wonders why it's using XML at all?

This draft adds a metadata element, defines the application/inkml+xml MIME media type, adds a documentID attribute, and includes more tutorial material. However, the fundamental problems with the proposed format have not been addressed or acknowledged.