468,771 Members | 1,798 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,771 developers. It's quick & easy.

htmldog suckerfish liquid

Anyone knows if the htmldog suckerfish menu can be done in a more fluid
way: http://www.htmldog.com/articles/suckerfish/dropdowns/

Or more precisely, the 2-level menu:
http://www.htmldog.com/articles/suck...le/bones2.html

In fluid I mean:

1) The width of each drop menu to equal the widest text of any item
contained within the visible drop menu.

2) The width each of the area for the always visible texts (Percoidei,
Anabantoidei and Gobiodei) to match that of each of those words.

3) Insert an equal distance between the always visible menu words depending
on the width of the browser window, so in case the browser window happens
to be for example 600 pixels:

---------------------------600px----------------------------

Percoidei Anabantoidei Anabantoidei

Or if the window is sized down to 360 pixels:
---------------360px-----------------
Percoidei Anabantoidei Anabantoidei
Can this be done in CSS? If so any tips how would be greatly appreciated!

Oct 21 '05 #1
23 2588
timmy wrote:
Anyone knows if the htmldog suckerfish menu can be done in a more fluid
way: http://www.htmldog.com/articles/suckerfish/dropdowns/

Or more precisely, the 2-level menu:
http://www.htmldog.com/articles/suck...le/bones2.html

In fluid I mean:

1) The width of each drop menu to equal the widest text of any item
contained within the visible drop menu.

2) The width each of the area for the always visible texts (Percoidei,
Anabantoidei and Gobiodei) to match that of each of those words.

3) Insert an equal distance between the always visible menu words depending
on the width of the browser window, so in case the browser window happens
to be for example 600 pixels:

---------------------------600px----------------------------

Percoidei Anabantoidei Anabantoidei

Or if the window is sized down to 360 pixels:
---------------360px-----------------
Percoidei Anabantoidei Anabantoidei
Can this be done in CSS? If so any tips how would be greatly appreciated!

timmy,

1) display: table might be what you want here.
2) Ambiguous requirement. What does "width of the area" mean? I see
three words, of differing lengths. I don't see any "area".
3) width: 33% or thereabouts for each word, or a div within which the
word exists.

Possible in CSS? Probably, if you confine yourself to
standards-compliant browsers. In other words, forget IE, which probably
isn't a bad idea...

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
non-compliant browsers will send you to the funny farm.

Chris Beall

Oct 24 '05 #2
> 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/suck...le/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.
Oct 24 '05 #3
timmy wrote:
(snip)
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.


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

Oct 25 '05 #4
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.

Oct 25 '05 #5
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.
Oct 25 '05 #6
> 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.


Worse implies that less worse drop menu solutions exist? Can anyone
recommend better drop menu solutions than the htmldog/suckerfish version?
Eg. site examples where I can go and deconstruct the code.

100% purism compromised I need a drop menu as I have a deep navigation and
it simply fits the site I'm working on, yet I can't ignore IE accessibility.

Oct 25 '05 #7
On Tue, 25 Oct 2005 16:16:17 +0200, timmy <sp****@mailinator.com> wrote:
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.


Worse implies that less worse drop menu solutions exist? Can anyone
recommend better drop menu solutions than the htmldog/suckerfish version?
Eg. site examples where I can go and deconstruct the code.


Well, I did one for Atlis when the owner wanted it very badly. I don't
think the result is too awful:

http://www.atlis.nl/nl/home/

If there are better ways, I'd be interested in hearing them.

(To save people commenting: no, the content of the English site doesn't
match the Dutch site.)

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Oct 25 '05 #8
timmy wrote:
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.

Worse implies that less worse drop menu solutions exist? Can anyone
recommend better drop menu solutions than the htmldog/suckerfish version?
Eg. site examples where I can go and deconstruct the code.

100% purism compromised I need a drop menu as I have a deep navigation and
it simply fits the site I'm working on, yet I can't ignore IE accessibility.


http://www.tanfa.co.uk/css/examples/menu/tutorial-h.asp

It seems to work just fine and it addresses the IE compatibility issues.
I had avoided menus for years on my site but this is what I'm using now.

