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

Lack of end tag messes up form styling - a known bug?

P: n/a
My basic style sheet has a distinctive background and border for forms,
to make the structure clearer and to make it visually evident what
belongs to a form.

However, as people complained that some forms were odd-looking, I
noticed that indeed, fairly often the background is not applied and
there is empty space inside a form I didn't ask for. This was rather
puzzling until I realized that the observed cases seem to result from
one single "error" in my markup.

The "error" is lack of the "optional" </ptag right before a form. That
is,
<p>paragraph text
<form ...>
causes the trouble. For a simple illustration, check
http://www.cs.tut.fi/~jkorpela/test/form.html
on IE 7. (When </pis omitted, the background set for the form is not
there, except for a thin stripe at the top.)

For years, browsers have been reported to behave wrongly when "optional"
end tags for elements are omitted. But this form-related problem appears
even on IE 7, and I don't remember having seen notes about this
particular type of bug elsewhere. What did I miss?

My conclusion is that "optional" end tags should not be omitted. There
is little hope of having browsers fixed, I'm afraid. What we _can_ do is
to stop using "handy" SGML features like tag omissibility.

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

Jun 27 '08 #1
Share this Question
Share on Google+
40 Replies


P: n/a
In article <5g********************@reader1.news.saunalahti.fi >,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
My basic style sheet has a distinctive background and border for forms,
to make the structure clearer and to make it visually evident what
belongs to a form.

However, as people complained that some forms were odd-looking, I
noticed that indeed, fairly often the background is not applied and
there is empty space inside a form I didn't ask for. This was rather
puzzling until I realized that the observed cases seem to result from
one single "error" in my markup.

The "error" is lack of the "optional" </ptag right before a form. That
is,
<p>paragraph text
<form ...>
causes the trouble. For a simple illustration, check
http://www.cs.tut.fi/~jkorpela/test/form.html
on IE 7. (When </pis omitted, the background set for the form is not
there, except for a thin stripe at the top.)

For years, browsers have been reported to behave wrongly when "optional"
end tags for elements are omitted. But this form-related problem appears
even on IE 7, and I don't remember having seen notes about this
particular type of bug elsewhere. What did I miss?

My conclusion is that "optional" end tags should not be omitted. There
is little hope of having browsers fixed, I'm afraid. What we _can_ do is
to stop using "handy" SGML features like tag omissibility.
I've run into this a couple of times, and usually it has to do with
the way a specific user agent infers where the missing end tag
should be, based on the content of the html file. (In my case,
however, it had nothing to do with forms.)

I've noticed on a couple of occasions that the W3C validator picks
up on these things, and will explicitly state what it has decided
to do when encountering a missing optional end tag; this choice is
rarely what I meant! But then, I am not as familiar with the full
scope of the html spec as the authors of the validator software...

The upshot is that, for purely practical reasons, I always include
"optional" end tags
Jun 27 '08 #2

P: n/a
David Stone wrote:
I've run into this a couple of times, and usually it has to do with
the way a specific user agent infers where the missing end tag
should be, based on the content of the html file. (In my case,
however, it had nothing to do with forms.)
It should be easy to check what the UA has inferred by using some
Javascript to report on the DOM tree. Does the tree differ depending on
whether or not the end tag is there?
Jun 27 '08 #3

P: n/a
Jukka K. Korpela wrote:
My basic style sheet has a distinctive background and border for forms,
to make the structure clearer and to make it visually evident what
belongs to a form.

However, as people complained that some forms were odd-looking, I
noticed that indeed, fairly often the background is not applied and
there is empty space inside a form I didn't ask for. This was rather
puzzling until I realized that the observed cases seem to result from
one single "error" in my markup.

The "error" is lack of the "optional" </ptag right before a form. That
is,
<p>paragraph text
<form ...>
causes the trouble. For a simple illustration, check
http://www.cs.tut.fi/~jkorpela/test/form.html
on IE 7. (When </pis omitted, the background set for the form is not
there, except for a thin stripe at the top.)
Strangely it does display correctly in IE 4-6 And folks wonder why I am
cynical about future IE8's compliance.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Jun 27 '08 #4

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
My conclusion is that "optional" end tags should not be omitted. There
is little hope of having browsers fixed, I'm afraid. What we _can_ do is
to stop using "handy" SGML features like tag omissibility.
David Stone <no******@domain.invalidwrote:
The upshot is that, for purely practical reasons, I always include
"optional" end tags
Same here. For a while now, I've been using spam/ospam to add optional
closing tags (and optional quotes around attribute values). It helps
browsers (and browser-like OS components) handle CSS more consistently.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Advice is what you ask for when you know the answer but wish you didn't."
Jun 27 '08 #5

P: n/a
In article <66*************@mid.individual.net>,
Harlan Messinger <hm*******************@comcast.netwrote:
David Stone wrote:
I've run into this a couple of times, and usually it has to do with
the way a specific user agent infers where the missing end tag
should be, based on the content of the html file. (In my case,
however, it had nothing to do with forms.)

