On 24/06/2014 20:09 , Ben Peters wrote:
Works for me. Should I just scare up a draft? It is likely to be a pretty short
spec :)
I'm really looking forward to getting things sorted out! But I think
we may want to take a step back and make sure we all agree on the
problem, goals, and use cases, as Ryosuke has been pushing for. We
have several different proposed solutions. Does it make sense to very
clearly state all of this before we press on too quickly?
Sure, but this is just one of the moving parts we need, and I think it
is well established that it is required. The existing contentEditable
has many built-in behaviours that cannot be removed by browser vendors
without breaking existing deployed code. This includes both native UI
and default actions for many events.
It's a small spec, it's just what is needed in order to enable the
baseline behaviour. The meat is elsewhere :) I was proposing to start
putting it together not because it's hard but to get a bit of momentum
going.
Problems:
* ContentEditable is too complex and buggy to be usable as-is
* ContentEditable does not easily enable the wide range of editing scenarios
Complex and buggy aren't necessarily show-stoppers. With hard work it
should be possible to take the current Editing APIs draft and
progressively iron out most of the kinks. It's difficult, but difficult
things have been done before.
The main problem here is that even if we did that we still wouldn't have
a usable system. And I would say that the issue isn't so much that it
doesn't enable scenarios more than that it works actively hard to make
them hard to implement :)
Maybe this can be captured as "Does not support
http://extensiblewebmanifesto.org/";.
Goals:
* Make it easy to disable browser behavior in editing scenarios
I don't think that we should make it easy to disable behaviour;
behaviour should be minimal and well-contained by default. Put
differently, maybe this should be "Editing behaviour should be opt-in
rather than opt-out"?
* Enumerate available actions in a given context before and after javascript
adds/modifies behavior
I'm not sure I understand what that is?
Use Cases:
* Create a js framework that enables a WYSIWYG editor and works the same in all
browsers with little browser-specific code
s/little/no/ ;-)
* Use a js framework to insert a customized editor into an email client
* Use a js framework to insert a customized editor into a blog
* Use a js framework to insert a customized editor into a wiki
Aren't those the same as the previous one?
* Create a document editor that uses an HTML editor as a frontend but a
different document model as a backend
I don't know if we want to mention MVC and other such things? Perhaps
just the general sanity of not using your rendering view as your model :)
--
Robin Berjon - http://berjon.com/ - @robinberjon
