Re: [editing] Leading with ContentEditable=Minimal

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

Received on Thursday, 26 June 2014 10:51:47 UTC