It should be easy to check what the UA has inferred by using some
Javascript to report on the DOM tree. Does the tree differ depending on
whether or not the end tag is there?
I don't know, I don't do Javascript. Might be interesting to
see what FireBug does with things like that. As I said in the
original post, however, I just explicitly include all "optional"
end tags anyway, so the point is moot.
Jun 27 '08 #6

P: n/a
VK
On Apr 10, 2:48 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
The "error" is lack of the "optional" </ptag right before a form.
The P element is being changed from the original paragraph separator
to a block element back in HTML 3.2 or even earlier if I recall
properly. The last time I saw P used as a paragraph separator on the
Web is about 1997-98, so your sample is the first in over ten years.
What actuality do you actually imply by your case?
Jun 27 '08 #7

P: n/a
VK <sc**********@yahoo.comwrites:
On Apr 10, 2:48 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
>The "error" is lack of the "optional" </ptag right before a form.

The P element is being changed from the original paragraph separator
to a block element back in HTML 3.2 or even earlier if I recall
properly. The last time I saw P used as a paragraph separator on the
Web is about 1997-98, so your sample is the first in over ten years.
What actuality do you actually imply by your case?
Not so fast. From the HTML 4.01 specs,
http://www.w3.org/TR/html4/struct/text.html#edef-P
9.3.1 Paragraphs: the P element

<!ELEMENT P - O (%inline;)* -- paragraph -->
<!ATTLIST P
%attrs; -- %coreattrs, %i18n, %events --
>
Start tag: required, End tag: optional

