[whatwg] several messages about XML syntax and HTML5

Sander Tekelenburg tekelenb at euronet.nl
Fri Dec 8 11:18:36 PST 2006


At 16:13 +0000 UTC, on 2006-12-08, Simon Pieters wrote:

> From: Sander Tekelenburg <tekelenb at euronet.nl>
>>[...] But it still leaves the question whether
>>every browser will in fact be HTML5 compliant.
>
> They probably won't, at least for the next few years.

Right. That's a window of opportunity (for the sort of attack I mentioned)
I'm voicing concern about. I agree that it will likely be much harder when
all browsers are HTML5-compliant and most authors produce HTML5. But before
that?

> [...] But having a clear
> spec generally leads to much better interoperability than not having a spec
> at all.

Heh. How could I possibly not agree with that ;)

[...]

[potential attack on HTML5]

> I believe you are wrong. That potential risk is much bigger *today* than if
> browsers implemented the HTML5 parsing model, because the HTML5 parsing
> model is a compromise between all browsers while being closest to IE. So
> pages written specifically for IE will probably look better in HTML5 UAs
> than today's non-IE browsers.

Yes, but your "written specifically for IE" assumes today's IE.

[...]

> I think that if MS change their tag soup parser, they will change it to be
> more compliant with HTML5, because doing otherwise would break the Web and
> MS don't want that

Right. I'm imagining a browser that is HTML5-compliant, except for some on
purpose different behaviour when encountering specific parse errors. Thus
showing both existing pages and new broken pages as authors intended, but
different from every truly HTML5-compliant browser.

[...]

> If it by any chance *does* happen

If this happens it won't be by chance ;)

> , then I think this will happen:
>
>    1. MS change their tag soup parser and break the Web (unlikely).

Agreed.

>    2. Users start using this new browser (unlikely).

Disagreed. Most people seem to stick with what they get with the box unless
it both [1] makes their lives miserable and [2] they realise that it does.

>    3. New Web content authored for this new browser breaks in other browsers
> (including IE6, IE7) (unlikely).

Agreed.

>    4. Other browser vendors find they are incompatible with new Web content
> and start to reverse engineer this new browser (has happened before, so
> potentially likely).

Yes. That's the guesswork/ESP engine I've been referring to. When that
happens, there will again be more browser behaviour differences than just the
2, like today.

If a situation does occur where such reverse engineering is needed, will all
browser developers do so together? Or will they be competing? It may well
seem attractive to be the first to offer a new version that shows such broken
documents 'correct'. Similarly, it's unlikely that all other browse vendors
will agree about on exactly what moment a specific problem is wide-spread
enough to warrant action. (Because not only does that action require
resources, it also implicitly means recognition of the tool that generated
the problem.)

>    5. The HTML parsing spec is updated to reflect reality (happens right
> now, so potentially likely).

Agreed, but (re)defining a spec and getting all parties to implement it takes
time. (Granted, possibly in a case like this it can be done rather quick.)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>



More information about the whatwg mailing list