Am 16.05.2011 21:20 schrieb Aryeh Gregor:
On Mon, May 16, 2011 at 9:33 AM, Markus Ernst<derer...@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.
