Alternatives to scribe for text formatting

[SgtOddball]

As per conversation on #410 to consider an alternative to Scribe for the text formatting on Sir Trev.

The reasons for asking to consider this is based around my own and other Sir Trev users' issues with the lack of documentation from Scribe (even they admit it themselves but very little has been done since this acknowledgement) as well as poor browser support (Scribe officially only supports Chrome and Firefox desktop versions).

As a replacement to consider that uses very similar methods to Scribe would be Quilljs which has strong browser support, better documentation as well as a more active development scene behind it.

[ninjabiscuit]

This is a really good idea. We've been following quill for a while, however we weren't aware of it at the time that we decided to implement Scribe. We need to do a bit of investigation into whether it meets all our needs and how me might go about integrating it. Good call though. Maybe @callum has some opinions?

[callum]

Quill is certainly a much nicer solution than Scribe. It abstracts away the complexities of patching HTML and instead handles events and builds an internal document structure, of which HTML can be generated from. A much cleaner, better-supported approach in my opinion.

I don't see any reason not to go ahead with it, but then I am least familiar with the Sir Trevor codebase. I defer @raffij to make a decision on it.

[andflett]

OH HAI

Agree with Callum on this. A clean document document structure is something
which is just not possible while allowing people to write HTML. No matter
how cleverly you transmute it.

Therein lies the theory behind ST separating -- from a users perspective as
well as in document structure -- block from inline elements
http://www.w3schools.com/html/html_blocks.asp.

However, we were little too literal with this in terms of UI. The theory
remains sound, I believe, however others
http://slackhq.com/post/130081834025/refreshing-posts-20 have handled it
better.

On Thu, 3 Dec 2015 at 12:13 callum notifications@github.com wrote:

Quill is certainly a much nicer solution than Scribe. It abstracts away
the complexities of patching HTML and instead handles events and builds an internal
document structure http://quilljs.com/docs/deltas/, of which HTML can
be generated from. A much cleaner, better-supported approach in my opinion.

I don't see any reason not to go ahead with it, but then I am least
familiar with the Sir Trevor codebase. I defer @raffij
https://github.com/raffij to make a decision on it.

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

[dwb]

The idea with Scribe wasn't to allow people to write HTML, just for rich text to be serialised as HTML. If Quill does this better than Scribe, super duper.

[raffij]

Quill works for what i've been doing with some new features. Manipulating delta arrays is much nicer than working with all the html edge cases in browsers i've been working to fix. If it can read and write html in exactly the same way in all browsers then i'm happy with it as a solution.

Also if it works with mobile browsers then this is a big bonus too.

@SgtOddball thanks for starting the discussion.

[andflett]

Sorry, I didn’t put that well.

As far as the human is concerned, they are inputting rich text, be it
Scribe or Quill, but as soon as it hits the browser it becomes HTML, which
then has to be then transformed into something structured in a way which
can then be reliably stored, queried and transformed in a view.

Be that transformation from messy HTML to clean HTML, or from messy HTML to
JSON, or from messy HTML to a RDBMS, it always starts with messy HTML so
long as you rely on browsers to take those key strokes and impart their
opinion on what the user use meant without that opinion being made explicit.

So, for what it’s worth, I believe that content should not be stored as
HTML, temporarily in the browser, nor permanently the database; HTML it too
opinionated, as much as it pretends to be a structured language, it’s
really a presentation layer.

Quill is closer to this than Scribe, but it’s still essentially a
work-around.

I think what Medium, Slack etc. have shown is that it’s possible to stick
to this clean technology approach while providing an elegant user
experience.

So, why are we still trying to hack HTML input/output?

A

On Thu, 3 Dec 2015 at 14:00 Dan Brown notifications@github.com wrote:

The idea with Scribe wasn't to allow people to write HTML, just for
rich text to be serialised as HTML. If Quill does this better than Scribe,
super duper.

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

[raffij]

I knew what you meant really and agree.

If we do use quilljs then we can store data as deltas and set the format on the text blocks.

[dwb]

If we don't store Quill deltas (and I can't see that being a good plan), we'd have to choose something to serialise to. You could either use HTML or something equivalent to it. HTML is better understood, more widely supported, and easier to eyeball than some odd other format. It's totally possible to generate clean HTML: Scribe does it, it's other aspects of Scribe we're not so happy with.

[raffij]

@dwb as you say html is best for us, but just wanted to say it's possible now with the updates we did when scribe was added.

It's also different when you control the entry and output in a closed environment such as medium / slack.

[callum]

You need to store deltas and HTML.

[lukaszsagol]

HTML should be enough?

[SgtOddball]

Eep, I must admit I didn't think this would strike up such a storm so quickly.

Personally, so long as the HTML block/inline states are preserved in the Sir Trev data arrays then that should be ideal as I can apply any further customisation when storing the block elements. (Which reminds me, I really should look at outputting to flat pages...) as I currently do now.

