W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: extracting semantics Re: Namespace

From: Ben Boyle <benjamins.boyle@gmail.com>
Date: Wed, 18 Jul 2007 20:09:28 +1000
Message-ID: <5f37426b0707180309i3c48b8afsd698dabf18a5e358@mail.gmail.com>
To: "James Graham" <jg307@cam.ac.uk>
Cc: "Karl Dubost" <karl@w3.org>, "Robert Burns" <rob@robburns.com>, "HTML WG" <public-html@w3.org>
I dunno about this. If people (using their tools) go looking for the
"small print" (i.e. legals, terms and conditions etc.) they should be
grabbing the contents of <small> in HTML5 documents. But not in
previous versions of HTML, where that is not what <small> means, and
they won't get meaningful information.

Maybe you're gonna tell me that I should be using the semantic web
here, HTML is all about presenting documents after all…

I think the burden of proof should be flipped here. If HTML5 changes
the semantics of an element, any element, that had better be

Are we "paving the cowpaths"? Prove it's a "widespread practice" among
authors to use <small> for the fine print, and *only* for fine print.

Is this "evolution not revolution"? Prove I won't have to reassess use
of <small> on deployed content to ensure it matches the new semantics
- because "old content can take advantage of new features without
having to make unrelated changes", right?

Does this solve real problem? Exactly what problem?

Is it related to Priority of Constituencies? Is this something users
want? Authors? Implementors? Anyone?

Were other solutions considered?

Much as this may sound inflammatory (I'm embracing the culture of the
list today) but seriously, a semantic change is far from trivial. I
want to see well reasoned thought behind such a change.

What's wrong with Karl's scenario? A semantics extractor will indeed
be confounded by small if it cannot tell the version. Why are we
introducing this problem? (read from start of email again).

On 7/18/07, James Graham <jg307@cam.ac.uk> wrote:
> Karl Dubost wrote:
> >
> >
> > Le 18 juil. 2007 à 02:57, Robert Burns a écrit :
> >> Earlier I gave the example of changing the semantics  of <small>  from
> >> meaning "presentationally small text" to meaning "legal descriptions
> >> and other disadvantages" With that, "the likelihood that it will be
> >> interpreted and presented as intended by an implementation" falls
> >> dramatically.
> >
> > Indeed a semantics extractor looking at the version of HTML
> >
> >     <p>Life is <small>tough</small>.</p>
> >
> >
> > * HTML 4.01
> >   SMALL: Renders text in a "small" font.
> > * HTML 5.01
> >   The small element represents small print (part of a document often
> > describing legal restrictions, such as copyrights or other
> > disadvantages), or other side comments.
> >
> >
> > Then I'm an implementer of a semantics extractor. What are my
> > implementation strategies?
> For those of us who believe that practical concerns outweigh theoretical
> possibilities, it would be much more persuasive if those who are
> claiming that slight changes in the definition of e.g. <small> are
> problematic could produce examples of existing tools that are affected
> by this kind of change and examples from the public web of the kind of
> documents for which the processing, by those tools, would be different
> in significant ways between HTML4 and HTML5.
> --
> "Mixed up signals
> Bullet train
> People snuffed out in the brutal rain"
> --Conner Oberst
Received on Wednesday, 18 July 2007 10:09:33 UTC

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