By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,797 Members | 1,262 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,797 IT Pros & Developers. It's quick & easy.

Fails on IE?!

P: n/a
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

Jul 18 '06 #1
Share this Question
Share on Google+
28 Replies


P: n/a
Els
la***********@zipmail.com wrote:
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?
IE6 doesn't support :hover on anything else than <a>.

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/
Jul 18 '06 #2

P: n/a
la***********@zipmail.com wrote:
Hi, Surprisingly, I can't get the drop down menus to work on PC IE 6.
Why "surprisingly"?
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
IE recognizes :hover only for A. Surprise!
Jul 18 '06 #3

P: n/a
On Tue, 18 Jul 2006, Els wrote:
IE6 doesn't support :hover on anything else than <a>.
To be pedantic, it won't support :hover on anything else
than <a href=...>

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

Although, as others already said, you can use CSS to make <ainto a
display:block element if you want, give it a nice box and background,
and the whole thing will then respond to :hover, even in IE. This
solution isn't acceptable in some situations, naturally (e.g links in
running text), but in others (e.g individual entries on a menu) it can
work just fine.

What *is* this fascination with :hover, anyway? If readers can't tell
beforehand that a link is a link, there's something wrong with the
design. It's supposed to be a navigation aid, ferchrissake - not some
kind of lucky dip, that you have to wave a rodent over to see what
lights up. (Except, of course, when it *is* meant to be a lucky
dip...).

Jul 18 '06 #4

P: n/a
Els
Alan J. Flavell wrote:
On Tue, 18 Jul 2006, Els wrote:
>IE6 doesn't support :hover on anything else than <a>.

To be pedantic,
If you must :-)
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.
Although, as others already said, you can use CSS to make <ainto a
display:block element if you want, give it a nice box and background,
and the whole thing will then respond to :hover, even in IE. This
solution isn't acceptable in some situations, naturally (e.g links in
running text), but in others (e.g individual entries on a menu) it can
work just fine.

What *is* this fascination with :hover, anyway? If readers can't tell
beforehand that a link is a link, there's something wrong with the
design. It's supposed to be a navigation aid, ferchrissake - not some
kind of lucky dip, that you have to wave a rodent over to see what
lights up. (Except, of course, when it *is* meant to be a lucky
dip...).
It's what people expect. If I see a menu - the conventional type: list
of links on the left, content of the page on the right. I *just know*
the words on the left are links, but when I go there with my mouse and
nothing happens, I'm surprised. I'll even hover again to see if I've
overlooked a less than obvious hover effect.

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/
Jul 18 '06 #5

P: n/a
Alan J. Flavell wrote:
On Tue, 18 Jul 2006, Els wrote:
>IE6 doesn't support :hover on anything else than <a>.

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

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

Although, as others already said, you can use CSS to make <ainto a
display:block element if you want, give it a nice box and background,
and the whole thing will then respond to :hover, even in IE. This
solution isn't acceptable in some situations, naturally (e.g links in
running text), but in others (e.g individual entries on a menu) it can
work just fine.

What *is* this fascination with :hover, anyway? If readers can't tell
beforehand that a link is a link, there's something wrong with the
design.
Even when it's obvious that there's something clickable, feedback that
tells you when the cursor is and is not within the area within which
clicking will produce a result can be valuable. It's not an absolute
necessity, but it isn't hopelessly misguided. Take the tabs show in the
first image under the section "Clickable Region Fix" in the "Sliding
Doors" article on A List Apart:

http://www.alistapart.com/articles/slidingdoors2/

Not the entirety of a tab reacts to clicking. A mouseover effect helps
alert the user to this fact.
Jul 18 '06 #6

P: n/a
Alan J. Flavell wrote:
What *is* this fascination with :hover, anyway? If readers can't tell
beforehand that a link is a link, there's something wrong with the
design. It's supposed to be a navigation aid, ferchrissake - not some
kind of lucky dip, that you have to wave a rodent over to see what
lights up. (Except, of course, when it *is* meant to be a lucky
dip...).
I take your point but there are circumstances when it is appropriate to
use hovering (perhaps with title) to disclose that a string is actually
link.

