[whatwg] Feedback on a variety of elements

Mon Dec 31 11:09:49 PST 2012

On Fri Dec 14 2012, Ian Hickson wrote:

> I don't think this works for all tables. For example, the first example in
> the spec in the <th> element's section does not get handled correctly by
> your algorithm -- it treats the ID column as important, instead of the
> second column.

I may did not used the correct word to identify that kind of cell that
I named "Key cell". The objective of the "Key cell" is to identify a
"td" cell that have a relationships to a "th" cell at his right side
in the same row. The "td" rowspan attribute would need to match or be
lower than the corresponding "th". The inverse would show a data cell
"td" used as an heading cell "th".

The current relationships algorithm create a relationship for the
preceding "th" cell not following "th" cell.

> Without the scope="" attributes, I don't think that table
> would make much sense.

You have right that the proposed algorithm, for the first example in
the spec in the <th> element's section does not get handled correctly.

The question is: Why from a visual point of view, by excluding any
styling, can you feel that "Cats" cell and the "English speakers" cell
is know as a row group as highlighted in the source code with the
scope attribute set to "rowgroup"?

My answer is: Because the header cell is surounded by empty data cell
in his row. For me that represent a mix of a layout table combined
with a data table. A quick fix to the proposed algorithm would be at
the end of the data row processing, do a test to know if the header
cell is surrounded by empty data cell, that until the first real data
row is found in the rowgroup (tbody) section. If that is true, the
header cell scope can be determined as a rowgroup header and the
surrounded empty data cell can be know as layout cell. Is that make
sense? Have you another visual logic regarding that case?

> Similarly, the "Characteristics with positive and
> negative sides" example used a number of times in the HTML spec works
> better with a few headers="" attributes to define the mappings than
> without, as far as I can tell

The raison you need the "headers" attributes is because the current
relationships algorithm do not support the "Key cell" relationship as
explained above.

> (though your algorithm does make a valiant
> attempt, I will grant you).

Thank you, I will do my best to explain the table usability concept.

> > Proposal: Table Usability API
>
> This is a very elaborate and large API. What are the use cases against
> which to evaluate it? i.e. what problem does it solve?

The main use case is to parse a complex table and extract the data in
the objectif to create an accessible (WCAG 2.0 Level AA compliant)
chart by using the progressive enhancement strategy. The use of the
table to create the chart remove the need for an web author to discus
and sometime debate with the content provider in the objectif to build
a descriptive text alternative version of the chart.

Also the proposed Table Usability API is not just to handle complex
table. The proposed API provide support access the tabular data either
by his row or by his columns. Sometime, for presentational purpose,
the axes are reversed.

As an example took the following two row table. Do you think, for
presentational purpose, it will be better have a two column table
instead? I think both table, with equivalent structure, should be
supported and have an equivalent accessible API.

