Comment by georgestephanis | Hacker News Reader

Comment by georgestephanis | Hacker News Reader

georgestephanis

Yup. Wysiwygs are hard. But just saying "You can edit paragraphs, that's all you get" is worse. Clients need to be able to do more advanced things in an editor, and coding a hard limit on never being able to do them feels like pure folly.

Is TinyMCE perfect? Far from it. But it's stable and reliable across browsers, with a well-defined API, and it gets the job done.

I know a lot of folks here would just as soon just use Markdown for all content writing. I like Markdown. Clients hate it. It feels like an obscure language, when they just want something "like Microsoft Word".

And CMS's can hardly say "Yeah, we know we used to support these greater markup sets, but now we're just not going to, so don't open up your old posts, or they're going to lose some content in our bright shiny new editor" -- that's massively problematic as well for user trust.

If you're starting something new, and want to place a hard cap on what your users can do markup-wise, sure, give this a shot. But be very aware of the restrictions that you're imposing.

I hate markdown. I always use a single line break to indicate a single line break. Having to use two breaks the most basic expectation of editing text.

Do you mean you don't like

    Line1
    Continuation of Line1
    
    Line2

If you're wrapping text, how else would you be able to do it?

Hard-wrapping text probably isn't something most people should be doing in most cases, especially for text documents. Computers are generally at least OK at wrapping automatically for display or editing - we've had code for it almost as long as we've had GUIs.

It's certainly not a concern for many of the places Markdown gets used - online systems where the primary form of entry is a textarea. Therefore, those places should likely not use Markdown.

What about something like Jekyll and text being edited in vim or emacs? There are many people, myself included, that prefer hard breaks for a variety of reasons.

Just because something doesn't fit your use-case doesn't mean it's not common.

There's a point to be made that if vim and emacs can't do soft line wrapping, perhaps people should be using tools that can provide basic modern conveniences like that instead of affecting the rest of us.

> vim and emacs can't do soft line wrapping

I never said they couldn't and they most certainly can (I simply find it awkward to work with). I've simply seen it more common to have them hardwrap than it is to see hardwrapping in a GUI editor.

And if Vim or Emacs couldn't do soft line wrapping, you'd have a point.

I use Vim to wdit markdown and have no problems editing long soft-wrapped lines. Should I?

You can edit with soft-wraps, I just don't like to. (I find it awkward to work with as line-movment is in lines, not soft-lines).

Also, when mixing code, you may want markdown in comments for better formatting of autogenerated docs, and you don't want softwrapping on while code (at least I don't).

It makes more sense in an environment where there's no automatic line wrapping. Breaks are a good way of maintaining readability in these environments, and you don't want those breaks to cause paragraph breaks in the rendered text.

> Having to use two breaks the most basic expectation of editing text.

You've never used LaTeX then. I almost always put a line break after a full stop when editing in plain text, because it adds semantic meaning.

Moreover, many single-spaced visual styles have unindented paragraphs with an extra line between paragraphs.

Two Markdown line breaks don't translate to a single line break in the output but to a paragraph break.

(To output a single line break, precede your source line break with two spaces. As others have pointed out, these behaviors are to let you manually wrap your source but have the output be auto-wrapped.)

> As others have pointed out, these behaviors are to let you manually wrap your source but have the output be auto-wrapped

Ah. That makes sense finally. However - I've never needed this ability whilst I constantly suffer from the non-intuitive default behaviour. Cure worse than disease?

In danger of being redundant:

> I always use a single line break to indicate a single line break.

Markdown isn't all that different from Word in this respect: hard linebreaks are second class citizens. In word, a single <enter> inserts a paragraph break, while <shift-enter> inserts a linebreak. In markdown a single linebreak inserts an (optional) space, while "<space><space><enter>" is translated to a hard linebreak.

It is very rarely that you need linebreaks in article/body text (eg: a book, newspaper article). One exception might be for dialogue:

   - "I don't know.", said Tom.
   - "Me neither.", I replied.

You'd probably want a break after the periods, no matter if the column broke up on eg: the comma or in the middle of a longer quote. This is all very different with source code, obviously.

It's a trade-off: Are most plain documents somewhat sloppily formatted wrt. paragraph/line breaks? I think this is probably true. And for natural language text, what you usually want for good layout, is soft word wrap. Lack of good word-splitting (hyphenation) for <p>-text in browsers have probably set back web layout 20 years -- and chrome is still a hold-out: https://bugs.chromium.org/p/chromium/issues/detail?id=47083

I don't use Word. I use normal text editors and plain text emails. So when I write text I often break it up into smaller parts. I write things like:

>argumentative essays

>off the cuff

pick one

if the quote is on the same line (like it is in Markdown formatting) the effect of a "choice" is lost, which is why I have to put two line breaks after it

Markdown isn't plain text, however - while annoying, you could achieve the desired formatting with markdown both in plain "unrendered" mode, and in eg: html, by appending "<space><space><enter>" for forced linebreaks. There's no equivalent AFAIK for hn markup, you'd have to use a pre-block:

  - pest
  - cholera
  pick one.

I believe the choice to translate single-enter to a space that can be reflowed is actually based on among other things email-formatting: https://tools.ietf.org/html/rfc2646#section-4

I suppose the reasoning for not sticking with "<space><cr><lf>" for soft breaks, and "<cr><lf>" for hard breaks is that plain text on *nix uses just <lf>. So either most people would get ugly <cr>-marks and/or inconsistent <cr><lf>s in their README.md-files, or something other than rfc2646 was needed.

I'm not sure what you mean about there being hard limits in place. While the implementation discussed here deals exclusively with paragraphs, the ideas are extensible to far more.

Quill, for example, is pretty feature-rich and has a similar model to that described here.[0]

The core idea is simple: forget about HTML, instead have your own data structure which represents a document in a saner way. Implement a series of functionally pure actions on that data structure and then map UI activity onto those actions (potentially using ContentEditable fields as an input). Then, React-style, your HTML is a pure function of the internal document structure.

I used a similar technique to build a rich text editor at a startup and we definitely didn't encounter anything which couldn't be done, including fairly complex structures (ex. quizzes with photo options and captions.). It definitely worked well and was a lot less error-prone and hacky than TinyMCE.

That being said, it was also a 6 month effort to get a full feature set in place. If you don't have that kind of time and just want something that works (and you don't need to extend it much), TinyMCE is fine.

Agreed that Markdown is a non-starter for almost anyone non-technical.

[0] https://github.com/quilljs/quill

I'm technical and Markdown enrages me almost daily.

TinyMCE is great. I've worked on multiple projects where this editor is being used and IMHO it is one of the easiest way to get out of the WYSIWYG Content-editable situation.

The source code [1] is modular and easily readable, so you can make yourself a decent plugin and add it to your code.

For some a blocker might be GNU license, but overall I think it's a great choice saving developer-hours.

1 : https://github.com/tinymce/tinymce/tree/master/js/tinymce/cl...

Reply on news.ycombinator.com