Test suite
Matthew Brealey
RichInStyle.com test suite/system 'permanent', and it's at
http://www.richinstyle.com/test/.
There are about 2000 tests (generated from a web-interface database),
and you can enter the results for your browser using the menus provided.
Results pages are then generated via
http://www.richinstyle.com/php/results.php
Comments should be sent to me at webm...@richinstyle.com or wherever
else you feel fit.
Sent via Deja.com
http://www.deja.com/
Michael Nahrath
> Just thought you'd all like to know that I've made the new
> RichInStyle.com test suite/system 'permanent', and it's at
> http://www.richinstyle.com/test/.
Tfere can be no results of any relevance as long as those test pages do
not contain valid html.
Don't expect Mozilla or Mac IE5 to give their best as long as there is
no !DOCTYPE
See
<http://validator.w3.org/check?uri=http://www.richinstyle.com/test/color
/noncss.php> for an example.
Are you interested if browsers do things right or how good their
workarounds for displaying invalid code are?
Greeting, Michi
--
distributed.net contest's logfile-grapher
JavaVis 1.4 for MacOs released <http://nahrath.de/dnet/JavaVis/>
Beiträge zu HTML, CSS und Netzkultur <http://www.subotnik.net/>
Matthew Brealey
subo...@gmx.de (Michael Nahrath) wrote:
> Matthew Brealey <thel...@yahoo.com> wrote:
>
> > Just thought you'd all like to know that I've made the new
> > RichInStyle.com test suite/system 'permanent', and it's at
> > http://www.richinstyle.com/test/.
>
> Tfere can be no results of any relevance as long as those test pages
do
> not contain valid html.
>
> Don't expect Mozilla or Mac IE5 to give their best as long as there is
> no !DOCTYPE
That was deliberate. Why?
1. It's betterto have more bugs than less.
2. Whereas the CSS specification is a standard, doctype detection is
not. It is proprietary, so I can't test for it.
3. Most pages trigger tagsoup, so that's thew most useful way to
getresults.
Plus other reasons
Michael Nahrath
> > Don't expect Mozilla or Mac IE5 to give their best as long as there is
> > no !DOCTYPE
>
> That was deliberate. Why?
>
> 1. It's betterto have more bugs than less.
???
> 2. Whereas the CSS specification is a standard, doctype detection is
> not. It is proprietary, so I can't test for it.
If there is no doctype declaration your pages are (strictly spoken)
no HTML at all, but some kind of tag-soup.
<http://www.w3.org/TR/html4/struct/global.html#h-7.2>
Some say, that HTML without doctype declaration should be rendered as
HTML 2.
In this case CSS had to be ignored completely because neither the STYLE
element nor the STYLE attribute nor LINK REL="stylesheet" were defined
in HTML 2.
That is what "missing doctype detection" is for:
Rendering invalid pages (like yours) by doing quirky assumtions.
> 3. Most pages trigger tagsoup, so that's thew most useful way to
> getresults.
No. It makes testcase-results bogus.
Example: If a UA has only _one_ problem with your JavaScript code he has
no chance to succed in any CSS test.
The only result of souch "tests" may be:
"rendering is not what the author originaly intended if his code is
errorous".
But to find out this no tescases are needed.
Jeff Thies
> not contain valid html.
>
> Don't expect Mozilla or Mac IE5 to give their best as long as there is
> no !DOCTYPE
Do these browsers render any differently with a doctype than they do
without? Is there any browser that actually does something with the
doctype? Examples???
Jeff
Francesco Spreafico
> Do these browsers render any differently with a doctype than they do
> without? Is there any browser that actually does something with the
> doctype? Examples???
This site of mine ( http://digilander.iol.it/sgrizzo/ ) is rendered
slightly differently in NS6 because of the xhtml doctype declaration.
(The blue horizontal lines are thicker than in all other browsers or in
NS6 without doctype declaration)
I have no idea about how this renders on a Mac.
The code for the rule is:
<table width="100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td class="linea" width="100%" height="2" bgcolor="blue">
<img src="px.gif" width="1" height="1" border="0" alt="" />
</td>
</tr>
</table>
--
Francesco
Michael Nahrath
> nor LINK REL="stylesheet" were defined in HTML 2.
Sorry, this was wrong.
I just found out that it was at least mentioned in HTML 2.
Michael Nahrath
> > Don't expect Mozilla or Mac IE5 to give their best as long as there is
> > no !DOCTYPE
>
> Do these browsers render any differently with a doctype than they do
> without? Is there any browser that actually does something with the
> doctype? Examples???
Good morning!
<http://www.hut.fi/u/hsivonen/doctype.html>
Bjoern Hoehrmann
>> > http://www.richinstyle.com/test/.
>>
>> Tfere can be no results of any relevance as long as those test pages
>> do not contain valid html.
>>
>> Don't expect Mozilla or Mac IE5 to give their best as long as there is
>> no !DOCTYPE
>That was deliberate.
Nope, that was ill-considered. Without a given document type declaration
the HTML user agent must assume HTML 2.0 (as per RFC 1866 section 3.3).
HTML 2.0 does not define the style and class attributes you are using.
>1. It's betterto have more bugs than less.
It's counterproductive to call certain behaivours "bugs" if they are
enforced by bugwards compatibility and there is a valid way to enforce a
compliant behaivour.
>2. Whereas the CSS specification is a standard, doctype detection is
>not.
The HTML 4.01 Specification is a standard, you do not conform to it.
>It is proprietary, so I can't test for it.
Ah, you know, if you write valid strictly conforming HTML 4.01 pages
with a document type declaration like
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
you'd get less bugs. So I can translate
"It's betterto have more bugs than less"
with
"I'm cooler if I find more `bugs`"
Or what are you trying to tell us?
The missing document type declaration is of course not the only thing
that makes your pages invalid.
>3. Most pages trigger tagsoup, so that's thew most useful way to
>getresults.
"most pages" are irrelevant.
--
Björn Höhrmann ^ mailto:bjo...@hoehrmann.de ^ http://www.bjoernsworld.de
am Badedeich 7 ° Telefon: +49(0)4667/981ASK ° http://bjoern.hoehrmann.de
25899 Dagebüll # PGP Pub. KeyID: 0xA4357E78 # http://learn.to/quote [!]e
"It may be those who do most, dream most." -- Stephen Leacock
Alan J. Flavell
> (Michael Nahrath) wrote:
> > Don't expect Mozilla or Mac IE5 to give their best as long as there is
> > no !DOCTYPE
>
> That was deliberate. Why?
>
> 1. It's betterto have more bugs than less.
Is it? It depends what you're trying to achieve.
As an author, I'd rather know what the rules are, and follow them, and
_then_ take an interest in any remaining bugs. As such, I wouldn't
care what the browser did with garbage, 'cause I'm not going to feed
it any (at least, that's the plan, E&OE).
As a reader, I'm also kind-of interested to see whether browsers can
achieve some kind of rendering of the error-ridden garbage that is out
there on the WWW; but I'm not going to start whining if their error
fixup just happens to be a bit different from my ideal error fixup.
(But don't start me on MS's strategy of guessing where the CSS rules
mandate ignoring defective styles).
> 2. Whereas the CSS specification is a standard, doctype detection is
> not.
DOCTYPE detection in browsers isn't standardised, it's true; but if
you have one, you're following the standards.
> It is proprietary, so I can't test for it.
No Sir, the proprietary part is what those browser-like objects do
with non-standard stuff. And in this particular context, you put the
browser into its proprietary mode by NOT including a recognized
DOCTYPE.
In other words, what you are doing _IS_ testing proprietary features.
> 3. Most pages trigger tagsoup,
"Most" pages are garbage, as an afternoon's browsing with iCab would
make only too clear if you were in any doubt - and that goes only for
their HTML; but we're getting there, slowly.
> so that's thew most useful way to getresults.
"The best test of a finely-honed chisel would be to work on
some rough chipboard with a few nails in it." I think not.
Still, you must do what you think best.
cheers
Matt McIrvin
<thel...@yahoo.com> wrote:
I'm not sure that this is such a good idea; you should at least have
versions of the tests that have a modern DOCTYPE.
When CSS authors (good ones, at least) look at a bug list or a test suite,
they are trying to answer the question "Can I trust browsers to do what
they are supposed to with this feature, given a reasonably simple effort
on my part?" Putting in an HTML 4.01 DOCTYPE is a reasonably simple
effort. If you say that some feature is buggy because it breaks when
there's no DOCTYPE or an old DOCTYPE, many authors will throw the baby out
with the bathwater and not use it even when it could be used with
confidence.
It's true that DOCTYPE sniffing is not a standard, and you may be opposed
to it in principle; but the fact is that it's out there, we'd probably
have no good CSS support at all without it, and it's more useful to test
standards compliance in the mode where the browser is really trying.
I believe that if you put either an HTML 4.01 Strict DOCTYPE, *or* an
HTML 4.01 Transitional DOCTYPE *with a DTD URL*, on a Web page, today's
browsers that do DOCTYPE sniffing will go into standard mode. At least,
I know from experiment that this is true for IE5/Mac and Netscape 6
(though there are Web pages out there that say otherwise, and insist
that Strict is required; my experience is that this is false).
--
Matt McIrvin http://world.std.com/~mmcirvin/
Arjun Ray
"Alan J. Flavell" <fla...@mail.cern.ch> wrote:
| you put the browser into its proprietary mode by NOT including
| a recognized DOCTYPE.
There is no such thing as a "recognized DOCTYPE". That's the
fundamental fallacy of "doctype sniffing".
--
:ar
Jeff Thies
> > > no !DOCTYPE
> >
> > Do these browsers render any differently with a doctype than they do
> > without? Is there any browser that actually does something with the
> > doctype? Examples???
>
> Good morning!
>
> <http://www.hut.fi/u/hsivonen/doctype.html>
That's rather interesting, is there a difference beyond the height of
the line box? From what I read there it seems that Mac IE5 reads the
doctype but does then ignores it! I'm off to see what happens in NS6.
Jeff
Jeff Thies
> > without? Is there any browser that actually does something with the
> > doctype? Examples???
>
> This site of mine ( http://digilander.iol.it/sgrizzo/ ) is rendered
> slightly differently in NS6 because of the xhtml doctype declaration.
> (The blue horizontal lines are thicker than in all other browsers or in
> NS6 without doctype declaration)
> I have no idea about how this renders on a Mac.
>
> The code for the rule is:
>
> <table width="100%" cellspacing="0" cellpadding="0" border="0">
> <tr>
> <td class="linea" width="100%" height="2" bgcolor="blue">
I'm confused about that, apparently a line height of 2px does not yield
a line that is not 2 pixels tall!
> <img src="px.gif" width="1" height="1" border="0" alt="" />
Does the image yield different results than just putting in an nbsp; ?
> </td>
> </tr>
> </table>
Cheers,
Jeff
>
> --
> Francesco
Alan J. Flavell
> "Alan J. Flavell" <fla...@mail.cern.ch> wrote:
>
> | you put the browser into its proprietary mode by NOT including
> | a recognized DOCTYPE.
>
> There is no such thing as a "recognized DOCTYPE".
It's a fair call. I meant "one that is recognized by the browser for
this purpose".
I don't disagree that it's an unsatisfactory situation in the first
place, as well as being a suboptimal way of addressing it.
cheers
Michael Nahrath
> | you put the browser into its proprietary mode by NOT including
> | a recognized DOCTYPE.
>
> There is no such thing as a "recognized DOCTYPE".
We don't need that.
Either there is a _correct_ DOCTYPE or this document is either HTML2 or
no HTML at all.
> That's the fundamental fallacy of "doctype sniffing".
Basically there is no sniffing.
Its so simple:
If that document doesn't claim to follow to any standard it is not
reasonable for a browser to assume it would.
If the first line starts with an error (missing DOCTYPE) why assume the
rest is anything but tagsoup?
Francesco Spreafico
> Does the image yield different results than just putting in an nbsp; ?
Yes, the is taller (even if I set a font-size)
--
Francesco
http://heinlein.cjb.net - RAH in Italian
Francesco Spreafico
> <http://www.hut.fi/u/hsivonen/doctype.html>
I'd really like to see this, but the link doesn't seem to work (I tried
for a couple of days, in case the server was down, but still it doesn't
work)
Alan J. Flavell
> "Michael Nahrath" <subo...@gmx.de> ha scritto:
>
> > <http://www.hut.fi/u/hsivonen/doctype.html>
>
> I'd really like to see this, but the link doesn't seem to work
It redirected me to
http://www.hut.fi/~hsivonen/doctype.html
which displayed just fine.
Btw, if/when URLs disappear you can often find a cached copy at
Google, e.g
http://www.google.com/search?q=cache:www.hut.fi/u/hsivonen/doctype.html
Jan Roland Eriksson
comp.infosystems.www.authoring.stylesheets Bjoern Hoehrmann
<bjo...@hoehrmann.de> wrote:
[...]
>Nope, that was ill-considered. Without a given document type declaration
>the HTML user agent must assume HTML 2.0 (as per RFC 1866 section 3.3).
>HTML 2.0 does not define the style and class attributes you are using.
HTML2, i.e. rfc1866 has been rendered obsolete, see rfc2854 for info on
that. It seems to me that there is nothing to "fall back" on any longer.
>The HTML 4.01 Specification is a standard,...
Pedantically spoken it's not. It is an "Industry Consortium
recommendation" that happens to make a normative reference to the
international standard for SGML.
>Ah, you know, if you write valid strictly conforming HTML 4.01 pages
>with a document type declaration like
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
1) The HTML recommendation can not invalidate parts of the
ISO standard for SGML that it makes a normative reference too.
2) The ISO standard for SGML specifically allows for an SGML
document instance to be valid even without referencing an
external subset via a <!DOCTYPE... declaration.
That part entered the ISO standard with the web-SGML-TC a
couple of years back, under the part that describes the
concept of a "fully tagged document instance".
Conclusion: An HTML document can be syntactically valid even without a
<!DOCTYPE... declaration, regardless of what W3C happen to say in the
matter.
This subject, along with the subject of <!DOCTYPE... sniffing in
browsers, has been beaten to death in several earlier threads.
I would have guessed that every one had understood about it all by now.
--
Jan Roland Eriksson <jre...@newsguy.com> <http://member.newsguy.com/~jrexon/>
Moronization: a form of acculturation where people are encouraged to anoint
themselves with the supposed benefits of a technology, without understanding
the engineering (or lack thereof.)
Jan Roland Eriksson
comp.infosystems.www.authoring.stylesheets subo...@gmx.de (Michael
Nahrath) wrote:
[...]
>Either there is a _correct_ DOCTYPE or this document is either HTML2 or
>no HTML at all.
HTML2 is obsolete, sorry to say. See rfc2854 for details.
A <!DOCTYPE... declaration does not specify a "type" for the document
instance, there are other methods available that needs to be used to
assert correct types for documents.
[...]
>If the first line starts with an error (missing DOCTYPE) why assume the
>rest is anything but tagsoup?
A "missing <!DOCTYPE..." is not an error if the document instance is a
"fully tagged instance" as per SGML standards.
For as long as the HTML recommendation makes a normative reference to
ISO SGML, it's formally not allowed for HTML to "take away author
rights" given in that ISO standard.
Bjoern Hoehrmann
>>Nope, that was ill-considered. Without a given document type declaration
>>the HTML user agent must assume HTML 2.0 (as per RFC 1866 section 3.3).
>>HTML 2.0 does not define the style and class attributes you are using.
>
>HTML2, i.e. rfc1866 has been rendered obsolete, see rfc2854 for info on
>that. It seems to me that there is nothing to "fall back" on any longer.
The document is dated June 2000, I don't think browser developers had a
chance to implement this in current browsers and maybe they decide to
conform to RFC 1866 instead of RFC 2854.
>>The HTML 4.01 Specification is a standard,...
>
>Pedantically spoken it's not.
This depends on how you define "standard", my dictionary allows more
interpretations than yours, but ok, use ISO/IEC 15445:2000 then.
However, Matthew defined the CSS recommendation to be a standard...
>Conclusion: An HTML document can be syntactically valid even without a
><!DOCTYPE... declaration, regardless of what W3C happen to say in the
>matter.
I don't want to argue how you define "syntactically valid". The HTML
4.01 Recommendation defines clearly what a valid (or call it conforming)
HTML document is, and a document without a document type declaration is
not a valid/conforming HTML document (see section 7.2 and 19.1).
If the document is not a conforming document, you cannot demand the
behaivour you intended, only fallback and error recovery rules apply,
so the test pages are useless.
Arjun Ray
subo...@gmx.de (Michael Nahrath) wrote:
| Either there is a _correct_ DOCTYPE
Actually, the relation is the other way around - there is no such
thing as an _incorrect_ DOCTYPE, either - in that either the markup
conforms to the constraints declared in the document type declaration,
or it does not. In the latter case, what you have is a (formally)
invalid document, not an "incorrect doctype".
| or this document is either HTML2 or no HTML at all.
This is even trickier - meeting the syntactic constraints of a set of
declarations does not establish the HTML-ness of a document. (The
condition is at best necessary, and far from sufficient.) There is no
point in appealing to, say, Section 7.2 of the 4.01 spec, because what
it says there is utterly bogus from beginning to end (*including* the
disarming reference to ISO 8879, implying a paraphrase of a supposedly
normative interpretation). See, e.g.
http://www.deja.com/=dnc/getdoc.xp?AN=695655671
|> That's the fundamental fallacy of "doctype sniffing".
|
| Basically there is no sniffing.
Glad to hear it. I wonder, then, why some threads had to be as long
as they were in netscape.public.mozilla.layout, e.g. "Sniffing Doctype
Declarations is Bogus" (Jan '00) or "Standards or Reality" (Oct '00).
| If the first line starts with an error (missing DOCTYPE) why assume
| the rest is anything but tagsoup?
I have a better question. If something comes over the wire labelled
as Content-type: text/html, why on earth would you *not* assume that
it *is* Tag Soup?
--
:ar
Arjun Ray
| * Jan Roland Eriksson wrote in ciwas:
| >Conclusion: An HTML document can be syntactically valid even without a
| ><!DOCTYPE... declaration, regardless of what W3C happen to say in the
| >matter.
|
| I don't want to argue how you define "syntactically valid". The HTML
| 4.01 Recommendation defines clearly what a valid (or call it conforming)
| HTML document is, and a document without a document type declaration is
| not a valid/conforming HTML document (see section 7.2 and 19.1).
Well, you just "argued" anyway:)
The problem with this "argument" is that the 4.01 spec is *not* clear.
It would be clear if the reference to ISO 8879 were not normative.
(7.2 and 19.1 make such a complete hash of what ISO 8879 provides for
that it would be a tragedy were it not already a farce.)
This is distinct from people (e.g. implementors) *wanting* to take the
4.01 prose as being clear (if only to excuse them from having to read
and understand normative references) - they can get what they want by
petitioning the W3C to expunge the normative reference.
--
:ar
Eric A. Meyer
<cybe...@sprintmail.com> wrote:
<URL:http://www.meyerweb.com/eric/css/tests/doctype1.html>
<URL:http://www.meyerweb.com/eric/css/tests/doctype2.html>
I know the pages behave as advertised in IE5/Mac, with the text size
being the doubled size in the second test. These pages should also
behave that way in Netscape 6, although I can't immediately confirm that
for Windows; it works on the Mac.
Note that I use "works" in the sense of "behaves according to known
DOCTYPE-sniffing principles." By using that word, I am not attempting
to assert that this is the Ideally Pure Way to Fix the Web. Religious
arguments should be directed to the Office of Teleological Affairs down
the hall. Thank you.
--
Eric A. Meyer - er...@meyerweb.com - http://www.meyerweb.com/eric/
Author, "CSS: The Definitive Guide" http://www.oreilly.com/catalog/css/
Editor, Style Sheets Reference Guide http://style.webreview.com/
Coordinator, W3C CSS1 Test Suite http://www.w3.org/Style/CSS/Test/
Michael Nahrath
> In <1elsc3y.ir...@news.bk30.de>,
> subo...@gmx.de (Michael Nahrath) wrote:
>
> | Either there is a _correct_ DOCTYPE
>
> Actually, the relation is the other way around - there is no such
> thing as an _incorrect_ DOCTYPE, either -
Of couse there might be syntactically incorrect DOCTYPE declarations:
<!DOCTYPE find ich blöd//EN"
"http:/invalid.invalid">
but this is not the point here.
> in that either the markup
> conforms to the constraints declared in the document type declaration,
> or it does not. In the latter case, what you have is a (formally)
> invalid document, not an "incorrect doctype".
The point is: What should a user agent that actually needs to know what
kind of document he has to render, do if there is no declaration?
> | or this document is either HTML2 or no HTML at all.
>
> This is even trickier - meeting the syntactic constraints of a set of
> declarations does not establish the HTML-ness of a document. (The
> condition is at best necessary, and far from sufficient.) There is no
> point in appealing to, say, Section 7.2 of the 4.01 spec, because what
> it says there is utterly bogus from beginning to end (*including* the
> disarming reference to ISO 8879, implying a paraphrase of a supposedly
> normative interpretation). See, e.g.
You say, Section 7.2 is completely invalid because it contains a wrong
reference to ISO 8879. Do you think everything was clear and doctype
declarations where formaly neccesary for conforming documents if this
reference to ISO 8879 would have been left out?
If there stood just
|| A valid HTML document declares what version of HTML is used in the
|| document. The document type declaration names the document type
|| definition (DTD) in use for the document.
and if rec-html4 would define the syntax for the document declaration in
its own, everything was OK for you?
> http://www.deja.com/=dnc/getdoc.xp?AN=695655671
There you wrote:
|| Nowhere is a "document type definition" itself *named* - as Section
|| 7.2 of the HTML 4.01 spec would like you to believe that ISO 8879
|| "requires".
I can find no sentence in Section 7.2 that tries to make me believe that
document type definitions are requiered _by ISO 8879_.
For me the reference "(see [ISO8879])" just means:
"If you are interested in backgrounds and how _they_ did it, readinging
ISO 8879 might be interesting for you."
> |> That's the fundamental fallacy of "doctype sniffing".
> |
> | Basically there is no sniffing.
>
> Glad to hear it.
I still suppose that a document without HTML4 doctype can not be a
conforming HTML4 document.
So the first "sniffing" is just a basic validity test:
No doctype -> no valid HTML4 or better -> quirky rendering.
> I wonder, then, why some threads had to be as long
> as they were in netscape.public.mozilla.layout, e.g. "Sniffing Doctype
> Declarations is Bogus" (Jan '00) or "Standards or Reality" (Oct '00).
That is where decissions become arguable.
Why not trust a document that states to be
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ?
This is politics and AFAIKS nobody is realy happy with his decissions.
But this thread started about pages that use no doctype at all.
> | If the first line starts with an error (missing DOCTYPE) why assume
> | the rest is anything but tagsoup?
>
> I have a better question. If something comes over the wire labelled
> as Content-type: text/html, why on earth would you *not* assume that
> it *is* Tag Soup?
At least you should give it a try if the document claims to be no
tagsoupe by stating to which DTD it tries to conform.
Or did I oversee your smiley for this question?
Jan Roland Eriksson
comp.infosystems.www.authoring.stylesheets "Eric A. Meyer"
<er...@meyerweb.com> wrote:
[...]
> Note that I use "works" in the sense of "behaves according to known
>DOCTYPE-sniffing principles." By using that word, I am not attempting
>to assert that this is the Ideally Pure Way to Fix the Web.
Even less than optimal solutions has a tendency to become rigorously
permanent over time Eric, all in the name of not breaking "older pages
on the www".
>Religious arguments should be directed to the Office of Teleological
>Affairs down the hall. Thank you.
I once had hopes that I should be able to use the HTML capacity in two
of the best CSS capable browsers to render HTML docs set up for other
purposes both on and off the www. Doctype sniffing took that possibility
away, it has very little to do with religion in fact, but it has
something to do with my daily work.
OTOH, I find on the style list that Peter Linss is enthusiastically
working on introducing an HTTP Link header to pull in stylesheets.
I'm at this point not all up to date on what implications the following,
from HTML4.01 section 14.6, has on that...
This section only applies to user agents conforming to
versions of HTTP that define a Link header field.
Note that HTTP 1.1 as defined by [RFC2616] does not
include a Link header field (refer to section 19.6.3).
But if Moz is now planning to introduce a 'Link' extension HTTP header,
to stay compliant with HTTP1.1 (rfc2616 section 7.1), I find it a bit
sad to be so solidly bashed around by Moz QA as I have been, over a
similar suggestion to suggest rendering modes in browsers.
Arjuns suggestion of using a specific recognized CLASS attribute value
on stylesheet links may be another way to create something that would
"work", it's not without problems of course, but who knows...
But the question is moot at this point I guess, Opera is acceptable for
my purpose still, and for clients that I can convince to shell out the
required $800 for Multi-Doc Pro I can provide even better solutions.
--
Jan Roland Eriksson <r...@css.nu> .. <URL:http://css.nu/>
Arjun Ray
| Religious arguments
The issue isn't religion (except perhaps to some W3C luminaries.)
It's hypocrisy parading as highmindedness. The postulated SGML basis
of HTML has been an intellectually bankrupt exercise since 1993.
--
:ar
Arjun Ray
subo...@gmx.de (Michael Nahrath) wrote:
| The point is: What should a user agent that actually needs to
| know what kind of document he has to render, do if there is no
| declaration?
Actually, the point is: Yes, a user agent indeed needs to know, but
the document type declaration - despite the terminology - is not the
source of the answer, and it never has been!
Right now, the only source of information normally available to a user
agent is the HTTP Content-type header. That is, 'text/html' is the
only 'reliable' assertion of type. (Type assertion for SGML isn't
even addressed in ISO 8879 - the only solution standardized so far is
in ISO 10744.)
| You say, Section 7.2 is completely invalid because it contains a
| wrong reference to ISO 8879.
No. I'm saying that while 7.2 is claiming to paraphrase provisions in
ISO 8879, that claim is bogus. Not only is there nothing in ISO 8879
to justify the statements in 7.2, but also what ISO 8879 does say in
fact *contradicts* 7.2. This is an issue only because the 4.01 spec
references ISO 8879 normatively (i.e., that the relevant authoritative
statements are to be found in ISO 8879, not in the 4.01 spec).
| Do you think everything was clear and doctype declarations where
| formaly neccesary for conforming documents if this reference to
| ISO 8879 would have been left out?
Not quite. The significant reference to ISO 8879 is in
http://www.w3.org/TR/html401/references.html
This is what needs to be removed. Once it's gone, the prose of the
4.01 spec becomes authoritative by virtue of being a free-standing
definition of its concepts, terms and usages.
(Of course, why an ab ovo spec for HTML would ever need the mumbojumbo
of a doctype declaration is another matter. You do realize, I hope,
that it came into HTML only because some people thought it was needed
to SGML-ize HTML?)
| If there stood just
|
| || A valid HTML document declares what version of HTML is used in the
| || document. The document type declaration names the document type
| || definition (DTD) in use for the document.
|
| and if rec-html4 would define the syntax for the document declaration
| in its own, everything was OK for you?
In principle, yes. And, removing ISO 8879 from the 4.01 spec would
then require the spec to define *all* of its syntax formally (not just
the doctype declaration, but tags and everything else.) They should
have done this ages ago.
|> http://www.deja.com/=dnc/getdoc.xp?AN=695655671
|
| There you wrote:
|
| || Nowhere is a "document type definition" itself *named* - as Section
| || 7.2 of the HTML 4.01 spec would like you to believe that ISO 8879
| || "requires".
|
| I can find no sentence in Section 7.2 that tries to make me believe
| that document type definitions are requiered _by ISO 8879_.
The statement "A valid HTML document declares what version of HTML is
used in the document" is vacuous, because whatever means there might
be to achieve this, the doctype declaration is not it.
The statement "The document type declaration names the document type
definition (DTD) in use for the document" is utter nonsense, because
the document type declaration does no such thing.
Take it from there.
| For me the reference "(see [ISO8879])" just means:
| "If you are interested in backgrounds and how _they_ did it, reading
| ISO 8879 might be interesting for you."
No. Normative references most definitely are not mere "background":
they are required reading, by the definition of "normative". Consider
this excerpt from the guidelines on preparing IETF I-Ds:
( http://www.ietf.org/ID-nits.html )
: References in Internet Drafts
:
: When publishing an Internet Draft onto the standards track, are there
: any dependencies on documents that are still drafts and/or not standards
: track, or lower grade? Non-normative references are OK, but normative
: references (those that must be read and understood to correctly understand
: or implement the specification) to documentation that may not be readily
: available are not.
Note the significance of a normative reference:
[that which] must be read and understood to correctly understand or
implement the specification.
IOW, if a reference is normative, you are not excused from having to
read it, having to understand it, and being obliged to apply that
understanding as the *definitive* one - it is impossible to claim a
*normative* spec and then contradict it.
Clause 15.2.2 of ISO 8879 makes it authoritative on all matters of
syntax - applications, such as HTML tries to be, are not at liberty to
reinterpret or redefine SGML categories. The doctype declaration is
an SGML construct, and its meaning as per SGML is final.
You don't like this? No problem. Just get rid of the *normative*
reference to SGML. Note also that this is what was done with the XNL
spec: the reference to SGML had to be informative in order to let the
XML spec function as a free-standing and complete document (and in
places override ISO 8879 authoritatively.)
See also, e.g.
http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jun/0486.html
where the same established meaning of "normative" is invoked.
| Why not trust a document that states to be
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ?
Because that is *not* - repeat **NOT** - a statement of "being"!!!
This is not a type/identity assertion; in fact this is not even an
assertion at all. It's a statement to syntactically incorporate a set
of declarations (all those funny looking ELEMENT, ATTLIST and ENTITY
thingies) - none of which make any statement about or reference to a
type.
If the HTML spec wants to *invent* its own meanings for constructs
nominally "borrowed" from SGML, it should be honest in doing so.
--
:ar
Michael Nahrath
> I once had hopes that I should be able to use the HTML capacity in two
> of the best CSS capable browsers to render HTML docs set up for other
> purposes both on and off the www. Doctype sniffing took that possibility
> away, it has very little to do with religion in fact, but it has
> something to do with my daily work.
Sorry, I don't understand this.
AFAIK the doctype checking procedure is the same if the browser reads
its data via http:// as text/html or if it gets the data via file:///
George Lund
<ar...@nmds.com.invalid> writes
>In <1eluk1p.ccw...@news.bk30.de>,
>subo...@gmx.de (Michael Nahrath) wrote:
>| The point is: What should a user agent that actually needs to
>| know what kind of document he has to render, do if there is no
>| declaration?
>Right now, the only source of information normally available to a user
>agent is the HTTP Content-type header. That is, 'text/html' is the
>only 'reliable' assertion of type. (Type assertion for SGML isn't
>even addressed in ISO 8879 - the only solution standardized so far is
>in ISO 10744.)
>
>| You say, Section 7.2 is completely invalid because it contains a
>| wrong reference to ISO 8879.
>
>No. I'm saying that while 7.2 is claiming to paraphrase provisions in
>ISO 8879, that claim is bogus. Not only is there nothing in ISO 8879
>to justify the statements in 7.2, but also what ISO 8879 does say in
>fact *contradicts* 7.2. This is an issue only because the 4.01 spec
>references ISO 8879 normatively (i.e., that the relevant authoritative
>statements are to be found in ISO 8879, not in the 4.01 spec).
>
>| Do you think everything was clear and doctype declarations where
>| formaly neccesary for conforming documents if this reference to
>| ISO 8879 would have been left out?
>
>Not quite. The significant reference to ISO 8879 is in
>
> http://www.w3.org/TR/html401/references.html
>
>This is what needs to be removed. Once it's gone, the prose of the
>4.01 spec becomes authoritative by virtue of being a free-standing
>definition of its concepts, terms and usages.
Here's a hypothesis that is probably wrong but the argument has
presented itself to me and is thus is bugging me :-) ...
- The SGML specification does not (now) specifically require doctypes.
- Any particular application of SGML does not therefore necessarily
require the inclusion of a doctype.
However:
- Applications of SGML do sometimes make further requirements on
documents not expressible in pure SGML terms.
(An example would be the requirement in HTML that the HREF attribute
contain a URI. Just because it cannot be expressed in SGML does not mean
it can't be a part of HTML.)
- Therefore it is in order that HTML make a further requirement on
documents that they must contain a doctype declaration.
An SGML document is not an HTML document if it contains HREF attributes
that are not URIs. Similarly an SGML document is not an HTML document if
it does not have a doctype. It may be that neither assertion could be
tested using an SGML validator.
Now, if you have the time, please blow apart this argument. Probably in
terms of my not having understood normative references. Cheers.
--
George Lund
Jan Roland Eriksson
>Jan Roland Eriksson <r...@css.nu> wrote:
>> I once had hopes that I should be able to use the HTML capacity in two
>> of the best CSS capable browsers to render HTML docs set up for other
>> purposes both on and off the www....
>Sorry, I don't understand this.
>AFAIK the doctype checking procedure is the same if the browser reads
>its data via http:// as text/html or if it gets the data via file:///
I can see where your conclusion comes from, but sad to say you are
looking at the wrong thing, probably without knowing it, yet :)
Right now I just don't have either the time or energy to start all over
again. The case is sadly lost in relation to MacIE5 and the current
level of Mozilla, and I have lost my fighting spirit when it comes to
"dragons" and their doings, lets leave it at that, Ok?
But if you want to dig up some info on your own?
I saved the 17 (to me) most important posts from the thread "Sniffing
Doctype Declarations is Bogus" and another 48 from the thread "Standards
or reality" when they where on in 'netscape.public.mozilla.layout' some
time back. Both threads was bigger than that though.
There are sub-threads on the same topic in the w3 style-list archive and
some other parts of it has been beaten to death here in this NG too,
more than one time.
"Sniffing Doctype Declarations is Bogus" was one subject-line of
threads, let the future set the score on that statement, I don't care
much about it any more.
You may want to go hunting in archives and read for your self?
Michael Nahrath
> You may want to go hunting in archives and read for your self?
OK,
Steve Bowen
> behave that way in Netscape 6, although I can't immediately confirm that
> for Windows; it works on the Mac.
Just checked it with a Mozilla (Mathml-SVG-XSLT) enabled on a windows
machine and it behavior correctly with the Doctype and gave the expected
result with the with out Doc
Now if everyone would use Mozilla, the sight of a rounded paragraph is
wonderful ie: -moz-border-radius{20px 20px 20px 20px}
steve
Arjun Ray
| - The SGML specification does not (now) specifically require doctypes.
|
| - Any particular application of SGML does not therefore necessarily
| require the inclusion of a doctype.
Not quite. The doctype is a syntactic component of a SGML document.
The sense in which SGML makes this component optional (i.e. omissible)
is that there are situations where it may not add any information
needed for parsing.
This is where most people go wrong. They think that the doctype
declaration is there for semantic reasons - such as "declaring by name
the class to which the document belongs" - and they tend to cling to
this misapprehension because at a deep level they're right in thinking
that assertions of that kind would be very useful.
But actually its function is *syntactic* only: if the parser doesn't
need its contents, it can be left out. Whether a doctype declaration
is needed is not a semantic decision that an application would have to
resolve. It's only a syntactic circumstance determined by the markup
actually used in the document. This is a strictly SGML part of *any*
SGML application, and hence not within the purview of application
definitions (to "require" or "prohibit" as the case may be).
Also, please note that a doctype declaration need not have an external
subset. That is, the following three forms are SGML-wise semantically
identical by definition:
1. Syntactic-sugar form of external subset inclusion:
<!DOCTYPE foo PUBLIC "-//MyOrg//DTD FooML V99.99//EN">
2. Explicit use of parameter entity for external subset inclusion:
<!DOCTYPE foo [
<!ENTITY % foo-dtd PUBLIC "-//MyOrg//DTD FooML V99.99//EN">
%foo-dtd;
]>
3. Direct specification of contents instead of an external subset:
<!DOCTYPE foo [
<!-- all declarations here -->
]>
In the third form, there is no external identifier at all - rather
inconvenient for sniffing, no? (As a matter of fact, at one point
during the development of the XML spec, Dr. Goldfarb proposed getting
rid of the external subset syntax altogether, as too confusing in
practice, in "External Subset Considered Harmful"!)
| (An example would be the requirement in HTML that the HREF attribute
| contain a URI. Just because it cannot be expressed in SGML does not
| mean it can't be a part of HTML.)
Yes. Actually, SGML now allows you to express a little more. Instead
of handwaving with a parameter entity %Uri; expanding to 'CDATA', we
can associate a _data content notation_ with an attribute value:
<!NOTATION Uri PUBLIC "-//IETF/RFC 2396//NOTATION
Uniform Resource Identifiers (URI):
Generic Syntax//EN" >
<!ATTLIST link
href DATA Uri #REQUIRED >
| - Therefore it is in order that HTML make a further requirement on
| documents that they must contain a doctype declaration.
Clause 15.2 "Conforming SGML Application" says the following:
: If an SGML application meets the requirements of this sub-clause it
: is a conforming SGML application.
:
: 15.2.1 Application Conventions
: A conforming SGML application's conventions can affect only areas
: that are left open to specification by applications.
: NOTE - Some examples are: naming conventions for elements and
: entities, or a content convention that data characters not in the
: syntax-reference character set always be entered by references
: rather than directly.
:
: 15.2.2 Conformance of Documents
: A conforming SGML application shall require its documents to be
: conforming SGML documents, and shall not prohibit any markup that
: this International Standard would allow in such documents.
: NOTE - For example, an application markup convention could
: recommend that only certain minimization functions be used, but
: could not prohibit the use of other functions if they are allowed
: by the formal specification.
Note the "shall not prohibit" part. The range of variation *allowed*
goes into the specifics of the SGML declaration (e.g. an application
can specify SHORTTAG NO to rule out many minimizations; and until the
recent unbundling of the SHORTTAG option, an application could *not*
say SHORTTAG YES and prohibit NET minimization.)
Nowhere in the SGML declaration is there an option that would allow an
application to control the *form* of a doctype declaration, which is
the *real* issue in the HTML specs. (See the three forms above: the
HTML specs want to enforce 1 while prohibiting 2 and 3.)
To repeat: the issue for the HTML specs and the doctype-sniffers is
not whether there should be a doctype declaration at all, but how to
rig things such that it can take only one particular form. All the
bullshit about "interoperability", "version information" and whatnot
is just about that.
| An SGML document is not an HTML document if it contains HREF
| attalsributes that are not URIs.
This is a content convention/requirement and up to the application to
specify.
| Similarly an SGML document is not an HTML document if it does not
| have a doctype.
This is a *syntax* convention/requirement, the permitted variations in
which are specified by SGML and fixed in the SGML declaration by the
application. There is no scope to constrain the form of a doctype
declaration.
To repeat: the issue for the HTML specs and the doctype-sniffers is
not whether there should be a doctype declaration at all, but how to
rig things such that it can take only one particular form. That is,
to *invent* a homegrown meaning for the doctype, in effect explaining
why it's there.
That's very simple to legitimize: just drop the normative reference to
ISO 8879. (THis would also mean retiring validator.w3.org, btw.)
--
:ar
Jan Roland Eriksson
comp.infosystems.www.authoring.stylesheets Steve Bowen
<skee...@netscape.net> wrote:
[...]
>Now if everyone would use Mozilla, the sight of a rounded paragraph is
>wonderful ie: -moz-border-radius{20px 20px 20px 20px}
Wonderful, just wonderful :>
I specifically remember that I asked Moz QA in a thread, why we could
not have some browser specific property recognized to propose a
rendering mode select. The reply was not very encouraging of course.
http://lists.w3.org/Archives/Public/www-html/2000Jul/0108.html
And now this... '-moz-border-radius{20px 20px 20px 20px}'
Phui... gimme a break will you all, in the light of this quote from the
URL above...?
LOL! That's as bad as (2) and (3) above. "You want us to
comply to standards? Well add this magic, NON-STANDARD
property to your stylesheets..."
It sort of explains why I never got an answer to my question on if it
was planned to take out all those little -moz- thingies before the final
release.
And yes, I have read Eric's article about why it's supposed to be
necessary for implementors to "test new things". I respect his words,
but I don't agree that test-implementation has to come before public
suggestion and discussion.
The current "process" works backwards, in my eyes.
Eric A. Meyer
Eriksson <jre...@newsguy.com> wrote:
> And yes, I have read Eric's article about why it's supposed to be
> necessary for implementors to "test new things". I respect his words,
> but I don't agree that test-implementation has to come before public
> suggestion and discussion.
I think you've misinterpreted what I wrote-- although that could be
due to a lack of clarity in my writing. The article was intended to
describe things as they are now, and the conclusion I reach at the end
of the article is that the process needs to be fixed. What a
coincidence-- you reached the same conclusion! The whole scenario of
field-testing solutions before making them standards is part of the W3C
process. In fact, they've recently formalized that very process. I'm
not trying to defend that arrangement, but to describe it in detail for
all the world to see.
Now, we may (or may not) disagree on the best method to fix the
problem, but I think we both agree that there is a real problem. And I
think if the article's conclusion is read closely, you can see that I
say so. I tossed about some potential changes, but avoided taking a
stand on any one of them simply because I'm not qualified to say "This
is the best fix." My secret hope was that those who ARE qualified would
read the article and make concrete proposals to fix things. I've
generally found that the W3C is willing to listen to serious ideas for
change, even if they don't necessarily adopt them, and interested in
serious discussion of the problems.
For those who are wondering what article we're talking about, you can
find it here:
<URL:http://hotwired.lycos.com/webmonkey/98/38/index1a.html>
Bear in mind it was written more than two years ago, so a few references
may be dated. I still stand behind the main point of the article,
though.
George Lund
<ar...@nmds.com.invalid> writes
(snip fantastic explanation which was just what I was after)
>That's very simple to legitimize: just drop the normative reference to
>ISO 8879. (THis would also mean retiring validator.w3.org, btw.)
So (correct me if I'm wrong) the argument is that doctype sniffing is a
bad thing so we would not actually necessarily want to legitimize it by
doing the above. (Surely if doctype sniffing *were* to be legitimized
then validation would become even more important? I may now have lost
the plot.)
However, all this doesn't stop validators being darn useful tools for
authors, and putting a doctype in suggests at least that the author has
thought about inter-operability. Inter-operability matters because HTML
isn't just any old SGML that can be rendered using an appropriate style
sheet, but might be interpreted 'tag soup' style using some other method
altogether. Or perhaps the very fact that HTML is an SGML app. means
that the 'style sheets and SGML parsing' model (whatever style language)
is the only proper way to build a browser. But there's some things (like
OBJECT, I'd suggest) that just aren't amenable to that approach.
I'd like some sort of language where you could have proper subclassing
of elements - ('ordered-list "is-a" or "extends" list; 'paragraph "is-a"
block' &c.) which as far as I know isn't XML or SGML. (I can hear now
'well if you're interested then why haven't you read the SGML
specification then' :-)
Cheers, and "woops aren't we off topic now"
--
George Lund
Jan Roland Eriksson
comp.infosystems.www.authoring.stylesheets "Eric A. Meyer"
<er...@meyerweb.com> wrote:
>In article <p5404t4s8hgpj1lpm...@4ax.com>, Jan Roland
>Eriksson <jre...@newsguy.com> wrote:
>
>> And yes, I have read Eric's article about why it's supposed to be
>> necessary for implementors to "test new things". I respect his words,
>> but I don't agree that test-implementation has to come before public
>> suggestion and discussion.
>
> I think you've misinterpreted what I wrote-- although that could be
>due to a lack of clarity in my writing.
Or may be in combination with the fact that english is not my native
language?
(you don't want to know how often I find my nose buried in a dictionary
when I'm really trying to understand what gets written in some places,
and my news client has a very good spell checker, so don't be fooled by
my posts either :)
>The article was intended to describe things as they are now,
>and the conclusion I reach at the end of the article is that
>the process needs to be fixed.
>What a coincidence-- you reached the same conclusion!
I'm just glad that we can agree...
>The whole scenario of field-testing solutions before making them
>standards is part of the W3C process. In fact, they've recently
>formalized that very process.
Yes, I know, and personally I think it's sad, really.
> Now, we may (or may not) disagree on the best method to fix the
>problem, but I think we both agree that there is a real problem.
Yup...
>And I think if the article's conclusion is read closely, you can
>see that I say so.
On a second read (with the dictionary within reach:) yes...
>I tossed about some potential changes, but avoided taking a
>stand on any one of them simply because I'm not qualified to
>say "This is the best fix."
IETF's RFC procedures has been proven, and reached a lot of good
mileage. Something could be picked up from there maybe?
>My secret hope was that those who ARE qualified would read the
>article and make concrete proposals to fix things. I've generally
>found that the W3C is willing to listen to serious ideas...
Maybe, but the downside is that even the most honest and knowledgable
member in a WG can only be allowed to be just so much of an idealist, if
s/he wants to receive the next paycheck from his/her employer, the same
employer that pays the W3C membership fee.
> For those who are wondering what article we're talking about, you can
>find it here:
>
> <URL:http://hotwired.lycos.com/webmonkey/98/38/index1a.html>
>
>Bear in mind it was written more than two years ago, so a few references
>may be dated. I still stand behind the main point of the article,
>though.
It's still a good article, no debate needed about that.
Every one interested in how new ideas eventually enters into
"standards", go read it.
P.S.
About public insight in W3C processes...
I personally find it a bit ridiculous that I can easily afford to become
a supporting member of OASIS out of my own private valet, while a
similar status at W3C calls for, at least a minor win, on the lottery.
Here in Sweden, such a principle is thought of as "discrimination".
We had a popular Swedish writer at one time, that formulated this "money
rules" principle like this...(in a free translation)
"It's a shame, and a stain, on the banner of Sweden,
that citizenship is named money."
...from the olden days, when the right to vote for government, was given
only to those backed up with a sufficient level of wealth.
Arjun Ray
In <p9zGciAo...@ntlworld.com>,
George Lund <G.A....@bigfoot.com> wrote:
| In article <29vv3tgnic33pnuf4...@4ax.com>,
| Arjun Ray <ar...@nmds.com.invalid> writes
|> That's very simple to legitimize: just drop the normative reference
|> to ISO 8879. (THis would also mean retiring validator.w3.org, btw.)
|
| So [...] the argument is that doctype sniffing is a bad thing
In that it's an attempt to institutionalize a misapprehension. Not
only is this likely to inhibit *correct* use/interpretation of an SGML
construct, it also obscures the fact that a genuine problem - that of
reliable type assertion - is still in need of a solution. It's like
insisting that your lost wallet must be under the lamppost because the
light is better there.
| so we would not actually necessarily want to legitimize it by doing
| the above.
It's a little bit more complicated than that. Mosaic tore HTML away
from whatever SGML roots it might have had, and that was a long time
ago. Since then one question has always been "Why SGML at all?". The
answer is that SGML is an international standard - and from this fact
a derivative spec would gain considerable cachet: a grounding in work
guaranteed to be stable. Without such a feather in the cap, the HTML
spec need be no better than a homebrewed concoction, that no one need
have a *reason* to take seriously. In fact, this is why the normative
reference to ISO 8879 will stay (the specs *need* that intellectual
legitimacy), even if it means having to jump through hoops with all
sorts of 'conventions' and circumlocutions. W3C canon has now made a
virtue of this "necessity" by having postulated unto themselves that
it is legitimate to cite a normative reference and then arbitrarily
override it (in order to "justify" exigencies, naturally).
IOW, the W3C has basically invited implementors to view the situation
as legitimized *already*: all that's left a-wanting is fait accomplis.
I think this "methodology" on the part of the W3C - as exemplified by,
say, 7.2 of the 4.01 spec - is best described by the fifth paragraph
from the end of:
http://www.mit.edu/people/grainer/frankfurt.html
| However, all this doesn't stop validators being darn useful tools
| for authors,
Only to the extent that they might want to take the SGML formalism
seriously. What goes on the wire as 'text/html' is determined largely
by the capabilities of implementations that authors are *aware* of,
and Gresham's Law ensures that the cheapest medium will prevail. It
is *costly* to go through the process of being "conservative in what
you send".
| and putting a doctype in suggests at least that the author has
| thought about inter-operability.
I doubt this could be infered from the mere presence of a doctype
declaration. There are plenty of "HTML editors" out there that insert
sufficiently impressive looking mumbojumbo at the top because uh, "the
spec sez you gotta have somethin kinda sorta like that".
| Or perhaps the very fact that HTML is an SGML app. means that the
| 'style sheets and SGML parsing' model (whatever style language) is
| the only proper way to build a browser.
In general, yes. Tag Soup loses the plot, big time.
| I'd like some sort of language where you could have proper subclassing
| of elements - ('ordered-list "is-a" or "extends" list; 'paragraph
| "is-a" block' &c.) which as far as I know isn't XML or SGML.
You're right, it isn't. In fact, I would say that the analogy with
programming languages that often motivates the need for "subclassing"
is a fertile source of conceptual errors:)
Rather than subclassing, the need is for annotation. The element
hierarchy in a structured document is only one "possible view", albeit
the one chosen by the author. It is normal for the *content* to be
classifiable under more than one taxonomy simultaneously - i.e for
other possible structured views to be legitimate. We accomplish this
by - what else? - adding markup: typically attributes.
<ordered-list is-a="list">...</ordered-list>
(Note that you can mark this #FIXED in an ATTLIST declaration and thus
obviate the need for explicit markup in the document instance.)
The (platonist or "ontological") trap to avoid is thinking of an
element as a "thing" - it's actually an abstraction, just as the
non-terminals of a grammar are abstractions used to *structure* the
terminals making up the content - and hence with a "fixed nature". It
only means what you've designed it to mean, so all that matters is
whether you've left yourself the room to add to the meanings you find
useful.
--
:ar
Jukka Korpela
>So (correct me if I'm wrong) the argument is that doctype sniffing is a
>bad thing so we would not actually necessarily want to legitimize it by
>doing the above.
Arjun's point was based on general principles, and it's hard to argue
against (though people may wish to argue if they don't understand those
principles). My point is a more practical one: The doctype sniffing just
gets things wrong most of the time. Most Web pages don't use doctypes,
or use wrong doctypes. It would be rather unsound to assume that pages
that use some specific doctype are in general more suitable for
"standards conforming" presentation than other pages.
Assuming that a browser wanted to be "compatible" with some other
browsers in questionable or incorrect display of some constructs and
still be able to display documents correctly, there would be two
sensible approaches, and neither of them involves a doctype:
a) look at some pseudo-comment in the source (something that is a
comment in HTML terms but complies with some convention you just
invented)
b) obey user's instructions.
>(Surely if doctype sniffing *were* to be legitimized
>then validation would become even more important?
No, validation would still just check the syntax - or it would not be
validation.
>However, all this doesn't stop validators being darn useful tools for
>authors
Against casual typos, yes. But in order to work properly with CSS, an
HTML document needs to be stricter than Strict. I know one can achieve
that by complying with XHTML, but personally I'd just feel stupid if I
scattered those foolish "/"s around. If desired, one could take an
HTML 4 doctype and edit it a little to make all end tags required.
--
Yucca, http://www.hut.fi/u/jkorpela/
Qui nescit tacere nescit et loqui