RE: [WSG] Space-saving Form Select vs Space-hungry HTML List
Dan wrote: What is the 'official' word on the use of form selects as an alternative to space hungry HTML lists? I would not even go think about using a form select for a menu, my experience has shown that most people ignore form selects. I inherited a web site many years ago that the main nav was in a form select. Over 50% of all users went from the home page straight to search. Replacing the form select with a list had dramatic results, basically an 75% reduction in the number of people who went to search straight after landing on the home page (ie just over 10% went home page search page, the remaining 90% went to other pages, and number of pages per visit increase). One surprise was the number of searches (it was a poor search engine) dropped from an average of 3 to 2 per visit to the search page. Nick This email is from the Department of Consumer and Employment Protection and any information or attachments to it may be confidential. If you are not the intended recipient, please reply mail to the sender informing them of the error and delete all copies from your computer system, including attachments and your reply email. As the information is confidential you must not disclose, copy or use it in any manner. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Space-saving Form Select vs Space-hungry HTML List
On 5/16/05, Nick Cowie [EMAIL PROTECTED] wrote: Dan wrote: What is the 'official' word on the use of form selects as an alternative to space hungry HTML lists? I would not even go think about using a form select for a menu, my experience has shown that most people ignore form selects. ... I can only second that. Use it only if list is reasonably big _and_ contains _known set_ of items (e.g. list of states, or months etc.) Regards, Rimantas -- http://rimantas.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Space-saving Form Select vs Space-hungry HTML List
Dan wrote: What is the 'official' word on the use of form selects as an alternative to space hungry HTML lists? I would avoid doing this for any kind of significant navigation as search engine spiders would not follow the navigation. I'm not sure how it would fare accessibility-wise either. -- Kay Smoljak http://kay.smoljak.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] search engine question
Hello, Do spiders crawl links in external javascript files, like the ones found in some dhtml menus? -kvnmcwebn ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
On Mon, 16 May 2005 01:58:23 +0100, Kvnmcwebn [EMAIL PROTECTED] wrote: Do spiders crawl links in external javascript files, like the ones found in some dhtml menus? No. You have to use good, accessible menu that uses links in HTML. See son of suckerfish dropdowns. -- regards, Kornel Lesiski ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
would those suckerfish dropdowns interfere with divs below them, ie push them down or anything. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
On Mon, 16 May 2005 02:59:32 +0100, Kvnmcwebn [EMAIL PROTECTED] wrote: would those suckerfish dropdowns interfere with divs below them, ie push them down or anything. No. Typical DHTML menus are HTML+CSS created and controlled by JS. Suckerfish dropdowns is HTML+CSS created by HTML and controlled by CSS. You get the same thing, but without need for JS support. Suckerfish actually uses a bit of JS to work around IE bug, but that's only for IE and other browsers and search engines don't need it. -- regards, Kornel Lesiski ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
Kornel Lesinski wrote: You have to use good, accessible menu that uses links in HTML. See son of suckerfish dropdowns. I'm not sure if CSS menus are really accessible. IMHO, they lack a timer, browser support is weak and most of them do not allow keyboard navigation. On top of that, if not well implemented, they can be totally inaccessible to IE users if scripts are disabled. FWIW, I'd go with a DHTML solution that degrades nicely. Thierry | http://www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
I guess theres pros and cons to both methods, Im leaning towards a dhtml menu that supports ns and ie 4+. but the links are in an external file, ugghh, I dont think it would degrade well but i suppose it woulnd have to with its browser support. I know what kornel is emphasizing is important as well...especially for us wsg people. heres the menu http://www.dynamicdrive.com/dynamicindex1/hvmenu/horizon.htm on 5/16/05 4:11 PM, Thierry Koblentz at [EMAIL PROTECTED] wrote: Kornel Lesinski wrote: You have to use good, accessible menu that uses links in HTML. See son of suckerfish dropdowns. I'm not sure if CSS menus are really accessible. IMHO, they lack a timer, browser support is weak and most of them do not allow keyboard navigation. On top of that, if not well implemented, they can be totally inaccessible to IE users if scripts are disabled. FWIW, I'd go with a DHTML solution that degrades nicely. Thierry | http://www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
Kvnmcwebn wrote: heres the menu http://www.dynamicdrive.com/dynamicindex1/hvmenu/horizon.htm Nice, but totally inaccessible without JS support. Check www.projectseven.com I believe most of their menus are fully accessible. It is important that without client script, the navigation fully expands. BTW, keeping this in mind, it may be better to go with a *vertical* flyout menu. Thierry | http://www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
Kvnmcwebn wrote: heres the menu http://www.dynamicdrive.com/dynamicindex1/hvmenu/horizon.htm This link is to show you that I'm not biased when I say you should favor a DHTML solution: http://www.tjkdesign.com/articles/dropdown/demo.asp ;-) Thierry | http://www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
On Mon, 16 May 2005 16:11:26 +0100, Thierry Koblentz [EMAIL PROTECTED] wrote: You have to use good, accessible menu that uses links in HTML. See son of suckerfish dropdowns. I'm not sure if CSS menus are really accessible. IMHO, they lack a timer, browser support is weak and most of them do not allow keyboard navigation. That's the same problem most JS menus have as well. On top of that, if not well implemented, they can be totally inaccessible to IE users if scripts are disabled. JS-based menu will fail as well, and not only in IE, but in other browsers. Having working, styled top-level items are IMHO best way such menu can degrade. Otherwise you may get something like few pages of unordered lists or spaghetti of links, which breaks page layout and isn't more usable. FWIW, I'd go with a DHTML solution that degrades nicely. But suckerfish dropdowns is DHTML solution that degrades nicely. You can get best of both worlds - extend CSS menu to have features of best JS menu. Add class to menu and make :hover work only on menu with that class. Then using JS remove that class and add mouseover/mouseout/focus handlers that implement closing delay, keyboard navigation, etc. -- regards, Kornel Lesiski ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
On Mon, 16 May 2005 04:01:09 +0100, Kvnmcwebn [EMAIL PROTECTED] wrote: I guess theres pros and cons to both methods, Im leaning towards a dhtml menu that supports ns and ie 4+. I'd avoid any non-trivial script that supports 4.x browsers. Scripts designed for those browsers often rely on browser sniffing and use outdated, non-standard DOMs and methods. When you write for modern browsers only, you may design your scripts much better. -- regards, Kornel Lesiski ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] search engine question
You may also be interested in this: http://udm4.com/ 1 html list (no excessively long, non-accessible navigation lists at top of page) + dhtml submenus. Without Javascript, you just get the top list. Appearance controlled by CSS. Well worth a look. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kornel Lesinski Sent: 16 May 2005 17:07 To: wsg@webstandardsgroup.org Subject: Re: [WSG] search engine question On Mon, 16 May 2005 16:11:26 +0100, Thierry Koblentz [EMAIL PROTECTED] wrote: You have to use good, accessible menu that uses links in HTML. See son of suckerfish dropdowns. I'm not sure if CSS menus are really accessible. IMHO, they lack a timer, browser support is weak and most of them do not allow keyboard navigation. That's the same problem most JS menus have as well. On top of that, if not well implemented, they can be totally inaccessible to IE users if scripts are disabled. JS-based menu will fail as well, and not only in IE, but in other browsers. Having working, styled top-level items are IMHO best way such menu can degrade. Otherwise you may get something like few pages of unordered lists or spaghetti of links, which breaks page layout and isn't more usable. FWIW, I'd go with a DHTML solution that degrades nicely. But suckerfish dropdowns is DHTML solution that degrades nicely. You can get best of both worlds - extend CSS menu to have features of best JS menu. Add class to menu and make :hover work only on menu with that class. Then using JS remove that class and add mouseover/mouseout/focus handlers that implement closing delay, keyboard navigation, etc. -- regards, Kornel Lesiski ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
Look im not 100% comfortable with the http://www.dynamicdrive.com/dynamicindex1/hvmenu/horizon.htm Unfortunately i've nearly run out of time on this project and must stick with what ive allready done. Unless you think im making a HUGE mistake by using this dhtml menu from, im going to leave it. I mean what are the percentages of users with scripting disabled-is it really going to come back and haunt me? I had started out with the original suckerfish dropdowns but abandoned them. I've only now became aware of the son of a suckerfish, as well as Thierry's method. frustrating. -Kvnmcwebn. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
Kornel Lesinski wrote: I'm not sure if CSS menus are really accessible. IMHO, they lack a timer, browser support is weak and most of them do not allow keyboard navigation. That's the same problem most JS menus have as well. That may be true for the bad ones, but not for quality JS menus. And I believe CSS offers no possibility re: a timer. There are workarounds, but they bring other issues. On top of that, if not well implemented, they can be totally inaccessible to IE users if scripts are disabled. JS-based menu will fail as well, and not only in IE, but in other browsers. I don't really agree. For example, the menu in my site is based on a projectseven's article. AFAIK, it degrades nicely in old browsers or in the ones with no script support. Having working, styled top-level items are IMHO best way such menu can degrade. Otherwise you may get something like few pages of unordered lists or spaghetti of links, which breaks page layout and isn't more usable. That's why I mentionned vertical flyouts vs. horizontal ones FWIW, I'd go with a DHTML solution that degrades nicely. But suckerfish dropdowns is DHTML solution that degrades nicely. You know what I mean, the suckerfish technique is not supposed to be a DHTML solution. And it degrades *only* if the top level items are actual links, which sometimes is not the wish of the designer. You can get best of both worlds - extend CSS menu to have features of best JS menu. Add class to menu and make :hover work only on menu with that class. Then using JS remove that class and add mouseover/mouseout/focus handlers that implement closing delay, keyboard navigation, etc. We agree on this. I believe that's what DHTML is, a bit of CSS with more JS ;-) Thierry | http://www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
Kvnmcwebn wrote: Unless you think im making a HUGE mistake by using this dhtml menu from, im going to leave it. IMHO, it is a HUGE mistake I mean what are the percentages of users with scripting disabled-is it really going to come back and haunt me? Did you check the source code? It is not only inaccessible to JS-challenged browsers, it is inaccessible to SE as well. If you need to go this route, make sure to plug some basic navigation links inside the noscript tag pair along with the warning you alreeady have in there. Thierry | http://www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
On Mon, 16 May 2005 05:06:43 +0100, Kvnmcwebn [EMAIL PROTECTED] wrote: Unless you think im making a HUGE mistake by using this dhtml menu from, im going to leave it. How huge mistake is having website seen by Google as Your browser does not support script message? I mean what are the percentages of users with scripting disabled-is it really going to come back and haunt me? 1-3% of users, 100% of search engines. -- regards, Kornel Lesiski ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] search engine question
Ongoing dialogue ... On Mon, 16 May 2005 05:06:43 +0100, Kvnmcwebn [EMAIL PROTECTED] wrote: Unless you think im making a HUGE mistake by using this dhtml menu from, im going to leave it. How huge mistake is having website seen by Google as Your browser does not support script message? I mean what are the percentages of users with scripting disabled-is it really going to come back and haunt me? 1-3% of users, 100% of search engines. There is no dropdown menu system which to my knowledge runs without JS DOM manipulation because of IE's lack of a CSS hover trigger. I obviate the JS dilemma by using noscript-tagged alternate menus, replicating the dropdown menu structures on http://www.seowebsitepromotion.com/. It's by no means a perfect menu system since it is not traversable via keyboard ... yet :o) I'm working on an accessible version as time permits but IE is proving challenging. Cheers, Mike Pepper Accessible Web Developer Internet SEO and Marketing Analyst http://www.seowebsitepromotion.com Administrator Guild of Accessible Web Designers [EMAIL PROTECTED] http://www.gawds.org ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Space-saving Form Select vs Space-hungry HTML List
Kay Smoljak wrote: I'm not sure how it would fare accessibility-wise either. Such jump menus can be accessible, if: - you use an actual form, with a submit button (or, at a stretch, a graphical input button) and a simple server-side redirector that takes the URL passed as the select's value and redirects to that location - you avoid using any kind of onchange behaviour on the select, as these get triggered as soon as a user browsing via keyboard starts to move down the list looking through the various items But yes, the issue of search engine spiders not seeing these links still remains. -- Patrick H. Lauke _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Any experiments with SMIL for menus? (was Re: [WSG] search engine question)
Thierry Koblentz wrote: Kornel Lesinski wrote: That's the same problem most JS menus have as well. That may be true for the bad ones, but not for quality JS menus. And I believe CSS offers no possibility re: a timer. There are workarounds, but they bring other issues. This is besides the point of answering the initial practical question, but have there been examples of using some of IE's HTML+TIME (or any other integration of HTML with something SMILish) for precisely this sort of effect? SMIL has simple ways of handling this sort of thing including with timers for menu deactivation that degrade very easily to browser that don't support it (and could probably have a script fallback for applicable cases). -- Robin Berjon ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
OK after all these comments im sold. But suckerfish dropdowns is DHTML solution that degrades nicely. You can get best of both worlds - extend CSS menu to have features of best JS menu. I'd avoid any non-trivial script that supports 4.x browsers. Scripts designed for those browsers often rely on browser sniffing and use outdated, non-standard DOMs and methods. When you write for modern browsers only, you may design your scripts much better. Nice, but totally inaccessible without JS support. Typical DHTML menus are HTML+CSS created and controlled by JS. Suckerfish dropdowns is HTML+CSS created by HTML and controlled by CSS. You get the same thing, but without need for JS support. Kvnmcwebn wrote: Unless you think im making a HUGE mistake by using this dhtml menu from, im going to leave it. IMHO, it is a HUGE mistake Well then im going to go for the son of a suckerfish and redoing everything. The only drawback(for me) is that the text size cant be fixed as in the js method i was using earlier. Thanks all ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] got a safari hack
Hello, Is there an equivelant to the underscore hack for safari out there? _kvnmcwebn ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
Kvnmcwebn wrote: The only drawback(for me) is that the text size cant be fixed as in the js method i was using earlier. Actually, that should be one more reason to stay away from that menu ;-) But check that menu in a different browser than IE, you'll see that text-size can always be increased/decreased. Thierry | http://www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: Any experiments with SMIL for menus? (was Re: [WSG] search engine question)
Robin Berjon wrote: SMIL has simple ways of handling this sort of thing including with timers for menu deactivation that degrade very easily to browser that don't support it (and could probably have a script fallback for applicable cases). To be honest, I think it's going a bit too far dragging out SMIL (or rather IE's incompatible HTML+TIME) for what is essentially something that can be achieved with just a touch of CSS and javascript. Native support for SMIL/HTML+TIME across browsers is quite bad, so it would be an exercise in futility, in my humble opinion... And yes, you can make something that degrades very easily with javascript off / css off as well. -- Patrick H. Lauke _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] mutli language websites
Hello WSG List Members, I am delveloping a website that can switch between english and itallian. I am wondering if I should be using en-GB or en-gb for my lang attributes and also for the meta http-equiv=Content-Language content=en-GB / are these attributes sensitive to casing? or should I just have en also is the charset iso-8859-1 OK for italian content? I would also appreciate any links to web standard sites using multiple languages? thanks in advance, Sam ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] mutli language websites
sam sherlock wrote: Hello WSG List Members, I am delveloping a website that can switch between english and itallian. I am wondering if I should be using en-GB or en-gb for my lang attributes and also for the meta http-equiv=Content-Language content=en-GB / are these attributes sensitive to casing? or should I just have en also is the charset iso-8859-1 OK for italian content? I would also appreciate any links to web standard sites using multiple languages? thanks in advance, Sam Does anyone use transparent content negotiation to handle multiple language sites? I get the feeling this is hardly ever used, if so, why not? Regards Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: Any experiments with SMIL for menus? (was Re: [WSG] search engine question)
Patrick H. Lauke wrote: Robin Berjon wrote: SMIL has simple ways of handling this sort of thing including with timers for menu deactivation that degrade very easily to browser that don't support it (and could probably have a script fallback for applicable cases). To be honest, I think it's going a bit too far dragging out SMIL (or rather IE's incompatible HTML+TIME) for what is essentially something that can be achieved with just a touch of CSS and javascript. As I said first thing in my post, I was not suggesting this as a practical solution, merely wondering if anyone knew of an example that had toyed with it. -- Robin Berjon ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] mutli language websites
Geoff Deering wrote: Does anyone use transparent content negotiation to handle multiple language sites? I get the feeling this is hardly ever used, if so, why not? The problem IME is that when you use it you have to also provide a way for the user to pick her language which will override the negotiation (I've been accessing the Web a lot from computers localized in Japanese recently, and they're probably not sending Accept-Language headers that reflect the reality of languages I can really accept :). It's not complicated to mix both together but the extra feature of negotiating the default language rarely seems worth it. -- Robin Berjon ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] mutli language websites
Robin Berjon wrote: Geoff Deering wrote: Does anyone use transparent content negotiation to handle multiple language sites? I get the feeling this is hardly ever used, if so, why not? The problem IME is that when you use it you have to also provide a way for the user to pick her language which will override the negotiation (I've been accessing the Web a lot from computers localized in Japanese recently, and they're probably not sending Accept-Language headers that reflect the reality of languages I can really "accept" :). It's not complicated to mix both together but the extra feature of negotiating the default language rarely seems worth it. I am using ip2couuntry class in PHP to decide the default lanuage. Thanks to Evandro who sent me a link to his site in Portugese and English. The site in question does not use the language attribute as inteneded (as far as I understand) all Lan attributes are set to en for Portugese, Itallian and English. What is the web standards best practise for multi-lingual sites Should I use en or en-GB is the casing important? What charset should I use for the Itallian version the same as english or other? Are the any link available to webstandard best practise examples? many thanks SS
Re: [WSG] mutli language websites
Robin Berjon wrote: The problem IME is that when you use it you have to also provide a way for the user to pick her language which will override the negotiation (I've been accessing the Web a lot from computers localized in Japanese recently, and they're probably not sending Accept-Language headers that reflect the reality of languages I can really accept :). It's not complicated to mix both together but the extra feature of negotiating the default language rarely seems worth it. Yes, these are some of the problems I would have expected using this approach. Let alone if you are in some other country, in a net cafe and it is defaulting to another language, as what often happens with Google, which can be annoying for the user. Regards Geoff D ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] mutli language websites
sam sherlock wrote: I am using ip2couuntry class in PHP to decide the default lanuage. Thanks to Evandro who sent me a link to his site in Portugese and English. The site in question does not use the language attribute as inteneded (as far as I understand) all Lan attributes are set to en for Portugese, Itallian and English. What is the web standards best practise for multi-lingual sites 1. Should I use en or en-GB is the casing important? 2. What charset should I use for the Itallian version the same as english or other? 3. Are the any link available to webstandard best practise examples? Maybe you will find some of the info you are looking for here http://www.w3.org/International/geo/html-tech/resources/ G ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] mutli language websites
sam sherlock wrote: I would also appreciate any links to web standard sites using multiple languages? Still doing some under-the-hood work on this one to bring it up to speed, but you can check out http://www.liveinvictoria.vic.gov.au/ to see the site I was pestering the list about a month or so back (thread starts here: http://www.mail-archive.com/wsg@webstandardsgroup.org/msg16198.html) Not all pages have multiple languages, but some have translations of the English in both Traditional and Simplified Chinese. Preferred language can be selected in the RH column. I used UTF-8 Cheers Lachlan ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] search engine question
You might would like to have a look at this accessible drop-down-menu: http://www.brothercake.com/dropdown/ Good luck, John S. Britsios Accessibility SEO Consultant, Usability Specialist Trainer Webnauts Net Koblenzer Str. 37a D-33613 Bielefeld Germany, Europe Telephone: (+49) 0521 - 305 10 20 Cellular: (+49) 0163 - 202 55 61 Email: [EMAIL PROTECTED] Homepage: http://www.webnauts.net Open Directory: http://www.webnauts.net/directory/ Discussion Forums: http://www.webnauts.net/phpBB2/ User Interface Usability Checklist: http://www.webnauts.net/user-interface-usability-checklist.html Designing Optimizing Web Sites with Accessibility, Search Engines Usability in Mind - Original Message - From: Kvnmcwebn [EMAIL PROTECTED] To: wsg wsg@webstandardsgroup.org Sent: Monday, May 16, 2005 2:58 AM Subject: [WSG] search engine question Hello, Do spiders crawl links in external javascript files, like the ones found in some dhtml menus? -kvnmcwebn ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] mutli language websites
sam sherlock wrote: I am using ip2couuntry class in PHP to decide the default lanuage. I don't know if this is the greatest feature - definitely not in Canada where I live. Since the country has two official languages [english and french], it would still requires an "evil", but necessary splash page to select your language (unless you want them to search for the language toogle link). All gouvernment websites that I know of have a language page as a well as a method to toggle between both languages. Should I use en or en-GB is the casing important? "EN" should be just fine and according to my notes it is *not* case-sensitive. What charset should I use for the Itallian version the same as english or other? Why not use UTF-8 which supports nearly all languages [if not all] I can think of. For example, ColdFuion uses UTF-8 as the default charset for HTML as well as source code unless otherwise set. Best, .Peter -- Peter J. Farrell :: Maestro Publishing blog :: http://blog.maestropublishing.com email :: [EMAIL PROTECTED] Create boilerplate beans! Check out the Mach-II Bean Creator - free download. http://blog.maestropublishing.com/mach-ii_beaner.htm If you only knew the power of the Dark Side --
