- From: Risto Kankkunen <risto.kankkunen@iki.fi>
- Date: Tue, 19 Oct 2004 19:58:20 +0300
- To: Edward Lass <elass@goer.state.ny.us>
- CC: www-html@w3.org
Edward Lass <elass@goer.state.ny.us> wrote: >>> 1. It provides alternative representations only for remote >>> resources > > In theory, HTTP Content Negotiation and XML encoding information > should already make sure that the user agent can handle everything > that an XHTML page throws at it. First of all, HTTP Content Negotiation works of course only when HTTP is used. XHTML is not meant to be used only with HTTP. Secondly, HTTP Content Negotiation, as well as the draft's mechanism, only works for external documents. Surely you don't mean that the author should prepare a number of different versions of a large document, just because it happens to contain a couple of phrases in a couple of different languages? This is just the reason we need a mechanism like "<alt>" that isn't tied into the external objects. > In practice, when I look at the W3C HTML Home Page in Firefox for > Windows, Masayasu Ishikawa's name in Japanese appears as a series of > question marks. It's great that you pointed out this real-life problem you are having, because it's just one of those things that "<alt>" could fix. When I go to that page, I get a dialog saying "To display language characters correctly, you need to install the following components: Japanese Text Display" and see the name as question marks. So the browser knows very well it cannot render the name properly. But since it doesn't have any other info to go on, it just puts up a number of question marks. If it was possible for the author to provide an inline alternative to the Japanese name via "<alt>" tag, the browser could use that information to make a better job. Even this simple addition would be better: <li> <a href="../People/mimasa/" lang="ja" lang="ja"> <alt> <span>石川 雅康 (ISHIKAWA Masayasu)</span> <span>ISHIKAWA Masayasu</span> </alt> </a> is the HTML Activity Lead and the Team Contact for the HTML Working Group </li> > However, from the example: > > <!-- in Cyrillic letters --> <p xml:lang="ru"> ? ???? ????????! </p> > > <!-- Latin transliteration --> <p xml:lang="ru"> S dnem rozhden'ja! > </p> > > Obviously the xml:lang attribute doesn't include encoding or font > information, so a user agent couldn't be expected to reject the > Cyrillic letters... I don't know, if it was obvious, but the Cyrillic version uses UTF-8 encoding, the one used by XML by default. So every user agent should be able to parse that, but without the correct font cannot necessarily display it (I don't think there are many people who have a font installed that contains all the Unicode characters). I don't know what you mean by saying "a user agent couldn't be expected to reject the Cyrillic letters". The user agent has no other alternative, if it doesn't support Cyrillic, and it is craving for instructions by the document author of what to do. > Is this problem common enough that a scripting solution is > inadequate? Probably not. I'm interested to see how you solve this with "a scripting solution". It's also interesting to see, that you don't think multilanguage documents are common... I hope the consensus is more like chapter "1.1.1 Design Aims" of the draft describes: # Better internationalization: since it is a World Wide Web. # Less scripting: achieving functionality through scripting is difficult for the author and restricts the type of user agent you can use to view the document. We have tried to identify current typical usage, and include those usages in markup. Regards, Risto Kankkunen
Received on Tuesday, 19 October 2004 16:58:17 UTC