Closed
Bug 50261
Opened 24 years ago
Closed 24 years ago
Nested list items are not functional
Categories
(Core :: DOM: HTML Parser, defect, P2)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: bijals, Assigned: rickg)
References
Details
(Keywords: compat, Whiteboard: [nsbeta3+][p:1][PDTP2])
Steps: 1) Launch Seamonkey 2) Go to following internal URL: http://blues/users/bijals/publish/shrimp/shrimpcookieproblem.htm 3) Click edit document menu item in File menu Actual Results: The numbered bullets are not sub bullets of the last regular bullet. Expected Results: Numbered bullets are sub bullets of last regular bullet Build Date/Platform: 2000082408 on NT
Updated•24 years ago
|
Assignee: beppe → jfrancis
Severity: normal → major
Keywords: correctness,
nsbeta3
Priority: P3 → P1
Summary: Bullets in Composer created document appear different in Seamonkey → Nested list items are not functional
Whiteboard: [nsbeta3+][p:1]
Target Milestone: --- → M18
Comment 1•24 years ago
|
||
this is a fundamental issue that is causing this to happen. Each list item has Previous summary: "Bullets in Composer created document appear different in Seamonkey" the closing list item marker, the nested list (when select indent). What should happen, is when the indent is triggered, the previous list item (parent list item) should drop the closing list element marker. assigning this to jfrancis, setting to P1 and nsbeta3
Comment 2•24 years ago
|
||
i can't understand either of you. :-( Bij, it sounds like you never actually edit, you just open the doc in the editor and things are immediately wrong? If that's true then it's a parser problem (or perhaps a layout problem). Beth, I can't make hide nor hair out of what you are saying. Care to try again?
Comment 3•24 years ago
|
||
i just looked at this in the mozilla browser, and see the same thing bijal reports. This is a parser issue. I'm not even sure it's a bug. <ol>'s aren't supposed to be able to go into <ul>s, so closing the ul sounds legit. On the other hand, if it's supposed to be a quirk for compatibilty with 4.x, then perhaps the ul should not be closed. harish, I'm handing this over to you - just close it out if it's not a bug.
Assignee: jfrancis → harishd
Component: Editor → Parser
Reporter | ||
Comment 4•24 years ago
|
||
Sorry for the late reply. Beth is correct that I did not edit the document at all. This is a parser issue and possibly a compatibility problem with 4.x created pages.
Comment 5•24 years ago
|
||
This is a compat issue. The markup goes like this: <ul> <li></li> <ol></ol> </ul> ...and we treat is as: <ul> <li></li> </ul> <ol></ol> What we do seems sensible to me. INVALID/WONTFIX? The fix in the document is simple -- remove the </li> before the <ol>.
Keywords: correctness → compat
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1] INVALID/WONTFIX ?
Actually, the document is legal, and we get it wrong. I think this is a must fix. Taking it from harishd.
Assignee: harishd → rickg
Whiteboard: [nsbeta3+][p:1] INVALID/WONTFIX ? → [nsbeta3+][p:1]
"Actually, the document is legal, and we get it wrong" Rickg, is this based on Ian's comment? AFAIK, <UL> cannot contain <OL> and <OL> can have only a block parent ( UL is not ). That would make this document illegal. So,the way we handle this document,currently, is correct. Btw, I agree with Ian in marking this WONTFIX. :-)
Rickg, could you please mark this bug a dup of 45464 and mark it beta3+? Looks like bug 50261 is not visible outside netscape! Thanx.
Comment 10•24 years ago
|
||
PDT thinks this is a P2. Changing priority and leaving [PDTP2] in the status whiteboard
Priority: P1 → P2
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1][PDTP2]
Comment 11•24 years ago
|
||
*** Bug 45464 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Making bug visible outside Netscape -- this bug is certainly not a Netscape Confidential bug. IMHO this bug could be marked nsbeta3-, WONTFIX or INVALID. This is a compat issue and we are not doing the wrong thing, we just happen not to do what other browsers are doing. But Rick says he has a fix, so let's just check it in and move on to more important things. :-)
Group: netscapeconfidential?
Assignee | ||
Comment 13•24 years ago
|
||
The problem with this is that <UL><li></li><OL> is *extremely* common. I have the fix in my tree.
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•24 years ago
|
||
Fixed by changes to element table. This is an EXTREMELY common case.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•