NavQuirks vs Standard Mode, and XML

4 views
Skip to first unread message

Jerry Baker

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to
Erik van der Poel wrote:
>
> 1. In NavX compatibility mode, Gecko must handle all HTML in a
> backward compatible manner. (The policy is 'accept and don't
> complain'). This includes dynamically rewriting the HTML in
> question. Users will be able to use the viewsource command to see
> errors that are present on the page, even though we've cleaned
> them up.

This is very cool if it is true. Now what do we have to do to our pages
to trigger compatibility mode? I hope nothing. I hope that HTML 4.0 (and
thus CSS) rules are only applied to documents declaring that they are
HTML 4.0.

Steve Morrison

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to


The presence of a doctype triggers standard mode.

-steve

Jerry Baker

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to

What is standard mode? Strict or quirks? What doctype - all?

Erik van der Poel

unread,
Jan 27, 2000, 3:00:00 AM1/27/00
to mozilla...@mozilla.org
We're getting way off the subject here, but I'll respond to DavidMc. Your distinction between 'don't accept' and 'accept but complain' is fitting. The parsing-engine/contentsink does in fact already support this distinction, and the rules are straightfoward:
    1. In NavX compatibility mode, Gecko must handle all HTML in a backward compatible manner. (The policy is 'accept and don't complain'). This includes dynamically rewriting the HTML in question. Users will be able to use the viewsource command to see errors that are present on the page, even though we've cleaned them up.
    1. In strict mode (using HTML4.0 strict DTD) we try to act in accordance with the cited W3C spec. We do far less cleanup (almost none). The policy here is 'accept but complain'.
    2. In XML and XHTML documents we comply with the XML spec, and errors are dealt with by presenting a message in the display. The policy is 'don't accept'.


    David McCusker wrote:

    Steve Clark wrote: [ snip ]
    > backwards compatible behavior is *very* important. again, I don't
    > have a strong opinion about where that compatibility layer ought to be.

    We should do two things:
    1. Support old behavior.
    2. Provide a mode giving negative feedback for deprecated old forms.

    Negative feedback means making a message available to users or
    developers with enough info to make a change most easily.  This helps
    folks out there converge on better behaved content encodings.

    Now the reason I am bothering to respond at all is to explain how we
    should handle all the crufy backwards compatible behavior everywhere.
    (I'll only say this once, so I won't engage in a conversation. :-)

    This applies to handling bad html nicely, as well as validating XML
    parser issues.  There is a very useful gray zone between 'accept' and
    'don't accept', and this mode should be called 'accept but complain'.

    The 'don't accept' mode is like errors in a compiler, and 'accept but
    complain' mode is like warnings in a compiler.  You folks can argue
    about what kind of value this provides folks under various conditions.

    I just hope these semantics end up in the final client, because I want
    to see warnings for my bad html, so I can go in and fix my mistakes.

    David Mc

    rickg.vcf

    Erik van der Poel

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to Jerry Baker
    Jerry Baker wrote:

    >
    > Steve Morrison wrote:
    > >
    > > The presence of a doctype triggers standard mode.
    >
    > What is standard mode? Strict or quirks? What doctype - all?

    Standard = strict.

    There is a bug report that discusses what doctype should trigger
    Standard Mode:

    http://bugzilla.mozilla.org/show_bug.cgi?id=1312

    Erik


    Pierre Saslawsky

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to Erik van der Poel

    Erik van der Poel wrote:
    >

    > Jerry Baker wrote:
    > >
    > > Steve Morrison wrote:
    > > >
    > > > The presence of a doctype triggers standard mode.
    > >
    > > What is standard mode? Strict or quirks? What doctype - all?
    >
    > Standard = strict.
    >

    To make it clear "standard = strict" but "default = quirks".

    If the document doesn't say anything, we run in quirks mode.
    If the document has a strict DTD, we run in strict mode.

    For those who wonder, the strict DTD is something like that at the top of the
    file: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

    --
    Pierre Saslawsky <pie...@netscape.com>
    French Style

    Jerry Baker

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to

    Mozilla is definitely not doing this now. See the whole thread about
    <font> tags. This is occuring in dics with no declaration.

    Jerry Baker

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to
    Jerry Baker wrote:
    >
    > Mozilla is definitely not doing this now. See the whole thread about
    > <font> tags. This is occuring in dics with no declaration.

    Dics? --> Docs
    --
    Jerry Baker

    "Real programmers don't work from 9 to 5. If any real programmers are
    around at 9am it's because they were up all night." - Anon.

    Robert Kaiser

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to
    What about this line:

    <!doctype html public "-//w3c//dtd html 4.0 transitional//en">

    That's what Composer 4.x writes to ALL html documents...
    (so the code written there should be a quirks code, right?)


    Chris Nelson

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to
    Uh - yes it is. It's just that not *everything* has been set up yet to work in a
    quirks/strict mode fashion yet. The line height issue you mentioned (I had to
    assume that was what you are talking about) is one of those things, and it sounds
    like it's going to get that treatment.

    --chris

    Jerry Baker wrote:

    > Pierre Saslawsky wrote:
    > >
    > > Erik van der Poel wrote:
    > > >
    > > > Jerry Baker wrote:
    > > > >
    > > > > Steve Morrison wrote:
    > > > > >
    > > > > > The presence of a doctype triggers standard mode.
    > > > >
    > > > > What is standard mode? Strict or quirks? What doctype - all?
    > > >
    > > > Standard = strict.
    > > >
    > >
    > > To make it clear "standard = strict" but "default = quirks".
    > >
    > > If the document doesn't say anything, we run in quirks mode.
    > > If the document has a strict DTD, we run in strict mode.
    > >
    > > For those who wonder, the strict DTD is something like that at the top of the
    > > file: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
    > >
    > > --
    > > Pierre Saslawsky <pie...@netscape.com>
    > > French Style
    >

    Jan Roland Eriksson

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to
    On Thu, 27 Jan 2000 12:08:05 +0100, in netscape.public.mozilla.layout
    Robert Kaiser <Ka...@StarTrekMail.com> wrote:

    >What about this line:
    >
    ><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
    >
    >That's what Composer 4.x writes to ALL html documents...

    If that's the case it only goes to show that the programmer that put
    that stuff in there in the first place, did not RTFM.

    >(so the code written there should be a quirks code, right?)

    It's an invalid doctype declaration any way you look at it so "quirks"
    mode should be guaranteed just by that.

    Doctype declarations are case sensitive as it comes to the identifier
    part of them, so a correct declaration in this case would have been...

    <!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN">

    ...it should still give "quirks" mode though, thanks to the
    'Transitional' nature of it.

    --
    Jan Roland Eriksson <r...@css.nu> .. <URL:http://css.nu/>

    Arjun Ray

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to
    On 27 Jan 2000 07:14:33 GMT,
    er...@netscape.com (Erik van der Poel) wrote:
    >
    > There is a bug report that discusses what doctype should trigger
    > Standard Mode:
    >
    > http://bugzilla.mozilla.org/show_bug.cgi?id=1312

    I read it, with growing dismay. The concept may appear workable, but
    in reality it's utterly, comprehensively and totally bogus, perhaps
    tragically so.

    The doctype declaration will not tell you what you need to know. That
    isn't its job, anyway. The name nothwithstanding, the doctype thingy
    is not about (declaring) document types. There might be people who
    think that, or have learned that from somewhere, but sadly, they're
    wrong; and at any rate, isolated instances of "sincere" use will be
    swamped by the bogotic extrusions of FrontPage, Composer, wannabes and
    &Deity; knows what else.

    Like it or not, 'quirks' mode is your only practical default. How to
    trigger 'strict' mode is a problem for which as yet there's no good
    answer. A lot of that has to do with inadequacy in the "official"
    specs too. They don't *provide* for an answer (even though the Powers
    That Be at the W3C actually think otherwise.)

    My suggestion? Make sure you support (a) Processing Instructions, and
    (b) Marked Sections. Why? Because 'strict' mode should - and will -
    be a matter of document authors actively asking for it, and so, as a
    workaround, they might just use one of those syntactic devices to pass
    Mozilla the right message *unambiguously*.


    :ar

    Jerry Baker

    unread,
    Jan 27, 2000, 3:00:00 AM1/27/00
    to
    Erik van der Poel wrote:
    >

    Maybe as a transition to more major browser support (read IE getting in
    line with standards <-hah hah hah), and to deal with crap that Composer
    and FrontPage emit now, you could have a Mozilla specific comment
    instead or in addition to a doctype?

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html40/loose.dtd">

    <!--Mozilla Strict Interpretation-->

    Or something? Probably bad, but just an idea. Temporary until the Web
    gets a little more standardized.

    Erik van der Poel

    unread,
    Jan 28, 2000, 3:00:00 AM1/28/00
    to ar...@interactrx.com
    Hi Arjun,

    Arjun Ray wrote:
    >
    > My suggestion? Make sure you support (a) Processing Instructions, and
    > (b) Marked Sections. Why? Because 'strict' mode should - and will -
    > be a matter of document authors actively asking for it, and so, as a
    > workaround, they might just use one of those syntactic devices to pass
    > Mozilla the right message *unambiguously*.

    Intriguing.

    What do Processing Instructions and Marked Sections look like? Do older
    browsers deal gracefully with these?

    Are they part of HTML and/or XML? Or just SGML? (Even if they are not in
    HTML and XML, we might still want to use them.)

    Was your comment about FrontPage, Composer and others referring to the
    doctypes that they emit right now, or doctypes that they might emit in
    the future? If the latter, what is to prevent those programs from
    emitting Processing Instructions and Marked Sections in the future? Or
    are you saying that Mozilla should be really strict in strict mode, and
    simply refuse to display non-conformant documents that have somehow
    managed to trigger strict mode? Any such refusal would only work if
    Mozilla had a large enough market share at that point. FrontPage et al
    are not going to be worried about some minor browser refusing to display
    their stuff, if the major browser(s) handle it OK.

    When you say "pass Mozilla the right message", do you mean authoring for
    Mozilla in particular, or for The Standards in general?

    Erik


    Arjun Ray

    unread,
    Jan 28, 2000, 3:00:00 AM1/28/00
    to
    On 28 Jan 2000 06:26:47 GMT,
    er...@netscape.com (Erik van der Poel) wrote:

    > What do Processing Instructions and Marked Sections look like?

    1. Processing instruction:

    <? anything except the ending delimiter ?>

    (The '?>' ending delimiter is new to XML, but harmlessly usable in
    SGML also, where traditionally it used to be '>')

    For instance, the "XML declaration" that usually looks like this:

    <?xml version="1.0"?>

    is actually a garden variety PI! There's no standardized internal
    syntax for PIs, but the "target convention" is pretty common: a
    "target" name immediately after the '<?' and name="value" pairs after
    that, very much like attribute specifications in start-tags. The idea
    is that the PI-target establishes some known schematic in which the
    remaining "attributes" make sense.

    PIs are allowed almost anywhere: before/after the doctype declaration,
    in DTDs, and in the document anywhere you could put text (i.e. only
    not inside markup.)

    2. Marked Section:

    <![KEYWORD[ anything except the ending delimter ]]>

    where KEYWORD is INCLUDE, IGNORE, CDATA or RCDATA
    or blank which "means" INCLUDE

    INCLUDE and IGNORE have the obvious meaning; they can be used in DTDs
    and in the document. The CDATA and RCDATA variants mean that almost
    no markup is recognized inside (except, of course the ending ']]>');
    the difference between CDATA and RCDATA is that in CDATA everything is
    just text data, while in RCDATA &entities; are still recognized. But
    no tags. (XML restrictions: INCLUDE/IGNORE only in DTDs, only CDATA
    in document.) The special case of no keyword at all, i.e. a start of
    '<![[' - also not allowed in XML - means "INCLUDE". (Yes, that's
    obviously stupid, but no one said SGML was a paragon of perfection:-))

    A CDATA marked section was *the* thing to "hide" scripts, way back
    when...

    > Do older browsers deal gracefully with these?

    Probably not with PIs, if they're "what-bug-it's-really-a-feature"
    evolutionary from Mosaic. With Marked Sections, partially, given that
    they kinda sorta start with '<!' and end with '>'...



    > Are they part of HTML and/or XML? Or just SGML?

    As fundamental syntax in SGML, they're HTML by definition. XML has
    some restrictions on marked section usage that I've noted above, which
    would apply to XHTML.

    > (Even if they are not in HTML and XML, we might still want to use them.)

    You're telling me!:) Check these out:

    http://x21.deja.com/=dnc/getdoc.xp?AN=139989335
    http://x23.deja.com/=dnc/getdoc.xp?AN=139149145

    Still waiting... ;)

    > Was your comment about FrontPage, Composer and others referring to
    > the doctypes that they emit right now, or doctypes that they might
    > emit in the future?

    Both.

    > If the latter, what is to prevent those programs from emitting
    > Processing Instructions and Marked Sections in the future?

    Nothing, in principle. You gotta get there first!:)

    Besides, there's no reason for them to emit these, unlike doctypes,
    which have both another purpose (ergo reasons to be there anyway) and
    verbiage in the specs apparently demanding them (ergo some need on the
    part of generators to demonstrate at least pro forma "conformance").

    However, there's one PI that has the backing of an international
    standard, so FrontPage et al can't emit it figuring "it'll be ignored
    anyway", because by definition it's not to be ignored (whereas a
    doctype can be.)

    > Or are you saying that Mozilla should be really strict in strict
    > mode, and simply refuse to display non-conformant documents that
    > have somehow managed to trigger strict mode?

    No. I'm saying that there is a way for documents to *assert* that
    they *want* strict mode. So, if that assertion is not there, Mozilla
    probably shouldn't insist. And if it is there, well, they *asked* for
    it...

    > When you say "pass Mozilla the right message", do you mean authoring
    > for Mozilla in particular, or for The Standards in general?

    For the latter, hopefully; for the former, if that's all that might be
    feasible in the short run. OK, enough mystery about the method. Here
    is the reference, an ISO working group document:

    http://www.ornl.gov/sgml/wg8/document/1957.htm

    It's a PI-based simplified version of this:

    http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.4.html

    Its miminal (proper) use could look like this

    <?IS10744:arch
    name = "html"
    public-id = "-//W3C//NOTATION HTML 4.01//EN"
    dtd-public-id = "-//W3C//DTD HTML 4.01//EN"
    ?>

    Note that the dtd-public-id has the same "public text class" of DTD as
    the FPIs found in doctypes. The basic difference is that this DTD is
    a reference only, while the external subset of the doctype is actually
    a syntactic component of the document.

    My suggestion is to look for this PI in the document, anywhere before
    the root <html> element's start-tag. If you need more background,
    here is one classic reference:

    http://www.dejanews.com/getdoc.xp?AN=325927738

    And, with some hesitation, I'd suggest the www-html mailing list for
    some recent threads, dealing with related issues.

    http://lists.w3.org/Archives/Public/www-html/2000Jan/

    :ar

    Ulf Pettersson

    unread,
    Jan 28, 2000, 3:00:00 AM1/28/00
    to
    > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    > "http://www.w3.org/TR/html40/loose.dtd">
    >
    > <!--Mozilla Strict Interpretation-->
    >
    > Or something? Probably bad, but just an idea. Temporary until the Web
    > gets a little more standardized.

    A _very_ bad idea.

    This is exactly the attitude that has ruined things with the web
    standards-wise.

    If there is no good, working, standard then don't do it.

    Jerry Baker

    unread,
    Jan 28, 2000, 3:00:00 AM1/28/00
    to
    Ulf Pettersson wrote:
    >
    > A _very_ bad idea.
    >
    > This is exactly the attitude that has ruined things with the web
    > standards-wise.
    >
    > If there is no good, working, standard then don't do it.

    I imagine that if Mozilla can pay attention to the "Transitional" or
    "Strict" part, then it could use doctypes. Maybe it can just use the
    DTD?

    Jan Roland Eriksson

    unread,
    Jan 28, 2000, 3:00:00 AM1/28/00
    to
    On Fri, 28 Jan 2000 03:21:55 -0500, in netscape.public.mozilla.layout
    Arjun Ray <ar...@nmds.com> wrote:
    [...]

    >OK, enough mystery about the method.
    >Here is the reference, an ISO working group document:
    >
    > http://www.ornl.gov/sgml/wg8/document/1957.htm
    >
    >It's a PI-based simplified version of this:
    >
    > http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.4.html
    >
    >Its miminal (proper) use could look like this
    >
    > <?IS10744:arch
    > name = "html"
    > public-id = "-//W3C//NOTATION HTML 4.01//EN"
    > dtd-public-id = "-//W3C//DTD HTML 4.01//EN"
    > ?>

    That would be a great way of "switching" Moz modes of course.

    But? Whatabaout that 'public-id'?

    First; it's not available yet, to the best of my knowledge.
    So that PI would not fill much of any other purpose.

    Secnd; Was it not things like that, that was going to cause
    a "heart attack" for some poor soul? :)

    Still I second the idea of using a PI or a marked section to switch Moz
    into strict mode. Anything wrong with a Moz that makes use of both?

    Todd Fahrner

    unread,
    Jan 28, 2000, 3:00:00 AM1/28/00
    to
    Arjun wrote:

    > The doctype declaration will not tell you what you need to know. That
    > isn't its job, anyway.

    I agree with the second sentence, but not with the first. Not yet, anyway.

    We're not proposing to confuse a strict doctype with a PI for "strict"
    treatment, but the converse: we're proposing to take the *absence* of a
    doctype, or the use of doctypes with a history of bogus usage, as equivalent
    to a PI for "tag soup" treatment.

    You have argued in the past that the text/html MIME type should be
    understood as equivalent to such a PI - "equivalent to" since explicit PIs
    aren't supported by "Mosaic spawn". There's an opportunity here, I think, to
    start rehabilitating the text/html MIME type without breaking legacy stuff
    (any more than it is already). If we fail, at least we will have erected a
    practical barrier against abuse of future doctypes as "incantations" or
    empty formalities embellishing tag-soup. You like, no?

    What we need to know is whether the document is likely to have been created
    under a certain regime of expectations: tag soup processors and the abortive
    stylesheet/DOM implementations natural to them. The text/html MIME type
    alone needn't be sufficient to indicate this, and an explicit PI *should be*
    superfluous IMO.

    > [snip] at any rate, isolated instances of "sincere" use will be


    > swamped by the bogotic extrusions of FrontPage, Composer, wannabes and
    > &Deity; knows what else.

    I disagree. FrontPage, Composer et al ostensibly do "what works" as tag
    soup, regardless of SGML formalities. If sticking in an unfamiliar or HTML 4
    Strict doctype causes tag-soup expectations to fail in Netscape 5 or any
    other UA that adopts a doctype-based switch (MacIE5 comes to mind, based on
    www-style hints), then they won't use one. I seriously doubt whether any
    so-called HTML authoring tool is cranking out tag soup and automatically
    using doctypes that will produce undesirable results against David's
    proposed heuristics:
    <http://www.people.fas.harvard.edu/~dbaron/tests/nglayout/doctypes.html>.
    And even if so, it should be easy to tweak.

    > Like it or not, 'quirks' mode is your only practical default.

    It's not practical - not for many applications requiring predictable
    stylesheet/DOM stuff. That's the problem.

    > How to
    > trigger 'strict' mode is a problem for which as yet there's no good
    > answer.

    Again, backwards: it's how to know whether it will likely break if treated
    per spec. If not an HTML spec per se, then the specs for any associated CSS
    or scripts (which in any case depend at least upon a predictable parse of
    the document).

    > My suggestion? Make sure you support (a) Processing Instructions, and
    > (b) Marked Sections. Why? Because 'strict' mode should - and will -
    > be a matter of document authors actively asking for it

    Why shouldn't it be a matter of course? We probably need to define "strict"
    a little better. I think of "strict" as simply the inverse of "quirks",
    where "quirks" is defined as a mode wherein previous (CSS/DOM!) anomalies
    are actively emulated.

    If you would define it more positively as "in full accord with SGML
    processing norms" or similar, I hear a barn door opening.


    Arjun Ray

    unread,
    Jan 29, 2000, 3:00:00 AM1/29/00
    to
    On Fri, 28 Jan 2000 16:23:31 -0800,
    Todd Fahrner <fah...@pobox.com> wrote:

    > Arjun wrote:

    > We're not proposing to confuse a strict doctype with a PI for
    > "strict" treatment, but the converse: we're proposing to take the
    > *absence* of a doctype, or the use of doctypes with a history of
    > bogus usage, as equivalent to a PI for "tag soup" treatment.

    With respect, this is the same bogus principle: that the doctype
    declaration asserts a *type*. Whether the software is programmed to
    understand the alleged type as tag soup or anything else is secondary;
    the *premise* of an intelligible type to begin with - i.e. sufficient
    to trigger appropriate software response reliably - is false. And as
    false premises invariably do, you invite a sea of troubles:

    (1) So you think this or that doctype has an, uh, history. What
    if it *is* kosher? Why are you penalizing good faith behavior?
    (The idea that one should not use HTML 2.0 because HTML 4.01 is
    "more up to date" - or any other reason appealing to vanity - is
    another bogus principle.)
    (2) *Why* do you think this or that doctype has a "history"? Don't
    say the judgement call is "necessary": examine the necessity.
    (3) The universe of bogosity is unbounded: your judgment calls will
    need unending revision and updating. Busywork.
    (4) The absence of a doctype mean nothing. As pure formalities go,
    this is now *legal* (more on this below), so that if anything,
    the mere *presence* of a doctype may *demand* Quirks mode!

    > You have argued in the past that the text/html MIME type should be
    > understood as equivalent to such a PI -

    In a nutshell: text/html == Tag Soup. That's the Mosaic/Netscape
    legacy. Ironic to find resistance to this fact in this newsgroup:)

    More generally, I've argued that SGML formalities applied to text/html
    are meaningless, at best misleading: "Familiarity breeds contempt".

    > "equivalent to" since explicit PIs aren't supported by "Mosaic spawn".

    The Mosaic spawn barfing on PIs is exquisitely ironic, considering the
    Rocket Science involved.

    > There's an opportunity here, I think, to start rehabilitating the
    > text/html MIME type without breaking legacy stuff (any more than it
    > is already).

    Humpty Dumpty is an omelet rotting in a ditch somewhere.

    > If we fail, at least we will have erected a practical barrier against
    > abuse of future doctypes as "incantations" or empty formalities
    > embellishing tag-soup. You like, no?

    No. If the doctype declaration is to be resurrected, it will have to
    be for its correct purpose - useful internal subsets.

    The FPI in a doctype declaration (i.e. an external subset "by name")
    is strictly redundant. It has never had privileged status, and any
    "requirement" mandating its presence is bogotic. (Yes, this applies
    to *all* existing HTML specs.) With the WebSGML TC (N1955), even the
    *formality* of a doctype declaration - i.e. the mandatory presence of
    a declaration subset as a syntactic component of a document - has been
    dropped from SGML, which moots any notion of even *expecting* a FPI.

    > What we need to know is whether the document is likely to have been
    > created under a certain regime of expectations: tag soup processors
    > and the abortive stylesheet/DOM implementations natural to them.

    Look no further. Content-type: text/html. Simple. Easy.

    > The text/html MIME type alone needn't be sufficient to indicate this,

    It is, certainly when it comes to "default assumptions" that may need
    to be made. This is not an "engineering" fact as much as it is a
    social fact. Gresham's Law.

    > and an explicit PI *should be* superfluous IMO.

    For one thing, given that tag soup processors *do* barf on PIs - oh
    the wonders of Rocket Science - wouldn't the presence of a PI say
    something...?;-)

    But that's drifting off the basic point, which is that the SGML/XML
    formalism, **even when one is prepared to take it seriously**, does
    *not* provide a type assertion mechanism. None. Seriously. The
    doctype declaration is not a pinch-hitter, either. The ArchUse PI is
    a necessary kludge: an "official" kludge, but a kludge nonetheless.



    > > [snip] at any rate, isolated instances of "sincere" use will be
    > > swamped by the bogotic extrusions of FrontPage, Composer, wannabes
    > > and &Deity; knows what else.
    >
    > I disagree. FrontPage, Composer et al ostensibly do "what works" as
    > tag soup, regardless of SGML formalities.

    True, but they emit a doctype *only* because of some inscrutable
    formal requirement. Look Good, Impress The Natives, And So on. We
    know this. (I have to say though, lowercasing everything was a piece
    of RTFM-challenged art that took my breath away. It must have earned
    the fella instant promotion, especially if RTFM was a firing offense.)

    > If sticking in an unfamiliar or HTML 4 Strict doctype causes tag-
    > soup expectations to fail in Netscape 5 or any other UA that adopts
    > a doctype-based switch (MacIE5 comes to mind, based on www-style
    > hints), then they won't use one.

    Are you predicting that they'll use doctypes guaranteed to evoke a tag
    soup response?

    > I seriously doubt whether any so-called HTML authoring tool is
    > cranking out tag soup and automatically using doctypes that will
    > produce undesirable results against David's proposed heuristics:
    > <http://www.people.fas.harvard.edu/~dbaron/tests/nglayout/doctypes.html>.

    Have you considered the possibility that an announced policy of
    sniffing doctypes could be the easiest road to marginalization?

    > And even if so, it should be easy to tweak.

    Note the comment about Quirks mode - that the list has to be
    comprehensive. See 'sea of troubles' above.



    > > Like it or not, 'quirks' mode is your only practical default.
    >
    > It's not practical - not for many applications requiring
    > predictable stylesheet/DOM stuff. That's the problem.

    No. The problem is divining such a requirement in Tag Soup. More
    generally, it's a *type assertion* problem which, never mind Tag Soup,
    existing "standards" don't provide for.

    > > How to trigger 'strict' mode is a problem for which as yet there's
    > > no good answer.
    >
    > Again, backwards:

    No, the corollary of the default. You may argue that this shouldn't
    be the default, but reforming 'text/html' is a quixotic quest.

    > it's how to know whether it will likely break if treated per spec.

    Simple. Assume it will. That's what 'text/html' *means*.



    > > Because 'strict' mode should - and will - be a matter of document
    > > authors actively asking for it
    >
    > Why shouldn't it be a matter of course?

    Because the matter of course assumes that a type assertion mechanism
    already exists. But it doesn't. What *should* be a matter of course
    is the use of such a mechanism *once* it's defined.


    :ar

    Arjun Ray

    unread,
    Jan 29, 2000, 3:00:00 AM1/29/00
    to
    On 30 Jan 2000 02:12:44 GMT,
    er...@netscape.com (Erik van der Poel) wrote:

    > When you suggested the use of a Processing Instruction or Marked
    > Section, was it your intention that the server would first check
    > the User-Agent request header to see what kind of browser it is,

    No, not at all. (Please don't get me started on *that* kind of
    sniffing!)

    My point was a general one: that no type assertion mechanism exists.
    So, one shouldn't try to read one out into the doctype declaration
    (for *any* type-related purpose.)

    Further, to date this basic *flaw* in the standards (SGML/XML) has
    been addressed in only one place: the SGML Extended Facilities (Annex
    A of ISO/IEC 10744), and the method involves the use of a PI. So,
    until something else also gets standardized, the only *standardized*
    type assertion mechanism is through a PI. Insofar as the Mozilla
    mode-toggle is based on reliable recognition of type, and positive
    assertion of type in the text/html quagmire is a rarity, it seems
    clear that the only thing that *should* be taken seriously is a PI
    *defined* for type assertion.

    > Or are you saying that the server should emit PIs or MSs regardless
    > of the browser type and version?

    Basically, yes, but there is a downside. First, of course, is that
    PIs have undesirable consequences in tag-slurpers, so their use
    involves the courage to have such processors crap out on their users.
    Huge disincentive. Also, the ArchUse PI actually serves a more
    general purpose (tied to type assertion, but in a wider context), so
    there other consequences of being prepared to recognize it - hence my
    caveat that this is for the short run.

    The marked section idea I haven't come to, and I hereby withdraw it -
    the kludge involved is much too elaborate.

    That said, David Baron's list of heuristics suggests another limited
    idea. It's limited because doctype declarations are now optional (if
    you want to keep up with the standards.) So, the *only* thing that
    might be taken seriously when a doctype declaration is present is an
    obvious *serious* use of it.

    An internal subset. Even a trivial one:

    <!DOCTYPE html PUBLIC "foo//bar" []>

    That still leaves the *type* determination unresolved, though. (No,
    repeat no, the FPI is not it.) Boil it down to this: reliable type
    assertion is based on a FPI with a public text class of NOTATION, not
    DTD.


    :ar

    Erik van der Poel

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to aray+...@nyct.net
    Arjun,

    When you suggested the use of a Processing Instruction or Marked
    Section, was it your intention that the server would first check the

    User-Agent request header to see what kind of browser it is, and then
    emit an "appropriate" stream, depending on the browser?

    For example, would the server only use the PI or MS if the User-Agent
    said Mozilla 5.0 (from mozilla.org, not MSIE's "compatible")?

    Or are you saying that the server should emit PIs or MSs regardless of
    the browser type and version?

    Erik


    Erik van der Poel

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to aray+...@nyct.net
    Arjun Ray wrote:
    >
    > An internal subset. Even a trivial one:
    >
    > <!DOCTYPE html PUBLIC "foo//bar" []>

    It seems like you have found good reasons to drop the PI and MS ideas,
    and that you are now seriously considering DOCTYPE.

    But I have a quite different question now. Is it really realistic to
    expect authors to produce documents that will work in both Nav4 and
    Mozilla's Standard Mode (not to mention the multiple versions of IE)?

    One of the nice things about Mozilla is that it has better support for
    HTML4 and CSS1 (and even some parts of CSS2). Of course, authors would
    love to be able to use those features in their documents, but would they
    work well enough in Nav4 (without looking bad or causing other trouble)?
    In particular, it has been said that Nav4 has poor support for CSS.

    I suppose authors could simply avoid using the CSS (and HTML?) features
    that are not implemented well in Nav4. They would effectively be
    limiting themselves to some subset of HTML/CSS. I'm wondering whether it
    makes much of a difference to trigger Mozilla's Standard Mode when the
    document itself is using such a subset. In other words, if the document
    is only using a subset of HTML/CSS, then it might as well "trigger"
    Mozilla's NavQuirks mode (i.e. it does not actively attempt to trigger
    Standard Mode).

    One trick that was discussed here a while ago was the use of the LINK
    element to refer to a CSS style sheet. If that LINK element is written
    in a special way (I forget the details), then Nav4 doesn't fetch the
    style sheet, but Mozilla does.

    This might be one way to avoid exposing Nav4's poor implementation of
    CSS, but then the HTML document itself would have to use some "poor
    man's" style mechanisms, such as <font size="-1"> (perhaps?), to get the
    document to look OK in Nav4. Since CSS specifies that "bad" things like
    <font size="-1"> have a specificity of zero, the CSS style sheet
    overrides the styles in the HTML document itself.

    Though this trick doesn't involve writing 2 different HTML documents
    (one for Nav4, one for Mozilla), it is pretty close, since the author
    must write the styles twice (once inside the HTML, once in the external
    CSS style sheet).

    Thoughts?

    Erik


    Arjun Ray

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to
    On 30 Jan 2000 06:13:21 GMT,
    er...@netscape.com (Erik van der Poel) wrote:
    > Arjun Ray wrote:

    > > An internal subset. Even a trivial one:
    > >
    > > <!DOCTYPE html PUBLIC "foo//bar" []>
    >
    > It seems like you have found good reasons to drop the PI and MS ideas,
    > and that you are now seriously considering DOCTYPE.

    No, I'm not. I'm trying to be fair to David's efforts: the only idea
    in that set of heuristics which has any merit is the presence of an
    internal subset, in that it suggests a constructive purpose to the
    doctype declaration being present at all. The empty subset hack isn't
    reliable, but in a text/html context, it just might be conventionally
    taken to mean "please take me seriously"; the downside is that this
    understanding must apply to *every* FPI, which means DTD-driven
    parsing (not the built-in heuristics in Mozilla's parser, but the
    *actual* DTD asserted; and not expat either, which only handles XML;
    you really don't want to do this for text/html.)

    Note: I'm discounting the XML declaration sniff, as it's a different
    universe. Besides, anyone prepared to use that should have no qualms
    using the *correct* PI!


    > But I have a quite different question now. Is it really realistic to
    > expect authors to produce documents that will work in both Nav4 and
    > Mozilla's Standard Mode (not to mention the multiple versions of IE)?

    Honestly, I don't know. You people are in a much better position to
    gauge the disconnect.


    > I suppose authors could simply avoid using the CSS (and HTML?)
    > features that are not implemented well in Nav4. They would effectively
    > be limiting themselves to some subset of HTML/CSS. I'm wondering
    > whether it makes much of a difference to trigger Mozilla's Standard
    > Mode when the document itself is using such a subset.

    If I follow you correctly, you're saying that there *is* enough of a
    disconnect, such that a document intended for both Nav4 and Mozilla's
    Standard mode is highly unlikely - specifically, that the *benefits*
    of Standard mode effectively preclude Nav4.

    > In other words, if the document is only using a subset of HTML/CSS,
    > then it might as well "trigger" Mozilla's NavQuirks mode (i.e. it
    > does not actively attempt to trigger Standard Mode).

    Again, I don't know. For instance, I don't see why CSS couldn't be
    applied to a HTML 2.0 document, so I'm not sure what "subset" really
    means here. The significant difference between HTML 4.0 and the older
    specs is script events. So, that's a DOM issue rather than HTML/CSS
    (and now, with BECSS, who knows, all events may get sucked out of the
    instance markup!)

    > Though this trick doesn't involve writing 2 different HTML documents
    > (one for Nav4, one for Mozilla), it is pretty close, since the author
    > must write the styles twice (once inside the HTML, once in the
    > external CSS style sheet).

    Not to mention all the <font size=1> crud.

    > Thoughts?

    Frankly, I'm against circumstantial hacks on principle. They have a
    way of biting, hard, in the longer haul. I'm not sure I follow the
    LINK hack (i.e. is there supposed to be some way to figure out "this
    CSS file is obviously not for Nav4" or equivalent?): it might work.
    But what about 404 Not Found?;)


    :ar

    Arjun Ray

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to
    On Fri, 28 Jan 2000 18:49:48 +0100,
    Jan Roland Eriksson <r...@css.nu> wrote:
    > On Fri, 28 Jan 2000 03:21:55 -0500, in netscape.public.mozilla.layout
    > Arjun Ray <ar...@nmds.com> wrote:
    > >

    > > <?IS10744:arch
    > > name = "html"
    > > public-id = "-//W3C//NOTATION HTML 4.01//EN"
    > > dtd-public-id = "-//W3C//DTD HTML 4.01//EN"
    > > ?>

    > But? Whatabaout that 'public-id'?


    >
    > First; it's not available yet, to the best of my knowledge.
    > So that PI would not fill much of any other purpose.

    True, in the sense that the W3C hasn't sanctioned that FPI. So, let's
    try another one:) The W3C claims that "Cool URIs Don't Change". Well
    then, they're going to find it awfully hard to repudiate the intent of
    this FPI:

    public-id = "+//IDN www.w3c.org//NOTATION 'TR/html401'//EN"

    See K.4.6 in the WebSGML TC:

    http://www.ornl.gov/sgml/wg8/document/1955.htm



    > Secnd; Was it not things like that, that was going to cause
    > a "heart attack" for some poor soul? :)

    The PI? Yes, the Emperor disdains PIs. So what? he hasn't blessed
    an alternative yet, either.


    :ar

    Jan Roland Eriksson

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to
    On Sun, 30 Jan 2000 04:02:41 -0500, in netscape.public.mozilla.layout
    Arjun Ray <ar...@nmds.com> wrote:

    >On Fri, 28 Jan 2000 18:49:48 +0100,
    >Jan Roland Eriksson <r...@css.nu> wrote:
    >> On Fri, 28 Jan 2000 03:21:55 -0500, in netscape.public.mozilla.layout
    >> Arjun Ray <ar...@nmds.com> wrote:

    >> > <?IS10744:arch
    >> > name = "html"
    >> > public-id = "-//W3C//NOTATION HTML 4.01//EN"
    >> > dtd-public-id = "-//W3C//DTD HTML 4.01//EN"
    >> > ?>
    >

    >> But? Whatabaout that 'public-id'?

    >> First; it's not available yet...

    >True, in the sense that the W3C hasn't sanctioned that FPI. So, let's
    >try another one:) The W3C claims that "Cool URIs Don't Change". Well
    >then, they're going to find it awfully hard to repudiate the intent of
    >this FPI:
    >
    > public-id = "+//IDN www.w3c.org//NOTATION 'TR/html401'//EN"
    >
    >See K.4.6 in the WebSGML TC:
    > http://www.ornl.gov/sgml/wg8/document/1955.htm

    Wow, that's genius :)

    I can put the correct info up somewhere at our site and roll my own
    'public-id' and 'dtd-public-id' based on css.nu I guess ?

    Erik van der Poel

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to aray+...@nyct.net
    Arjun Ray wrote:
    >
    > Erik van der Poel wrote:
    > >
    > > But I have a quite different question now. Is it really realistic to
    > > expect authors to produce documents that will work in both Nav4 and
    > > Mozilla's Standard Mode (not to mention the multiple versions of IE)?
    >
    > Honestly, I don't know. You people are in a much better position to
    > gauge the disconnect.

    I don't know either. The NavQuirks/Standard mode stuff was designed and
    implemented by others. It is possible to find out more about Mozilla's
    NavQuirks mode by investigating the following code:

    http://lxr.mozilla.org/seamonkey/search?string=GetCompatibilityMode

    However, this is a limited picture, because it only reveals the
    particular features that have already been implemented in Mozilla. It
    does not tell us very much about Nav4, MSIE4 and MSIE5.

    > If I follow you correctly, you're saying that there *is* enough of a
    > disconnect, such that a document intended for both Nav4 and Mozilla's
    > Standard mode is highly unlikely - specifically, that the *benefits*
    > of Standard mode effectively preclude Nav4.

    I don't know enough about the magnitude of the disconnect to say for
    sure. I'm just wondering whether the disconnect is that large.

    > For instance, I don't see why CSS couldn't be
    > applied to a HTML 2.0 document, so I'm not sure what "subset" really
    > means here.

    Nav4 implements some parts of CSS. Some of those parts are implemented
    well. I'm referring to that subset of CSS.

    I think you can say similar things about HTML4.

    > (and now, with BECSS, who knows, all events may get sucked out of the
    > instance markup!)

    Forgive me for asking yet another question: What is BECSS?

    > Frankly, I'm against circumstantial hacks on principle. They have a
    > way of biting, hard, in the longer haul.

    I know from bitter experience that hacks can bite hard in the long run.
    So I'd really like to know which particular circumstantial hacks you are
    referring to here. Are you talking about the LINK element hack that
    attempts to exclude Nav4? Or some hack(s) in Mozilla, that ought not to
    be there?

    > I'm not sure I follow the
    > LINK hack (i.e. is there supposed to be some way to figure out "this
    > CSS file is obviously not for Nav4" or equivalent?): it might work.

    I don't remember the details, and I don't care either. Ian Hickson and
    Braden McDaniel were involved in that discussion, and they may wish to
    say something here.

    > But what about 404 Not Found?;)

    The LINK hack does not involve User-Agent sniffing. But 404 might be a
    cleaner hack (less disgusting hack?).

    Erik


    Arjun Ray

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to
    On 30 Jan 2000 18:09:38 GMT,
    er...@netscape.com (Erik van der Poel) wrote:
    > Arjun Ray wrote:
    > > Erik van der Poel wrote:

    > It is possible to find out more about Mozilla's
    > NavQuirks mode by investigating the following code:
    >
    > http://lxr.mozilla.org/seamonkey/search?string=GetCompatibilityMode
    >

    > However, this is a limited picture, [...]

    Thanks. I'll take a look.

    > > (and now, with BECSS, who knows, all events may get sucked out of
    > > the instance markup!)
    >
    > Forgive me for asking yet another question: What is BECSS?

    Apparently, the folding of Netscape's Action Sheet proposal into CSS
    (the BE stands for "Behavorial Extensions to", I believe.)

    > So I'd really like to know which particular circumstantial hacks you
    > are referring to here.

    My empty internal subset heuristic (about the only thing I would
    consider, albeit briefly, sniffing in a doctype declaration.)

    > Are you talking about the LINK element hack that attempts to exclude
    > Nav4? Or some hack(s) in Mozilla, that ought not to be there?

    No. On the contrary, I'd like to find out what it involves. One
    downside that I see is that LINK seems to come too late in the parse
    (i.e. we're already past <html>, <head>, most likely <title>, and so
    on), but I'm no Mozilla code expert, so I have no idea whether this is
    really a problem. However, it could have the characteristic - the
    voluntary assertion of something distinctive - vital to what I would
    consider "decent" hacks.


    :ar

    Jerry Baker

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to
    Erik van der Poel wrote:
    >
    > I don't know enough about the magnitude of the disconnect to say for
    > sure. I'm just wondering whether the disconnect is that large.

    I can tell you that over in
    news://forums.macromedia.com/macromedia.dreamweaver that almost all of
    the posters are of the firm belief that Mozilla is going to break all of
    their hard work. They do not complain about specifics, but frequently
    mention that NS5 is going to break everything they have. Whether true or
    not, it represents a general apprehension of Mozilla by a subset of Web
    developers. I do not know whether Dreamweaver users constitute a
    represntative sample of Web developers or not.

    Jan Roland Eriksson

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to
    On 30 Jan 2000 18:09:38 GMT, in netscape.public.mozilla.layout

    er...@netscape.com (Erik van der Poel) wrote:

    >Arjun Ray wrote:

    >> Erik van der Poel wrote:

    >> (and now, with BECSS, who knows, all events may get sucked out of the
    >> instance markup!)

    >Forgive me for asking yet another question: What is BECSS?

    Don't get me wrong now, I'm in no way trying to be blunt, but aren't you
    and Vidur working for the same company?

    <URL:http://www.w3.org/TR/1999/WD-becss-19990804>

    Please don't get ideas from this now. It's bad enough already that MS
    has gone their own way, as in creating an "expression" syntax for how to
    specify CSS property values in IE5.5, and those MS-expressions looks
    very much like function calls into Jscript to me.

    At least let's keep Mozilla compliant to available CSS specs _only_

    Erik van der Poel

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to aray+...@nyct.net
    Arjun Ray wrote:
    >
    > On the contrary, I'd like to find out what it involves.

    The thread started with the following message:

    news://news.mozilla.org/Pine.GSO.4.04.10001151748490.10319-100000%40mary.bath.ac.uk

    > One
    > downside that I see is that LINK seems to come too late in the parse
    > (i.e. we're already past <html>, <head>, most likely <title>, and so
    > on), but I'm no Mozilla code expert, so I have no idea whether this is
    > really a problem.

    As far as I know, the LINK hack is not to trigger Standard Mode. It is
    to avoid sending a style sheet to Nav4.

    Erik


    Arjun Ray

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to
    On 30 Jan 2000 22:51:40 GMT,
    er...@netscape.com (Erik van der Poel) wrote:

    > news://news.mozilla.org/Pine.GSO.4.04.10001151748490.10319-100000%40mary.bath.ac.uk

    > As far as I know, the LINK hack is not to trigger Standard Mode. It
    > is to avoid sending a style sheet to Nav4.

    Yes, that's my reading too. So, with this special form of <LINK> all
    we know is that Nav4 will be shut out. One could suspect that the CSS
    is Nav4-incompatible, but is that enough to rule out Quirks mode? I
    don't think that's warranted.


    :ar

    Erik van der Poel

    unread,
    Jan 30, 2000, 3:00:00 AM1/30/00
    to aray+...@nyct.net
    Arjun Ray wrote:
    >
    > So, with this special form of <LINK> all
    > we know is that Nav4 will be shut out. One could suspect that the CSS
    > is Nav4-incompatible, but is that enough to rule out Quirks mode? I
    > don't think that's warranted.

    There may be some misunderstanding here. I only mentioned the LINK hack
    as a way to send CSS style sheets to browsers other than Nav4 (since it
    doesn't support CSS very well). I didn't mention the LINK hack as a way
    to trigger Standard Mode.

    Erik


    Braden N. McDaniel

    unread,
    Jan 31, 2000, 3:00:00 AM1/31/00
    to
    Erik van der Poel wrote:
    >
    > Arjun Ray wrote:
    > > I'm not sure I follow the
    > > LINK hack (i.e. is there supposed to be some way to figure out "this
    > > CSS file is obviously not for Nav4" or equivalent?): it might work.
    >
    > I don't remember the details, and I don't care either. Ian Hickson and
    > Braden McDaniel were involved in that discussion, and they may wish to
    > say something here.

    My understanding: if Nav4 sees a MEDIA attribute for LINK or STYLE with
    a value other than just "screen", it won't load/apply the stylesheet.

    --
    Braden N. McDaniel
    bra...@endoframe.com
    <URL:http://www.endoframe.com>

    starsunited

    unread,
    Jan 27, 2005, 11:32:27 PM1/27/05
    to
    what is the reason u feel tat way? is it because u have try n u have
    fail?
    Arjun Ray wrote:
    > On 27 Jan 2000 07:14:33 GMT,

    > er...@netscape.com (Erik van der Poel) wrote:
    > >
    > > There is a bug report that discusses what doctype should trigger
    > > Standard Mode:
    > >
    > > http://bugzilla.mozilla.org/show_bug.cgi?id=1312
    >
    > I read it, with growing dismay. The concept may appear workable, but
    > in reality it's utterly, comprehensively and totally bogus, perhaps
    > tragically so.
    >
    > The doctype declaration will not tell you what you need to know.
    That
    > isn't its job, anyway. The name nothwithstanding, the doctype thingy
    > is not about (declaring) document types. There might be people who
    > think that, or have learned that from somewhere, but sadly, they're
    > wrong; and at any rate, isolated instances of "sincere" use will be

    > swamped by the bogotic extrusions of FrontPage, Composer, wannabes
    and
    > &Deity; knows what else.
    >
    > Like it or not, 'quirks' mode is your only practical default. How to

    > trigger 'strict' mode is a problem for which as yet there's no good
    > answer. A lot of that has to do with inadequacy in the "official"
    > specs too. They don't *provide* for an answer (even though the
    Powers
    > That Be at the W3C actually think otherwise.)
    >
    > My suggestion? Make sure you support (a) Processing Instructions,
    and
    > (b) Marked Sections. Why? Because 'strict' mode should - and will -
    > be a matter of document authors actively asking for it, and so, as a
    > workaround, they might just use one of those syntactic devices to
    pass
    > Mozilla the right message *unambiguously*.
    >
    >
    > :ar

    Reply all
    Reply to author
    Forward
    0 new messages