Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03

On Thu, Sep 3, 2009 at 3:31 AM, Ian Hickson<> wrote:
> On Thu, 3 Sep 2009, Mark Baker wrote:
>> How it's handled/processed depends upon the type of user agent.
>> Browsers might handle things one way, screen readers another, and
>> spiders yet another. Sure, there might be *some* common behaviour
>> between *some* classes of agent, but there's only *two* things which are
>> common to *all* agents, past, present, and future; the shared
>> understanding of the meaning of the document, and the recognition of the
>> text/html media type.
> No, this isn't true. You can define processing requirements -- indeed,
> HTML5 does define processing requirements -- without being so wishy washy
> as to rely on a "shared understanding of the meaning".


> For example, there are very specific rules for how to process sections and
> headings, and how they relate to outlines. These requirements apply to a
> huge number of conformance classes -- editors, screen readers, search
> engines, validators, outliners, etc.

I just had a look through the "sections" section, and other than the
intermixing of IDL/event stuff, it's largely defined in "wishy-washy"

"The section element represents a generic document or application
section. A section, in this context, is a thematic grouping of
content, typically with a heading, possibly with a footer."

"The nav element represents a section of a page that links to other
pages or to parts within the page: a section with navigation links.
Not all groups of links on a page need to be in a nav element  only
sections that consist of major navigation blocks are appropriate for
the nav element. In particular, it is common for footers to have a
list of links to various key parts of a site, but the footer element
is more appropriate in such cases, and no nav element is necessary for
those links."

"The article element represents a section of a page that consists of a
composition that forms an independent part of a document, page,
application, or site. This could be a forum post, a magazine or
newspaper article, a Web log entry, a user-submitted comment, an
interactive widget, or any other independent item of content."

So that's all great.  However, there's an issue with with,
"Creating an outline" where you specify an algorithm for outline
creation.  It's not *necessarily* a problem that algorithms are used
in this way - sometimes that's the simplest approach that will yield
the fewest interpretation problems, though it usually comes at the
cost of legibility to humans as well as unnecessarily restricting
implementations.  So, for example, I think it's reasonable to specify
the parser as an algorithm because of the enormous complexity (though
others may disagree with me).  But in the case of outlines, it seems
overkill to me because it isn't particularly complex and could be
easily, and perhaps even more concisely, specified declaratively.

FWIW, this example seems to be another instance of the issue Larry raised here;


Received on Saturday, 5 September 2009 12:35:59 UTC