- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Wed, 27 Jul 2011 16:51:31 -0700
Feedback on sections 1 through 3: - WebKit treats any font-weight above or equal to 600 as bold because that's what user sees, and boldness is a binary concept in execCommand; Firefox 5 appears to do the same. - WebKit compares colors in rgb/rgba format; e.g. red is first parsed as rgb(255, 0, 0). Firefox 5 seems to does the same as well. - WebKit compares font sizes in legacy font size used in font element; See CSSStyleSelector::legacyFontSize or legacyFontSizeFromCSSValue in EditingStyle.cpp - Throwing SYNTAX_ERR might cause a backward compatibility issue because the UAs don't throw an error now. We can probably throwing console messages first to give authors some grace period to transition. - For font element vs. span with style issue, we could add another boolean flag that forces UAs to toggle font-element; i.e. add StyleWithFont command. - 3.2: Prefix "webkit-" doesn't seem natural given all editing commands use Camel case. Maybe Ms, Gecko, WebKit and Opera? e.g. WebKitFontSizeDelta. But again this might cause a backward compatibility because we do implement few editing commands that are not in the spec and they are not prefixed. - 3.3: The return value of queryCommandEnable depends on beforecut, beforecopy, and beforepaste events and selection state in WebKit; WebKit returns false if default actions are prevented in those events or selection is not a range. Firefox 5 appears to do the same for selection but doesn't seem to fire beforecut, beforecopy, and beforepaste. - Ryosuke On Tue, Jul 26, 2011 at 2:26 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote: > Since February, I've been working on writing a detailed specification > for browser editing, primarily the document.execCommand() and > document.queryCommand*() methods. These were created by Microsoft in > the 1990s and were subsequently adopted in some form by all other > browsers, and today browsers have to implement them to be compatible > with web content, but no detailed specification ever existed. > Interoperability is practically nonexistent as a result, which has > driven all major content editing frameworks away from using > execCommand(). Hopefully we can start to fix that and make these APIs > a part of the web platform that just works. > > The current version of the specification is at > <http://aryeh.name/spec/editing/editing.html>. It's about fifty pages > printed, and supersedes the Editing APIs section of HTML > < > http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis > > > (which is more like two pages). In the style of modern web specs, it > is phrased in terms of algorithms that attempt to cover all corner > cases unambiguously and leave no behavior undefined, and it tries to > match the behavior of existing browsers to the greatest extent > possible. At this point, it's stable and complete enough that I > believe it's ready for serious review by implementers, and I would > like as much detailed feedback as possible. > > There is a basically complete JavaScript implementation, which is used > to produce expected results for a largely undocumented and entirely ad > hoc test suite: > <http://aryeh.name/spec/editing/autoimplementation.html>. I used the > tests as an aid to writing the spec, and they probably aren't well > suited to aid implementers in implementing it. I will probably get > around to porting them to something like testharness.js at some point. > I haven't tried testing my implementation on real-world sites, only > on artificial input, so I don't know at this point how implementable > it really is, but the JS implementation means that it at least has > large parts that make sense. > > Anyone reviewing the spec should be advised that I put extensive > rationale in HTML comments. If you want to know why the spec says > what it does, check the HTML source. I plan to change this to use > <details> or such in the near future. There are lots of minor known > issues still left, but none that I thought was important enough that > it needs to delay review. Feedback can be sent to the whatwg list, > CCing me, with [editing] in the subject. (I'm also fine receiving > feedback on public-html or public-webapps, but I don't know if the > chairs would be okay with that, since it's off-topic.) I should be > available to respond to all feedback promptly at least through the end > of August. After that, I can't make specific guarantees about my > availability, but I do plan to continue maintaining the spec in the > long term. > > I've CCd or BCCd everyone who's commented on or contributed to this > spec at some point. >
Received on Wednesday, 27 July 2011 16:51:31 UTC