On 5/4/05, <b class="gmail_sendername">Ian Hickson</b> <<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As far as editing goes, contentEditable="" is the way we're going at the<br>moment, I think. Focusable is probably going to be tabindex="".<br>Selectable hasn't yet been discussed (I could be convinced that that is
<br>presentational, actually). Draggable is clearly not presentational; my<br>current thinking is something like contentDraggable="" or something.</blockquote><div><br>
I don't really see a case outside the datagrid dragging (which is
handled elsewhere) where there would be a need to specify an element as
draggable or as a drag target without scripting in drag behavior. In
light of this, I don't see any reason to pollute the HTML namespace
with more attributes (contentDraggable) when this will necessarily be a
scripted event anyway. Please feel free to point out cases where
another HTML attribute would have an advantage over a DOM property that
could be set directly via script.<br>
<br>
As for the dragging event model for a single DOM element, I think the
events outlined in the current draft of the spec are a good start. In
addition, however, it would be nice to add some presentational niceties
via CSS pseudo-classes.<br>
<br>
:draggable = DOM element that has .draggable=true (or whatever is decided on)<br>
:dragging = DOM element that is being dragged (perhaps opacity: 0.5)<br>
:dragging:droppable = DOM element that is being dragged and can be dropped over its current location<br>
:dragtarget / ? = container that allows for the current dragging element to be dropped upon it (border: 2px dotted red)<br>
:dragged = the original DOM element that was dragged, in its original
position (it would be up to script to determine whether or not to
remove it or whatever else)<br>
<br>
I think something along these lines is invaluable to a rich GUI interface.<br>
<br>
Drag groups could be specified by a simple NodeList that would be defined at dragstart.<br>
<br>
e.g.<br>
  var elDrag = document.getElementById("mydragelement");<br>
  var myNodeList = [];<br>
  myNodeList.push(document.getElementById("dragfriend1"));<br>
  myNodeList.push(document.getElementById("dragfriend2"));<br>
  // or just as easily: var myNodeList = document.getElementsByTagName("LI");<br>
  elDrag.addEventListener("dragstart", function(e) { e.dragNodes.appendChildren(myNodeList); return true; }, false);<br>
<br>
For the droppable model, it makes sense to have the drag target element specify either Elements or NodeLists that are droppable.<br>
<br>
e.g.<br>
  var elDragTarget = document.getElementById("mydragtarget");<br>
  elDragTarget.addDroppable(elDrag);<br>
  elDragTarget.addDroppable(myNodeList);<br>
<br>
Then the question comes about dragging a group of elements to a drag
target which only has *some* of the dragged elements in its droppable
list. Without thinking about it too much, I think this could be handled
when the elements are dropped as such:<br>
<br>
  elDrag.addEventListener("dragend", function(e) {<br>
    // go through each dropped element and check if it's droppable on the drag target<br>
    for (var i=0; i < e.dragNodes.length; i++)<br>
      if (
!dragTarget.isDroppable(e.dragNodes[i]) ) alert("Unabled to drag
"+e.dragNodes[i].id+" to "+dragTarget.id);<br>
    // of course something more graceful than an alert could be done<br>
<br>
    return true;<br>
  }, false);<br>
<br>
Anyway, most of it is food for thought.<br>
<br>
-- <br>

Brad Fults<br>

NeatBox </div><br></div>