Closed Bug 348149 Opened 17 years ago Closed 11 years ago
Mode editor: newline after a Heading or lists should result in a new <p>
(Core :: DOM: Editor, defect)
(Reporter: apratt, Unassigned)
17 years ago
Component: General → Editor
Product: Firefox → Core
QA Contact: general
Version: unspecified → 1.8 Branch
I'd accept hitting Enter creating a new block level element of the same kind (if I am in H1, and hitting enter creates a new H1 for example) rather than the system guessing what I want to do next, although 75% of the time I probably do want a new paragraph. There are usually controls to change the current block level element to something else, and I'd notice if I was still typing H1 or a list element. But if it creates text outside of a block level element, I most likely won't notice - if I'm using a RTE then I don't expect to view the source. Most people using RTEs wouldn't even know how to. So I totally agree that the current behaviour is bad practice. RTEs exist so people don't need to worry about creating correct markup. If an RTE creates bad semantic markup, then it isn't doing its job. If it does this in such a way that the average user doesn't realise it then those RTEs become a source of much bad markup on the web.
17 years ago
Daniel is the module owner. He would need to approve this behavior change. I thought we had planned that we would offer two modes (current behavior and "standards" behavior which did <p> instead of <br> in various situations including the scenarios presented in this bug) but I don't recall the final decisions. Looking at the source code (trunk / FF3), it looks like that should be the behavior but perhaps the behavior is only for <p> after <p> and not supposed to handle lists and headings. Daniel--could you clarify if the expectation for the command "insertBrOnReturn" is supposed to affect lists and headings or only paragraphs?
17 years ago
Regarding Comment #2: in 2005 there was some discussion about CR behavior while in a paragraph, and the new behavior was implemented in nsHTMLEditRules::ReturnInParagraph. But the methods ReturnInListItem and ReturnInHeader have no such logic. I just think nobody ever mentioned it. I want to say again that IE's designMode editor component does insert paragraphs after headings and lists. Regarding Comment #1, I think pressing CR while in the *middle* of an <h1> tag should break the existing text into two <h1> tags, as it does now. Pressing CR while at the *end* of a line formatted as <h1> should end the heading, also as it does now. I have no beef with that part of the current behavior. But in exiting the heading and list modes, the editor does *not* insert a <p> for the new text, and that's what I think is wrong. Without a <p> tag, subsequent input from the user appears at the top level of the HTML, outside all tags. That is the problem.
16 years ago
QA Contact: editor
11 years ago
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.