Re: Doctype detection

On Thu, 27 Jul 2000 07:21:43 +0100 (BST), py8ieh=mozilla@bath.ac.uk
wrote:

>On Thu, 27 Jul 2000, Jan Roland Eriksson wrote:

[...]

>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.

That would be a blessing if you ask me, but I understand that there's a
lot of money and time at stake here too.

>> 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. 

CSS2 6.4
  User agent: Conforming user agents must apply a default style
  sheet (or behave as if they did) prior to all other style
  sheets for a document.

[...]

>> If a document lacks a <!DOCTYPE... declaration,
>...then it is invalid.

If a document has a <!DOCTYPE... declaration,
it can still be invalid, will Mozilla switch to 'quirk' mode
in that case too?

If it does? On what criteria is such a decision taken then?

>> 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.

RFC1866 specifies a typical processing expectation (i.e rendering)
for all elements defined.

[...]

>>> ...how would you suggest browsers should detect whether to use
>>> their quirks mode or their standard compliant mode?
[...]
>> 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,

Please...
You know exactly what I mean by giving a user full control of his
browsing environment.

>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 again...
Have you not yet understood that you can _never_ have such a guarantee
for documents served from an arbitrary server to an arbitrary user?
At least I thought this was clear among experienced web users by now.

[snip some analogy]

>> 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!

I wonder if that is just an outburst or if you did read what I wrote?

META HTTP-EQUIV _is_ available in HTML4.01 strict even, like it or not.

>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.

Breaking what standard? HTTP1.1 _is_ as much of a standard it can be and
so is the META element, what are you talking about?
I guess Mozilla is still supporting all the other, sometimes "idiotic"
uses, that comes in via META elements?

I personally don't need it though, I know how to configure my own
server, so let it go then, I will not miss it.

>> 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.

And as I understand it, there's a bone hard resistance among vendors to
provide an alternative way for authors to suggest rendering mode?

[...]

>> 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..."

While you are still in a good mode and on the topic of "NON-STANDARD",
it would be interesting to know if all those little -moz-... thingies
and maybe also the funny looking :out-of-date pseudo (to name a few
things) will be gone from Mozillas own css files before the final
version ships?

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

Lesson learned.
Browser vendors don't like to give users full control of their browser.
(well there is one exception I guess)
Browser vendors don't like to give authors to many alternatives either.

>Do you have any better ideas?

Let's come back to that when the first problems with "doctype sniffing"
gets reported.

-- 
Jan Roland Eriksson <jrexon@newsguy.com>
<URL:http://member.newsguy.com/%7Ejrexon/>

Received on Thursday, 27 July 2000 14:32:23 UTC