Re: Doctype detection

On Wed, 26 Jul 2000 19:12:38 +0100 (BST), Ian Hickson
<py8ieh=mozilla@bath.ac.uk> wrote:

>On Wed, 26 Jul 2000, Jan Roland Eriksson wrote:
>> 
>> Don't use "doctype-sniffing" for the wrong purpose, doing that
>> will only create a new set of problems that we need to discuss
>> again some years from now.
>
>I disagree, but let us put that aside for now.

Ok, if it's in any way possible to settle the thing right here and now,
I'm all ears...

>Given the following facts:
>
>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.

It's not "against recommendations" to "follow recommendations", but at
least I would say that it is definitely inconsistent behavior not to
follow _all_ recommendations just because one of them happens to
convenient to follow for just this moment.

[recall my summary: 1) 2) and 3) in my previous post]

>2. Browsers should render documents designed for the standards 
>   in a standards-compliant way without being explicitly told
>   to using non-standard extensions.

Browsers are designed as "non validating SGML systems", that's a fact,
and let's not fight about that part at least.

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)

User suggestions adds to initial values, author suggestions adds more,
and so does the remaining part of the possibilities of a cascade in
order to produce a final presentation of a document.

If the original doc just happens to be of HTML2 origin, or not, does not
make any difference at all here.

If a document lacks a <!DOCTYPE... declaration, the UA that wants to
conform to "the backwards compatibility" recommendations, shall infer a
strict HTML2 DTD reference, and after that? who knows, except for a
"validating SGML environment" what will happen.

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

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

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

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) Let the browser look for a META HTTP-EQUIV entry in the
   markup to give the same effect as 2) above, and follow that
   one, before...

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


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.

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.

Which made me think of an alternative approach
to 1) 2) 3) and 4) above...

1) would be the same as 1) above...

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

3) The same "config" property should also be available for
   use in a user stylesheet of course.

4) Cascading rules could be applied on this...

Caveat:

I know the HTTP extension approach would work good inside the WWW, I
have not had time to follow trough on all implications of the second
approach as for a proprietary CSS extension, initially it looks as a
promising way to go though...

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

Received on Wednesday, 26 July 2000 20:22:26 UTC