Marquee For Firefox

[Ben C]

W3C DTDs _are_ "more equal", because they can be referred to by a
doctype declaration that also triggers a standards-based rendering
mode. AFAIK, there's no way to have a custom DTD (a legit SGML
feature) and to _also_ trigger standards rendering (highly HTML-
related and specific to the world of "web browsers" alone).

Well, Mr K. said that a custom DTD does give you strict mode.

I just tried this and he's right. I got strict mode in Opera, Konqueror
and Firefox with a custom doctype.

 

[Jukka K. Korpela]

Scripsit Ben C:

- -
They're equal in those terms. It was your parenthetical remark I was
disagreeing with.

I find that strange, since the parenthetic remark is just an attempt at
a humorous clarification of something that was said previously; it does
not add any new factual statement.

But what is the purpose of validation?

I think I already answered that: to avoid some stupid mistakes.

Often because you intend to use
your markup as the input to some computer program one of whose implied
preconditions is that its input consist of a valid document according
to one or other from a set of particular DTDs.

You're trying to refer to browsers, aren't you? But you're not actually
describing how they behave.

Please explain.

Try it. Use different DTDs and see how much browsers care.

My understanding of a modern browser is basically
this:

1. The HTML is parsed and the result is a DOM tree.
2. The DOM tree is rendered according to the CSS specification (taking
into account any styles you set).
3. The DOM tree can be further manipulated by JS.

That's an idealistic description, but let's suppose that browsers really
do that. Now where does the DTD or validation come into the picture?

I just tried P inside SPAN in Firefox out of interest and it just
gives me a DOM tree containing a P inside a SPAN, so nothing
unpredictable there. Not a good example then.

So it really couldn't care less about the DTD, could it? A more advanced
browser could infer a missing </span> tag when it encounters a <p> tag
and a SPAN element is open, but this is a quality issue, about error
handling quality.

Here is a better one:

<table>

Tables aren't a good example of anything in this area, since tables are
processed in quite idiosyncratic ways, with lots of adhockery and
kludgery.

<tr>
<span>hello</span>

That's one of those stupid mistakes that validators catch. I think we
have no disagreement on that.

Now, if I didn't validate, I might expect to get this DOM tree
(fragment):

Whether you validate or not, it's a mistake and, in practice, results on
"hello" thrown in into the presentation in some odd place, probably
before or after the entire table. That's because browsers have been
"hard-wired" to process table markup in specific ways.

Of course this implies that you should use markup that meets browsers'
expectations, and validation may help you there. But _any_ DTD will do,
as long as the language described by it meets those expectations. You
don't have to use a specific W3C DTD for that (still less a specific
doctype declaration, even though the HTML 4.01 and XHTML 1.0
specifications prescribe that here are the three doctypes among which
thou shalt choose)

In fact, using a non-W3C DTD is _better_ for such purposes as well. The
reason is that browsers may get wild if some end tags that are omissible
according to HTML 4.01 DTDs are omitted. It can thus be useful to make
the end tag required in your DTD. (Using XHTML 1.0 DTD would solve this
in a different way, but the most popular browser is really not prepared
to XHTML, even though it can deal with XHTML written according to
Appendix C, but does this make much sense? You _don't_ have to use XHTML
1.0 just because you want to close all elements explicitly.)

 

[Toby A Inkster]

W3C DTDs _are_ "more equal", because they can be referred to by a
doctype declaration that also triggers a standards-based rendering mode.
AFAIK, there's no way to have a custom DTD (a legit SGML feature) and to
_also_ trigger standards rendering (highly HTML- related and specific to
the world of "web browsers" alone).

You are wrong. In fact, the opposite of what you say is true. There is no
way for a custom DTD to trigger quirks mode -- they *always* trigger
standards mode.

Custom DTDs are very useful. I have used them on at least two sites. There
are various elements out there that although never part of any standard,
are widely supported and can be quite useful. Good examples are <NOBR> and
<CANVAS>.

If you decide that you indeed want to use such elements (which is a
decision that needs some thought -- you need to consider whether their
usefulness outweighs the drawback that they won't have 100% browser
support; though such decisions need to be made with regards to standard
HTML elements too: e.g. <ABBR> in Internet Explorer 6) then you probably
don't want to be told about them every time you validate your pages.

But you still want to be able to use validation as a tool, because it
catches some of your slip-ups, such as elements you forgot to close,
forgot to open, or nested incorrectly, or perhaps alt attributes that you
forgot. So the solution is to write a DTD which allows your deliberate
deviations from W3C HTML to pass through, but catches your errors.

One of the times I used a custom DTD was to create a version of HTML which
was a proper subset of W3C HTML 4.01 Transitional, but a superset of W3C
HTML 4.01 Strict. I decided that I wanted to use the "start" attribute for
ordered lists, and I wanted the <U> element. But I didn't want any of the
other sloppy transitional stuff.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 22:33.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[rf]

Scripsit Ben C:

Besides, if you try to nest a P inside a SPAN, things will go wrong in
browsers quite independently of the DTD you declare and independently of
validation.

FFS that is what you are arguing *for* in this thread, isn't it? . Make up
your own DTD?

Now you say that if I make up my own DTD then browsers may break my page?

That is exactly what dorayme has been arguing. The only DTD's that are
viable in the wild are those provided by the W3C, not one of yours that may
have whatever you want in it.

I think you just argue for the sake of seeing your own words in print.
Bloody dipstick!

 

[Toby A Inkster]

One of the times I used a custom DTD was to create a version of HTML
which was a proper subset of W3C HTML 4.01 Transitional, but a superset
of W3C HTML 4.01 Strict. I decided that I wanted to use the "start"
attribute for ordered lists, and I wanted the <U> element. But I didn't
want any of the other sloppy transitional stuff.

PS: Another application is to actually *tighten up* HTML 4.01 Strict.

For example, in HTML 4.01 Strict, the <html>, <head> and <body> tags (both
opening and closing) are *optional*. If you know that your HTML is going
to be processed by some user-agent (in this case, not a browser, but
probably some kind of poorly-written script) which needs to find explicit
<html>, <head> and/or <body> tags, then your DTD could make them into
required tags.

Similarly, if you think that the use of the <b> and <i> elements are never
justified, and that you should always use <em> and <strong> instead, you
can just find all the places where they're allowed content, and ban their
use.

Also, perhaps you need to support Netscape 4.x for some reason. Then you
might want to make the </td> and </tr> tags required instead of optional.

If you want to *really* improve the markup quality of your data tables,
you could make the "summary" attribute and <caption> element required;
enforce use of <thead>, <tfoot> and <tbody> by banning <table> from
directly containing any <tr> elements; and make the "scope" element of
<th> required.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 23:53.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Ben C]

Scripsit Ben C: [...]

My understanding of a modern browser is basically
this:

1. The HTML is parsed and the result is a DOM tree.
2. The DOM tree is rendered according to the CSS specification (taking
into account any styles you set).
3. The DOM tree can be further manipulated by JS.

That's an idealistic description, but let's suppose that browsers really
do that. Now where does the DTD or validation come into the picture?

At the first of those three stages. Only if the HTML is valid can you
reasonably expect to get the correct DOM tree.

So it really couldn't care less about the DTD, could it?

That doesn't follow. Valid input is sufficient for particular correct
output, not necessary.

It's if I wrote valid input, and did not get the correct DOM tree, that
I would file a bug report.

[...]

Tables aren't a good example of anything in this area, since tables are
processed in quite idiosyncratic ways, with lots of adhockery and
kludgery.

That's exactly the point I'm making: if the input is invalid anything
might happen, and anything includes adhockery and kludgery. It is a good
example.

Browsers produce the proper DOM tree from valid table markup. If you can
give me an example of when they don't (excluding IE) I will be
interested to hear it.