Note the last word. Now, since FORM is a block-level element, it should
AFAICT close a P tag, since a P tag cannot contain another block-level
element. Please also note that because of all kinds of inconsistencies,
I agree (if that's your point) that it's far more worth-while to just
close all damn tags appropriately, even if that's "optional" and focus
on what issues are left.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jun 27 '08 #8

P: n/a
VK
On Apr 11, 1:23 am, Joost Diepenmaat <jo...@zeekat.nlwrote:
VK <schools_r...@yahoo.comwrites:
On Apr 10, 2:48 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
The "error" is lack of the "optional" </ptag right before a form.
The P element is being changed from the original paragraph separator
to a block element back in HTML 3.2 or even earlier if I recall
properly. The last time I saw P used as a paragraph separator on the
Web is about 1997-98, so your sample is the first in over ten years.
What actuality do you actually imply by your case?

Not so fast. From the HTML 4.01 specs,http://www.w3.org/TR/html4/struct/text.html#edef-P

9.3.1 Paragraphs: the P element

<!ELEMENT P - O (%inline;)* -- paragraph -->
<!ATTLIST P
%attrs; -- %coreattrs, %i18n, %events --
>

Start tag: required, End tag: optional
I did not mean that it is wrong. I am well aware of "P issue" and
explained it several times at ciwah - where this issue is better
suited IMO - see for instance
http://groups.google.com/group/comp....1685c07c06d971

I am just saying that no one ever widely used it even at the time when
P was officially a paragraph break and not a container - except some
really amateurish pages. So making an issue out of it now is kind of
checking XMP or ISINDEX tag support amidst modern browsers.

IMHO

Jun 27 '08 #9

P: n/a
VK
On Apr 11, 2:07 am, VK <schools_r...@yahoo.comwrote:
I am just saying that no one ever widely used it even at the time when
P was officially a paragraph break and not a container - except some
really amateurish pages.
"no one ever widely used it" refers to the "permission" to omit the
closing tag, not to P element itself, of course.
Jun 27 '08 #10

P: n/a
VK wrote:
>
The P element is being changed from the original paragraph separator
to a block element back in HTML 3.2 or even earlier if I recall
properly.
Huh? What is this "paragraph separator" you speak of? If it is in fact
<p>, that is and always has been a block element.

http://www.faqs.org/rfcs/rfc1866.html

Go to section 5.5
The last time I saw P used as a paragraph separator on the
Web is about 1997-98,
If you aren't using <pto mark up paragraphs, what pray tell *are* you
using?

--
Berg
Jun 27 '08 #11

P: n/a
VK
On Apr 11, 2:19 am, Bergamot <berga...@visi.comwrote:
Huh? What is this "paragraph separator" you speak of? If it is in fact
<p>, that is and always has been a block element.
No offense, but you were too young that time to remember I guess.
Initially there were paragraph break P (with adding space between
lines) and BR (w/o adding space). And numerous manual suggestions to
still "use </Pdespite it is meaningless now because the meaning of
this element should change and hopefully will change soon".

Please read the linked post at
http://groups.google.com/group/comp....1685c07c06d971

- it is boring to answer such FAQ over and over again.
Jun 27 '08 #12

P: n/a
VK <sc**********@yahoo.comwrites:
On Apr 11, 2:07 am, VK <schools_r...@yahoo.comwrote:
>I am just saying that no one ever widely used it even at the time when
P was officially a paragraph break and not a container - except some
really amateurish pages.

"no one ever widely used it" refers to the "permission" to omit the
closing tag, not to P element itself, of course.
I don't think that's true, but that depends on your definition of
"amateurish". Not having to close some tags makes it easier to write
HTML by hand, and besides, it's not a '"permission"', it's *explicitely
allowed*. That's not to say that this kind of implicit closing can't
lead to all kinds of problems, but AFAICT that's mostly an
implementation issue...

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jun 27 '08 #13

P: n/a
Scripsit Joost Diepenmaat:
VK <sc**********@yahoo.comwrites:
>On Apr 11, 2:07 am, VK <schools_r...@yahoo.comwrote:
>>I am just saying that no one ever widely used it even at the time
when P was officially a paragraph break and not a container -
except some really amateurish pages.

"no one ever widely used it" refers to the "permission" to omit the
closing tag, not to P element itself, of course.

I don't think that's true, but that depends on your definition of
"amateurish".
I'm afraid you just have to learn to ignore "VK" as many people
presumably do. "VK" is apparently not even an amateur in HTML matters
but this does not prevent her, him, or it from posting opinions and
advice on them.

(P was _never_ officially a paragraph break. The first HTML
specification was HTML 2.0, and it clearly defines P as an element
indicating a paragraph. I don't think "VK" even ever read an HTML
specification.)

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

Jun 27 '08 #14

P: n/a
Bergamot <be******@visi.comwrites:
VK wrote:
>>
The P element is being changed from the original paragraph separator
to a block element back in HTML 3.2 or even earlier if I recall
properly.

Huh? What is this "paragraph separator" you speak of? If it is in fact
<p>, that is and always has been a block element.
Tim Berners-Lee original HTML 1.0 DTD declared P elements to be empty.
Thus, for a very short time, </Pwas not valid syntax. The draft
(never even made it to RFC) calls it a "paragraph separator".

--
Ben.
Jun 27 '08 #15

P: n/a
VK <sc**********@yahoo.comwrites:
On Apr 10, 2:48 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
>The "error" is lack of the "optional" </ptag right before a form.

The P element is being changed from the original paragraph separator
to a block element back in HTML 3.2 or even earlier if I recall
properly. The last time I saw P used as a paragraph separator on the
Web is about 1997-98, so your sample is the first in over ten years.
There was a short time (two years: 1993-95) during which it was not
permitted to write <P>...</Pbecause the original DTD stated that P
elements were empty.

HTML 2 (RFC 1866) changed that and at the same time stated that the
closing tag was optional. That was repeated by HTML 3.2 and then by
HTML 4.01. Thus, for all time, a lone <Phas been valid syntax. The
closing has been either prohibited or optional forever, so it seem
harsh to find its use surprising.

I find it sad that this most basic element is not properly parsed.
There is no excuse (that I can see) for any browser (old or new) to
expect a <Pto be closed explicitly.
What actuality do you actually imply by your case?
What did it ever mean but a paragraph?

--
Ben.
Jun 27 '08 #16

P: n/a
VK wrote:
On Apr 11, 2:19 am, Bergamot <berga...@visi.comwrote:
>Huh? What is this "paragraph separator" you speak of? If it is in fact
<p>, that is and always has been a block element.

Please read the linked post at
http://groups.google.com/group/comp....1685c07c06d971
I did. It's gibberish.
- it is boring to answer such FAQ over and over again.
Then why don't you refrain from saying anything at all? ;)

--
Berg
Jun 27 '08 #17

P: n/a
Ben Bacarisse wrote:
Bergamot <be******@visi.comwrites:
>What is this "paragraph separator" you speak of? If it is in fact
<p>, that is and always has been a block element.

Tim Berners-Lee original HTML 1.0 DTD declared P elements to be empty.
Thus, for a very short time, </Pwas not valid syntax. The draft
(never even made it to RFC) calls it a "paragraph separator".
I looked as far back as the HTML 2.0 spec but guess that wasn't far
enough. Leave it VK to dredge up something this old and make it sound
like it's had any relevance for the last 10+ years. :-\

--
Berg
Jun 27 '08 #18

P: n/a
Scripsit Jonathan N. Little:
>For a simple illustration, check
http://www.cs.tut.fi/~jkorpela/test/form.html
on IE 7. (When </pis omitted, the background set for the form is
not there, except for a thin stripe at the top.)

Strangely it does display correctly in IE 4-6 And folks wonder why I
am cynical about future IE8's compliance.
I have a _bad_ feeling about this...

Indeed, this bug exists in IE 7 in "standards mode" only. The version
http://www.cs.tut.fi/~jkorpela/test/form2.html
that lacks a DOCTYPE declaration (thereby throwing IE 7 into "quirks
mode") works properly.

Surprisingly, I'm not even surprised.

I'll add this to my document on "quirks mode",
http://www.cs.tut.fi/~jkorpela/quirks-mode.html

I guess this in analogous with IE 7's failure to recognize valid entity
references like &Omega when they lack the "optional" semicolon, except
that the reference bug exists in both modes. That is, IE 7 plays by some
XHTML rules, even for non-XHTML documents (and even though IE 7 does not
grok XHTML).

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

Jun 27 '08 #19

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fiwrites:
For years, browsers have been reported to behave wrongly when
"optional" end tags for elements are omitted. But this form-related
problem appears even on IE 7, and I don't remember having seen
notes about this particular type of bug elsewhere
Opera 9.27 (on XP) is getting it wrong too. The yellow box for the
first form is thin (4 px high) sitting above its form. Inspecting the
DOM shows that the FORM is a child of the P that ought to have ended.
DIV is a child of BODY; the submit works despite that.
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pe*********@westerngeco.com -./\.- the opinion of Schlumberger or
http://petef.22web.net -./\.- WesternGeco.
Jun 27 '08 #20

P: n/a
Bergamot <be******@visi.comwrites:
Ben Bacarisse wrote:
>Bergamot <be******@visi.comwrites:
>>What is this "paragraph separator" you speak of? If it is in fact
<p>, that is and always has been a block element.

Tim Berners-Lee original HTML 1.0 DTD declared P elements to be empty.
Thus, for a very short time, </Pwas not valid syntax. The draft
(never even made it to RFC) calls it a "paragraph separator".

I looked as far back as the HTML 2.0 spec but guess that wasn't far
enough. Leave it VK to dredge up something this old and make it sound
like it's had any relevance for the last 10+ years. :-\
Oh, and I was not implying that it had any relevance except to explain
where the confusion might come from. It was never anything more that
a draft. HTML 2.0 was the first real specification that mattered.

--
Ben.
Jun 27 '08 #21

P: n/a
Ben Bacarisse wrote:
Bergamot <be******@visi.comwrites:
>like it's had any relevance for the last 10+ years. :-\

Oh, and I was not implying that it had any relevance except to explain
where the confusion might come from.
I wasn't implying that you were implying anything else. :)
It was never anything more that
a draft. HTML 2.0 was the first real specification that mattered.
That's what I thought.

cheers

--
Berg
Jun 27 '08 #22

P: n/a
Jukka K. Korpela wrote:
>
(P was _never_ officially a paragraph break. The first HTML
specification was HTML 2.0, and it clearly defines P as an element
indicating a paragraph. I don't think "VK" even ever read an HTML
specification.)
P was a paragraph break in HTML 1.0, but I don't believe that ever
moved past IETF internet-draft status, so I'd agree that doesn't count
as "official".

From the 1993 HTML 1.0 internet-draft [1]:

<!ELEMENT P - O EMPTY -- separates paragraphs -->

The "EMPTY" indicates that the P element has no content. Also, the
body of the i-d states: "The empty P element indicates a paragraph break".

By the 1995 HTML DTD [2], P was a container:

<!ELEMENT P - O (%text)*>

The HTML DTD change log [3] indicates that P was made a container in
April 1994:

-----
revision 1.7.2.2
date: 1994/04/01 20:30:17; author: connolly; state: Exp; lines: +38 -95
Changed P, LI, DT, DD from EMPTY to containers.
-----

So there you have it. P was a paragraph break before April 1994, but
that was never recognized as an "official" standard; it had already
become a container when HTML 2.0 was standardized as an RFC.

And my guess is that, contrary to VK's assertion, back in the pre-1994
HTML 1.0 days, when P was an empty element indicating a paragraph
break, probably most people omitted the optional end tag for it. Just
as they did for the BR element. (Somewhere I have some HTML I wrote in
1993, but I can't be bothered to dig it out right now to check it.)

In fact, in the current DTDs, "O" for the end tag together with
content type "EMPTY" means that the end tag *must* be omitted (see eg
HTML 4.01 3.3.3). I don't know if that true for HTML 1.0 as well; I
don't believe it can be represented in the DTD itself, so it's one of
the constraints that has to be defined in the specification outside
the DTD. The internet-draft [1] says "every non-empty element ends
with a tag", which could imply that "</P>" was illegal in HTML 1.0.
[1] http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
[2] http://www.w3.org/MarkUp/html-spec/html.dtd
[3] http://www.w3.org/MarkUp/html-spec/ChangeLog

--
Michael Wojcik
Jun 27 '08 #23

P: n/a
Scripsit Michael Wojcik:
P was a paragraph break in HTML 1.0, but I don't believe that ever
moved past IETF internet-draft status, so I'd agree that doesn't count
as "official".
Internet drafts have no status, and they themselves contain a
boilerplate disclaimer:

It is not appropriate to use Internet Drafts as reference material
or to cite them other than as a "working draft" or "work in
progress".

It is even incorrect to speak of HTML 1.0. The draft itself does not use
such an expression, but more importantly, it was never anything but a
draft. Of course HTML existed prior to HTML 2.0, but no specification
preceded it.

ObStylesheets: Although CSS wasn't even a draft at that time, it is
interesting to note that the Internet draft for HTML referred to "style
sheets" - namely in the description of the <Ptag:

The empty P element indicates a paragraph break. The exact
rendering of this (indentation, leading, etc) is not defined here,
and may be a function of other tags, style sheets etc.
P was a paragraph break before April 1994,
No, it wasn't; it is inappropriate to cite Internet Drafts as other than
a "working draft" or "work in progress". In terms of specifications, P
or any other tag was nothing before HTML 2.0 was defined. In terms of
practices and implementations, P was whatever authors used it for and
whatever browsers did upon enountering it - and this cannot be deduced
from Internet Drafts or other drafts as such.
but that was never recognized as an "official" standard;
It was never any kind of a specification, still less a standard in any
sense.
it had already
become a container when HTML 2.0 was standardized as an RFC.
It was defined as a container in HTML 2.0. It was not defined in any way
in any specification prior to that. Authoring and browser practices are
a different issue, and there seems to be a continuous tradition of
confusion and mess here.

Returning now to our agenda, style sheets, it's time to conclude that

1) for styling, it has always (as long as CSS has existed in any sense)
been good practice to put your paragraphs inside paragraph markup with
explicit start and end tags,
<p>...</p>

2) it has been and it still is very common practice to omit </ptags
(as well as omit paragraph markup altogether in many cases, e.g. writing
<h2>...</h2foo <p>
so that in terms of markup, and for styling, foo ain't no paragraph at
all).

Good browsers would acknowledge (2), as well as HTML specifications that
allow the omission of </p>, but browsers aren't going to be good. So
authors need to be good authors and apply (1).
In fact, in the current DTDs, "O" for the end tag together with
content type "EMPTY" means that the end tag *must* be omitted (see eg
HTML 4.01 3.3.3).
It means that in any DTD by the SGML standard. (Beware that HTML
specifications, not to mention drafts, are sloppy in SGML matters,
though the HTML 2.0 specification is a great improvement over its
successors in this respect, too.)
I don't know if that true for HTML 1.0 as well;
There was no HTML 1.0, but the DTD in the Internet Draft meant, if
anything, an SGML DTD.
I don't believe it can be represented in the DTD itself, so it's one
of
the constraints that has to be defined in the specification outside
the DTD.
Declaring EMPTY content model inevitably implies that an end tag is
formally prohibited. See the quotation from the SGML standard (as quoted
in The SGML Handbook) at
http://www.cs.tut.fi/~jkorpela/html/empty.html#sgml

Beyond that, there is nothing a DTD needs to do, and nothing it could
do, to prohibit an end tag for an element that it declares.
The internet-draft [1] says "every non-empty element ends
with a tag", which could imply that "</P>" was illegal in HTML 1.0.
Non sequitur, but the DTD in the Internet Draft prohibited </P>. This,
on the other hand, is merely a statement of the content of a working
draft that expired ages ago.

Browsers have always been inconsistent in the treatment of paragraph
tags, and they still have tag soup oriented processing that treats
sometimes <p>, sometimes </p>, sometimes both as "paragraph break" and
possibly as "leave an empty line" command. Such tag soup processing is
not consistent with the ideas of modern HTML, or CSS, or DOM, but it's
still with us. And using <p>...</pis best hope against it.

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

Jun 27 '08 #24

P: n/a
VK
On Apr 12, 9:40 am, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
Internet drafts have no status, and they themselves contain a
boilerplate disclaimer:

It is not appropriate to use Internet Drafts as reference material
or to cite them other than as a "working draft" or "work in
progress".
You are making a common mistake of the younger generation. By "younger
generation" I do not mean your physical age which I don't know and
that I am not asking about. I mean people who came into Web
development after the Browser Wars. Due to the lack of personal
experience they have to rely on "official history sources" like say
http://www.w3.org/Consortium/history and similar "corporate history of
success" and similar crap.
A few facts:
1) Preliminary HTML drafts, sketches, proposals, blue prints - name it
as you want - had the greatest impact on HTML/Web as it is now,
because NCSA Mosaic used them as the basis for their feature
extensions.
2) HTML 2.0 was a post factum attempt to describe the practice
resulted from Mosaic (in the first turn) and some other graphics UA
features.
3) W3C drafts and recomendations value was equal zero to the very end
of 1998. Only when Netscape realized that the war is lost, they
applied to W3C authority and introduced the promo schema "good
standards follower - bad standards violator" - which is rather funny
from the historical perspective to see it initiated either by Netscape
or Microsoft.
4) Until the very end of 1998 the only task of W3C in HTML was to
describe current practice imposed by NN/IE rivalry. Even that task was
never really completed until upcoming stagnation and Web slow down
gave enough time to W3C to prepare HTML 4.0

