Closed
Bug 166461
Opened 22 years ago
Closed 21 years ago
CSS form styles doesn't stop at </form> tag if a paragraph is left with unmatching </p>
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
People
(Reporter: gwidion, Assigned: harishd)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
When applying a CSS style to a form- I've tested with borders
and background - if inside the form there is a paragraph HTML
tag ( <p> ), without a macthing end of paragraph tag ( </p> ), the style
will bleed over to the next paragraphs after the form is closed
with </form>. (even if after the </form> all paragraphs do have
a matching </p> tag)
Reproducible: Always
Steps to Reproduce:
1.in html body do:
2.
<body>
<form style="border: solid 5px;">
<p>some text
</form>
<p>
some other text
</body>
Actual Results:
all the text is encompassed by the border, though
"some other text" should not be.
Expected Results:
Have enclosed "some text" with the border,
and left "some other text" with the default CSS for
<p>
|
||
Comment 1•22 years ago
|
||
This is grotesquely invalid HTML. HTML is a linearization of a tree structure,
and the above markup does not represent a tree structure. The only reason we
even render it is because early HTML user agents (Mosaic, Netscape 1, etc.) did
so because of the way they parsed HTML. This style of HTML is not compatible
with use of DOM and CSS and the results are (and should be) undefined.
That said, FORM is even more complicated than other elements to implement
because the backwards-compatibility needs to take into account the submission of
forms.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Component: Style System → Parser
Resolution: --- → INVALID
Summary: CSS form styles doesn't stop at </form> tag if a paragraph is left with unmatching </p> → CSS form styles doesn't stop at </form> tag if a paragraph is left with unmatching </p>
|
|
||
Comment 2•22 years ago
|
||
Er, actually, I didn't read closely enough. I'm the idiot. (I'm too used to
seeing what I thought I saw there.)
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
|
|
||
Comment 3•22 years ago
|
||
This is the testcase given by the reporter, although slightly modified to make
it valid HTML, and with a slightly more descriptive text.
|
|
||
Comment 4•22 years ago
|
||
->Parser, confirmed, definitely not minor. Apologies again for the incorrect
initial response.
Assignee: dbaron → harishd
Severity: minor → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: ian → moied
|
||
Comment 5•22 years ago
|
||
cc'ing heikki, since harishd is (AFAIK) still on sabbatical. Heikki, can you
take a look at this? It seems serious.
Keywords: testcase
|
||
Comment 6•22 years ago
|
||
This is because we treat form as a complete no-op unless the <form> tag is
well-matched. Unfortunately this is because so many sites use the <form> tag
as a logical container, not caring where the end form tag ends up. We could do
fixup such as closing child <P>, which seems to be in the standard.
IE solves these problems by making its style/frame tree separate from its DOM
tree. Changing our paradigm to match would fix this and probably many other
parser bugs. But it would be Hard. And also it would add bugs. If you look
at that testcase in IE, its DOM is really messed up in this case--I mean
*really* messed up, to the point where things are out of document order.
|
||
Comment 7•22 years ago
|
||
I just reported bug #193784 regarding a <P> element refusing to being enclosed
within a user-defined container element. Not certain it's related, but it
sounded similar enough to mention here.
|
||
Comment 8•21 years ago
|
||
*** This bug has been marked as a duplicate of 22480 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•