Re: extracting semantics Re: Namespace

Good questions all, and I don't know. I wish our design principles
offered guidance here.

Can I propose a design principle: All elements should have a clearly
defined structural (semantic) meaning

I propose this because:
- it is a principle that appears to have been applied in HTML5 (but
it's not documented)
- to foster debate at the design principle level (for all elements,
not case by case)
- because we may not need it; a few elements that offer "style" and no
"structure" might be acceptable (even if the practice is discouraged
in some circles)

I think Henri summed it up well:

… there are another group of people who, as a matter of principle,
objects to including anything considered "presentational" in the spec.
…  has backfired politically as a large part of the group of people
who object to putting "presentational" stuff in the spec seems to be
very uncomfortable with *any* tweaking of semantics.

Clearly we all need to agree on principle here, or we'll be arguing for days.



On 7/18/07, James Graham <jg307@cam.ac.uk> wrote:
> Ben Boyle wrote:
>
> > 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.
>
> I agree there is a burden of proof in that direction as well and I would very
> much like to see research into the way that elements such as <small> are
> currently used. However let us pretend, for the sake of argument that we examine
> a large number of documents and find <small> is being used for two distinct
> purposes:
>
>   - General "uninteresting" (i.e. without obvious semantics) presentational effects
>
>   - Legal smallprint
>
> Is it, in that case, acceptable to tweak the semantics of <small> so that the
> use for legal small print is conforming whilst the use for presentation is
> non-conforming (given the typical stance of the group on presentational markup
> it is not unreasonable to assume that the only other option would be to make all
> use of <small> non-conforming)? There are claims that such a change is not
> acceptable because there might be tools that do something with <small> elements
> that would break in the face of this change. I don't think it's unreasonable to
> ask to see evidence that these supposed tools actually exist and suffer from the
> described problems; this is an example of "Solve Real Problems".
>
> > Much as this may sound inflammatory (I'm embracing the culture of the
> > list today) but seriously, a semantic change is far from trivial.
>
> It depends if anyone is making use of those semantics. I don't quite see how
> going from purely-presentational to some-semantics is going to be an issue for
> an existing tool - if it ignores <small> now it can do so in the future with no
> loss in functionality. I would also suggest that any tool which tries to extract
> semantics from the public web has to be tolerant of markup abuse so the fact
> that they will have to process documents in which <small> is used in both
> conforming and non-conforming ways will be no more of an issue than it is for,
> say, <blockquote>.
>
> Hopefully by examining evidence to back up claims that things are or aren't
> problems, the incidence of people talking past each other can be reduced. As a
> optimistic corollary, this might cut down unnecessary traffic on the list making
> it easier to follow and allowing us to make more rapid progress to completing a
> spec :)
>
> --
> "Eternity's a terrible thought. I mean, where's it all going to end?"
>   -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
>

Received on Wednesday, 18 July 2007 12:33:34 UTC