[Webkit-unassigned] [Bug 45784] Deleting line break before h1 converts h1 to span

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=45784





--- Comment #3 from Aryeh Gregor <ayg at aryeh.name>  2011-08-22 12:05:42 PST ---
Per my spec, it should become "hello<span style=color:red>world</span>" or "hello<font color=red>world</font>", depending on styleWithCSS.  The approach I use is defined here:

http://aryeh.name/spec/editing/editing.html#record-the-values

Basically, I specify that we preserve only styles that were inline styles of some kind to start with (either style="" or font/b/u/i/etc.).  So if a style was created by a CSS rule, we don't restore it if it gets lost.  This matches the behavior I observe in Word 2007 when creating markup like this (set second line to Heading 1, make it red, backspace).  IE10PP2, Firefox 8.0a2, and Opera 11.50 all remove the markup entirely, including coloring, which is wrong.

IMO, what I specify is what matches user expectations.  If something looks like a heading, it should *be* a heading, so <span style="font-size 32px; font-weight:bold"> is extremely confusing.  <h1 style="display: inline"> is also confusing -- who ever heard of an inline heading?  But you can't do it anyway, because if you have

  <p>hello</p><h1>world</h1>

you *cannot* produce

  <p>hello<h1 style="display:inline">world</h1></p>

because the text/html parser doesn't allow <h1> as a child of <p>.  If a document contains that markup, it will be parsed to a DOM like

  <p>hello</p><h1 style="display:inline">world</h1><p></p>

with the <h1> auto-closing the <p> and the </p> being interpreted like <p>.  So block elements inside <p> are not an option: when you serialize and reparse you'll get a different DOM.  Getting rid of the <h1> and its styles, like Word 2007, makes the most sense IMO.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.