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>
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>
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 → ---
This is the testcase given by the reporter, although slightly modified to make it valid HTML, and with a slightly more descriptive text.
->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
•