TESTERS CALLED: Enter Key Handler

Small question.

I use the Template with the Img, the first one. Observed behaviour dictate Enter after the Heading to go to the first paragraph, but instead a new DIV is created, Should it not rather be a SPAN for inline elements? Beside that the Paragraph is replaced with div instead, working great.

Could this then mean you could have sticky buttons for behaviour change? ie: click button to switch div/span/p behaviour.....

My setup
Ent=<br>; Shf+Ent=<div>
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

The first instance is the best, I might have been confused myself, but only because I was testing ...

The default behaviour for Enter to "add" space to elements would be best solved by introducing <br>. I like the idea of trying out the Shift+Enter for creation of encapsulated elements like the <p> and <div>

So Fred, the instance of:

----
<img style="MARGIN-RIGHT: 10px" height="100" alt="" width="100" align="left" />
<h3>Type the title here</h3>
Test^<br />
Type the text here
----

Would be 100% satisfying to me.

Works great for me (Firefox 2.0.0.1)! I've tested basic paragraphs (Enter), headers (plus Enter-behaviour after) and the Shift+Enter and Delete behaviour.

I found only one bug: when editing in a header, shift+enter returns a new paragraph, instead of a <br /> in the header. Not sure if this was intentional, but I think it should be changed.

Oh, and for the record, the file manager in the nightly build is broken?

OK,

Per Frederico's suggestion, I'm taking an e-mail thread here to the forum so others can weigh in on this.

In the past, our group has worked with various editors ranging from HTMLArea, Xinha and TinyMCE to FCKeditor.

FCKeditor is the best. But all that said...
They all have the same problem: This whole P vs BR business.

There are a couple issues.

1) Browser

Mozilla & IE differences. IE seems to be mostly tame when you have it in P mode. Firefox is a little quirky. It will follow P-mode when it sees it, and use BR mode otherwise. This leads to weird hacks like the <p>&nbsp;</p> which can produce inconsistent results (think: Select All, Delete... or just having to hit enter twice in certain cases before things work right). Everyone already knows all this. This is why we're here in the first place.

Now, this is where it gets a little more interesting:

2) with regards to Semantic XHTML Mark-Up

Text nodes need to be contained in a P. Anything else is unacceptable. Using forced-BR mode works beautiful for providing consistency between the browsers for all users. But it doesn't produce semantic mark-up if you're using BR's.

This work is helping make this a reality. The Firefox-specific work so far helps us remove this <p>&nbsp;</p> dirty-hack-ness. It seems to be producing <p></p> nodes perfectly.. and has just recently gotten around the trailing <p>&nbsp;</p> problem as well. Being forced to press enter before a <p></p> is created, when you are starting with a completely blank field, also seems to be working now as well.

The trailing <p>&nbsp;</p> still seems to be an issue in MSIE.

However, I must say that, as it stands now, it is very close. It seems to actually work better than it did when I first emailed Frederico... I could be wrong... but I must say my hat is off to him and the rest of the FCK team for making such stellar progress on this annoying issue.

3) with regards to User Experience

Users expect hitting enter to produce a single line-feed. They also expect to be able to use style elements without introducing any breaks. These two features mimic MSWord, which is what they "expect" when they see the editor. Sure, we can "educate" them about publishing on the web... but they will still think that it should function like MSWord.


So....

In order to make everyone happy. I see a couple solutions:

** With regards to P vs BR:
This seems to be coming along rather wonderfully. There are two possible approaches here to keep everyone (semantic xhtml people and end users):

1) An implementation-level/application-specific compromise that can make them happy with the way the editor seems to be functioning now. The editor should be set up to produce <p></p> nodes around all text blockes. The P margin should be set so that it mimics a BR. Then the application can output any user-supplied (FCK-derived) content in a <div> that can provide a CSS context for changing this P margin only on this content. Then users press enter and get what they expect. The semantic zealots get the mark-up they righteously strive for (and for good reason!).

