I've did some testing on Firefox 2.0. Hitting Enter produces a paragraph indeed, but i noticed undo and redo do not work.
By the way: personally i would prefer the Enter-key to produce a <br /> and Shift + Enter a paragraph. To me that seems the most logic approach. But anyway: it would be a tremendous improvement if all browsers have the same behaviour concerning enter!
I'll be implementing the Undo system used on IE for Firefox too, also for the 2.4. It gives us more control on it.
The actual behavior of the enter key will be completely configurable. I've just committed in the SVN a new version which produces also BRs, and a new sample with which you can play with it. I'll posting the link tomorrow as soon as the nightly is updated.
Just as a note... in these days it is much more correct and professional to work with <p>, instead of <br>. It gives a better structure to the document, producing XHTML semantically correct. Line breaks (<br>) should be used on those rare cases when you want to split semantically related information in different lines. If the spaces between paragraphs (which make the text more readable) represent a problem, you can always control it using CSS.
Ok, the nightly has been updated. Now, you will find in the list of samples (the combo in the top of the page) the new sample 12, which is dedicated to this new feature.
You can now play with the settings of both the [Enter] and [Shift]+[Enter] keys, producing <p>, <div> or <br>. Still Firefox only.
This is still a first version. Work must be done, and your impressions about it are important to complete it with the expected high quality.
We'll be working now on fixing the current version and expanding the compatibility with IE.
It shows us how difficult is provide a software like Firefox, which must work on multiple platforms. As we can see, Firefox for Mac is a few steps behind the Windows version.
The behavior you have described may also happen with Firefox 1.0.x on Windows, and we made it work accordingly. No, I'm doing the same implementation for Firefox on Mac, and it seams it works.
I'll be committing the fixed code today, so we can expect it to be ok on our next nightly tomorrow.
I didn't realize the browser affected what happens when you hit the Enter key, except for JavaScript events!
I was thinking it should produce a paragraph when you hit Enter twice and a Break tag when you hit Enter once...but apparently, from these posts, people are used to some other behavior from embedded editors? I've never been a big WYSIWYG user, so I guess that explains my ignorance.
I think it could also be confusing that everyone who uses this could configure it different ways, but I guess they're thinking when it is embedded in CMS, most people at the user level aren't even aware they are using a specific plugin and would be more familiar with a specific website, anyway.
It seems to work great on FF2 Windows already! Creating paragraphs with [enter] and linebreaks with Shift+Enter works fine for me, however, erasing them with backspace sometimes results in the text cursor disappearing?
The enter key behaviour is a great idea and works well for me in Firefox.
Except... is there any way to force FCKEditor to start in a particular mode (in my case, 'p') rather than the default 'nothing' mode? I'm using FCKEditor as part of OpenCms 6.2.3 (and therefore with FCKEditor version 2.3.2, I think), and when users start typing in a free-form text area the content is not contained within <p> tags as I'd like it to be - unless they are diligent enough to choose the right format from the dropdown, or the right style from my styles dropdown.
There are also cases where block content is inserted inside <p> tags, and this isn't XHTML-compliant - but I guess that's a different thread.
Actually the current implementation will guarantee that all source under <body> will be inside block tags. The editor will actually "fix" the code when "outputting" it for post or when switching to the source view.
So, the <p> is not guaranteed to be there during the editing, but you can be sure it will be included when the data reaches your server.
For the "block content [being] inserted inside <p> tags", as you have understood, it is reserved for another thread. But we are aware of it and we are working to provide a nice way to handle it too.
RE: New enter key handler: first impressions
RE: New enter key handler: first impressions
As I've said, we have implemented only the <p> behavior with the <Enter>. I'm working now in the <br> behavior for the <Shift> + <Enter>.
Thanks for the message Alfonso. I'm anxious for more impressions.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: New enter key handler: first impressions
Hitting Enter produces a paragraph indeed, but i noticed undo and redo do not work.
By the way: personally i would prefer the Enter-key to produce a <br /> and Shift + Enter a paragraph. To me that seems the most logic approach. But anyway: it would be a tremendous improvement if all browsers have the same behaviour concerning enter!
RE: New enter key handler: first impressions
The actual behavior of the enter key will be completely configurable. I've just committed in the SVN a new version which produces also BRs, and a new sample with which you can play with it. I'll posting the link tomorrow as soon as the nightly is updated.
Just as a note... in these days it is much more correct and professional to work with <p>, instead of <br>. It gives a better structure to the document, producing XHTML semantically correct. Line breaks (<br>) should be used on those rare cases when you want to split semantically related information in different lines. If the spaces between paragraphs (which make the text more readable) represent a problem, you can always control it using CSS.
Thanks for your comments Koen.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: New enter key handler: first impressions
RE: New enter key handler: first impressions
You can now play with the settings of both the [Enter] and [Shift]+[Enter] keys, producing <p>, <div> or <br>. Still Firefox only.
This is still a first version. Work must be done, and your impressions about it are important to complete it with the expected high quality.
We'll be working now on fixing the current version and expanding the compatibility with IE.
I hope you'll enjoy it. Thanks again.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: New enter key handler: first impressions
http://www.fckeditor.net/
RE: New enter key handler: first impressions
The behavior you have described may also happen with Firefox 1.0.x on Windows, and we made it work accordingly. No, I'm doing the same implementation for Firefox on Mac, and it seams it works.
I'll be committing the fixed code today, so we can expect it to be ok on our next nightly tomorrow.
Thanks for the message Hubert.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: New enter key handler: first impressions
When i make a new <p> with ENTER, i can't create a new <div>.
RE: New enter key handler: first impressions
http://wiki.fckeditor.net/EnterKey
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: New enter key handler: first impressions
I mean: when creating a <p> with ENTER, it's not possible to create a <div> with Shift-Enter.
RE: New enter key handler: first impressions
http://wiki.fckeditor.net/EnterKey
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: New enter key handler: first impressions
I was thinking it should produce a paragraph when you hit Enter twice and a Break tag when you hit Enter once...but apparently, from these posts, people are used to some other behavior from embedded editors? I've never been a big WYSIWYG user, so I guess that explains my ignorance.
I think it could also be confusing that everyone who uses this could configure it different ways, but I guess they're thinking when it is embedded in CMS, most people at the user level aren't even aware they are using a specific plugin and would be more familiar with a specific website, anyway.
RE: New enter key handler: first impressions
RE: New enter key handler: first impressions
Except... is there any way to force FCKEditor to start in a particular mode (in my case, 'p') rather than the default 'nothing' mode? I'm using FCKEditor as part of OpenCms 6.2.3 (and therefore with FCKEditor version 2.3.2, I think), and when users start typing in a free-form text area the content is not contained within <p> tags as I'd like it to be - unless they are diligent enough to choose the right format from the dropdown, or the right style from my styles dropdown.
There are also cases where block content is inserted inside <p> tags, and this isn't XHTML-compliant - but I guess that's a different thread.
Jon
RE: New enter key handler: first impressions
Actually the current implementation will guarantee that all source under <body> will be inside block tags. The editor will actually "fix" the code when "outputting" it for post or when switching to the source view.
So, the <p> is not guaranteed to be there during the editing, but you can be sure it will be included when the data reaches your server.
For the "block content [being] inserted inside <p> tags", as you have understood, it is reserved for another thread. But we are aware of it and we are working to provide a nice way to handle it too.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn