Substance: a JavaScript library for web-based content editing | Hacker News Reader

Substance: a JavaScript library for web-based content editing

substance.io

113 pointsr0muald26 comments

Thank you for sharing this on HN. Just wanted to add our introduction blog post, which may clarify some of the questions asked here.

https://medium.com/@_mql/build-your-own-editor-with-substanc...

And some usage examples:

Scientific Writing - http://substance.io/lens - https://github.com/Coko-Foundation/pubsweet-core Spreadsheet Software - https://stenci.la/demo/sheets/iris Digital Archives: - https://medium.com/@_daniel/publish-interactive-historical-d...

Mmh, lens example doesn't work well with the ipad pro (safari). I get a zoom on a few words and can't zoom out.

For the scientific editor mobile is not a priority atm. However we work on better mobile support for Substance in general. Beta 5 is dedicated to that among other things.

looks promising, and something I'd like to use over tinyMCE.

however, the 'lens' example seems broken. in both FF and chrome (all up-to-date) I can't insert figures. FF just does nothing, chrome gives me a file chooser, but images do not appear in the document. is this a known bug ?

You are right. I may have broken that with the last update. Will be fixed soon. Generally, LensWriter is still in experimental state but we are working with publishers to integrate into their workflows. During April there will be a push on enabling LensWriter to read and write JATS XML files.

thanks, I'll look into it later on :) I played with that example because it has almost all features I normally use with tinyMCE.

Can somebody give any use case that make this project or draft.js interesting compared to all the other WYSIWYG editors available (tinyMCE, CKEditor and so on...)?

Especially since the generated HTML of the editor is very verbose and doesn't respect semantic (header1 isn't translate as h1 but a div with a super long id. Why?)

And what is so terrible about contentEditable? I spent a few minutes with it a few month ago and it felt great (and works on old version of IE), just lacking some library on top of it to give the end user a way to fully control everything.

ContentEditable is an absolute nightmare across browsers if you want to normalize your content in any way -- since there's no standard for what the generated HTML is supposed to be, every browser implements it differently (and sometimes very unusually). Couple that to the fact that you can't control what the user is doing (at least not without intercepting events where possible) and you have a feature that lands somewhere between worthless and actively malicious.

In the same way as highjacking the scrollbar, WYSIWYG editors have always feel like a hack to support end user needs without technical background. The idea of being able to seamlessly edit a website, create pages that respect semantic that even my grand ma could maintain is quite compelling to me.

Many of those editors tends to produce bad looking HTML code that might be fine for today but will become an headache to migrate to any other platform or will become an headache when somebody decide they want to change the color of all their link as their crappy editors produce inline styling ....

Anyway we might not have a one size fit all solution but WYSIWYG isn't a perfect solution either.

How about built in support for collaborative editing: https://twitter.com/juretriglav/status/710191077102395392 (they're just now working on this). The internal document model supports OT, and the collaborative feature is based on the Google Wave model.

In the very near future there will also be NLM JATS XML support (a standard format in science).

To address the verbosity: if you're looking at the output HTML, you're looking at the wrong place. That's just a rendering of the internal model, which is very succinct and semantic indeed, e.g. in XML: https://github.com/substance/lens/blob/d18d2c6353db8d97649b9...

Hi Mickael!

Each content type consists of the following pieces:

- Node (model) [1] - Component (visual representation) [2] - Converter (optional, used to map from and to XML/HTML) [3]

The verbose output for heading1 you see is just the DOM projection of the data, which is custom and can be specified in the Component implementation [2]. Often you need to add extra markup and interactive elements, so that's why for Substance content (data) is not rendered 1:1 but through a custom renderer component.

Please have a look at the examples [4], which includes minimal but functional implementations using most of the available concepts.

[1] https://github.com/substance/substance/blob/master/packages/... [2] https://github.com/substance/substance/blob/master/packages/... [3] https://github.com/substance/substance/blob/master/packages/... [4] https://github.com/substance/examples#substance-examples

Huh. I have actually been looking for precisely this --- I was going to go with the Guardian's Scribe, but I might investigate this instead.

Unfortunately it looks like it's JQuery and AMD modules, and I'm a Polymer and browserify shop, so it may just not be feasible. [sad face]

Old (veeeeeeery old) substance dev here.

They are not AMD based (have a look here indeed https://github.com/substance/substance/blob/master/browser.j...) and about jQuery I’m pretty sure you can wrap it up as a Web Component pretty easily.

I've never actually used browser-side require, so have no idea how it works --- I just saw a boot.amd.js file.

Also, did I say browserify? I meant vulcanize.

Hi! To clarify: Substance is compatible with Browserify and Webpack. It runs in Node and in the browser. It doesn't come as one big module, instead it lets you deep require individual files so your bundle only includes what you explicitly required. e.g. require('substance/collab/CollabServer').

I've deleted the amd.boot.js file as it's no longer supported.

They're going down the route of not using contentEditable, which I think is a great move. I was a little bit disappointed when I saw Facebook's Draft.js didn't do the same. It's more work up-front to get something functional, but it's a better pattern for building text editors on the web.

Nice! Glad to see mobile support is on the roadmap [1]. So many browser rich editors seem to be virtually unusable on touch devices, it's the first thing I check now.

[1] https://github.com/substance/substance#beta-5

Very exciting project, specially the support for custom document schemas.

If the authors are around, I'd love to hear what was their thinking regarding implementing focus and selection, with regards to the inconvenients outlined by the author of ProseMirror here: http://marijnhaverbeke.nl/blog/prosemirror.html#general-appr...

In a nutshell, ProseMirror chose to keep contentEditable in order to have browser-level support for spell-checking, screen-readers, RTL, etc.

What are the tradeoffs exactly?

Thanks.

I think the approaches of Substance and ProseMirror are quite similar. We map DOM coordinates to model coordinates and the other way around. That way we can use the native DOM for cursor navigation (not trivial to implement), but all input is applied on the model first and then updated in the view component.

I had a brief talk with the author of ProseMirror the other day. From my point of view the difference lies in scope. ProseMirror's focus is providing an editor widget that can be extended but works out of the box with HTML + markdown. With Substance you basically start from zero, and you probably have to invest more time to get going. But then you could build apps that are not limited to one isolated editor area for instance. You could build a custom title editor, body editor and metadata editor and have a shared toolbar for them and shared undo/redo history. Substance also provides a bunch of top-level UI components that you can but don't have to use. A ScrollPane with a visual scrollbar for instance. A Table Of Contents component, TwoPanel editor layout etc.

Just published an example that shows realtime collab capabilities:

http://substance.io/examples/collabwriter/

This looks really interesting - it's very encouraging to see it being used in real projects of quite disparate types. It bodes well for the maturity and flexibility of the model.

For something like this I usually like to see a demo before I invest time in trying it out but the demo link is broken... Seems like something I might want to explore though!!

There's a demo on the front page --- try typing into the big white box at the top with the bullet points in it.

I missed it too. Not obvious at all.

With the next release we will package the ability to have editors based on document slices (aka prjections): https://cloud.githubusercontent.com/assets/284099/13857486/6...

Does anyone know what GitHub uses for their editor?

Reply on news.ycombinator.com