| Issue 3: | r19: inconsistent ENTER key behavior |
1 of 6
Next ›
|
| 3 people starred this issue and may be notified of changes. | Back to list |
In IE, pressing ENTER creates a paragraph - but in Firefox and Opera, it creates a break, which, apart from the obvious layout problems, does not carry the same semantic meaning. It looks like you tried to correct this, but it didn't really work out. In Firefox, sometimes you get a break immidiately - then, when you press ENTER after typing another line of text, these are suddenly transformed into paragraphs. And sometimes even two of them, e.g. <p>content</p><p></p><p>more content</p> I know this one's complicated to solve, but it has been done before - FCKEditor, I believe, is one of the only editors that managed to do it properly across most major browsers. I believe that consistent ENTER key behavior across the major browsers should be a high priority, as you can not produce consistent CSS layout for content with an unpredictable structure. I have looked into the matter myself many times in relation to other editors, but have been unable to understand the techniques used in FCKEditor... Maybe somebody else gets it??
Apr 7, 2008
#1
w...@sozdatel.net
Apr 8, 2008
A fix for this is currently in the mootools-1.11 version. Take a look at the "semantics" option. Once we get a little more testing, I think we are planning on implementing it into the main version, thats up to cheeaun though.
Status:
Started
Labels: Component-Logic
Apr 8, 2008
(No comment was entered for this change.)
Owner:
TJLeahy.Jr
Nov 5, 2008
Closing this since I believe it was fixed when the semantics option was incorporated.
Status:
Fixed
Nov 5, 2008
Unfortunately, semantic fixes are still not applied when you press ENTER, so this really doesn't affect ENTER key behavior. In IE, it seems to work. But in Firefox, press CTRL+A (select all), backspace (deleting entire document), then type a line, press ENTER, type another line, etc. Semantics are not applied when you press ENTER. Turn source editing on/off to force semantics to be applied, and from then on it works - I think, due to the fact that Firefox creates paragraphs when a document already contains paragraphs, not because of the semantic fixes (??) Either way, it's still inconsistent...
Status:
Started
Nov 6, 2008
After looking through the MooEditable.Selection class, I think it would be possible to make enter key behavior consistent, via capturing enter key events and the like. Cheeaun could you provide a little basic API documentation on this class (or a link to where you got the information on ranges)? I think the hardest part would be making sure the cursor is in the correct position after cleaning up the code.
Cc:
cheeaun
Nov 11, 2008
Kinda fixed. on rev 65.
Status:
Fixed
Nov 11, 2008
Uhm. It still doesn't work. In fact, it's worse now than it was before - try pressing return twice in a row. Anyhow, nobody wants to fix this, so just let it lie - it doesn't look like any of us have the time or capacity to come up with a solution at this point...
Nov 11, 2008
Hmm.. I'm not sure *which* problem you're talking about. Now, from my testing, it have consistent ENTER key behaviour across IE, Firefox and Safari. I guess the problem that you're talking about the code cleanup part where it removes the empty <p></p> after you ENTER twice?
Nov 12, 2008
hey cheeaun, I encountered similar problems to what you describe with the code cleanup and another one relating to linebreaks. There were basically two things that I noticed: First, the code cleanup is *too* aggressive; it blindly converts every linebreak to a paragraph tag, even when you have mixed paragraphs and linebreaks (e.g. shift-Enter). Second, and probably what mindplay.dk is referring to, is that the editor becomes confused when paragraphise is enabled and you enter linebreaks. If you enter a linebreak (shift+Enter) it appears properly, however if you then add a normal paragraph break (just Enter) it affects the linebreak of the line above it, too. You can enter multiple sequential line breaks and they will "stick", however the next paragraph break you create will convert the most recent linebreak to a paragraph break. Thank you for your continuing work on this editor, Cheeaun.
Nov 12, 2008
Shift+Enter should now work in r67. It's doesn't behave 100% the same cross browser, but it does work in Firefox, IE, Opera. Don't have safari installed, but for whatever reason I couldn't get Chrome to work properly. From my testing, here's what I found. Firefox: Have to hit the down-arrow key after a shift+enter to get the cursor onto the next line. Also, hitting enter on a line after a break will cause that line to be placed in a paragrph of its own (I believe this is a problem with MooEditable.enterListener). IE: Works as expected. Opera: Works as expected. Chrome: Doesn't work at all. Safari: Untested.
Status:
Started
Nov 12, 2008
I don't think there's a problem with Shift+Enter in non-IE browsers though. 'insertBreak' function for those browsers are kinda unnecessary? And the only problem I know is, ya, the enterListener function which needs to be revised.
Nov 13, 2008
The reason I implemented it for all browsers is because the semantics option tries to remove all those erroneous <br>s, so I add the class mooeditable-skip to the <br>. It's not the ideal solution, but the semantics regular expressions don't recognize it, so it leaves them alone. If you can come up with a better solution, definitely put it in; that's just the best I could whip up relatively quick here at work ;).
Nov 13, 2008
After a little testing, it seems to work fine if you only enable it in IE. r68 makes shift+enter consistent cross-browser, again untested in Safari. The only bug left in this ticket appears to be hitting enter after a few shift+enters in Firefox, which causes the last line to be "paragraphised".
Nov 14, 2008
I just made a discovery that could be useful. As you know, Firefox will default to paragraphs automatically, if you press ENTER while you're already in a paragraph. My biggest problem has been that when you start with an empty document, this doesn't happen. Well, try editing source, then insert the following: <p> </p> Then switch back to WYSIWYG, start typing, press ENTER. It works. I tried this in a couple of different lightweight WYSIWYG editors - it works consistently in Firefox. Note that <p></p> will not work. You need the to preserve the paragraph. Odd... Now if we could somehow detect if the document is empty, e.g. after CTRL+A, DEL or BACKSPACE ... and then insert the default empty paragraph with a nbsp... ??
Dec 3, 2008
Currently (r71) if I open the demo http://mooeditable.googlecode.com/svn/trunk/examples/default-additional-buttons.html and then; - click the text area - make "this is cool" an H1 via the button - press enter In Firefox (3.0.4) it turns it into a normal paragraph In Chrome (0.4.154.29) and Safari (3.1.2 win) it create two more blank h1 tags! In IE7 it works.
Jan 9, 2009
@mindplay.dk Does the <p> </p> trick work cross-browser, or is that a Firefox only fix?
Jan 9, 2009
I tested only with IE7 and Firefox, those worked. |