The way tables are _rendered_ is only incompletely specified in both
HTML and CSS, but that isn't relevant here.

That's one of those stupid mistakes that validators catch. I think we
have no disagreement on that.


Whether you validate or not, it's a mistake and, in practice, results on
"hello" thrown in into the presentation in some odd place, probably
before or after the entire table. That's because browsers have been
"hard-wired" to process table markup in specific ways.

Of course this implies that you should use markup that meets browsers'
expectations, and validation may help you there.

Yes, that is exactly what I have been trying to say.

But _any_ DTD will do, as long as the language described by it meets
those expectations. You don't have to use a specific W3C DTD for that
(still less a specific doctype declaration, even though the HTML 4.01
and XHTML 1.0 specifications prescribe that here are the three
doctypes among which thou shalt choose)

In fact, using a non-W3C DTD is _better_ for such purposes as well. The
reason is that browsers may get wild if some end tags that are omissible
according to HTML 4.01 DTDs are omitted. It can thus be useful to make
the end tag required in your DTD.

Interesting.

 

[Toby A Inkster]

Jukka K. Korpela write:


FFS that is what you are arguing *for* in this thread, isn't it? . Make
up your own DTD?

It is not at all what Jukka is arguing for. Or not how I read it at least.

Making up your own elements and attributes willy-nilly and nesting
elements in crazy ways doesn't make any sense because they won't be
supported in real-world browsers, DTD or no DTD.

However. there are a number of elements (e.g. <nobr>), attributes (e.g.
<body margintop="0">) and nesting combinations (e.g. <input> directly
inside <form>) which are supported in all, or virtually all browsers.

Although many of these proprietary constructions are best avoided, or can
achieved using CSS instead, in some situations, one might deem it
appropriate to use such markup. In these cases, it can be useful to create
your own DTD to validate against, which permits your deliberate markup
deviations, but enables you to use validation as a tool for catching
coding slip-ups.

That, I believe, is the point that Jukka is trying to make. And it's
something that I agree with, have used on occasions in the past, and would
not hesitate to use again.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 6 days, 2:00.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Jukka K. Korpela]

Scripsit Ben C:

At the first of those three stages. Only if the HTML is valid can you
reasonably expect to get the correct DOM tree.

No, the results of parsing depend on the parser of the browser. It does
not apply a DTD there. You can check this by using different DTDs for
the same document and observing - no effects.

That's exactly the point I'm making: if the input is invalid anything
might happen, and anything includes adhockery and kludgery. It is a
good example.

No, you are missing the point. The point is that browsers behave that
way, independently of DTD and independently of validity. If the markup
is too different from what browsers expect, disaster will follow. Using
markup that conforms to W3C specifications tends to increase the odds of
matching browser expectations, but they are not the same thing at all,
and the specific DTDs are irrelevant here.

For example, if I replace the DTD fragment