--
Ed Mullen
http://edmullen.net
http://mozilla.edmullen.net
Oct 26 '05 #9
Ed Mullen <ed@edmullen.net> wrote:
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.


Worse implies that less worse drop menu solutions exist? Can anyone
recommend better drop menu solutions than the htmldog/suckerfish version?
Eg. site examples where I can go and deconstruct the code.

100% purism compromised I need a drop menu as I have a deep navigation and
it simply fits the site I'm working on, yet I can't ignore IE accessibility.


http://www.tanfa.co.uk/css/examples/menu/tutorial-h.asp

It seems to work just fine and it addresses the IE compatibility issues.
I had avoided menus for years on my site but this is what I'm using now.


This seems to use the same technique as the suckerfish menus that
kchayka referred to, it dumps to many navigation links on every page.
The rule of thumb for navbars is that they should contain no more than 7
links. On top of that the use of headers in your quoted example is
seriously misguided, adding yet another accessibility issue.

--
Spartanicus
Oct 26 '05 #10
Spartanicus wrote:
Ed Mullen <ed@edmullen.net> wrote:

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.

Worse implies that less worse drop menu solutions exist? Can anyone
recommend better drop menu solutions than the htmldog/suckerfish version?
Eg. site examples where I can go and deconstruct the code.

100% purism compromised I need a drop menu as I have a deep navigation and
it simply fits the site I'm working on, yet I can't ignore IE accessibility.


http://www.tanfa.co.uk/css/examples/menu/tutorial-h.asp

It seems to work just fine and it addresses the IE compatibility issues.
I had avoided menus for years on my site but this is what I'm using now.

This seems to use the same technique as the suckerfish menus that
kchayka referred to, it dumps to many navigation links on every page.
The rule of thumb for navbars is that they should contain no more than 7
links. On top of that the use of headers in your quoted example is
seriously misguided, adding yet another accessibility issue.


Too many nav links? The example has three nav buttons at the top and
the deepest drop down has 6 links. Pretty simple. My menu structure
has more links in some of the drop-downs but provides a consistent
interface across every page which was the goal.

Could you provide some detail for your comment about headers, please? I
honestly don't know what you mean.

--
Ed Mullen
http://edmullen.net
http://mozilla.edmullen.net
Everybody repeat after me ...We are all individuals.
Oct 26 '05 #11
Ed Mullen <ed@edmullen.net> wrote:
http://www.tanfa.co.uk/css/examples/menu/tutorial-h.asp

It seems to work just fine and it addresses the IE compatibility issues.
I had avoided menus for years on my site but this is what I'm using now.

This seems to use the same technique as the suckerfish menus that
kchayka referred to, it dumps to many navigation links on every page.
The rule of thumb for navbars is that they should contain no more than 7
links. On top of that the use of headers in your quoted example is
seriously misguided, adding yet another accessibility issue.


Too many nav links? The example has three nav buttons at the top and
the deepest drop down has 6 links.


"Look" beyond what you can see, screen readers and talking browsers read
out all links. In the visual domain folding menu type navigation coded
as content cleans up the interface considerably, but at the expense of
aural rendering.
Could you provide some detail for your comment about headers, please? I
honestly don't know what you mean.


Headers should be used to markup document structure, not the structure
of a menu.

--
Spartanicus
Oct 26 '05 #12
Ed Mullen wrote:

http://www.tanfa.co.uk/css/examples/menu/tutorial-h.asp

It seems to work just fine and it addresses the IE compatibility issues.


It doesn't seem to work very fine for us keyboard users. :(

Enabling or disabling JavaScript has no effect, and disabling CSS
reveals a couple screens worth of links. Why do I want to pour through
that on every page?

FWICT, this isn't any better than any other DHTML menu. It just bloats
the page with excess code. Some of your visitors may find the menu
convenient, but it's at the expense of others.

