Re: [public-html] <none>

On Apr 27, 2007, at 6:36 AM, Gareth Hay wrote:

> I'm sorry, but I just can't agree on most if not all of the points
>>
>>
>>> What is preventing them having an HTML5 mode, which may or may  
>>> not build upon their previous engine.
>>> That way, you visit a page that you used to (google, bank, etc)  
>>> browser uses 'old' mode.
>>> You visit an HTML5 page, browser uses the new mode.
>>> Why is this a problem?
>>
>> There are several problems with that, all of which have been  
>> mentioned several times on this list.
>>
>> * It doesn't help improve interoperability for legacy content.
>> * New browsers in the future will still be forced to reverse  
>> engineer legacy browsers, instead of just implementing the spec.
>> * Browser vendors (except for IE) don't want to maintain more  
>> different modes for for HTML because it increases complexity and  
>> cost.  (see the versioning threads)
>> * Every new mode that is introduced, introduces a new mode that  
>> may need to be reverse engineered and specced.
>>
>> There are probably more that I can't remember off hand, please  
>> search the archives.
>>
>
> Maybe I wasn't clear. Browser manufacturers just freeze what they  
> have now as "legacy mode".

Except that we can't freeze what we have (other than IE) because we  
have to keep making fixes to work better with existing web sites.  
Your so-called "legacy mode" will be 99.9% of the web for the  
foreseeable future, and we're not going to punish our users by not  
fixing those bugs. If the spec doesn't exist

>  They begin implementing HTML5 as "html5 mode". If a page fails to  
> render in HTML5, for whatever reason, you either stop rendering and  
> report the error, or attempt to render the page in "old mode".

Processing pages twice is unacceptable for performance and security  
reasons.

> I don't see anyone having a page that doesn't work in this situation.

I hate to break the news to you, but there's lots of pages that don't  
work in Firefox, Safari, Opera, and sometimes even IE due to the lack  
of interoperability.

> Browser vendors will then be implementing to the HTML5 spec, so I  
> don't see how there is any reverse engineering or different modes.  
> (Just HTML5 or legacy - with legacy receiving no updates to the  
> codebase as of HTML5 release)

Not fixing any bugs on existing sites is unacceptable to anyone but  
Microsoft.

>> A new browser manufacturer, starting from scratch, is not going to
>> already have a mode that renders existing pages.
>>
> If we discount the possibility of another browser manufacturer  
> entering the market for a moment.

Discounting the possibility doesn't address the problem.

>  Do we really want to carry on the way we have, with browsers  
> attempting to render bad code and poorly spec. stuff all over the  
> place, or do we actually want to standardise on a spec and move  
> forward.

Yes, we do want browsers attempting to render bad code. Not rendering  
it means lost users.

> I think the correct course of action is as I have stated before,  
> keep what we have as "legacy mode", but bring in html5 mode to  
> render new html5 pages. Creating an HTML5 only browser frees us of  
> the legacy nonsense. (as that is effectively what would be happening)
> It's not as if we are going to remove legacy browsers as new HTML5  
> browsers come along.
> I don't think it is realistic to have one browser to render 100% of  
> the web. It's just not, so let's get with the program that will  
> give us this solution in a reasonable amount of time.

Try substituting "XHTML2" for "HTML5" in that paragraph and think  
about why it didn't work.

>
>>> What is preventing them having an HTML5 mode, which may or may not
>>> build upon their previous engine.
>>
>> Nothing -- the new manufacturer can implement an HTML5 mode,  
>> following
>> the spec.  But at that point, the browser could fail to render  
>> most of
>> today's web content -- because most of the current content was  
>> written
>> without knowledge of HTML5, and indeed without following any spec at
>> all.
>
> I read this as saying, "If I design a program to render Latex, it  
> won't render the rest of the web". Of course it won't.
>
> I don't see the problem, release HTML5 as "Web 2.0" and tell  
> everyone they need a new browser, problem solved, you want Web2.0  
> sites, you need the new browser (just keep your old browser for the  
> rest of the web)

Making users use two browsers for different sites is unacceptable.  
That's the kind of thing that makes users write angry blog posts and  
then switch browsers.

> It's not ideal, but it gets us to a much better location than we  
> can ever get to with quirks modes and almost standards modes, and  
> backwards compatibility.\

The big problem with your plan is that it's not going to happen. Let  
me be frank for a moment. Standards groups are not your opportunity  
to order browser vendors to majorly shift their development strategy,  
neither Microsoft (as we have seen) nor anyone else. It is a place to  
work together and negotiate, yes. But if you ask browser vendors to  
do something they are fundamentally unwilling to do, like break  
compatibility, they will just walk away from the process. That's how  
you end up with XHTML2.

For those of us who do not have the limitless development resources  
and cash pile of Microsoft, making HTML5 a completely separate mode  
is an unacceptably high cost. So it's not going to happen. I know  
it's lots of fun to make up something pure and clean and new, with  
all the ugly rough edges of compatibility filed off. But you can't  
have both that and a spec that browsers will implement. Time to choose.

Regards,
Maciej