@raffij With regards to setting format on the blocks, would this include inline formatting as well or would we talking the whole span/div/{insert html element of choice}? As I would have thought that would be a step back for those of us who've done some enhancements already to the format bar (underlines, font resizing and that kind of jazz) which relies on being able to apply the HTML over the select text.

(Which reminds me, need to check how Quill handles anchor tags. I like to use things like phone numbers, email addresses and the like which usually end up getting ignored)

[dwb]

Don't you only need to store deltas if you want to preserve undo stages? Which isn't really necessary?

[SgtOddball]

I'm gonna look like a right idiot on this one, but would it be possible to clarify what you mean by delta arrays (I get arrays and how to handle them for just about anything, I'm not that slow) as I get the feeling its not what I think it is.

(Yes, I never actually went to uni/college to do programming, how did you know?)

[raffij]

@SgtOddball http://quilljs.com/docs/deltas/

[SgtOddball]

......RTFM..... excuse me while I go cry in a server room....

[SgtOddball]

In that case after actually doing some reading, I'd agree with @dwb on this one.
Once the edits have been saved/committed then the deltas aren't needed any more since the changes should be in the HTML as it appears on the page.

The only reason I can see for them to be changed would be if you wanted version/authorship type facilities so you can add who did what over the life of the block/text.

This would however cause issues if the block was removed as it should then also remove said history making it a half measure if saved or requiring versioning against the blocks as well.

Your own requirements may of course differ but thats what comes to mind after having a quick nosy.

[callum]

To my understanding deltas are instructions for rendering a document. History is managed elsewhere. So the point of storing deltas would be to restore the state of a document to the editor when you're making changes to it. I believe it can also parse the HTML back into a delta, but whether that's how you're supposed to do it, I don't know.

[ninjabiscuit]

I like this idea in theory but doesn't it present us a problem with
backwards compatibility?

On Thursday, 3 December 2015, callum notifications@github.com wrote:

To my understanding deltas are instructions for rendering a document.
History is managed elsewhere. So the point of storing deltas would be to
restore the state of a document to the editor when you're making changes to
it. I believe it can also parse the HTML back into a delta, but whether
that's how you're supposed to do it, I don't know.

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

Made by Many Limited is registered in England and Wales (No.06346338).
Registered office: Diespeker Wharf, 38 Graham Street, London, N1 8JX, UK

Made by Many Inc is registered in the State of New York (No.4427021). 65
Greene Street, 4th Floor, New York, NY 10012, USA

[raffij]

Something we have to consider is quill produces valid html, but not like you'd expect from an html editor.

slab/quill#252
slab/quill#228

This is a paragraph

This is another paragraph
with a breakline.

------

<div>This is a paragraph</div>
<div><br></div>
<div>This is another paragraph</div>
<div>with a breakline.</div>

[ninjabiscuit]

That's annoying. Perhaps that matters less to us as we're using blocks for each new paragraph now?

[raffij]

We'll want to see what the overhead of an editor per paragraph is with this.

[lukaszsagol]

The default branch on quill repo is develop and includes a complete rewrite of the editor, which is unfortunately not finished yet.

The current stable version doesn't look great: https://github.com/quilljs/quill/tree/0.20.1

[SgtOddball]

I've opened a can of worms with this one!? I'll have a further look over the weekend and possibly see if there's any others that fit the bill better than Quill or Scribe (though at least with Quill they seem to be doing something and are willing to support the community).

@raffij I wouldn't have thought the overhead was that much greater than scribe, it seems to push about the same about of stuff into the console et al as scribe does but again I'll see if I can't find a way of comparing them both (been itching for something new to play with ff dev edition on so this looks ideal).

As for the current stable version @lukaszsagol at least it's being developed further. Scribe just seems to get minor bug fixes and thats your lot (at least from what I've been following since starting with Sir Trev and trying to get my head around scribe as well) but I do see your point, wonder if it'd be worth forking an experimental version of Sir Trev and see just what it takes to at least get some basic blocks up and going with it instead.

[lukaszsagol]

I think that Quill is still a good alternative, I would just wait for them to release the next version (after the rewrite) and asses it then. I'm really glad we're having this conversation as Scribe is what it is, and we should be on the lookout for something better.

Because we decided to use HTML as a data format for text blocks we need to make sure that editor we use produces consistently good quality output across different browsers - not sure if current Quill can promise that with their current version.

[SgtOddball]

@lukaszsagol Thats a fare comment, and with regards to consistent HTML at least they're covering more browsers than scribe (that said I've only had seriously weird behaviour on Android chrome (Android FF seems to be behave well) and <IE11 (.natch but I'll be damned if I'm going to have to develop for <IE any more, bloody thing has taken far too many weeks/months/years of my life trying to fix it's idiocy.)