Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Plans for cross-browser normalization for contenteditable #5

Open
balupton opened this issue May 10, 2011 · 9 comments
Open

Plans for cross-browser normalization for contenteditable #5

balupton opened this issue May 10, 2011 · 9 comments

Comments

@balupton
Copy link

How lightweight will Hallo be? In other words:

  • Will it bother about the cross browser differences?
  • Will it bother with only HTML5 browsers? or HTML4 too?
@bergie
Copy link
Owner

bergie commented May 11, 2011

I think the focus will be on modern browsers. So unless somebody wants to bother with the efforts of legacy IE support, it won't be there.

As for cross-browser differences in generated HTML, the initial plan is to use jQuery clean (http://code.google.com/p/jquery-clean/) in getContents, and probably also for paste events.

@balupton
Copy link
Author

https://github.com/balupton/html5edit would be a good low-level interface for this (which could then implement jquery clean if needed), allowing Hallo to focus just on the UI

@bergie
Copy link
Owner

bergie commented Jun 15, 2011

+1, this is probably the right way to go

@BladeBronson
Copy link

I'm very interested in this project. Even the basics seem to be in great need of normalization. For instance, pressing enter twice to create a new "paragraph" will only create a paragraph if already in a paragraph - otherwise a series of divs are used. Should this level of normalization be a goal for Hallo?

@bergie
Copy link
Owner

bergie commented Jun 16, 2011

@BladeBronson: cross-browser normalization is indeed important. I think that falls under the jurisdiction of @balupton 's html5edit in the scheme where html5edit is the contentEditable core, and Hallo is the UI

@bergie
Copy link
Owner

bergie commented Oct 7, 2011

Hallo's UX is heavily built on the concept of selections. When you're writing content, you're just writing. When you make a selection, a popover toolbar appears underneath. This popover should only display the commands relevant to the current selection (following rules around inline vs. block-level elements, etc).

Because of this, the lower level library should provide us the APIs and events that inform us of selections, actions possible for them, and allow us to execute these actions.

The actions will include stuff like bold and italic, changing the blocklevel element, and inserting content like images, links, and RDFa-marked annotated content (like persons).

if html5edit can do this for us, that will make life a lot easier for Hallo and practically any other rich text editor out there.

@bergie
Copy link
Owner

bergie commented Jun 28, 2012

The idea of Hallo is to provide an easily usable rich text editor that has a permissive license, and which is as easy to use as any jQuery Ui widget. A major part of this is a good and universally functioning way to handle the actual HTML formattings, regardless of which browser is used to make them, or whether they come through copy-paste.

Since this is a quite large problem space, it makes sense to join forces here with other editor projects. There are some projects that explicitly seek to aim a rich text editor core that can be used with different shells (which Hallo would then be). Here is a non-exhaustive list of them. Editor cores that have an incompatible licensing model are not considered:

  • HTML5 Edit - very interesting handling of selections, but doesn't appear to be actively maintained (ping @balupton)
  • wysihtml5 - actively maintained and with a focus on secure mark-up generation, but uses IFRAMEs instead of actual in-line editing
  • Substance Surface - very early stage library with a promising approach based on operational transformation, which would make collaborative editing easy to implement
  • Squire - another editor core built on IFRAMEs
  • Rizzoma - another operational transformation editor core, but with all comments in Russian

@bergie
Copy link
Owner

bergie commented Jul 11, 2012

Here are some notes on what we would need from Surface: substance/surface#2 (comment)

@bergie
Copy link
Owner

bergie commented May 6, 2013

http://yields.github.io/editable/index.html by @yields is another one, based on the web components idea.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants