[whatwg] Request for feedback: supported elements for formatBlock

[Ehsan Akhgari]

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