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

[Ryosuke Niwa]

On Wed, Jul 27, 2011 at 4:51 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> 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.
>
>
Feedback on selections 5 through 7:

   - The definition of collapsed line break isn't clear.  Maybe it's br
   immediately before the end of a block?
   - Isn't this essentially the collapsed line break and a br inside a block
   where br is the sole visible node?
   - The definition of visible should definitely take display: none and
   visibility: hidden into account.  Also, you should take collapsed whitespace
   into account.  e.g. " <br> " is invisible even though there are Text nodes
   before and after br.  CSS2.1 spec section 16.6.1 has some elaboration on how
   whitespace is collapsed.
   - Step 3 in "remove extraneous line breaks before" seems redundant
   because we traverse the tree in the reversed tree order in step 4.
   - What are "sibling criteria" and "new parent instructions" in 6.2?
      - Also where would new parent be inserted if new parent's parent was
      not null?  Or will it stay where it was?
      - I'm not sure why we'd need to add br's so aggressively in this
      algorithm
   - Can 6.3 be tied with "phrasing content" concept used in the rest of
   HTML5 spec?
   - 7.2: Firefox appears to differentiate backColor and hiliteColor; namely
   backColor is always the first non-transparent background color of the block
   ancestors.
   - 7.2: The last time I checked, only WebKit respected vertical-align for
   "sub" and "sup" so I'm not sure we should keep that.  It appears that all
   other browser ignores vertical-align.
   - 7.6: In WebKit, we have the concept of *typing style*, which is a
   collection of CSS styles that will be applied when user types characters
   (uses b, i, etc... when StyleWithCSS is false).  Maybe we can introduce this
   concept in the spec, and step 2 in 7.6 can update that?
   - 7.7: Should we assume two colors are same if both of them had alpha=0
   since they are transparent anyway?
   - 7.8: WebKit (and Firefox 5 as far as I checked) regards 700, 800, & 900
   as "bold".
   - The algorithm to compute the legacy font size in 7.11 doesn't really
   match the one WebKit and Firefox implement. Maybe it's better to say it's
   the numbers between 1 and 7 such that it would have produced the closest
   font size to the resolved value of "font-size" in pixels when used in font
   element's size attribute.
   - 7.15: WebKit uses blacklist.  And IE doesn't modify any inline style
   declaration so I'd vote for black-listing.  I did an extensive research
   about this when I recently re-implemented WebKit's RemoveFormat:
   https://bugs.webkit.org/show_bug.cgi?id=43017

I've read a part of sections 7 and 8 but I've kind of lost here.  The spec
is very detailed and I can't really get a high-level view of what will
happen.  It might be helpful to have some high-level summary of what it
tries to do for each algorithm something like one at the beginning of 7.6.

I'm mainly concerned that there doesn't seem to be a good way for me to
check whether the current implementation is consistent with your spec
because the spec is defined in terms of algorithms.  Indeed, it's a NP-hard
problem :(

Also, I'm not certain if there's a much value in each browser matching the
spec exactly.  I feel like we need to have some kind of tolerance level as
done in browserscope's RTE2 test suite (+roland since he worked on this
stuff).  Test suites like Roland's might also help us determining whether
your spec is consistent with browsers' or not.  In fact, is there a way we
can run browserscope tests under your reference implementation?

- Ryosuke