On Mon, Mar 21, 2011 at 7:51 PM, Ehsan Akhgari <eakhg...@mozilla.com> wrote: > You're proposing to remove something from Gecko and Webkit which has been > supported for many years (about 8 years for Gecko). We do not have the > ability to make sure that nobody is relying on this in any of the billions of > available web sites. Unless you have a very strong argument on why we should > remove support for an API as old as this one, I'm not sure that we're going > to do that, and I think that Webkit might have similar constraints as well. > So far, the argument that you've proposed is extrapolating the assumption > that this API doesn't have any users from three implementations which use the > editing APIs. I'm afraid you should have a _much_ larger sample if you want > to draw this conclusion. > > I would personally very much like to get one of the two modes killed in favor > of the other, since that means an easier spec to implement, less code to > maintain, and easier life for me. But I think we should carefully think > about what this would means for potential users who are using the CSS mode in > their applications.
Okay, so I've thought about this a bit, and realized my dislike for the current behavior of styleWithCSS was because of a combination of two things: 1) There is no reason I can see that anyone would actually want <span>s instead of <b>s, except XHTML 1.0 Strict conformance, which we shouldn't care about. 2) There's a good reason to want markup that is both compact and conforming, which styleWithCSS doesn't currently give -- it's more verbose than necessary to conform to HTML5. Thus I felt it would be more useful if the mode didn't affect bold and italic (and maybe underline if that becomes valid again). But then I realized that authors who want markup that's both compact and conforming could just switch styleWithCSS on or off before running each particular command -- e.g., leave it on generally, but switch off immediately before executing bold or italic. So now I have no problem with the status quo, and am happy to spec styleWithCSS/useCSS. Changing it as I proposed wouldn't really help anyone, but would remove some power from authors (in case anyone does want <span style="font-weight: bold"> for some bizarre reason) in addition to the compatibility and consistency issues. > It's not orthogonal, in fact. I was talking about the case where you don't > have control (or knowledge) of the target page's CSS rules. Your algorithm > works based on this knowledge. The correct solution to your first example is > this markup, FWIW: > > <span style="font-weight: bold">Foo<span class="notbold" style="font-weight: > bold">bar</span>baz</span> This doesn't really matter now, but -- in that case, you'd have to ensure that every single text node is the child of an element with the inline style applied, so bolding <p>Hi there, this is some <em>text</em>. <p>Go look at <a href=foo>some other page</a>. would have to result in <p style="font-weight: bold">Hi there, this is some <em style="font-weight: bold">text</em>. <p style="font-weight: bold">Go look at <a style="font-weight: bold" href=foo>some other page</a>. which nobody does or should do in any mode. And if you were doing that, there's still no reason you should want to output <span style="font-weight: bold"> instead of <b style="font-weight: bold">, because the latter will work even in non-CSS UAs and is also shorter. Unless you're aiming for HTML 4 Strict or XHTML 1.0 Strict conformance, which I suspect was the original motivation. > Unfortunately, most rich text editing applications on the web have lots of > browser specific hacks to work around the bugs in the implementations, so > they may easily maintain Gecko/Webkit specific code. If they depend on the exact markup produced based on browser-sniffing, however, they'll have to break in some browsers when browsers converge, no matter what we do. For what it's worth, I'm pretty sure all these sites are forcing styleWithCSS to false solely so that Firefox outputs more similar markup to everyone else (except the e-mail clients, which really want <font> and such). > Something that I meant to mention elsewhere in the thread: simpler DOM > structure is for sure better, but I'm not sure there's much value to try to > make the string representation of the generated DOM as short as possible. One person from Google who gave me private feedback said that one reason some Google sites moved away from using execCommand() was because of the messy markup it often produced, and specifically cited the number of bytes on the wire and ease of hand-editing as two of the problems. <b> is much better than <span style="font-weight: bold"> from both perspectives. But you can have the best of both worlds by toggling styleWithCSS selectively, so it's no big deal in the end. > Yes, I actually think that this is a nice optimization to have in the > algorithm. I'll add it tomorrow. On Mon, Mar 21, 2011 at 11:48 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > We can deprecate the CSS mode and leave it unspecified, without removing it > from Webkit and Gecko. That won't hurt interop since anyone using it is > probably UA-sniffing already. > > If sometime in the future we decide that a "CSS mode" is worth having, then > someone can start writing a spec for it then. That seems silly, since it's very simple to spec and implement. I'll just add it to the spec. On Tue, Mar 22, 2011 at 3:37 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > One thing we might want to consider is to merge elements when forcing style > or pushing down style. For example, if we had "<b>hello </b>world" and > bolded "world", I'd expect to get "<b>hello world</b>" instead of "<b>hello > </b><b>world</b>". While it's not that much of an improvement in this very > simple case, the effect is obvious when the applied on more complicated > markup. That's the first step in "Forcing the style of a node". It's really necessary the way I've written the algorithm, because the way I've written it, you style each node successively and independently. So it's very common that there's a preceding node to use, since styling the previous node likely created it. (Gecko and WebKit both also do this to a limited extent. See the tests I just added to <http://aryeh.name/spec/editcommands/autoimplementation.html#bold>, beginning with foo<b>bar</b>[baz].) > Yes, it addresses most of my current concerns except StyleWithCSS. I think > we should just obsolete StyleWithCSS and let it unspecified so that we can > keep it backward compatible. I'll spec it instead. I'm generally not happy with just leaving things unspecced if browsers aren't willing to drop support.