By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,246 Members | 1,451 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,246 IT Pros & Developers. It's quick & easy.

<p> and <div> and breaks

P: n/a
1. Here's some html from a W3C recommendations page.

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>

2.Although I didn't think it would make any difference, I tried it
with the </p>s included as well.
<P>aaaaaaaaa</p><DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</p></DIV>
FF2 renders both #1 and #2 as:
------------------
aaaaaaaaa

bbbbbbbbb
cccccccc

dddddddd

So it looks like FF2 doesn't allow either <div>s within a <por <p>s
within a <div>??? Is there some other explanation? FF is either
putting a double break (<br><br>) after the <pterminates or a single
break after the <pand another single break before the following
<div>. Could the second <divbe terminating when it hits the <p>? It
looks like it.

W3C says that most browsers will show the first one as:
----------------------
aaaaaaaaa
bbbbbbbbb
cccccccc

dddddddd

....which is how IE7 shows it.
IE7 renders #2 as:
-----------
aaaaaaaaa

bbbbbbbbb
cccccccc

dddddddd
It looks like in IE7 a <pCAN contain a <divwhich accounts for the
difference between #1 and #2 when we add the </p>s. The <pin #1
probably doesn't end until it hits the second <p>.

I was surprised by these results.

Regards,
Kent Feiler
www.KentFeiler.com
Dec 19 '06 #1
Share this Question
Share on Google+
28 Replies


P: n/a
Scripsit Kent Feiler:
2.Although I didn't think it would make any difference, I tried it
with the </p>s included as well.
By HTML specifications, the </ptag is always omissible in "classic"
(SGML-based) HTML and always required (for a <pelement) in XHTML. When
omissible, the omission should not have any effect on meaning or rendering.

But that's not how browsers (a.k.a. wowsers or tag slurpers) behave. Just
live with it. Use </peven if you use "classic" HTML (as you should, unless
you _know_ some actual benefit that you get from XHTML), because that way,
browser behavior is more predictable.
FF2 renders both #1 and #2 as:
So what?
So it looks like FF2 doesn't allow either <div>s within a <por <p>s
within a <div>???
What?? What do you mean by not allowing something? It's the HTML
specifications that disallow <divwithin <p>.
FF is either
putting a double break (<br><br>) after the <pterminates or a single
break after the <pand another single break before the following
<div>. Could the second <divbe terminating when it hits the <p>? It
looks like it.
Stop guessing. Find a tutorial on HTML and read about tags and elements.
Then come back if problems remain.
W3C says that most browsers will show the first one as:
What? Where? Are we supposed to guess which part of which document you read?

Generally, what the W3C documents say about browsers is partly dated, partly
just made-up (wishful thinking perhaps), and partly correct.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Dec 19 '06 #2

P: n/a
Kent Feiler wrote:
1. Here's some html from a W3C recommendations page.
Presumably http://www.w3.org/TR/html4/struct/global.html#h-7.5.4
But oh, maybe not. It's not the exact same. Where did you find that?
>
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>

2.Although I didn't think it would make any difference, I tried it
with the </p>s included as well.

<P>aaaaaaaaa</p><DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</p></DIV>
FF2 renders both #1 and #2 as:
------------------
aaaaaaaaa

bbbbbbbbb
cccccccc

dddddddd

So it looks like FF2 doesn't allow either <div>s within a <por <p>s
within a <div>??? Is there some other explanation? FF is either
putting a double break (<br><br>) after the <pterminates or a single
break after the <pand another single break before the following
<div>.
Kent,

Forget about breaks. Forget about <br>. They are just confusing you.

Add a <br>, singly, inside a paragraph, only if you want the paragraph
to break to the next line. Otherwise, never. Forget about them, and the
spacing-ness of them.

What you are seeing, or at least looking at, is the case where <p>
elements are automatically terminated. When the browser is reading
through the aaa's, preparing to render that <p>, it bumps into a <div>
and realizes it should terminate the paragraph and start a new block
item, the div.

Read <http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1>.

Now, *it happens* that individual browsers have certain default vertical
spacings before and after certain elements, including <pand <div>, and
*it happens* that these may appear to be common among several browsers,
it may also *look* as though the spacing is the equivalent of, say, the
result of inserting <brinto the source, but FORGET ALL OF THAT. Just
mark up the content, and style the elements for the spacing you'd like
to recommended.

Could the second <divbe terminating when it hits the <p>? It
looks like it.
I think the div isn't terminating, but a paragraph is starting. Your
browser probably has a default vertical spacing before the <p>. There it is.
>
It looks like in IE7 a <pCAN contain a <div>
I don't think so. <divis block-level markup. But a <pcannot contain
block-level elements:
http://www.w3.org/TR/html4/struct/text.html#edef-P

I don't know why IE6 and IE7 are different, exactly, but different
browsers are, well, different. Are you in quirks mode? Or what?

HTH
--
John
Dec 19 '06 #3

P: n/a
On 12/19/2006 02:09 PM, Kent Feiler wrote:
1. Here's some html from a W3C recommendations page.

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>

2.Although I didn't think it would make any difference, I tried it
with the </p>s included as well.
<P>aaaaaaaaa</p><DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</p></DIV>
FF2 renders both #1 and #2 as:
------------------
aaaaaaaaa

