On Thu, May 26, 2011 at 12:53 PM, Ryosuke Niwa <rn...@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.