- From: Jim Ley <jim.ley@gmail.com>
- Date: Sat, 8 Jan 2005 16:41:08 +0000
On Sat, 8 Jan 2005 23:12:40 +1300, Matthew Thomas <mpt at myrealbox.com> wrote: > On 8 Jan, 2005, at 3:47 AM, Ian Hickson wrote: > > would need to implement all kinds of funky things in the rendering > > engine (e.g. how to handle a drag when the elements in question are in > > a 0.5 opacity block rotated 47 degrees > > Implementation complexity circa 2005: use a dragging-in-progress > cursor. Implementation circa 2000 in javascript in a popular user agent has no problem with the last.... I've written lots of drag and drop form widgets which use opacity under the cursor. I'd never done one with a 47 degree rotated box, but a quick hack here demonstrated that IE had little problems dragging such an element. http://jibbering.com/2005/1/drag-rotate.html The extension to dragging an element in a table or similar, is simply a matter of cloning the element at the start of the drag, having that absolutely positioned under the cursor, adding something to suggest where it's dropped then organising the dropping - It's trivial. I certainly don't see any problem with the implementation in an IE javascript implementation of web-forms 2.0, now I appreciate Ian is from Opera, and maybe Operas engine is significantly poorer than IE's at achieving this sort of thing, but we can certainly prove useful things like move can be done, rather than the really trivial to do in script move-up and move-down. > If not, why will it be any great catastrophe that the SVG plug-in > produced by Bill McCoy's colleagues at Adobe doesn't support Web Forms > 2 in its embedded HTML either? I also don't see any real problem with that, an SVG rendering engine will be pretty optimised at rendering such changes, more optimised than IE is, graphics compositing being its core functionality. I've never tried such a form widget in an SVG UA, but using IE's filters which achieve similar to SVG ones aren't a problem. Jim.
Received on Saturday, 8 January 2005 08:41:08 UTC