Drag and Drop - Using HTML 5
Scott Wilson
As some of you may remember, we had planned to use the Palette
extensions for D'n'D in Wookie. However, I've just had a play with
HTML 5 drag and drop, with some good results:
http://zope.cetis.ac.uk/members/scott/blogview?entry=20090623135357
So, the question is whether the special D'n'D API in palette adds
anything beyond this, other than the obvious fact that it works with
legacy browsers?
Should a widget D'n'D API basically 'shadow' HTML 5, and only
implement it to support older browsers? Or should we just encourage
adoption of HTML5?
S
Stephane
Drag'n Drop support at the browser's level is one of the coolest thing
that could happen to the Web ! And your second blog entry on that
topic shows that coupled with microformat this can be tremendously
useful (*)
In fact you are right, D'nD API in mywiwall (the Palette portal) was a
raw attempt to move away from the point'n click that prevailed on the
Web since the beginning towards much more Direct Manipulation user
interfaces ! In the future it is probable that D'nD usage on the Web
may go farther than D'nD in desktop applications today !
So now there are many reason to adopt this HTML 5 Dn'D drop API rather
than the one experimented in mywiwall:
1/ it is declarative and can be integrated directly with the markup,
for instance it allows to have drag target within widgets (which we do
not do at that time as we are limited to one widget frame as a drop
target)
2/ it works between different windows, so as you mentioned it is
possible to interat between services that spawn several domains
without the usual cross-domain security restrictions
3/ (I didn't check it) but I hope that browser's implementation will
integrate it with the desktop operating system drag and drop; that
would allow for instance to upload files from your desktop by dropping
them directly inside a widget (no more boring File selection dialog
box), including batch import of several files at the same time !
4/ You can also drop data on demand, for instance by providing only a
URL as the drag data which can be used to pull out the real data out
of a Web service after a drop occured
So you are right, I think that in mywiwall we should reengineer the
Dn'D module so that it mimics the HTML 5 Dn'D API for legacy browser
that do not have it (at least between widgets), and that it would just
let it work if available (**).
However I see some areas where we should still have some issues to
tackle:
1/ do we need to give a uniform feedback at the widget's level when it
contains a drop target compatible with the current drag data (I think
this is not part of HTML 5), and if so how to achieve this ?
2/ how to be sure that different developers of different widgets will
agree on the data format strings they use ? the HTML 5 API allows to
set any format with setData (although the W3C overview seems to
mention only "text/plain" and "text/uri-list" DOMString formats), so
maybe here a "higher level" widget API could help different widget
developers to have compatible widgets ? Currently in mywiwall we
suggested using a kind of URI string to identify an event type and
then to send drag data as a JSON object, this was an attempt in that
direction, is it possible to do the same thing with MIME-Types as it
seems to be the proposed solution with setData and getData in HTML 5
Dn'D ?
As you mention to use micro-formats Scott, is there a way to identify
a micro-format with a kind of unique ID that could be used as a data
format string (for instance I am not sure there is a MIME-Type defined
for each microformat data type ?), and then how to transfer it ? As a
JSON object (it seems that as per-the-spec each drag event also carry
data in a "application/microdata+json" format built with microdata
extracted from the source node) ?
3/ I have quickly been through the spec and at that point I do not
understand if it will be possible to define that a drop target only
accepts only some specific kind of drag data (for instance based on
the data format string), this may be a problem from a usability point
of view ? Maybe you can circumvent it by displaying your own feedback
programmatically by subscribing to dragenter and dragleave events,
and then providing your own feedback only if the drag data is
compatible with the current drop target, but then I suggest there is a
reason to "homogenize" that feedback at the Widget portal level and
hence to have a higher level API ?
In any case, I am looking forward to see a widespread use of Dn'D on
the Web :)
Stéphane S.
---
PS: As you mentioned, D'nD and micro-formats can be combined together
to transport chunks of structured data between Web apps. I also see a
great potential in using D'nD with services that can transform data,
in fact that would let users create ad'hoc workflows between services
(that was the idea of "chains of interactions" we were thinking about
in Palette when we started implementing this in mywiwall); for
instance imagine a photo meta-data editor widget: if I drop an image
on it, I can edit it's meta-data, then if I drag and drop the image
from it to a target repository (including my local disk), that would
transfer the image with the meta-data just edited saved in EXIF format
in it...
(*) http://zope.cetis.ac.uk/members/scott/blogview?entry=20090624222327
(**) I also draw your attention that in mywiwall there is also an
inter-widget messaging API which can be used for system-driven (not
triggered by the users) communication between widgets [see our WWW
2009 poster at http://www2009.eprints.org/138/]
Scott Wilson
The user agent must take the list of dragged nodes and extract the microdata from those nodes into a JSON form, and then must add the resulting string to the
dataTransfermember, associated with theapplication/microdata+jsonformat.The user agent must take the list of dragged nodes and extract the vCard data from those nodes, and then must add the resulting string to the
dataTransfermember, associated with thetext/directory;profile=vcardformat.The user agent must take the list of dragged nodes and extract the vEvent data from those nodes, and then must add the resulting string to the
dataTransfermember, associated with thetext/calendar;component=veventformat.For each node node that is sectioning content in the list of dragged nodes, the user agent must check if there are any
footerelements that apply to node and that contain any elements that are top-level microdata items with the typebibtex, and if so, then the user agent must concatenate the strings obtained from extracting BibTeX data from all such nodes, and then must add the resulting string to thedataTransfermember, associated with theapplication/microdata+bibtexformat
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Talk about Widgets" group.
To post to this group, send email to talk-abou...@googlegroups.com
To unsubscribe from this group, send email to talk-about-widg...@googlegroups.com
For more options, visit this group at http://groups.google.fr/group/talk-about-widgets?hl=en
-~----------~----~----~----~------~----~------~--~---
Stephane
On Jun 25, 2009, at 6:33 PM, Scott Wilson wrote:
> For (3) you can have a dragover event that can return feedback based
> on the content of the datatransfer - however as a security
> precaution this only works when source and target have the same
> origin. (Otherwise, if you have a drag that crosses an Evil Window,
> it can sniff the contents as they move across it, even if you didn't
> want to drop anything on it).
These are the reasons (the dragover trick to give feedback case by
case) I believe it could be interesting to keep a higher level drag
and drop API at a Widget container level so that the code to check
event compability between a source a potential target is factorized,
and maybe the feedback too. This way widgets authors would just have
to declare:
- drag source (declaratively as in HTML 5)
- drop target (declaratively as in HTML 5)
- type of drag data generated by a source (this is already the case
with the DOMString data format in HTML 5 ? although this is done at
runtime and not declaratively)
- accepted type of data on drop targets (I am not sure this is in HTML
5, and I am not sure what is the best way to do this)
the higher level Dn'D API would do all the compatibility checks /
feedbacks automatically (that would avoid to repeat again and again
the same code/stylesheets in every widget and increase the homogeneity
of the UI). In a short term we could also imagine that (depending on
the data type declaration mechanisms) the higher level API could also
use some impedance matching algorithms to automatically convert data
between sources / targets when possible.
But maybe I am wrong and it is already possible with the HTML 5 API to
declare a "phone number data source" and to have only "phone number
compatible" drop source highlighted when dragging other them ?
Stéphane
---
Scott Wilson
possible. I think the native Microdata processing in the editor's
draft version might provide some more answers?
However, perhaps at least some convenience methods for widget authors
for feedback could be good, as I do agree that it would be good if
widgets provided a consistent user experience for DnD.
For example, I wonder if the Widget could declare some "accepted drop
types" in the config.xml, and the container handle the onDrag event to
check types? That way the widget "frame" could respond to the user
rather than the widget content? (Just an idea..)