bbbbbbbbb
cccccccc

dddddddd

So it looks like FF2 doesn't allow either <div>s within a <por <p>s
within a <div>??? Is there some other explanation? FF is either
putting a double break (<br><br>) after the <pterminates or a single
break after the <pand another single break before the following
<div>. Could the second <divbe terminating when it hits the <p>? It
looks like it.

W3C says that most browsers will show the first one as:
----------------------
aaaaaaaaa
bbbbbbbbb
cccccccc

dddddddd

....which is how IE7 shows it.
IE7 renders #2 as:
-----------
aaaaaaaaa

bbbbbbbbb
cccccccc

dddddddd
It looks like in IE7 a <pCAN contain a <divwhich accounts for the
difference between #1 and #2 when we add the </p>s. The <pin #1
probably doesn't end until it hits the second <p>.

I was surprised by these results.

Regards,
Kent Feiler
www.KentFeiler.com
A <pelement can only contain inline elements and text:
http://www.w3.org/TR/html4/struct/text.html#h-9.3.1

I might be inclined to say that FF is right, but I'm not sure.
--
pa*******************@earthlink.net
http://home.earthlink.net/~mumia.w.18.spam/
Dec 19 '06 #4

P: n/a
Kent Feiler wrote:
1. Here's some html from a W3C recommendations page.

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>

2.Although I didn't think it would make any difference, I tried it
with the </p>s included as well.
<P>aaaaaaaaa</p><DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</p></DIV>
The last portion after "which is typically rendered as:
<http://www.w3.org/TR/html4/struct/global.html#h-7.5.4>
is typically rendered thusly only by IE. It is an *error* in the
specifications (someone should report this to W3C). It should be and is
actually rendered, in conforming browsers, as:

aaaaaaaaa

bbbbbbbbb
ccccc

ccccc

This is not what the section is about though. It's about "New Line/Line
Break" and not specifically "Double Line Leading" as performed by
default Top and Bottom Margin values for the P element. Probably for
that reason the error was not picked up before.

Only the "a" line and the second "c" line should have Double Line
Leading created by default Top and Bottom Margins applied to the P
element. The anonymous text does not - it only creates a "New Line/Line
Break" at the end of the anonymous text by virtue of the block end tag
</divin the first instance and block start tag <pin the second.

Your example is the same as the W3C example, exept for your renaming of
the last line to d's from the W3C's repeated c's and in neither is there
any DIV inside a P as you suggest and which would not be permitted per
the Specs and, of course, there is a P element in a DIV in the example,
which is permissable. Perhaps viewing your example slightly differently
but still meaning the same will help:

<P>aaaaaaaaa</p>
<DIV>bbbbbbbbb</DIV>
<DIV>cccccccc<P>dddddddd</p></DIV>

Fx and Opera render it corrrectly with or without the closing tags.
IE 6 and IE 7 both, whether in Standards or Quirk Mode, do not render it
correctly if the first </pclosing tag is omitted.
Interestingly, if applying different colored borders to all the
elements, IE sees all the elements correctly, but does not apply the
margin-bottom to the first P if the closing tag is omitted.
IE 6 and IE 7 both render it correctly if the closing tags are included.
Interestingly, Both IE 6 and 7 have the same bug, which shows that 6 and
7 are really the same with different eyecandy.
Considering that in XHTML and XML end tags are mandatory, we should use
all optional tags in any case - problem resolved.

--
Gus
Dec 20 '06 #5

P: n/a
Scripsit Gus Richter:
The last portion after "which is typically rendered as:
<http://www.w3.org/TR/html4/struct/global.html#h-7.5.4>
is typically rendered thusly only by IE.
So it's rather typical, isn't it? After all, IE is far more widely used
these days than all other browsers combined.

The _point_ here is that browsers display div elements as blocks, i.e. start
the content on a new line and start the content that follows the element on
a new line as well. They just confuse things by using paragraph markup as
well.
It is an *error* in the specifications
No, it's just sloppy wording. The entire passage is obscure, but not in
error.
(someone should report this to W3C).
Someone moved to the next galaxy since Everyone gave Someone far too many
tasks and duties. But don't bother. They're not interested in any reports
about the _old_ (pre-XHTML) specifications, even as regards to things that
are provably errors.
It should be and
is actually rendered, in conforming browsers, as:

aaaaaaaaa

bbbbbbbbb
ccccc

ccccc
Exactly which statement(s) in the specification prescribe(s) such a
rendering.

Of course the guys who wrote the sloppy passage thought wrong. They didn't
realize that by SGML rules (assuming, of course, the HTML 4 DTD),
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>
is equivalent to
<P>aaaaaaaaa</P><DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</P></DIV>
Instead they thought of a <Ptag as implying an empty line before the
paragraph and a </Ptag as implying an empty line after the paragraph,
since this is what tag slurpers did, and IE still carries that tradition.

But it would be incorrect to say that the rendering is nonconforming _as
such_. It is only nonconforming if the browser renders the two equivalent
markup alternatives differently.

There's no law against a browser having a default style sheet like
p { margin: 1.3em 0 0 0; }
This is not what the section is about though. It's about "New
Line/Line Break" and not specifically "Double Line Leading" as
performed by default Top and Bottom Margin values for the P element.
Probably for that reason the error was not picked up before.
Right. Except that it's not error in the specification - even though it was
a result of carelessness.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Dec 20 '06 #6

