W3C home > Mailing lists > Public > www-html@w3.org > January 2000

XHTML Family User Agent Conformance

From: Arjun Ray <aray@q2.net>
Date: Wed, 26 Jan 2000 02:02:30 -0500 (EST)
To: www-html@w3.org
Message-ID: <Pine.LNX.4.10.10001252236430.15214-100000@mail.q2.net>


On Mon, 24 Jan 2000, W. Eliot Kimber wrote:

> XHTML Modularization Spec
> 
> 3.3 XHTML Family User Agent Conformance
> 
> Constraint 4 needs to clarify whether the term "render" as used here
> means "enable processing by the controlling style sheet" or "make
> visible to the reader". A controlling style sheet may choose to hide an
> unrecognized element that the XHTML processor is required to pass
> through to the rendition component of the browser.  This constraint
> could be read as "must always make visible".

I've already argued (with illustrative examples) that the conformance
requirement is absurd as stated and inappropriate even in intent.

  http://lists.w3.org/Archives/Public/www-html/2000Jan/0176.html

Grandfathering the historical behavior of browsers is one thing,
mandating such (broken) behavior is another.  If the specs were aimed
at description of current practice, they could have taken a page out
of RFC 1866 (4.2.1) and simply reported the observation.  But the
specs seem aimed at prescription, in which case #4 is, IMHO, bogotic.

First, it forgets that this is XML, where there are no missing tags.
That, by the way, was the escape clause invoked by the Netscape people
to "justify" their stick-in-a-comment kludge for LiveScript.  The
position of an unknown element in a putative XHTML element tree is
unambiguous.  The only operative question, therefore, is whether it
should be transparent - its content becomes part of the parent's
content - or opaque.

Second, mandating a conforming agent "must do something with the
content" - as opposed to ignoring it - can make a hash of context
dependent processing.  What if there's no stylesheet rule for
unexpected stuff?  Or does every stylesheet have to anticipate every
bogotic combination?  This is *why* the historical behavior is, has
been and always will be sop hopelessly inadequate. 

Finally, if conforming agents *must* do something - in effect,
*recognize* the element as inherently processable *within* the XHTML
semantic domain - then this should be *allowed* in the DTD.  Define a
catch-all element, say CatchAll, to which all unrecognized elements
are to be mapped, and add it to all content models.  

   <!ELEMENT ul  (CatchAll|li)+ >

Define the processing behavior as "pass content to parent".  You can
even do better and define a global *attribute*, say htmlignore, that
any CatchAll element can exhibit.  If its value means 'yes', this is a
way for documents to override the default mapping and make the element
opaque and suppressible by agents that don't grok.

But disallowing such stuff according to the DTD and then *requiring*
in-paradigm treatment for conformance makes no sense.


Arjun
Received on Wednesday, 26 January 2000 01:53:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:41 GMT