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

Ian Hickson wrote:
> On Sat, 6 Jun 2009, Laura Carlson wrote:
>> Jonas wrote:
>>
>>>> If a feature that we've developed is being improperly used
>>>> after years of adoption, we have to change something.
>>> Long Term Solution Possibilities
>>> http://esw.w3.org/topic/HTML/SummaryForTABLE#head-847d2ebafa6828471a3d2777ad3676944007c35d
>> What do you think of the  Long Term Solution Possibilities listed in
>> the Wiki, in particular a new <summary> element or equivalent?
> 
> I will look at the above closely when I get to this issue in my slog 
> through feedback e-mails, but in the meantime I would really appreciate 
> coherent e-mails for each proposal. When I glanced at the wiki just now I 
> actually couldn't work out what many of the proposals were -- just 
> proposing a new element name, for example, doesn't really mean anything -- 
> what does the element do? What are the proposed conformance criteria for 
> authors? For browser vendors? For accessibility tools? How does it solve 
> the problems that have been raised? What new problems can it introduce? 


I have started making testcases for some of the proposed ways of adding 
captions/summaries/descriptions to tables. These can be seen at [1]. The 
original data was taken from [2] which in turn is based on the 
real-world table at [3]. I took the caption from the current version of 
that table, modified it slightly by adding extra description of a type 
that would be of limited use to most users but might be useful to some 
e.g. AT users. I failed to notice that the format of the table had 
changed somewhat so all the stuff about asterisks indicating missing 
data is wrong in the version of the table I have presented. I guess I 
will fix that eventually.

I didn't consider <tdesc> or whatever because that would have meant 
inventing even more text relative to the <summary> example ("<summary> 
would provide a concise description of the table's structure. <tdesc> or 
<tdescription> or <desc> would provide a long description"). I didn't 
consider <details> of a child of <table> because this is equivalent to 
<details> as a child of <caption> but with a considerably worse legacy 
compatibility story (though maybe I should make a testcase to 
demonstrate this).

Bug reports and suggestions for additional cases are most welcome. I am 
following "release early release often" here.

Some mostly-unrelated-to-summaries observations:

Forcing <caption> to be the first child of <table> seems odd and 
unintuitive. I initially forgot this conformance requirement and I guess 
many other authors would as well (data would be nice...). I understand 
that there are theoretical reasons for it related to progressive 
rendering but the non-obviousness seems like a bigger problem than the 
benefits of the solution.

<legend> should allow flow content children. It is quite reasonable to 
want multiple paragraphs in a figure caption. In general 
over-restricting content models where no real technical reason for the 
restriction exists seems bad (people will route around the damage by 
ignoring validation and hence miss other, more important, problems).

<caption> should probably also allow flow content children, particularly 
if it is to be used for longer table descriptions which could easily be 
longer than a single paragraph.

One related to summaries observation:

Adding new elements to the content model of <table> has a seriously bad 
legacy compatibility story (because of foster parenting).

[1] http://james.html5.org/table_descriptions/
[2] http://projectcerbera.com/web/study/2007/tables/tides/minimal
[3] http://broads-authority.gov.uk/boating/navigating/tide-tables.html

Received on Monday, 8 June 2009 10:02:40 UTC