P: n/a
Jukka K. Korpela wrote:
Scripsit Gus Richter:
>The last portion after "which is typically rendered as:
<http://www.w3.org/TR/html4/struct/global.html#h-7.5.4>
is typically rendered thusly only by IE.

So it's rather typical, isn't it? After all, IE is far more widely used
these days than all other browsers combined.
I see the use of typical as "among all available" browsers and not of
"all" browsers in use out there. Hence the rendering as shown is not
typical for the browsers of today, but cynically typical only by IE.
Typically, the browsers of today render as below.
>It should be and
is actually rendered, in conforming browsers, as:

aaaaaaaaa

bbbbbbbbb
ccccc

ccccc

Exactly which statement(s) in the specification prescribe(s) such a
rendering.
The <plines ("a" and "2nd c") have Top and Bottom Margins applied to
create the conventional Double Line Leading for paragraphs, whereas the
anonymous test lines ("b" and "1st "c") do not. They don't even create
"New Line/Line Break". It is performed by associated <divand <pelements.
Of course the guys who wrote the sloppy passage thought wrong. They
didn't realize that by SGML rules (assuming, of course, the HTML 4 DTD),
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>
is equivalent to
<P>aaaaaaaaa</P><DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</P></DIV>

But it would be incorrect to say that the rendering is nonconforming _as
such_. It is only nonconforming if the browser renders the two
equivalent markup alternatives differently.
And indeed IE 6 and IE 7 both render them differently.
There's no law against a browser having a default style sheet like
p { margin: 1.3em 0 0 0; }
But then it would not follow the "Double Line Leading" convention for
paragraphs. OK for the beginning of the paragraph (assuming 1.3em is
sufficient), but only Single Line Leading for the end of the paragraph.
>This is not what the section is about though. It's about "New
Line/Line Break" and not specifically "Double Line Leading" as
performed by default Top and Bottom Margin values for the P element.
Probably for that reason the error was not picked up before.

Right. Except that it's not error in the specification - even though it
was a result of carelessness.
The subject in the specification is regarding a DIV being on a "New
Line" and the method used by the browsers is the placing of
line breaks before and after DIVs. Example markup is presented and how
it will be rendered. Whether it is an error or whatever due to
carelessness, it is wrong. IE is the only one that renders it like that
and only if the optional closing tags are not used. With the optional
closing tags, IE renders as all other browsers do. The importance of
showing the proper way that it should be rendered is demonstrated by the
OP's confusion, as well as his and our wasted time on this.

--
Gus
Dec 20 '06 #7

P: n/a
Scripsit Gus Richter:
I see the use of typical as "among all available" browsers and not of
"all" browsers in use out there.
I see "typical" as meaning common, usual, or characteristic. But this
doesn't mean much, since the authors don' t say what _they_ mean by
"typical". Besides, it's descriptive, not prescriptive (normative) anyway.
>Exactly which statement(s) in the specification prescribe(s) such a
rendering.

The <plines ("a" and "2nd c") have Top and Bottom Margins applied to
create the conventional Double Line Leading for paragraphs, whereas
the anonymous test lines ("b" and "1st "c") do not. They don't even
create "New Line/Line Break". It is performed by associated <divand
<pelements.
The HTML specification imposes no _requirements_ on vertical margins. Simple
as that. You cannot violate a requirement that does not exist. What you
think about the underlying mechanisms is immaterial.
>There's no law against a browser having a default style sheet like
p { margin: 1.3em 0 0 0; }

But then it would not follow the "Double Line Leading" convention for
paragraphs.
So what? That convention is bad style anyway ("engineer's paragraphs"), and,
what matters here, just a convention, not part of HTML (or CSS)
specifications.
The subject in the specification is regarding a DIV being on a "New
Line" and the method used by the browsers is the placing of
line breaks before and after DIVs. Example markup is presented and how
it will be rendered.
No, how it is _typically_ rendered.
Whether it is an error or whatever due to
carelessness, it is wrong.
No, it contains line breaks just where the text says they are. Whether it
also contains vertical spacing is a different issue. And they made a mistake
in confusing the two.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Dec 20 '06 #8

P: n/a
On Wed, 20 Dec 2006 16:21:39 +0200, "Jukka K. Korpela"
<jk******@cs.tut.fiwrote:
>Scripsit Gus Richter:
>>There's no law against a browser having a default style sheet like
p { margin: 1.3em 0 0 0; }

But then it would not follow the "Double Line Leading" convention for
paragraphs.

So what? That convention is bad style anyway ("engineer's paragraphs"), and,
what matters here, just a convention, not part of HTML (or CSS)
specifications.
With the advent of CSS, html is meant to not specify any particular
layout or presentation at all, other than that some elements are
"block", some are "inline", and some other things.

We are supposed to mark up the meaning of the content, not it's
presentation. It's true that browsers all have default renderings, but
beside the point. If we want a particular layout we do not specify it
in the html, but in the CSS.

How any particular element is typically displayed is irrelevant to html
markup. What the content means is what matters, so far as markup is
concerned.

Dec 20 '06 #9

P: n/a
On Tue, 19 Dec 2006 14:09:48 -0600, Kent Feiler <zz**@zzzz.comwrote:

1. Here's some html from a W3C recommendations page.

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>
------------------------------------------------------------------------------

I have to say that this newsgroup seems to have a higher percentage of
obnoxious creeps who post to it than most. But maybe I should check
out some of the religious newgroups, it may turn out that everyone
here is really quite polite and courteous!

To begin, I was curious as to: (1)why this snippet of html wasn't
producing the results I thought it would, and (2)why IE7 and FF2 were
producing different results. In the end, the answer to (2) is the
usual, "That's the way it is, sukka. Suffer!"

But I'm still confused about (1). Where does the first <pend? For
FF2 it appears to end at the first <div>, but why? Is it because of a
syntax error, i.e. <div>s are not allowed within <pso FF terminates
the first <pwith the normal double break and then continues
processing?

IE7 looks like it doesn't end the first <puntil it hits the second
one and processes the two internal <div>s with a single break. I would
have thought it would discard the syntactically invalid <divtags and
produce something like:

aaaaaaaaaabbbbbbbbbbcccccccccc

dddddddddd

....but instead it seems to ignore the idea the <div>s aren't allowed
within <p>s. Maybe it didn't attend the meeting. Or maybe it doesn't
think it should be in the business of enforcing syntax errors.

Does that sound like what's happening?

Regards,
Kent Feiler
www.KentFeiler.com
Dec 20 '06 #10

P: n/a

Kent Feiler wrote:
On Tue, 19 Dec 2006 14:09:48 -0600, Kent Feiler <zz**@zzzz.comwrote:
[...]
I have to say that this newsgroup seems to have a higher percentage of
obnoxious creeps who post to it than most.
Are you aware that it's your own posting you're commenting to?

Dec 20 '06 #11

P: n/a
Kent Feiler wrote:
On Tue, 19 Dec 2006 14:09:48 -0600, Kent Feiler <zz**@zzzz.comwrote:

1. Here's some html from a W3C recommendations page.

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>
*Where's* some HTML? You still didn't say which page.
I have to say that this newsgroup seems to have a higher percentage of
obnoxious creeps who post to it than most. But maybe I should check
out some of the religious newgroups, it may turn out that everyone
here is really quite polite and courteous!
Your statement surprises me, Kent. I've looked through this thread
again, and it looks like we're all just discussing your topic.
>
To begin, I was curious as to: (1)why this snippet of html wasn't
producing the results I thought it would, and (2)why IE7 and FF2 were
producing different results. In the end, the answer to (2) is the
usual, "That's the way it is, sukka. Suffer!"

But I'm still confused about (1). Where does the first <pend?
At the first <div>. As written in the other posts.
For
FF2 it appears to end at the first <div>, but why?
It's supposed to. As per the W3C documents referenced in the posts by
Mumia, Gus, and myself.
Is it because of a
syntax error, i.e. <div>s are not allowed within <pso FF terminates
the first <p>
Yes.
with the normal double break
NO! Forget about breaks and double breaks. A div is starting and a div
may have a default leading space (and the terminated <pmay have a
following space), but forget this break fixation. Look at the *blocks*
(really, elements), not the *spaces* between them.
and then continues processing?

IE7 looks like it doesn't end the first <puntil it hits the second
one and processes the two internal <div>s with a single break.
I consider this a bug in IE.
I would
have thought it would discard the syntactically invalid <divtags and
produce something like:

aaaaaaaaaabbbbbbbbbbcccccccccc

dddddddddd
That'd be an option (maybe, although Jukka is the expert on
spec/language matters), but it's not what the browsers do. "Sorry,
sucker!" ;-)
...but instead it seems to ignore the idea the <div>s aren't allowed
within <p>s. Maybe it didn't attend the meeting. Or maybe it doesn't
think it should be in the business of enforcing syntax errors.
I hope this helps, but if it doesn't, you could reply to it and tell me
why it doesn't. Nothing obnoxious, creepy, or religious intended by it.

--
John
Dec 20 '06 #12

P: n/a
Kent Feiler wrote:
On Tue, 19 Dec 2006 14:09:48 -0600, Kent Feiler <zz**@zzzz.comwrote:

1. Here's some html from a W3C recommendations page.

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>
------------------------------------------------------------------------------

I have to say that this newsgroup seems to have a higher percentage of
obnoxious creeps who post to it than most. But maybe I should check
out some of the religious newgroups, it may turn out that everyone
here is really quite polite and courteous!

To begin, I was curious as to: (1)why this snippet of html wasn't
producing the results I thought it would,
That would be hard to explain, since you didn't say what results you had
expected, in terms of the spacing.

and (2)why IE7 and FF2 were
producing different results. In the end, the answer to (2) is the
usual, "That's the way it is, sukka. Suffer!"

But I'm still confused about (1). Where does the first <pend?
The first P is *supposed* to end immediately before the beginning DIV
tag, because the P end tag is optional in HTML (as opposed to XHTML),
and a P element isn't allowed to contain a DIV element, so that's the
latest location that the browser can impute the end tag.

A P is allowed inside a DIV.

Firefox by default styles P with top and bottom margins of 1em. (In a
Windows installation, at least, see the html.css file in the Firefox
res directory.) So the aaa paragraph is separated from the bbb block
that follows it and the ddd paragraph is separated from the ccc block
that precedes it. (The ccc is treated as though contained by an
anonymous block box: see http://www.w3.org/TR/CSS21/visuren.html#q5.)

Regarding IE7: did you includes a DOCTYPE at the top of your page?
For
FF2 it appears to end at the first <div>, but why? Is it because of a
syntax error, i.e. <div>s are not allowed within <pso FF terminates
the first <pwith the normal double break and then continues
processing?

IE7 looks like it doesn't end the first <puntil it hits the second
one and processes the two internal <div>s with a single break. I would
have thought it would discard the syntactically invalid <divtags and
produce something like:

aaaaaaaaaabbbbbbbbbbcccccccccc

dddddddddd

...but instead it seems to ignore the idea the <div>s aren't allowed
within <p>s. Maybe it didn't attend the meeting. Or maybe it doesn't
think it should be in the business of enforcing syntax errors.

Does that sound like what's happening?

Regards,
Kent Feiler
www.KentFeiler.com
Dec 20 '06 #13

P: n/a
Kent Feiler wrote:
IE7 looks like it doesn't end the first <puntil it hits the second
one and processes the two internal <div>s with a single break. I would
have thought it would discard the syntactically invalid <divtags and
produce something like:
That DIV *tag* isn't syntactically invalid, *because* the P end tag is
optional.

More food for thought: both the beginning and end tags are optional for
the HTML, HEAD, and BODY elements. You can have a valid document in HTML
4.01 Strict that contains nothing more than

<title>Minimal Page</title>
<p>Here's a paragraph.</p>

The HTML, HEAD, and BODY *elements* are required, so a properly
functioning user agent will internally build from this code an HTML
element containing a HEAD and BODY element and will know that the HEAD
element has to contain the TITLE element represented by the TITLE tags
and the text between them, and that the BODY has to contain the P
element represented by the P tags and the text between them. In other
words, the user agent should internally treat the document as though it
had been written

<html>
<head>
<title>Minimal Page</title>
</head>
<body>
<p>Here's a paragraph.</p>
</body>
</html>

That's how the relationship between tags (both required and optional,
both explicit and implicit) and elements (the conceptual parts of the
document that may or may not be represented by tags in the source HTML)
works.
Dec 20 '06 #14

P: n/a
Kent Feiler <zz**@zzzz.comwrote:
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>
In http://www.w3.org/TR/REC-html40/stru...l.html#h-7.5.4 the example
is actually

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

but I like your version better.
But I'm still confused about (1). Where does the first <pend? For
FF2 it appears to end at the first <div>, but why? Is it because of a
syntax error, i.e. <div>s are not allowed within <pso FF terminates
the first <pwith the normal double break and then continues
processing?
There is no syntax error in the HTML. Since DIV elements are not allowed
inside P elements, and since the closing </Ptag is optional, the closing
of the P element is implied by the opening of the DIV element.
IE7 looks like it doesn't end the first <puntil it hits the second
one and processes the two internal <div>s with a single break. I would
have thought it would discard the syntactically invalid <divtags and
produce something like:
There is nothing syntactially invalid here. Browsers should treat your
example and

<P>aaaaaaaaa</P><DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</P></DIV>

identically. If they don't, then it's a bug.

It's a good idea to include all the optional closing tags, because it helps
buggy browsers (and browser-like OS components) render documents more
consistently.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"FAILURE IS NOT AN OPTION. It comes bundled with the software."
Dec 20 '06 #15

P: n/a
Jukka K. Korpela wrote:
Scripsit Gus Richter:
>I see the use of typical as "among all available" browsers and not of
"all" browsers in use out there.

I see "typical" as meaning common, usual, or characteristic.
Right, and among all the "different" browsers. Really ridiculous to mean
the total volume of all browsers in use, other than to just be
argumentative.
>>There's no law against a browser having a default style sheet like
p { margin: 1.3em 0 0 0; }

But then it would not follow the "Double Line Leading" convention for
paragraphs.

So what? That convention is bad style anyway ("engineer's paragraphs"),
and, what matters here, just a convention, not part of HTML (or CSS)
specifications.
I happen to not like the Double Line Leading convention for paragraphs,
but it is here and encouraged by W3C. Don't ask for proof for I won't
bother to search for it. You know that this is so.

Your rule for top-margin only as a default for paragraphs would confuse
a document and is truly grasping for argumentative straws.
>The subject in the specification is regarding a DIV being on a "New
Line" and the method used by the browsers is the placing of
line breaks before and after DIVs. Example markup is presented and how
it will be rendered.

No, how it is _typically_ rendered.
You are predictable. I left it out on purpose for you.
>Whether it is an error or whatever due to
carelessness, it is wrong.

No, it contains line breaks just where the text says they are. Whether
it also contains vertical spacing is a different issue. And they made a
mistake in confusing the two.
I say that it is an error and that it is wrong. You say No, but hedge
your bet by adding at the end that they made a mistake. It seems to me
that it is you that is confusing the two issues. Vertical spacing is the
issue in this thread as demonstrated in an example where the issue is
about line breaks.

In an example of rendering for line breaks, the example also shows
vertical spacing as "Double Line Leading" in one instance, but not in
the other instance. Perhaps they should have used a different example,
but they didn't and by indicating that it is a typical browser rendering
is wrong, an error and a mistake.

--
Gus
Dec 20 '06 #16

P: n/a
In our last episode,
<7o********************************@4ax.com>,
the lovely and talented Kent Feiler
broadcast on comp.infosystems.www.authoring.html:
On Tue, 19 Dec 2006 14:09:48 -0600, Kent Feiler <zz**@zzzz.comwrote:
1. Here's some html from a W3C recommendations page.
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>
------------------------------------------------------------------------------
I have to say that this newsgroup seems to have a higher percentage of
obnoxious creeps who post to it than most. But maybe I should check
out some of the religious newgroups, it may turn out that everyone
here is really quite polite and courteous!
When you have not made the least effort to learn HTML, what do you expect?
To begin, I was curious as to: (1)why this snippet of html wasn't
producing the results I thought it would, and (2)why IE7 and FF2 were
producing different results. In the end, the answer to (2) is the
usual, "That's the way it is, sukka. Suffer!"
There are plenty of headaches when browsers do not interpret styles the same
way. That they have different defaults for unstyled elements is not really
a problem.
But I'm still confused about (1). Where does the first <pend?
Since P cannot contain a block element and DIV is a block element,
P is closed when the first DIV is opened.
For FF2 it appears to end at the first <div>, but why?
As you would know if you had ever looked at a spec, P cannot contain
a block element. The browser assumes you must have meant to close
P when you opened DIV, because DIV in P is impossible.
Is it because of a syntax error,
It isn't really a syntax error in HTML. In HTML many elements do not
require closing tags. If you are thinking you are putting a DIV in P,
you are just wrong, but <Pblah, blah, blah. <DIVis not incorrect syntax.
It is just syntax that doesn't mean what you think it does.
i.e. <div>s are not allowed within <pso
FF terminates the first <pwith the normal double break and then
continues processing?
Thinking about "double breaks" is misleading. A browser could reasonably
have a default that puts a single break when P closes and and a break with
an indent when P opens. It is not about how browsers choose to render
paragraphs. It is about the structure of the document.
IE7 looks like it doesn't end the first <puntil it hits the second
one and processes the two internal <div>s with a single break. I would
have thought it would discard the syntactically invalid <divtags and
produce something like:
The <DIV>s are not syntactically incorrect (in HTML). They just do
not mean what you think they do.
aaaaaaaaaabbbbbbbbbbcccccccccc
dddddddddd
...but instead it seems to ignore the idea the <div>s aren't allowed
within <p>s. Maybe it didn't attend the meeting. Or maybe it doesn't
think it should be in the business of enforcing syntax errors.
If IE doesn't assume P is closed when DIV opens, it is wrong.
Does that sound like what's happening?

--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
Consider what might be fertilizing the greener grass across the fence.
Dec 20 '06 #17

P: n/a
On 20 Dec 2006 22:42:25 GMT, Lars Eighner <us****@larseighner.com>
wrote:

In our last episode,
<7o********************************@4ax.com>,
the lovely and talented Kent Feiler
broadcast on comp.infosystems.www.authoring.html:
On Tue, 19 Dec 2006 14:09:48 -0600, Kent Feiler <zz**@zzzz.com>
wrote:
1. Here's some html from a W3C recommendations page.
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>
------------------------------------------------------------------------------
I have to say that this newsgroup seems to have a higher percentage
of obnoxious creeps who post to it than most. But maybe I should
check out some of the religious newgroups, it may turn out that
everyone here is really quite polite and courteous!
----------------------------------------------------------------------
When you have not made the least effort to learn HTML, what do you
expect?
I rest my case.

Regards,
Kent Feiler
www.KentFeiler.com
Dec 21 '06 #18

P: n/a
Kent Feiler wrote:
It looks like in IE7 a <pCAN contain a <divwhich accounts for the
difference between #1 and #2 when we add the </p>s. The <pin #1
probably doesn't end until it hits the second <p>.
I'm never surprised by IE getting things wrong.

Firefox is right, and is consistant with the W3C Recommendation, as is
Opera, Safari and iCab. IE 5 for Mac gets things right too.

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

Dec 21 '06 #19

P: n/a
Welcome to MAX web Solution's Website, a full service affordable
offshore web site design, Search Engine marketing and web development
company based in Kathmandu. We focus on e business solutions at low
prices serving the needs of small to medium businesses all over the
world. We offer a wide range of custom web site design development and
seo services at affordable prices starting from small presentation
sites to complex multifunctional web portals and advanced custom
e-commerce business solutions.
Service is everything - your satisfaction is guaranteed
That is why we would gladly accept the responsibility of taking care of
your site. We want to save your time, so that you could devote yourself
to the most important thing - your business. Allow us to maintain and
support your web site.
Money back guarantee
A 30 Day money back guarantee for the first monthly fee.
You can also response to this message.

Fillup the below information for further inquarry.
Contact Name :
Organization Name:
E-mail Address :
Phone no:
Call us for Demostration
Call : 2390177 / 9841206820
Check it out for more information
http://www.max-online.biz/idevaffili...ate.php?id=749

Dec 24 '06 #20

P: n/a
In message <1N******************************@golden.net>, Gus Richter
<gu********@netscape.netwrites
>Don't ask for proof for I won't bother to search for it. You know that
this is so.
Yup, that's convinced me.

--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/?
Dec 29 '06 #21

P: n/a
In message <v3********************************@4ax.com>, Kent Feiler
<zz**@zzzz.comwrites
>I have to say that this newsgroup seems to have a higher percentage
of obnoxious creeps who post to it than most. But maybe I should
check out some of the religious newgroups, it may turn out that
everyone here is really quite polite and courteous!
----------------------------------------------------------------------
When you have not made the least effort to learn HTML, what do you
expect?
I rest my case.
It clearly hasn't occurred to you that many people might regard someone
who comes in, demanding answers to questions which they can easily find
on-line, and then complaining when they're given helpful answers anyway,
as impolite and discourteous, or even as an obnoxious creep.

--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/?
Dec 29 '06 #22

P: n/a
On Wed, 20 Dec 2006 18:50:27 +0000 (UTC), Darin McGrew
<mc****@stanfordalumni.orgwrote:

Kent Feiler <zz**@zzzz.comwrote:
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>cccccccc<P>dddddddd</DIV>
In http://www.w3.org/TR/REC-html40/stru...l.html#h-7.5.4 the
example
is actually

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

but I like your version better.

There is no syntax error in the HTML. Since DIV elements are not
allowed inside P elements, and since the closing </Ptag is optional,
the closing of the P element is implied by the opening of the DIV
element.
---------------------------------------------------------------------

I apoligize for dragging this out. I understand that DIV elements are
not allowed inside P elements and I understand that the closing </p>
tag is optional, but unless it's somewhere stated what a browser
should DO when it finds a DIV that appears to be intended to be inside
a P, it seems like a browser-philosopy issue. Should the browser
assume that the html writer just forgot to insert the </pbefore the
<divand put one in for him, or should it assume that the html writer
didn't know that <div>s weren't allowed within <p>s and forget about
the W3C recomendation? On the third hand, if a browser really wants to
enforce the W3C recomendation maybe it should discard the two <div>s.

In the end, the browser is just trying to make a sensible screen out
of whatever piece of html crap is presented to it. I'd vote for the FF
method, but I have some sympathy for the IE idea, that may be what the
html writer really intended.
Regards,
Kent Feiler
www.KentFeiler.com
Jan 2 '07 #23

P: n/a
<li********************************@4ax.com>,
the lovely and talented Kent Feiler
broadcast on comp.infosystems.www.authoring.html:
I apoligize for dragging this out. I understand that DIV elements are
not allowed inside P elements and I understand that the closing </p>
tag is optional, but unless it's somewhere stated what a browser
should DO when it finds a DIV that appears to be intended to be inside
a P, it seems like a browser-philosopy issue.
How could the browser possibly judge that that a DIV "appears to be intended
to be inside a P"?
Should the browser assume that the html writer just forgot to insert the
</p>
The closing tag is *optional*. Many authors know the rules and simple don't
waste the keystrokes to put in the optional tags. They did not forget. The
knew the rules and expected a conforming browser to abide by them. You seem
to be saying that authors who study the rules and know how to use them
should have there documents second-guessed because some people just put any
old slop on the web and have never looked at a DTD in their lives.

before the <divand put one in for him, or should it assume that the html
writer didn't know that <div>s weren't allowed within <p>s and forget
about the W3C recomendation? On the third hand, if a browser really wants
to enforce the W3C recomendation maybe it should discard the two <div>s.
Nonsense. This is from the W3C 4.01 spec, a document you still show no sign
of having ever read:

+ A user agent must ensure that rendering is unchanged by the
presence or absence of start tags and end tags when the HTML
DTD indicates that these are optional. See the section on
element definitions for introductory information on SGML
elements.

See that word "must"? A conforming browser *must* treat:

<p>blah blah blah<div>yadda yadda</div>

exactly like:

<p>blah blah blah</p><div>yadda yadda</div>
In the end, the browser is just trying to make a sensible screen out
of whatever piece of html crap is presented to it. I'd vote for the FF
method, but I have some sympathy for the IE idea, that may be what the
html writer really intended.
--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
An effective way to deal with predators is to taste terrible.
Jan 2 '07 #24

P: n/a
VK
Kent Feiler wrote:
I apoligize for dragging this out. I understand that DIV elements are
not allowed inside P elements and I understand that the closing </p>
tag is optional, but unless it's somewhere stated what a browser
should DO when it finds a DIV that appears to be intended to be inside
a P, it seems like a browser-philosopy issue.
There is no philosophy here: purely technical aspect plus a leftover of
the "HTML childhood". That was explained N times already but let's make
N+1th time:
>From the very beginning and until relatively recently P element was not
a container: it was an element w./o content marking _paragraph break_

This way originally in HTML there were paired elements "small" line
break BR and "big" paragraph break P. Respectively BR marked the
beginning of the next line and P marked the beginning of the next
paragraph.

When later it was decided to promote P into container the task was do
not break millions of already existing pages. The compromise rule was
made as simple as moo-cow:

New paragraph starts with the opening <Ptag and ends by closing </P>
tag or by opening tag of a block element - whatever comes first.

I fail to find any "browser philosophy" in here.

Jan 2 '07 #25

P: n/a
VK <sc**********@yahoo.comwrote:
From the very beginning and until relatively recently P element was not
a container: it was an element w./o content marking _paragraph break_
Do you really consider HTML 2.0 "relatively recently" in the history of
HTML? The P element has been a container (with an optional closing tag)
since then.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"I'd love to make time, if only I could find the recipe."
Jan 2 '07 #26

P: n/a
VK
Darin McGrew wrote:
Do you really consider HTML 2.0 "relatively recently" in the history of
HTML? The P element has been a container (with an optional closing tag)
since then.
This comment is correct: but only from the modern point of view.

The time we are talking about RFC HTML specs were of the same public
interest as the average density of Jupiter is right now. Besides of a
very few extremely curious people around the world - everyone else was
reading Netscape specs and testing on the current Netscape release. To
the honor of Netscape they stated from the beginning that "despite
closing </Ptag has no sense, we encourage you to use it in case of
future changes" (by memory quote). But an average developer even at
that far time was pretty much the same as it is right now: skip on any
keystroke one can skip and to use only absolutely necessary things :-)

