[whatwg] Request for feedback: supported elements for formatBlock

[Aryeh Gregor]

On Thu, May 26, 2011 at 1:56 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> WebKit's FormatBlock basically supports all HTML5 elements that are display: block by default.

Well, not really.  It doesn't support body, ol, or listing, for
instance.  It does support many more than any other browser does, and
I don't think this is useful.

>>
>> The issue with all the non-IE browsers is that they support a bunch of
>> things that make sense to nest within one another, and formatBlock
>> doesn't work for nesting.  So for instance, if I do
>> execCommand("formatBlock", false, "blockquote") on
>> <p>foo</p><p>bar</p>, what's the result?  Firefox produces
>> <blockquote><p>foo</p><p>bar</p></blockquote>, Chrome produces
>> <blockquote>foo<br>bar</blockquote>, and Opera produces
>> <blockquote>foo</blockquote><blockquote>bar</blockquote>.
>
> I think Chrome's and Opera's behaviors make most senes here given that FormatBlock removes the current enclosing block and replace it with the specified block in other situations.

Sure, but given that, does it make sense to support blockquote for
formatBlock at all?

> If you argue that blockquote can be nested, then I'd argue that any block elements except p can be nested in various situations.

Of the elements I mentioned (address, div, h*, p, pre), h*, p, and pre
are only allowed to contain phrasing content -- i.e., not block
elements.  address is allowed to contain flow content, but with
significant restrictions (no headers or sections).  Furthermore, to
the extent people use it correctly at all, it will usually contain
only phrasing content.  All examples given in the spec contain only
phrasing content.  As for div, it shouldn't be on the list, but all
browsers support it, so I'm forced to add support unless browsers are
willing to drop it.

I don't think any of this justifies adding blockquote, which is not
supported by all browsers and whose *usual* use is to contain multiple
blocks of content.

>> As for Chrome or Opera, their way of doing things might make sense in
>> some cases for blockquote, but usually you want the way indent behaves
>> instead.  If I select two paragraphs and want to put a blockquote
>> around them, normally I want a two-paragraph blockquote, not a
>> two-line blockquote or two blockquotes.  It doesn't make any sense at
>> all for things like article -- you want
>> <article><p>foo</p><p>bar</p></article>, not
>> <article>foo<br>bar</article> and certainly not
>> <article>foo</article><article>bar</article>.
>
> I disagree.  It depends on context.

In what context would you want to convert
<p>foo</p><pre>bar</pre><p>baz</p>, say, into
<article>foo<br>bar<br>baz</article> instead of
<article><p>foo</p><pre>bar</pre><p>baz</p></article>?  If you really
wanted to do this, we should have a command to convert <p>/<div> into
<br>, and a separate command to wrap or unwrap in tags like <article>
along the lines of indent/outdent.  What are the use-cases for wanting
to wrap in <article> anyway?  What are the use-cases for wanting to
wrap in <blockquote> where indent/outdent don't work?

> I think we have to support blockquote.  The last time I checked, Gmail used FormatBlock to add blockquote around the quoted context.

I checked using:

javascript:var doc =
document.getElementById("canvas_frame").contentWindow.document.getElementById(":et").contentWindow.document;
var execC = doc.execCommand; doc.execCommand = function() {
console.log(arguments[0] + " " + arguments[1] + " " + arguments[2]);
execC.apply(this, arguments); }; void(0);

(I had to get the id by inspecting the DOM; I think it varies.)  Gmail
uses the indent and outdent commands for blockquote.  Which makes
sense, since everyone supports those, and IE doesn't support
formatBlock with blockquote.  My proposal is to converge on the
intersection of what all browsers currently support (plus possibly
dd/dt, which only Opera doesn't support).