Re: [WSG] Google chrome... Coming very soon...
I found out that the download server doesn't like download managers... got the file twice - apparently intact and sane, but wouldn't run - with Download Express. The same file downloaded the old and tested way (same filesize and all) worked fine. Hope this helps. djn Paul Collins wrote: > Anyone else getting an initialisation error when I try to run the > browser?! I've tried to install twice. Maybe it's to do with the proxy, > but the message says "The application failed to initialize properly, > click OK to terminate" when I start it up. -- ----- Dejan Kozina Web design studio Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] SEO, fact or fiction and myths
Nice to hear again about PICS. I use to label all my websites, but I've ofter wondered if I'm the last one using this (and P3P...). djn Mike at Green-Beast.com wrote: That seems incredibly arbitrary when a robots.txt is purely optional - especially as the default spider behavior is to index all unless told otherwise. So you're penalizing people by having your robot behave in the opposite manner? And regarding PICS labels, most people don't know how to set them or don't have the requisite server access. How do you justify these? John, We don't necessarily penalize for not having one, we just credit for having one (offering one is not part of our criteria [1]). It's something we like to see. For the reasons I stated: we grade a site on many levels, and we see that providing a robots.txt as a positive thing that helps make a site/domain complete. Same with a PICS label, it's not a requirement, though I believe a PICS label can actually help with access in that some schools districts won't allow network access to site that doesn't claim to be appropriate for the level of the students the system serves. Regarding "requisite server access" I don't understand. The PICS label is put into the head of the document. If a developer doesn't understand how to get a PICS label or can't add one to the head and don't have access to such, I doubt they'd be submitting a site for possible awarding. But, regardless, the main point of my reply was to clarify that the robots.txt file has no bearing on the site's accessibility (that I'm aware of) and that's it's just one of the many things we look for in a quality submission. Cheers. Mike [1] http://accessites.org/site/criteria/ -- - Dejan Kozina Web design studio Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] SEO, fact or fiction
I believe you got it somewhat wrong. The basic purpose of a robots.txt file is to tell a search engine what not to index - and you can issue different instructions to each robot separately. It does not tell the robots which pages to index, except for the basic tenet that anything not explicitly forbidden is fair game. The very purpose of a sitemap is to list every page in a site you want indexed - handy when some pages are difficult to reach just following links (this shouldn't happen, but in the real world sometimes it does). You can also tell the search engine how often do you expect a page to be updated and which pages you deem more important than the rest. Search engines may or may not care. In plain-speak: if you list a page in your sitemap, but robots.txt says (either to all bots or a specific one) to stay away from it, it won't be indexed; conversely, if you do not list a page in the sitemap, but the robot finds it out some other way (say, following a link either on your site or somebody's else) it will be indexed unless robots.txt forbids it. Robots.txt and sitemaps are thus in different lines of business and you may as well make good use of both even if neither is - strictly speaking - "needed". You may omit a robots.txt if you're OK with everything on the site being indexed; you may omit the sitemap if the site has a simple strutcure with all pages cross-linked. The only relation between the two, according to sitemap.org, is that you may use robots.txt for autodiscovery of the sitemap: the Big Three search engines have agreed on a convention to look into the file for the position of the sitemap. djn tee wrote: On Mar 7, 2008, at 12:36 AM, Stuart Foulstone wrote: Hi, Search robots are essentially blind users. Anybody knows about this? The robots text is good for search robots, but I read from somewhere, that robots text no longer is needed when Google Sitemap is implemented for the site. I didn't know robots text was important for accessibility, however I learned from the accessites team that it is. Thanks! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- --------- Dejan Kozina Web design studio Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hello all again. I just got curious and went on to test that .htaccess trick in the real world. I'd say that I'm less than happy with the results. With Thunderbird as the default mail app on Windows XP SP2, IE7, Firefox 2.0.0.7 and Seamonkey 1.1.4 did indeed open a new message window with the correct addressee in the To: field. The main browser window, in meantime, went to a blank page in IE and a "Found - The document has moved here." page in Gecko browsers. The design part of my soul cried thinking at website visitors landing there after clicking a link... Even worse, both Opera 9.23 and Safari 3.0.3 failed to open a message compo window. Opera just hanged there spinning a 'busy' cursor, while Safari informed me that »The page you opened redirected you to a page that isn’t supported by Safari. Safari can’t open the page “http://www.kozina.com/mailtest/example/com/me” because it cannot redirect to locations starting with “http:”.« I guess there is a 'not' missing somewhere. Anybody (Mac & Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. djn -- --------- Dejan Kozina Web design studio Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hello list. This is what I use in my Smarty templates:
{ #email#|escape:"hexentity" }
With this, [EMAIL PROTECTED] becomes:
mailto:%6d%65%40%6d%65%2e%63%6f%6d";>
me@me.com
It's not foolproof, but my customers are generally happy with the result.
This other trick I haven't tried yet, but sure sounds good to me:
http://www.htaccesselite.com/htaccess/use-htaccess-to-hide-mailto-links-vt181.html
I posted about this on the WebAIM list back in February and nobody seems
to have found objections to it, accessibility-wise.
djn
Rick Lecoat wrote:
> can anyone tell me what is the best accessible way (if any) of encoding
> a mailto: link? I want to make the email addresses on a site usable to
> screen reader users, but don't want them harvested by spambots.
>
--
-----
Dejan Kozina Web design studio
Dolina 346 (TS) - I-34018 Italy
tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina
http://www.kozina.com/ - e-mail: [EMAIL PROTECTED]
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Mobiles and standards
You may find a lot of real-world info here: http://tech.groups.yahoo.com/group/wmlprogramming/ It might not be to everyone's taste, as the group is often critical of the W3C and its mobile efforts, perceived as choosing theoretical constructs over what real handsets are out there in the wild... Katrina wrote: W3C standards (HTML4 or XHTML 1.0) or other (XHTML-Basic, XHTML-MP, WML, HDML) ? HTML4 and XHTML1.0 are safe only for the newest handsets with enough power to run Safari or Opera. XHTML-Basic is a W3C standard few use - see next. XHTML-MP is XHTML-Basic with some extension coming from the browser makers (Netscape extensions anyone :-)?) and is the de facto "safe" standard for new handsets. HDML has died a quiet death sometime in the previous century; don't bother. WML is the fallback standard every handset (bar those based on i-mode) more or less supports if nothing else works, and the only one you can rely on for scripting support (via WMLScript). I-mode handsets require CHTML, which is a heavily tweaked son of HTML 3.2 and is supposed to converge toward XHTML-MP (nobody seems much in a hurry, anyway). Can mobile devices process CSS 2.1 or less when served as media="handheld"? You just can't rely on it. Some do, some do not and some make a mess of it. Mobile IE has a longstanding tradition of applying both the screen stylesheets and the handheld ones. Do mobile devices that handle XHTML need a particular mime type (eg. text/html, text/xml, application/xhtml + xml, application/xml ? This comes straight from the Wireless FAQ (http://www.thewirelessfaq.com/): Plain WML documents text/vnd.wap.wml.wml Wireless Bitmap Images image/vnd.wap.wbmp .wbmp Compiled WML documents application/vnd.wap.wmlc.wmlc WMLScripts text/vnd.wap.wmlscript .wmls Compiled WML Scriptsapplication/vnd.wap.wmlscriptc .wmlsc XHTML Basic application/xhtml+xml .xhtml XHTML-MPapplication/vnd.wap.xhtml+xml .xhtml and yes, mobile browser can be picky about it. NB. I am very tempted to side with the W3C XHTML 1.0 Strict and serve that up to everybody regardless of type of device (although admitting to device dependence within the CSS using mediatypes). But, in so doing, do I then snub a large percentage of mobile devices? Yes, definitely. You'd be leaving out: 1. old handsets; 2. cheap and less powerful handsets without the steam to run a desktop-derived browser; 3. Nokia users who choose wrong between a heavy 'proper' browser and the lighter 'WML' one (some handsets have more than one browser)... If mime type is important for mobile devices and it is different from text/html, does content negotiation assist in solving this problem? WURFL has been around for some time now (http://wurfl.sourceforge.net/ and http://wurfl.sourceforge.net/faq.php) For a starter I'd suggest you take a look at this: http://www.passani.it/gap/ Least I can say, it's well written (W3C, take note)... djn -- - Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] WCAG 2.0
Hi all. This one didn't make it to the Reccomended readings, but it seems well worth to me: http://accessites.org/site/2007/05/wcag2-woeful-to-wonderful-in-one-easy-draft/ djn -- - Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Best Practices: Specifying Language
This one just came in via the W3C newsfeed: "Internationalization Best Practices: Specifying Language in XHTML & HTML Content" http://www.w3.org/TR/2007/NOTE-i18n-html-tech-lang-20070412/ A well done "human readable" note on where, how and why embed langauge information in documents. djn -- ----- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] best standard / format for imbeded mp3 player in browser
I found this recently: http://musicplayer.sourceforge.net/ It seems solid (to me, at least). djn BKDesign Solutions wrote: http://www.jeroenwijering.com/?item=Flash_MP3_Player -- - Dejan Kozina Web design studio Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] maximum backward compartible to mobile phone (WAP) users? Which XHTML DTD?
I fear not, I have to admit. Mostly, I've been following the mailing list for the last year or so and, while nobody states this explicitly (most of the messages are about server config issues for the WALL thing), everybody with a live site seems to talk and behave like this was the case. Server stats are rarely on the forefront, and even then the assumption seems to be that they're not to be extrapolated and make sense only for their geographic area and a narrow set of phone companies. The phone model is, to all practical effects, used as an alias for the phone/browser combo. Further, I've gone at some depth into that XML capabilities file, where the User Agent string is the variable you query to retrieve the phone/browser combo details. User agent strings almost always consist of a manufacturer's brand/model/version string followed by the browser string. Now, almost all phone models are present with a single entry, while some popular phones present with different browsers seems rather the case when phone companies buy handsets in bulk and add (personalize) a browser of their choice (recognizable because they add their name in front of the string). My (personal and unsupported) view on all this is that end users just don't care to have the latest and greatest browser 'cause they see the whole mobile web experience as secondary to their desktop browsing (something just like me checking mozilla.org often, while upgrading Linx once a year at best, if at all). djn Jon Tan wrote: Dejan Kozina wrote: [...] phone owners just do not upgrade their browsers. They're far more likely to buy a new phone that to mess with the handset's preinstalled software. [...] Very interesting and informative reply Dejan, thank you. We've been discussing mobile content publishing for (ironically) a mobile phone provider to deliver content to their own employees - the user behaviour you describe sounds reasonable but if you have any data to support your statement could you let me know? I'm particularly interested in Opera downloads or usage where Opera is not the default device browser. Thanks Jon Tan www.gr0w.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 ****** -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] maximum backward compartible to mobile phone (WAP) users? Which XHTML DTD?
Andrey, the mobile phone browsers are a hard nut to crack. I've just researched this for an upcoming project, so let me summarize the field: 1. WML phones understand only WML, either served natively from the webserver (with the proper MIME type) or as converted from (X)HTML by their provider's WAP Gateway (WAP phones do not speak HTTP, they connect to the gateway via the WAP protocol and the gateway takes care of the HTTP leg). Scripting only via WMLScript, an ECMAScript based scripting language (AFAIK, gateways don't even try to convert Javascript). No CSS. Images only in WBMP (wireless bitmap) 2-bit format (pixels are black or white, forget about greyscale, much less color). Gateways do convert common image formats. Very narrow limits of page (called deck) size (the stinkiest on record accepted no more than 8.192 bytes per page, images included). Development stopped long ago. 2. 'imode' phones (popular in Japan, some diffusion in Europe and stateside) understand cHTML (compact HTML), also called i-html, which is a subset of HTML 3.2. Browsers are known to crash if served proper HTML or XHTML (e.g.: closing your LIs is all but guaranteed to send the browser into a spin). No scripting, no CSS. GIFs are okay (but there are limits on filesize, for animations limits on loops too). JPEGs only on newer phones, sometimes FlashLite. Java MIDlets on all models but the oldest. Will converge on XHTML MP in the future, but have still a long way to go. 3. XHTML Basic just went nowhere, 'cause the browser makers found it too basic and extended it into: 4. XHTML MP (Mobile Profile), which is the current baseline standard. 'Should' have no problem with most of XHTML, a limited subset of CSS (missing mostly what would be most useful, like floats), no scripting. GIFs and JPEGs are common, PNGs only on newer models. All XHTML MP browsers understand WML too (so if you absolutely need scripting you can link to a separate WML page with a WMLScript). Differences between browsers are way greater than anything in the desktop world (think Firefox vs. Netscape 3). There are sporadic cases of TinySVG and FlashLite support, but don't rely on this. Java MIDlets are generally supported. 4½. A long time ago there was a half-offline format for Palm Pilots too, using a proprietary network linked to the Net. The whole show has been disbanded since. 5. Finally, some high-end phones have a proper web browser (namely, Opera 8) and can do with everydays web pages. A future Nokia phone will come with a browser based on khtml (Safari). Windows CE based palmtops come with Mobile Internet Explorer, which (who would have guessed?) makes a mess of CSS media types and applies both the screen stylesheet and the handheld one. Such support for ordinary web pages is therefore expected ti increase with time. Another hitch: phone owners just do not upgrade their browsers. They're far more likely to buy a new phone that to mess with the handset's preinstalled software. The best solution I've found up to now is WURFL (http://wurfl.sourceforge.net), which is an open source effort to build a database of mobile phone characteristics, downloadable as a XML file (couple thousands user agents in it). Tools for data retrieval are available for Java, Perl, PHP, Ruby, Python and others. There is a (fairly technical) mailing list at http://groups.yahoo.com/group/wmlprogramming. Most of the list contibutors seems to use WALL (http://wurfl.sourceforge.net/java/wall.php), a Java/JSP taglib that (if I got it right) lets you use in your pages stuff like http://url"; title="title">link and converts on the fly to the browser's preferred markup (reading the user agent and quering the XML file with it). There is a PHP version at http://laacz.lv/dev/Wall/ . A final note: nobody seems to know how many (or if somebody at all) really uses to browse via mobile. Some 6 months ago the british BBC (which maintais a wireless version of their news site) published detailed stats of the browsers visiting them. It went down in detail tallying even WebTV and PSP visitors, but there were no recognizable phone browsers at all. We all might be just chasing our wishful dreams on that front. djn -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] parse error
Lori Cole wrote: > http://members.cox.net/loricole/Week4a.html > Also, when the CSS validator asks for a background color in the > instances I have left it out, if I assign it as white then the > backgrounds interfere with the background logo. The validator is right when saying 'too many values'. What you're trying to do is either: background: white url(WCLogo.gif) center no-repeat; or background-color: white; background-image: url(WCLogo.gif); background-position: center; background-repeat: no-repeat; > Then, I have no idea what to do about the border warnings and would The validator warnings are not errors, they're there just to be sure you really wanted to to that (and not everybody finds them useful at all...). You can just let them be. djn -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] BOM and charset declaration in CSS
I do use @charset (utf-8); even if it actually serves no purpose: some time ago I've put it in my default CSS template file and never cared about it anymore... You can safely remove the BOM from any utf-8 document, as it serves no purpose: http://www.unicode.org/faq/utf_bom.html#29. If your Unicode text editor doesn't allow to save your file without it, just open the file in a plain text editor and delete the first two characters: it won't mess the remaining text. djn Gene Falck wrote: Hi Paul and Russ, Paul wrote: And how do you get around the UTF-8 signature or byte order mark (BOM) that some editors add to the document? I see you already have some replies on this BOM bit. For looking over your file format (and also simply deleting the BOM) you might also try a utility like XVI32.exe which displays your file character by character along side the hex values. Anything that your editor puts before the DOCTYPE will put you into quirks mode so the BOM (and anything else the editor inserted at the beginning of the file) can and probably should be deleted. I like XVI32 a lot because I don't have a lot of files to run in batch and I was curious what was happening. Regards, Gene Falck [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ****** -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] BOM and charset declaration in CSS
I do use @charset (utf-8); even if it actually serves no purpose: some time ago I've put it in my default CSS template file and never cared about it anymore... You can safely remove the BOM from any utf-8 document, as it serves no purpose: http://www.unicode.org/faq/utf_bom.html#29. If your Unicode text editor doesn't allow to save your file without it, just open the file in a plain text editor and delete the first two characters: it won't mess the remaining text. djn Gene Falck wrote: Hi Paul and Russ, Paul wrote: And how do you get around the UTF-8 signature or byte order mark (BOM) that some editors add to the document? I see you already have some replies on this BOM bit. For looking over your file format (and also simply deleting the BOM) you might also try a utility like XVI32.exe which displays your file character by character along side the hex values. Anything that your editor puts before the DOCTYPE will put you into quirks mode so the BOM (and anything else the editor inserted at the beginning of the file) can and probably should be deleted. I like XVI32 a lot because I don't have a lot of files to run in batch and I was curious what was happening. Regards, Gene Falck [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ****** -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] jump menu method
No, you're right and it seems that I'm much dumber than that. The form uses POST indeed, but I managed to hide some link in a div with display: none to help the bots around my Java-only navigation (yes, it was that long ago; probably the very first CSS I wrote!)and, of course, one of those pointed straight to the receiving script... djn (hiding in shame...) Mark Stanton wrote: You must have been using GET rather than POST.Spider's won't submit forms that us POST, but they have every right to follow forms that use GET. -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] jump menu method
Just a quick correction to a previous message: searchbots DO submit HTML forms. Years ago I wrote a contact form (no javascript involved) with a PHP script sending mail to myself and didn't care to check if any user input was actually submitted, so now I know every time a bot passes by because I get an email with empty placeholders only. djn Terrence Wood wrote: Search engines don't submit forms -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 ** 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] firefox for OS9?
This page should be it: http://browser.netscape.com/ns8/download/archive70x.jsp Kay Smoljak wrote: On 8/6/05, Drake, Ted C. <[EMAIL PROTECTED]> wrote: Sorry for a possibly off-topic post. We have a client on our intranet that needs to look at our site on OS9.2. I couldn't find information on the Firefox web site about compatibility with this platform. Does anyone know where I could send this person for more advice? I had a client with OS9 who were using Netscape 4 (!), and I got them to upgrade to Netscape 7. The later builds don't support OS9, but earlier ones do, so if you look around you should be able to find one. -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] Need help with centering and then some
This is what you're looking for: http://www.alistapart.com/articles/flashsatay/ Tom Livingston wrote: only errors left involve the tags and I don't know how to make the Validator happy with it. djn -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] Encoding, charsets and entities...
Hi Roberto.
As long as you can input the characters directly utf-8 is a big
time-saver. It makes for more readable code to boot. Since the demise of
NN4 it is supported on all browsers around.
If you use a web-based form to submit content and the page is declared
as utf-8, you can copy and paste at will into the form and the browser
will be happy to take care of the conversion. Beats writing pagefuls of
&#xxx; any time.
The first place a browser should look for the encoding declaration are
the HTTP headers sent before the document itself ('Content-Type:
text/html (or whatever);charset=utf-8'). If you're using Apache you may
add a 'AddDefaultCharset utf-8' to your .htaccess.
The encoding declaration in the XML prolog is required only if you use
an encoding that's not utf-8 or utf-16. XHTML documents default to utf-8
if not otherwise specified, while HTML (4.01) documents have no default
charset.
You may want to declare the charset inside the document too (with http-equiv>), just in case somebody saves it to the disk.
Roberto Gorjão wrote:
Hi,
I’m trying to understand the pros and cons of different charset
encodings and I would like to know what your experience tells you about
this subject, notably:
* Unicode encoding (UTF-8) seems to be more efficient than ISO
charsets (iso-8859-1): It covers all the languages in a single
encoding; it’s universal (or at least getting to be); it’s
compatible with ASCII; some argue even that it’s quicker… Are
there any drawbacks? Does the fact that the characters Unicode may
have different sizes affect string calculus with JavaScript?
String lengths, character position retrieval and so on?
* Where does the use of UTF leaves us regarding to entities? Some
say that we don’t have to worry anymore with coding currency
symbols or accented letters… Is that true? (I really did never pay
much attention to this matter and get used to see Dreamweaver code
automatically all accented letters that I insert in the design tab
(that’s almost the only reason why I use the design tab nowadays…)
but I think I would convert myself definitely to a much cheaper
software if even this functionality turns out to be useless). And
what about quotation marks and less than and greater than signs?
They seem to validate all right when inserted directly on the code
without any kind of special entities coding.
* Which is the best way to declare it? I’ve noticed that
webstandardsgroup.org page declares it only in the XML “prolog”
and does not use any meta tag to do it as does for instance the
Unicode.org page.
Thank you.
Roberto
--
Dejan Kozina
Dolina 346 (TS) - I-34018 Italy
tel./fax: +39 040 228 436 - cell.: +39 348 7355 225
http://www.kozina.com/ - e-mail: [EMAIL PROTECTED]
**
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] I18n - Traditional & Simplified Chinese in an English web site
True, those ugly squares are a real risk on any non-Unicode OS (Windows up to ME, MacOS up to 9), which tipically came with fonts only for their native codepage. Let's try again. I tend to have strange ideas when working late at night, so if any of the following is wrong, non-standard or just plainly dumb, I beg your pardon in advance. Assumptions: â it has to be done with valid HTML only; â it must comply with the acessibility guidelines; â it must understandably (i.e. verbosely) explain the font issue; â every 'visual' browser can at least display ASCII; â you have enough space for a 100x25px image. For readability's sake I'll think of an English page with a graphical link to its Chinese equivalent (I'm ignoring on purpose the difference between a language and the writing system it uses) as seen by a desktop browser with images on and no usable Chinese font, the same browser with images off, a text-only browser and a screereader. 1)For desktop browsers without a proper font for Han and images on I'd make an image with "Chinese version" in both writings, as in: a) layer 1: the background; layer 2:an English "Chinese" contrasting with the background; layer 3: its Han equivalent with a degree of transparency, so that both written layers are readable or at least recognizable even if overlapping; or b) an animated GIF showing the English text in one frame and the Chinese text in the next (nowadays every browser with images on can display a GIF89a). 2)A desktop browser with images off and a text-only browser would be (relatively) happy with this code: as long as the alt and title attributes contain an explanation of the font issue. Alas, a screen-reader expects, and the accessibility guidelines require, any change in language to be properly marked up, and we can't mix languages inside the same element. So this is what I thought up (think Rube Goldberg): 3) This is basically an image map with an unusual, but valid sintax for clickable zones. The image's alt attribute is empty because the image contains no additional information besides what's in the related map element. I might have used two plain old area elements, but the hreflang attribute is not allowed there. The real world value of hreflang is zero or thereabout (no support that I know of), but it's still required in WCAG. HTML 4.01 allows for hreflang in links only, and those are allowed in maps if contained in block-level content, so what we have here are two overlapping clickable areas (with the same target)within an image, each with its title 'tooltip' in the same language as inherited from the containig block element, all this without requiring lots of screen estate (adjust the image size to what you have available, the 'tooltips' will take care of themselves). Again, sorry if there's something amiss in these night ramblings. The nearest coffee is still hours away... djn Lachlan Hardy wrote: Well, this will teach me not to send messages to the list without proper sleep. I'll try and explain the situation a bit better: The Chinese (both Traditional and Simplified) was encoded in UTF-8 and is displayed as UTF-8. It shows up fine for me in Firefox. It shows up fine in IE, if the code specifies the change of language. It shows only blocks in IE if simply inputted without particular language specification. I have not installed language packs etc, but I'm not fussed about that. My testing shows that the Chinese will work fine for those who want to see it My concern (and that of my client) is for those people who do not have Chinese (of either variety) installed on their machine and don't want to. If an typical user comes upon a section of the page that doesn't display in readable fashion, their assumption is likely to be that the site does not work. It is always my fault, not theirs. I'm attempting to find a way around that Currently, main content pages in Chinese contain a special blurb in English to explain that this is a Chinese page, how to see it if they want to and provide a link back to the English version in case they don't. I need to be able to either explain to users that the unreadable (for them) content is Chinese, or show it as Chinese consistently Hopefully, that is a bit clearer, seeing as I've had some coffee now Cheers, Lachlan -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] I18n - Traditional & Simplified Chinese in an English web site
Not sure, but I'll try: with the image saying something like Chinese version. Now, if your design allows for a little padding of the you'd have the English title shortly displayed before the mouse hovers on the image, so those without a proper font can roll back their mouse to the link when their browser fails to display the alt text. Lachlan Hardy wrote: G'day folks! A query for those with some experience in using multiple languages in their sites: In a site that is predominantly English, select pages have been translated into both Simplified and Traditional Chinese. Each page contains a link where users are able to indicate their preferred language (hence receiving translated pages as appropriate). My issue is how to show this this link appropriately Originally I had something similar to this: çääæ (don't know this will come out in email, but the contents of the anchor and its title attribute are Simplified Chinese) However, this fails as on many computers it will appear as those horrible little blocks that indicate lack of the appropriate font Next attempt was something like: src="#" alt="Most pages will display in English, only translated pages display in Simplified Chinese. éæ åïåæéééåçèæéèïäåæåèééæäçääææç" title="When selected, most pages will be in readable in English with only translated pages displaying in Simplified Chinese. éæ åïåæéééåçèæéèïäåæåèééæäçääææç"> Except of course, that doesn't give any indication of language involved. Suggestions, experiences, vague clues? 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 ****** -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] Other character sets/languages
Gene Falck wrote: Do you suppose Microsoft fixed Notepad when they coded Windows XP? Yes, it's pretty safe to assume that enhancements to Notepad do not get their own press release ... AFAIK, **all** my files are missing the http headers Correct, http headers are only sent by a web server. That said, installing Apache on Windows is quite simple, as long as you have an administrator account. Download it from http://www.apache.org/dyn/closer.cgi/httpd/binaries/win32/ (choose the apache_1.3.33-win32-x86-no_src.msi file), launch the installer, supply a domain name (localhost is a safe choice), a (whichever) email address and you are ready to go. Start the server, point your browser to http://localhost and a welcome page will appear. If you go to Apache's htdocs subdirectory, throw away any content and put your files there, refreshing your browser will display your very own index.htm. That's more or less all. Keep the installer for when you're going to uninstall Apache. To check the http headers you can download the standalone ViewHead from http://www.pc-tools.net/win32/viewhead, or install a Mozilla extension from http://livehttpheaders.mozdev.org (after installing and restarting the browser, rightclick, select View Page Info and then the Headers tab). After a while, you'll feel ready to play with the various config options. These are stored in a textfile called httpd.conf in Apache's conf subdirectory. Follow the instructions within the file, restart the server to apply the changes and have fun. Almost everything that works on Windows will work the same way on a Linux/Unix web server, so you may safely test at home before applying to a production server. Should you need more instructions, a default install will put a lot of useful content at http://localhost/manual. djn -- Dejan Kozina Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] ** 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] Other character sets/languages
Well, http://www.w3.org/International/technique-index#language I guess. djn Richard Ishida wrote: http://localhost/International/technique-index#language begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Other character sets/languages
Richard Ishida wrote: In any case you should always finish a font-family declaration with 'serif' or 'sans-serif' in this situation. Then if none of the fonts you indicated are on the user's system, a font that they do have will be used. Good point. Lesson learned: I really shouldn't write heady stuff before sunrise and a fair serving of coffee. What I had in mind was rather the case (admittedly rare, but happened to me) when a non-Unicode font has the same name as a Unicode one. The culprit in my case was Georgia with CE characters, back then when W2k was brand new. Made a website assuming every Georgia has the full set of Latin glyphs, while my customer had an Italian Win98 supplied with a Win-1252 Georgia... Still hate those empty squares. Researching the user base is something I find iffy anyway. Every once in a while there is a thread trying to find a safe sequence of fonts usable both on Windows and MacOS, and it ends up with a boatload of different typefaces, plus assorted arguments about display details. Directly asking a vietnamese designer might be more straightforward. Anyway, my suggestion should be more correctly amended to: 'use a generic font-family and let the browser help itself, rather than risk a miss trying to overdesign the appearance'. djn begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Other character sets/languages
Hi Gene, You wrote: the chance to select the "Encoding:" is next below that True. Windows started using Unicode as of Win2K. I was surprised indeed to find the Unicode option in Win98's Wordpad. I was surprised again today when opening in Unired a file saved as 'Unicode text' with Wordpad. Unired said it was no utf-8, it was utf-16 (Little Endian) instead, so sending it as utf-8 would be incorrect, even if Mozilla seemed not to care that much. I thought nothing of the fact that I have not seen such a result in IE6 and Mozilla 1.7. Mozilla 1.7.5 still proudly displays an ugly BOM, IE doesn't. All of my efforts, so far, are stand-alone and intranet applications, so I don't know what to expect from actually having the file on a true server situation accessed from the Internet. As long as you have a web server on your intranet it shouldn't do any difference to the browser, it's just documents coming from the network. It's files from your disk that will miss the http headers. Urk! Fortunately, my files are English-language with a few &#... codes for "proper" typographic punctuation and some characters in names This works, but after a few characters it just becomes tiring ... One thing I've just thought of. The final hurdle in letting the world see vietnamese text is hoping that the visitor's browser has a font capable of displaying the text. There is not much you can do if it doesn't, but if it has one you should allow the browser to choose it avoiding to declare a font-family for that part of the page. djn begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Other character sets/languages
Gene wrote: I usually code using > Notepad which offers, from the Save As... menu choice, > the Encoding options: I'm not really sure, as the Notepad I got with Win98 doesn't offer anything but 'text file' and 'all files'(Win98 doesn't do Unicode). What you can try is to save the page as utf-8, open it in Mozilla/Firefox and check the very first characters displayed. If there is no strange character there you know it's OK. I just tried the same trick with good old Wordpad (which has an Unicode option even with W98) and it saved my test file without the BOM. > Is saving a > file as UTF-8 compatible with the iso-8859-1 meta tag? I'm not sure why would you want to do this, but here goes some reasoning on general principles. As long as the file is saved as uft-8 it contains the correctly encoded content and it's up to the browser to display it accordingly. Now, the primary source of encoding declaration for the browser is the HTTP header sent by the server along the document (this is the .htaccess stuff I mentioned), which should override every other directive, including the meta declaration. Thus, the browser should choose the correct encoding and display both the english and the vietnamese text. I don't recall anybody really testing browsers with that stuff, so you may be in for unexpected results here: if the browser ignores the rule and chooses to believe the meta directive instead of the header, it would display correctly the english part, but the vietnamese one would be a sequence of empty squares, question marks and/or best-guess ISO-8859-1 characters (two for every Unicode one). As too much things web-related, 'should' is a iffy thing to rely upon. More, if somebody saves that page to the disk and looks at it later, the only source of encoding information would be the meta stuff, with the same result as above... More generally, inputing characters not native to my keyboard/OS is to me the most annoying part of it all (I routinely have to input central-european stuff by switching the keyboard layout, meaning I had to remember which key becomes which). If you have the luck to get your content already typed, copy/paste is much more error-proof than the alternatives. djn begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Other character sets/languages
woric wrote: Choose charset UTF-8 (not UTF-8 BOM) when saving. Can you explain the difference? In other words, the BOM is a "funny character" Unicode uses as the very first char in some of its encoding forms to declare which byte is which when characters are composed of more than 1 byte. As stated by the Unicode consortium itself, utf-8 does not need this, so the mark can be safely ignored when creating a utf-8 document (you can even delete it from an existing document without consequences). Using the BOM in a utf-8 webpage would have two unhappy outcomes: Gecko-based browsers would display the thing (not something you'd usually like), and IE would render the page in Quirks mode (as with every other character coming before the Doctype declaration). The second point is really related to the document language, not the character encoding. Declaring it properly (with and ) should help screen-readers read each part of the page with the correct pronunciation and search engines recognize the content language (eg. every localized Google has an option to search only documents in its native language). djn begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Other character sets/languages
Hi John, Unicode is today the most foolproof way of sending internationalized characters to modern browsers. I use Unired for the purpose: http://www.esperanto.mv.ru/UniRed/ENG/ It's free and it works fine to boot. You should be able to copy/paste into your HTML from Word, PDF and anything that can display Vietnamese characters. Choose charset UTF-8 (not UTF-8 BOM) when saving. Next you need to tell the browser about the encoding. The standard compliant way is to use http headers. On Apache just add a line with 'AddDefaultCharset utf-8' to your .htaccess. Not sure about other kinds of server. Just to be safe put ''into the head of the document (as soon in the source as possible). Don't forget to mark up properly the Vietnamese content with or such... Well, that's more or less all. djn John Horner wrote: So, do I code the page in UTF-8? I don't use a special Vietnamese encoding? begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] divs, layers, trans and strict
I looked at both with Mozilla 1.7.5, IE 6 sp1 and Opera 7.54u1 on Windows 98SE at 800x600: couldn't see any difference ..? djn designer wrote: [1] http://www.treyarnon.fsworld.co.uk [2] http://www.treyarnon.fsworld.co.uk/index_strict.html begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] The Holy Grail ... CSS Liquid Three-Column Layout
Well done. Tested with Win98 SE at 800x600: works perfectly with Mozilla 1.7.3, Firefox 1.0, IE 6 SP1, Netscape 7.01, Netscape 6.2; there is something amiss with Opera - the layout is OK with 7.54, 7.29, 6.05 and 5.12, but it doesn't recognize the links at the bottom of the side columns, treating them as normal text; the padding is not appled to the side columns in IE 5.5 SP2; the layout breaks in IE 5.01 SP2, Amaya 8.5, MSN TV 2.8, WebTV Viewer 2.6; degrades cleanly to an unstyled page in IE 3, Netscape 4.74, OffByOne 3.4a, WebTV Viewer 2.0 tested with Linux (Mandrake 10.1) with KDE 3.2.3 at 1024x768: works as expected with Mozilla 1.7.2 and Konqueror 3.2.3 same link problem as in Windows with Opera 7.54 final tested with MacOS 7.5.5 under Basilisk II emulator at 800x600: layout breaks with IE 4.0 and iCab 2.95; degrades well with Netscape 4.05. I'm sendig you some screenshot off-list. Mani Sheriar wrote:  What I need help with is this: I have checked this out on Mozilla, FireFox, Netscape, and IE all on the pc. Can anyone who is interested please check it out on some other browsers/platforms? Hereâs the link: http://www.ManiSheriar.com/holygrail -- Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Images in Nav, Splash Screens.
No, I was afraid of what could I find inside. Been hard enough to convince my customer I was not going to take it as an example. Since then I've learned not to ask prospective clients what kind of website they would like to have... Bennie Shepherd wrote: Did ya sign up so you could enter? :o) > P.S. they're denim fabric wholesalers, I think. Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Images in Nav, Splash Screens.
I guess this one wins the gold medal: http://www.italdenim.com. Bert Doorn wrote: Bailout rates up to 71% have been reported with some splash pages. -- Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Mac IE (and Safari, too) testing on a PC and emulator info.
I have Basilisk installed, but it is of no use for web page testing, as PPC applications do not run on it, no matter the OS version: the most modern browsers I found in 68k version are IE 4.0, Netscape 4.05 and iCab 2.95. Until I find the time to install PearPC, I try to simulate Safari testing with Konqueror on Linux (actually a Knoppix live CD), as they should have the same KHTML rendering engine. Has anybody compared the real Safari with Konqueror ? Mordechai Peller wrote: As the only proper way to test to to actually run the software (screen shots don't help much with JavaScript), and while any standards based code which works properly in Firefox stands a good chance of also working in Safari, IE, on the other hand (surprise, surprise) isn't quite such a sure thing. Now, while I'm not ready to go out and by a Mac, does anyone have any experience with emulators under either WinXP or (x86 based) Linux? I've heard of SoftMac, Basilisk II, and PearPC, but I don't know much about them, so maybe someone can fill in the gaps. PearPC can emulate a PowerPC and run up to OS X, but at 1/40 of the speed (that figure might be out of date). The other two emulate the 68K and can run up to OS 8.1, but how fast? Up to OS 7.5.5 is available free from Apple; is this enough for IE5? Basilisk II can run under several OS's, including WinXP and Linux, but which is faster? ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ****** -- Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] choosing encoding, charset and using special characters
Manuel GonzÃlez Noriega wrote: [UTF-8] it will be stored correctly and rendered as expected, as long as you remember to put a in your page's head. Actually, what you should be doing is getting the server to send the right content-type header. Meta elements are not authoritative and in fact lead many people to confusion when they are superceded by the server headers. You're right, of course. I still use to put the declaration in the meta just in case somebody wants to save the page to the disk (and because I still remember the good old days when I had no access to the server config). -- Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] choosing encoding, charset and using special characters
JuliÃn Landerreche wrote: 1) Question: Is there a way to use special characters directly in the code? Two ways, actually, both requiring the pages being displayed as utf-8. One is writing the document with an editor capable of saving text as utf-8 (Unired is the one I like - http://www.esperanto.mv.ru/UniRed/ENG/), so that anything you can key or paste in it will be stored correctly and rendered as expected, as long as you remember to put a in your page's head. The other one is using a browser's form to input the text and send it to some sort of CMS. Provided the page with the form is utf-8 too, all modern browsers will convert the whole stuff to utf-8 while uploading. 2) I have seen a lot of webpages that directly use the special character and dont code them as html entities. This pages are displayed correctly. Question: Is this a good or bad practice (to use special characters in code, instead of entities)? According to my experience, it is OK to do it using Unicode, otherwise you're relying on unwarranted assumptions regarding the native codepage of the reader's machine (example: if you use an à in your source it will probably be displayed as such on any Spanish and generally western language OS, but it will become a Ä on most Central European PCs). 3. In Google results, I found that those special characters arent always correctly displayed. Google uses utf-8 for display, so your browser renders the title as if it was encoded as such. Question: Is there a way to force or override the encoding (not the charset) directly from the page code? I think that my textpattern managed pages should have ISO-8850-1 encoding. You can try using the numeric character references (written as &#xxx, where xxx is the decimal value of the character) or the hexadecimal ones (written as ꪪ, where is the hex value of the same). The complete list of references is at ftp://ftp.unicode.org/Public/MAPPINGS/. 3. If I change to UTF-8... wich are the advantages / disvantages? The main advantages are correct rendering in all modern browsers - OSes, plus the possibility of hassle-free mixing of characters from any charset on a single page. Besides this, it is rapidly becoming the standard encoding for all sort of documents, on the web or otherwise. There are disavantages: Netscape 4.7 mostly doesn't recognize the characters (except for the first 127 that are part of ASCII) and MacOS 9 and below has sometimes a weird way of displaying them. One final word about the document title: even if you place the above meta before the title tag and tweak your server to transmit the correct MIME type almost any browser around will still use the OS's default 'window title' font for the title, so it will be displayed as expected only if that font contains the required glyphs (or shapes). It will display correctly in Google listings, nevertheless. -- Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] -moz-border-radius
The stylesheet is not invalid, it just doesn't validate (expl.: the validator is stuck to CSS 2.0 while proprietary extensions are allowed in CSS 2.01). Neerav wrote: ... I contend that while it does make the stylesheet invalid, it shouldnt cause parsing errors because its the last few lines of my CSS file, its use is harmless and is OK for personal sites. Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Proper extension and directory for server side includes
This is what made sense to me: save the included files as myfile.inc.php (so I know at first sight it is an include ), put all of them into an 'includes' directory inside the server root ( so it's easier to port the whole thing to another server ) and prevent Apache from serving anything from that directory with a .htaccess file containing: order allow, deny deny from all This effectively makes the content of the directory unreachable from any web client, while PHP doesn't care for .htaccess files. Even if PHP was to break down, the file content will not be sent to the client. It's more or less the same as putting it outside the server root, except the portability. djn b) simply use the extension of your server-side language (again, in the case of PHP, simply use .php) This way, in the worst case, somebody who tries to access an include file on its own will only see any output the include might generate. They won't see the source code, and won't see things like database connection details or any other business logic. Now, on the subject of directories: an additional safeguard to prevent people from accessing includes in their browser on their own is to have a directory for include files which is completely outside of the normal web root, meaning that it's not possible to actually get to them from the web. Only your server-side language - as it can access your server's real file system - can get to them when generating the page. begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Solutions for testing in speech/text readers
Take a look at pwWebSpeak [http://www.soundlinks.com/pwgen.htm]. "If you are a visually impaired individual, or are using the software to evaluate sites for accessibility, you may use the software freely, but will not be entitled to support." djn -- Dejan Kozina Web Design Studio Dolina 346 (TS) I-34018 Trst/Trieste - Italy tel./fax: +39 040 228 436 cell.: +39 348 7355 225 http://www.kozina.com/ e-mail: [EMAIL PROTECTED] begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] accessible audio-visual content
Well, I was wrong. The QT file format is at http://developer.apple.com/documentation/QuickTime/FileFormatSpecification-d ate.html At 20.55 13/09/04 +1000, you wrote: > >GPL isn't the only definition of an "open standard", but I'd agree -- >QuickTime specs for the latest codecs aren't made freely available by >Apple! Projects like MPlayer and Xine (at least, I think they've >developed their own, and haven't used prior work...) have reverse >engineered implementations of the codec, but I very much doubt Apple are >handing them the format on a platter and saying "Here you go, compete." > >Not that Apple are competing at all on a GNU/Linux platform... but >that's a COMPLETELY irrelevant rant. > Dejan Kozina Web Design Studio Dolina 346 - 34018 TS - Italy tel./fax: +39 040228436 cell.: +39 3487355225 e-mail: [EMAIL PROTECTED] http://www.kozina.com
Re: [WSG] accessible audio-visual content
At 23.16 12/09/04 -0700, Rick wrote: >Why are some folks so biased against Quicktime when it's the best?! And it's >an open standard! What more do you want! A free streaming QT server? It's >available! > >Rick What do you mean with 'open standard'? I've never heard of this and Apple's website doesn't say anything like this. The only GPL thing found by Google is OpenQuickTime.org, which is a library for .mov file handling, but this doesn't make QuickTime open at all. If you want to go the open road better embed a MPEG in Flash, at least the specs have been published (and the installed base is somewhat wider). You'll have smaller files, too. By the way, QuickTime can be a real nuisance on Windows: every time the player launches it will try to write itself to the registry to be launched at startup time. Bugger. Dejan Kozina Web Design Studio Dolina 346 - 34018 TS - Italy tel./fax: +39 040228436 cell.: +39 3487355225 e-mail: [EMAIL PROTECTED] http://www.kozina.com