The first more or less wide interest to HTML standards appeared only
closer to the end of Browser Wars when standard/non-standard topic was
used as a propaganda tool to fight the rival. By that time it was
already absolutely irrelevant what <Pis or should be - the only
really important matter was to never break millions of legacy pages.

Jan 3 '07 #27

P: n/a
VK

VK wrote:
From the very beginning and until relatively recently P element was not
a container: it was an element w./o content marking _paragraph break_

This way originally in HTML there were paired elements "small" line
break BR and "big" paragraph break P. Respectively BR marked the
beginning of the next line and P marked the beginning of the next
paragraph.

When later it was decided to promote P into container the task was do
not break millions of already existing pages. The compromise rule was
made as simple as moo-cow:

New paragraph starts with the opening <Ptag and ends by closing </P>
tag or by opening tag of a block element - whatever comes first.
I guess the question "why P is not like everyone else?" and similar
will stay forever, so I will bookmark this segment of the thread for
future quick references. For the same purpose I'll include in here the
answer on your original question:

Both
<P>aaa<DIV>bbb</DIV><DIV>ccc<P>ddd</DIV>
and
<P>aaa</P><DIV>bbb</DIV><DIV>ccc<P>ddd</P></DIV>
produce the same tree fragment:

#parent_node
|_
#P
|_#text aaa
|
#DIV
|_#text bbb
|
#DIV
|_#text ccc
|_#P
|_#text ddd