2) A slight modification could produce a more optimal result: a hybrid P/BR mode. Pressing enter once will produce a <br />. Pressing enter a second time (i.e. the presence of two consecutive <br /> nodes) will produce a </p> <p> and remove the previous <br />. And, similarly, pressing backspace on a </p> <p> will merge the two P's and insert a single <br /> between them. This is not how the editor works now... but it would be the "best of both worlds" ... In that the users would get what they want .. And the semantic mark-up is present without any futzing around with the CSS.


** With regards to block-level elements such as H1-H6:

This is where the "expect to be able to use style elements without introducing any breaks" part comes into play. There is really only one option that I can see at this time that makes both groups happy (again semantic xhtml people vs end users):

A CSS implementation similar to the above P vs BR solution #1; place a <div> around FCK-derived content and make the Hx tags inside of that non-breaking. This will allow users to "style" their text while still providing semantic markup for their headings, etc.

An alternative, of course... is to use something like <span> styles and such... This may perhaps produce code that is no longer be semantic, depending on the application-specific context presented to the end user and the content they are actually producing.




So... in summary...

It seems that most of the work is already done on the whole P vs BR front.

As it stands now, the trailing <p>&nbsp;</p> can be problematic sometimes... and it just not clean... and should be resolved, if possible.

There should be no case, whatsoever, where the user can fall out of the <p></p> node, when its appropriate (I think this is actually working now!). Falling out of the P is problematic; it is no longer semantic... and, worse yet, the designer will tend to rely upon the presence of a P tag for CSS purposes... and a text node not being contained in one will become unstyled if there isn't a fall-back for this unpredicted scenario. I think we are doing OK on this front.

The hybrid P-BR mode would just be a god-send in terms of xhtml beauty, cleanliness and user experience. But a P/BR margin workaround exists now, and can work "well enough" if there are no bugs where a user can fall out of P. It's not optimal, however ---- mixed used P-BR mode would be.

As for the whole text stylization thing... and heading tags... well, this is just up to the developers implementating FCK into their specific app.. and intended end-user usage.... the break-less Hx tag approach can be a nice way to give users some extra style control while providing some support intended to make the final mark-up more "semantic."

Well.. And all that said.. I must say FCK rocks.

Alex

Also, I might add that <br/><br/> handler... as could be implemented in a "mixed-mode" line break implementation... could potentially help with MSWord cut-n-paste... as it tends to produce lots of <br/> from what I've seen.

Looks pretty good. I found a bug:

1. Type foo[Shift][Enter]bar

2. Position the cursor at the end of "foo"

3. Hit delete -- the "f" is deleted, when you would have expected the line
break to be deleted.

well. providing a hybrid mode does allow for a nice compromise. saying that BR is "always" bad...and that there is a choice between BR or P mode... is not necessarily taking in the full perspective of the end user but more so that of the XHTML/semantic expert.

a user expects pressing enter to go down one line. they press enter twice to produce a new paragraph. just like they do in word.

also, i have seen ms word paste produce BR's. i would think that "hybrid handling" mode could perhaps help change this to P.

I agree that using only P is the "correct" way to do it... but I have seen with my own eyes many times what happens when you give them that...and then tell them to press Shift-Enter when they only want a regular break. "that's annoying, can you make it not do that?" .. or then there is the make-everyone-happy mode... use only P (which used to be quite buggy with Firefox because of the <p>&nbsp;</p> hack) and then CSS the P to have a margin break like BR.

"....2) A slight modification could produce a more optimal result: a hybrid P/BR mode. Pressing enter once will produce a <br />. Pressing enter a second time (i.e. the presence of two consecutive <br /> nodes) will produce a </p> <p> and remove the previous <br />. And, similarly, pressing backspace on a </p> <p> will merge the two P's and insert a single <br /> between them. This is not how the editor works now... but it would be the "best of both worlds" ... In that the users would get what they want .. And the semantic mark-up is present without any futzing around with the CSS. ..." (quote alexnoinc)

