Re: Doctype detection

On Thu, 27 Jul 2000, Jan Roland Eriksson wrote:
>>
>> 1. For browsers to have any significant market share they must 
>>    render legacy content in a backwards-compatible way.
> 
> I'm not against that view; But please see the implications of it in the
> light of what available specs says.

I may have missed fact 0:

 0. The current W3C specs are not an accurate representation of 
    what legacy browsers do.

In other words, complying with the specs breaks existing pages.


> Browsers shall render docs according to the default mode they have
> been produced to use from the start of their own life, if nothing
> else. (available CSS specs implies that at least)

?? I do not understand that. 

CSS != Legacy rendering. There are some things in CSS1 (for instance,
the inline box model) that are GREAT improvements over the legacy
renderings, but which are NOT backwards compatible (for instance,
stacking images in subsequent lines).


> If a document lacks a <!DOCTYPE... declaration,

...then it is invalid.


> But one thing is for sure, after that inference of a <!DOCTYPE... no
> switching into "buggy quirks rendering mode" is to take place...

Why? HTML and rendering are distinct, and with the exception of HTML 3.2
and some deprecated parts of HTML 4, no parts of HTML give any details
on how to render the documents at all.

 
> If the browsers gets a text/html doc over HTTP and knows how to get
> a linked stylesheet as a text/css doc in the same way, the browser
> is obliged to use the info it gets to the best of its capability,
> totally regardless of the existence of an original <!DOCTYPE...
> declaration or just an inferred <!DOCTYPE...

You mean it has to follow the CSS specification regardless? Sorry, no
can do. That would break too much non-compliant content and thus the
browser in question from gaining market acceptance.


>> ...how would you suggest browsers should detect whether to use
>> their quirks mode or their standard compliant mode?
> 
> This is a repeat, sorry (it's in Bugzilla too, since long back)
> 
> My initial suggestion has been as follows...
> (top to bottom priority)
> 
> 1) Create the required part of the UI that lets the user
>    decide for him/her self.

Excuse me?? You mean that as a user I have to keep hitting a button to
get pages to draw right, and as a web author I have no guarentee that my
pages will look the same in the browser each time a user visits??

Please tell me how a non-techy person would understand a "rendering mode
switch" in a browser.

That's like having a button on a microwave labelled "magnesium content
greater than 1 part per 1000", and then having microwave meals only
taste right if cooked using the right setting on that switch. 

Except that there is no wrapping to a website -- you can't read the
instructions first and discover whether a page should be viewed in
Quirks mode or not.


>> 2. Browsers should render documents designed for the standards 
>>    in a standards-compliant way without being explicitly told
>>    to using non-standard extensions.
>
> 2) Define a specific HTTP1.1 extension header that authors
>    can use to send an indication about what might be a good
>    choice of rendering mode.
> 3) [<meta http-equiv> version of (2)]

No way!! "Hello everyone, we are going to comply to standards, but if
you want us to render your pages right, you have to add a non-standard
tag! 

That is the same as requiring a doctype... except that we have no
excuse! At least with a DOCTYPE we can say "Ah but you need a doctype if
you are standards compliant anyway". Requiring authors to break
standards just so that their pages are rendered per the standards is
simply ridiculous.


> 4) ...using <!DOCTYPE... sniffing for any purpose at all...

Which is what Mozilla and MacIE5 have decided on, and what WinIE are
currently looking at, as I understand it.


> At some point (not so long ago) it was suggested to me that the
> above scheme might not be fully usable in all situations, especially
> not in areas where docs was served outside of the www.

That's the least of the problems...


> The suggestion given was that we might want to _totally_ separate
> markup from presentation already at the situation of document
> delivery, and keep all parts of presentational suggestions in a
> stylesheet.

That would be ideal. But some of the backwards compatability issues deal
with the parsing, too. For example, <!-- -- --> This is a comment <!--
-- --> is treated correctly in standards mode in Mozilla but in a
backwards compatible way in quirks mode.


> 2) Define a proprietary CSS property (starting with e.g. -- )
>    that takes on values like :user :quirk :standard :strict

LOL! That's as bad as (2) and (3) above. "You want us to comply to
standards? Well add this magic, NON-STANDARD property to your
stylesheets..." 

Sorry, but your solutions have all the problems of DOCTYPE heuristics,
with several additional ones thrown in for good measure.

Do you have any better ideas?

-- 
Ian Hickson                            ("`-''-/").___..--''"`-._   
http://www.bath.ac.uk/%7Epy8ieh/        `6_ 6  )   `-.  (     ).`-.__.`)
                                        (_Y_.)'  ._   )  `._ `. ``-..-' fL
Member, Mozilla Quality Assurance     _..`--'_..-_/  /--'_.' ,'
Browser Standards Compliance Team    (il).-''  (li).'  ((!.-'

Received on Thursday, 27 July 2000 02:21:47 UTC