[whatwg] Request for feedback: supported elements for formatBlock

[Aryeh Gregor]

On Thu, May 26, 2011 at 12:53 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> The problem is with queryCommandValue.  One of the reasons we support so
> many block elements is so that queryCommandValue returns a sensible value.
>  For example, if called queryCommandValue('FormatBlock') inside a
> blockquote, I'd expect to get blockquote back, not an empty string.

I'd expect to get an empty string, if there's no line wrapper.  So if
you had "foo<br>bar", querying the value would return nothing, and if
you formatted as <p>, it would become "<p>foo</p><p>bar</p>".
Likewise, if you had "<blockquote>foo<br>bar</blockquote>", querying
the value would return nothing and formatting as <p> would get
"<blockquote><p>foo</p><p>bar</p></blockquote>".

> I'm still skeptical that no web content depends on blockquote being
> supported by FormatBlock on WebKit.  You might argue that they'll have to
> modify anyway due to IE not supporting it but most of editors do feature /
> browser detection and heavily rely on their current behavior.

I just looked a bit more closely, and it turns out no one except
WebKit treats blockquote like other elements.  Given
<blockquote>foo</blockquote> with "foo" selected, if you run
execCommand("formatBlock", false, "<p>"), Chrome 13 dev produces
"<p>foo</p>".  IE9, Firefox 5.0a2, and Opera 11.10 produce
"<blockquote><p>foo</p></blockquote>", which is what my current spec
says too.  So on that score, clearly WebKit's behavior is going to be
less web-compatible than the current spec.  On the other hand, Gecko's
and Opera's wrapping behavior means the command creates <blockquote>s
it can't remove, which doesn't seem useful at all.  IE's behavior
makes the most sense, and is as likely to be web-compatible as any of
the other three behaviors.

(Opera's behavior actually seems a bit complicated.  It will add
blockquote as a wrapper sometimes and replace a preexisting element
sometimes, but it seems it will never remove an existing blockquote.)

> And WebKit is
> also a part of Mac OS X framework and native applications that use WebKit as
> a part of their applications have no incentive to support Trident, Gecko, or
> Opera behaviors.

I'm aiming to write something that works well for the web.  If you
have lots of non-web engine-specific content, maybe you'll eventually
need to have multiple modes, the way IE handles IE-only intranet
content.

> Okay, I'm fine with that.  But I'm still not convinced that WebKit should
> drop the support for other elements because there is virtually no benefit in
> dropping the support other than the fact we'll conform to the spec.
> In general, I'm not convinced that all browsers should support the exact set
> of elements for FormatBlock.  Having the set of elements supported by all
> browsers seems to suffice.

It doesn't, as the example given above shows.  Supporting
blockquote/article/etc. the way WebKit does changes the behavior of
execCommand("formatBlock", false, "<p>") also, in common cases.  Try
getting out an execCommand()-based WYSIWYG editor, type some text,
indent it, and then make it a header or pre or something.  In WebKit,
and only WebKit, this outdents the text.  That's very unexpected
behavior for the user.