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

----- Original Message -----
> From: "Aryeh Gregor" <Simetrical+w3c at gmail.com>
> To: "Ehsan Akhgari" <ehsan.akhgari at gmail.com>
> Cc: "whatwg" <whatwg at lists.whatwg.org>, ehsan at mozilla.com, "Hallvord R. M. Steen" <hallvord at opera.com>, "Ryosuke Niwa"
> <rniwa at webkit.org>
> Sent: Monday, March 21, 2011 1:25:40 PM
> Subject: Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
> On Sat, Mar 19, 2011 at 1:23 AM, Ehsan Akhgari
> <ehsan.akhgari at gmail.com> wrote:
> > I don't think this is a useful argument for not supporting the CSS
> > mode.
> > ?But if you're looking for examples, a quick Google search suggested
> > ?that
> > elRTE can take advantage of the CSS mode (possibly among many other
> > rich
> > text editing frameworks).
> 
> As I said, I looked at three rich-text frameworks that used
> execCommand(), and all three forced styleWithCSS to false. You're
> right that elRTE has a styleWithCSS option, but it defaults to false,
> so by default elRTE also forces styleWithCSS off. Theoretically a
> site using it could re-enable it, but are you aware of any site
> actually doing so? Just because the software supports it doesn't mean
> anyone uses the feature.

Like I said, I don't see why this is a useful argument.  I just meant to give you an example of somewhere that can use the CSS mode, and I didn't spend more than 2 minutes in googling until I found the first result.

You're proposing to remove something from Gecko and Webkit which has been supported for many years (about 8 years for Gecko).  We do not have the ability to make sure that nobody is relying on this in any of the billions of available web sites.  Unless you have a very strong argument on why we should remove support for an API as old as this one, I'm not sure that we're going to do that, and I think that Webkit might have similar constraints as well.  So far, the argument that you've proposed is extrapolating the assumption that this API doesn't have any users from three implementations which use the editing APIs.  I'm afraid you should have a _much_ larger sample if you want to draw this conclusion.

I would personally very much like to get one of the two modes killed in favor of the other, since that means an easier spec to implement, less code to maintain, and easier life for me.  But I think we should carefully think about what this would means for potential users who are using the CSS mode in their applications.

