|
Convenient web based access to our favorite web design Usenet groups
|
 |
This is Interesting: Free Magazines for Graphics designers and webmasters
| Author |
| Thread |
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
Re: htmldog suckerfish liquid |
 |
|
 |
|
|
|
 10-24-05 - 11:35 PM 
|
> three words, of differing lengths. I don't see any "area".
Yes you're right, the areas are not visible, as they're not colored on the
example.
What I mean is the area of the blocks (links) of the htmldog example, they
all span the same width of 10em as defined in the CSS code:
http://www.htmldog.com/articles/suc...ple/bones2.html
The excess space which I want to get rid of is between the end of the word
Percoidei to the start of the word Anabantoidei , and from the end of
Anabantoidei to the start of Gobioidei. This would make the horizontal
style menu more compact.
> I'm being deliberately vague here. Getting this to work the way you
> want will be a tedious and frustrating exercise. Making it work with
OK - sounds complicated, so instead, if I reduce the problem and my chances
of going to the funny farm, would it be possible to:
1) Make the areas containing the always visible links (eg. Percoidei,
Anabantoidei and Gobiodei) size only to required width of contents? (In
other words - no space on the right of any of the words).
2) Can the width of each drop menu equal the width of longest text within?
I can do the above using graphics instead of plain text links and fixed
pixel widths for each drop menu area, but it would make updating any site
that is changing on a frequent basis a more than tedious procedure.
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
|
|
|
Re: htmldog suckerfish liquid |
|
|
|
|
|
|
|
10-25-05 - 08:27 AM
|
timmy wrote:
(snip)
> OK - sounds complicated, so instead, if I reduce the problem and my chance
s
> of going to the funny farm, would it be possible to:
>
> 1) Make the areas containing the always visible links (eg. Percoidei,
> Anabantoidei and Gobiodei) size only to required width of contents? (In
> other words - no space on the right of any of the words).
>
> 2) Can the width of each drop menu equal the width of longest text within?
>
> I can do the above using graphics instead of plain text links and fixed
> pixel widths for each drop menu area, but it would make updating any site
> that is changing on a frequent basis a more than tedious procedure.
timmy,
Using graphics prohibits your visitor from changing the size of the text
and prevents search engines from indexing the words (which are probably
the most critical ones on the page for search purposes).
On some days, I might consider this to be an interesting technical
challenge, but this isn't one of them. The first thing I would do is
set my goal carefully:
- HTML and CSS only. No JavaScript.
- No support for IE, which is obsolete. This would allow me to use
:hover.
Since that last criteria probably isn't acceptable (yet) in the real
world, I know what I would do if it were MY site:
- Toss the JavaScript
- Toss all of the CSS associated with #nav.
That leaves you with a three-level nested list, which is, let's face it,
what the data is. Present it to the user that way. What's the point of
hiding most of the information, then showing fragments of it only when
the user, with a steady hand, hovers over the right spot with a mouse?
(I just tried to navigate through it using only the Tab key. I infer
that this 'works', but the 2nd and 3rd levels of the list are never
visible, so the user can't tell where the focus is, making it useless.)
Some problems you can bull through, some you can leap over. For some,
the best thing to do is just walk away and look for another path. I
think this is one of the latter.
Chris Beall
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
|
|
|
Re: htmldog suckerfish liquid |
|
|
|
|
|
|
|
10-25-05 - 11:27 AM
|
and prevents search engines from indexing the words (which are probably
> the most critical ones on the page for search purposes).
I only explored possible methods of making those menus appear same width of
the contaning texts. In fact I don't want to use graphics, and as I said,
it would make updating too complex.
Otherwise, doesn't the alt tag provide a space for searchable words?
> - HTML and CSS only. No JavaScript.
Javascript isn't that bad, it has a noscript tag fallback option for
example, and as long as a site is navigable without Javascript all should
be fine, thats being Javascript enhanced, not Javascript dependent.
In the suckerfish case the Javascript is used only for backwards
compatibility for IE. Otherwise hover is used.
> - No support for IE, which is obsolete. This would allow me to use
> :hover.
Unfortunately for a commercial site I can't afford to ignore IE yet
although I would like too. As much as I hate it, IE still has a large user
base of people who don't care about the latest browsers and so on.
> visible, so the user can't tell where the focus is, making it useless.)
Yes, I read that the menu has this problem, I think someone has a fix for
it, perhaps somewhere at: http://www.htmldog.com/ptg/archives/000050.php
> think this is one of the latter.
My last question was only how the top level items and drop menus can be
made as wide as they want, determined by the width of the widest containing
text string, and not as the current set-width suckerfish menus. But I guess
it isn't as simple as it sounds.
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
|
|
|
Re: htmldog suckerfish liquid |
|
|
|
|
|
|
|
10-25-05 - 11:42 PM
|
Chris Beall wrote:
>
> (I just tried to navigate through it using only the Tab key. I infer
> that this 'works', but the 2nd and 3rd levels of the list are never
> visible, so the user can't tell where the focus is, making it useless.)
This is a serious usability issue for us keyboard users. Even if the
submenus did display on focus, it makes for very cumbersome navigation
when you can't get to a particular link within a few keystrokes.
If I'm tabbing between links, I surely don't want to tab through a bunch
of submenus to get to the last group. Likewise, if I'm using a screen
reader, I surely don't want to listen to them. If this is on a separate
site map page, it is quite acceptable. It is not acceptable on every
bloomin' page.
> Some problems you can bull through, some you can leap over. For some,
> the best thing to do is just walk away and look for another path. I
> think this is one of the latter.
Agreed. DHTML menus generally suck to begin with, but the suckerfish
variety are worse (IMO) because they claim to be accessible. That's
rather an overstatement, IYAM.
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
|
|
|
|
|
|
|
| All times are GMT. The time now is 04:57 AM. |
|
|
|
|
|
| |
|
