<h2> Odd Behaviour?

Gene Wirchenko · Nov 22, 2011

Dear HTMLers and JavaScripters:

[Note crossposting.]

I do not know if my problem is HTML, JavaScript, my browser, my
text, though I doubt it is me. But who knows?

I have entered a text's code (HTML and JavaScript) which picks up
various pieces of browser data and writes them to another window
opened with
whOut=open("","output");
The HTML is generated with a series of whOut.document.write() calls:
<html><head><title>Output Window</title></head><body>
<h2>Browser Properties</h2>
*****value of navigator.appCodeName***** *****value of
navigotor.appName***** etc.<br>*****a couple more values*****
<h2>Window Properties</h2>
Frames: *****value of frames.length<br>

The data displays like this:

Browser Properties
navigator.appCodeName value...

Window Properties

Frames: 0
....

Note the blank line between the "Windows Properties" and "Frames"
lines. Note that there is no blank line between the "Browser
Properties" and values lines. Why not?

If I enter static HTML approximating the lines, I get the blank
line. If I generate static HTML approximating the lines, I get the
blank line.

What am I missing?

Is my text relying on browser-defined behaviour? (I am wondering
if I should have a paragraph tag there. The text does not have it,
but if I add it, it then works. I would like to understand what is
going on though.) Should I have the tag? If so, a pointer as to why
would be appreciated.

Sincerely,

Gene Wirchenko

Jukka K. Korpela · Nov 22, 2011

I do not know if my problem is HTML, JavaScript, my browser, my
text, though I doubt it is me. But who knows?

We would probably find it out rather soon if you gave us a URL.

Note the blank line between the "Windows Properties" and "Frames"
lines. Note that there is no blank line between the "Browser
Properties" and values lines. Why not?

That's impossible to say without seeing the actual code. And of course
this means that we need the URL of the page that generates the HTML code
client-side.

When you have an <h2> element in HTML followed by text content, there
will normally be empty space, corresponding to one empty line or so, due
to default styling (default margin-bottom for <h2>). Wrapping the text
content in a <p> container normally has no impact on this, since by CSS
rules, adjacent vertical margins "collapse" (i.e., the combined effect
is the larger of the margins, not their sum).

The default behavior might be affected by various factors, such as a
style sheet in the document and markup errors.

Denis McMahon · Nov 22, 2011

Note the blank line between the "Windows Properties" and "Frames"
lines. Note that there is no blank line between the "Browser
Properties" and values lines. Why not?

What does this look like:

http://www.sined.co.uk/tmp/wirchenko.htm

Note that I've wrapped all the text in enclosing block elements i.e. <p></
p>. It's a personal preference of mine that text be encapsulated in such
block elements, and that they be closed, even if it's not strictly
necessary according to the standards. Partly because the first book /
tutorial on html that I read back in the mid 90's said it should be done
thus, and whether it was right or wrong at the time, and regardless of
the fact that it may not matter with some versions, that's still the way
I do it.

Rgds

Denis McMahon

Gene Wirchenko · Nov 22, 2011

We would probably find it out rather soon if you gave us a URL.

There is no URL. This is internal.

That's impossible to say without seeing the actual code. And of course
this means that we need the URL of the page that generates the HTML code
client-side.

When you have an <h2> element in HTML followed by text content, there
will normally be empty space, corresponding to one empty line or so, due
to default styling (default margin-bottom for <h2>). Wrapping the text
content in a <p> container normally has no impact on this, since by CSS
rules, adjacent vertical margins "collapse" (i.e., the combined effect
is the larger of the margins, not their sum).

The default behavior might be affected by various factors, such as a
style sheet in the document and markup errors.

None. None that I know of. On the second, I have copied code
from the second to the first, and I still see the behaviour. If I
reverse the calls to DescribeBrowser() and DescribeWindow(), I get the
same behaviour but now with the Window Properties, that is, the first
<h2> and following is the problem.

The doctype is a default provided by Dreamweaver 8. I do not
know which doctype I should use so I have gone with the default.

***** Start of Code *****
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<title>try6.html</title>

