Re: [whatwg] Drag and drop in HTML5
On 5/6/05, Brad Fults [EMAIL PROTECTED] wrote: :draggable = DOM element that has .draggable=true (or whatever is decided on) :dragging = DOM element that is being dragged (perhaps opacity: 0.5) :dragging:droppable = DOM element that is being dragged and can be dropped over its current location :dragtarget / ? = container that allows for the current dragging element to be dropped upon it (border: 2px dotted red) :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) After thinking about it more, it seems that this list is incomplete. :dragtarget:droppable = the currently dragging element can be dropped over this element. (border: 2px dotted green) And instead, make :dragtarget generic for all drag targets for the currently dragging element. :dragtarget = a valid drag target for the currently dragging element--the dragging element is in this drag target's droppable list. (border: 2px solid blue)-- Brad FultsNeatBox
Re: [whatwg] Drag and drop in HTML5
On Wed, 4 May 2005, Dave Hyatt wrote: WinIE supports setting tabindex to -1 to make an element focusable via .focus(). Yeah, that's already in the WHATWG draft actually (or something close to it, it's only a first draft right now). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag and drop in HTML5
On Wed, 04 May 2005 23:51:17 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
So there is currently no whole-element drag-and-drop API that we can
conveniently re-use. There are use cases though:
As a web developer I'd like:
- enabling/disabling dragging for each DOM element:
foo.draggable = true;
- event that asks if item can be dropped here. Dragged item should
fire events on elements it hovers (like onmouseover) and response to this
event (preventDefault?) should control if mouse pointer looks 'forbidden'
or 'normal' accordingly.
foo.addEventListener('dragtarget',function(e) {if (this.isBusy)
e.preventDefault();},false);
If it can't be an event (above example doesn't look bulletproof to me),
less convenient method like specifying if element is allowed target may be
sufficient (foo.dragTarget = true)
- 'item dropped' event fired on target element
- :drag CSS pseudo-class is nice idea. There might be also :drag-target
(:drag:target?) pseudo-class that styles elements that agreed to be drag
target.
:drag {opacity: 0.5;}
:drag-target {outline: 2px dotted red;}
There is use-case of reordering items, which means dragging items in
between other items. That seems a bit more complex, and probably needs
additional helper API.
To implement this with simple interface I've proposed, events should be
handled either by existing elements (like list items that compare their
size and position of dragged element to decide whether element should be
dropped before or after) or handled by container that would probably need
to calculate positions of it's children and create new element to show
drop target. Smooth Mac-like drag'n'drop can be implemented by animating
drop target's padding/margin. So that's quite a bit of code that's going
to be reinvented each time someone implements reordering.
--
pozdrawiam, Kornel Lesinski
Re: [whatwg] Drag and drop in HTML5
On 4 May 2005 at 22:51, Ian Hickson wrote:
- Dragging items to classify them. I could see you dragging items from
a list of items in a shopping mall interface to a virtual shopping
cart, or dragging them out from there to a wishlist. Another example of
this is dragging cards (between piles) in a card game.
Or dragging E-mails to folders in a webmail service..
One of the issues here is that there ought to be a way to drag a
collection of elements that aren't necessarily siblings in the DOM.
Perhaps a way to specify a drag-group to say that certain elements
considered draggable should be dragged together.
foo onclick=
if( ! this.draggable ){
this.draggable = true;
dragGroup = mailBucket;
}else
this.draggable = false;
A DragGroup object would be a sort of nodelist.. Perhaps something
like myDragGroup.add(this); would be more logical? Or perhaps just
assign a specific ID string..?
--
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/
Re: [whatwg] Drag and drop in HTML5
On 5 May 2005 at 17:41, Hallvord Reiar Michaelsen Steen wrote: dragGroup = mailBucket; (Meant this.dragGroup = mailBucket;. Sorry.) -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
Re: [whatwg] Drag and drop in HTML5
Ian Hickson wrote: Selectable hasn't yet been discussed (I could be convinced that that is presentational, actually). I don't think it is. Consider selecting options in a select-control. This is clearly semantic information. How selection is performed (mouse click, tab to element and press space, shouting the label on the element) is media dependent. regards Olav Junker Kjær
Re: [whatwg] Drag and drop in HTML5
On Thu, 5 May 2005, Hallvord Reiar Michaelsen Steen wrote:
One of the issues here is that there ought to be a way to drag a
collection of elements that aren't necessarily siblings in the DOM.
Perhaps a way to specify a drag-group to say that certain elements
considered draggable should be dragged together.
foo onclick=
if( ! this.draggable ){
this.draggable = true;
dragGroup = mailBucket;
}else
this.draggable = false;
A DragGroup object would be a sort of nodelist.. Perhaps something
like myDragGroup.add(this); would be more logical? Or perhaps just
assign a specific ID string..?
Do you mean that instead of labelling each draggable element as draggable,
you would instead add each draggable element to a list?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag and drop in HTML5
On Thu, 5 May 2005, Hallvord Reiar Michaelsen Steen wrote:
[...]
So to summarise, you want a way to make a drag operation initiated on one
element cause a number of elements to simultaneously be dragged.
I see the use for that. As far as the mail case goes, I would imagine that
would be done via a datagrid which would support dragging natively, so
that would be a different problem. But I could see it being possible for
groups of DOM nodes as well.
My proposal for doing that would be to have a way in ondragstart to say
...and by the way, also drag all these elements at the same time.
As in:
function dragStartHandler(e) {
e.dataTransfer.addElement(e.target.nextSibling.nextSibling);
}
...or something.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Drag and drop in HTML5
I am currently working on trying to specify IE's (and now Safari's) drag and drop API. In IE, drag and drop is basically only supported for WYSIWYG editing use cases: you can drag selections, images, and URLs. That's fine. Those are a major use case which we need to support, and the API is designed in a way that makes it easy to specify independent of media or platform (the names may be media-specific, but, like the click event, that's just to make developing for the platform easy, it's not actually stopping those events from being used for slightly different purposes in other media). In Safari, you can also drag entire blocks. This is done by using a CSS property, -khtml-user-drag I believe, which can take values that disallow dragging, enable selection and image dragging, and enable whole-element dragging. Now for Safari's use case this makes sense. Their target was platform-dependent, media-specific widgets, with accessibility needs addressed explicitly in the widget's code. However, from an HTML point of view, it doesn't make sense. Having a style property control application behaviour is wrong -- the fact that something is draggable isn't going to change depending on what the skin is. It's not even going to change based on the media -- something that's draggable (via a mouse) on a visual UA is still going to be draggable when the user is using an interactive aural agent (albeit with a radically different interaction model probably involving explicitly picking two elements and saying that the first is to be dragged to the second). So there is currently no whole-element drag-and-drop API that we can conveniently re-use. There are use cases though: - Dragging items around in a visual representation. You drag little ships in a game showing a visual representation of the game board (for example, I really want to drag the fleet icons in VoidWars www.voidwars.com). I could see you dragging icons around the map in Google Maps. -- here it seems like we may want a specific element that represents a thing. There's more to this case than just dragging and dropping -- there is a media-dependent aspect as well. You're dropping to a specific coordinate. Non-visual media are SOL if this is the only way to interact with the application. - Dragging items to classify them. I could see you dragging items from a list of items in a shopping mall interface to a virtual shopping cart, or dragging them out from there to a wishlist. Another example of this is dragging cards (between piles) in a card game. -- here it seems that we have a structure where one element contains a set of other elements all of which are draggable, and all of which can be dragged to specific other elements. Would it be enough to just mark elements as drag-item-sources and drag-targets and say that all the elements in d-i-sources can be dragged to d-targets? - Dragging items around a list view or between list views. -- here it seems like datagrid should just natively support drag and drop, so we don't need much more here. What other use cases are there? Are there any requirements I'm missing? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag and drop in HTML5
Safari also supports a :-khtml-dragging pseudo-class (like :hover or :active) that is used to render the element while it is being dragged. This allows you to do dynamic drag effects solely using CSS, is purely presentational, and so IMO does belong in CSS. I personally think controlling focusability, dragging, selection and editing from CSS is a done deal. Safari and Dashboard already support user-drag, user-select and user-modify. Mozilla supports user-focus and user-select. We plan to add user-focus support to Safari. dave On May 4, 2005, at 4:12 PM, Dean Edwards wrote: Ian Hickson wrote: I am currently working on trying to specify IE's (and now Safari's) drag and drop API. However, from an HTML point of view, it doesn't make sense. Having a style property control application behaviour is wrong -- the fact that something is draggable isn't going to change depending on what the skin is. It's not even going to change based on the media -- something that's draggable (via a mouse) on a visual UA is still going to be draggable when the user is using an interactive aural agent (albeit with a radically different interaction model probably involving explicitly picking two elements and saying that the first is to be dragged to the second). So there is currently no whole-element drag-and-drop API that we can conveniently re-use. Controlling behavior through CSS is OK if the what you are changing is CSS. It seems there two kinds of drag/drop. One kind affects the DOM, e.g. changing the order of items in a list. The other kind affects CSS, e.g. dragging a window on screen. For a draggable window only the CSS left and top positions would be a affected. It would be difficult to specify this without CSS! Ideally, i'd like to do both. Use CSS to declare a draggable element and use HTML to declare a list that can be re-ordered. -dean
Re: [whatwg] Drag and drop in HTML5
On Wed, 4 May 2005, David Hyatt wrote: Safari also supports a :-khtml-dragging pseudo-class (like :hover or :active) that is used to render the element while it is being dragged. This allows you to do dynamic drag effects solely using CSS, is purely presentational, and so IMO does belong in CSS. Yeah, that belongs in CSS. I personally think controlling focusability, dragging, selection and editing from CSS is a done deal. Safari and Dashboard already support user-drag, user-select and user-modify. Mozilla supports user-focus and user-select. We plan to add user-focus support to Safari. Whether an element (other than something purely presentational like a window) is draggable, whether an element is selectable, and whether an element is modifiable or editable are quite clearly not presentational aspects. They don't belong in the presentational layer, especially since that layer can be turned off. IMHO. As far as editing goes, contentEditable= is the way we're going at the moment, I think. Focusable is probably going to be tabindex=. Selectable hasn't yet been discussed (I could be convinced that that is presentational, actually). Draggable is clearly not presentational; my current thinking is something like contentDraggable= or something. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag and drop in HTML5
WinIE supports setting tabindex to -1 to make an element focusable via .focus(). dave On May 4, 2005, at 5:19 PM, Ian Hickson wrote: On Wed, 4 May 2005, David Hyatt wrote: Safari also supports a :-khtml-dragging pseudo-class (like :hover or :active) that is used to render the element while it is being dragged. This allows you to do dynamic drag effects solely using CSS, is purely presentational, and so IMO does belong in CSS. Yeah, that belongs in CSS. I personally think controlling focusability, dragging, selection and editing from CSS is a done deal. Safari and Dashboard already support user-drag, user-select and user-modify. Mozilla supports user- focus and user-select. We plan to add user-focus support to Safari. Whether an element (other than something purely presentational like a window) is draggable, whether an element is selectable, and whether an element is modifiable or editable are quite clearly not presentational aspects. They don't belong in the presentational layer, especially since that layer can be turned off. IMHO. As far as editing goes, contentEditable= is the way we're going at the moment, I think. Focusable is probably going to be tabindex=. Selectable hasn't yet been discussed (I could be convinced that that is presentational, actually). Draggable is clearly not presentational; my current thinking is something like contentDraggable= or something. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
