Re: [Clipboard] Processing model feedback (and other)

2012-02-20 Thread Glenn Maynard 
On Mon, Feb 20, 2012 at 2:30 AM, Hallvord R. M. Steen wrote:

> ..but what about the steps we need to do for "copy" and "cut" events *if*
> the canceled flag is set? It's actually a bit more complicated than "abort
> these steps", which is why I'm not sure how I should structure it if I try
> to follow your advice.
>

Yuck, I see the behavior now.  Here:

7. Create an event *ev* using the *ClipboardEvent* interface, with its *type
* attribute initialized to *e,* its *clipboardData* attribute initialized
to *data transfer,* and its *isTrusted* attribute initialized to true*.*
8. Dispatch *ev* at *event target*.
9. If *e* is:
*paste*:
If *ev*'s *canceled flag* is unset, and the cursor or selection is
in an editable context, insert the data from the clipboard and queue tasks
to fire any events that should fire due to the modification, see
interaction with other events for details
*cut *or *copy*:
If *ev*'s *canceled flag* is set,
...
Otherwise,
...

(This is a first pass; it could probably be reduced to two steps without
losing precision.  Anne, maybe we need a hook into "fire an event named"
that lets us give the resulting event a name, like "fire an event *ev* named
*paste* at *object*"?  I'm not sure if the word "named" makes that
confusing.  He could just keep saying "the event" and not give it a name,
but it seems like a good idea to name objects when referring to them from
other steps.)

-- 
Glenn Maynard

Re: [Clipboard] Processing model feedback (and other)

2012-02-20 Thread Hallvord R. M. Steen 

On Mon, 20 Feb 2012 00:09:56 +0100, Glenn Maynard  wrote:


You can use the wording I gave above (modified here slightly):

7. Fire an event using the *ClipboardEvent* interface, with its *type*
attribute
initialized to *e* and its *clipboardData* attribute initialized to *data
transfer*, at *event target*.  If the event's *canceled flag* is set then
abort these steps.


..but what about the steps we need to do for "copy" and "cut" events *if*  
the canceled flag is set? It's actually a bit more complicated than "abort  
these steps", which is why I'm not sure how I should structure it if I try  
to follow your advice.


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

Re: [Clipboard] Processing model feedback (and other)

2012-02-19 Thread Glenn Maynard 
On Sat, Feb 18, 2012 at 10:12 AM, Hallvord R. M. Steen
wrote:

> I've looked at rewriting it but I'm not sure how. Cancelling the default
> action has different outcomes for the different types of events. Some of
> the outcomes are also easier to understand if you think that the default
> action *is* no-op (rather than thinking "skip handling the default action").
>

You can use the wording I gave above (modified here slightly):

7. Fire an event using the *ClipboardEvent* interface, with its *type*
attribute
initialized to *e* and its *clipboardData* attribute initialized to *data
transfer*, at *event target*.  If the event's *canceled flag* is set then
abort these steps.
8. If *e* is:
*paste*:


The bits about "the focused node" and "the
>> context is editable" above should probably reference something specific
>> in HTML.
>>
>
> Quite possibly, but I'm not sure where to find it..


(I don't either.  I'll leave these to people more familiar with those
topics...)


On Sun, Feb 19, 2012 at 4:05 PM, Paul Libbrecht  wrote:

> > http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and it's
> called DOM4.
>
> That's a moving target, from reading the URL.


This is a well-understood topic: DOM2 is hazardously obsolete and new specs
reference DOM4 for definitions of things like DOM Events.  This isn't a
"hot debate"; it's a finished one.  If you'd like more explanation about
this please start another thread--please don't derail this one.

-- 
Glenn Maynard

Re: [Clipboard] Processing model feedback (and other)

2012-02-19 Thread Hallvord R. M. Steen 

Siterer Anne van Kesteren :


Except there's no such thing as default action really...


IMO this is well established terminology and easy to understand for  
 script authors because of the preventDefault() method name.. I've   
changed the text slightly though.


I don't really think the term is that clear personally and it's not in
DOM4 at the moment. The whole notion that an event would have a default
action is flawed. A particular action might have a default action
preceded by an event that if canceled, cancels the default action, but
I think it would be clearer to just say fire the event and if it was
canceled do not do this next step. Which is how DOM4 is modeled.


