looking at Nav4, I notice that if you have: <h1>word</h1> and the selection is anywhere EXCEPT after the 'd', it splits the H1. we should only create a paragraph after a heading in the case where the selection is at the end of the content (collapsed or extended selection)

charley, mike, any comments about what this rule ought to be?

what timing buster..I was just gonna file this bug a second ago and then I got this mail...The behavior I was gonna file was: 1) launch apprunner and editor 2) place cursor infront of the "Here's the deal" 3) hit return the heading becomes normal text...

If selection is at the beginning of the H1 text, I'd say that the user wants to insert blank lines, so keep the H1 style. If selecion is in the middle, I have no problem with changing the part to the right (now on a new line) to "normal". The goal is to not have a heading with more than 1 line.

well, this is because nav4 wasn't as smart as nav5, isn't it? this is a feature. do we know for sure that we don't want this? I've brought it up before and no one yelled at the time...

Please explain "that we don't want this?" What is "this"? I.e., which of the 3 cases I described: caret at beginning, in the middle, or at the end of line.

sorry Charlie, my response was to earlier comments. I got the impression that this bug was about splitting headings instead of making the second half into a paragraph (or mozdiv, in my current tree). I do agree that if they hit returns at the beginning they want whitespace. Am I to take it that we are in agreement that the current behavior is correct except for when the cursor is at the beginning?

Yes, I think so (to your last question!)

Granted, the question of "correct" behavior is a judgement call about what's the most efficient/convenient for users and what their expectations are based on prior experience with Nav4 Composer (for the installed base), and both of these issues require making assumptions about usage patterns. My comments refer here to the case where there is no selection but rather a blinking insertion bar, but I think it's the same issue so I'm inserting into this bug report. FWIW, here's what I think the behavior should be: 1) if the insertion point is before the first character of the H1, hitting return should in effect create a second H1 at the insertion point, causing the existing H1 to be immediately below the new one (reason: when I hit return in this case, I've typically decided that another H1 is needed as I'm going to create a whole new section) 2) if the insertion point is anywhere within the characters of the H1 (but not after the last character), hitting return should split the H1 into two H1s at the insertion point (reasons: (a) here I'm splitting one header into two, and (b) consistency with Nav4 Composer behavior) [NOTE: The behavior I'm proposing here differs from what the previous Description comments recommended.] 3) if the insertion point is after the last character of the H1, hitting return should create a new body text-type element (Normal or Paragraph or whatever). Reason: after you type in a header, most often you want to then start typing some ordinary text to go after it The behavior I'm arguing for is the same as the behavior of both Nav4 Composer and of MS Word, which is currently the most widely-used word processor and will therefore heavily influence user expectations about "correct" behavior for editing operations. (Try the same operations on a Word Heading 1 and you'll see.) Nominating for dogfood as this behavior IMHO is making Composer so awkward to use that I can't justify using it for daily work, and that end users will consider it unusably buggy. The workaround, going to the previous element and then hitting return and then changing the created element as necessary to an H1, is multiple extra steps, really awkward and time consuming, and doesn't succeed either due to a separate bug I'm about to file--having tried the workaround, I'm now looking at a page in which the element created in that way is showing "Heading 3" in the pulldown menu but is getting Normal formatting [i.e. normal size, non-bold text].

I agree completely with Eric's description of the desired behavior. Only do the switch to "normal" when caret is at the end of the line. Note that there is a PDT+ bug (27306) concerning using Enter/Return when at the end of a heading line.

Not the same as 27306 since this one involves splitting the header as oppose to clicking at the end.

Putting on the PDT- radar for beta1. Easy workaround.

have fix

adding EB to status summary..ender blocker

fixed

verified in 2/25 build.