Fails on IE?!

[laredotornado]

Hi, Surprisingly, I can't get the drop down menus to work on PC IE 6.
If you roll over "PRODUCTS", normally a drop down menu appears (on
Safari and Firefox), but on PC IE, nada.

http://test2.boxxtech.com/corporate/test.asp

Any ideas?

Thanks, - Dave

[Els]

Alan J. Flavell wrote:

On Tue, 18 Jul 2006, Els wrote:

>Alan J. Flavell wrote:

...

>>it won't support :hover on anything else
than <a href=...>

No other kind of <a, notably <a name=...>, will impress it.

Now that you mention it, I think I read something like that recently.
Just didn't stick, since I don't see a use for hover on <a name...>
anyway.

Quite - but think about it the other way around.

Someone who's only familiar with the behaviour of IE might well
think it's a good idea to code a:hover in their CSS.

But, if they then code some <a name=...tags, they may well be
surprised at what happens on a real web browser. I recommend
coding a:link:hover instead.

Good idea, but...
People who will follow that advice, probably do so, because they
understood the explanation. Which diminishes the usefulness somewhat.

It may come in handy when styling a site that's editable by semi-savvy
people through a CMS though, and now that I think of semi-savvies,
it's probably also a good idea to use in tutorials.

[1] - like the habit of putting the navigation menu at top left,
distracting from the main content of the page. That's one point on
which my own pages don't compromise - the navigation links are at the
foot of the page (and in the <link rel=...markup, for the benefit of
those with Better Browsers). I honestly don't expect this to baffle
or confuse anyone who'd be interested in my pages. I've had a
considerable number of positive emails about pages of mine that aren't
about the WWW, and very few of them have made any complaint, and then
only quite minor, about the usability of the pages; the mails have
been overwhelmingly about the content - which is how it's supposed to
be IMHO.

You're saying you put the navigation at the bottom of the page, even
if that page is very long? I take it you have at least an in your face
link to the navigation at the top then?

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

[Alan J. Flavell]

On Fri, 21 Jul 2006, Els wrote:

You're saying you put the navigation at the bottom of the page, even
if that page is very long? I take it you have at least an in your face
link to the navigation at the top then?

No, I haven't. If the page is the one they want, I hope they'll read
it. If it isn't, then I expect them either to take the Back button
or use their search engine bookmark to find something better.

Recall, these are my hobby pages, they get far too many hits for
comfort already, considering they are hosted at my work. My only
interest is that visitors get the information that they are looking
for - whether from me or from some place that does it better -
I have no motivation to "keep them on my server come hell or high
water".

With this setup, I don't seem to be able to help getting high ratings
at the search engines. Whenever I look for topics of interest to me,
the poor thing *will* keep boring me by showing me my own pages on
that topic!

Anyway - surely all browsers have their own "jump to bottom of page"
facility? The ones that I use all seem to respond to the End key, and
some have several other ways of getting there without simply
scrolling. I can't find any enthusiasm for all these in-page
navigation tools that at best duplicate (but in different ways on
different sites) functions that are present in any browser and only
have to be learned once (per browser).

Having the navigation menu on the top is no way to convince them that
they've found the right page. That's the job of the content! And my
pages stand or fall by their content (admittedly, some of them are now
*very* long in the tooth).

And, as I say, the better browsers have support for <link rel="...">
which is available *wherever* they might be on the page.

But I've already conceded that this isn't how pages are commonly done:
anyone looking at my example is entirely welcome to reject it, in part
or in whole.

regards

[Els]

Alan J. Flavell wrote:

On Fri, 21 Jul 2006, Els wrote:

>You're saying you put the navigation at the bottom of the page, even
if that page is very long? I take it you have at least an in your face
link to the navigation at the top then?

No, I haven't. If the page is the one they want, I hope they'll read
it. If it isn't, then I expect them either to take the Back button
or use their search engine bookmark to find something better.

Recall, these are my hobby pages, they get far too many hits for
comfort already, considering they are hosted at my work. My only
interest is that visitors get the information that they are looking
for - whether from me or from some place that does it better -
I have no motivation to "keep them on my server come hell or high
water".

