There are some issues with that approach: background-image won't stretch
like an image, it doesn't send onload/error events, and IE requires the
use of an image to get clickable sprites to work properly - see the
fix_ie_clickable quirk...
P T Withington wrote:
So, I'm digging myself in deep to your hints about how see LPP-5435 and
LPP-8219 might be affecting this cursor problem. There's a huge amount
of mechanism there to try to work around <input> elements in front of
<img> elements. It would be really nice to be able to eliminate that if
possible. It would be a real simplification...
At the bottom of it all is the way we put a resource on a view. We
create a subsidiary <img> to the view and then set that <img>'s src and
background-image to the url of the resource. I think that the
difficulty in IE with text and clickable might be because the mouse
events are leaking through to that <img> and there is a default browser
action on <img> tags.
So I wonder, why do we need this subsidiary <img> element to give a
background to a view sprite, when we could instead just use the CSS
background-color and background-image attributes to put the background
directly on the view sprite div. A simple experiment shows that does
_not_ interfere with the <input> element, indicating we could possibly
do away with the quirks introduced for 5435 and 8219.
So, I need some background on why we have the subsidiary <img> element.
Was it just to parallel the swf structure (which I believe was to
actually work around a bug in swf5!), or is there some DHTML reason?
--
Regards,
Max Carlson
OpenLaszlo.org
