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

[Ehsan Akhgari]

On 11-08-06 1:33 AM, Michael[tm] Smith wrote:

Aryeh Gregor, 2011-08-04 14:22 -0400:


On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari  wrote:

Is it possible to get a unique QA contact (or default CC address) for this
component please, so that people who are interested in watching it can watch
that email address instead of member-webapi-...@w3.org?


Would this be possible, Mike?


I changed the QA contact to sideshowbarker+html-editing-...@gmail.com (a
unique address used just for this bugzilla component), so anybody who wants
to get all bugmail for this component can do that by going to here:

   http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email

...and adding sideshowbarker+html-editing-...@gmail.com to the "Add users
to my watch list" field near the bottom.

Ehsan, if that's not what you had in mind, let me know and I can get
something else set up.


That is exactly what I had in mind, thanks.

I also went ahead and changed the QA contact for the existing bugs in 
this component to sideshowbarker+html-editing-...@gmail.com.


Thanks!
Ehsan

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

[Aryeh Gregor]

On Mon, Aug 8, 2011 at 5:03 AM, Simon Pieters  wrote:
> Things that are visibility:hidden are not focusable. I don't think that can
> be changed without compat problems. If visibility:hidden things are not
> focusable, I guess it makes sense to not make it selectable, too. (Possibly
> Web pages also expect visibility:hidden things to let clicks go through?)
>
> Sense aside, visibility:hidden is not selectable in any current browsers,
> right?

Testing with foobarbaz, Firefox 7.0a2 and Opera
11.50 both allow placing the cursor in the hidden text as normal,
letting you type and delete and so on.  Chrome 14 dev jumps over it,
so if your cursor is at b[]az and you go back it jumps to foo[].
IE10PP2 just ignores the visibility and makes it visible (??).

So it seems like treating it like regular text is the best match for
current browsers, as well as the simplest, unless people have other
test-cases that are relevant.

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

[Simon Pieters]

On Fri, 05 Aug 2011 22:57:13 +0200, Aryeh Gregor  wrote:


Yeah, it all looks the same to the user, so I don't see why
visibility: hidden should be any different.  Just let the user select
and manipulate the hidden text like any other text.


Things that are visibility:hidden are not focusable. I don't think that  
can be changed without compat problems. If visibility:hidden things are  
not focusable, I guess it makes sense to not make it selectable, too.  
(Possibly Web pages also expect visibility:hidden things to let clicks go  
through?)


Sense aside, visibility:hidden is not selectable in any current browsers,  
right?


--
Simon Pieters
Opera Software

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

[Michael[tm] Smith]

Aryeh Gregor , 2011-08-04 14:22 -0400:

> On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari  wrote:
> > Is it possible to get a unique QA contact (or default CC address) for this
> > component please, so that people who are interested in watching it can watch
> > that email address instead of member-webapi-...@w3.org?
> 
> Would this be possible, Mike?

I changed the QA contact to sideshowbarker+html-editing-...@gmail.com (a
unique address used just for this bugzilla component), so anybody who wants
to get all bugmail for this component can do that by going to here:

  http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email

...and adding sideshowbarker+html-editing-...@gmail.com to the "Add users
to my watch list" field near the bottom.

Ehsan, if that's not what you had in mind, let me know and I can get
something else set up.

  --Mike

-- 
Michael[tm] Smith
http://people.w3.org/mike/+

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

[Aryeh Gregor]

On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa  wrote:
> 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've added a whole bunch of high-level summary:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13633

Tell me if there are any parts where it could use more.

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

[Aryeh Gregor]

On Fri, Aug 5, 2011 at 2:24 PM, Boris Zbarsky  wrote:
> On 8/5/11 1:59 PM, Aryeh Gregor wrote:
>>
>> Yeah, it's a problem.  The basic issue is that there are no standard
>> interfaces to query things like "what's the height of this?"
>
> That depends on how you define "height" (esp when clearance is involved).
>
>> or "are these two nodes in the same line box?"
>
> This is, generally, a nonsensical question...

Yeah, I more or less realize that.  If the questions I wanted to ask
made any sense per the CSS specs, my life would be a lot easier here.
:)

> More precisely, the basic issue you're running into is that the CSS box
> model doesn't necessarily map onto most people's mental model of wysiwyg
> editing areas (insofar as such a thing even exists).