That is not call of a troll: I am not answering to any comments to
this part of the post nor expecting any. Just somewhere the things
have to be said. Sometimes the sh** hits the fan of listening someones
explanations "how everything really was", so like I was about 4 years
in the row in some LSD inspired dreamland and not in a California web
development company.
Returning now to our agenda, style sheets,
Right, it's about time
it's time to conclude that

1) for styling, it has always (as long as CSS has existed in any sense)
been good practice to put your paragraphs inside paragraph markup with
explicit start and end tags,
<p>...</p>
It is not really about styling: it is about understanding markup and
following its rule sincerely instead of pseudo-standardized fallacy.
If one has a container with some content inside, the content must be
placed between opening and closing tag. If one knows how to use the
fork and he has it, then it is not an excuse to grab a meal by hand,
even if one knows that people around may tolerate it.
This is why I hate to see, say, HTML Strict pages with all IFRAMEs
wrapped into SCRIPT blocks for dynamic insertion: "because IFRAME is
not allowed in Strict" - and at the same time using non-empty P
without closing tag: "because it is allowed". That is a stinkiest
fallacy one can imagine yet I was misfortune to see some real life
samples.
2) it has been and it still is very common practice to omit </ptags
Only in a very bad coding style of a few individuals. The real
professionals never do it; the real beginners do not use manual coding
and all authoring software uses syntax with closing tag.
(as well as omit paragraph markup altogether in many cases, e.g. writing
<h2>...</h2foo <p>
so that in terms of markup, and for styling, foo ain't no paragraph at
all).

