Enter means 'line break' but should mean 'new paragraph' (was: Please don't kill kittens)

[andybak]

A kitten dies everytime someone releases an editor where 'Enter' means 'line-break' instead of 'new paragraph'.

Think of the kittens...

[rocketraman]

:-) Oh those poor kitties.

While I sympathize with the plight of the kittens, I don't think I'll change this. The primary use case for Ritzy is to serve as a data entry system for people who might traditionally have reached for Word or Google Docs, but the entry system needs to be embeddable inside a web application. So the behavior has to be as similar as possible.

Both Word and Google Docs treat 'Enter' as 'line-break', at least by default. Both have the capability to add a "style" that will turn that line break into a paragraph break. I see Ritzy's future evolution in the same vein.

[andybak]

I was under the impression Word switched their defaults a while back. Good luck with that regex that can work out how to turn br+br into a wrapping p

;-)

[rocketraman]

I was under the impression Word switched their defaults a while back.

You're right! I see now that they did. That is very interesting. Let me reopen this issue for further discussion.

Good luck with that regex that can work out how to turn br+br into a wrapping p

I'd appreciate some additional explanation / rationale behind your case. Did you mean for the purposes of exporting the editor data into HTML? That logic is already in place and does not require regexes. See https://github.com/ritzyed/ritzy/blob/master/src/core/htmlwriter.js. A good way to test it is to copy some data in the editor into the clipboard, and then examine the clipboard's HTML contents e.g.:

xclip -selection clipboard -o -t text/html

For example, this editor input:

produces this HTML on the clipboard (line breaks added for readability):

<meta http-equiv="content-type" content="text/html; charset=utf-8">
<p style="white-space:pre-wrap;">This is a test!</p>
<p style="white-space:pre-wrap;">Foobar baz.</p>
<p style="white-space:pre-wrap;">New paragraph.</p>

That being said, some general comments:

• Ritzy is a rich text editor, not an HTML editor. So HTML compatibility is not a primary concern, though it is a secondary one. But I don't see this as sufficient justification either way.
• For the use cases that Ritzy is intended for, I think the enter-is-newline behavior will be more "expected" by users. For example, here is one use case: lets say I'm a webapp developer and I want to have my users create Markdown in Ritzy, but with the simpler formatting e.g. bold/italics/etc operating in a way that is more familiar to them (think this text box GitHub uses).
• However, Enter-is-parabreak would mirror Word behavior as you pointed out.

Another option is to work like Google Docs seems to: by default enter-is-parabreak, but paragraphs have no extra spacing after them. However, the paragraph style can be changed to add the extra space in situations where that is desired. That might capture the best of both worlds, although changing the spacing decision after lots of text has already been entered does create havoc. In most cases devs should be able to configure Ritzy the way they want it up front.

Thoughts?

[andybak]

I suppose I'm being somewhat Utopian - it would be great if everyone's expectations mirrored the default behaviour. So I want a world where 'enter' does the same thing in all rich text/wysiwyg fields so poor users stop being surprised (they don't like surprises... and surprises == bad UX)

So on one level the biggest aim is to get everyone to damn well agree what 'enter' means. Consistency will make everyone happier.

So what should 'enter' mean? I would assume that people want a new paragraph more often than they want a single line break. (However - they don't like surprises and if they are unfamiliar with how to do a single line break they experience fear and uncertainty even if they don't need one right away.)

Also document that has lots of double line breaks instead of paragraphs is very hard to style. You face some difficult choices - detect double line-breaks and instantly interpret them as paragraphs (this is very hard to get right - think of the ickiness of Word's "guess whether they've finished a bulleted list" feature which is a similar attempt to be helpful and automagically infer structural knowledge of the document).

Or you give up on the whole concept of paragraph styling (and therefore effectively give up on the idea of paragraphs).

Or have some concept of 'export to a format that you can style' which is roughly what you're doing. I'm very curious how you detect and convert paragraphs and whether you cater well for edge-cases. I have a deep abiding loathing of Markdown because it does an awful job of guessing whether I wanted a paragraph or not.

'Shift and enter' isn't intuitive but neither are lots of things people use every day. If it's ubiquitous then it will become familiar. Maybe there's a better solution than than shift+enter?

[rocketraman]

Good thoughts.

I'm very curious how you detect and convert paragraphs and whether you cater well for edge-cases.

The source I referred to is pretty easy to grok. The algorithm is pretty simple, so I probably don't cater well to edge cases. Can you give some specific examples? Note that this logic is not a core part of the editor nor an internal data structure in any way -- currently it's just used when exporting the editor contents to HTML.

I think your thoughts above are consistent with my last suggestion about making the editor work like Google Docs, including shift-enter. Actually, now that I think about it the only difference between Google Docs and Word appears to be the default setting for whether there is space after a paragraph or not. Based on this exchange I am starting to think Ritzy should work the same way. Then the only question that remains is: what is the default setting for space after paragraphs?

[syranide]

Long-term, wouldn't it be preferable to control all of this through callbacks instead (this being possible so easily seems like another huge benefit of this approach), allowing the developer to control exactly what happens dynamically rather than via limited configuration. EDIT: Say, enter in a header should probably be handled differently from enter in a paragraph, or in a bullet list.

[rocketraman]

@syranide Interesting thought. There are two sides that need to know – indirectly -- about what a given input such as 'Enter' "means". One is when the input is made, the current context of the cursor (in a bulleted list or not) may be relevant to determining which character is actually placed into the underlying data structure (i.e. \n or a paragraph [1]). Secondly, the system needs to know how to render the data structure to the editing surface, and how to convert interaction with the editing surface (clicks, navigation, selection) into the relevant actions given the data structure.

The former is probably where a callback could come in and work well. It would be important for enough context to be provided to the callback to make it powerful enough to do cool stuff. The latter could be some type of callback as well potentially, but since rendering directly impacts stuff like wrapping and cursor positioning, for that its probably better to just to allow a limited set of style configurations that the editor knows how to deal with internally.

Is that along the lines you were thinking?

This is definitely longer term though -- so far Ritzy doesn't even support bullets :-), so adding that type of capability first will be important to designing this in a sane way. The basic non-callback paragraph handling could be added sooner.

[1] As an aside, how to represent the paragraph will need to be decided... The approach that is probably most compatible with the underlying causal tree CRDT is to make the end-of-paragraph a character within the underlying model. There may be other approaches though.

[syranide]

The former is probably where a callback could come in and work well. It would be important for enough context to be provided to the callback to make it powerful enough to do cool stuff. The latter could be some type of callback as well potentially, but since rendering directly impacts stuff like wrapping and cursor positioning, for that its probably better to just to allow a limited set of style configurations that the editor knows how to deal with internally.

Is that along the lines you were thinking?

Yeah I think so. Obviously some parts of the editor (as you say) are probably best handled by style configuration (and super long-term allowing the entire module (highlighting) or sub modules (the highlighting box) to be replaced if someone feels it isn't sufficient for their needs). I'm primarily referring to user interaction above really, it's not uncommon to see people think "this is a text editor and they work this way" which is really sadly limiting, when in reality if you don't simply hard-code keyboard mappings/etc then there are a lot of interesting features and use-cases it enables that aren't strictly "text editors" (remember Google Wave?).

This is obviously not trivial in the big picture, but overall I'm just a big proponent of core flexibility through callbacks/modular code rather than enough configuration directives to reach the moon and back (which you can still provide through a module if that's your thing), which never seem quite flexible enough in the end anyway and tend to unrealistically increase maintenance.

So yeah, I mostly entertaining the idea of also being modular rather than only configurable, but I don't have much practical advice at this moment :)