Hah! Well after some googling, apparently it’s a problem with IE 7 not properly supporting the :hover attribute. Opinion is divided on whether a background will solve the problem.
IE 8 may not have this problem. And oddly enough, IE6 may not. Ah me.
IE has trouble with :hover on anything besides an A tag. Freeway generates an A tag – an empty # anchor one if necessary – for every option in a CSS Menu. So the issue is probably not related to the famous IE :hover-blindness.
First thing I would try is to remove all font styling from your menu. Open up the menu list with a double-click, select all, and press the [No Style] option in the Styles palette.
Then, test your menu – ugly though it will be – in your target browsers. I am thinking it will work.
To add the style back in, create a named style in the Style palette that contains all the font settings you want (color will be overridden by the link, so don’t bother with that). Click once on your menu container element and apply the named style to it. Then look in the CSS Menu interface in the Actions palette and add in the color and underline options for the links. As long as you have removed all of the style attributes from the text you should be done at this point.
Test again, and see if the styled version still works in your target browsers.
No, I haven’t been able to get back to this until tonight. So no testing has been done. Interesting that you saw the problem in IE8!
Ah, where would we be without Internet Explorer?
Dear Walter,
Of course I trust you implicitly, and so will implement as you suggest. But to my ignorant self, that seems a pretty bizarre solution!
I did create a named Style for the menu text, according to the instructions for the Caxton Action. I then applied the Style to the text itself.
Just out of rabid curiosity, what will applying the @fontface Style to the container element, as opposed to the actual contained text, accomplish? Or in other words, what’s the big diff?
The CSS Menu Action writes a lot of CSS that looks like this:
fwMenu * * * * * * someOtherSelector
where the number of stars is a critical thing. Those are serving as “counters” for the degree of nesting of a particular element. If you style a run of text inside your menu list, you can end up with this sort of structure (as you have):
ul
li
span (caxton marker name)
Text Value
/span
/li
li
span (caxton marker name)
Text Value
/span
/li
li
span (caxton marker name)
Text Value
/span
/li
/ul
which puts your text value at a different distance from the top of the tree than it would be if you had left the text inside your menu completely alone.
I am not certain that this is significant at all, but it would be one of the first things I would try. I am almost certain that Paul would have tested the use of Caxton inside the menu, but I think that might be related as well.
If all of the text inside your menu uses the same font, then it shouldn’t make any difference in how it works with Caxton if you use the class “marker” style on the container or the actual text. I suspect it might actually be faster that way, since your browser wouldn’t be switching context as often, generating a separate @font-face context for each line of text, versus one for the container object holding the menu.
Something odd is happening to the CSS. When you select no background color or image the Action should fall back to using a transparent GIF specifically to stop this problem. Could you try selecting a color for Background Normal (Color), and, if you aren’t using an image, uncheck the Image option too. Publish, check this works in IE and then remove the color again. If that still doesn’t work then send support(a)softpress.com your file and they will take a look at what’s happening there.
Thanks so much for jumping in. Looks like both Walt and Dave were right, eh? So I’m not crazy! Although I’m probably doing something else in my files to ball up the CSS definitions. Wouldn’t be the first time!
I’m working away from my home office today, and will post a few test versions tonight, with your kind indulgence. URLs to come! Thanks again. SoftPress is the best!
Hmmmm. I’ve just had a thought. I’ve been constructing these pages all wrong. Would it help if instead of a placed JPEG, and menu DIV, and a lower Contents DIV with a background, I made one Content DIV, with one background, and put the menu DIV and the various contents DIVs inside it?
A total box model page? Just a thought. That way, my one single background would grow as text sizes increased, and all would float above it.
I tried your file and it works first time for me. On closer inspection it looks like the Action is having a hard time finding the transparent image it uses to fix the problem you’re getting. This could be due to a number of reasons so I think the best solution, since you are on Freeway 5.4.2, would be to upgrade to Freeway 5.4.3 (or Freeway 5.5) to see if that fixes the problem.
Let me know,
Joe
On 18 Nov 2010, at 13:07, Bucky Edgett wrote:
Hmmmm. I’ve just had a thought. I’ve been constructing these pages all wrong. Would it help if instead of a placed JPEG, and menu DIV, and a lower Contents DIV with a background, I made one Content DIV, with one background, and put the menu DIV and the various contents DIVs inside it?
A total box model page? Just a thought. That way, my one single background would grow as text sizes increased, and all would float above it.
I assume that by “the Action is having a hard time finding the transparent image” you mean the HTML { text-decoration:none; background:url(‘’) repeat; } should read something like { text-decoration:none; background:url(‘http://luckypro.biz/client/mcg/craft/Resources/transparent.gif’) repeat; }
Of course I realize the Action could not know the correct URL, and should probably slap in a relative one. However…
I’m going to try TextWranglering the HTML files by hand, and testing them. Why the action should be so finicky is beyond me! Perhaps some day we’ll get this working within Freeway! That’d be great.
Yes indeed. Delta Dave was right, at least as far as a background goes. Using the transparent GIF worked. I edited all the HTML files with TextWrangler as described above and my submenus work as expected in IE.
Are there any further thoughts about why the CSS Menu Action is broken in my FW file?
As I have “Click to Flash” enabled, in order that no Flash elements on a Web Page load unless I, errmmm, click to Flash, I am possibly more aware of how many simple text elements of a Web Page are now embedded via Flash. I have no particular desire to include such elements, but I was wondering, leaving aside Apple’s disinterest in enabling Flash on the iPad etc, what so many Web designers see as the benefit from embedding relatively simple text elements via Flash, rather than simple Graphic text?
I’ve noticed exactly the same thing myself Neil. On some pages even
static headers (or maybe simple rollovers) are Flash based, surely not
good for the non-Flashers out there.
Trev
On 30 Nov 2010, at 08:41, Neil Carter wrote:
As I have “Click to Flash” enabled, in order that no Flash elements
on a Web Page load unless I, errmmm, click to Flash, I am possibly
more aware of how many simple text elements of a Web Page are now
embedded via Flash. I have no particular desire to include such
elements, but I was wondering, leaving aside Apple’s disinterest in
enabling Flash on the iPad etc, what so many Web designers see as
the benefit from embedding relatively simple text elements via
Flash, rather than simple Graphic text?