[whatwg] Ongoing work on an editing commands (execCommand()) specification

Wed Mar 2 11:18:08 PST 2011

On Tue, Mar 1, 2011 at 5:11 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Styling a Range doesn't support styleWithCSS=false

I saw this feature in Mozilla's docs, but I don't really get it.  What
use-cases does it have?  Why do we need to support both ways of doing
things if they create the same visible effect?

> Ignores possibility of JavaScript modifying DOM while your algorithm is
> running - This is actually consistent with TOT WebKit where dispatches of
> DOM mutation events are delayed until the editing command finishes its
> algorithm.

Hmm, I hadn't considered that.  Since I'm not an expert on this, tell
me if I understand correctly: most JavaScript will never get a chance
to run in the middle of this algorithm, since events that get fired
will wait to execute until the browser spins the event loop (?).  But
some events are synchronous, which means they could theoretically
interrupt the algorithm, and those could mess everything up.  Right?

I've added a note to the spec in the Issues section.

> Unstyling a Range doesn't work for text decorations because overriding
> text-decoration property doesn't clear underline nor line-through.

This is already noted as an issue in the spec (under "underline" in
the command list).  I wrote a post to www-style asking for a new CSS
property to use here:

http://lists.w3.org/Archives/Public/www-style/2011Feb/0641.html

As I point out in that post, attempts to do anything with the current
properties are inevitably going to fail in some cases.  E.g., this
fails to remove the underline in Chrome:

data:text/html,<!doctype html>
<button onclick="execCommand('underline', false, null)"><u>U</u></button>
<div contenteditable=true style="text-decoration: underline">
<p>Hello there!
</div>

If you de-underline part of this text in Chrome, the underline color
changes on the rest:

data:text/html,<!doctype html>
<button onclick="execCommand('underline', false, null)"><u>U</u></button>
<div contenteditable=true>
<p style="text-decoration: underline; color: red"><span style="color:
blue">Hello there!</span>
</div>

Etc.  So if we want a fix that won't fail in corner cases, we need CSS
support for disabling ancestor text-decoration, and if we have that,
my current general approach works.

> Styling a Range / Unstyling a Range doesn't seem to split the range into
> segments of phrasing contents.  How does your algorithm avoid wrapping a
> non-phrasing element with a span? (e.g. we don't want to wrap div,
> blockquote, etc... with a span)

I currently avoid this by just not wrapping anything but text nodes.
This is part of what makes the algorithm horribly messy: bolding

    abc <i>def</i> <br> ghi

gives

    <b>abc </b><i style="font-weight: bold">def</i><b> </b><br
style="font-weight: bold"><b> ghi</b>

instead of

    <b>abc <i>def</i> <br> ghi</b>

This is clearly not acceptable for a final algorithm.  I plan to work
on polishing the markup cleanliness later, after I've got all the
important features more or less working.  Currently I haven't even
looked at commands as basic as "delete" -- although hopefully a lot of
my work has been done for me by the research Google published some
months ago on some of these commands.

On Tue, Mar 1, 2011 at 11:39 PM, Roland Steiner
<rolandsteiner at google.com> wrote:
> First, could it be that the link you posted is broken (I get "404 - No such
> project." when clicking on it)?

It seems to be some sort of bug in Gmail and/or Chrome -- it converts
the semicolons to %3B, which causes gitweb.cgi to interpret the query
string as one long parameter (since it uses semicolons to delimit
query parameters instead of ampersands), which causes it to not find
the repo.  It works in Gmail from Firefox, and by copy-pasting in
Chrome.

> In general, I completely agree on 2), but I think there are several issues
> with 1) and the "messy DOM" part:
> .) If you produce messy DOMs, the DOM will get ever more messy the more the
> user edits stuff. IMHO producing nicer DOMs is more important than simple
> algorithms. Also, the messier the DOM, the harder it is for editors to cope
> with it. FWIW, for the new Browserscope RichText test suite I took the
> opposite stance: that the resulting DOM should be as concise as possible.

I agree that in the long term, the DOM needs to be simpler than what
I'm currently producing.  I've changed the draft to clarify my intent
for future revisions.  For now I'll focus on laying the groundwork for
other features, and later I'll get back to fleshing out the stuff I've
already started.  This way I'll have a better grasp of the big
picture.

> .) In your results you mix element-based styling and CSS-based styling. I
> don't think that's a good idea, for 2 reasons (apart from looking
> inconsistent): 1.) you force complexity on code that perhaps could live with
> just simple element-based markup  2.) whether to produce element-based
> styling or CSS-based styling should be determined by whether or not
> "StyleWithCSS" was set. (Now, I'm not a huge fan of that command, but I do
> think it's important for users to have a way to specify this).

First, why do you think it's important for users to have a way to
specify this?  I don't understand what the use-cases are.  We should
just go with the simplest output that achieves the desired result, no?

Second, the way I've currently specced it is essentially only
CSS-based.  It's inspired by how Gecko works by default.  The only
time I insert elements is around text nodes, where I have to insert an
element anyway, so I use (for instance) <b> instead of <span
style="font-weight: bold">.  I initially tried a purely element-based
approach, but it wound up being far more complicated.  I might return
to that approach in the future, however, especially now that I've seen
an explanation of how WebKit does it (which seems no harder than how
I'm doing it now, and maybe easier).

Thanks again to everyone who's commented so far.