On 11-05-26 4:40 PM, Aryeh Gregor wrote:
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.
What is IE's behavior in this case?
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.
As Boris said, and Ryosuke agreed, non-web consumers of any rendering
engine should not affect what we specify for the web. WebKit is free to
have its non-web interface for other consumers if it needs to (as Gecko
does today).
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.
I agree. I think WebKit's behavior in this case is not ideal.
Ehsan
