467,891 Members | 1,811 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,891 developers. It's quick & easy.

HTML vs BODY container

VK
Richard Cornford wrote:
The html element is the outermost element in an (x)HTML document.
All other elements are its descendants, with its direct children being
the head and body elements.


It is not exactly true at least for Firefox (keep missing to test in
full on Opera). In Firefox HTML is a container as any other where you
can add say images and div's. Try
html {
width:100%;
height:100%;
background-color:#DDD;
}
body {
width:75%;
background-color:#FFF;
}

and now add say <img src=...> between </body> and </html>.

IE does automatical tree correction in such case (so <body> container
is still used instead). I don't know if it's a proper reading of specs
or a rendering bug - but should be mentioned.

May 29 '06 #1
  • viewed: 5992
Share:
10 Replies
VK wrote:

(Follow ups set)
Richard Cornford wrote:
The html element is the outermost element in an (x)HTML document.
All other elements are its descendants, with its direct children being
the head and body elements.
It is not exactly true at least for Firefox (keep missing to test in
full on Opera). In Firefox HTML is a container as any other where you
can add say images and div's. Try

.... and now add say <img src=...> between </body> and </html>.


Since (X)HTML documents are not allowed <img> elements as child elements of
the <html> element, that isn't an HTML document. How browsers handle
author's errors is irrelevent.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
May 29 '06 #2
VK

David Dorward wrote:
Since (X)HTML documents are not allowed <img> elements as child elements of
the <html> element, that isn't an HTML document. How browsers handle
author's errors is irrelevent.


ACK

May 29 '06 #3
VK wrote:
It is not exactly true at least for Firefox (keep missing to test in
full on Opera). In Firefox HTML is a container as any other where you
can add say images and div's.


No browser (that I know of) does this properly anyway.

e.g.

HTML {
background: cyan;
margin: 2em;
padding: 2em;
}

In a correct rendering of CSS, the 2em of blank space created by the
padding should be cyan, but the 2em of blank space created by the margin
should not.

This is not really an appropriate topic for either of the groups you
posted to though. Cross-posted to c.i.w.a.stylesheets, follow-ups set.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

May 29 '06 #4
VK wrote:
Richard Cornford wrote:
The html element is the outermost element in an (x)HTML
document. All other elements are its descendants, with
its direct children being the head and body elements.
It is not exactly true at least for Firefox


How on earth would you know?
(keep missing to test in full on Opera).
In Firefox HTML is a container as any other where you
can add say images and div's.
Bullshit.
Try
html {
width:100%;
height:100%;
background-color:#DDD;
}
body {
width:75%;
background-color:#FFF;
}

and now add say <img src=...> between </body>
and </html>.
OK, I tried this in Firefox (with scripting and pop-ups enabled):-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
var win = window.open('','');
function showDom(){
var div = document;
var st = '<pre>'+listNodeStart(div);
st += showChildren(div, '\t');
st += listNodeEnd(div, '');
st += '<\/pre>';
win.document.write(st);
win.document.close();
}
function showChildren(el, ind){
var node, st = '';
for(var c = 0;c < el.childNodes.length;++c){
node = el.childNodes[c];
if(node.nodeType == 1){
st += ind+listNodeStart(node);
st += showChildren(node, (ind+'\t'));
st += listNodeEnd(node, ind);
}
}
return st;
}
function listNodeStart(el){
return ('&lt;' + el.nodeName +
((el.type)?(' type=\"' + el.type+'\"'):'')
+ '&gt\n');
}
function listNodeEnd(el, ind){
return el.childNodes.length?(ind+'&lt;/' + el.nodeName +'&gt\n'):'';
}

</script>
<style type="text/css">
html {
width:100%;
height:100%;
background-color:#DDD;
}
body {
width:75%;
background-color:#FFF;
}
</style>
</head>
<body onload="showDom();">
</body>
<img src="images/example.gif" alt="">
</html>

It shows that in the DOM structure created from mark-up with an IMG in
your proposed invalid context Firefox has placed the IMG element as a
direct child of the BODY element. The DOM tree is structurally valid
even if the mark-up is not.

<snip> ... I don't know if it's a proper reading of specs
or a rendering bug - but should be mentioned.


It would save everyone a considerable amount of time if you did not
mention anything that you do not understand, is irrelevant or false.
That is; just be silent.

Richard.
May 29 '06 #5
VK

Richard Cornford wrote:
It shows that in the DOM structure created from mark-up with an IMG in
your proposed invalid context Firefox has placed the IMG element as a
direct child of the BODY element. The DOM tree is structurally valid
even if the mark-up is not.


1. Please don't crosspost

2. Visually image is rendered as located in html container (anyone can
see including you). The same can be achieved with position:relative and
negative offset. I'm glad to hear that FF autocorrects DOM tree as IE
does. In this case it is a rendering error or the chosen AID behavior
as I proposed in the OP.