because P element will be auto-closed before any block-level element
even if closing tag is ommited. It is important that block-level vs
inline detection goes by default display and not by the current display
style.
This way
<P>aaa<DIV style="display:inline">bbb</DIV><DIV
style="display:inline">ccc<P>ddd</DIV>
doesn't change anything in the parsing process. If you are really
targeted to be surprised by something in HTML :-) then the latter is
much more appropriate subject :-)
At the same time say this source:
<P>aaa<DIV>bbb</DIV></P>
will produce tree fragment:

#parent_node
|_
#P
|_#text aaa
|
#DIV
|_#text bbb

because P will be automatically closed before opening <DIV>, so besides
other "surprises" you are getting unmatched closing </Ptag after
</DIV>. While HTML doesn't care of such details, XHTML parser will
complain.

Jan 3 '07 #28

P: n/a

Kent Feiler wrote:
I understand that DIV elements are
not allowed inside P elements and I understand that the closing </p>
tag is optional, but unless it's somewhere stated what a browser
should DO when it finds a DIV that appears to be intended to be inside
a P, it seems like a browser-philosopy issue.
It is stated, although it's not directly stated and it's not clearly
stated.

"Browser philosophy" issues would be things like the rendering of
invalid HTML (and whether to even try), default stylesheets and error
recoveries. The parsing of tags into the elements that structure the
document model though is simple SGML behaviour pre-dating HTML, isn't
an error and is clearly defined with a single clear interpretation (for
most cases). Admittedly finding this definition requires knowing that
HTML is an SGML application and knowing where to find the SGML
definitions themselves.

Omitted closing tags aren't in any way "wrong" in the SGML context,
because SGML has always defined its parsing behaviour from a partial
set of tags plus a DTD into a complete document structure as a tree of
elements. Obviously the DOM elements are always closed and well nested
(the DOM can't hold a structure that isn't) and so every parsing
operation _must_ transform one to the other (or raise an error).
According to SGML's rules and for HTML that's still valid (even if
stripped of many closing tags) this mapping is a defined and
non-ambiguous process.

If you read the release notes for Tidy then there's a little
explanation of how far this strategy can go and what the awkward cases
are that can break it.

SGML set out with a design principle of allowing tags to be omitted
where practical, as a way of reducing verbosity. XML takes the opposite
approach and requires that documents (tag to element parsing anyway)
are parseable in isolation from their DTDs. This also requires them to
not use the tag omission rules, as in the abbsence of a DTD there's no
way to tell what the implied closures would be. XML has the
side-effect of making thhe document more easily human-readable too, or
at least more accurately human readable. Humans have historically been
bad at correctly interpreting terse SGML documents with much
implication in them.

Jan 4 '07 #29

This discussion thread is closed

Replies have been disabled for this discussion.