This is the holy grail for me. Is there a way of emulating this behaviour using the EnterMode yet? If not is there a chance of it happening in a future release?

I don't think that is a good compromise.

Even in Microsoft Word (producer of the crappiest HTML known to man), pressing enter creates a paragraph. It just happens to be styled without a margin at top in the default template.

Most people seem to think they want a <br/>, but what they really want is a paragraph with no margin. You can achieve this with some css, and still keep your documents symantically correct.

p {margin:0}


My vote goes to ENTER = <p>, SHIFT-ENTER = <br/>

Most people seem to think they want a <br />, but what they really want is a paragraph with no margin.

erm, sorry but I know what I want. A paragraph is completely different symantically to a line break. If I have a line break I simply want to start a new line of text within the same paragraph. If I want a paragraph I want a 1 line gap between where the paragraph ends and the next begins.

surely to get this:

hi there,
How you doing? Haven't spoken to you in a while

What have you been doing recently etc...

this:

<p>
hi there,<br />
How you doing? Haven't spoken to you in a while.
</p>
<p>
What have you been doing recently etc...
</p>

is better than this:

<p>
hi there,
</p>
<p style="margin:0px;">
How you doing? Haven't spoken to you in a while.
</p>
<p>
What have you been doing recently etc...
</p>

Sure, I didn't say that there is never a place for a <br/>.

It's just that <p> is much more commonly needed. Therefore having to press enter twice to get one doesn't make sense.

And making it work differently to the word processor that the vast majority of people use is. Does anyone know what OpenOffice does?

For the user end (forgetting background tags and formatting etc.) Word is 1 enter for a line break (visually) and two to start a new paragraph. Noone ever presses shift-enter that I know of.

I just checked though and you're absolutely right, it does indeed create paragraphs with <p>&nbsp;</p> and shift-enter does create a <br /> in the background code.
I see what you mean about the paragraphs with no margins now. I guess this is the 'best' compromise to be in keeping with word and should be most consistent between browsers.

Many Thanks

Greg

I'm glad we agree.

Also, I just installed Word 2007 and it's default behaviour is the same ... however the default paragraph style has now gone back to having a margin at the top. So the difference between a <p> and <br/> is now even more obvious in Word (again)

I'm having a problem entering <br /> in a non-empty listitem <li>

I would like to create XHTML as the following:
<ul>
<li class="decimal"><span class="ol">1. </span><em>Test 1</em><br />This line should appear on a new line, because a &lt;br /&gt; was entered with 'SHIFT + ENTER, just after '<em>Test 1</em>'.</li>
</ul>

But in fact in (Internet Explorer 7) when I hit SHIFT + ENTER a single time, the <br /> diasappears (for example: after switching to source-mode and back).
In Firefox i've no problem at all and SHIFT + ENTER behaves like expected!

I found two 'solutions':
1. Remove the <em> and </em> surrounding 'Test 1'
2. Hit SHIFT + ENTER twice!!!!

For me this is a huge problem, because the users of my CMS (most of them use Internet Explorer) of course would never think about hitting SHIFT + ENTER twice.

Regards,
Koen Willems

It seems that there's a problem with the way the new enter key handler handles div's (didn't see this one before).

This can be reproduced in the demo on the FCKeditor website.

- Go to source view and type <div id="test">my test</div>
- Switch back to the wysiwyg view and place the cursor right after 'test'
- Press enter once and type 'some text'
- Go back to source view
- This is what I see:
<div id="test">my test</div>
<div id="test">some text</div>

So another div (with the same id) is created. I don't think that's correct behaviour.
This behaviour is seen in IE7 and FireFox 2.0.0.1.

If you use FCKConfig.DisableEnterKeyHandler = true; in your fckconfig.js file, the editor works correctly (or at least to my oppinion) and creates a new <p> inside the current div.

Any ideas on how to fix this?