[whatwg] Request for feedback: supported elements for formatBlock
Simetrical+w3c at gmail.com
Thu May 26 13:40:11 PDT 2011
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
> 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
> 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.
More information about the whatwg