Re: Rendering: contenteditable

On Wed, 10 Jun 2009, Robert O'Callahan 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 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. 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.

On Wed, 10 Jun 2009, Anne van Kesteren wrote:
>
> Maybe "act like a replaced element with the height of the line box and a 
> width of zero".

I've done something more or less like what Anne suggests.


On Wed, 10 Jun 2009, Simon Pieters 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.

What should the following render as?

  <style>
   div { margin: 1em; }
  </style>
  <div contenteditable>
   <div></div>
   <div><div></div></div>
  </div>


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

I'm not sure that's a particularly great solution, but this is solved in 
the spec too now.


> 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.

I don't know how to resolve this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 8 July 2009 00:56:11 UTC