6 ms·

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 themselve

by Jaruzel 11y ago

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.

intrasight 11y ago
Wow, that would be sweet!
Rezo 11y ago
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.
- esailija 11y ago
  Aka Extensible Web https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/
KwanEsq 11y ago
>(standardised via w3c of course) Why? They are irrelevant for that now. It would be standardised through the WHATWG.
- kuschku 11y ago
  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.
ilmiont 11y ago
Good idea... but I'm not sure the "supports" attribute would be friendly to configure, and standardisation would be hard.
- jtolmar 11y ago
  <input type="editor" supports="images;links;headings" spans="italic;bold;blinky" extras="carousel" oncarousel="function (event) {return document.createElement('div') /* TODO: implement carousel */; }"> 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.
  - majewsky 11y ago
    > 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.
    - sp332 11y ago
      It looks like you'd define your own DTD, to be a subset of HTML.
    - jtolmar 11y ago
      > 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.
morgante 11y ago
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.
dmix 11y ago
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.

by Jaruzel 11y ago

intrasight 11y ago

Wow, that would be sweet!

Rezo 11y ago

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.

esailija 11y ago
Aka Extensible Web https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/

KwanEsq 11y ago

>(standardised via w3c of course) Why? They are irrelevant for that now. It would be standardised through the WHATWG.

kuschku 11y ago
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.

ilmiont 11y ago

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

jtolmar 11y ago
<input type="editor" supports="images;links;headings" spans="italic;bold;blinky" extras="carousel" oncarousel="function (event) {return document.createElement('div') /* TODO: implement carousel */; }"> 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.
- majewsky 11y ago
  > 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.
  - sp332 11y ago
    It looks like you'd define your own DTD, to be a subset of HTML.
  - jtolmar 11y ago
    > 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.

morgante 11y ago

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.

dmix 11y ago

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.