Good browsers would acknowledge (2), as well as HTML specifications that
allow the omission of </p>, but browsers aren't going to be good. So
authors need to be good authors and apply (1).
Sustained.
Jun 27 '08 #25

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fiwrites:
http://www.cs.tut.fi/~jkorpela/test/form.html
Do you have the Developer Toolbar installed, BTW?

(it's pretty funny, both form elements are children of the paragraph
element, and the contents of the first form element cannot be inspected
at all; ditto with IE 8 beta [0] :)

If you only had pretended to be able to use XHTML syntax on the web
instead of pretending to be able to use HTML syntax on the web, this
wouldn’t have happened in the first place ;-)

[0] I checked for an update with Tools Windows Update before posting;
this is what I get back:

| Thank you for your interest in obtaining updates from our site.
|
| To use this site, you must be running Microsoft Internet Explorer 5 or
| later.

UA sniffing can’t get any more official :)

--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jun 27 '08 #26

P: n/a
On 10 avr, 06:48, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:

http://www.cs.tut.fi/~jkorpela/test/form.html
(When </pis omitted, the background set for the form is not
there, except for a thin stripe at the top.)

Jukka,

Good catch!

Recent news from IE blog indicates Microsoft's clear willingness
+determination to eradicate bugs of such types:

*"<Pelement now closes when <TABLEis encountered (ACID 2
compliance)."*
HTML and DOM Standards Compliance in IE8 Beta 1
Consistency and reliability with Standards and other browsers
from Travis Leithead, Thursday, April 10, 2008
http://blogs.msdn.com/ie/archive/200...e8-beta-1.aspx