<!ELEMENT TABLE - -
(CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>

by

<!ELEMENT TABLE - -
(CAPTION, THEAD, TBODY)>

then I'm simply defining a table model that is more restricted than the
W3C model, and this makes perfect sense if I intend to use the
restricted model. There's no magic or esoteric about this, even though
most authors have no idea of such possibilities (partly because HTML
specifications explicitly discourage it by requiring the use of specific
doctype declarations).

 

[Bone Ur]

Well bust mah britches and call me cheeky, on Thu, 13 Dec 2007 15:36:34
GMT Toby A Inkster scribed:

It is not at all what Jukka is arguing for. Or not how I read it at
least.

Making up your own elements and attributes willy-nilly and nesting
elements in crazy ways doesn't make any sense because they won't be
supported in real-world browsers, DTD or no DTD.

However. there are a number of elements (e.g. <nobr>), attributes
(e.g. <body margintop="0">) and nesting combinations (e.g. <input>
directly inside <form>) which are supported in all, or virtually all
browsers.

Although many of these proprietary constructions are best avoided, or
can achieved using CSS instead, in some situations, one might deem it
appropriate to use such markup. In these cases, it can be useful to
create your own DTD to validate against, which permits your deliberate
markup deviations, but enables you to use validation as a tool for
catching coding slip-ups.

What's the point of making up your own rules to "validate" your own
markup against? It's just more silly nonsense from the praesidium, and
those who choose to indulge are simply wasting their time.

That, I believe, is the point that Jukka is trying to make. And it's
something that I agree with, have used on occasions in the past, and
would not hesitate to use again.

Technically, a very valid, convincing, and logical argument. Actually -
bupkis.

 

[Harlan Messinger]

Well bust mah britches and call me cheeky, on Thu, 13 Dec 2007 15:36:34
GMT Toby A Inkster scribed:


What's the point of making up your own rules to "validate" your own
markup against? It's just more silly nonsense from the praesidium, and
those who choose to indulge are simply wasting their time.

As far as I can tell he just explained it clearly and convincingly. What
part of it do you object to?

 

[Ben C]

Scripsit Ben C:


No, the results of parsing depend on the parser of the browser. It does
not apply a DTD there. You can check this by using different DTDs for
the same document and observing - no effects.

I know. I thought we'd been through this, although perhaps I was being
unclear. The browser does not use the DTD (apart from to do the quirks
mode switch, which is something different). But the browser still
expects something resembling valid HTML, and behaves unpredictably if it
doesn't get it.

So the author validates in order to be sure she's giving the browser the
best possible input she can. She is therefore best off validating
against HTML, or, as has been suggested, some DTD based on HTML
plus/minus things she believes work or don't work or that she has
decided to use or not to use for some good reason.

No, you are missing the point. The point is that browsers behave that
way, independently of DTD and independently of validity. If the markup
is too different from what browsers expect, disaster will follow. Using
markup that conforms to W3C specifications tends to increase the odds of
matching browser expectations, but they are not the same thing at all,
and the specific DTDs are irrelevant here.

Can you give me an example of valid HTML that produces the wrong DOM
tree in any browser other than IE?

For example, if I replace the DTD fragment

<!ELEMENT TABLE - -
(CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>

by

<!ELEMENT TABLE - -
(CAPTION, THEAD, TBODY)>

then I'm simply defining a table model that is more restricted than the
W3C model, and this makes perfect sense if I intend to use the
restricted model. There's no magic or esoteric about this, even though
most authors have no idea of such possibilities (partly because HTML
specifications explicitly discourage it by requiring the use of specific
doctype declarations).

I'm not arguing with this part. The custom DTD sounds like an excellent
idea.

 

[Jukka K. Korpela]

Scripsit Ben C:

Can you give me an example of valid HTML that produces the wrong DOM
tree in any browser other than IE?

Surely, but I don't think that's particularly relevant. (And why the
restriction "other than IE", thereby excluding the vast majority of
browsing situations?)

http://www.cs.tut.fi/~jkorpela/test/valid.html

Here's the important part thereof:

<p><em/Hello/ world!
(The word “Hello” and only it should
appear as emphasized.).</p>

Yet those wowsers even fail to display that text at all (and parse the
markup all wrong).

 

[Ben C]

Scripsit Ben C:


Surely, but I don't think that's particularly relevant. (And why the
restriction "other than IE", thereby excluding the vast majority of
browsing situations?)

Because finding bugs in IE is easier than finding ice cream on a rug
with a Bassett hound.

http://www.cs.tut.fi/~jkorpela/test/valid.html

Here's the important part thereof:

<p><em/Hello/ world!
(The word “Hello” and only it should
appear as emphasized.).</p>
Yet those wowsers even fail to display that text at all (and parse the
markup all wrong).

I might have guessed you'd come up with that one

OK, any examples that don't involve anything from Appendix B.3.3 of the
HTML specification?

 

[dorayme]

PS: Another application is to actually *tighten up* HTML 4.01 Strict.

For example, in HTML 4.01 Strict, the <html>, <head> and <body> tags (both
opening and closing) are *optional*. If you know that your HTML is going
to be processed by some user-agent (in this case, not a browser, but
probably some kind of poorly-written script) which needs to find explicit
<html>, <head> and/or <body> tags, then your DTD could make them into
required tags...

All of this sounds interesting and fair to me. Mostly though, the
*practical* need for these checks is greatly reduced for many of
us because we use checkers that pick up many things that are not
strictly invalid. They deliver "warnings", whether so labelled or
not. My iCab is remorseless in its reports, and my BBEdit does
not miss too much for my purposes either. If I did not have these
checkers, I would seriously consider a custom DTD (now that I
understand the concept better) because I rather like being forced
or at least invited to a summary for a table and to close tags
for various elements.

 

[Bone Ur]

Well bust mah britches and call me cheeky, on Thu, 13 Dec 2007 21:08:06
GMT Harlan Messinger scribed:

As far as I can tell he just explained it clearly and convincingly.
What part of it do you object to?

His explanation was fine, -nothing wrong with it. I'm just saying that
doing such things is pointless. Doctypes themselves are essentially
pointless, but of course they really appeal to the TI world.

 

[Toby A Inkster]

What's the point of making up your own rules to "validate" your own
markup against?

Ultimately, that's what we all do.

You're not going to be arrested if you use <h1> to simply make your text
large, and not for a proper heading; but most of us would refuse to do
this -- we all decide on our internal standards of what is acceptable
markup.

Writing your own DTD is just a way of explicitly codifying those standards
so that you can check your output conforms against them in an automated
manner.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 6 days, 19:36.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Jukka K. Korpela]

Scripsit dorayme:

Mostly though, the
*practical* need for these checks is greatly reduced for many of
us because we use checkers that pick up many things that are not
strictly invalid.

All checkers that I have tested have issued misleading or completely
wrong "warnings" or "error messages" (perhaps in addition to something
useful).

If I did not have these
checkers, I would seriously consider a custom DTD (now that I
understand the concept better) because I rather like being forced
or at least invited to a summary for a table and to close tags
for various elements.

Closing all elements with explicit end tags is useful, but are you sure
your checkers really require that for all elements? And don't issue
misleading messages relating to empty elements?

Making a summary for a table required or at last invited is an
interesting idea, but are you sure it's useful? Do you know some
_actual_ benefits that users get from it, on present-day browsers in
real life? (_I_ know some actual benefits, but I'm not sure at all that
they outweigh the labor needed to write them, especially when we
consider the risk that people who don't understand the issue but are
"forced" or "invited" to write summary attributes will write clueless
and even harmful values for them, just as so many people write
grotesquely absurd alt attributes.)

Would you like to trust on the authors of a checker in such matters?
What a checker "forces" or "invites" might be just a personal idea of
its author, and quite possibly a _bad_ idea.

 

[Toby A Inkster]

Doctypes themselves are essentially pointless

DOCTYPEs are not essentially pointless, as they provide a route to
validation. Validation is useful as it provides a mechanism to detect the
mark-up equivalent of a speling error.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 6 days, 19:40.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Adrienne Boswell]

Gazing into my crystal ball I observed Toby A Inkster

DOCTYPEs are not essentially pointless, as they provide a route to
validation. Validation is useful as it provides a mechanism to detect
the mark-up equivalent of a speling error.

Great analogy, even to the spelling of "speling".

 

[Harlan Messinger]

DOCTYPEs are not essentially pointless, as they provide a route to
validation. Validation is useful as it provides a mechanism to detect the
mark-up equivalent of a speling error.

A custom DTD that differs from the standard can also be useful for
enforcing in-house standards for a team of developers, so if the house
rules include "WBR is OK, FONT isn't, an explicit width and height must
be provided for all IMG tags, the TBODY must be explicit for all tables,
and any page that would go down as far as H5 is to be broken up into a
collection of smaller documents", there's a simple way to validate
documents produced by anyone on the team against these rules.