Oh no, that's not what I intend with a basic navigation at the top.
Just that I like to give the visitor the option to explore more
topics/pages if the page that they found isn't entirely what they were
looking for, while another page might be.

Very simple example with my own site: the majority of my visitors, is
coming from Google images, search query "lions". They then find one
page with one picture of lions. By providing navigation where they can
see it, I give them the option to see more pictures of lions. If they
don't like the first picture, they can hit the back button and Google
some more. If they do like it, they may want to see more of the same.
(Yes I know, example doesn't hold, cause I don't actually have more
pictures of lions on my site, but you get the idea)

With this setup, I don't seem to be able to help getting high ratings
at the search engines. Whenever I look for topics of interest to me,
the poor thing *will* keep boring me by showing me my own pages on
that topic!

Did you test if those high ratings actually go away if you have a
'jump to navigation' link?

Anyway - surely all browsers have their own "jump to bottom of page"
facility?

Sure - if one is expecting navigation at the bottom, one would
probably use those. But if I search in Google and find a page that
starts with content, I assume a navigation-less page - you know, one
of those dumb framed ones ;-)

Having the navigation menu on the top is no way to convince them that
they've found the right page. That's the job of the content! And my
pages stand or fall by their content (admittedly, some of them are now
*very* long in the tooth).

And, as I say, the better browsers have support for <link rel="...">
which is available *wherever* they might be on the page.

I have those better browsers, but since not many pages code for it, I
never bother to use that feature.

But I've already conceded that this isn't how pages are commonly done:
anyone looking at my example is entirely welcome to reject it, in part
or in whole.

Your page, your choice. Nothing to reject :-)

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

[Adrienne Boswell]

Gazing into my crystal ball I observed Els <el*********@ti scali.nlwriting
in news:br******** *************** ******@40tude.n et:

>>
And, as I say, the better browsers have support for <link rel="...">
which is available *wherever* they might be on the page.

I have those better browsers, but since not many pages code for it, I
never bother to use that feature.

I code for it. Opera has the option to show it when it's available (or all
the time), and Firefox has an extension that puts the information at the
bottom somewhere.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

[Els]

Adrienne Boswell wrote:

Gazing into my crystal ball I observed Els <el*********@ti scali.nlwriting
in news:br******** *************** ******@40tude.n et:

>>>
And, as I say, the better browsers have support for <link rel="...">
which is available *wherever* they might be on the page.

I have those better browsers, but since not many pages code for it, I
never bother to use that feature.

I code for it. Opera has the option to show it when it's available (or all
the time),

I know, but because not many sites use it, it doesn't become
automatic. I do most things on the keyboard, including clicking links.
Which is actually one of the reasons I prefer Firefox over Opera,
cause in Opera I can't just tab from link to link. (I know there are
shortcuts, but nothing is as easy as the tab button, which works in
all the other browsers).

and Firefox has an extension that puts the information at the
bottom somewhere.

Besides me not wanting to install "all" the extensions Firefox has to
offer, I don't get into using those shortcuts. If I'd be surfing 24/7
on a site that has those links enabled, I'd get used to them, and I
wouldn't have to think twice about it when I used them. It would
become automatic. But since it's not working on all sites (to say the
least), this automatism would actually hurt my surfing.
I already dislike the fact that opening a new tab in IE7 and Firefox
is CTRL-T, while in Opera it's CTRL-N. Too many times I've opened up
the bookmarks (?) window in Opera when I needed a new tab.
Vice versa, I don't like it that in Firefox or IE I can't type in
CTRL-H to go to the address bar.

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

[Alan J. Flavell]

On Fri, 21 Jul 2006, Els wrote:

Alan J. Flavell wrote:

And, as I say, the better browsers have support for <link rel="...">
which is available *wherever* they might be on the page.

I have those better browsers, but since not many pages code for it, I
never bother to use that feature.

I have a script which generates the navigational tools on each page,
using a list which I code (based on a template) for each page.

