Page background color won't change.

[Harlan Messinger]

Explicitly in which specification though? Is there a DOM specification
that says anything about the number of body elements you're allowed?

The DOM is the *HTML* DOM--the object model for *HTML documents*, for
which validity is defined by the *HTML DTD*s. The DTDs *aren't* about
tags in a text file--there isn't anything IN a DTD that declares
anything whatsoever about the written notation used to represent a
document. What a DTD defines is a hierarchical structure--the structure
represented in the DOM. If the hierarchical structure of a document as
represented in the DOM is not a structure as specified in the DTD, then
it is invalid under that DTD.

How could it be otherwise? The user agent is supposed to know how to
render documents formed according to some set of rules. If you go and
manipulate a document within the user agent so that it no longer
conforms to those rules, how do you expect the user agent to be able to
render it in any reliable way, any more than if you had fed it the same
structure directly in the HTML markup?

 

[Ben C]

The DOM is the *HTML* DOM--the object model for *HTML documents*, for
which validity is defined by the *HTML DTD*s. The DTDs *aren't* about
tags in a text file--there isn't anything IN a DTD that declares
anything whatsoever about the written notation used to represent a
document. What a DTD defines is a hierarchical structure--the structure
represented in the DOM. If the hierarchical structure of a document as
represented in the DOM is not a structure as specified in the DTD, then
it is invalid under that DTD.

That's an interesting way of looking at it.

I tend to think of a DTD as an input to a parser. Markup + DTD goes in,
a DOM tree comes out if you're lucky. By the time you've got your DOM
tree you're finished with the HTML and DTD and no longer care about
them.

How could it be otherwise? The user agent is supposed to know how to
render documents formed according to some set of rules. If you go and
manipulate a document within the user agent so that it no longer
conforms to those rules, how do you expect the user agent to be able to
render it in any reliable way, any more than if you had fed it the same
structure directly in the HTML markup?

CSS user agents don't care whether the document's structure corresponds
to valid HTML or not-- all they need is a proper tree structure (i.e.
not a "soup" or a graph) and a set of properties for each node. Then
they can render it according to CSS specifications.

You get undefined _parsing_ in browsers if you use invalid HTML. The
consequence is the DOM tree you end up with isn't always the one you
expected. If you construct the DOM tree with scripting, it doesn't
matter whether it corresponds to valid HTML or not it-- you will get
exactly the tree you created, you can style it how you like, and it
should be rendered correctly according to the CSS spec.

What is the point of valid HTML? So as to get predictable results from
the parsers in browsers, and so as to provide a document that can be
parsed by other programs for other purposes.

There's is nothing in the specifications for browser rendering or
scripting that I have found that requires a document whose structure
corresponds to valid HTML.

 

[Eric B. Bednarz]

[…] If you construct the DOM tree with scripting, it doesn't
matter whether it corresponds to valid HTML or not it-- you will get
exactly the tree you created, you can style it how you like, and it
should be rendered correctly according to the CSS spec.

Time for some fun.

<http://bednarz.nl/tmp/tree.html>

Opera 9 does a good job here.

Firefox 2 and Safari 3 behave the same, link not underlined and
stretched across the viewport. They also share that their computed style
values for all the elements don’t explain the latter behaviour.

As of Internet Explorer 6 and 7, you will be happy to find that it is
all there in the DOM tree too.

 

[Harlan Messinger]

That's an interesting way of looking at it.

I tend to think of a DTD as an input to a parser. Markup + DTD goes in,
a DOM tree comes out if you're lucky. By the time you've got your DOM
tree you're finished with the HTML and DTD and no longer care about
them.

Thinking that it's a matter of "caring" is an interesting way to look at
it. If it were a matter of "caring", what would be the point of "caring"
in the first place if the user agent immediately lost interest?

Does the user agent no longer care if you create a dozen new elements
all with the same ID and then expect your client-side code to know which
of those items you're referring to?

Does it no longer care if you stick TRs directly inside TDs so that it
no longer knows what the table's structure is and can no longer render
it, and an attached screen reader can no longer read it?

Does it no longer care if you use scripting to nest one hyperlink inside
another or one form inside another and then expect the user agent to
guess what behavior you expect?

If you see it as just a matter of meaningless tags to which you apply
styles, why are you bothering with HTML at all? Just create your own DTD
with tags that have nothing to do with HTML but that represent the
contents of your document, and base your documents on that.

CSS user agents don't care whether the document's structure corresponds
to valid HTML or not-- all they need is a proper tree structure (i.e.
not a "soup" or a graph) and a set of properties for each node. Then
they can render it according to CSS specifications.