I think I see your point now from a technical point of view, but I  
think we're close to splitting hairs here. The term "default action"  
is simply a sort of language shortcut to say what happens when the  
event is not cancelled. It's well established (just like I'd argue  
"MIME type" is) and I see no real problems caused by its usage.


/Hallvord

Re: [Clipboard] Processing model feedback (and other)

2012-02-19 Thread Paul Libbrecht 

Le 19 févr. 2012 à 10:46, Anne van Kesteren a écrit :

> On Sat, 18 Feb 2012 16:45:07 +0100, Hallvord R. M. Steen  
> wrote:
 "Firing an event" surely should be specified elaborately elsewhere. I 
 added another reference to DOM2-Events (though "fire" probably is used 
 without being precisely spec'ed there..).
>>> 
>>> Yes, you need to reference DOM4. Otherwise EventInit and such are undefined 
>>> too.
>> 
>> Oops, haven't fixed this yet. What is the best (most stable) URL for DOM 
>> Core / DOM 4 / whatever it's called nowadays?
> 
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and it's called DOM4.

That's a moving target, from reading the URL.

> Why do you also reference DOM 2 Events? That's confusing and not needed.

Anne, please do not prevent this.

I think Hallvord is trying to keep away from the hot debates and referencing 
one stable and one moving target, and he tries to be somewhat compatible with 
both at least at time of issuing.

paul

Re: [Clipboard] Processing model feedback (and other)

2012-02-19 Thread Anne van Kesteren 
On Sat, 18 Feb 2012 16:45:07 +0100, Hallvord R. M. Steen  
 wrote:
"Firing an event" surely should be specified elaborately elsewhere. I  
added another reference to DOM2-Events (though "fire" probably is used  
without being precisely spec'ed there..).


Yes, you need to reference DOM4. Otherwise EventInit and such are  
undefined too.


Oops, haven't fixed this yet. What is the best (most stable) URL for DOM  
Core / DOM 4 / whatever it's called nowadays?


http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and it's called  
DOM4.


Why do you also reference DOM 2 Events? That's confusing and not needed.



Seems pretty readable and precise to me as-is.


Except there's no such thing as default action really...


IMO this is well established terminology and easy to understand for  
script authors because of the preventDefault() method name.. I've  
changed the text slightly though.


I don't really think the term is that clear personally and it's not in  
DOM4 at the moment. The whole notion that an event would have a default  
action is flawed. A particular action might have a default action preceded  
by an event that if canceled, cancels the default action, but I think it  
would be clearer to just say fire the event and if it was canceled do not  
do this next step. Which is how DOM4 is modeled.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [Clipboard] Processing model feedback (and other)

2012-02-18 Thread Hallvord R. M. Steen 

On Thu, 16 Feb 2012 17:05:23 +0100, Glenn Maynard  wrote:

* The "Process the default action" step should instead talk about  
whether
or not the  
http://dvcs.w3.org/hg/domcore/**raw-file/tip/Overview.html#**
canceled-flagof  
the event ended up being set and what to do when it is not.
It's not clear to me.  It makes it sound like you always perform the  
stuff

in step 8, since there's no conditional.  I have to guess what's actually
intended.


I've looked at rewriting it but I'm not sure how. Cancelling the default  
action has different outcomes for the different types of events. Some of  
the outcomes are also easier to understand if you think that the default  
action *is* no-op (rather than thinking "skip handling the default  
action").



There's an awkwardness to the steps in section 5.  Based on the style I'm
used to seeing in other modern Web specs, I'd write it along these lines
(note that HTML formatting is used below):


Thanks a lot, I've used your suggestion almost verbatim.


Step 4 has an "i.e."; if you feel something needs additional explanation,
it probably belongs in a note.


Fixed.


The bits about "the focused node" and "the
context is editable" above should probably reference something specific  
in HTML.


Quite possibly, but I'm not sure where to find it..


Step 5 switched from a procedural style to a descriptive style.


Fixed.


Section 6 says "The default action of a synthetic paste event".  There is
no "default action" for events fired by scripts (except for one or two
unfortunate backwards-compatibility hacks).


OK. I thought it would be a cool feature, but nevermind - I've reversed  
the statements and all related tests.


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

Re: [Clipboard] Processing model feedback (and other)

2012-02-18 Thread Hallvord R. M. Steen 
On Thu, 16 Feb 2012 14:35:50 +0100, Anne van Kesteren   
wrote:


The processing model is about how to deal with a "copy/paste/cut  
operation" it is not about firing an event (that is mainly part of it).


..it happens to be *the* part of the processing this spec is all about  
:)..?


I mean that the way it is defined currently does not make much sense.


Anne, I'm afraid such a comment doesn't help me at all. I can assure you  
that it made sense to me when I wrote it, and that I've read it dozens of  
time and still thought it made sense :-)


The user initiates a "copy operation". A "copy operation" is a long list  
of steps that will eventually fire a "copy" event as part of that "copy  
operation".


So you should not have "When the user initiates a paste operation, the  
implementation must fire a paste event." But instead you should have  
"When the user initiates a paste operation, run the /paste operation  
steps/." or some such.


That is much more useful, thanks. I've removed 'must' and such entirely  
from section 4 and turned it into an informative description of how things  
are meant to behave, so I think this is fixed in the process.


You can also invoke such actions from script via the execCommand()  
APIs apparently, but that does not appear to be described in detail.


It's mentioned in the #integration-with-other-scripts-and-events  
section (8). I'm not sure where else to mention it or what more detail  
is needed. execCommand() is presumably spec'ed in Aryeh's rich text  
editing work.


You need some kind of hook for that though.


Linked to HTML5's definition of execCommand() at the moment.

So first I think it would make sense to clearly distinguish between  
operations and events.


Can you give me an example of a specific change to the spec's outline  
or vocabulary that would help make this distinction?


I think what you want to do for maximum clarity is to define "paste  
operation steps" / "copy operation steps" / etc. and include all the  
details there. Including the dispatching of the event, handling of the  
canceled flag of the event object being set, etc.


I think the current specification is pretty close. Section 4 just needs  
to go and become part of 5.


I've instead removed the IDL for DataTransfer and friends and merged some  
text from there into the now informative section 4.


You will still need a section that defines when the operations are  
invoked.


If section 4 were to be removed, or generally?


Well section 4 does not really say the operation is invoked; it just  
talks about events somewhat confusingly (imo).


..and here I'm not quite sure if I have addressed this or not, because  
it's not entirely clear to me what I need to say. I may have to improve my  
skillz on reverse engineering Anne's mind, eh? ;-)



Apart from this I noticed a few other things:

* "the BODY element" should probably be defined as reference to what  
it is in HTML.


Done.

* If you reference externally used terms mention that somehow. E.g.  
DataTransfer's mode flag is actually called "drag data store mode".  
DataTransfer in HTML is defined in terms of "drag data store" so it  
would make sense to talk about the same thing here. (Maybe get it  
renamed from drag to something more neutral?)


Now also linked to HTML5.

* The "Fire the event" step should be more elaborated:  
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#firing-events


"Firing an event" surely should be specified elaborately elsewhere. I  
added another reference to DOM2-Events (though "fire" probably is used  
without being precisely spec'ed there..).


Yes, you need to reference DOM4. Otherwise EventInit and such are  
undefined too.


Oops, haven't fixed this yet. What is the best (most stable) URL for DOM  
Core / DOM 4 / whatever it's called nowadays?


* The "Process the default action" step should instead talk about  
whether or not the  
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#canceled-flag  
of the event ended up being set and what to do when it is not.


Seems pretty readable and precise to me as-is.


Except there's no such thing as default action really...


IMO this is well established terminology and easy to understand for script  
authors because of the preventDefault() method name.. I've changed the  
text slightly though.



* I think having section 7 is confusing. Cross-references would be  
better.


Fixed.

http://wiki.whatwg.org/wiki/Anolis has tips on how to use it. E.g. to  
reference HTML fetch you would use:


fetch


Most instances of relevant terms now crosslinked.

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

Re: [Clipboard] Processing model feedback (and other)

2012-02-16 Thread Glenn Maynard 
On Thu, Feb 9, 2012 at 7:20 AM, Hallvord R. M. Steen wrote:

> * The "Process the default action" step should instead talk about whether
>> or not the http://dvcs.w3.org/hg/domcore/**raw-file/tip/Overview.html#**
>> canceled-flagof
>>  the event ended up being set and what to do when it is not.
>>
>
> Seems pretty readable and precise to me as-is.


It's not clear to me.  It makes it sound like you always perform the stuff
in step 8, since there's no conditional.  I have to guess what's actually
intended.

There's an awkwardness to the steps in section 5.  Based on the style I'm
used to seeing in other modern Web specs, I'd write it along these lines
(note that HTML formatting is used below):

To *fire a clipboard event named e*,

1. Let *data transfer* be a DataTransfer object.
2. Let *clear was called *be true.
3. Let *types to clear* be an empty unordered set.
4. Let *sequence number* be the sequence number of the clipboard content,
or null if not supported.
5. If the context is editable, let *event target* be the element that
contains the start of the selection in document order, or the BODY element
if there is no selection or cursor.  If the context is not editable, let *event
target* be the focused node, or BODY if no node has focus.
6. If *e* is:
*paste*:

*copy* or *cut*:
...
7. Dispatch an event using the *ClipboardEvent* interface, with its
*type* attribute
initialized to *e*, its *isTrusted* attribute initialized to true, and its *
clipboardData* attribute initialized to *data transfer*, at *event target*.
8. If the event's *canceled flag* is not set, then if *e* is:
*paste*:


Then, elsewhere, say eg. "*fire a clipboard event named paste*".

Step 4 has an "i.e."; if you feel something needs additional explanation,
it probably belongs in a note.  The bits about "the focused node" and "the
context is editable" above should probably reference something specific in
HTML.

Step 5 switched from a procedural style to a descriptive style.  (That is,
instead of saying "do this, then do this", it started to say "this must be
like this, and this must be like this".)  When describing an algorithm, it
helps to stay procedural the whole way through.

Section 6 says "The default action of a synthetic paste event".  There is
no "default action" for events fired by scripts (except for one or two
unfortunate backwards-compatibility hacks).  The default action of an event
fired by script is whatever the JavaScript programmer does if
dispatchEvent() returns false; dispatching an event has no side-effects
except firing event listeners.  Please see
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-eventtarget-dispatchevent
for
the modern definition of dispatchEvent.

-- 
Glenn Maynard

Re: [Clipboard] Processing model feedback (and other)

2012-02-16 Thread Anne van Kesteren 
On Thu, 09 Feb 2012 14:20:57 +0100, Hallvord R. M. Steen  
 wrote:
Anne van Kesteren  skreiv Fri, 09 Sep 2011 16:48:36  
+0200
As a high-level comment it seems to me the organization of the  
specification needs some changing. The processing model is about how to  
deal with a "copy/paste/cut operation" it is not about firing an event  
(that is mainly part of it). The events section meanwhile is about how  
users invoke a "copy/paste/cut operation" and not so much about firing  
an event either (the event summary boxes are not needed I think).


I agree that the event summary tables aren't really required, and have  
removed them. I'm not quite sure what else I should do specifically to  
address the comment that the "organization of the specification needs  
some changing". For example regarding


The processing model is about how to deal with a "copy/paste/cut  
operation" it is not about firing an event (that is mainly part of it).


..it happens to be *the* part of the processing this spec is all about  
:)..?


I mean that the way it is defined currently does not make much sense. The  
user initiates a "copy operation". A "copy operation" is a long list of  
steps that will eventually fire a "copy" event as part of that "copy  
operation".


So you should not have "When the user initiates a paste operation, the  
implementation must fire a paste event." But instead you should have "When  
the user initiates a paste operation, run the /paste operation steps/." or  
some such.



You can also invoke such actions from script via the execCommand() APIs  
apparently, but that does not appear to be described in detail.


It's mentioned in the #integration-with-other-scripts-and-events section  
(8). I'm not sure where else to mention it or what more detail is  
needed. execCommand() is presumably spec'ed in Aryeh's rich text editing  
work.


You need some kind of hook for that though.


So first I think it would make sense to clearly distinguish between  
operations and events.


Can you give me an example of a specific change to the spec's outline or  
vocabulary that would help make this distinction?


I think what you want to do for maximum clarity is to define "paste  
operation steps" / "copy operation steps" / etc. and include all the  
details there. Including the dispatching of the event, handling of the  
canceled flag of the event object being set, etc.


I think the current specification is pretty close. Section 4 just needs to  
go and become part of 5.



Because there is a processing model that includes dispatching events  
the section on events can probably be removed. The requirements made  
therein are redundant.


Indeed. The spec evolved this way, section 4 with normal prose  
description of how things are expected to work predates section 5 and  
the processing model that give more exact implementation details. So we  
could drop all of section 4 and just keep the processing model. However,  
I think keeping the short prose description for each event in section 4  
makes sense. It makes the spec more readable (and implementors are  
readers too) and makes it clear what behaviour the processing model  
intends to dictate.


Then you should clearly indicate section 4 is non-normative and not use  
words such as "must". Specifications should not have duplicate conformance  
requirements.



You will still need a section that defines when the operations are  
invoked.


If section 4 were to be removed, or generally?


Well section 4 does not really say the operation is invoked; it just talks  
about events somewhat confusingly (imo).




Apart from this I noticed a few other things:

* "the BODY element" should probably be defined as reference to what it  
is in HTML.


Added generic reference to HTML5 after both instances of "BODY element".  
Would it be better to refer to a specific section directly? I'd happily  
just link the text "the BODY element" directly to  
http://www.w3.org/TR/html5/sections.html#the-body-element but it seems  
like specs must be a bit more pedantic about things and list references  
at the bottom etc..?


Both are okay. What happens by the way if there is no body element? HTML  
also defines a specific term "the body element" (or some such) that means  
something different from the HTML body element.



* If you define an internal flag do not use  for it, but  or  
maybe .


Fixed. I think I've once read a spec or recommendation dealing with best  
markup for a spec, but I can't find it now. If you know what document  
I'm likely thinking about please send me a link :)


http://wiki.whatwg.org/wiki/How_to_write_a_spec has some advice.


* If you reference externally used terms mention that somehow. E.g.  
DataTransfer's mode flag is actually called "drag data store mode".  
DataTransfer in HTML is defined in terms of "drag data store" so it  
would make sense to talk about the same thing here. (Maybe get it  
renamed from drag to something more neutral?)


Chan

Re: [Clipboard] Processing model feedback (and other)

2012-02-09 Thread Hallvord R. M. Steen 

Anne van Kesteren  skreiv Fri, 09 Sep 2011 16:48:36 +0200

As a high-level comment it seems to me the organization of the  
specification needs some changing. The processing model is about how to  
deal with a "copy/paste/cut operation" it is not about firing an event  
(that is mainly part of it). The events section meanwhile is about how  
users invoke a "copy/paste/cut operation" and not so much about firing  
an event either (the event summary boxes are not needed I think).


I agree that the event summary tables aren't really required, and have  
removed them. I'm not quite sure what else I should do specifically to  
address the comment that the "organization of the specification needs some  
changing". For example regarding


The processing model is about how to deal with a "copy/paste/cut  
operation" it is not about firing an event (that is mainly part of it).


..it happens to be *the* part of the processing this spec is all about  
:)..?


You can also invoke such actions from script via the execCommand() APIs  
apparently, but that does not appear to be described in detail.


It's mentioned in the #integration-with-other-scripts-and-events section  
(8). I'm not sure where else to mention it or what more detail is needed.  
execCommand() is presumably spec'ed in Aryeh's rich text editing work.


So first I think it would make sense to clearly distinguish between  
operations and events.


Can you give me an example of a specific change to the spec's outline or  
vocabulary that would help make this distinction?


Because there is a processing model that includes dispatching events the  
section on events can probably be removed. The requirements made therein  
are redundant.


Indeed. The spec evolved this way, section 4 with normal prose description  
of how things are expected to work predates section 5 and the processing  
model that give more exact implementation details. So we could drop all of  
section 4 and just keep the processing model. However, I think keeping the  
short prose description for each event in section 4 makes sense. It makes  
the spec more readable (and implementors are readers too) and makes it  
clear what behaviour the processing model intends to dictate.


You will still need a section that defines when the operations are  
invoked.


If section 4 were to be removed, or generally?

Alternatively, you could leave that out of scope for the HTML Editing  
APIs specification.


For execCommand() I'll do that, I think.


Apart from this I noticed a few other things:

* "the BODY element" should probably be defined as reference to what it  
is in HTML.


Added generic reference to HTML5 after both instances of "BODY element".  
Would it be better to refer to a specific section directly? I'd happily  
just link the text "the BODY element" directly to  
http://www.w3.org/TR/html5/sections.html#the-body-element but it seems  
like specs must be a bit more pedantic about things and list references at  
the bottom etc..?


* If you define an internal flag do not use  for it, but  or  
maybe .


Fixed. I think I've once read a spec or recommendation dealing with best  
markup for a spec, but I can't find it now. If you know what document I'm  
likely thinking about please send me a link :)