Your bug is in a favorable position to be added in a to-fix-list and
then fixed for IE 8 final. How could Microsoft fix <p><tablebut not
<p><form>?

I could report your "unclosed <Ppreceding a form confuses rendering
in IE 7+" webpage in my IE7 and IE8 bugs webpages or even at
connect.microsoft.com The problem you see in IE 7 is even worse,
clearly more noticeable in IE 8 beta 1. Another idea is that you could
submit a bug report with the "Report a Webpage Problem Internet
Explorer 8.0 Beta" Add-On ... downloadable at

http://go.microsoft.com/fwlink/?LinkId=110518

Note that Firefox 2.0.0.13, Seamonkey 2.0a1, Safari 3.1, Opera 9.50
build 9903 all render your webpage correctly and the same.

Some recommendations. Remove the "Hello world" and just states
something like

<h1>An unclosed &lt;p&gt; preceding a &lt;form&gt; should be
implicitly closed in IE 7 and IE 8 beta 1</h1>

...

<h3>Expected results: the 2 forms above should look (render) exactly
the same.</h3>

<p>Firefox 2.0.0.13, Seamonkey 2.0a1, Safari 3.1, Opera 9.50 build
9903 all pass this test.</p>

and here, I usually insert 2 W3C validation buttons

Regards,

Grard
--
Internet Explorer 8 bugs
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/
Jun 27 '08 #27

P: n/a
On 12 Apr, 21:01, VK <schools_r...@yahoo.comwrote:
On Apr 12, 9:40 am, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
You are making a common mistake of the younger generation. By "younger
generation" I do not mean your physical age which I don't know and
that I am not asking about. I mean people who came into Web
development after the Browser Wars. D
Nurse!!!
Jun 27 '08 #28

P: n/a
On 11 Apr, 21:45, Michael Wojcik <mwoj...@newsguy.comwrote:
P was a paragraph break in HTML 1.0, but I don't believe that ever
moved past IETF internet-draft status, so I'd agree that doesn't count
as "official".
It's an interesting historical comment. For a bit more light on it,
read Haakon Lie's PhD thesis on the design of CSS.
Jun 27 '08 #29

P: n/a
On 12 avr, 19:45, Eric B. Bednarz <bedn...@fahr-zur-hoelle.orgwrote:
http://www.cs.tut.fi/~jkorpela/test/form.html

Do you have the Developer Toolbar installed, BTW?

(it's pretty funny, both form elements are children of the paragraph
element, and the contents of the first form element cannot be inspected
at all; ditto with IE 8 beta [0] :)
In IE 8 beta 1, the vertical padding of the form is shared by both
(<pand <form>) when you let the Developer tools outline the
containers with a blue thin border. Also, the DOM tree of nodes also
show problems: the <formis not shown as a sibling of the unclosed
<pbut as a child of the unclosed <p>. To better see/distinguish that
thin blue outline, you should remove the border's form.

