[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
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
> > 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
> 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?
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
> > Or will it stay where it was?
> I clarified in a comment:
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
> and the author runs "indent", it has to become
> 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
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
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:
> 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
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
> 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
> > 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
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:
Very nice! Can we have scores for each component so that?
More information about the whatwg