On Thu, 16 Feb 2012 14:35:50 +0100, Anne van Kesteren <[email protected]>
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:
<span data-anolis-spec=html>fetch</span>
Most instances of relevant terms now crosslinked.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