You get undefined _parsing_ in browsers if you use invalid HTML. The
consequence is the DOM tree you end up with isn't always the one you
expected. If you construct the DOM tree with scripting, it doesn't
matter whether it corresponds to valid HTML or not it-- you will get
exactly the tree you created, you can style it how you like, and it
should be rendered correctly according to the CSS spec.

What is the point of valid HTML? So as to get predictable results from
the parsers in browsers,

Validity isn't a prerequisite for document parsing. If a document is
well-formed, it doesn't have to be valid under any DTD for the result to
be predictable. A parser that knows the rules for well-formed (X/SG)ML
style documents can parse

<foo>
<bar att="3">Hello</bar>
</foo>

and create a document object from it with no trouble at all.

> and so as to provide a document that can be
parsed by other programs for other purposes.

There's is nothing in the specifications for browser rendering or
scripting that I have found that requires a document whose structure
corresponds to valid HTML.

Of course not. See foo and bar, above. But if you *tell* the browser
that you want an HTML document, then it should be what you say it is. I
don't understand why you think the user agent needs to be assured that
it's HTML one moment and not the next moment.

 

[Ben C]

Thinking that it's a matter of "caring" is an interesting way to look at
it. If it were a matter of "caring", what would be the point of "caring"
in the first place if the user agent immediately lost interest?

Does the user agent no longer care if you create a dozen new elements
all with the same ID and then expect your client-side code to know which
of those items you're referring to?

Does it no longer care if you stick TRs directly inside TDs so that it
no longer knows what the table's structure is and can no longer render
it

[...]

CSS rules define how to render something that's display: table-row
directly inside something that's display: table-cell. There's no problem
there.

[...]

Does it no longer care if you use scripting to nest one hyperlink inside
another or one form inside another and then expect the user agent to
guess what behavior you expect?

