Might be hard to change the behavior of browser to match the spec in some cases (e.g. backColor on Gecko)
Need to way to measure the consistency between the reference implementation and browsers - test suite, maybe let reference impl. run WebKit/Gecko's test suites to see how much it passes?
Need to handle nested editability, SVG, MathML (we should at least not garble SVG & MathML)
It would be good if implementations could converge gradually on parts of the spec which don't break web compatibility too badly
Need more editor use cases (and also non-editor use cases)
Do not add equivalent thing on after editing command event
Do not evoke observers after each editing command; we should de-couple editing and mutation notifications
Would like to address most (editing) use cases by after editing command event
The goal here is to provide a simple API which doesn't try too hard to prevent the authors from doing stupid things
Each UndoManager should be non-reentering. For example, while a transaction is in progress in one UndoManager, another transaction should not be started on the same UndoManager.
We mostly ignore the weird scenarios which could happen with nested UndoManagers.
<del>Remove proper sequence of managed transactions, just say that DOM states must be same</del> <ins>This won't work in the case where we have an editor and canvas/SVG/MathML /etc... because the latter won't necessarily have the same DOM state.</ins>
undoscope: managed transactions shouldn't revert any changes outside of undoscope
UndoManager should have both manualTrasact & managedTrasact instead of implicitly determining the kind
Each execCommand call, if there is no current transaction, will start a new one which will span both the before and after events firing
Add TransactionEvent, Undo, & Redo events; just needs to be spec-ed. One use case for TransactionEvent could be enabling the Undo/Redo buttons in the UI of the webapp.
TransactionEvent is not necessarily related to "after editing action" events, since a single transaction might include multiple execCommand calls
Editing command events
before editing command:
Should let scripts replace browser's implementation by preventDefault-ing the event
Should have command name and value
Maybe normalize value so that scripts don't have to parse color, fontsize, etc...?
Probably doesn't need other properties
Canceling the before event will prevent the after event from firing
May want to do some sanity checks before firing the "before" event, but shouldn't perform any command specific checks before firing this event, in case scripts want to change the behavior so much that the check would not make sense
after editing command:
fixup / cleanup / do extra stuff
need to know use cases - rniwa contacts editors
We prefer to add less properties at first, and add more as people come up with use cases
Add a way to create new "blank" Selection objects (document.createNewSelection/window.createNewSelection -- bikeshedding!)
Get rid of multi-range selection - ehsan will (hopefully) hide it from scripts. need to discuss this with other Gecko folks
Maybe invest time on how to better support table editing (future project)
We should follow up with the web editor widget authors to see what kinds of stuff they would want us to expose. Aryeh is going to talk to them.
This is all future work, we should wait for the spec to stabilize before jumping into this
Keyboard/caret navigations needs to be specified at some point
There might be cases which need to be platform specific, but we should try to be as specific as possible
Resizing and table editing UI
Gecko tries and fails, webkit doesn't try to provide any UI
We think that we may be able to hijack the CSS resize property
We may want to provide resizing handles as the UI for images, tables, block elements, etc
Table editing UI needs to be a future project, definitely wanted, but too big to tackle at this point
Annie gave an overview on how collaborative editing works
We want semantic information on events about what the user wants to do (before/after events which we discussed go a long way towards this)
We want selection change events (possibly cancellable events)
Authors want semantic information on how the selection is going to change, for example, extending a selection by one word forward
Google docs gave up on contentEditable because of implementation differences between UAs, and also because of their custom layout requirements
Aryeh and ehsan think that p should be the default paragraph element, Ryosuke doesn't agree (or at least other WebKit people don't agree; Ryosuke will talk to them)
Having a changeTag command of some sort would be extremely useful for the div/p or b/strong case
The transaction logs which can be captured from transaction/undo/redo events might help with the data model problem and also the diffing problem
The Mutation Notification events may also help here
Ryosuke mentioned the idea of adding a "marker" to the mutation notifications to denote the transaction boundaries, but it seems like this is something that we should support only when somebody comes up with a concrete use case for.