Re: [XHTML 2] 24.2 Position of param elements (PR#7753)

Shane McCarron wrote:
> Anne van Kesteren wrote:
>> At one point the HTML WG looks at current implementations and at 
>> other  points they simply miss the fact that implementations typically 
>> do not  have validating parsers.
> 
> I disagree - the working group knows that most browsers do not 
> validate.  Nor is there a requirement that they do.  But let's not have 
> that argument - its circular and painful.
> ...
>    Conforming user agents must refuse to process any document that
>    claims to be an XHTML 2.0 document but does not conform to the
>    requirements for a Conforming XHTML 2.0 Document.  When such a
>    document is encountered, the user agent must by default present an
>    error message and not process or render any of the content from the
>    document.
> 
> I don't think that is the type of thing that anyone really wants, mind 
> you.  But you really should present a concrete proposal.

I don't think anyone wants such extreme draconian error handling added 
to XHTML 2, beyond that imposed by XML, but there is a requirement to 
define what browsers must do, whatever that may be, upon encountering 
erroneous documents.

> You (and others) assert that it is incumbent upon a standard to define 
> behavior in the presence of incorrect usage.

Yes, that's correct because the fact is that authors will write invalid 
XHTML, they will publish it on the web and browsers will be forced to 
handle it somehow.  We only have to look back at how differently 
browsers handle invalid HTML and how much reverse engineering of error 
conditions has been done to know how important it is for XHTML2 to 
define it properly from the start.

>  As evidence for this, you seem to claim that without this it is impossible 
> to have interoperability.  That seems confused to me.  Interoperability is about 
> how portable applications/documents function on conforming 
> implementations.

Interoperability is also about ensuring that different implementations 
produce the same result given the same input, and considering that the 
input *will* be invalid/non-conformant in many cases (that is, at least, 
here in the real world), implementations need to know what to do and 
need to implement such behaviour interoperably across the board.

> The working group has attempted to define the 
> requirements a portable application/document must adhere to (XHTML 2 
> Strictly Conforming Document) and the requirements on a conforming 
> implementation (XHTML 2 User Agent Conformance).

You've expressed many requirements about what UAs must do when given 
conforming documents, but you either need to do the same for 
non-conforming document or prove beyond any reasonable doubt that 
browsers will never have to deal with such things.  Given that the 
latter is impossible to do, I suggest you do the former.

> If it is not XHTML 2, we don't know what it is and 
> we cannot define processing rules for it...  Other than something 
> draconian like the clauses above.

I'm sorry, but neither I, nor anyone else, is going to believe that 
draconian error handling for a document that simply has a misplaced 
param element, for example, is the only option.

As for a concrete proposal for this param element issue, there are two 
choices that I can think of:

1. Any param element that is a child of an object element that occurs 
after any sibling element other than caption, standby or other param 
elements is to be ignored.  Param elements that are not children of an 
object element are to be ignored.  If a param element is not empty, its 
content is to be ignored (although it will still be present in the DOM) 
and must not be rendered or executed (e.g. in the case of nested 
handler/script elements) by default.

2. All param elements which are direct children of an object element 
must be used, regardless of their position within the object element. 
Param elements that are not children of an object element are to be 
ignored.  If a param element is not empty, its content is to be ignored 
(although it will still be present in the DOM) and must not be rendered 
or executed (e.g. in the case of nested handler/script elements) by default.

The wording could probably be improved, but it's a start.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Wednesday, 25 January 2006 03:02:47 UTC