I still think the best method is to code on each page just main menu
links (no submenus) that go to real web pages. On those pages list all
the links for the submenu pages. Use JS to add the DHTML submenus in.
Then those who want to use the fancy schmancy menus can, and those who
don't won't be punished for it. Or at least not punished as severely.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Oct 26 '05 #13
kchayka <us****@c-net.us> wrote:
I still think the best method is to code on each page just main menu
links (no submenus) that go to real web pages. On those pages list all
the links for the submenu pages.
Add a layer of documents that serve no other purpose than to link to a
deeper level of documents?
Use JS to add the DHTML submenus in.


Add in where?

If JS is used to create sub menus on the site navbar then like most
so-called CSS drop down menus it again causes all links to be read out
by screen readers and talking browsers who use a JS enabled renderer
(most if not all renderers used by aural clients are JS capable).

--
Spartanicus
Oct 26 '05 #14
Spartanicus wrote:
kchayka <us****@c-net.us> wrote:
I still think the best method is to code on each page just main menu
links (no submenus) that go to real web pages. On those pages list all
the links for the submenu pages.
Add a layer of documents that serve no other purpose than to link to a
deeper level of documents?


If there is an always-visible submenu on each page of a section, then
you don't really need this, but that is not what you get with the
typical DHTML menu. So this is an accessible alternative.

Personally, I'd rather have an always-visible submenu specific to the
section I happen to be in. Anything more than that is too much info,
less might make navigation cumbersome, but it depends on the site. We
don't need no stinkin' DHTML menus for sure, but there's no convincing
some people.

If link elements were more mature, they could be useful, but browser
support isn't where it should be for link to be a viable solution.
If JS is used to create sub menus on the site navbar then like most
so-called CSS drop down menus it again causes all links to be read out
by screen readers and talking browsers who use a JS enabled renderer
(most if not all renderers used by aural clients are JS capable).


If the submenus are hidden via display:none or visibility:hidden and
only become visible on :hover/mouseover, a JS-enabled screen reader
won't read them out. At least not the most-used readers, all of which
honor screen media CSS. How many screen reader users use a mouse to
navigate? Not many, I'd say. ;)

And any JS-disabled browser won't have to be bothered with them at all. :)

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Oct 26 '05 #15
kchayka <us****@c-net.us> wrote:
Add a layer of documents that serve no other purpose than to link to a
deeper level of documents?


If there is an always-visible submenu on each page of a section, then
you don't really need this, but that is not what you get with the
typical DHTML menu. So this is an accessible alternative.


Sorry, I can't parse that.
If JS is used to create sub menus on the site navbar then like most
so-called CSS drop down menus it again causes all links to be read out
by screen readers and talking browsers who use a JS enabled renderer
(most if not all renderers used by aural clients are JS capable).


If the submenus are hidden via display:none or visibility:hidden and
only become visible on :hover/mouseover, a JS-enabled screen reader
won't read them out.


I'm not really familiar with either JS or CSS drop down menus (can't
stand them), but afaik many do expand fully when accessed with an AT
talking browser or screen reader. The example drop downs posted in this
thread do anyway (IBM HPR/IE).

--
Spartanicus
Oct 27 '05 #16
> thread do anyway (IBM HPR/IE).

The fact is that drop-menus are useful navigation aids, there are sites
than can benefit from them, it depends on how much info there is and how it
communicates optimally. Its sometimes not a good idea to display always
visable links of everything everywhere onsite as users can suffer
information overload. But what some people don't understand here is you
don't design content around CSS standards which happens to be technically
viable at this time, instead you cut corners to reach critical mass. But I
guess I won't get much agreement no matter what on this topic, as many
participants here are purists without a purpose, yet some opinions are
interesting to know, if valid however, it depends on the purpose of each
individual site, and sometimes 100% accessibility is simply not necessary.

Oct 27 '05 #17
in comp.infosystems.www.authoring.stylesheets, Spartanicus wrote:
I'm not really familiar with either JS or CSS drop down menus (can't
stand them), but afaik many do expand fully when accessed with an AT
talking browser or screen reader. The example drop downs posted in this
thread do anyway (IBM HPR/IE).


That is IMHO big problem. It is OK to it to expand partially (for example
the subsection you are currently in), but fully - who will have time to
read/hear it again every time in need to use it. DHTML menus work soehow,
as they are used to categorize lots of links in small space. Without
collapsing, link list will easily be far too long for one page.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Oct 27 '05 #18

