 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / October 2005htmldog 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/suckerfish/dropdowns/example/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! > Anyone knows if the htmldog suckerfish menu can be done in a more fluid > way: http://www.htmldog.com/articles/suckerfish/dropdowns/ [quoted text clipped - 24 lines] > > 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 > 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/suckerfish/dropdowns/example/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. (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: [quoted text clipped - 8 lines] > 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 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. > (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.  SignatureReply email address is a bottomless spam bucket. Please reply to the group so everyone can share. > 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. >> Agreed. DHTML menus generally suck to begin with, but the suckerfish >> variety are worse (IMO) because they claim to be accessible. That's [quoted text clipped - 3 lines] >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.) SignatureStephen Poley http://www.xs4all.nl/~sbpoley/webmatters/ >>Agreed. DHTML menus generally suck to begin with, but the suckerfish >>variety are worse (IMO) because they claim to be accessible. That's [quoted text clipped - 6 lines] > 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. SignatureEd Mullen http://edmullen.net http://mozilla.edmullen.net >>>Agreed. DHTML menus generally suck to begin with, but the suckerfish >>>variety are worse (IMO) because they claim to be accessible. That's [quoted text clipped - 11 lines] >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. SignatureSpartanicus >>>>Agreed. DHTML menus generally suck to begin with, but the suckerfish >>>>variety are worse (IMO) because they claim to be accessible. That's [quoted text clipped - 17 lines] > 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. SignatureEd Mullen http://edmullen.net http://mozilla.edmullen.net Everybody repeat after me ...We are all individuals. >>>http://www.tanfa.co.uk/css/examples/menu/tutorial-h.asp >>> [quoted text clipped - 9 lines] >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. SignatureSpartanicus > 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. SignatureReply email address is a bottomless spam bucket. Please reply to the group so everyone can share. >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). SignatureSpartanicus >>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. :) SignatureReply email address is a bottomless spam bucket. Please reply to the group so everyone can share. >> 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 [quoted text clipped - 4 lines] >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). SignatureSpartanicus > 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. > 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. SignatureLauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts> > 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/> SignatureReply email address is a bottomless spam bucket. Please reply to the group so everyone can share. >> 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. SignatureSpartanicus > (snip) > > OK - sounds complicated, so instead, if I reduce the problem and my chances [quoted text clipped - 15 lines] > 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. SignatureNorman 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 >> Using graphics prohibits your visitor from changing the size of the text >> and prevents search engines from indexing the words (which are probably [quoted text clipped - 5 lines] >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. SignatureSpartanicus > >> Using graphics prohibits your visitor from changing the size of the text > >> and prevents search engines from indexing the words (which are probably [quoted text clipped - 9 lines] > 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? SignatureNorman 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 >> >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. [quoted text clipped - 4 lines] > >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. >> [quoted text clipped - 4 lines] >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. SignatureSpartanicus |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.