Everytime I see this, I wonder why browsers (and the W3C) don't add more functionality to textarea.
ContentEditable always felt like an ugly hack for me. A rich set of API on textarea could move the web forward. Imagine building an IDE in a textarea. That should be possible.
Great work nonetheless, very clean code and very nice documentation!
Also, in this day and age of sans-serif, variable-width fonts, why do we have to specify rows and cols on <textarea>?!
Then you will understand why things don't move faster.
Especially in situations like publishing, when the content creation is being done 100% by people under employment or contract. Give them a native app or browser plugin for authoring, and you can solve all these problems with much greater sophistication.
In the distant past I used to use Microsoft Content Management Server to power websites. It lacked most of the modern features of a web CMS, but it provided a native app and IE plugin for authoring. In terms of code control and consistency it kicked the ass of even the best JS libraries available today.
A native authoring app, side loaded onto employee machines, would be a much more powerful authoring solution. It would produce clean HTML code and push it into the CMS via an API call.
second, i can't help observing that efforts to use
contenteditable seem to start with a rush of success
-- as the early results are always very impressive --
but then seem to quickly bog down in the particulars.
bug-reports come in which are difficult to reproduce,
typically originating from idiosyncrasies in an o.s.,
or a browser, or (in one thorny case) a _combination_.
and although people have much enthusiasm for solving
these glitches at first, the slog is generally endless,
and, eventually, it wears down even the most determined.
at least, that's what i have observed, enough so that
-- once i started experiencing the bramblebushes too --
i pushed the contenteditable strategy off to the side.
which was easy, since i've been a long-time supporter
for light-markup. no, not markdown, since that thing
is too primitive, and forked, and fragmented nowadays,
and will give you a big dose of misery down the line.
i built my own light-markup -- "zen markup language",
extension .zml, based on the project gutenberg corpus.
i have also built a phalanx of e-book authoring-tools
over the last 20 years, and it's all come together now.
the trick is making an editor that will be acceptable to
both the light-markup adherents _and_ the wysiwyg folks,
and i think i cracked that nut. i'd like your feedback
on pre-release versions of some new stuff i'll have soon.
e-mail me at firstname.lastname@example.org if you'd like to play...
and again, best of luck to the guardian people on this!
For our 2nd client CMS, we chucked the WYSIWYG, spent a little more time helping our clients understand Markdown (actually Textile - this took a few minutes of our and their time). There was a little squirming involved on the part of our clients, but after a day or so, they understood it. Best part, it just works. It ensures that our site renders perfect, semantically correct HTML!
WYSIWYG in RTEs has grown up a bit, as we can see in Guardian's latest attempt. However, its largest flaw, from our perspective, is that it outputs HTML! HTML is just not a proper end-format. It is too difficult to reverse engineer. Markdown, on the other hand, can be rendered into many format. It can be output as HTML, raw text, truncated text, etc. So, while I applaud Guardian for releasing this, it saddens me that we're still attempting to improve on browser-based, user-facing tools which output HTML.
When I've worked on news sites in the past, many of the journalists preferred writing in their desktop word processor of choice and cutting and pasting into the CMS as the final step before publishing.
The CMS was probably viewed as a necessary evil and I don't remember there being much love for it from the people who had to spend hours in it everyday.
Partly this was due to the CMS not working offline and it just wasn't as pleasant to use as the software the writers have used for years, which is understandable.
We're only at the beginning, but the curly quotes plugin mentioned in the blog post is a good example of that. Other ideas in the pipeline include automatically enforcing and converting to UL/LI lists instead of paragraphs with bullet point characters, warning on punctuation issues, etc.
Scribe has also allowed us to integrate contextual options, such as buttons to add images when the caret is on an empty line, or a button to embed any URL pasted into the body.
So the biggest challenge is therefore to provide a reliable UI that responds as one would expect, while allowing extra features to be built on top of it without too much effort.
Markdown gets a lot of love from developers, but in my experience with clients across many industries (including journalism), it's a non-starter. If you're used to looking at markup in an editor, Markdown is an abstraction you can tolerate. But the average non-technical person tasked with the job of updating a blog or website sees Markdown as something like pig latin - a thing that makes communication more complicated.
If I were the King of the Internet and had to choose one tool for text entry it would be a system sort of like Ghost/Prose.io, where you use Markdown, but can see the results. So even laymen can get the swing of the tool developers prefer. As King, I would also levy a tax.
However, I am curious as to their stance on Markdown and if it was ever considered.
To download it to your desktop and try it out locally get [these files](https://github.com/guardian/scribe/tree/gh-pages)
Just two weeks ago I thought we'd have to implement the same thing for the same reasons: old editors were good in handling browser inconsistencies but bad in being too tightly coupled to their dated UIs, new editors sucked at generating semantic markup.
Thank you for making this public.
It looks, at least from first impression that you guys have done a much better job...hopefully it turns out to be the perfect solution my need..Thank you!
Then perform your manipulation, when done call:
Tim Down! Thank you so much for your rangy library, it is a noble library, and I respect all your hard work trying to normalize the Range API. Monotype is similar to your new Text module but behaves a bit differently, please email me so we can talk more! mark at accelsor.com
Just to make clear, this would enable Scribe to work in older IE browsers.
 - http://www.aloha-editor.org/
It's a bit more work up front, but possibly less work than trying to get four different implementations of contentEditable to behave the way you want. And this way you own the editing logic.
I tried building one a long time ago. The hard parts are mouse events (ie moving the caret based on a pixel coordinate) and pasting.
Google docs solves the mouse event problem by rendering every glyph offscreen and measuring it's bounding box. That is intensive and difficult if your font is bidi or changes by context (eg Arabic, accents). I tried wrapping every glyph in a span but it wiped out the available RAM. That may not be a problem anymore in 2014.
But on chrome, firefox, and probably safari, it appears that you can call document.getSelection() in a click handler, and the returned object will be an appropriate Caret selection with offset and node.
I recall that the selection object in older versions of IE do not offer the character offset, so you have to copy the selection and move it one character at a time until you get to the beginning of the text node. IE9 and above appear to have modern selection objects (according the MS docs). I don't know if they're updated onclick.
I guess they must have worked out that their CSS and JS was lean and minified enough that despite the extra overhead of it being in the HTML (which is even less when gzipped, I guess) and not being served from cache, it was faster than making another 2 requests. I guess there is some small overhead to fetching a file from the browser cache but surely it is tiny?
Would be interested to get more insight into this aspect of the site if anyone knows anything!
The Gruand is also trying progressive image loading.
Unfortunately it actually just looks shit, it's like peeking behind the curtains in Oz as your content kinda half renders then renders again properly, twitching into life like some sort of half botched Frankenstein experiment.
Notice the `loadFontsAsynchronously` and the `loadCssFromStorage` in the js.
In some ways I like that the Gruand's team is experimenting, in others it's frustrating to see how the creaky and leaky HTML/web browser combo is still justifying people doing all sorts of crazy things to try and get a simple page to render quickly 25 years after the web was born. And "responsive" designs that are really just mobile designs stretched to a one-size-fits-all simply because browsers are too fucking stupid to tell you what they actually need.
My Grump is in full swing today.
My offshore teammates littered our repo with inline styles for no reason. It completely changed the UI I built for the projects. I spent serval days this week trying to fix it and I am still not done.
I'm curious what support on mobile is like. I tried the demo on my Nexus 7 and it worked well for the two minutes I played. However I skimmed the browserinconsistencies.md file and did not see any specific mention of mobile browsers. Mobile is a place where most of the existing solutions fall on their face. Having good mobile could really drive adoption.
As far as I know, the solution they have here is impressive and as good as the state-of-the-art, in terms of usability and modularity...but it still can't overcome the major quirks that come up with rich-text editors.
For example, I typed in the following in the demo (http://guardian.github.io/scribe/):
So the error here is that after typing "world", I switched off the italics and hit line break/Enter. However, the italics-mode persisted into the next line. This was the generated HTML:
<p>Hello, <i>world</i></p><p><i>Why italics?</i></p>
edit: the rest of this is address to a general "you", not to "you, the Guardian developers", as in, "why didn't you just do Markdown"...though if the Guardian took the lead in that, I'd most definitely upvote that too ;)
I think rich-text editors are fine for the very layperson. But I think for professional reporters, there needs to be a move toward the expectation that they all learn Markdown. Note, I'm not saying that everyone needs to learn HTML...but Markdown is basically the exact subset of text formatting a professional online writer needs to communicate 99.9% of their reportage material, with the rest being made up through plugins/shortcode/embed, as is currently the case for most online CMSes.
Markdown can be written in any editor and is portable to a huge variety of systems and services. More importantly, even without a specialized editor, Markdown still has human-friendly structure. What else does a writer need?
Before you say: oh but we can't expect our writers to learn code-like things...this is not true at all. As an intern at the Denver Post, I spent at least a day learning the in-house editor, which was Windows-only, designed for the print-publishing workflow, and had all manner of arcane key combinations to add editing marks (again, for print, and not the web). Everyone was expected to learn it, and everyone did fine.
But unlike Markdown, this in-house closed source coding system was...well, shitty as most industry-specific codes are...and once in awhile someone would accidentally "un-hide" notes meant for an editor's eyes only, which would then show up in print. What I love about Markdown is that you don't even have to really know it to write what you need...hitting Enter creates a paragraph break, both in your text editor and the platform to which you publish. How much easier can you get?
You make some very good points about Markdown, and we spent awhile thinking about whether to go down that road or not. Although there is a technical barrier to access for Markdown, that’s not the reason we decided against it. Maybe we should do another blog post to follow up with more details regarding our decisions. (Or, I’ll come here with more details in just a bit.)
I'm just trying to get a feel of Scribe's scope... Does it want to fix all inconsistencies, even pure UI irritants, or is it mostly about ensuring correct content?
I'm tempted to write a plugin that "types" space-delete after every CR. That's the quickest and nastiest fix I can think of...
Generally speaking, it should patch behaviour to the point where it doesn’t get in the way of the user and produces clean and semantic markup. We have found that patching some of the smaller behaviour obscurities would not be trivial. If it matters to the community though, we (the open source community) can definitely get them patched!
Markdown is an abstraction that professional writers do not need. MacWrite et al solved the text-editing problem 30 years ago. Press the "paragraph" button (carriage-return); you get a new para in the content and on the screen. Press the universal shortcut for italic (cmd-I) and you get italics, in the content and on the screen. And so on.
Markdown is a hack that works around two inconvenient truths. First, in-browser editing has traditionally been shitty. Second, for those working in a coding milieu, you can't just type 'less someasciifile.txt' and have it display with the right italics, bold and breaks.
If you're a professional writer for print, none of this has bothered you since WordStar. You write in your tool of choice (most places I've worked it's been Word, though I use TextEdit). You save. The designer brings it into Quark or, latterly, InDesign, which preserves the formatting. End of. You don't need to think of "markup language" at any stage in the process, and nor should you.
Expecting the rest of the world to downgrade to a hack devised for the web is entirely backasswards. Scribe looks like a good attempt to bring in-browser editing up to the standard everyone else has enjoyed for 30 years, rather than dragging everyone down to the hack level of Markdown. Good luck to them.
(My background: former full-time consumer magazine editor, now freelance; semi-pro coder.)
And how does your process handle the checking of URLs? I've done newspaper pasteup with PageMaker since high school...as far as I remember, there was not a simple way to double check URLs. Actually I don't even remember there being such a concept as embedding hyperlink URLs into what would be print newspapers, but that's besides the point...
And correct me if I'm wrong, but where does the MacWrite magic turn into Web content? You ended your description at "designer brings it into Quark". That's not the Web. that's not even...anything.
And of course, I'm talking about a lot more than the Web here, I'm talking about a portable format that can be read without any special text editor at all. How does MacWrite fit into that?
Getting that into your medium of choice, whether that be print, the web, or whatever, is a SMOP. The Guardian have chosen to tackle this SMOP. Markdown chose to hack around it instead, but at the cost of usability.
Django was originally developed by a Kansas newspaper.
That said, I think those are exceptions, not the rule.
Tables are a problem, but tables are just as horrible to write in Markdown as they are in HTML.
I've used ckeditor 4 recently and found that pretty impressive (it was a system for a company of charity workers, not a hope in hell that markdown was going to happen) and it was good enough.
This looks like something I'd use for my own stuff.