Discussion:
Constructive criticism from a js-html-css developer.
Rene Veerman
2011-06-26 12:24:30 UTC
Permalink
Hi.

Lately i've been building animated web components. A button and a menu
component so far.
However, i've overcome several problems that apparently *all* the
browsers have.
I'd like to make a report here to the firefox development community,
and possibly link to this post from other browsers' forums.

The idea is to put video or an animation on a button or menu-item from
a png css-spritesheet, have 4 button/item-states (normal, hover,
selected and disabled) and some settings to control the fps and other
things per state in a JSON file.

A demo of the code that bypasses these problems is at http://mediabeez.ws/new_interface
(to be moved to /).

First problem;
Because I have several states like this, my item html structure looks
like this;
[div id="itemID"]
[table class="holdsTheTextOnTheButton"]
...
[/table]
[div id="itemID__img1"][/div]
[div id="itemID__img2"][/div]
[/div]
The 3 inner elements all have position:absolute of course, so they
overlap. The outer item div has position:relative.
On the __img's [div]s i put the backgroundImage and backgroundPosition
settings to my png sprite sheet.
I do an opacity animation between __img1 and __img2 when moving from
one state to another (onmouseover:state=hover,
onmouseout:state=normal), fast or slow, depending on the json theme
settings.
So forget about not using the 2 __img [div]s, you shouldn't twiddle
with the opacity of the buttontext table.

Now the problem with the menu component, not just in firefox but also
in other non-IE browsers, is the capturing of the onmouseover and
onmouseout events.
First instinct is to put the handlers as html attributes on the outer
div of the entire item.
But if you do that, you get ghost events, for a needed onmouseout you
get an extra onmouseover and then (if you're lucky) another
onmouseout. Vice versa for needed onmouseover events. This will mess
up the operation of the component.
And there's also the z-index to consider, because you want the
buttontext table to have a higher z-index than the __img's.
A few hours of experimentation revealed 1 way in which i could get
correct events;
You put the handlers, as HTML attributes, on the inner TD of the
buttontext table. __img1:z-index=100,__img2:z-index=101,table:z-
index=200

I think this is a very complicated way to get proper mouse events.
In my initial coding (that failed, with the event handler html
attributes on the outer item div) i had no event handlers at all on
the inner elements. I wish it would've worked then, outta the box.

Second problem is that I have to refetch some DOM links. In one of the
javascript inmemory objects that i use to keep track of things, i have
js-variable-to-DOM links like item.img1=document.getElementByID(itemID
+'__img1');
These somehow get either their direct .parentNode, or their
grandfather (.parentNode.parentNode) reset to null. I swear it's not
me doing it on purpose ;)
Animations on an DOM element link that's effectively detached from the
document's DOM, result in no animation at all.
I have to check during the animation loop if the .parentNode and
grandfater are still there, and re-fetch it with
document.getElementById() if it's not, or my animations (here's the
kicker!) (firefox:)won't work during the first 15 seconds after
loading a page. in other non-ie browsers the animation doesn't show at
all without re-fetching the DOM links.

Now, i've found work-arounds for both these problems, so i'm not
filing a bug-report on this personally.
But i do believe it to be bugs that almost all browsers replicate. I
tested opera 11.11 and the latest chrome.
I leave the rest up to the reader.
Boris Zbarsky
2011-06-26 14:51:33 UTC
Permalink
Post by Rene Veerman
But if you do that, you get ghost events, for a needed onmouseout you
get an extra onmouseover and then (if you're lucky) another
onmouseout.
These have different targets, no? So this should be fine as long as
your event listener checks what the event target is and acts accordingly.
Post by Rene Veerman
These somehow get either their direct .parentNode, or their
grandfather (.parentNode.parentNode) reset to null. I swear it's not
me doing it on purpose ;)
There are innerHTML sets all over your code. That would remove the old
nodes from the DOM, and create new nodes parsed from the string in its
place. Are you sure that's not what's happening here?

-Boris

Continue reading on narkive:
Search results for 'Constructive criticism from a js-html-css developer.' (Questions and Answers)
6
replies
Novice Web Developer in Need of Expert Advice!?
started 2014-05-29 07:57:05 UTC
programming & design
Loading...