[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

[Ryosuke Niwa]

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.
>