kaeli said:
(e-mail address removed) enlightened us with...
I was wondering whether it would occur to aa that when a mass of experts
repeatedly tell you that you are wrong it is probably time to re-examine
your opinions; apparently not.
His menu is looking pretty good,
Thanks. I haven't had much time to work in it recently so it isn't
finished yet. On the other hand I will have access to a couple of Macs
this weekend so I should have a chance to check that it is working (or
cleanly degrading) on Mac IE and Safari versions.
but it won't work cross-frames (that is, the menu appears
in one frame while the subs open in another), as it simply
changes existing LI items into menu items.
I didn't design the script to operate across frames, and there is no
truly general cross-browser solution to menus that operate across frames
because you would need to deduce the relative positions of all frames in
the browser's DOM in order to line the contents up properly between
frames. The information required for that is simply not available on
some browsers that would otherwise happily support the script as it is.
The cross-frame menu scripts that I have seen to date avoid that problem
by imposing restrictions on the form and layout of the frameset used.
Those restrictions are likely to impact heavily on the potential for
clean degradation.
In principle the menu defined by the HTML in one frame could be
re-produced in all others by transferring pertinent properties to
elements created in the other documents, but they would need to be
accurately aligned for the result to be acceptable.
I can't tell if you could include more
than one menu on a single page.
The script itself is fully encapsulated so there would be no problem in
having as many operating menu instances as available memory could
support, Though I can't see much need to have more than one.
Plus it's going to be hell to configure colors until he
implements CSS classes that use variables or something
(if that can even be done...I dunno).
I see the combination of ID selectors and inserted elements with
pre-defined classes as allowing considerable flexibility in how the
displayed menus are styled (and differently in their active and degraded
states).
Right now, you'd have to change the color in every
single selector.
That requirement only exists in some CSS contexts. Given a simpler
context there would be more potential to exploit inheritance in the CSS
used.
Easy with a edit/replace, I guess, but it might fudge up.
I can't tell if you can position the menu at a given spot.
One of the areas that I have been concentrating on in recent scripts is
achieving the same fluidity in DHTML as is available through HTML and
CSS. The menu will go exactly where you choose to put it (flowed or
positioned). And correct itself for re-flowing and/or font re-sizing.
Absolute positioning is an important thing
for many people, including myself.
That shouldn't be a problem, but some care would be needed in setting
CSS overflow on any positioned container.
I also can't tell what would happen if a form select
element was under one of those submenus. Form select
elements have screwed up DHTML since it was invented,
thanks to IE considering them a window object.
As it stands on IE select elements would be a problem, but I have a
generalised object for hiding select elements (actually any form
elements as <INPUT type="text/button/etc"> are equally problematic on
some older browsers (Opera 6, for example), and a variant of the element
position reporting object used by the script that provides an additional
collision detection method on its interface. It is just a matter of
swapping the position reporting object, including the form element
hiding object, registering the pop-up DIVs with it, and triggering the
testing whenever anything was moved, revealed or hidden, to handle
select elements and the like. (and Jim's screening IFRAME trick works
pretty well as an alternative (and potentially simpler approach), but
only on the newer dynamic browsers (Opera 6 cannot cope with it at all).
So far, I like it a lot for a menu all on one page, though,
and you don't have to include a ton of files from the look
of it. You could even put the menu HTML in an included file
if you had some sort of server-side include (ASP, SSI, JSP...),
making it easy as heck to modify with a text editor.
<snip>
One of the nice things about facilitating clean degradation by defining
the data for the script within the HTML is that server-side scripting
only has to deal with writing HTML (not javascript data structures (the
writing out of which is indirect, error prone and liable to introduce a
considerable debugging and maintenance burden)), and that is exactly
what most server-side technologies are best at (and something that the
authors of server pages should be expected to easily understand).
Richard.
