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?
- [Laszlo-dev] Need input on LPP-8441 P T Withington
-