The script can generate those navigational tools in any way that I
please, so, once the basic scheme is in place, it's no extra effort to
also generate the <link rel=...links, and it does no harm to those
who can't use them.

I won't say that the script is ideal - I've been using it for many
years now, and if I started again today, I'd probably script it
differently; but the general idea is good, IMHO.

--

[Els]

Alan J. Flavell wrote:

On Fri, 21 Jul 2006, Els wrote:

>Alan J. Flavell wrote:

>>And, as I say, the better browsers have support for <link rel="...">
which is available *wherever* they might be on the page.

I have those better browsers, but since not many pages code for it, I
never bother to use that feature.

I have a script which generates the navigational tools on each page,
using a list which I code (based on a template) for each page.

The script can generate those navigational tools in any way that I
please, so, once the basic scheme is in place, it's no extra effort to
also generate the <link rel=...links, and it does no harm to those
who can't use them.

I won't say that the script is ideal - I've been using it for many
years now, and if I started again today, I'd probably script it
differently; but the general idea is good, IMHO.

Are you talking about a script you use to generate your own pages, or
one that inserts stuff into other people's pages while you're looking
at them in your browser?

I'm deducting the former, but that makes two people who code with
those links: you, and Adrienne. (and a couple more on the web).
It's just no use for me and probably others, since the majority
doesn't use them. Not enough sites have it, so I'm not easily getting
used to it. But if I would get used to it, I'd keep clicking shortcuts
that won't work on other sites, out of habit.

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

[Alan J. Flavell]

On Sat, 22 Jul 2006, Els wrote:

Alan J. Flavell wrote:

I have a script which generates the navigational tools on each
page, using a list which I code (based on a template) for each
page.

....

Are you talking about a script you use to generate your own pages,

yes.

or one that inserts stuff into other people's pages while you're
looking at them in your browser?

no.

I'm deducting the former, but that makes two people who code with
those links: you, and Adrienne. (and a couple more on the web).

www.w3.org
news.bbc.co.uk

to mention two pages that I've been reading in the past few minutes.

It's just no use for me and probably others, since the majority
doesn't use them.

As I said: it does them no harm - and somebody's got to make a start.

It's a pity that FF took them out (they were avaliable in Moz, even if
they were disabled by default and one had to go out of one's way to
enable them). But Opera attracts discerning users - maybe they'll be
the ones to give the critical mass. The idea has been simmering
forever, and Lynx has had support for it (which was what first
attracted me to it, many years ago - the ability to call up a
navigation toolbar with a single "#" keycommand).

If authors don't put them in, they can't be used! If authors *do* put
them in, as an optional extra, then at least they are available, and
they do no harm to anyone who can't or won't use them. That's why I
find the idea of scripting to be beneficial: I don't have to design
and code the links specially - once the script is in place, they are
generated from the same data as also generates the navigation bar on
the page.

regards

[Els]

Alan J. Flavell wrote:

On Sat, 22 Jul 2006, Els wrote:

>Alan J. Flavell wrote:

>>I have a script which generates the navigational tools on each
page, using a list which I code (based on a template) for each
page.

...

>I'm deducting the former, but that makes two people who code with
those links: you, and Adrienne. (and a couple more on the web).

www.w3.org
news.bbc.co.uk

to mention two pages that I've been reading in the past few minutes.

Okay - there are some more ;-)

>It's just no use for me and probably others, since the majority
doesn't use them.

As I said: it does them no harm - and somebody's got to make a start.

My mistake - I was looking from the user perspective, not the coder's.
Yes, it's a good idea to code them, for those that want to use them. I
actually had a plan for it one day, (for prev and next links on
photopages) but never carried it out (yet).

It's a pity that FF took them out (they were avaliable in Moz, even if
they were disabled by default and one had to go out of one's way to
enable them). But Opera attracts discerning users - maybe they'll be
the ones to give the critical mass. The idea has been simmering
forever, and Lynx has had support for it (which was what first
attracted me to it, many years ago - the ability to call up a
navigation toolbar with a single "#" keycommand).