A case in point might be a history with very frequent citing of persons,
places and events where it is wanted to link to particular end notes.
To differentiate these on the page , visually, disrupts the readers'
eye. It can look like a pakapoo ticket

The only need is for the reader to be advised that end notes for cited
elements are available on mouse over.

Louise

Jul 18 '06 #7

P: n/a

Alan J. Flavell wrote:
What *is* this fascination with :hover, anyway? If readers can't tell
beforehand that a link is a link, there's something wrong with the
design.
There's another advantage to :hover. Competent design might tell you
"Here's a table of links", but :hover also gives you feedback that your
pointer is properly placed over a particular link. For dense
navigation, this can be a useful usability benefit.

Jul 19 '06 #8

P: n/a
Alan J. Flavell schrieb:
What *is* this fascination with :hover, anyway? If readers can't tell
beforehand that a link is a link, there's something wrong with the
design. It's supposed to be a navigation aid, ferchrissake
In addition to what has been mentioned already, I see 2 more cases where
it can be useful:

tr:hover {[...]}
This can be very helpful if you have a list with many columns and some
"edit" and "delete" buttons at the end of each row, as for example in
phpMyAdmin. It helps keeping orientation about which row you are
actually clicking on. (As it is a helping goodie only, lacking IE
support is not a problem.)

a:hover, a:focus {[...]}
This combination produces a consistent rendering of a link, regardless
of it being accessed by hovering or with the tab key.

--
Markus
Jul 19 '06 #9

P: n/a
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.
What *is* this fascination with :hover, anyway? If readers can't
tell beforehand that a link is a link, there's something wrong
with the design. It's supposed to be a navigation aid,
ferchrissake - not some kind of lucky dip, that you have to wave a
rodent over to see what lights up.
....
It's what people expect.
Well, OK, you do have a point. There can be benefits in doing some
things - even things which are illogical - if they're what the user is
accustomed to.[1] After all, it's a good principle to keep in mind
that web users spend most of their browsing time on *other* sites, to
the extent that "innovative" ways of doing things can leave the users
baffled and confused.

In this instance I'm not entirely convinced - even though I had
included a modest hover effect (for unvisited links) in my own
stylesheet, in the interests of user familiarity. And, as another has
said, if there's any doubt that the rodent is *really* over the link
text, the hover effect can confirm it.

cheers

