Re: [XHTML 2] 24.2 Referenced objects not yet defined (PR#7752)

Steven Pemberton schreef:
> You don't need interoperability for incorrect documents, just for 
> correct ones. The specification defines what a correct document is, 
> and how that should behave. If you then send a correct document to a 
> browser, it is part of a contract between you and the browser, and if 
> the browser fails to correctly deal with the document it is then a bug 
> in the browser.
>
> If you send an incorrect document to a browser, there is no agreement 
> on how it should behave. If the browser does something you didn't 
> intend, it is your fault, not the browser's. 

The problem here is that the web is not just a set of pages that is 
maintained, and information on invalid pages that are no longer 
maintained is worthless. The web is about /information/, and I’d say it 
is the ultimate goal to preserve that information and try our best to 
make every page display, whether it was authored in 1994 or now. Young 
as it is, the web is already a highly volatile medium, and we should do 
our best to ensure that information is not lost any further (and 
information on invalid pages is not worthless). I think breaking 
existing content is socially unacceptable.

So given that browsers have to render invalid content, if these error 
conditions (or at least the most likely/common ones) are not 
well-defined, it is a likely scenario that we will reach a situation 
where each browser manufacturer instead of just implementing XHTML2 also 
needs to do an extensive study of finding the bugs that other browsers, 
particularly the major browser, have. Which is a situation which harms 
the ease of creating an XHTML2 client which is not only functional but 
also practical. Practical because, for its users, it is not acceptable 
to render broken content ‘incorrectly’ (that is, different than it was 
intended).

That said, I do not think browser-dependant differences will necessarily 
differ so much that they will cause the content to be really broken 
(just maybe rendered incorrectly), and differences in invalid markup 
implementation accross browser will probably also stimulate authors to 
create valid pages, as they either check in multiple browsers themselves 
or get notified by users of different clients when the page has 
significant problems.

But, it’s more or less a guess on how XHTML2 will evolve in its use on 
the web. When there’s a single major user agent, the situation where you 
have to reverse-engineer bugs of that browser is much more likely to 
occur. On the other hand, that might also not happen. But it’s a pretty 
wild guess, and it would be better to try to avoid the situation as much 
as possible by specifying in more detail how invalid markup should be 
handled.

In that process I would focus on the cases where the content either 
works or breaks, e.g. in the case of <param>, if one browser can handle 
it in invalid locations, others have, too, or the object can probably 
not be rendered at all. A different way of handling this case would mean 
that the content breaks. As another example, if a <li> is not placed 
inside an <ul>, assuming that user agents have a CSS-based 
implementation for that, the list will still render, albeit not 
correctly and maybe differently accross browsers. But at least it would 
show, so it would not be necessary to carefully define error handling 
cases for that.

This does not have to be done now however - I think it is better when 
done based on browser implementation experience, you’ll then get more 
real-world feedback on how invalid things are most easily handled.

Returning to the <param> example, if you specify that either invalid 
<param>s should not be processed, or that they should be processed but 
it will harm incremental rendering and cause a reflow or 
re-initialisation of the object. Which of the two ways to handle this I 
think would best should show after implementation experience, e.g. I 
think the latter will be difficult to implement while retaining 
incremental rendering capability, but practice will have to show that. 
In any case, once this implementation experience is there, I think rules 
for handling the invalid content should be added to the specification.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.

Received on Thursday, 26 January 2006 15:55:11 UTC