Re: [whatwg] Disabled attribute for iframes
On Fri, Aug 15, 2008 at 12:45 AM, Greg Houston [EMAIL PROTECTED] wrote: I would like to propose a disabled attribute for iframes. things like this inevitably are used for copy protection. and they aren't going to work quite the way you expect on mobile devices (we're probably going to have a couple of input method modes, not to mention things like select all...). Disabled would make the iframe read-only, i.e., you cannot highlight text, click on forms, or scroll the iframe content. someone might be able to use this to steal content from another site using well placed scrolled regions... ... you go on to talk about drag and drop or similar operations and it seems clear that you're not really asking for a disabled attribute. i'm merely replying to remind people that the original idea isn't something that should be considered. the actual problem you're really trying to solve otoh could be worth solving. but do keep in mind that some capture behaviors may cause pain for small devices too.
Re: [whatwg] Disabled attribute for iframes
On Fri, Aug 15, 2008 at 2:00 PM, Ojan Vafai [EMAIL PROTECTED] wrote:
On Thu, Aug 14, 2008 at 4:14 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 14 Aug 2008, Greg Houston wrote:
1. You have a fluid layout where the columns are resizable via
javascript by dragging the borders. The content of one of the columns is
an iframe. You begin dragging the border between it and the column to
the left, but as soon as the cursor goes over the iframe, the dragging
functionality stops because you have now entered the context of the
iframe. Thus it becomes impossible or at the very least very difficult
to resize the column containing it.
This seems like a bug. It seems like we would want to address this
directly rather than requiring authors to disable iframes when doing drags
(especially since that wouldn't help with things like plugins or
whatever). Wouldn't the better solution be to provide some sort of
mechanism to say that while the mouse button is down, all the mouse move
events should go to the element that got the mousedown event?
setCapture/releaseCapture is how IE supports this. Seems to work well
with iframes. It even deals with event coordinates in the expected way
(e.g. clientX, clientY are relative to the document that the captured
element is in instead of the document of the iframe).
Seems like a fine addition to HTML5.
Some sample code:
div onmousemove=document.getElementById('res').innerHTML+=event.clientX
+ '|' + event.clientY + ' ' onmousedown=this.setCapture()
onmouseup=document.releaseCapture()foo/div
iframe/iframe
div id=res/div
I tested Ojan's suggestion in IE7 with both iframes and Flash and it
works perfectly. I too believe setCapture and releaseCapture would be
excellent additions to HTML5.
- Greg
[whatwg] Disabled attribute for iframes
I would like to propose a disabled attribute for iframes. Disabled would make the iframe read-only, i.e., you cannot highlight text, click on forms, or scroll the iframe content. I don't know what the correct terminology is for the behavior that happens when you mouseover an iframe, but basically you shift context from the parent page to the iframe. This shift in context can cause problems in at least a couple situations with web applications. 1. You have a fluid layout where the columns are resizable via javascript by dragging the borders. The content of one of the columns is an iframe. You begin dragging the border between it and the column to the left, but as soon as the cursor goes over the iframe, the dragging functionality stops because you have now entered the context of the iframe. Thus it becomes impossible or at the very least very difficult to resize the column containing it. 2. This case is very similar. Say you have the same fluid layout as above with the middle column being an iframe. Above that you have a DHTML popup dialog window that can be resized and moved (both via drag). Trying to resize such a dialog window becomes very difficult since as soon as the cursor leaves the bounds of the dialog window and over the iframe everything stops. You just shifted context to the iframe. A workaround for the first issue is to hide the visibility of all iframes on the page when you start dragging, but it would be nicer if you could still see the iframes and just toggle their disabled attribute at the beginning and end of a drag. A workaround for the second issue is to create a transparent overlay (such as used with modals, but transparent) beneath the DHTML dialog window whenever it is being dragged or resized, and thus cover any iframes on the page. This solution doesn't work for the first issue however and it involves a lot extra markup, code, and tricky css to get the overlay to cover the entire viewable area of the page. Note this will probably be an issue with the new drag and drop functionality in HTML5. Say you have an element on the left side of the page. There is an iframe in the middle of the page. You try to drag the element to the right side of the page. Once you get over the iframe your dragging is most likely going to stop right in its tracks because you just left the parent document and entered the context of the iframe. The iframe could be 10px by 10px in size, but as soon as your cursor goes over it dragging stops. There may be smarter solutions for this, though perhaps more complex for the user agents. To drag something you must have your mouse button down. So if you pass over an iframe while a mouse button is down don't shift context to the iframe, not until the mouse button has been released. This would probably fix most drag and drop and resize issues with iframes. - Greg
Re: [whatwg] Disabled attribute for iframes
On Thu, 14 Aug 2008, Greg Houston wrote: 1. You have a fluid layout where the columns are resizable via javascript by dragging the borders. The content of one of the columns is an iframe. You begin dragging the border between it and the column to the left, but as soon as the cursor goes over the iframe, the dragging functionality stops because you have now entered the context of the iframe. Thus it becomes impossible or at the very least very difficult to resize the column containing it. This seems like a bug. It seems like we would want to address this directly rather than requiring authors to disable iframes when doing drags (especially since that wouldn't help with things like plugins or whatever). Wouldn't the better solution be to provide some sort of mechanism to say that while the mouse button is down, all the mouse move events should go to the element that got the mousedown event? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Disabled attribute for iframes
Ian Hickson: This seems like a bug. It seems like we would want to address this directly rather than requiring authors to disable iframes when doing drags (especially since that wouldn't help with things like plugins or whatever). Wouldn't the better solution be to provide some sort of mechanism to say that while the mouse button is down, all the mouse move events should go to the element that got the mousedown event? The old SVG 1.2 Full draft had a pair of methods (which are implemented in Batik), startMouseCapture()/ stopMouseCapture(), that could be used to do this kind of thing. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Disabled attribute for iframes
On Thu, Aug 14, 2008 at 6:14 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 14 Aug 2008, Greg Houston wrote: 1. You have a fluid layout where the columns are resizable via javascript by dragging the borders. The content of one of the columns is an iframe. You begin dragging the border between it and the column to the left, but as soon as the cursor goes over the iframe, the dragging functionality stops because you have now entered the context of the iframe. Thus it becomes impossible or at the very least very difficult to resize the column containing it. This seems like a bug. It seems like we would want to address this directly rather than requiring authors to disable iframes when doing drags (especially since that wouldn't help with things like plugins or whatever). Wouldn't the better solution be to provide some sort of mechanism to say that while the mouse button is down, all the mouse move events should go to the element that got the mousedown event? That would probably work, though I don't know if limiting it to the specific element itself might cause any issues. For instance, something lacking in the HTML5 drag and drop specification is the ability to define a handle for the element that is being dragged. With the drag and drop in javascript libraries you can define a handle (a different element) that drags the draggable element. If the handle property/attribute is null then the element itself is it's own handle. Perhaps there is a mousemove event in the current context (the parent document let's say) that is checking to see if the user tries to drag an object over it. We don't want to break the ability to create this sort of collision detection. It might be safer to say that while the mouse button is down, all the mouse move events should be processed in the same context the mousedown event occurred in. So if the mousedown occurs in the parent, mouse move events should be processed in the parent until a mouseup occurs. Likewise, if a mousedown occurs in the child iframe, mouse move events should be processed in the child iframe until a mouseup occurs. Yet there should also probably be some way to disable this or a way for one context to release mouse ownership to another context. I did a search for drag and drop between iframes, and there is at least one application out there that can fake this: http://intersoftpt.wordpress.com/2007/03/16/drag-and-drop-across-iframes/ Also, from a forum post on drag and drop between iframes: I have *heard* of people doing this by using the parent window to store and mediate state between the 2 child iframe windows. So when a drag was in progress, and the mouse coord reached the edge of the iframe window, you would notify the other iframe to start listening for mouseover events and create the illusion of a seamless drag. In these cases you would probably want a way to change context during mousedown, though the change should probably be controlled from the context the mousedown occurred in. That context gets to decide if it relinquishes control of the mouse move events before the mouseup or not. By default it should not. - Greg
Re: [whatwg] Disabled attribute for iframes
Greg Houston wrote: On Thu, Aug 14, 2008 at 6:14 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 14 Aug 2008, Greg Houston wrote: 1. You have a fluid layout where the columns are resizable via javascript by dragging the borders. The content of one of the columns is an iframe. You begin dragging the border between it and the column to the left, but as soon as the cursor goes over the iframe, the dragging functionality stops because you have now entered the context of the iframe. Thus it becomes impossible or at the very least very difficult to resize the column containing it. This seems like a bug. It seems like we would want to address this directly rather than requiring authors to disable iframes when doing drags (especially since that wouldn't help with things like plugins or whatever). Wouldn't the better solution be to provide some sort of mechanism to say that while the mouse button is down, all the mouse move events should go to the element that got the mousedown event? That would probably work, though I don't know if limiting it to the specific element itself might cause any issues. For instance, something lacking in the HTML5 drag and drop specification is the ability to define a handle for the element that is being dragged. I assume by 'handle' you mean a grabber element which is used to drag a larger element, much like a titlebar drags a window. If so, you would just make the 'handle' draggable=true. That you are dragging the other element is just conceptual for the user. The setDragImage for instance could be set to the other element to make a drag feedback image Perhaps there is a mousemove event in the current context (the parent document let's say) that is checking to see if the user tries to drag an object over it. We don't want to break the ability to create this sort of collision detection. It might be safer to say that while the mouse button is down, all the mouse move events should be processed in the same context the mousedown event occurred in. So if the mousedown occurs in the parent, mouse move events should be processed in the parent until a mouseup occurs. Likewise, if a mousedown occurs in the child iframe, mouse move events should be processed in the child iframe until a mouseup occurs. Is this related to the html5 drag and drop spec? It isn't clear from your earlier comment and this one. In the spec, mouse events don't fire at all during a drag. Implementations would fire dragover events in the parent or child frames as needed. Dragging columns widths probably wouldn't be done using the html5 dd, but instead would need a mouse capturing api as previously described.
Re: [whatwg] Disabled attribute for iframes
On Thu, Aug 14, 2008 at 7:50 PM, João Eiras [EMAIL PROTECTED] wrote:
Hi !
1. You have a fluid layout where the columns are resizable via
javascript by dragging the borders. The content of one of the columns
is an iframe. You begin dragging the border between it and the column
to the left, but as soon as the cursor goes over the iframe, the
dragging functionality stops because you have now entered the context
of the iframe. Thus it becomes impossible or at the very least very
difficult to resize the column containing it.
Well, if you need a workaround you can overlay an almost invisible element
over your iframe, like
function disableIframe(iframe){
if( iframe.__cover ){
var d = document.createElement('iframedisabler');
d.style.margin=0;
d.style.border=0;
d.style.position='absolute';
d.style.backgroundColor='white';
d.style.opacity = '0.01';
d.style.MozOpacity = '0.01';
d.style.WebkitOpacity = '0.01';
d.style.filter = 'alpha(opacity=1)';
iframe.__cover = d;
}
function get_xy(e){
var o = {x:0,y:0};
while( e ){
o.x += e.offsetLeft;
o.y += e.offsetTop;
e = e.offsetParent;
}
return o;
}
var xy = get_xy(iframe);
d.style.height=iframe.offsetHeight+'px';
d.style.width=iframe.offsetWidth+'px';
d.style.top=xy.y+'px';
d.style.left=xy.x+'px';
document.body.appendChild(d);
};
function enableIframe(iframe){
if( iframe.__cover ){
document.body.removeChild(iframe.__cover);
}
};
Yes, I had I mentioned that workaround in the original post. Ian had
mentioned that disabling an iframe might be a hassle for authors (
paraphrased by me) but compare the following with the current
workaround above:
myIframe.setAttribute(disabled, disabled);
On Thu, Aug 14, 2008 at 7:56 PM, Neil Deakin [EMAIL PROTECTED] wrote:
Is this related to the html5 drag and drop spec? It isn't clear from your
earlier comment and this one. In the spec, mouse events don't fire at all
during a drag. Implementations would fire dragover events in the parent or
child frames as needed.
Dragging columns widths probably wouldn't be done using the html5 dd, but
instead would need a mouse capturing api as previously described.
Neil, thanks for the clarification. So this may only apply to dragging
columns and resizing elements and not the HTML5 drag and drop.
- Greg
