In richtext2, do not require breaking up ancestors (RTE2-C_FN:c_FONTf:a-1_SI)

[GoogleCodeExporter]

The test RTE2-C_FN:c_FONTf:a-1_SI changes the font to Courier on the input

  <font face="arial">foo[bar]baz</font>

It expects

  <font face="arial">foo</font><font face="courier">[bar]</font><font face="arial">baz</font>

which is what WebKit produces.  It deems

  <font face="arial">foo<font face="courier">[bar]</font>baz</font>

to be acceptable, but not a pass.  The latter is what the editing spec 
currently requires, and what all non-WebKit browsers produce in this case 
(IIRC).  Please make this a pass too.  The two approaches each produce better 
(shorter) markup in some cases, so in the editing spec I went with the majority 
of browsers.

More detailed rationale from the spec (hidden behind a "View comments" button):

"""
If we go all the way up to the root and still don't have the desired value, 
pushing down values is pointless. It will create extra markup for no purpose. 
Except if the value is null, which basically just means "try to get rid of 
anything affecting the current element but don't aim for any specific value".

Nevertheless, Chrome 14 dev does seem to do this. Running bold on <span 
style=font-weight:300>f[o]o</span> breaks up the span and adds a <b> as a 
sibling. In IE9, Firefox 6.0a2, and Opera 11.50, it instead nests the <b> 
inside the <span>. It's a tradeoff: WebKit's behavior is better for things like

<font color=red>fo[o</font><font color=blue>b]ar</font>
-> <font color=red>fo</font><font color=green>[ob]</font><font 
color=blue>ar</font>
(where the spec adds two extra font tags instead of one), but the spec is 
simpler for things like

<font color=red>f[o]o</font>
-> <font color=red>f<font color=green>[o]</font>o</font>
(where WebKit splits the existing tag up in addition to creating a new tag). 
I'm not particularly sure which approach is better overall, so I'll go with the 
majority of browsers. If these algorithms move to use runs of consecutive 
siblings instead of doing everything node-by-node, it might make sense to break 
up the parent as long as it won't create an extra node (i.e., we're styling 
something that includes the first or last child).
"""
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#pushing-down-values

Original issue reported on code.google.com by Simetrical on 16 Apr 2012 at 1:24

[GoogleCodeExporter]

RTE2-CC_BC:gray_SPANs:bc:b-1_SI and RTE2-CC_FN:c_FONTf:a-1_SI have the problem 
too.

Original comment by Simetrical on 16 Apr 2012 at 2:12

[GoogleCodeExporter]

Ideally, from a puristic point of view, the settings of a node should be true 
for all descendant nodes. Overriding properties, such as font goes against this 
principle. For example, if you bold a stretch of text using , you have no 
recourse to an "<unbold>" tag, either.

Original comment by rolandst...@chromium.org on 24 Apr 2012 at 2:38

[GoogleCodeExporter]

I don't agree with that.  For , yes, it's best to break up the tag instead of 
inserting <span style="font-weight: normal"> (although that's necessary in 
corner cases).  But in the cases I named here, the markup that richtext2 wants 
is more verbose than the markup the spec generates.  I don't think the extra 
nesting is problematic -- we should just aim for the tersest markup possible.

Original comment by a...@aryeh.name on 24 Apr 2012 at 6:21