May 29 '06 #6
On 2006-05-29 09:40:15 +0200, "VK" <sc**********@yahoo.com> said:
IE does automatical tree correction in such case (so <body> container
is still used instead). I don't know if it's a proper reading of specs
or a rendering bug - but should be mentioned.


That's the point..
this script was written for IE only.... and I am testing it with Firefox

I changed :
this.image = new Image();
document.appendChild(this.image);
to :
this.image = new Image();
this.image.width="0";
this.image.height="0";
document.body.appendChild(this.image);

and it works... I got it invisible, but there...

May 29 '06 #7
VK wrote:
Richard Cornford wrote:
It shows that in the DOM structure created from mark-up with
an IMG in your proposed invalid context Firefox has placed
the IMG element as a direct child of the BODY element. The
DOM tree is structurally valid even if the mark-up is not.
1. Please don't crosspost


Who are you to be giving me instructions?

1. It was you who added to inappropriate cross-post to c.i.w.a.h
(inappropriate because the subject of the post to which you
posted a cross-posted response was the structure of the document
object model exposed to scripting by web browsers, even if you
did not include sufficient context to make that clear to readers
of c.i.w.a.h. That is, the subject was exclusively script related
and had nothing to do with mark-up).

2. If you wanted to restrict/direct the groups in which responses
should appear it is _your_ responsibility to set follow-ups _and_
state that you have done so.

3. Your statement that I was in error was demonstrably false, as
everyone expects from you. If you would learn to appreciate that
mental process that you apply to understanding web technologies
is so fundamentally flawed that you almost never manage to
understand what is said, draw correct conclusions or even make
meaningful/coherent statements, you could save everyone
considerable time and effort by not bothering them with your
nonsense.
2. Visually image is rendered as located in html container
(anyone can see including you). The same can be achieved with
position:relative and negative offset.
If your issue is presentation then c.i.w.a.s would have been a more
appropriate cross post (though the response would inevitably be that if
you write invalid mark-up its presentation will tend to be uncertain).
My statement was about DOM structure (related only to scripting), your
response was substantially false and irrelevant in all other respects
(as usual).
I'm glad to hear that FF autocorrects DOM tree as IE does.
Firefox's error correction of structurally invalid mark-up in DOM
creation is not the same as IE's (as I have demonstrated to you in the
past), it is just similar in this instance.
In this case it is a rendering error or the chosen AID
behavior as I proposed in the OP.


Gibberish.

[Follow-ups to comp.lang.javascript]

Richard.
May 29 '06 #8
VK wrote:

1. Please don't crosspost

Why not, pray? If a post is on-topic for two groups, and the poster
reads both groups, then surely crossposting is perfectly in-order?

If you don't like reading crossposts twice, then perhaps you need a
newsreader that doesn't show them twice. GoogleGroups is not a
newsreader at all, by the way, and I don't think Usenet posters should
feel in any way constrained by what is and isn't convenient for
GoogleGropers.

--
Jack.

May 29 '06 #9
VK
<OT>

<g />

</OT>

May 29 '06 #10
Josselin wrote:
On 2006-05-29 09:40:15 +0200, "VK" <sc**********@yahoo.com> said:
IE does automatical tree correction in such case (so <body> container
is still used instead). I don't know if it's a proper reading of specs
or a rendering bug - but should be mentioned.
That's the point..
this script was written for IE only.... and I am testing it with Firefox

I changed :
this.image = new Image();
document.appendChild(this.image);
to :
this.image = new Image();


Nobody has commented on the *approach* so far, so I feel obliged to do it.

A proprietary Image object is different from a standardized HTMLImageElement
object. At least it should be. Relying on equality because it is so in
one or two (or a handful) UAs is error-prone.
this.image.width="0";
this.image.height="0";
Neither property expects a string value.
document.body.appendChild(this.image);
This will not only fail, it will break in some UAs.

<URL:http://pointedears.de/scripts/test/whatami#inference>
and it works...
By coincidence.
I got it invisible, but there...


Your implementation of an "image cache" is nonsense. Caching, if it happens
at all, happens already when the value of the `src' property of an Image
object is changed -- as the article you are referring to states already.
As for `onreadystatechange', that event handler is IE-only (except of XHR).
Cross-browser (since Image objects were introduced in JavaScript 1.1, and
all vendors have copied DOM Level 0 so far) is `onload', and unsurprisingly
it does not require a bogus image added to the document.

See also <URL:http://pointedears.de/hoverMe>.

Note that without client-side script support nothing is cached; there are
prefetching techniques with HTML, though, that can be exploited here.
F'up2 cljs

PointedEars
--
What one man can invent another can discover.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Adventure of the Dancing Men"
May 29 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Terry | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.