(reference: http://agora.ic.gc.ca/lineActivityRevenue_eng.cfm?p_auction_id=5.0&p_round_no=331)
<h2>Revenue Graph</h2>
<table class="wet-boew-charts wb-charts-line wb-charts-height-450
wb-charts-width-550">
<caption>Standing High Bids (M$)</caption>
<thead>
<tr>
<th>Round</th>
<td>1</td>
<td>2</td>
<td>3</td>
<td>4</td>
<td>5</td>
<td>6</td>
<td>7</td>
<td>8</td>
<td>9</td>
<td>10</td>
<td>11</td>
<td>12</td>
<td>13</td>
<td>14</td>
<td>15</td>
<td>16</td>
<td>17</td>
<td>18</td>
<td>19</td>
<td>20</td>
<td>21</td>
<td>22</td>
<td>23</td>
<td>24</td>
<td>25</td>
<td>26</td>
<td>27</td>
<td>28</td>
<td>29</td>
<td>30</td>
<td>31</td>
<td>32</td>
<td>33</td>
<td>34</td>
<td>35</td>
<td>36</td>
<td>37</td>
<td>38</td>
<td>39</td>
<td>40</td>
<td>41</td>
<td>42</td>
<td>43</td>
<td>44</td>
<td>45</td>
<td>46</td>
<td>47</td>
<td>48</td>
<td>49</td>
<td>50</td>
<td>51</td>
<td>52</td>
<td>53</td>
<td>54</td>
<td>55</td>
<td>56</td>
<td>57</td>
<td>58</td>
<td>59</td>
<td>60</td>
<td>61</td>
<td>62</td>
<td>63</td>
<td>64</td>
<td>65</td>
<td>66</td>
<td>67</td>
<td>68</td>
<td>69</td>
<td>70</td>
<td>71</td>
<td>72</td>
<td>73</td>
<td>74</td>
<td>75</td>
<td>76</td>
<td>77</td>
<td>78</td>
<td>79</td>
<td>80</td>
<td>81</td>
<td>82</td>
<td>83</td>
<td>84</td>
<td>85</td>
<td>86</td>
<td>87</td>
<td>88</td>
<td>89</td>
<td>90</td>
<td>91</td>
<td>92</td>
<td>93</td>
<td>94</td>
<td>95</td>
<td>96</td>
<td>97</td>
<td>98</td>
<td>99</td>
<td>100</td>
<td>101</td>
<td>102</td>
<td>103</td>
<td>104</td>
<td>105</td>
<td>106</td>
<td>107</td>
<td>108</td>
<td>109</td>
<td>110</td>
<td>111</td>
<td>112</td>
<td>113</td>
<td>114</td>
<td>115</td>
<td>116</td>
<td>117</td>
<td>118</td>
<td>119</td>
<td>120</td>
<td>121</td>
<td>122</td>
<td>123</td>
<td>124</td>
<td>125</td>
<td>126</td>
<td>127</td>
<td>128</td>
<td>129</td>
<td>130</td>
<td>131</td>
<td>132</td>
<td>133</td>
<td>134</td>
<td>135</td>
<td>136</td>
<td>137</td>
<td>138</td>
<td>139</td>
<td>140</td>
<td>141</td>
<td>142</td>
<td>143</td>
<td>144</td>
<td>145</td>
<td>146</td>
<td>147</td>
<td>148</td>
<td>149</td>
<td>150</td>
<td>151</td>
<td>152</td>
<td>153</td>
<td>154</td>
<td>155</td>
<td>156</td>
<td>157</td>
<td>158</td>
<td>159</td>
<td>160</td>
<td>161</td>
<td>162</td>
<td>163</td>
<td>164</td>
<td>165</td>
<td>166</td>
<td>167</td>
<td>168</td>
<td>169</td>
<td>170</td>
<td>171</td>
<td>172</td>
<td>173</td>
<td>174</td>
<td>175</td>
<td>176</td>
<td>177</td>
<td>178</td>
<td>179</td>
<td>180</td>
<td>181</td>
<td>182</td>
<td>183</td>
<td>184</td>
<td>185</td>
<td>186</td>
<td>187</td>
<td>188</td>
<td>189</td>
<td>190</td>
<td>191</td>
<td>192</td>
<td>193</td>
<td>194</td>
<td>195</td>
<td>196</td>
<td>197</td>
<td>198</td>
<td>199</td>
<td>200</td>
<td>201</td>
<td>202</td>
<td>203</td>
<td>204</td>
<td>205</td>
<td>206</td>
<td>207</td>
<td>208</td>
<td>209</td>
<td>210</td>
<td>211</td>
<td>212</td>
<td>213</td>
<td>214</td>
<td>215</td>
<td>216</td>
<td>217</td>
<td>218</td>
<td>219</td>
<td>220</td>
<td>221</td>
<td>222</td>
<td>223</td>
<td>224</td>
<td>225</td>
<td>226</td>
<td>227</td>
<td>228</td>
<td>229</td>
<td>230</td>
<td>231</td>
<td>232</td>
<td>233</td>
<td>234</td>
<td>235</td>
<td>236</td>
<td>237</td>
<td>238</td>
<td>239</td>
<td>240</td>
<td>241</td>
<td>242</td>
<td>243</td>
<td>244</td>
<td>245</td>
<td>246</td>
<td>247</td>
<td>248</td>
<td>249</td>
<td>250</td>
<td>251</td>
<td>252</td>
<td>253</td>
<td>254</td>
<td>255</td>
<td>256</td>
<td>257</td>
<td>258</td>
<td>259</td>
<td>260</td>
<td>261</td>
<td>262</td>
<td>263</td>
<td>264</td>
<td>265</td>
<td>266</td>
<td>267</td>
<td>268</td>
<td>269</td>
<td>270</td>
<td>271</td>
<td>272</td>
<td>273</td>
<td>274</td>
<td>275</td>
<td>276</td>
<td>277</td>
<td>278</td>
<td>279</td>
<td>280</td>
<td>281</td>
<td>282</td>
<td>283</td>
<td>284</td>
<td>285</td>
<td>286</td>
<td>287</td>
<td>288</td>
<td>289</td>
<td>290</td>
<td>291</td>
<td>292</td>
<td>293</td>
<td>294</td>
<td>295</td>
<td>296</td>
<td>297</td>
<td>298</td>
<td>299</td>
<td>300</td>
<td>301</td>
<td>302</td>
<td>303</td>
<td>304</td>
<td>305</td>
<td>306</td>
<td>307</td>
<td>308</td>
<td>309</td>
<td>310</td>
<td>311</td>
<td>312</td>
<td>313</td>
<td>314</td>
<td>315</td>
<td>316</td>
<td>317</td>
<td>318</td>
<td>319</td>
<td>320</td>
<td>321</td>
<td>322</td>
<td>323</td>
<td>324</td>
<td>325</td>
<td>326</td>
<td>327</td>
<td>328</td>
<td>329</td>
<td>330</td>
<td>331</td>
</tr>
</thead>
<tbody>
<tr>
<th>Revenue</th>
<td>$490.9m</td>
<td>$560.2m</td>
<td>$627.6m</td>
<td>$701m</td>
<td>$779.5m</td>
<td>$864.3m</td>
<td>$965.5m</td>
<td>$1043.9m</td>
<td>$1139.5m</td>
<td>$1262m</td>
<td>$1399.4m</td>
<td>$1564m</td>
<td>$1713.1m</td>
<td>$1814.1m</td>
<td>$1932.2m</td>
<td>$2084m</td>
<td>$2192.4m</td>
<td>$2309.6m</td>
<td>$2437m</td>
<td>$2545.2m</td>
<td>$2626.5m</td>
<td>$2711.5m</td>
<td>$2778.9m</td>
<td>$2851.8m</td>
<td>$2887.7m</td>
<td>$2922.8m</td>
<td>$2958.8m</td>
<td>$2991.7m</td>
<td>$3028.9m</td>
<td>$3071.4m</td>
<td>$3105.7m</td>
<td>$3131.2m</td>
<td>$3144.3m</td>
<td>$3155.1m</td>
<td>$3193.6m</td>
<td>$3239m</td>
<td>$3185m</td>
<td>$3210.7m</td>
<td>$3237.1m</td>
<td>$3272.2m</td>
<td>$3395m</td>
<td>$3415.4m</td>
<td>$3436.2m</td>
<td>$3356.2m</td>
<td>$3369.1m</td>
<td>$3481.6m</td>
<td>$3497.3m</td>
<td>$3509.6m</td>
<td>$3521.8m</td>
<td>$3532.9m</td>
<td>$3544.4m</td>
<td>$3552.5m</td>
<td>$3564.9m</td>
<td>$3577.1m</td>
<td>$3588.3m</td>
<td>$3598.3m</td>
<td>$3611.1m</td>
<td>$3617.9m</td>
<td>$3631.2m</td>
<td>$3643.3m</td>
<td>$3653.9m</td>
<td>$3664m</td>
<td>$3675.1m</td>
<td>$3685.8m</td>
<td>$3695.9m</td>
<td>$3706.4m</td>
<td>$3717.7m</td>
<td>$3729.1m</td>
<td>$3742.1m</td>
<td>$3755.3m</td>
<td>$3766.9m</td>
<td>$3775.5m</td>
<td>$3686.6m</td>
<td>$3771.1m</td>
<td>$3798.4m</td>
<td>$3805.3m</td>
<td>$3811m</td>
<td>$3816.3m</td>
<td>$3822.6m</td>
<td>$3829.9m</td>
<td>$3836.5m</td>
<td>$3842.1m</td>
<td>$3848.6m</td>
<td>$3854.9m</td>
<td>$3860.8m</td>
<td>$3866.7m</td>
<td>$3873.2m</td>
<td>$3879.5m</td>
<td>$3884.7m</td>
<td>$3889.5m</td>
<td>$3894m</td>
<td>$3898.4m</td>
<td>$3902.4m</td>
<td>$3907m</td>
<td>$3912.4m</td>
<td>$3917.3m</td>
<td>$3922.6m</td>
<td>$3927.9m</td>
<td>$3933.8m</td>
<td>$3940.5m</td>
<td>$3946.4m</td>
<td>$3952.3m</td>
<td>$3959m</td>
<td>$3964.1m</td>
<td>$3969.7m</td>
<td>$3976m</td>
<td>$3980.8m</td>
<td>$3984.6m</td>
<td>$3958.7m</td>
<td>$3980.4m</td>
<td>$4000.2m</td>
<td>$4004.7m</td>
<td>$4009.2m</td>
<td>$4013.7m</td>
<td>$4017.7m</td>
<td>$4023.8m</td>
<td>$4028.8m</td>
<td>$4033.4m</td>
<td>$4038.5m</td>
<td>$4043.2m</td>
<td>$4046.6m</td>
<td>$4050m</td>
<td>$4053.3m</td>
<td>$4057.9m</td>
<td>$4060.5m</td>
<td>$4060.6m</td>
<td>$4066.7m</td>
<td>$4071.9m</td>
<td>$4075.7m</td>
<td>$4078.8m</td>
<td>$4081.7m</td>
<td>$4084.7m</td>
<td>$4087.8m</td>
<td>$4090.4m</td>
<td>$4092.8m</td>
<td>$4083.1m</td>
<td>$4099m</td>
<td>$4102.1m</td>
<td>$4104.6m</td>
<td>$4106.5m</td>
<td>$4070.1m</td>
<td>$4087.3m</td>
<td>$4090.2m</td>
<td>$4105.8m</td>
<td>$4110.4m</td>
<td>$4129.6m</td>
<td>$4133.4m</td>
<td>$4136.4m</td>
<td>$4139.1m</td>
<td>$4142.5m</td>
<td>$4145.4m</td>
<td>$4148.1m</td>
<td>$4150.7m</td>
<td>$4153.4m</td>
<td>$4156m</td>
<td>$4158.5m</td>
<td>$4161.3m</td>
<td>$4162.8m</td>
<td>$4164.4m</td>
<td>$4165.9m</td>
<td>$4167.8m</td>
<td>$4169.4m</td>
<td>$4170.6m</td>
<td>$4172.1m</td>
<td>$4173.2m</td>
<td>$4174.5m</td>
<td>$4176.4m</td>
<td>$4178.1m</td>
<td>$4179.9m</td>
<td>$4182m</td>
<td>$4183.1m</td>
<td>$4184.1m</td>
<td>$4185m</td>
<td>$4185.8m</td>
<td>$4187.1m</td>
<td>$4188.2m</td>
<td>$4189.4m</td>
<td>$4190m</td>
<td>$4190.5m</td>
<td>$4190.8m</td>
<td>$4191.1m</td>
<td>$4183.6m</td>
<td>$4192.5m</td>
<td>$4192.7m</td>
<td>$4191m</td>
<td>$4191.5m</td>
<td>$4193.6m</td>
<td>$4194.1m</td>
<td>$4195.1m</td>
<td>$4195.3m</td>
<td>$4195.4m</td>
<td>$4195.5m</td>
<td>$4195.7m</td>
<td>$4195.9m</td>
<td>$4196m</td>
<td>$4196.1m</td>
<td>$4196.2m</td>
<td>$4196.3m</td>
<td>$4196.3m</td>
<td>$4196.4m</td>
<td>$4196.5m</td>
<td>$4196.6m</td>
<td>$4196.6m</td>
<td>$4196.7m</td>
<td>$4196.8m</td>
<td>$4196.9m</td>
<td>$4197m</td>
<td>$4197.1m</td>
<td>$4197.1m</td>
<td>$4197.2m</td>
<td>$4197.3m</td>
<td>$4197.4m</td>
<td>$4197.5m</td>
<td>$4197.6m</td>
<td>$4197.6m</td>
<td>$4197.7m</td>
<td>$4197.8m</td>
<td>$4198m</td>
<td>$4198.1m</td>
<td>$4198.3m</td>
<td>$4198.4m</td>
<td>$4198.6m</td>
<td>$4198.9m</td>
<td>$4199m</td>
<td>$4199.1m</td>
<td>$4199.2m</td>
<td>$4197.5m</td>
<td>$4197.6m</td>
<td>$4197.8m</td>
<td>$4197.9m</td>
<td>$4197.9m</td>
<td>$4197.9m</td>
<td>$4198.5m</td>
<td>$4198.7m</td>
<td>$4198.8m</td>
<td>$4198.7m</td>
<td>$4198.1m</td>
<td>$4199.1m</td>
<td>$4199.2m</td>
<td>$4198.7m</td>
<td>$4200.3m</td>
<td>$4201.9m</td>
<td>$4201.9m</td>
<td>$4201.2m</td>
<td>$4201.4m</td>
<td>$4201.8m</td>
<td>$4182.4m</td>
<td>$4189.2m</td>
<td>$4204.9m</td>
<td>$4205.5m</td>
<td>$4206m</td>
<td>$4206.7m</td>
<td>$4207.4m</td>
<td>$4208m</td>
<td>$4208.9m</td>
<td>$4209.9m</td>
<td>$4210.9m</td>
<td>$4211.3m</td>
<td>$4211.8m</td>
<td>$4212.3m</td>
<td>$4212.6m</td>
<td>$4213m</td>
<td>$4213.4m</td>
<td>$4213.8m</td>
<td>$4214.2m</td>
<td>$4214.6m</td>
<td>$4214.9m</td>
<td>$4215.3m</td>
<td>$4215.8m</td>
<td>$4216.1m</td>
<td>$4216.4m</td>
<td>$4216.7m</td>
<td>$4217.1m</td>
<td>$4217.4m</td>
<td>$4217.7m</td>
<td>$4217.9m</td>
<td>$4218m</td>
<td>$4218.2m</td>
<td>$4218.5m</td>
<td>$4218.8m</td>
<td>$4219m</td>
<td>$4219.6m</td>
<td>$4220.4m</td>
<td>$4220.5m</td>
<td>$4220.6m</td>
<td>$4220.1m</td>
<td>$4221.4m</td>
<td>$4222.8m</td>
<td>$4224.2m</td>
<td>$4224.6m</td>
<td>$4225.1m</td>
<td>$4226.5m</td>
<td>$4228.1m</td>
<td>$4228.5m</td>
<td>$4229m</td>
<td>$4229.4m</td>
<td>$4229.9m</td>
<td>$4230.4m</td>
<td>$4230.5m</td>
<td>$4225m</td>
<td>$4232.6m</td>
<td>$4233.5m</td>
<td>$4234.5m</td>
<td>$4234.2m</td>
<td>$4236.3m</td>
<td>$4236.8m</td>
<td>$4237.3m</td>
<td>$4208.8m</td>
<td>$4211.9m</td>
<td>$4245m</td>
<td>$4246.4m</td>
<td>$4246.6m</td>
<td>$4247m</td>
<td>$4247.1m</td>
<td>$4217.4m</td>
<td>$4221m</td>
<td>$4252.6m</td>
<td>$4252.6m</td>
<td>$4252.3m</td>
<td>$4251.1m</td>
<td>$4252.8m</td>
<td>$4253m</td>
<td>$4253.2m</td>
<td>$4253.4m</td>
<td>$4253.5m</td>
<td>$4253.7m</td>
<td>$4253.9m</td>
<td>$4254m</td>
<td>$4254.2m</td>
<td>$4254.7m</td>
<td>$4254.7m</td>
</tr>
</tbody>
</table>

> > Proposal: Table Usability Parser Algorithm
> > https://github.com/duboisp/Table-Usability-Concept/tree/master/Algorithm
>
> Can you elaborate on how this differs from the algorithm in the HTML spec,
> and in what ways it is better? (e.g. examples that your algorithm handles
> but that the HTML spec doesn't)
>
> I'm all in favour of improving the spec, I just don't have a good frame of
> reference here by which to evaluate the proposal.

Yes, I will do a more elaborated comparaison between the current and
the proposed algorithm. I will send an email later when that is
completed.

<aside>
The proposed algorithm define a relationship model on how to get the
benefit of using the row grouping and the column grouping markup. When
the row grouping markup is not used, that algorithm are able to detect
which rows belong to the table head (thead) and are able to detect
simple row group and simple column group. Also the algorithm suggest a
real use case of using the 'colgroup' and 'col' element in a table.
That is made possible by using the proposed API in regards of
accessing the data by using the column instead of the row.

I found a lot of example where the 'colgroup' and 'col' element is use
for utilitarian purposes. But I was unable to find a example where the
'colgroup'  and the 'col' element is used to provide an
additional/supplemental information to the cell header (th) defined in
the table head (thead) section.

>From a row group perspective the specification define 3 kind of row
group (thead, tbody and tfoot). The algorithm define how to detect
those 3 kind of group in a column perspective.

The proposed algorithm define the relationships between groups (Data level).
</aside>

>
>
> On Fri, 19 Oct 2012, Pierre Dubois wrote:
> >
> > Sometime the subsequent row grouping under the same data level and the
> > subsequent column grouping under the same data level don't necessary
> > mean a summary group but still a data group.
>
> A summary group is just a group with a heading saying it's a summary
> group, no? I don't really understand what is special about a summary
> group. How should software treat it differently?

Sometime a summary group is not clearly identified by using a cell
heading (th) but it is often identified by using the styling.
>From an accessibility (WCAG 2.0) point of view, by using styling to
define those summary group make it fail the Success Criterion 1.3.3
(Level A) "Sensory Characteristics"
http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html

Here a simple common example where a summary group do not have a
heading saying it's a summary group.

<table hassum>
<caption>Invoice</caption>
<thead>
<tr>
<th>Item</th>
<th>Price</th>
</tr>
</thead>
<tbody>
<tr><th>Product 1</th><td>25.00</td></tr>
<tr><th>Product 2</th><td>60.00</td></tr>
<tr><th>Product 3</th><td>15.00</td></tr>
</tbody>
<tbody class="summary">
<tr><th>Sub Total</th><td>100.00</td></tr>
<tr><th>Federal Taxes</th><td>5.00</td></tr>
<tr><th>Provincial Taxes</th><td>10.00</td></tr>
</tbody>
<tfoot>
<tr><th>Total</th><td>115.00</td></tr>
</tfoot>
</table>

The summary group concept can be useful to spec a responsive table
concept. For example, an user agent could hide some data group to
reduce the table space taken in view port. So in the previous
"Invoice" table, the user agent could hide the first row group and
provide a mechanism to display it, if requested by the user.

> > To fix that the solution would be to have a new attribute set on the
> > table element to know if the table contains summaries group.
>
> I would be very surprised if such an attribute was used correctly a useful
> fraction of the time.

If the responsive table is spec by having summary group, then I am
sure it would used correctly or at least to get the espected
behaviour.

> On Tue, 6 Nov 2012, Pierre Dubois wrote:
> >
> > Use case: Draw a graphic based on a data table
> > * Like a pie chart, based on a sub-set of data contained in a data table.
>
> This is an interesting use case. Do any sites actually try to do this
> today?
>

Any website that use the Web Experience Toolkit chart plugin
(https://github.com/wet-boew/wet-boew/wiki/Charts-and-graphs) and any
website that use the Filament Group chart
(http://www.filamentgroup.com/examples/charting_v2/)

> I tried writing an example to do this, and it's not clear to me that the
> API is particularly hard to use. Somewhat verbose, granted, but it only
> took a few lines of code, most of which is spent in canvas logic and in
> the CSS styles to make the table presentable:
>
>   http://damowmow.com/playground/demos/tables/002.html
>
> That's an admittedly simple table; what kinds of tables are people
> generating pie charts out of? Are they more complex? Do you have any
> examples we could study?

> > An issue can be when the header cell cover and/or represent more than
> > one group (eg. multiple tbody from a column perspective and multiple
> > colgroup from a row perspective)
>
> Certainly that does make things more complex and the current API doesn't
> handle spanning cells well if you want to select a cell by grid position.

The goal with the following table is to generate a bar chart for the
data group and a line chart for the summary group. See the an example
of the espected result here:
https://github.com/duboisp/Table-Usability-Concept/blob/master/Table%20Example/graph_samples/cluster-column-line-markers-eng.jpg#files

(The cells relationships of the following table are not supported by
the current algorithm. The proposed algorithm support that kind of
complex table)
<table hassum>
<caption>Current account balances</caption>

<colgroup>
<col />
</colgroup>
<colgroup>
<col />
<col />
</colgroup>
<colgroup>
<col />
</colgroup>

<thead>
<tr><th> <th>Goods<th>Other current account<th>Total

<tbody>
<tr><th colspan="4">2006
<tr><th>III <td>11 406 <td>-7010 <td>4396
<tr><th>IV <td>12 139 <td>-7437 <td>4702
<tr><th colspan="4">2007
<tr><th>I <td>13 563 <td>-10231 <td>3332
<tr><th>II <td>15 134 <td>-9516 <td>5618
<tr><th>III <td>9 510 <td>-7910 <td>1600
<tr><th>IV <td>9 230 <td>-7009 <td>2221
<tr><th colspan="4">2008
<tr><th>I <td>12 551 <td>-6387 <td>6164
<tr><th>II <td>16 095 <td>-10573 <td>5522
<tr><th>III <td>14 383 <td>-11603 <td>2780
<tr><th>IV <td>3 215 <td>-10763 <td>-7548
<tr><th colspan="4">2009
<tr><th>I <td>403 <td>-7498 <td>-7095
<tr><th>II <td>-2 019 <td>-10436 <td>-12455
<tr><th>III <td>-3 388 <td>-10382 <td>-13770
<tr><th>IV <td>436 <td>-10640 <td>-10204
<tr><th colspan="4">2010
<tr><th>I <td>1 103 <td>-10289 <td>-9186
<tr><th>II <td>-2 236 <td>-10747 <td>-12983
<tr><th>III <td>-6 504 <td>-11032 <td>-17536
</tbody>
</table>

> Can you be more elaborate? Examples of pages trying to do this, examples
> of tables that need to be charted client-side, etc, would go a long way
> towards helping flesh out the use case.

Generating client-side chart help about the Web Content Accessibility.
Generating client-side chart save money. It is faster to change a data
cell value of a HTML table instead of updating a non HTML data table
(like MS Excel), generating a new chart image, add the corporate look,
update the text alternatives version, upload the image, update the
webpage, ...

Pierre Dubois

:-)