> On Mon, May 16, 2011 at 12:20 PM, Aryeh Gregor > <[email protected]>wrote: > > > > > This is very presentational thinking. > > > > Correct. This API was designed and is used presentationally, not > > semantically. Both authors and users want presentational formatting > > here. That's why it's called "What You *See* Is What You Get". > > > > I completely disagree. As a user, I want semantics when I write my > blog > entry on WordPress so that I can tweak presentation afterwards. e.g. I > have > frequently used em {font-style: normal; font-weight:bold;} strong > {text-decoration:underline; font-weight: normal;} in the past. > > And when I press enter, I want a paragraph separator NOT a line break.
I agree. Furthermore, I think it makes no sense for the spec to pretend to have a hard line against presentationalism (to the point of trying to define <i> and <b> to mean something other than italic and bold) while supplying a built-in mechanism for creating totally presentational markup. I'd want contenteditable to supply an editor that's suitable for producing content that's correct for the purposes of the rest of the spec. That is, I think pressing return should create a paragraph break. On the other hand, I think the commands for italicizing and bolding text should generate <i> and <b> and those should be defined to mean italics and bold. In other words, I think the old IE behavior makes sense and I think the Gecko and WebKit behaviors of creating a soup of <br> and style="..." are unfortunate. That libraries feel the need to fix e.g. Gecko output in JS to get more IE-ish behavior is indication that the Gecko/WebKit approach isn't good. -- Henri Sivonen [email protected] http://hsivonen.iki.fi/
