NavQuirks vs Standard Mode, and XML
Jerry Baker
>
> 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
The presence of a doctype triggers standard mode.
-steve
Jerry Baker
What is standard mode? Strict or quirks? What doctype - all?
Erik van der Poel
- 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.
- 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'.
- 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
Erik van der Poel
>
> Steve Morrison wrote:
> >
> > The presence of a doctype triggers standard mode.
>
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
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
Mozilla is definitely not doing this now. See the whole thread about
<font> tags. This is occuring in dics with no declaration.
Jerry Baker
>
> 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
<!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
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
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
>
> 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
>
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
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
> 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
> "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
>
> 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
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
> 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
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
> 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
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
>
> 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
> > 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
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
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
>
> Erik van der Poel wrote:
> >
> > 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
> > 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
>
> 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
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
>
> 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
> 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
>
> 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
>
> > 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
fail?
Arjun Ray wrote:
> On 27 Jan 2000 07:14:33 GMT,
> > 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.
>
That
> is not about (declaring) document types. There might be people who
> think that, or have learned that from somewhere, but sadly, they're
> swamped by the bogotic extrusions of FrontPage, Composer, wannabes
and
> &Deity; knows what else.
>
> trigger 'strict' mode is a problem for which as yet there's no good
> specs too. They don't *provide* for an answer (even though the
Powers
> That Be at the W3C actually think otherwise.)
>
and
> 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
> Mozilla the right message *unambiguously*.
>
>
> :ar