[Bug 8449] Remove extraneous material from Table section

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8449





--- Comment #4 from Shelley Powers <shelleyp@burningbird.net>  2009-12-07 16:17:08 ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > >
> > > > In addition, the use of HTML tables in figure elements is being discussed in
> > > > another bug. It is against established practice and procedure to use data
> > > > tables in figures. And since the only type of table supported in HTML5 is a
> > > > data table, it's erroneous to use the table in a figure element.
> > > 
> > > It seems like the evidence of that bug was that it's quite common to have
> > > tables in something label as a Figure. It also seemed to be quite common to
> > > give a table figure-like presentation (matching the semantics of the HTML
> > > <figure> element, but separately numbed as Tables instead of Figures. And
> > > finally, other markup languages such as DocBook specifically seem to allow
> > > tables in their figure element. Your counterpoint that tables in figures should
> > > first be converted into an image seems poorly founded, and as far as I can
> > > tell, no one else agrees that it is ever good practice to convert a table to an
> > > image in HTML.
> > > 
> > > It seems misleading to reference the original premise of the bug as if it's
> > > established fact, without citing any of that follow-up discussion.
> > > 
> > 
> > No, it's not common. 
> 
> It seems like many examples were cited of tabels labeled as Figures, both
> online and in real-world books and papers. Including books written by you. I
> will grant it is a small fraction of figures, but it seems wrong to me to
> declare it categorically incorrect. Furthermore, the case has been made that a
> floating numbered table has the semantics of a <figure> in general, even though
> often (but not always) they are labeled distinctively and numbered separately
> from Figures proper.
> 

This is incidental to this bug, and I did add a link to the other discussion to
this list, if someone wanted to pursue it separately. 

> I realize that you may ultimately disagree with these arguments, and where the
> preponderence of the evidence lies. It just seemed misleading to me to ignore
> the counter-arguments entirely and state your opinion as if it were undisputed
> fact.
> 
> 
> > And is typically against typographical style guides in
> > print publications. Regardless, this section is Primer material, not
> > specification material.
> 
> I think it's totally appropriate for the HTML specification to include usage
> examples and advice, especially in cases where correct usage is tricky or where
> a particular use case is not directly served by a single specific markup
> feature.
> 
> I agree with you that a non-normative authoring guide of some sort is a good
> place for advice, but I disagree that it's categorically wrong to have it in
> the main spec as well.
> 
> By the way, earlier, you also said:
> 
> > This bug does not impact on the current discussions about the table summary
> > attribute, within the HTML Accessibility task force.
> 
> But it seems this bug does impact that discussion, because the Change Proposal
> for the table-summary issue adds to and edits the section in question. Most of
> that Change Proposal would be invalidated if the section in question were to be
> removed.
> 

Actually, no there is very little impact on the summary change.

The summary change removed summary from being obsolete but conforming, added a
new attribute, a new explanation for what summary is, and only incidentally
suggested a modification to the long example given.

The only impact would be if the section describing how to describe table
structure is moved to a primer, the option for using summary would also be
moved to a Primer. But the meat of the change, the status of summary, the
addition or orientation, the API, the descriptive text, and conformance
guidelines for user agents all belong in the spec.

It's only item 1.3 on the change proposal, "minor edits in the descriptions of
the alternative mechanisms to summary" that would be impacted, and only that
the edits would occur in material in a Primer, rather than in the spec.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 7 December 2009 16:17:10 UTC