> In the face of arbitrary non-inline CSS rules, you can't rely on
> cascading to work either. What my current spec does is first try to
> wrap things with tags, because that produces the nicest markup. It
> then checks if the desired style is actually present, and if not,
> forces it using additional tags or inline CSS. For instance, when
> bolding
> 
> Foo<span class="notbold">bar</span>baz
> 
> (where there's a rule .notbold { font-weight: normal }) I produce
> 
> <b>Foo<span class="notbold"><b>bar</b></span>baz</b>
> 
> while WebKit and Gecko both produce
> 
> <b>Foo<span class="notbold">bar</span>baz</b>
> 
> which gives incorrect appearance. In styleWithCSS mode, Gecko and
> WebKit respectively produce
> 
> <div style="font-weight: bold;">Foo<span
> class="notbold">bar</span>baz</div>
> 
> (applying the style to the container) and
> 
> <span class="Apple-style-span" style="font-weight: bold;">Foo<span
> class="notbold">bar</span>baz</span>
> 
> which again both give incorrect appearance.
> 
> If I add b, strong { font-weight: normal } to my stylesheet, my
> algorithm starts using <b style="font-weight: bold">, which works just
> as well as <span style="font-weight: bold"> and is slightly shorter.
> 
> So, I don't think this is a legitimate use-case. Whether in CSS mode
> or not, the algorithm should be robust enough to deal with conflicting
> style rules -- the issue you raise is orthogonal.

It's not orthogonal, in fact.  I was talking about the case where you don't have control (or knowledge) of the target page's CSS rules.  Your algorithm works based on this knowledge.  The correct solution to your first example is this markup, FWIW:

<span style="font-weight: bold">Foo<span class="notbold" style="font-weight: bold">bar</span>baz</span>

> > Non-CSS mode: Suppose that you're writing a web based email editor.
> > Your
> > task is to create HTML emails, and automatically format the
> > plaintext
> > version of the email on the server side using simple rules such as
> > wrapping
> > bold text with asterisks, or italic text with underscores. You can
> > set the
> > client side editor to use the non-CSS mode, and then use an
> > off-the-shelf
> > Python HTML parser library to parse the simple HTML tags and replace
> > them
> > with the correct characters. Having to deal with CSS in that case
> > means that
> > you have to write a full-blown CSS parser and support style
> > resolution on
> > each node, which is not trivial.
> 
> I agree that there are use-cases for not relying on CSS. I also agree
> that there are use-cases for producing only conforming markup.
> However, I don't see the use-cases for outputting <span
> style="font-weight: bold"> instead of <b> (et al.).

I presented one sample use case.  It's easy to invent more.  :-)

> > I can give you more examples for each case, but I think the above
> > two help
> > me to drive this point home: there are legit usecases for both
> > cases, and
> > since they've both been around for quite a while, I don't see the
> > existing
> > implementations drop this support (or even worse, adopt a mixed
> > mode).
> > ?Backwards compatibility is what this boils down to.
> 
> In the end I'm going to have to go with what implementers want to
> implement here, but I'm still going to argue a bit more. :) The four
> execCommand()-using rich text editors I've looked at so far all force
> styleWithCSS to false. I'm planning to also look at some major
> webmail clients' use of execCommand(), but I'm practically certain
> they'll also force styleWithCSS false, because otherwise their mail
> won't display right in (at least) Blackberry. Likewise, if you look
> at the bug requesting that WebKit support styleWithCSS
> <https://bugs.webkit.org/show_bug.cgi?id=13490>, it seems clear that
> what the users there want is for WebKit to output things like <b>
> instead of CSS, i.e., they just want WebKit to support it so they can
> set it to false.
> 
> So I see lots of users who want styleWithCSS false, and not a single
> one yet who wants it true.

As I said above, I don't think that your sample set is large enough for drawing that conclusion.

> I can't see a backward-compatibility issue
> when there are no known sites that use of the feature, *and* when IE
> and Opera have never supported it.

Unfortunately, most rich text editing applications on the web have lots of browser specific hacks to work around the bugs in the implementations, so they may easily maintain Gecko/Webkit specific code.

> You probably know better than me, but I'm guessing the history of this
> feature went something like this:
> 
> * In September 1997, Microsoft introduces the API in IE4. CSS is a
> new technology that only cutting-edge browsers have support for, so
> they output only tags like <font> and <b>, not CSS.
> * In March 2003, Mozilla clones the API in Mozilla 1.3. CSS is now
> well-established and widely supported, and tags like <font> and <b>
> are banned in HTML 4 Strict and XHTML 1 Strict. XHTML 2 removes them
> from the language entirely. Thus Mozilla uses CSS instead. For
> compatibility with IE or due to author demand or something, they also
> add a useCSS feature to let you use deprecated tags instead, if you
> don't care about conformance or use transitional formats.

This dates back to before my time here at Mozilla, so I don't really know, and unfortunately there is nobody that I know of who knows why they really chose to do things the way that they did!

> If this is the case, the fact that styleWithCSS doesn't output tags
> like <b> or <i> is because they happened not to be valid when it was
> first devised. This is no longer relevant today. But there will be
> authors today who want conforming markup that's *also* as short as
> possible, which is what my proposed revision of styleWithCSS = true
> gives -- something that's demonstrably useful.

Something that I meant to mention elsewhere in the thread: simpler DOM structure is for sure better, but I'm not sure there's much value to try to make the string representation of the generated DOM as short as possible.

> > I think simpler DOM structures should be preferred, and we can't
> > give away
> > simple DOM structures for the sake of simpler algorithms. Browsers
> > tend to
> > have buggier behavior when it comes to editing more complex DOM
> > structures,
> > and one should also keep in mind that editing operations are
> > additive:
> > having one command generate a complex DOM would cause the next one
> > to
> > generate even more complex DOM, and so on.
> 
> I've rewritten my algorithm to produce (IMO) better markup in all
> cases than any existing browsers. There are only a few cases I've
> thrown at it where it produces markup that's worse than I'd produce by
> hand, like
> 
> <i><b>Foo</b></i>bar<i><b>baz</b></i>
> 
> becoming (when you bold "bar")
> 
> <i><b>Foo</b></i><b>bar</b><i><b>baz</b></i>
> 
> instead of
> 
> <b><i>Foo</i>bar<i>baz</i></b>
> 
> but no browser I've looked at handles that better. (Maybe I'll update
> the algorithm to handle it, too -- it's probably not that uncommon in
> practice.)

Yes, I actually think that this is a nice optimization to have in the algorithm.

> On Sat, Mar 19, 2011 at 1:39 AM, Ehsan Akhgari
> <ehsan.akhgari at gmail.com> wrote:
> >> I disagree. The editing behaviors of browsers are fairly consistent
> >> across
> >> browsers as of now even though they fail to deal with many edge
> >> cases.
> >> ?While we should try to spec and agree on those edge cases, we
> >> ?shouldn't
> >> suddenly change the overall editing behavior of execCommand at this
> >> point.
> >
> > I agree with Ryosuke here.
> 
> I also agree, in cases where browsers are actually consistent. Where
> browsers agree, I won't spec anything different without compelling
> reason. But browsers don't agree on styleWithCSS -- IE and Opera
> don't implement it.

That's true, so we should decide whether we want to support it or not.

So far in this thread I haven't seen a clear-cut argument on whether (or not) the CSS mode should be supported.  The backward compatibility concerns outweigh the arguments towards the alternative of not specifying the CSS mode at this point, the way I see things.

But more thought and comments would definitely be appreciated!

Cheers,
--
Ehsan Akhgari
Mozilla Corporation
http://ehsanakhgari.org/

Received on Monday, 21 March 2011 16:55:10 UTC