[webkit-dev] Fwd: webkit editing rewrite?

[Ojan Vafai]

On Tue, Aug 3, 2010 at 5:06 PM, Simon Fraser <simon.fraser at apple.com> wrote:
> I assume you plan on maintaining support for the DOM Range API?
> <http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html>

Yes. We're stuck with them unfortunately.


On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>> -Ensures that the APIs we expose to the web are at least good enough for our own editing code
>
> I don't think this necessarily follows. Not everything exposed to the internal editing implementation would necessarily be exposed to the web. If we required that everything exposed to the internal editing implementation be exposed to the web, that would substantially slow development, since every new API would need to be vetted and possibly standardized. So this is either not true or a substantial con.

This would have been a fine point without the last sentence here. I'm
not sure how to read that sentence without the implication that I'm
either being stupid or manipulative. FWIW, I do think that everything
exposed to the internal editing implementation should eventually be
exposed to the web. I'll expand on that below.


On Wed, Aug 4, 2010 at 3:07 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> Are they correspondingly bad at C++? If so, that might be an argument for using JavaScript instead of C++, but a better solution would probably be to find engineers who are good at C++.

I understand your point and I agree with it. But, that's not the point
Alex was making and this phrasing is unnecessarily confrontational.


>> -Ensures that editing code never crashes (outside of JSC/V8 bugs)
>
> JavaScript can still crash -- you just get an unhandled exception instead of a segfault. It's not clear to me why that would be better. I can think of reasons why it would be worse:

Incorrect behavior + an unhandled exception seems better to me than
crashing. It's an especially bad user experience to crash while
editing given the implied data-loss.


> You're not considering the hurt that the editing JavaScript code could put on website code. If the editing memory footprint is large, the GC hit on other websites could be substantial.

I hadn't considered this. Good point.


On Wed, Aug 4, 2010 at 12:53 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> (1) A new editing API exposed to Web content.
> (2) A new set of fundamental abstractions to build editing on top of (which maybe has to be the same as #1?)
> (3) A change in implementation language for much of the editing code from C++ to JavaScript.
> (4) A from-scratch rewrite of the whole editing subsystem, rather than an incremental refactoring.

On Aug 4, 2010 4:30:01 PM PDT, Darin Adler <darin at apple.com> wrote:
>> On Aug 4, 2010, at 3:48 PM, Ryosuke Niwa wrote:
>> To put it another way, our not being able to implement the existing
>> editing commands using the public APIs indicates that we're not
>> providing good set of APIs now.
>
> Designing and creating a new lower level set of editing functions that
> you could build higher level commands on top of them seems like a
> worthwhile thing to do. I’m hoping that our existing editing code
> provides some clues about what we’d need. I’d love to see some specific
> proposals.

On Tue, Aug 3, 2010 at 4:38 PM, Darin Adler <darin at apple.com> wrote:
> Inventing a new layer to rebuild editing on top could well be good. Exposing that layer itself to webpages seems like it makes the job even harder rather than easier! Hidden implementation details can be changed more easily than exposed APIs.

I agree that these can be separated out. 1 and 2 are the ones I really
care about. 3 and 4 were just an idea of one way to get there. I'm not
attached to them.

I was picturing that we would first implement all or most of our
editing code on top of the editing API and then, once we were
confident with it, expose it as a webkit prefixed set of APIs that we
propose to the appropriate standards body. I'd like to see an approach
to this where we move (incrementally) in the direction of a clearly
defined editing API that the editing code uses that we can eventually
expose to the web.

I'll try and make some concrete proposals in the coming days.

On Aug 4, 2010 4:30:01 PM PDT, Darin Adler <darin at apple.com> wrote:
>> On Aug 4, 2010, at 3:48 PM, Ryosuke Niwa wrote:
>> > I think the kind of crashes Ojan is talking about are ones caused by
>> DOM mutation events.
<snip>
> It’s possible we’ll address this by changing how DOM mutation events
> work.

We need to change how DOM mutation events work regardless of this
proposal IMO. So, lets keep that a separate discussion.