Re: Summary of Thursday's IRC conversation about @summary

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