- From: Leif Halvard Silli <lhs@malform.no>
- Date: Wed, 10 Jun 2009 17:29:16 +0200
- To: James Graham <jgraham@opera.com>, HTMLWG <public-html@w3.org>
James Graham On 09-06-10 17.12: > Leif Halvard Silli wrote: >>> As a child of <table> <summary> (or any other element) has too bad >>> legacy compatibility properties to work. > I discussed the issues here: >> >> http://www.w3.org/mid/4A2DC7A6.206@malform.no > > Yes, I saw that; it was rather helpful. I am not sure it is always > accurate though. For example you assert that "Until <summary> as child > of <table> is fully supported cross browser, authors must place the > summary as child of <figure>. This is a fully workable solution > though.". The statement that this solution is fully workable ignores the > fact that AT must be updated to understand the <figure> element implies > a relationship between the <figcaption> (or <legend>) and the table. > Otherwise the user experience will be the same as placing the summary in > an unassociated paragraph below the table. I am under the impression > that this is not considered acceptable for users of current UAs. Yes, AT must be updated, that's for sure regardless. That is true, though, even for <figure> in general. (Consider what the draft says about omitting <caption> when <table> is only child (except <legend>/<figcaption>) of <figure> - perhaps the draft should not say so?) Point is that figure allows gradual introduction of <summary>. (But it doesn't allow that we cut off @summary.) Also, an element doesn't need the same degree of "User Agent Learning" as an attribute needs - if it appears at right place in the DOM, UAs will read its content. >> Semantics is what must be agreed upon first, though. > [...] I believe the parsing of > unexpected children of <table> in existing UAs is a significant enough > problem that we should reject any solution that relies on it [...] By agreeing upon semantics I was referring to what Josh said earlier today [1] (and I also have said similar things [2]). It _might_ be that @summary is good enough, if we define/limit its purpose enough. At least, it could make staying with an attribute a more acceptable option. [1] http://www.w3.org/mid/4A2F7693.1080001@cfit.ie [2] http://www.w3.org/mid/4A2E6E14.80608@malform.no -- leif halvard silli
Received on Wednesday, 10 June 2009 15:29:54 UTC