On Tue, 25 Oct 2005, Chris Beall wrote:
timmy wrote:
(snip)
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.


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).


Not really. I have seen this asserted so often that I had to make some
tests to see if it was right. It isn't.

As long as the image sizes are specified with appropriate units (use "em"
and not "px"), the image size will change along with the text size.
Alt text can be used for text-only viewers and search-engines.

Figuring out the appropriate em specification is left as an exercise for
the webmaster. Better appearance with larger text size is produced by
creating the images oversize and letting the browser reduce them when
necessary.

The following was tested and found to work in IE, Firefox and Opera
(but Opera always enlarges *everything* anyway). The URL for a test
riddle/joke with the answer in three formats, (a) text only using Unicode
character entities, (b) images of the special characters with the entities
as alt text and (c) images with the names of the characters as alt text
was posted to alt.comp.blind-users and version (c) was judged to be the
most accessible:
http://www.chebucto.ns.ca/~af380/ts1.htm
Note that the images of the characters in versions (b) and (c) change
size when the text size is changed.

Bandwidth may be a valid reason for avoiding images. An inability to
resize images is *not* a valid reason.

--
Norman De Forest http://www.chebucto.ns.ca/~af380/Profile.html
"> Is there anything Spamazon DOESN'T sell?
Clues. The market's too small to justify the effort."
-- Stuart Lamble in the scary devil monastery, Fri, 13 May 2005

Oct 27 '05 #19
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
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).
Not really. I have seen this asserted so often that I had to make some
tests to see if it was right. It isn't.

As long as the image sizes are specified with appropriate units (use "em"
and not "px"), the image size will change along with the text size.


You seem to have missed the rather fundamental point that CSS is
optional, and only by using CSS can you suggest a rendering in a size
relative to the user's font setting.

Then there's also the issue that people use images of text because they
are super precious about how their text looks on their screens, that
goal isn't exactly helped by having a CSS enabled browser resize images
which is likely to result in ugly graphics.
Alt text can be used for text-only viewers and search-engines.
SE's may not index alt content, or only when the image is linked, alt
content rendering is regularly switched off by default, or disabled by
users of AT UAs.
Figuring out the appropriate em specification is left as an exercise for
the webmaster. Better appearance with larger text size is produced by
creating the images oversize and letting the browser reduce them when
necessary.


Browser down sized images are often still ugly as feck.

--
Spartanicus
Oct 27 '05 #20
Spartanicus wrote:

I'm not really familiar with either JS or CSS drop down menus (can't
stand them), but afaik many do expand fully when accessed with an AT
talking browser or screen reader.
Some do, but only if they are specifically coded to do so, via onfocus
or some other method. I have never seen one do it by default otherwise.
The example drop downs posted in this
thread do anyway (IBM HPR/IE).


That actually seems to be a bug in the latest release, HPR 3.04. It's
showing anything with a title attribute, regardless of display:none or
visibility:hidden. If there's no title attribute, the links stay hidden.
HPR 3.02 did not have this anomoly. I reported it to IBM.

The expectation is display:none hides content from most screen readers
as well as on screen.
<URL:http://www.access-matters.com/screen-reader-test-results/>

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Oct 27 '05 #21

On Thu, 27 Oct 2005, Spartanicus wrote:
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
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).
Not really. I have seen this asserted so often that I had to make some
tests to see if it was right. It isn't.

As long as the image sizes are specified with appropriate units (use "em"
and not "px"), the image size will change along with the text size.


You seem to have missed the rather fundamental point that CSS is
optional, and only by using CSS can you suggest a rendering in a size
relative to the user's font setting.


So visually-impaired users with no CSS get larger, more viewable images.
The layout may be messed up but it's viewable.

Then there's also the issue that people use images of text because they
are super precious about how their text looks on their screens, that
goal isn't exactly helped by having a CSS enabled browser resize images
which is likely to result in ugly graphics.
The webmaster should be a judge of what he/she considers ugly.
Alt text can be used for text-only viewers and search-engines.


