Hacker News Reader

Comment by zv | Hacker News Reader

Whenever I see "new rich HTML editor", I notice that there is no table editing. What's the point of editor that is missing the most needed function? You could argue that it is not needed, however lack of this function leads to cases of copy-paste from word/excel with bad markup.

View on HN

I have never seen a rich editor that handles tables well. In fact I've never seen a rich editor that does much of anything well. I almost always have switch to HTML view to get anything done.

I've been thinking about this a lot with Hallo (http://hallojs.org/), and I'm starting to come to the conclusion that the traditional way of doing tables in WYSIWYG editors is simply wrong.

What is a table editor would essentially be a database query, with data coming from your CMS or some other system? Then instead of building a generic table by hand you could do things like Insert a table of attendees of this event, with columns displayName, company, and email.

I'll try to do some experiments with this in the summer.

If you've used Drupal, what you're describing is simply the correct usage of one of its most powerful pieces: Views. However, even with its somewhat decent "query" editing interface, it's still a complex task that requires some critical data-oriented thinking skills. It's important, I think, for people to be able to format an electronic table about as easily as they can do it with a pen and paper. It's a fundamental formatting operation, IMO, and there should always be a fast/intuitive way of making them.

Aloha handles Tables perfectly (including merge/split of rows & columns, plus pasting from Microsoft Word).

Check the demo - http://aloha-editor.org/builds/development/latest/src/demo/b...

Looks nice, but the Aloha licensing basically requires you to buy a license if you're going to use it commercially, whereas this one uses the very simple and open MIT license.

It's licensed under AGPLv3. I prefer MIT as well, but surely you don't need to buy a licence to use this?

https://github.com/alohaeditor/Aloha-Editor/blob/dev/LICENSE...

Furthermore, I've been trying to get them to sell me a commercial license for months. Someone sometimes emails me back, but they have yet to give me a way to give them money.

Aloha is more than a meg of JS as it stands and the documentation is pitiful.

I'm a contributor to Aloha and recently project underwent a huge re-write to cut down the cruft. Next release, will use a light weight UI based on jQuery and also switching to a newer command API based on W3C's editing API will also make things more faster (and easier).

Main issue with the documentation was the rapid changes to the API in the past. Since the API is getting stable there will be more concern on improving the documentation.

That sounds very promising. Do you have a time frame for this release?

I among others will work on the dev-jqueryui branch in June. I hope we will manage to stabilize it and merge it to dev in this time.

It should be noted that we plan to make the ui an optional part of Aloha (with default being a jqueryui implementation) to make it easier to integrate into existing systems. The heavy extjs dependency is part of why Aloha is so huge.

I also plan to look into using google closure compiler in ADVANCED_OPTIMIZATION mode to shrink the size to the absolute minimum.

Sorry, just re-read my comment and realised I came across as yet another of those entitled and grumpy anonymous commenters you find online. For what it’s worth, I like Aloha as integrated into the Aloha site, I just failed miserably despite much effort to integrate seamlessly into a recent project. I was aware of the jQuery UI rewrite but the branch didn’t seem to have had any commits in the previous two weeks when I looked so I assumed progress was slow. Glad to hear there’s more definitive plans.

I stand by my comment about the lack of documentation though. I appreciate that it’s often difficult to get people to contribute to docs over code, but it’s pretty imperative for a project like this that there’s at least an easy integration walkthrough and a handful of examples showing common customisations.

If I could +1 this a million times... that's the number one feedback I receive from CMS users in commercial environments. Please make it convenient for them to create tables!

Pah! "Just paste the table in from Word".

...and let the hilarity commence.

Copy and pasting tables from MS Office is the most needed feature? I don't know whether to raise my eyebrows or feel bad for you.

How about neither, and just try to comprehend that tables are a common use case that if we haven't perfected yet in HTML editors it's web programmers/standards' fault and not Word's?

And why is that the logic conclusion exactly?

Because tables are a basic, centuries old, typographic feature that is also needed -no ifs or buts- in HTML editors?

Sorry, I was mocking the notion that someone is supposed to interop with Word and that not magically converting from Word is somehow their fault instead of Word's. I can only image it's non standard. In fact, it's probably handled by the user-agent.

Reply on news.ycombinator.com