14608 - heading rules not quite right: return in an H1 should split the H1 unless the selection was at the end of the H1 content

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[buster]

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)

Comment 1

[buster]

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

Comment 2

[sujay]

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...

Comment 3

[Charles Manske]

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.

Comment 4

[Joe Francis]

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...

Comment 5

[Charles Manske]

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.

Comment 6

[Joe Francis]

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?

Comment 7

[Charles Manske]

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

Comment 8

[ekrock's old account (dead)]

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].

Comment 9

[Charles Manske]

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.

Comment 10

[bijals (gone)]

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

Comment 11

[leger]

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

Comment 12

[Joe Francis]

have fix

Comment 13

[sujay]

adding EB to status summary..ender blocker

Comment 14

[Joe Francis]

fixed

Comment 15

[sujay]

verified in 2/25 build.