- From: Ehsan Akhgari <ehsan@mozilla.com>
- Date: Sat, 19 Mar 2011 02:09:11 -0400
On 11-03-04 10:23 PM, Ryosuke Niwa wrote: > > On Sat, Mar 5, 2011 at 3:58 AM, Aryeh Gregor<Simetrical+w3c at gmail.com>wrote: > >> On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwa<rniwa at webkit.org> wrote: >>> >>> Backward compatibility. I suspect that there are many web contents that >>> depend on styleWithCSS available on WebKit / Gecko. >> >> Generally, I've been assuming that sites that already use >> execCommand() will either 1) not depend on particular markup, since >> the markup tends to vary so widely between browsers, so any markup >> that achieves the same effect is okay; or 2) use browser-sniffing, in >> which case they'll break no matter what when things are standardized. >> In other words, I think there's going to be some level of >> compatibility pain no matter what when browsers converge here. > > > I disagree. The editing behaviors of browsers are fairly consistent across > browsers as of now even though they fail to deal with many edge cases. > While we should try to spec and agree on those edge cases, we shouldn't > suddenly change the overall editing behavior of execCommand at this point. I agree with Ryosuke here. >> 1) Always use tags (<b>,<i>, etc.) if they're conforming, even in CSS >> mode. >> > > This breaks backward compatibility. Seconded. > 2) In CSS mode, use CSS where the tag isn't conforming (<font>, etc.) > or there is no tag (like hiliteColor). I would argue that in CSS mode, we should always use inline CSS styles. > 3) In non-CSS mode, use tags where available even if not conforming > (<font>, etc.), and only use CSS if there's no tag for the feature > (like hiliteColor). Agreed. > 4) Interpret parameters as consistently as possible between CSS and > non-CSS modes. E.g., for foreColor, output directly as a CSS color in > CSS mode; in non-CSS mode, translate the CSS color to a simple #123456 > type color and use that for<font>. (Unless it's a color that<font> > doesn't support, like with alpha; then I guess use CSS.) This avoids > having the same command achieve different visual effects in different > modes. WebKit already behaves something like this, but Gecko doesn't > (see my earlier color=ff0000 example). This makes sense to me. > 5) CSS mode should be the default. I haven't made up my mind on this one yet... > Gecko and WebKit both honor it, but in >> >> substantially different ways. E.g., with styleWithCSS on, Gecko will >> output something like<p style="font-weight: bold">Foo</p> if you bold >> a paragraph, while WebKit will output something like<p><span >> style="font-weight: bold">Foo</span></p>. >> > > In my opinion, they're equivalent and consistent enough although it's nice > to agree on which DOM to produce. I agree with Ryosuke here as well. -- Ehsan Akhgari Mozilla Corporation http://ehsanakhgari.org/
Received on Friday, 18 March 2011 23:09:11 UTC