W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Bug 8404 -- taking it to the lists

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 1 Dec 2009 08:43:02 -0600
Message-ID: <643cc0270912010643x4d6bcc26gaf58c211a15ac98c@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: HTMLWG WG <public-html@w3.org>
On Tue, Dec 1, 2009 at 8:19 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Dec 1, 2009 at 8:03 AM, Shelley Powers <shelley.just@gmail.com> wrote:
>> Bug 8404 reads as follows:
>>
>> Currently the HTML5 specification has an overly broad definition about what can
>> be allowed in a figure element:
>>
>> "The element can thus be used to annotate illustrations, diagrams, photos, code
>> listings, etc, that are referred to from the main content of the document, but
>> that could, without affecting the flow of the document, be moved away from that
>> primary content, e.g. to the side of the page, to dedicated pages, or to an
>> appendix."
>>
>> This is counter to understandings about figure in other businesses and
>> environments, where figures are a graphic of some form. In addition, this
>> provides a confusing parallel in functionality between figure and aside, enough
>> so that people are going to have a difficult time knowing which is which, and
>> when to use one over the other. In fact, with this parallelism, we don't need
>> both.
>
> As I stated on the bug, this last paragraph is false.  I provided
> three examples directly from Google Books results, obtained after a
> bare minimum of searching, of both code and tables.  A good 15 minutes
> of effort would have provided tens of more examples.  I also made
> reference to the first coding book I pulled off of my shelf, which is
> full of dozens of code figures (not illustrative, actual code) and
> literally hundreds of table figures (again, where the contents are not
> just illustrative, but are actually necessary for understanding the
> text that refers to it).  In all of these cases the figures match
> exactly with what the spec says - they are part of the document, but
> could be moved away, perhaps into an appendix, without affecting the
> meaning or flow of the document.
>
> It takes only a modicum of effort to thoroughly disprove your
> assertion.  It is simply incorrect, and cannot be used as a valid
> reasoning for anything in this bug.  Please stop attempting to use it
> as justification.
>
> ~TJ
>


If you want to debate Tab, I find that telling a person to stop using
an argument as justification isn't effective. I can use an argument,
and you can provide a counter, and leave it to the reader to form
their own conclusion as to which is the superior argument.

I brought this to the email group specification because I was asked to.

As demonstrated in recent emails[1] to this group, there is an
assumption that whatever is in figure is illustrative, and
illustrative in HTML has typically been graphical, though it doesn't
_have_ to be. But people do make assumptions about figure in HTML when
they see it, even with the examples given in HTML5. That there will be
confusion about what figure is has already been proven by previous
discussions.

But there is a difference between something given for illustration
purposes and something given for other purposes. In a web page,
though, there is no way to differentiate between the two, other than
to convert whatever is used for illustration into a format that is by
its nature, purely illustrative.

We can put illustrative tables in figure, but there is no way to mark
the table as illustrative, and to suggest that the table not be parsed
into the DOM, or parsed by search engines. We don't have this ability
now, when we use tables for illustration contained within a div
element, true, but the purpose behind figure is, I believe, because
we're trying to improve the semantics of the markup. If this is true,
then the semantics must be extended across all levels of the web page,
and this includes the DOM.

If we're just going to slap figure in, and repurpose other elements
(dt/dd) in order to work around technical issues related to the
caption, then all we've done is add elements--we've not improved HTML,
semantically or otherwise.

Shelley

[1] http://lists.w3.org/Archives/Public/public-html/2009Nov/0667.html
Received on Tuesday, 1 December 2009 14:43:36 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC