- From: Markus Ernst <derernst@gmx.ch>
- Date: Tue, 17 May 2011 09:04:34 +0200
Am 16.05.2011 21:20 schrieb Aryeh Gregor: > On Mon, May 16, 2011 at 9:33 AM, Markus Ernst<derernst at gmx.ch> wrote: >> I have seen content management systems where text editors tweak the enter >> key to behave the same also in non-IE UAs (e.g. if you use Contenido with >> TinyMCE, Firefox produces the same output as IE when you hit enter). > > I mentioned one forum (vBulletin) which used to set margin to 0 on > paragraphs so that IE looked the same as non-IE browsers. So it's an > argument for giving authors an option, maybe, but it doesn't help us > decide what the default should be. > >> This is very presentational thinking. > > Correct. This API was designed and is used presentationally, not > semantically. Both authors and users want presentational formatting > here. That's why it's called "What You *See* Is What You Get". Right, but this does not answer the question about the best standard behavior for the enter key. For real WYSIYWYG, it would be necessary to introduce a mechanism to apply some CSS separate from the surrounding page to the contenteditable element, so CMS or forum authors can provide the styles of the output page in the input element. (This is actually the case in iframe-based RTEs such as Kevin Roth's Cross-Browser RTE or TinyMCE.) I assume there are use cases for both generating <p>s and <br>s. The IE/Opera approach has the advantage of allowing both, which is perfect for text and basic HTML editing. From a WYSIWYG POV it might be best to offer both options, so authors are not encouraged to add server-side processing to change the output, which would break WYSIWYG. If the behavior is settable, it might even be a good idea to leave the choice of the standard behavior to the UAs. Authors who have a reason to care can set their preferred behavior, while other authors might prefer to leave it as it was, so there is no change for their existing users.
Received on Tuesday, 17 May 2011 00:04:34 UTC