Re: Rendering: contenteditable

On Wed, 10 Jun 2009 07:27:00 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> On Wed, Jun 10, 2009 at 1:23 PM, Ian Hickson <ian@hixie.ch> wrote:
>
>> On Fri, 15 May 2009, Simon Pieters wrote:
>> > The spec should say in the rendering section that a block that is an
>> > editing host and would with normal CSS rules collapse, should instead
>> > act as if it had a line box so that it doesn't collapse. This is in
>> > order to allow the user to be able to click in the element to place  
>> the
>> > caret and start typing.
>>
>> This would cause the rendering to not be at all WYSIWYG.

I don't see how that's relevant. It's what's inside the container that's  
supposed to be WYSIWYG, not the container itself.


>> I have, however,
>> made the spec explicitly say that the caret is like an empty inline and
>> that _it_ causes a line box to appear.
>>
>
> You mean this text?
>
> The current text editing caret (the one at the caret position in a  
> focused
>> editing host) is expected to act like an empty inline element for the
>> purposes of the CSS rendering model.
>>
>> This means that even an empty block can have the caret inside it, and  
>> that
>> when the caret is in such an element, prevents margins from collapsing
>> through the element.
>
>
> Unfortunately that won't work. I know CSS 2.1 says that you can't  
> collapse
> through a block that has a line box, but Gecko, Webkit and Presto all
> collapse through a block that contains only an empty inline element.

Indeed.


> Not
> sure about IE but I strongly suspect CSS 2.1 will have to be amended for  
> Web
> compatibility.
>
> It's a good idea in principle but I'm not sure what to write here.

Opera places a <br> element in an empty block when you put the caret in  
there, so that's already solved.

The problem I was trying to solve here is *before* you put the caret in  
there. It's hard to click in a zero-height block.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 10 June 2009 09:24:36 UTC