Nor does the DOM, but I mostly get stuff to work reasonably
regardless.  Really I guess the issues are more like

1) I don't actually understand the CSS box model very well (unlike the DOM).

2) The way I'm writing my spec is by implementing it in JavaScript to
test it out.  JavaScript has complete access to the DOM, but almost no
access to the CSS box model, so it's much easier for me to test out
DOM-based definitions.

3) Since there are no JavaScript APIs to access some of the
information I'd want to use, I don't know if browsers actually store
it in a form that's usable internally by DOM methods.  I know DOM
stuff is readily accessible to internal browser methods, because you
can access it from JavaScript.  I know that when speccing innerText, I
was told things like "you can't access computed styles of nodes in
detached trees, because we don't compute them".

> It gets worse.  What about white text on a white background?  What about
> rgba(0, 0, 0, 0.01) text?  What about text with other stuff on top of it?
>  ;)

Yeah, it all looks the same to the user, so I don't see why
visibility: hidden should be any different.  Just let the user select
and manipulate the hidden text like any other text.

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

[Boris Zbarsky]

On 8/5/11 1:59 PM, Aryeh Gregor wrote:

Yeah, it's a problem.  The basic issue is that there are no standard
interfaces to query things like "what's the height of this?"


That depends on how you define "height" (esp when clearance is involved).


or "are these two nodes in the same line box?"


This is, generally, a nonsensical question...

More precisely, the basic issue you're running into is that the CSS box 
model doesn't necessarily map onto most people's mental model of wysiwyg 
editing areas (insofar as such a thing even exists).



Right.  But you definitely don't want to place a caret / selection end point
inside a node with visibility : hidden.  So to that extent, you'd have to
mention it somewhere (definitely when you're normalizing selection end
points).


Hmm, I'm not sure.  Text that's visibility: hidden looks the same to
the user as text that's color: transparent, so why should it behave
differently for selections?


It gets worse.  What about white text on a white background?  What about 
rgba(0, 0, 0, 0.01) text?  What about text with other stuff on top of 
it?  ;)


-Boris

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

[Aryeh Gregor]

