Re: XHTML 2.0 Error Handling (was: Re: [html] Elements within "title"?)

Barry wrote:
> Lachlan Hunt wrote:
>> Barry wrote:
>>> The specs are clear enough that both forms of the title equivalent, 
>>> so including both or two of either should be considered an error by 
>>> the rendering engine
>>
>> Where exactly does the spec specify that it is an error to include 
>> both <title> and <meta property="title">?  Are you just making an 
>> assumption about it's intended meaning?
> 
> If identical titles are given then it's not an issue when rendering the 
> title, but if two different titles are given then it's an error based on 
> the specification that you quoted even though the word "error" isn't 
> used. It wouldn't be logically valid. I think of that as an error.

You didn't actually answer my question, but based on your response, it 
seems as though you are making an assumption about conformance.  I could 
just as well assume that anything the spec does not explicitly define as 
non-conforming, can be considered conforming.  Thus, based on my 
assumption, it would be ok to include both <title> and <meta 
property="title"> in the same document.  Logically, it may not make much 
sense to do so, but that doesn't automatically make it non-conforming.

Now you can see that we have made 2 different assumptions, neither of 
which can be considered wrong based upon what the spec actually says. 
Now consider that each of us were implementing our own conformance 
checkers.  Yours disallows the use of both together, while mine allows 
it.  Now, these 2 potentially correct assumptions have resulted in 
non-interoperable behaviour that would directly affect authors trying to 
use either conformance checker.

>>> and it's not practical to specify how every possible error should be 
>>> handled.
>>> In this case, I suggest a warning from the validator if two titles 
>>> exist and an error if the titles' content differs.
>>
>> If it can't be specified, how can it possibly be implemented?
> ...
>> Programmers would be forced to make assumptions about the parts of the 
>> spec that are poorly defined, or completely undefined, and different 
>> programmers will almost certainly make different assumptions.  
>> Different assumptions lead to different implementations that are not 
>> interoperable.
> 
> If someone tries creating a webpage in a way that the spec doesn't 
> indicate will work (if the person uses "logically invalid" code, or 
> whatever), then there's no correct way to render it.

And that is exactly what the problem is.  With no correct way to handle 
the page, different browsers will produce different results.  Regardless 
of what the browsers do, most authors will begin to rely upon the 
behaviour of the market leading browser of the time.  Then in an effort 
to compete, other browser vendors will be forced to reverse engineer the 
market leading browser, and we're back to the same situation we are in 
with HTML4, and are in the process of cleaning up.

Given that XHTML2 is a revolution, rather than an evolution, of HTML, 
you'd think the XHTML2 WG would have learned from the mistakes of the 
past.  Why must the XHTML2 WG be doomed to repeat the very same mistakes 
from which they were trying to escape?

> Standardizing agent behavior for logically invalid code would be based on
> a guess about the intention of the person who made the error. Maybe W3C 
> can make a better guess than browser developers, but I wouldn't have them 
> bother.

It's not about ensuring browsers correctly guess the intention of 
authors that make mistakes. If authors make significant mistakes, all 
bets are off as to what their intended meaning actually may be.  It's 
simply about explicitly defining what is and is not correct (neither of 
which the spec does particularly well), and what browsers must do to 
handle it.

> An error message pointing to the error during validation is the 
> correct way to handle it.

In general, most authors don't read specs, they don't validate and they 
don't care if they use semantically correct elements for everything. 
They make mistakes, they publish their mistakes and they expect things 
to just work.

Browsers have to deal with all sorts of errors and they have to do so 
interoperably.  Whether it's graceful or draconian error handling is not 
particularly relevant to this discussion, but it is important that be 
defined and interoperably implemented.

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

Received on Friday, 9 March 2007 12:40:26 UTC