Hacker News Reader

Comment by Jaruzel | Hacker News Reader

On the basis that browser based WYSIWYG editors have become de-rigour in almost all big online publishing platforms, it surprises me that the browsers themselves are not being updated to provide a standard input field (standardised via w3c of course) whose 'value' attribute outputs basic HTML mark-up. Something along the lines of:

  <input type="editor" supports="bold;italic;images;headings"  ... >

This would remove the massive amount of work that UI developers still have to do to hand crank something as simple as a good editor that GUI OSs have enjoyed for decades.

View on HN

If the browsers incorporate complex editors, they're likely to be subtly or even wildly different from each other in behavior. What's the "correct" behavior after hinting enter in an unordered item list, create a new bullet or start a new line for the current one? Is there a popup to create links when you highlight text? Can a heading be split over multiple lines? Some of the answers depend on the constraints of your underlying storage format like Markdown vs HTML. On the other hand, if I pick ProseMirror or Draft.js, I can be reasonably secure in that the behavior is consistent for my users.

If a capability can be implemented outside of the core browser, I think it's a good idea to do so. It's sort of like putting something into the Linux kernel vs doing it in a userspace module. The kernel/browser should provide the low-level hooks for userspace to innovate, not try to incorporate userspace components. An external project can iterate more rapidly, and there's also a lower barrier for people to contribute code and fixes. Duplicate projects "waste" resources, but they're also competing with each other and that improves quality in the long run.

Aka Extensible Web https://extensiblewebmanifesto.org/

Ideally, your CMS shouldn't even store HTML at all. It's not a pure system and makes changes hard to make in the future.

You're much better off storing an internal representation of documents and then outputting that as HTML where necessary.

In addition to the large requirement set that would have to be decided on that was mentioned elsewhere, it would probably be held back given the large hurdle involved in securing such a field. I'd imagine most of the teams would be apprehensive to be the first try to tackle that. Especially given that it will end up being reimplemented a bunch of times across browser platforms. It just sounds like introducing a large new attack surface.

Good idea... but I'm not sure the "supports" attribute would be friendly to configure, and standardisation would be hard.

With "supports" being common things with extra markup (especially images and links), spans deferring your problems to css classes, and extras deferring your problems to javascript. The element returned by an extra would always be treated as a single black box by the editor.

> supports="headings"

* Does it allow further markup inside the headings? If so, which tags? strong? emph? span? a?

* Which attributes are allowed on the <h1> etc. tags? class? style? name? id? lang? dir? id?

You see where this is going.

> spans="blinky"

Hell no.

It looks like you'd define your own DTD, to be a subset of HTML.

> You see where this is going.

Yes: the wrong direction.

Trying to support every possible thing obviously won't work - we can't replace writing HTML with a clever enough rich text field. But you can still make progress on web usability by solving the most obvious bits and adding some hooks for the easiest ways to extend it.

>(standardised via w3c of course)

Why? They are irrelevant for that now. It would be standardised through the WHATWG.

And WHATWG is more relevant? Have you ever heard of Chrome? Whenever WHATWG decides on something different than what the Chrome devs wanted, they implement their solution anyway and ignore the decision.

Anyone trying to develop for the web constantly feels the pain of trying to get something working everywhere.

Wow, that would be sweet!

Reply on news.ycombinator.com