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





Reply via email to