* If you reference externally used terms mention that somehow. E.g.  
DataTransfer's mode flag is actually called "drag data store mode".  
DataTransfer in HTML is defined in terms of "drag data store" so it  
would make sense to talk about the same thing here. (Maybe get it  
renamed from drag to something more neutral?)


Changed instances of "mode" to "drag data store mode", "kind" to "drag  
data item kind" etc. Added a reference for the HTML5 DnD chapter, and some  
more referencing to this on first usage of DataTransfer. (IMO it becomes  
harder to read though - as long as we're dealing with properties of a  
precisely specified object it should be OK to refer to their property  
names like "item" and "type". "Mode" is a bit special in that it is AFAIK  
an internal flag and not visible to script authors.)


* "If the current clipboard part contains HTML- or XHTML-formatted text"  
seems really vague (how do you tell whether it contains that?) as are  
the steps that lead to creating some kind of tree. They probably need to  
reference something specific in HTML.


Slightly elaborated - better now?

* The "Fire the event" step should be more elaborated:  
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#firing-events


"Firing an event" surely should be specified elaborately elsewhere. I  
added another reference to DOM2-Events (though "fire" probably is used  
without being precisely spec'ed there..).


* The "Process the default action" step should instead talk about  
whether or not the  
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#canceled-flag  
of the event ended up being set and what to do when it is not.


Seems pretty readable and precise to me as-is.

[Clipboard] Processing model feedback (and other)

2011-09-09 Thread Anne van Kesteren 
As a high-level comment it seems to me the organization of the  
specification needs some changing. The processing model is about how to  
deal with a "copy/paste/cut operation" it is not about firing an event  
(that is mainly part of it). The events section meanwhile is about how  
users invoke a "copy/paste/cut operation" and not so much about firing an  
event either (the event summary boxes are not needed I think). You can  
also invoke such actions from script via the execCommand() APIs  
apparently, but that does not appear to be described in detail.


So first I think it would make sense to clearly distinguish between  
operations and events.


Because there is a processing model that includes dispatching events the  
section on events can probably be removed. The requirements made therein  
are redundant. You will still need a section that defines when the  
operations are invoked. Alternatively, you could leave that out of scope  
for the HTML Editing APIs specification.



Apart from this I noticed a few other things:

* "the BODY element" should probably be defined as reference to what it is  
in HTML.


* If you define an internal flag do not use  for it, but  or  
maybe .


* If you reference externally used terms mention that somehow. E.g.  
DataTransfer's mode flag is actually called "drag data store mode".  
DataTransfer in HTML is defined in terms of "drag data store" so it would  
make sense to talk about the same thing here. (Maybe get it renamed from  
drag to something more neutral?)


* "If the current clipboard part contains HTML- or XHTML-formatted text"  
seems really vague (how do you tell whether it contains that?) as are the  
steps that lead to creating some kind of tree. They probably need to  
reference something specific in HTML.


* The "Fire the event" step should be more elaborated:  
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#firing-events


* The "Process the default action" step should instead talk about whether  
or not the  
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#canceled-flag of  
the event ended up being set and what to do when it is not.


* Since ClipboardEvent is new we do not need to introduce  
initClipboardEvent() and go solely for an event constructor.


* I think having section 7 is confusing. Cross-references would be better.


If you want to perform cross-references between HTML, DOM, and your  
specification it might be an idea to use  
https://bitbucket.org/ms2ger/anolis I can help out if needed.



--
Anne van Kesteren
http://annevankesteren.nl/