- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Thu, 12 Jan 2012 11:47:06 -0500
- To: "Hallvord R. M. Steen" <hallvord@opera.com>, Simon Pieters <simonp@opera.com>
- Cc: Markus Ernst <derernst@gmx.ch>, Ryosuke Niwa <rniwa@webkit.org>, Ojan Vafai <ojan@chromium.org>, Ehsan Akhgari <ehsan@mozilla.com>, "Michael A. Puls II" <shadow2531@gmail.com>, WebApps WG <public-webapps@w3.org>
On Thu, Jan 12, 2012 at 4:58 AM, Hallvord R. M. Steen <hallvord@opera.com> wrote: > Probably a stupid question, but one I've always wanted to ask: couldn't we > default to a different, smaller, possibly 0 margin for P when in editable > content? As Markus says: it breaks WYSIWYG. The idea of contenteditable is you can write a blog post or something in a contenteditable area, then post the resulting HTML to your web page in non-editable form and have it look the same. Having contenteditable behave differently means that you write the post, get it looking the way you want it -- and then suddenly when you post it, it looks different for no obvious reason. On Thu, Jan 12, 2012 at 5:50 AM, Simon Pieters <simonp@opera.com> wrote: > Currently the editing options available, other than enabling and disabling > contenteditable, use the execCommand API. I don't see why we should switch > to attributes for new editing options. To make editing options per editing > host, I prefer this proposal: > > . . . As do I -- I suggested new attributes before I saw Ojan's suggestion. > Indeed, e.g. shift+enter doesn't break out of lists, so it's not equivalent. > Making it equivalent would be adding some complexity. Good point. I didn't think of that. > So what's the use case? :-) If none are presented, I object to adding it > based on the Avoid Needless Complexity and Solve Real Problems design > principles. Agreed. That some authors are using it is not a strong enough reason to support it.
Received on Thursday, 12 January 2012 23:45:10 UTC