[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.
Jul 21 '06 #10

P: n/a
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/
Jul 21 '06 #11

P: n/a
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
Jul 21 '06 #12

P: n/a
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/
Jul 21 '06 #13

P: n/a
Gazing into my crystal ball I observed Els <el*********@tiscali.nlwriting
in news:br*****************************@40tude.net:
>>
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

Jul 22 '06 #14

P: n/a
Els
Adrienne Boswell wrote:
Gazing into my crystal ball I observed Els <el*********@tiscali.nlwriting
in news:br*****************************@40tude.net:
>>>
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/
Jul 22 '06 #15

P: n/a
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.

--

Jul 22 '06 #16

P: n/a
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/
Jul 22 '06 #17

P: n/a
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
Jul 22 '06 #18

P: n/a
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/
Jul 22 '06 #19

P: n/a
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_prev" --><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_more" --><LINK REL="More"
HREF="<!--#echo var="link_more" -->"><!--#endif
--><!--#if expr="$link_next" --><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
Jul 22 '06 #20

P: n/a
Gazing into my crystal ball I observed Els <el*********@tiscali.nl>
writing in news:vy****************************@40tude.net:
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?

In addition to what Alan does, I do this little bit in ASP (also PHP but
I'll use ASP for this example)

dim thispage, thisurl, thefirst, thelast, thenext, theprevious

thispage = "Welcome"
thisurl = "index.asp"

If the page has pagination then:
thefirst = firstpage
if page = 1 then
thenext = firstpage+1
else
thenext = page +1
end if
if page 1 then
theprevious = page-1
end if
thelast = lastpage

Then in linkrel_inc.asp ->
<% if page <"" then %>
<link rel="first" href="<%=thefirst%>">
<link rel="next" href="<%=thenext%>">
<link rel="last" href="<%=thelast%>">
<% if page 1 then%>
<link rel="previous" href="<%=theprevious%>">
<%end if
end if%>
<link rel="Home" href="index.asp">
<link type="text/css" href="style.css" rel="stylesheet">
<link type="text/css" href="colors.css" rel="stylesheet">
<title>Some nice Website - <%=thispage%></title>
<meta name="description" contents="Some nice Website <%=thispage%>">
And in H1_inc.asp ->
<h1><%=thispage%></h1>
This saves a lot of typing, and a lot of not remembering to fill in the
title element. It don't do too bad in the search engines either.

I like to separate colors and positioning into two separate stylesheets.
It makes it easier for me to change colors, or to have different colors
themes (especially in the case liturgical colors for a church site I
designed and maintain).

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

Jul 22 '06 #21

P: n/a
On Sat, 22 Jul 2006 12:36:14 +0200, Els wrote:
Adrienne Boswell wrote:
>Gazing into my crystal ball I observed Els <el*********@tiscali.nl>
writing in news:br*****************************@40tude.net:

>>>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).
In Opera, if there's a 'next' link, pressing the space bar when the screen
is scrolled to the bottom of the page will go to it. This also works if
there's a link with the text 'next' -- try pressing space repeatedly on a
Google search results page. There's a few other shortcuts for this too
(the >button for instance).

I prefer the Shift-arrowkey shortcuts in Opera, I think it's quicker. But
'A' and 'Q' are the equivalent to 'Tab' and 'Shift-tab' here (more or less).
> 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.
Opera have given in and gone with Ctrl-T for new tab in version 9, if you
do a clean install (otherwise it keeps the old Ctrl-N). Ctrl-H doesn't go
to the address bar for me, but I use F8 for this.

--
Matt

Jul 22 '06 #22

P: n/a
Els
Matt wrote:
>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).

In Opera, if there's a 'next' link, pressing the space bar when the
screen is scrolled to the bottom of the page will go to it. This
also works if there's a link with the text 'next' -- try pressing
space repeatedly on a Google search results page. There's a few
other shortcuts for this too (the >button for instance).

I prefer the Shift-arrowkey shortcuts in Opera, I think it's
quicker. But 'A' and 'Q' are the equivalent to 'Tab' and
'Shift-tab' here (more or less).
Yes, but my point is that all the other browsers use the TAB to go
from link to link, and if I automatically do the same in Opera, I get
send back and forth between input elements. A and Q just aren't as
logical and obvious to type when I want to go to the next link. (YMMV
of course)

Sidenote: I discovered that 'A' doesn't always work well. On the
homepage of http://locusoptimus.com for instance, when I load the
page, and press A several times, it just goes back and forth between
the logo and the 'skip to content' link (which isn't visible because
Opera won't respond to :focus styles). It doesn't go further to the
navigation or in page links. I can press the Q multiple times to go
backwards into the navigation though, but it does seem a bit
cumbersome ;-)
>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.

Opera have given in and gone with Ctrl-T for new tab in version 9,
if you do a clean install (otherwise it keeps the old Ctrl-N).
Good to know. Now that you mention it, I think I may have noticed it
once. (Don't remember where I installed 9 though - could have been the
beta before my hd crashed)
Ctrl-H doesn't go to the address bar for me, but I use F8 for this.
If only the different browsers would use the same shortcuts...