Regards, Grard
--
Internet Explorer 7 bugs
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/
Jun 27 '08 #30

P: n/a
Scripsit GTalbot:
I could report your "unclosed <Ppreceding a form confuses rendering
in IE 7+" webpage in my IE7 and IE8 bugs webpages or even at
connect.microsoft.com The problem you see in IE 7 is even worse,
clearly more noticeable in IE 8 beta 1.
Go ahead if you like. I'm not testing IE 8 (for now at least), and I
specifically advice others not to use beta versions (in most cases), if
they do not want to actively participate in beta testing and report
problems - in particular, not to play with beta version browsers to test
their own pages (as opposite to helping companies to test their
products). I used IE 7 beta when preparing a book that discusses IE 7,
and it was rather frustrating (though interesting).

My main interest in this issue is to warn people (including myself) that
browsers still fail to process HTML by the specifications as regards to
things like end tag omission. That is, to emphasize that all paragraphs
be closed with </p>. I'm too lazy to do that for all old pages of mine,
but I'll try to remember this when problems emerge. Actually I just
changed my own DTD to require </p>.
Some recommendations.
I could do some of them, but...
<p>Firefox 2.0.0.13, Seamonkey 2.0a1, Safari 3.1, Opera 9.50 build
9903 all pass this test.</p>
I haven't tested it on those browsers.

I have no objection if you wish to copy my test page and modify it as
you like it.
and here, I usually insert 2 W3C validation buttons
I don't, even in cases like this. People who work on fixing browser bugs
should have handy shortcuts for using validators and checkers on any
page.

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

Jun 27 '08 #31

P: n/a
Scripsit Michael Wojcik:
>Internet drafts have no status,

Nonsense. They have the status of drafts. They have no status as
official standards.
This is boring and off-topic. If you like to say that a draft has the
status of draft, go ahead; it means nothing.
While it's
incorrect to cite an i-d as a standard, it's absolutely proper to cite
them in a historical context, as in "this was the text of this
internet-draft at this point in time".
But you cited it as "HTML 1.0".
And "HTML 1.0"
is widely recognized for that purpose.
No, it isn't. It is rarely used, and I have never seen it used except by
a person who doesn't know what he is talking about. It is useful only as
a cluelessness indicator.

And now I'm really bored.

ObCSS: CSS 1.0 and CSS 2.0 exist as W3C recommendations but are not
recommended by the W3C, and CSS 2.1 is designated as a draft that may
change at any moment without notice and should not be cited except as
work in progress, and CSS 3.0 is just a name for a mixture of sketches
(largely not even drafts). Isn't life wonderful? Yet, the situation is
better than with HTML before HTML 2.0, since there's a rough consensus
that CSS 2.1 is the "de facto" specification. (It's really just an
excuse for a plastic imitation of a surrogate of a feeble attempt at a
draft specification, but it's still useful, within its limits.)

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

Jun 27 '08 #32

P: n/a
On 15 avr, 18:38, GTalbot <newsgr...@gtalbot.orgwrote:

http://www.cs.tut.fi/~jkorpela/test/form.html
"
Building High Performance HTML Pages

Close Your Tags

Unlike Extensible Markup Language (XML), HTML has the notion of
implicitly closed tags. This includes frame, img, li, and p. If you
don't close these tags, Internet Explorer renders your pages just
fine. If you do close your tags, Internet Explorer will render your
pages even faster.
"
coming fromhttp://msdn.microsoft.com/workshop/author/perf/perftips.asp
and fromhttp://msdn2.microsoft.com/en-us/library/ms533020.aspx#Close_Your_Tags

Here's more. I downloaded Microsoft's IE8 beta 1 white paper

"HTML Improvements and Acid2" *_PDF_* document downloadable at
http://code.msdn.microsoft.com/ie8wh...?ReleaseId=572

and this is what you can read:

"
The P element represents a logical paragraph. Closing P tags are
optional in HTML 4.01. However, when
closing P tags are omitted, Internet Explorer 7 does not properly
close paragraphs when TABLE elements
are encountered. This results in some subsequent table content being
automatically included in the
current paragraph when that may or may not have been the author's
intent.
To be compliant with HTML 4.01, the P tag must close before any non-
inline element. The Acid2 test
uses a TABLE element to illustrate this problem for all the browsers.
"

Obviously, the above is not entirely correct... Only IE versions had
that problem ... and your webpage, Jukka, proved they didn't fix it
completely, thoroughly.

Regards,

Grard
--
Internet Explorer 8 bugs
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/
Jun 27 '08 #33

P: n/a
GTalbot <ne*******@gtalbot.orgwrites:
>Close Your Tags
Uh huh.
>Unlike Extensible Markup Language (XML), HTML has the notion of
implicitly closed tags. This includes frame, img, li, and p. If you
don't close these tags, Internet Explorer renders your pages just
fine.
<h1<i>I don’t think so</i></h1>
>If you do close your tags, Internet Explorer will render your
pages even faster.
"
coming fromhttp://msdn.microsoft.com/workshop/author/perf/perftips.asp
A space before the protocol might help. :)