<script type="text/javascript">

whOut=open("","output");

function SetupWindow()
{
whOut.document.write("<html><head><title>Output
Window</title></head><body>");
}

function DescribeBrowser()
{
whOut.document.write("<h2>Browser Properties</h2>");
whOut.document.write(navigator.appCodeName+" ");
whOut.document.write(navigator.appName+" ");
whOut.document.write(navigator.appVersion+"<br>");
whOut.document.write(navigator.mimeTypes.length+" MIME types are
defined. ");
whOut.document.write(navigator.plugins.length+" plug-ins are
installed.</p>");
}

function DescribeWindow()
{
whOut.document.write("<h2>Window Properties</h2>");
whOut.document.write("Frames: "+frames.length+"<br>");
whOut.document.write("URL: "+location.href+"<br>");
}

function DescribeDocument()
{
DescribeLinks();
DescribeForms();
}

function DescribeLinks()
{
whOut.document.write("<h3>Links</h3>");
whOut.document.write("This document contains
"+document.links.length+" links:<br>");
for (var i=0; i<document.links.length; i++)
whOut.document.write(document.links.href+"<br>");
}

function DescribeForms()
{
whOut.document.write("<h3>Forms</h3>");
for (var i=0; i<document.forms.length; i++)
DescribeForm(i);
}

function DescribeForm
(
n
)
{
whOut.document.write("Form "+n+" has
"+document.forms[n].elements.length+" elements:");
for (var i=0; i<document.forms[n].elements.length; i++)
whOut.document.write(" "+document.forms[n].elements.name);
whOut.document.write("<br>");
}

function FinishWindow()
{
whOut.document.write(
'<br><form><input type=button value="Close Window"
onclick="window.close()"></form>');
whOut.document.write("</body></html>");
}

</script>

</head>

<body>

<h1>Using Hierarchical Object Identifiers</h1>

<p><a href="http://www.dilbert.com/">Link to Dilbert</a></p>
<p><a href="http://www.xkcd.com/">Link to XKCD</a></p>

<form>
<p><input name=TextField1 Value="Enter text here!" /></p>
<p><input type=checkbox name=CheckBox1 checked=checked />I'm
checkbox1.</p>
<p><input type=checkbox name=CheckBox2 />I'm checkbox2.</p>
<input type=submit name=SubmitButton value="Click here!" />
</form>

<script type="text/javascript">

SetupWindow();
DescribeBrowser();
DescribeWindow();
DescribeDocument();
FinishWindow();

</script>

</body>

</html>
***** End of Code *****

Sincerely,

Gene Wirchenko

Gene Wirchenko · Nov 22, 2011

What does this look like:

http://www.sined.co.uk/tmp/wirchenko.htm

Note that I've wrapped all the text in enclosing block elements i.e. <p></
p>. It's a personal preference of mine that text be encapsulated in such
block elements, and that they be closed, even if it's not strictly
necessary according to the standards. Partly because the first book /
tutorial on html that I read back in the mid 90's said it should be done
thus, and whether it was right or wrong at the time, and regardless of
the fact that it may not matter with some versions, that's still the way
I do it.

Yes, it works. I already found that out. I am wondering if <p>
tags are compulsory to be sure of correctness. I am trying to avoid
cargo-cult programming.

Sincerely,

Gene Wirchenko

Doug Miller · Nov 22, 2011

There is no URL. This is internal.

Then please post a copy on a free hosting site somewhere. It's *far*
easier to diagnose problems from an actual working example than from a
description.

Jukka K. Korpela · Nov 22, 2011

There is no URL. This is internal.

Then you should have set up a URL. It was more difficult to me to do
that, since the code you posted here had some line breaks inserted by
your newsreader and I had to fix the issues. But there it is:
http://www.cs.tut.fi/~jkorpela/test/odd.html

This seems to happen on IE only, and if you refresh the Output Window, a
blank line gets inserted. The same happens if you do F12 on IE 9. So it
seems to be an IE quirk. It does not happen if the content is presented
as a static document.

The doctype is a default provided by Dreamweaver 8. I do not
know which doctype I should use so I have gone with the default.

In your code, the _generated_ document has no doctype declaration.

Gene Wirchenko · Nov 23, 2011

Then you should have set up a URL. It was more difficult to me to do
that, since the code you posted here had some line breaks inserted by
your newsreader and I had to fix the issues. But there it is:
http://www.cs.tut.fi/~jkorpela/test/odd.html

It works for me.

This seems to happen on IE only, and if you refresh the Output Window, a
blank line gets inserted. The same happens if you do F12 on IE 9. So it
seems to be an IE quirk. It does not happen if the content is presented
as a static document.

As I found. I was wondering if it were something I had done or
not done.

And the quirk seems to vanish if you add <!doctype html> at the start of
the generated document.
Yes.

In your code, the _generated_ document has no doctype declaration.

I added one, the same as in the generating document, and then it
worked.

Thank you.

Sincerely,

Gene Wrichenko

Denis McMahon · Nov 23, 2011

Yes, it works. I already found that out. I am wondering if <p>
tags are compulsory to be sure of correctness. I am trying to avoid
cargo-cult programming.

It may be browser dependant, and depend on how each browser handles un-
encapsulated as opposed to encapsulated text wrt stylistic presentation -
and that might further come down to user preferences.

It's old, but the following explanatory text from the HTML 3.2
specification at <url:http://www.w3.org/TR/REC-html32-19970114#body>
might shed light:

"Most elements that can appear in the document body fall into one of two
groups: block level elements which cause paragraph breaks, and text level
elements which don't."

This distinction was carried over into section 7.5.3 of the 4.01
Specification, albeit worded slightly differently:

"By default, block-level elements are formatted differently than inline
elements. Generally, block-level elements begin on new lines, inline
elements do not."

Of course, how exactly a browser interprets "begin on a new line" for
some inline text after a preceding block element (eg a header) is a
matter for the browser - some might insert a margin relating to the
previous block element, some might consider that the preceding block
element implies a new-line after regardless of what follows, others might
not etc.

Rgds

Denis McMahon

Doug Miller · Nov 23, 2011

It works for me.

Which is one *more* reason why you should set up a publicly-accessible
URL demonstrating the problem. Please remember that for the future.

Swifty · Nov 23, 2011

Of course, how exactly a browser interprets "begin on a new line" for
some inline text after a preceding block element (eg a header) is a
matter for the browser

I recently read that Microsoft had generated an extensive test suite
for HTML5 and that the W3 group had accepted it as the de facto
benchmark for compliance.

I don't know how true that is, but if so, the other browsers may end
up falling into line.

Dr J R Stockton · Nov 23, 2011

In comp.lang.javascript message <gqamc7phm92nv5ln9je0cpbgr8f2tddr8l@4ax.

com> said:
I do not know if my problem is HTML, JavaScript, my browser, my
text, though I doubt it is me. But who knows?

Certainly part at least of the problem is you.

You have not heeded the FAQ.

You may have pasted, but you have not posted, executable code, clear of
egregious error.

You have not named your browser and OS, including versions.

FYI: If, instead of using '+' to concatenate a literal string, ' + ' is
used, the code is easier to read. Likewise ',' -> ', ', '=' -> ' = '.

Song requests	4	Aug 16, 2023
Only one table shows up with the information	2	Mar 29, 2023
Text does not display correctly to glow	2	Sep 16, 2022
Reversing output of user input by using while loop...	2	Sep 1, 2022
Working on mobile css menu with plenty of frustration!	2	Dec 29, 2022
Help with code	0	Jun 12, 2022
I am trying to make an audio player, how do I get the selected file to be playable?	5	Mar 29, 2022
I Need Help with making a function that draws in a canvas using location data.	1	Dec 17, 2021

<h2> Odd Behaviour?

Gene Wirchenko

Jukka K. Korpela

Denis McMahon

Gene Wirchenko

Gene Wirchenko

Doug Miller

Jukka K. Korpela

Gene Wirchenko

Denis McMahon

Doug Miller

Swifty

Dr J R Stockton

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads