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

On Thu, 16 Feb 2012 14:35:50 +0100, Anne van Kesteren <annevk@opera.com>  
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/

Received on Saturday, 18 February 2012 15:44:19 UTC