SE's may not index alt content, or only when the image is linked, alt
content rendering is regularly switched off by default, or disabled by
users of AT UAs.


Screen-readers reading special Unicode characters can be worse than
screen-readers reading alt text. If you have a red heart on a page,
is it better to get an image with the alt text read out as "heart" or
better to use a Unicode heart and get the Unicode name of the character
read out as "black heart suit" (if the browser and/or screen reader can
even recognise the character)?

Which do you think screen-readers will handle better, this?
(Read out as "I black heart suit baby seals".)

...
...
<p>I ♥ baby seals</p>
...
...

Or this? (Read out as "I heart baby seals.")

...
...
<style type="text/css" media="screen">
<!--
.shirtsymbol { height: .8em; width: 1em; color: red}
-->
</style>
...
...
<p>I <img src="heart.gif" alt="Heart" title="Heart"
class="shirtsymbol"> baby seals</p>
...
...
Figuring out the appropriate em specification is left as an exercise for
the webmaster. Better appearance with larger text size is produced by
creating the images oversize and letting the browser reduce them when
necessary.


Browser down sized images are often still ugly as feck.


Two questions:

1. Why did you snip my mention of the opinions posted to alt.comp.blind
users?

2. Did you look at the pages with the three answer formats to see
what they are like or are you commenting without having seen them?

--
Norman De Forest http://www.chebucto.ns.ca/~af380/Profile.html
"> Is there anything Spamazon DOESN'T sell?
Clues. The market's too small to justify the effort."
-- Stuart Lamble in the scary devil monastery, Fri, 13 May 2005

Oct 27 '05 #22
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
>As long as the image sizes are specified with appropriate units (use "em"
>and not "px"), the image size will change along with the text size.
You seem to have missed the rather fundamental point that CSS is
optional, and only by using CSS can you suggest a rendering in a size
relative to the user's font setting.


So visually-impaired users with no CSS get larger, more viewable images.


A rendering without CSS is not particular to the visually impaired.
The layout may be messed up
Without CSS a document should be laid out in a basic but structured,
logical and correct manner, there is no reason why the layout should be
"messed up".
but it's viewable.
That is likely, did you mean usable?
Then there's also the issue that people use images of text because they
are super precious about how their text looks on their screens, that
goal isn't exactly helped by having a CSS enabled browser resize images
which is likely to result in ugly graphics.


The webmaster should be a judge of what he/she considers ugly.


The designer should be the judge of that, what do you think a designer
would think of your browser resized images of text?
>Alt text can be used for text-only viewers and search-engines.


SE's may not index alt content, or only when the image is linked, alt
content rendering is regularly switched off by default, or disabled by
users of AT UAs.


Screen-readers reading special Unicode characters can be worse than
screen-readers reading alt text.


The issue is that SE's not indexing alt content is a major reason why
designers have turned to IR techniques.
Two questions:

1. Why did you snip my mention of the opinions posted to alt.comp.blind
users?
Because it was irrelevant to the point I am making.

It is pointless to argue that images of text can be coded to be
accessible to the visually impaired if the likely practical result of
your proposed method is that the text ends up looking uglier than
rendered text. The reason why designers want to use images of text is
that they want a prettier result than rendered text.
2. Did you look at the pages with the three answer formats to see
what they are like or are you commenting without having seen them?


See above.

--
Spartanicus
Oct 27 '05 #23
kchayka <us****@c-net.us> wrote:
The example drop downs posted in this
thread do anyway (IBM HPR/IE).


That actually seems to be a bug in the latest release, HPR 3.04.


Possible, a quick check with Jaws showed that it does not expand the
menu choices. Perhaps my personal dislike of drop down menus tainted my
recollection of how they generally behave with AT software.

--
Spartanicus
Oct 27 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by kayodeok | last post: by
1 post views Thread by Martial Spirit | last post: by
reply views Thread by Chad | last post: by
248 posts views Thread by Generic Usenet Account | last post: by
3 posts views Thread by j0nharris | last post: by
michaelea
5 posts views Thread by michaelea | last post: by
9 posts views Thread by Eric Lindsay | last post: by
13 posts views Thread by ray | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.