On Thu, 13 Sep 2012 23:04:13 +0200, Ojan Vafai <o...@chromium.org> wrote:
But on the other hand, it looks like everyone but Gecko does do it,
although I'm sure the details are totally different. And it's
certainly nice for usability. So it would be nice if we had some good
way to spec it. I wonder if Opera does it in a saner-to-spec way.
I think Opera generally tries to automatically focus the *first*
contenteditable element (at least for top-level browsing context), which
inserts a <br> (the <br> adding still happens for iframed documents even
though we don't focus in that case).
See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1767
(click "Rendered view" to get it in a top-level browsing context).
However, this auto-focusing is not implemented by other browsers for
contenteditable (only for designMode) and has caused us some minor
problems, so we're most likely going to stop doing so. Automatically
inserting a <br> before the user has put the caret there seems a bit
annoying and makes the :empty selector never match.
The way I'd want to see this happen is to expose a CSS property that
prevents collapsing empty elements, then we'd add something like the
following to the UA stylesheet:
*[contentEditable=true] { empty-collapse-behavior: no-collapse }
That sounds like a good solution on first blush and might even be
something authors would like to use for other elements. However, the
selector is wrong since contenteditable is an enumerated attribute which
allow mixed case, and further the empty string is a valid keyword (meaning
true). I think this would be correct:
*[contenteditable=true i], *[contenteditable=""] {
empty-collapse-behavior: no-collapse }
(Bikeshedding: I think the "-behavior" part is usually omitted in CSS;
c.f. border-collapse.)
--
Simon Pieters
Opera Software
