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

[Jukka K. Korpela]

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/

[David Stone]

In article <5g************ ********@reader 1.news.saunalah ti.fi>,
"Jukka K. Korpela" <jk******@cs.tu t.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

[Harlan Messinger]

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?

[Jonathan N. Little]

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

[Darin McGrew]

"Jukka K. Korpela" <jk******@cs.tu t.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******@domai n.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****@stanford alumni.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."

[David Stone]

In article <66************ *@mid.individua l.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.

[VK]

On Apr 10, 2:48 pm, "Jukka K. Korpela" <[e-mail] t.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?

[Joost Diepenmaat]

VK <sc**********@y ahoo.comwrites:

On Apr 10, 2:48 pm, "Jukka K. Korpela" <[e-mail] t.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/

[VK]

On Apr 11, 1:23 am, Joost Diepenmaat <jo...@zeekat.n lwrote:

VK <schools_r...@y ahoo.comwrites:

On Apr 10, 2:48 pm, "Jukka K. Korpela" <[e-mail] t.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

[VK]

On Apr 11, 2:07 am, VK <schools_r...@y ahoo.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.