I would also like the different languages to use the same shortcuts,
but I don't think that will ever happen. In my Dutch progs I need
alt-b-p to save a document, in the English ones it's alt-f-s. Logical
language wise, but tricky when using more than one language on one PC
:-)

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/
Jul 22 '06 #23

P: n/a
Els
Alan J. Flavell wrote:
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.
I never use anything uncritically ;-)

[snip lots of info]
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.
Yup, that's how I do it too. Not 'localhost' though - I use proper
domain names and subdomains ;-)

Even if a site is not going to use PHP when live, I still use includes
locally during development, to make my life easier.
Then again, you could turn the whole thing inside-out and use a
content management system for the page content.
That would feel like cheating...
h t h
It did, thanks :-)

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/
Jul 22 '06 #24

P: n/a
Els
Adrienne Boswell wrote:
In addition to what Alan does, I do this little bit in ASP (also PHP
but I'll use ASP for this example)
[snip example code]

Thanks, that's helpful.
And in H1_inc.asp ->
<h1><%=thispage%></h1>
This saves a lot of typing, and a lot of not remembering to fill in
the title element. It don't do too bad in the search engines
either.
Makes sense, yes.
I like to separate colors and positioning into two separate stylesheets.
It makes it easier for me to change colors, or to have different colors
themes (especially in the case liturgical colors for a church site I
designed and maintain).
I did that too after the first theme/colour change of my site. Going
through a long stylesheet hunting down colour values is something you
have to do only once, before converting to use separate stylesheets.

(before anyone tells me I'm not using a separate stylesheet on my site
currently: that's because I don't intend to keep this layout with
different colours ;-) )
--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/
Jul 22 '06 #25

P: n/a
Gazing into my crystal ball I observed Els <el*********@tiscali.nlwriting
in news:48****************************@40tude.net:
I did that too after the first theme/colour change of my site. Going
through a long stylesheet hunting down colour values is something you
have to do only once, before converting to use separate stylesheets.

Yup, and I'm playing with generated stylesheets, for example:
Get the value of the current color (green), and
programatically/mathematically change it in all the stylesheet (shades of
green). I'm not quite there yet, but when I am, I'll probably post it
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

Jul 22 '06 #26

P: n/a
Els
Adrienne Boswell wrote:
Yup, and I'm playing with generated stylesheets, for example: Get
the value of the current color (green), and
programatically/mathematically change it in all the stylesheet
(shades of green). I'm not quite there yet, but when I am, I'll
probably post it somewhere.
If 'somewhere' is in a place where I'll see it, that would be good :-)

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/
Jul 23 '06 #27

P: n/a
Gazing into my crystal ball I observed Els <el*********@tiscali.nl>
writing in news:1m****************************@40tude.net:
Adrienne Boswell wrote:
>Yup, and I'm playing with generated stylesheets, for example: Get
the value of the current color (green), and
programatically/mathematically change it in all the stylesheet
(shades of green). I'm not quite there yet, but when I am, I'll
probably post it somewhere.

If 'somewhere' is in a place where I'll see it, that would be good :-)
Sure thing... The only thing I have up now is this
<http://www.intraproducts.com/usenet/requiredform.aspa form that uses
CSS to present information to the user as to was not submitted or not
correctly submitted. It might keep you amused for a minute or two.

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

Jul 23 '06 #28

P: n/a
begin quotation
from la***********@zipmail.com <la***********@zipmail.com>
in message <11**********************@s13g2000cwa.googlegroups .com>
posted at 2006-07-18T19:04
Hi, Surprisingly, I can't get the drop down menus to work on PC IE 6.
There is no such thing as "PC IE 6". There is a Windows IE, and a MacOS
IE, and I think even a Solaris IE.

--
___ _ _____ |*|
/ __| |/ / _ \ |*| Shawn K. Quinn
\__ \ ' < (_) | |*| sk*****@speakeasy.net
|___/_|\_\__\_\ |*| Houston, TX, USA
Jul 24 '06 #29

This discussion thread is closed

Replies have been disabled for this discussion.