[whatwg] Content Model Restrictions on table>tr in HTML

[Ian Hickson]

On Wed, 6 Dec 2006, Bjoern Hoehrmann wrote:
> 
> If something can be deduced it "is there" for all intents and purposes. 
> You can look at this from a very practical perspective: someone wants to 
> build a "HTML5" "conformance checker". He has already implemented an al- 
> gorithm that transforms a document into a tree and parse errors and an 
> algorithm that determines whether a document conforms to the draft. Now, 
> in order to complete the tool, he has to implement a third algorithm 
> that determines whether a document conforms to section 9.1 of the draft, 
> possibly by deducing which of the requirements in that section are al- 
> ready checked for by the algorithms he already has, which is an extremly 
> wasteful excercise.

No, he doesn't. The spec explicitly says of the 9.1 section that "it does 
not apply to conformance checkers; conformance checkers must use the 
requirements given in the next section ("parsing HTML documents")". (Just 
added; the spec said something equivalent before but it wasn't as clear.)


> You can also put it like this: a conformance checker implementer needs 
> to read only those parts of the draft that define document conformance 
> criteria.

No, conformance checkers must do what is required of conformance checkers, 
as defined by the various sections that give conformance criteria for 
conformance checkers.


> According to you, section 9.2 does not define any

Section 9.2 explicitly covers conformance checkers. It's section 9.1 that 
doesn't. Section 9.1 only covers conformance criteria for documents and 
markup generators.


> A missing </option> implies non-conformance but no parse error per 9.1 
> and 9.2 respectively.

<option> and other form controls aren't yet really part of the 
specification, and are missing all over the place. I added these to the 
syntax section for you, but in general anything to do with form controls 
is incomplete at best, and missing at worst.


> None of these problems would exist if you had simply defined something 
> like
> 
>   A document conforms to this specification if and only if it can be
>   parsed into a tree structure that conforms to this specification
>   without error in accord with the applicable specifications.

That would be precise, but useless to all. This would require a very 
painful exercise of trying to reverse-engineer the parser section to 
determine what is allowed and what is not.


> Or ensured in some other way that no clause that implies the definition 
> of a constraint can be removed without changing what conforms to the 
> specification.

The "writing" part of the syntax section doesn't affect what conformance 
checkers report, which is what is important. I'll fix inconsistencies as 
we find them, but I doubt there are many.


> >What is your point? I'm confused. The syntax section is clear that you 
> >can't create such a document. This is, in fact, one very important 
> >example of why the syntax section is important -- if an authoring tool 
> >tried to generate a document that had a <pre> inside a <p>, it would be 
> >non-conforming, but only because of the syntax section (9.1.2.5:2), not 
> >because of the parser section -- the parser section wouldn't be able to 
> >determine there was an error.
> 
> There are no authoring tool requirements in that section and I do not 
> see how the tool would be non-conforming.

1.3: "Authoring tools and markup generators must generate conforming 
documents."

9.1: "Documents must consist of the following parts, in the given order:"

I believe you are incorrect.

I have further added an explicit statement in the spec that that section 
applies to authoring tools, FWIW.



> The draft has "A p element must not contain blockquote, dl, menu, ol, 
> pre, table, or ul elements". It is not possible to tell whether or not 
> the requirement is being followed by a document that does not follow the 
> requirement.

Correct, but an implementor can use this requirement to establish whether 
or not they are conforming to the spec, because if they _try_ to place a 
<dl> element inside a <p>, the syntax section tells them they can't. This 
is much more explicit than having to reverse-engineer the parsing section. 
The parsing section is basically unreadable except to someone implementing 
a parser (which is that section's target audience, of course).


>   A conformance requirement must be testable. That is, you must be
>   able to tell whether a product follows it or not. If you can't tell
>   if a product follows it, then it isn't a conformance requirement,
>   and shouldn't pretend to be one.
> 
> Without the parsing algorithm it is impossible to determine whether a p 
> element contains a pre element without assuming that p elements never 
> contain pre elements, and if you assume that, there is nothing left to 
> determine.

You can test it by looking at the DOM you are attempting to serialise. It 
isn't something you can determine from the document itself, but you can 
determine it through white box testing.


> The conformance requirement really only applies to "conforming 
> documents" but that is quite unclear from the draft.
> 
>   A conformance requirement must also be clear (either by context
>   or explicitly) about exactly what kind of product it applies to.
> 
> That certain constructs cannot be represented using the HTML syntax is 
> important information that should be highlighted by the draft, but 
> 9.1.2.5 is very far from doing an adequate job to that effect. And I 
> can't see what else it might be there for.

I'm not really sure what you would like me to do about this. It seems 
reasonably clear to me.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'