On Thu, Aug 4, 2011 at 5:22 PM, Ryosuke Niwa  wrote:
> I see.  It's an interesting point.  In WebKit, we're quite inconsistent in
> relying on CSS/rendering engine and pure DOM.  This is an inherent issue in
> RTE because user would like the editor to work like WYSIWYG yet we have to
> produce conforming markup :(

Yeah, it's a problem.  The basic issue is that there are no standard
interfaces to query things like "what's the height of this ?" or
"are these two nodes in the same line box?" from CSS, so I have
nothing to reference and browser engines might not even know the
information.  So I hack around it with a mix of pure-DOM definitions,
and just not defining things clearly.

> Right.  But you definitely don't want to place a caret / selection end point
> inside a node with visibility : hidden.  So to that extent, you'd have to
> mention it somewhere (definitely when you're normalizing selection end
> points).

Hmm, I'm not sure.  Text that's visibility: hidden looks the same to
the user as text that's color: transparent, so why should it behave
differently for selections?

> I still don't understand exactly when sibling criteria returns true and
> which node new parent instructors returns.  Where are these algorithm
> defined?

The "wrap" algorithm takes three inputs: a list of nodes, and two
algorithms.  The callers provide the sibling criteria and new parent
instructions algorithms.  Take a look at the callers of the wrap
algorithm and hopefully it will be clearer.  Do you have any
suggestions on how to make this clearer in the spec?  Maybe the note I
just added at the beginning

helps?

> Not really. Surprisingly or not, it's a very common technique used
> throughout WebKit's editing code.   I just wished we could avoid adding br
> if we were to only remove them later.

That would be nice, but it's hard to figure out sometimes.  Like if
the selection is in {}, and a script does insertHTML to add
"foo", we want to remove the , but if it adds "" we
want to keep it.  And if you select {} and insertHTML to
add "", we need to make a new  regardless.  I could
write it so that it checks after the fact if the  is extraneous,
but it seemed easier to just remove it in the beginning and then add a
new one later if needed.

CSS makes me sad sometimes.  :(

> I see.  That's very unfortunate.  Can we defined the list in terms of the
> phrasing content though?  Or define phrasing content in terms of your
> definition?

There are complications.  For instance, HTML defines , , and
 as being phrasing content only if they contain only phrasing
content, which isn't useful for our purposes.  The idea of phrasing
content is meant to be concerned with authoring conformance, and it
doesn't seem well suited to what we need.  But I'd like to see
something worked out in the long term to harmonize them, yeah.  It's
just not an immediate need, it can wait.

> I personally think Gecko and Opera's behavior makes more sense here.

I don't.  Partly it's for the reason I give in the comment next to
backColor's action: it's

"""
incoherent from a user perspective. For instance, if you try it on
paragraphs the background will have big gaps where the margins are. If
you try it on an inline element that's a child of the editing host, it
will do nothing or apply the background to everything or such, even
though such an inline element is visually indistinguishable from one
sitting inside a div. This would only make sense if we take
considerable effort to ensure that block elements all have no margins,
or if we wrap things in a div if they have margins, or something like
that.
"""

background-color on block elements doesn't make sense from a WYSIWYG
perspective, because it behaves differently based on whether an
element has margin vs. padding, or whether there's a wrapper around a
block or just 's, etc.  These differences normally aren't visible
in rendering, so making command behavior depend on them is confusing.

Also, the way the spec defines it is the way both IE and WebKit
behave, so that's a large majority of the market and is probably the
most compatible.

> This is a WebKit bug that I've been intending to
> fix: https://bugs.webkit.org/show_bug.cgi?id=11089.

Okay, changed: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=b599880c

> I don't think so although I might have missed something.  I just think that
> introducing the concept of "typing style" might make the spec easier to read
> and understand.

I don't like the use of the word "style" here, because it doesn't fit
for createLink.  I could change it from "state override" and "value
override" to "typing state" and "typing value", I guess.  But it
doesn't just affect typing, either: it also affects the return value
of queryCommandState()/queryCommandValue().  Thus "override", because
it overrides the normal definition of state/value.

>> See the comment next to "inline command activated values" for bo

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

[Ehsan Akhgari]

Here's my feedback on sections 1-3.  I'll provide feedback on the rest 
of the specification in the near future.


3.2
* The "gecko" prefix should be changed to "moz", to be compatible with 
other Gecko specific prefixes.
* Do we have any other case where the HTML spec says that a browser can 
change its behavior if it's upgraded in the middle of the browsing session?


3.3
* Gecko currently has some problems in returning the correct status of a 
command based on the active range, so the results obtained from Firefox 
here should not be a determining factor (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=676401).
* On the same note, I actually think that WebKit's behavior makes sense. 
 We need to make sure that _something_ happens when the command is 
executed after making sure that queryCommandEnabled returns true.  If 
the beginning of the active range falls into an editable section, that 
would happen (perhaps to part of the range).  Initially I thought that 
it would be better to return true if any range in the selection falls 
into the editable section, but that wouldn't make a lot of sense if the 
range spans across multiple contentEditable sections.


Cheers,
Ehsan

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

[Ryosuke Niwa]

On Wed, Aug 3, 2011 at 1:13 PM, Aryeh Gregor  wrote:
>
>  On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa  wrote:
> > 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?
>
> Unfortunately, that's not good enough if we want it to be correct in
> all cases.  For instance, the  in  behaves like a collapsed line break for CSS purposes.
> Maybe we could just let the algorithm be wrong in those cases, if we
> can't come up with a better definition.  The problem is that a real
> definition would depend very heavily on CSS.  This is why there's a
> big red box in the spec . . .
>

I see.  It's an interesting point.  In WebKit, we're quite inconsistent in
relying on CSS/rendering engine and pure DOM.  This is an inherent issue in
RTE because user would like the editor to work like WYSIWYG yet we have to
produce conforming markup :(

visibility: hidden shouldn't be taken into account, I don't think.

Such nodes still take up space, they just don't get painted, so they
> don't behave like real invisible nodes.


Right.  But you definitely don't want to place a caret / selection end point
inside a node with visibility : hidden.  So to that extent, you'd have to
mention it somewhere (definitely when you're normalizing selection end
points).

> Step 3 in "remove extraneous line breaks before" seems redundant because
> we
> > traverse the tree in the reversed tree order in step 4.
>
> I'm not sure what you mean.  Step 3 is "While ref has children, set
> ref to its lastChild", and step 4 is "While ref is invisible but not
> an extraneous line break, and ref does not equal node's parent, set
> ref to the node before it in tree order".


Ok.  I misunderstood your algorithm then.

"""
> To wrap a list node list of consecutive sibling nodes, run the
> following algorithm. In addition to node list, the algorithm accepts
> two inputs: an algorithm sibling criteria that accepts a node as input
> and outputs a boolean, and an algorithm new parent instructions that
> accepts nothing as input and outputs a node or null. If not provided,
> sibling criteria returns false and new parent instructions returns
> null.
> """
>
> I also changed "sibling criteria" and "new parent instructions" to use
>  instead of /, to match other variables.  Does that
> make it clear?
> http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=2992f823


I still don't understand exactly when sibling criteria returns true and
which node new parent instructors returns.  Where are these algorithm
defined?

> Also where would new parent be inserted if new parent's parent was not
> null?
> >  Or will it stay where it was?
>
> I clarified in a comment:
> http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=5771e7c0

Does it make sense now?
>

Yes!  Thank you.

Basically every time I add a , it's because I found a case in
> tests where there was some bug otherwise.  As far as I know, every
> time a  is added, it's needed to stop two lines from running
> together -- I avoid adding unnecessary s and in fact remove them
> in a lot of places.  If you look closely at the conditions, these
> 's will only be added when you're wrapping in block elements.
> Things like if you have
>
>  foo[bar]
>
> and the author runs "indent", it has to become
>
>  foo[bar]
>
> not
>
>  foo[bar]
>
> None of these should normally do anything if you're wrapping in
> something like a .  Are there any specific cases that you think are
> unnecessary?
>

Not really. Surprisingly or not, it's a very common technique used
throughout WebKit's editing code.   I just wished we could avoid adding br
if we were to only remove them later.

The biggest problem with phrasing content is that it's only defined for
> valid elements, but we need to also care about things like  for
> compatibility.
>

I see.  That's very unfortunate.  Can we defined the list in terms of the
phrasing content though?  Or define phrasing content in terms of your
definition?

There's no interop on what backColor does, and I wound up defining it
> identically to hiliteColor.  This basically matches the behavior of IE and
> WebKit, but Gecko and Opera behave differently.
>

I personally think Gecko and Opera's behavior makes more sense here.

I honor vertical-align because WebKit will currently create such markup in
> styleWithCSS = true mode, although the spec says not to, so I wanted
> the algorithm to handle the existing markup correctly.  If WebKit
> wants to change, I'd be happy to remove this from the spec, since it
> complicates things.
>

This is a WebKit bug that I've been intending to fix:
https://bugs.webkit.org/show_bug.cgi?id=11089.

This seems like it's the same basic idea as "state override" and
> "value override".  I clarified what those are meant to do, since it
> probably didn't make sense on a first reading:
>
> http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=22697d3d
>
> Do you think anything else needs to be 

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

[Aryeh Gregor]

On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari  wrote:
> On 11-08-03 4:13 PM, Aryeh Gregor wrote:
>>
>> Mike Smith has been kind enough to add a component to the W3C Bugzilla
>> for the editing spec, in the WebApps WG product.  From now on I'll use
>> it for tracking feedback so I can be organized about things that I
>> can't fix right away.  The link to file a bug is:
>>
>>
>> http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=HTML+Editing+APIs
>>
>> I'll still respond to all e-mail feedback.
>
> Is it possible to get a unique QA contact (or default CC address) for this
> component please, so that people who are interested in watching it can watch
> that email address instead of member-webapi-...@w3.org?

Would this be possible, Mike?

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

[Ehsan Akhgari]

On 11-08-03 4:13 PM, Aryeh Gregor wrote:

Mike Smith has been kind enough to add a component to the W3C Bugzilla
for the editing spec, in the WebApps WG product.  From now on I'll use
it for tracking feedback so I can be organized about things that I
can't fix right away.  The link to file a bug is:

http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=HTML+Editing+APIs

I'll still respond to all e-mail feedback.


Is it possible to get a unique QA contact (or default CC address) for 
this component please, so that people who are interested in watching it 
can watch that email address instead of member-webapi-...@w3.org?


Thanks!
Ehsan

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

[Aryeh Gregor]

Mike Smith has been kind enough to add a component to the W3C Bugzilla
for the editing spec, in the WebApps WG product.  From now on I'll use
it for tracking feedback so I can be organized about things that I
can't fix right away.  The link to file a bug is:

http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=HTML+Editing+APIs

I'll still respond to all e-mail feedback.

On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa  wrote:
> 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?

Unfortunately, that's not good enough if we want it to be correct in
all cases.  For instance, the  in  behaves like a collapsed line break for CSS purposes.
Maybe we could just let the algorithm be wrong in those cases, if we
can't come up with a better definition.  The problem is that a real
definition would depend very heavily on CSS.  This is why there's a
big red box in the spec . . .

> Isn't this essentially the collapsed line break and a br inside a block
> where br is the sole visible node?

Sorry, I don't understand what you're saying here.

> The definition of visible should definitely take display: none and
> visibility: hidden into account.  Also, you should take collapsed whitespace
> into account.  e.g. "  " 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.

visibility: hidden shouldn't be taken into account, I don't think.
Such nodes still take up space, they just don't get painted, so they
don't behave like real invisible nodes.  I definitely need to take
collapsed whitespace into account, and display: none.  I filed a bug:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13631

> Step 3 in "remove extraneous line breaks before" seems redundant because we
> traverse the tree in the reversed tree order in step 4.

I'm not sure what you mean.  Step 3 is "While ref has children, set
ref to its lastChild", and step 4 is "While ref is invisible but not
an extraneous line break, and ref does not equal node's parent, set
ref to the node before it in tree order".  Suppose you have

foobar

and the algorithm is invoked with ref equal to the .  First we set
ref to the  in step 1.  Then in step 3 we set it to the .
Then step 4 does nothing, because the  is an extraneous line
break.  Then in step 5 we remove the .  Without step 3, ref would
still be equal to the .

> What are "sibling criteria" and "new parent instructions" in 6.2?

I changed

"""
To wrap a list node list of consecutive sibling nodes, given sibling
criteria and new parent instructions, run the following algorithm.  If
not provided, sibling criteria match nothing and new parent
instructions return null.
"""

to

"""
To wrap a list node list of consecutive sibling nodes, run the
following algorithm. In addition to node list, the algorithm accepts
two inputs: an algorithm sibling criteria that accepts a node as input
and outputs a boolean, and an algorithm new parent instructions that
accepts nothing as input and outputs a node or null. If not provided,
sibling criteria returns false and new parent instructions returns
null.
"""

I also changed "sibling criteria" and "new parent instructions" to use
 instead of /, to match other variables.  Does that
make it clear?
http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=2992f823

> Also where would new parent be inserted if new parent's parent was not null?
>  Or will it stay where it was?

I clarified in a comment:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=5771e7c0

Does it make sense now?

> I'm not sure why we'd need to add br's so aggressively in this algorithm

Basically every time I add a , it's because I found a case in
tests where there was some bug otherwise.  As far as I know, every
time a  is added, it's needed to stop two lines from running
together -- I avoid adding unnecessary s and in fact remove them
in a lot of places.  If you look closely at the conditions, these
's will only be added when you're wrapping in block elements.
Things like if you have

  foo[bar]

and the author runs "indent", it has to become

  foo[bar]

not

  foo[bar]

None of these should normally do anything if you're wrapping in
something like a .  Are there any specific cases that you think are
unnecessary?

> Can 6.3 be tied with "phrasing content" concept used in the rest of HTML5
> spec?

See the comment at the beginning of the "allowed child" algorithm,
beginning with "TODO: This list doesn't currently match HTML's
validity requirements for a few reasons:".  The biggest problem with
phrasing content is that it's only defined for valid elements, but we
need to also care about things like  for compatibility.

But as I say in the comments next to the definition for "name of an
element with inline contents", "TODO: The definitions of prohibited
paragraph children and elements with inline contents should

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

[Ryosuke Niwa]

On Wed, Jul 27, 2011 at 4:51 PM, Ryosuke Niwa  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. "  " 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
st

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

[Aryeh Gregor]

On Tue, Jul 26, 2011 at 5:26 PM, Aryeh Gregor  wrote:
> 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
>  or such in the near future.

Since the comments were relatively hard to spot, I've rewritten them
to be visible as you read the spec.  There are now tons of "Comments"
buttons floated to the right, which contain lots of rationale and
other commentary.  Some are pretty terse and are reminders to me as
much as anything, others are detailed explanations of the reasons
behind various decisions (some inordinately long, with the "toggle
lists" one being the most egregious).  I probably introduced some
editorial mistakes in the course of converting the comments, but they
should be extremely helpful for review.

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

[Hallvord R. M. Steen]

On Thu, 28 Jul 2011 01:51:31 +0200, Ryosuke Niwa  wrote:

The return value of queryCommandEnable depends on beforecut, beforecopy,  
and beforepaste events and selection state in WebKit;


This is actually a use case for before* events I wasn't aware of.  
Interesting. I guess you've taken this behaviour from IE? It seems a bit  
complicated though, in the sense that if the script knows some condition  
that means copy/cut/paste should not be available, listening for an event  
to cancel it is a bit of a convoluted way to make that logic available to  
other parts of the script. But then, I guess using same way to communicate  
state to the browser's UI and to other scripts is simplifying.


(I still haven't added anything about before* events to the CCnP spec,  
because I'm unsure if they are used and whether they are a nice way to  
solve the use case.)


--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

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

[Aryeh Gregor]

On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa  wrote:
> 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

Okay, I've now defined precisely how values have to be compared (in
two different ways), and painstakingly used them everywhere they're
necessary:

http://aryeh.name/tmp/editing/editing.html#equivalent-values

This should be well-defined now.

On Thu, Jul 28, 2011 at 4:31 PM, Ryosuke Niwa  wrote:
> WebKit fires those events :(  I don't know why we do that.  I think it's a
> WebKit bug but I'm just pointing that out in the case there are some
> websites out there that depends on this quirky behavior.  Just
> cut/copy/paste for now as far as I know.

How do the cut/copy/paste commands work at all in WebKit?  I tried
using them but they did nothing.  queryCommandSupported() returns
false for all three.  Is there some special switch?

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

[Ryosuke Niwa]

On Thu, Jul 28, 2011 at 1:17 PM, Aryeh Gregor wrote:
>
>  > 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.
>
> How does WebKit know if those events will be prevented or not, without
> running the handlers?  If the page runs queryCommandEnabled(), nothing
> actually happened, so surely WebKit doesn't fire any events?  Also,
> are you only talking about the cut/copy/paste commands, or other
> commands too?
>

WebKit fires those events :(  I don't know why we do that.  I think it's a
WebKit bug but I'm just pointing that out in the case there are some
websites out there that depends on this quirky behavior.  Just
cut/copy/paste for now as far as I know.

- Ryosuke

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

[Aryeh Gregor]

Thanks to both of you for the feedback!

On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa  wrote:
> 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.

Yes, bold is not a big problem.  If you look at "the bold command"
section, it explicitly defines the values "bold", "600", "700", "800",
or "900" as corresponding to "on", so it's simple string comparison.
The bigger problem is things like colors and sizes, where there are
lots of units that are related in complicated ways.

What I'd really like to do is have CSSOM define a reliable way of
uniquely serializing CSS values, and then say that two values are
equal if they serialize to the same thing.  But I guess for now I
should just make up my own definition.  For most things it's pretty
straightforward in principle, but it still needs to be specced.

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

Yeah, that's the obvious way to do it.  If I have to write the
definition for this, I guess I'll just say two CSS colors are equal if
their R/G/B/A channels are all equal.

> WebKit compares font sizes in legacy font size used in font element;
> See CSSStyleSelector::legacyFontSize or legacyFontSizeFromCSSValue in
> EditingStyle.cpp

I more or less reverse-engineered that to define
queryCommandValue("fontSize") -- translate the computed font-size to
pixels, then round to the nearest corresponding legacy font size.
Other browsers do different things that are less useful.  But there
are cases when I want to compare CSS values for equality more
precisely.  For instance, per spec, if you have

foo[bar]baz

and run execCommand("fontSize", false, "4"), it does nothing.  WebKit
seems to break up the span and add a new span or font element, but
this adds extra clutter.  However, if you have

foo[bar]baz

then the spec says to break up the span, because 18px != large, even
though queryCommandValue() says the same thing for both.

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

Yeah, this was a bad idea.  The only case where anyone throws
exceptions for bad values is Opera with formatBlock.  I've removed
this:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=ff9f4629

Don't know why I added it in the first place.

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

I guess.

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

I copied this from HTML5, and I think at least Opera has some commands
with this syntax, but you're right it doesn't make much sense.  I've
changed it: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=e9369d6c

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

How does WebKit know if those events will be prevented or not, without
running the handlers?  If the page runs queryCommandEnabled(), nothing
actually happened, so surely WebKit doesn't fire any events?  Also,
are you only talking about the cut/copy/paste commands, or other
commands too?

On Thu, Jul 28, 2011 at 7:06 AM, Michael A. Puls II
 wrote:
> At the end of section 4, there's:
>
>> the state of insertOrderedList and insertOrderedList might be true both
>> before and after calling
>
> Is one of those supposed to be insertUnorderedList?

Yeah, thanks.  Fixed:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=eb346d01

> At the beginning of section 5, there's:
>
>> An editing host is a node that is either an Element with a contenteditable
>> attribute set to the true state, or the Element child of a Document whose
>> designMode is enabled.
>
> What does "Element child" refer to specifically in the latter? Is it the
> HTML body element or is that implementation-specific?

It just means what the literal words imply: any Element that is the
child of a Document whose designMode is enabled.  The Nodes model

implies that any Document will always have either zero or one child
that's an Element.  If one exists, it will be returned by
document.documentElement.  For HTML documents, the Element child o

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

[Michael A. Puls II]

Thanks for working on this. Much appreciated!

A few things so far:

At the end of section 4, there's:

the state of insertOrderedList and insertOrderedList might be true both  
before and after calling


Is one of those supposed to be insertUnorderedList?

At the beginning of section 5, there's:

An editing host is a node that is either an Element with a  
contenteditable attribute set to the true state, or the Element child of  
a Document whose designMode is enabled.


What does "Element child" refer to specifically in the latter? Is it the  
HTML body element or is that implementation-specific?


Still in section 5:

A collapsed line break is a br that begins a line box which has nothing  
else in it, and therefore has zero height.


An extraneous line break is a br that has no visual effect, in that  
removing it from the DOM would not change layout, except that a br that  
is the sole child of an li is not extraneous.

Is this a good definition at all?


Don't really have much opinion on the names or the definition.

Which one refers to a  that acts like a placeholder for a line (so the  
line is selectable) where the  disappears once the user starts editing  
that line or closes the paragraph?


At the end of section 5:

When the user agent is instructed to run a particular method, it must  
follow the steps defined for that method in the appropriate  
specification, not act as though the method had actually been called  
from JavaScript. In particular, if the author has overridden the method  
with a custom method, the standard method must be run rather than the  
custom one.


Is this saying that doing something like:

HTMLDocument.prototype.execCommand = function(a, b, c) {
// stuff
};

, will have no effect or should throw an error or something?

If so, is this just matching what browsers do now or just something you  
think is a good thing to prevent?


In section 6.1 with:


To set the tag name of an Element element to new name:

1. If element is an HTML element with local name equal to new name,  
return element.


2. If element's parent is null, return element.

3. Let replacement element be the result of calling createElement(new  
name) on the ownerDocument of element.


4. Insert replacement element into element's parent immediately before  
element.


5. Copy all attributes of element to replacement element, in order.

6. While element has children, append the first child of element as the  
last child of replacement element, preserving ranges.


7. Remove element from its parent.

8. Return replacement element.


I pretty much translate that as:

var replacementElement = document.createElement("differentTagName");
parent.insertBefore(replacementElement, element);
for (var i = 0; i < element.attributes.length; ++i) {
replacementElement.setAttribute(element.attributes[i].name,  
element.attributes[i].value);

}
while (element.hasChildNodes()) {
replacementElement.appendChild(element.removeChild(element.lastChild));
}
parent.removeChild(element);

That seems to be removing attributes and nodes from one element and  
appending them to another while they're both being displayed in the parent.


Do you intend for that to be strictly done like that or is doing it a  
different way (like copying to the replacementElement in the DOM and then  
doing a replace) allowed as long as it gives the same end result? Or, will  
that mess up the range preservation?


--
Michael

Re: [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 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
> .  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:
> .  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
>  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.
>

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

[Aryeh Gregor]

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
.  It's about fifty pages
printed, and supersedes the Editing APIs section of HTML

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