--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jun 27 '08 #34

P: n/a
GTalbot <ne*******@gtalbot.orgwrites:
Eric B. Bednarz <bedn...@fahr-zur-hoelle.orgwrote:
If I wanted to mangle that address, I could do so myself, thanks.

[IE 8 developer toolbar]
>[…] both form elements are children of the paragraph element […]
[…] Also, the DOM tree of nodes also
show problems: the <formis not shown as a sibling of the unclosed
<pbut as a child of the unclosed <p>.
Ah, I thought it was shown as a child of the P element node. Thanks for
clearing that up. This HTML stuff is pretty tough.
To better see/distinguish that
thin blue outline, you should remove the border's form.
I added neither a thin blue outline nor a border’s form to anything in
the first place. :)

--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jun 27 '08 #35

P: n/a
On 16 avr, 16:59, Eric B. Bednarz <bedn...@fahr-zur-hoelle.orgwrote:
GTalbot <newsgr...@gtalbot.orgwrites:
Close Your Tags

Uh huh.
Unlike Extensible Markup Language (XML), HTML has the notion of
implicitly closed tags. This includes frame, img, li, and p. If you
don't close these tags, Internet Explorer renders your pages just
fine.

<h1<i>I dont think so</i></h1>
Hello Eric,

Of course, I don't think so too. Jukka's webpage (and acid2 test on IE
7 and lower) proves that not including the end tag can have
consequences on IE page rendering.
coming fromhttp://msdn.microsoft.com/workshop/author/perf/perftips.asp

A space before the protocol might help. :)
That was a quick copy and paste.

Regarding the thin blue outline, that comment was meant for Jukka.
When one uses Developer Tools in IE 8 b1, this thin blue outline
appears on selected containers like <pand <form>. By removing the
form {border: solid #333 1px; }
from Jukka's original testcase, we can then better see how IE8 b1
defines, shows graphically the containers. I could upload a screen
shot of what one sees in IE8b1 to clarify all this.

Regards, Grard
Jun 27 '08 #36

P: n/a
GTalbot <ne*******@gtalbot.orgwrites:
Eric B. Bednarz wrote:
><h1<i>I don’t think so</i></h1>
Of course, I don't think so too.
Your humor parser is in need of improvement.
With SHORTTAG YES in the SGML declaration, TAGC can be omitted (“close
your tags” =“unclosed tags”, an actual feature). That’s quite
different from end-tag omission (needs SHORTTAG YES all the same, but
requires omission to be allowed in the document type declaration subset
as well).
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Jun 27 '08 #38

P: n/a
On 16 avr, 19:06, GTalbot <newsgr...@gtalbot.orgwrote:
I'll create a bug report at connect.feedback IE 8 beta later.
Done:

Bug 338580: An unclosed <pimmediately preceding a form element
should be implicitly closed by IE when parsing and building DOM tree
https://connect.microsoft.com/IE/fee...dbackID=338580

I believe you need to be registered to be able to vote or comment on
this bug entry.

Regards, Grard
--
Internet Explorer 8 bugs
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/
Jun 27 '08 #39

P: n/a
On 16 avr, 19:09, Eric B. Bednarz <bedn...@fahr-zur-hoelle.orgwrote:
With SHORTTAG YES in the SGML declaration, TAGC can be omitted (close
your tags =unclosed tags, an actual feature). Thats quite
different from end-tag omission (needs SHORTTAG YES all the same, but
requires omission to be allowed in the document type declaration subset
as well).
From now on, I'll say "omitting optional end-tag" instead of unclosed
<p>.

Regards, Grard
Jun 27 '08 #40

P: n/a
On 16 avr, 02:18, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
My main interest in this issue is to warn people (including myself) that
browsers still fail to process HTML by the specifications as regards to
things like end tag omission. That is, to emphasize that all paragraphs
be closed with </p>. I'm too lazy to do that for all old pages of mine,
but I'll try to remember this when problems emerge. Actually I just
changed my own DTD to require </p>.
HTML Tidy adds the optional end-tag (if missing) and this by default.

hide-endtags parameter set to yes will force HTML Tidy to not add the
optional end-tag (if missing).
http://tidy.sourceforge.net/docs/qui...l#hide-endtags

The -omit processing directive will omit optional end tags.
http://tidy.sourceforge.net/docs/tidy_man.html#OPTIONS

Trying to fix all your webpages with HTML Tidy could be tricky. The
thing is that HTML Tidy does several things when using the clean
command. It may add the optional end-tag (if missing) but it may also
do pretty printing, remove blank spaces, do line-wrapping at a default
number of characters, indent blocks, convert character entities, etc..
You are advised to test this carefully before processing a batch of
webpages with HTML Tidy. You can set write-back to 0 (it is 0 by
default) and wrap to 0.

You could try a moderately old version of HTML Tidy online to see how
it works and deals with your webpages:

http://infohound.net/tidy/

Grard
Jun 27 '08 #41

This discussion thread is closed

Replies have been disabled for this discussion.