Well, they sort of had to, being that you can't use a mouse and
tabbing through pages can be a pain ;-)

If authors don't put them in, they can't be used! If authors *do* put
them in, as an optional extra, then at least they are available, and
they do no harm to anyone who can't or won't use them. That's why I
find the idea of scripting to be beneficial: I don't have to design
and code the links specially - once the script is in place, they are
generated from the same data as also generates the navigation bar on
the page.

Okay, next: is that script of yours difficult to implement for other
people? Like specifically - would it be of any use to me to get
<link>s into my own pages?

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

[Alan J. Flavell]

On Sat, 22 Jul 2006, Els wrote:

Okay, next: is that script of yours difficult to implement for other
people?

As I've already said - the specific details in mine were set, some
years back, and if I was starting again today there would likely be
big differences. So, what I'm saying is, feel free to use the
*principles* I'm suggesting, but don't just copy the details
uncritically.

First of all, one needs to decide whether to do this offline ("at
publishing time" i.e in conjunction with uploading the content to the
server to produce static pages), or on the fly when the page is
requested (SSI, PHP etc.).

In my case, as it's a relatively low-volume site, I make do with
on-the-fly processing, despite its (small) overhead and its potential
for interfering with cacheing.

In principle I'm using SSI - but actually it's Apache "XBitHack full",
which gives a bit more control over cacheability. Nowadays one might
consider PHP.

Basically, the source for each page starts with a template similar to
this:

<!--#set var="title" value="Cycle around Glasgow"
--><!--#set var="rev_made" value=""
--><!--#set var="link_prev" value=""
--><!--#set var="link_up" value="./"
--><!--#set var="link_more" value=""
--><!--#set var="link_next" value=""
-->

by which I can define various "variables" for the page. Having
copied-in my default template, I can then edit it to define suitable
values for title, link_prev, link_more etc., to define the author to
be someone else, and so on.

Then, at various points in the page, I run a bit of code, like this

<!--#include virtual="/%7Eflavell/bit-of-code-for-links" -->

In that code, I work my way down the variables which are relevant to
that bit-of-code, and generate the corresponding HTML.

When the rev_made variable is null, the code puts my details in as
author. So I only need to define that if it's different. The same
goes for stylesheet(s), document language, shortcut icon, and so on
(details not shown here).

When a link_* is null, on the other hand, it omits the link
altogether.

Later in the page, I'll then call another bit-of-code-for-navbar,
and it will do a similar job for building the navbar.

In SSI, it goes something like this (in the bit-of-code-* files):

[...]
<title><!--#echo var="title" --></title>
<!--#if expr="$rev-made" --><LINK REV="Made"
HREF="<!--#echo var="rev_made" -->"><!--#endif
--><!--#if expr="$link_pre v" --><LINK REL="Prev"
HREF="<!--#echo var="link_prev" -->"><!--#endif
--><!--#if expr="$link_up" --><LINK REL="Up"
HREF="<!--#echo var="link_up" -->"><!--#endif
--><!--#if expr="$link_mor e" --><LINK REL="More"
HREF="<!--#echo var="link_more" -->"><!--#endif
--><!--#if expr="$link_nex t" --><LINK REL="Next"
HREF="<!--#echo var="link_next" -->"><!--#endif
-->

and so on. But I must stress that I'm only showing this detail in
order to illustrate the principle. It's old code, and could surely be
done better with e.g PHP. Or, as I say, it could be implemented in a
preprocessor step at the time of publishing to the server, leaving the
result as a static page with the full benefits of cacheability.

As an aside, it can be useful to run a local Apache server on one's
editing platform (even a laptop), configured as closely as possible to
the production server, and to browse the edited pages via
http://localhost/ prior to uploading them to the production server
(I'm assuming that the production server will be an Apache-family
server, seeing that most of them are ;-). There are many kinds of
problem which simply don't show up when one merely browses the local
HTML files. That's true even if one doesn't use SSI or PHP, but can
be especially useful if one does.

Then again, you could turn the whole thing inside-out and use a
content management system for the page content.

h t h