[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

Ryosuke Niwa rniwa at webkit.org
Thu Aug 4 14:22:42 PDT 2011

On Wed, Aug 3, 2011 at 1:13 PM, Aryeh Gregor <ayg at aryeh.name> wrote:
>  On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > Feedback on selections 5 through 7:
> >
> > The definition of collapsed line break isn't clear.  Maybe it's br
> > immediately before the end of a block?
> Unfortunately, that's not good enough if we want it to be correct in
> all cases.  For instance, the <br> in <p><span><br><!-- foo
> --></span></p> behaves like a collapsed line break for CSS purposes.
> Maybe we could just let the algorithm be wrong in those cases, if we
> can't come up with a better definition.  The problem is that a real
> definition would depend very heavily on CSS.  This is why there's a
> big red box in the spec . . .

I see.  It's an interesting point.  In WebKit, we're quite inconsistent in
relying on CSS/rendering engine and pure DOM.  This is an inherent issue in
RTE because user would like the editor to work like WYSIWYG yet we have to
produce conforming markup :(

visibility: hidden shouldn't be taken into account, I don't think.

Such nodes still take up space, they just don't get painted, so they
> don't behave like real invisible nodes.

Right.  But you definitely don't want to place a caret / selection end point
inside a node with visibility : hidden.  So to that extent, you'd have to
mention it somewhere (definitely when you're normalizing selection end

> Step 3 in "remove extraneous line breaks before" seems redundant because
> we
> > traverse the tree in the reversed tree order in step 4.
> I'm not sure what you mean.  Step 3 is "While ref has children, set
> ref to its lastChild", and step 4 is "While ref is invisible but not
> an extraneous line break, and ref does not equal node's parent, set
> ref to the node before it in tree order".

Ok.  I misunderstood your algorithm then.

> To wrap a list node list of consecutive sibling nodes, run the
> following algorithm. In addition to node list, the algorithm accepts
> two inputs: an algorithm sibling criteria that accepts a node as input
> and outputs a boolean, and an algorithm new parent instructions that
> accepts nothing as input and outputs a node or null. If not provided,
> sibling criteria returns false and new parent instructions returns
> null.
> """
> I also changed "sibling criteria" and "new parent instructions" to use
> <var> instead of <dfn>/<span>, to match other variables.  Does that
> make it clear?
> http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=2992f823

I still don't understand exactly when sibling criteria returns true and
which node new parent instructors returns.  Where are these algorithm

> Also where would new parent be inserted if new parent's parent was not
> null?
> >  Or will it stay where it was?
> I clarified in a comment:
> http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=5771e7c0

Does it make sense now?

Yes!  Thank you.

Basically every time I add a <br>, it's because I found a case in
> tests where there was some bug otherwise.  As far as I know, every
> time a <br> is added, it's needed to stop two lines from running
> together -- I avoid adding unnecessary <br>s and in fact remove them
> in a lot of places.  If you look closely at the conditions, these
> <br>'s will only be added when you're wrapping in block elements.
> Things like if you have
>  <blockquote>foo</blockquote>[bar]
> and the author runs "indent", it has to become
>  <blockquote>foo<br>[bar]</blockquote>
> not
>  <blockquote>foo[bar]</blockquote>
> None of these should normally do anything if you're wrapping in
> something like a <b>.  Are there any specific cases that you think are
> unnecessary?

Not really. Surprisingly or not, it's a very common technique used
throughout WebKit's editing code.   I just wished we could avoid adding br
if we were to only remove them later.

The biggest problem with phrasing content is that it's only defined for
> valid elements, but we need to also care about things like <font> for
> compatibility.

I see.  That's very unfortunate.  Can we defined the list in terms of the
phrasing content though?  Or define phrasing content in terms of your

There's no interop on what backColor does, and I wound up defining it
> identically to hiliteColor.  This basically matches the behavior of IE and
> WebKit, but Gecko and Opera behave differently.

I personally think Gecko and Opera's behavior makes more sense here.

I honor vertical-align because WebKit will currently create such markup in
> styleWithCSS = true mode, although the spec says not to, so I wanted
> the algorithm to handle the existing markup correctly.  If WebKit
> wants to change, I'd be happy to remove this from the spec, since it
> complicates things.

This is a WebKit bug that I've been intending to fix:

This seems like it's the same basic idea as "state override" and
> "value override".  I clarified what those are meant to do, since it
> probably didn't make sense on a first reading:
> http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=22697d3d
> Do you think anything else needs to be changed about how these work?

I don't think so although I might have missed something.  I just think that
introducing the concept of "typing style" might make the spec easier to read
and understand.

I think it's simpler not to.  The worst that happens is we replace one
> transparent color by another, which doesn't matter, so there's no
> point in making it more complicated.


See the comment next to "inline command activated values" for bold.
> On my test systems with default settings (both Ubuntu 10.04 and
> Windows 7 IIRC), 600 and up translates to bold in IE, Firefox, and
> Opera, and 700 and up translates to bold in Chrome.

How did you test that?  As far as I know, WebKit considers 600 to be bold as

queryCommandState will definitely return true when font-weight is 600 in the
following example:

> I'm mainly concerned that there doesn't seem to be a good way for me to
> > check whether the current implementation is consistent with your spec
> > because the spec is defined in terms of algorithms.  Indeed, it's a
> NP-hard
> > problem :(
> Implementations will have to be rewritten to match the spec, yeah.

I don't think we can do that in any foreseeable future.

> They're not going to give the same results if they weren't written
> from scratch to behave like the spec.  A good test suite should be
> able to check if implementations are matching the spec well enough.

Yeah, I think having a good test suite will help us improving our code base
and match the spec to a reasonable degree.

The RTE2 test suite needs to have some tolerance because otherwise it
> would just fail almost every browser for almost every test.  Once we
> have an exact spec, I don't see why browsers shouldn't match it
> exactly.

But I don't think WebKit or any other browser vendors are ready to rewrite
the entire editing engine.  We need a way to gradually improve our code to
match the spec, and a comprehensive test suite will just do that.

I wrote my own tests, which formed the basis for a lot of the spec:

> http://aryeh.name/spec/editing/autoimplementation.html

Very nice!  Can we have scores for each component so that?

- Ryosuke

More information about the whatwg mailing list