That kind of thing is more of a problem. Rendering (according to CSS
rules-- I don't know any specifications for screen readers) does not
have any requirements relating to HTML validity. Handling forms and
links does.

If you see it as just a matter of meaningless tags to which you apply
styles, why are you bothering with HTML at all? Just create your own DTD
with tags that have nothing to do with HTML but that represent the
contents of your document, and base your documents on that.

Good question-- why not?

[...]

Of course not. See foo and bar, above. But if you *tell* the browser
that you want an HTML document, then it should be what you say it is. I
don't understand why you think the user agent needs to be assured that
it's HTML one moment and not the next moment.

OK, practical question. Suppose someone uses scripting to attach a DIV
as a child of a TR. What should the browser do? Raise a DOM Exception
(if so, which one), apply the same patch-up rules it would if it were
parsing <TR><DIV>, or just allow it?

 

[Bergamot]

OK, practical question. Suppose someone uses scripting to attach a DIV
as a child of a TR. What should the browser do?

Behavior for any nesting that's invalid per the specs is likely to be
unpredictable, regardless of what the specs say should (or must) be
done. Relying on consistent error correction across browsers is a crap
shoot, don't you think?

 

[Ben C]

Behavior for any nesting that's invalid per the specs is likely to be
unpredictable, regardless of what the specs say should (or must) be
done. Relying on consistent error correction across browsers is a crap
shoot, don't you think?

Of course, it's just that from what I've seen browsers don't do error
correction when attaching nodes to the tree with scripting. It just
works (and the resulting tree can always be rendered by CSS specs,
although forms and links might be broken). I believe this to be the
correct thing for browsers to do but wondered if anyone knew of a
specification that says anything about this.

appendChild does raise an exception if you try to attach a DIV as a
child of a #text node. But not if you attach a DIV as a child of a TR.
If it did raise an exception in that case I suspect that would be
non-conforming.

 

[Harlan Messinger]

Thinking that it's a matter of "caring" is an interesting way to look at
it. If it were a matter of "caring", what would be the point of "caring"
in the first place if the user agent immediately lost interest?

Does the user agent no longer care if you create a dozen new elements
all with the same ID and then expect your client-side code to know which
of those items you're referring to?

Does it no longer care if you stick TRs directly inside TDs so that it
no longer knows what the table's structure is and can no longer render
it

[...]

CSS rules define how to render something that's display: table-row
directly inside something that's display: table-cell. There's no problem
there.

I'm not talking about CSS, I'm talking about HTML. You could make the
same CSS-based excuse for having <TD><TR>...</TR></TD> in your HTML
markup. The point is, you're making a distinction between the markup and
what you do to the object model afterwards, and I'm pointing out that
whatever benefits there are to validity before continue to apply after,
and whatever problems are caused by invalid markup are still problems if
introduced after the initial rendering.

[...]

Does it no longer care if you use scripting to nest one hyperlink inside
another or one form inside another and then expect the user agent to
guess what behavior you expect?

That kind of thing is more of a problem. Rendering (according to CSS
rules-- I don't know any specifications for screen readers) does not
have any requirements relating to HTML validity. Handling forms and
links does.

If you see it as just a matter of meaningless tags to which you apply
styles, why are you bothering with HTML at all? Just create your own DTD
with tags that have nothing to do with HTML but that represent the
contents of your document, and base your documents on that.

Good question-- why not?

No reason. The point is, if you DO make your HTML valid for whatever
reason validity is important, it doesn't suddenly become unimportant.
Whatever problems will be caused by invalid HTML on the way into the
browser are the same problems that will be caused invalidities added to
the document afterwards.

[...]

Of course not. See foo and bar, above. But if you *tell* the browser
that you want an HTML document, then it should be what you say it is. I
don't understand why you think the user agent needs to be assured that
it's HTML one moment and not the next moment.

OK, practical question. Suppose someone uses scripting to attach a DIV
as a child of a TR. What should the browser do? Raise a DOM Exception
(if so, which one), apply the same patch-up rules it would if it were
parsing <TR><DIV>, or just allow it?

I don't know. As far as I know it's undefined behavior, so it requires
some unwarranted confidence to assume that it'll work a certain way in
all browsers now and in the future.

 

[Ben C]

Does it no longer care if you stick TRs directly inside TDs so that it
no longer knows what the table's structure is and can no longer render
it

[...]

CSS rules define how to render something that's display: table-row
directly inside something that's display: table-cell. There's no problem
there.

I'm not talking about CSS, I'm talking about HTML. You could make the
same CSS-based excuse for having <TD><TR>...</TR></TD> in your HTML
markup.

No, because if you put that in your HTML markup that's not what you will
get in your DOM tree (in Firefox etc. or by HTML5 suggestions).

The point is, you're making a distinction between the markup and
what you do to the object model afterwards, and I'm pointing out that
whatever benefits there are to validity before continue to apply after,

Not quite all-- one of the benefits to validity is that the markup can
be processed by other programs which aren't going to run the JS.

and whatever problems are caused by invalid markup are still problems if
introduced after the initial rendering.

Valid markup is required for correct forms and links behaviour. But not
for CSS rendering. The biggest practical problem caused by invalid
markup (where forms and links aren't involved) is that the browser
patches it up producing an unpredictable DOM tree. If you create your
DOM tree with scripting, you _have_ avoided that problem, assuming
browsers don't do any patching up in that case, which they don't.

 

[Harlan Messinger]

Does it no longer care if you stick TRs directly inside TDs so that it
no longer knows what the table's structure is and can no longer render
it
[...]

CSS rules define how to render something that's display: table-row
directly inside something that's display: table-cell. There's no problem
there.

I'm not talking about CSS, I'm talking about HTML. You could make the
same CSS-based excuse for having <TD><TR>...</TR></TD> in your HTML
markup.

No, because if you put that in your HTML markup that's not what you will
get in your DOM tree (in Firefox etc. or by HTML5 suggestions).

You're still missing the point. You are treating validity as having no
purpose other than to slip by the thing in your browser that insists on
validity. If that were true, fine--except then there wouldn't be any
point in the browser insisting on validity in the first place.

 

[Ben C]

Ben C wrote:
Does it no longer care if you stick TRs directly inside TDs so that it
no longer knows what the table's structure is and can no longer render
it
[...]

CSS rules define how to render something that's display: table-row
directly inside something that's display: table-cell. There's no problem
there.
I'm not talking about CSS, I'm talking about HTML. You could make the
same CSS-based excuse for having <TD><TR>...</TR></TD> in your HTML
markup.

No, because if you put that in your HTML markup that's not what you will
get in your DOM tree (in Firefox etc. or by HTML5 suggestions).

You're still missing the point. You are treating validity as having no
purpose other than to slip by the thing in your browser that insists on
validity.

Correct, that is just what I'm doing!

If that were true, fine--except then there wouldn't be any
point in the browser insisting on validity in the first place.

They don't insist on validity or need it for rendering. But for
historical reasons they move things around if the markup is invalid. To
stop that happening (because it's annoying and unpredictable) is the
biggest reason for most authors to insist on validity, although not the
only one.

I suspect that earlier generations of browsers that were not CSS based
_did_ need some degree of validity in order to render pages and so
that's why they particularly patch up invalid TABLE/TR/TD markup.