 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / May 2006specify language as in <span lang="en">?
Hi, can't figure this one out, what's the CSS way to specify the language? In HTML it would be simply an lang="xx" attribute, or XHTML xml:lang="xx", but, how about in CSS? This would be required for a screen reader (text to speech) for accessibility, to help the reader software use the correct presentation method (e.g. correct language module). As a pseudo example of what I'm looking for: set Finnish 'fi' for certain td's td.fi { lang: fi; font-family: Arial,Helvetica; } I can find only info about "aural style sheets" but these don't contain any way to specify the language. It's got to be somewhere, though... (?) thanks, - Jan > can't figure this one out, what's the CSS way to specify the language? Language information is content, not presentation. So it does not belong into a presentation language like CSS.  SignatureJohannes Koch Spem in alium nunquam habui praeter in te, Deus Israel. (Thomas Tallis, 40-part motet) > can't figure this one out, what's the CSS way to specify the language? None. Language specification is a matter of metadata, to be made in markup, not a presentation issue. It is declarative, instead of recommending any particular rendering. Such language information might be _utilized_ in CSS rules, in suitable selectors, e.g. when saying that texts in some language be rendered in some particular font. But even this is mostly just theory. > In HTML it would be simply an lang="xx" attribute, or XHTML xml:lang="xx", Right. > This would be required for a screen reader (text to speech) for > accessibility, to help the reader software use the correct presentation > method (e.g. correct language module). In theory, yes. In practice, few programs make any sensible use of language information. In any case, it's a markup issue, not a style sheet issue. > As a pseudo example of what I'm looking for: set Finnish 'fi' for certain > td's [quoted text clipped - 3 lines] > font-family: Arial,Helvetica; > } This postulates that you have <td class="fi"> in your markup. Why not use <td lang="fi"> instead? Well, you might have a reason to use _both_ a lang attribute _and_ a class attribute, since td.fi is well supported, td[lang="fi"] is very poorly supported at present. > I can find only info about "aural style sheets" which hardly have any implementation worth mentioning. > but these don't contain any way to specify the language. They are not supposed to. Language is an inherent property of text, not a casual suggestion on rendering. >> This would be required for a screen reader (text to speech) for >> accessibility, to help the reader software use the correct >> presentation method (e.g. correct language module). > In theory, yes. In practice, few programs make any sensible use of > language information. Screen readers do. SignatureJohannes Koch Spem in alium nunquam habui praeter in te, Deus Israel. (Thomas Tallis, 40-part motet) >> In theory, yes. In practice, few programs make any sensible use of >> language information. > > Screen readers do. A few of them do, most in new versions only, and for a very limited set of languages. >>> In theory, yes. In practice, few programs make any sensible use of >>> language information. >> >> Screen readers do. > > A few of them do, The most widely used do. > most in new versions only, What is new? Three years old? > and for a very limited set > of languages. That's true, of course. SignatureJohannes Koch In te domine speravi; non confundar in aeternum. (Te Deum, 4th cent.) >>> In theory, yes. In practice, few programs make any sensible use of >>> language information. [quoted text clipped - 3 lines] > A few of them do, most in new versions only, and for a very limited set > of languages. JAWS supports quite a few. The MS Speech API with 3rd party extensions does, also. http://www.microsoft.com/speech/evaluation/thirdparty/engines.mspx Considering that even something as exotic as Finnish is included in JAWS, I would not talk about a very limited set of languages! ;-)) regards, - Jan >> In theory, yes. In practice, few programs make any sensible use of >>language information. > >Screen readers do. What about search engines? SignatureAndy Mabbett Say "NO!" to compulsory ID Cards: <http://www.no2id.net/> Free Our Data: <http://www.freeourdata.org.uk> Andy Mabbett <usenet200309@pigsonthewing.org.uk> scripsit: >>> In theory, yes. In practice, few programs make any sensible use of >>> language information. >> >> Screen readers do. > > What about search engines? They don't, and one cannot really blame them. Only a small minority of pages has language markup, and a surprisingly large number of them use simply _wrong_ language markup. Typically, they have lang="en" or lang="en-US" because some authoring software spits that out, quite independently of the language actually used on the page. In practice, simple heuristics works better in recognizing the language. >> I can find only info about "aural style sheets" > >which hardly have any implementation worth mentioning. Opera on WinNT (W2K & XP) supports a good portion and useful set of aural CSS properties and values. SignatureSpartanicus >>> I can find only info about "aural style sheets" >> >>which hardly have any implementation worth mentioning. > > Opera on WinNT (W2K & XP) supports a good portion and useful set of > aural CSS properties and values. You mean the CSS 2.0 aural style sheet properties, which are being phased out in the CSS 2.1 draft? While I can see some potential use for them in limited applications, like intranets where Opera is used for this very purpose, this does not seem useful in authoring for the WWW. There would be far too much work as compared with the small number of users who use Opera in a mode where aural style sheets might matter. In effect, I would regard the issue quite comparable to using purely browser-specific extension, for a minority browser. >>>> I can find only info about "aural style sheets" >>> [quoted text clipped - 5 lines] >You mean the CSS 2.0 aural style sheet properties, which are being phased >out in the CSS 2.1 draft? A key aim of CSS 2.1 is to remove those parts that had (not yet) been implemented. Removal from CSS 2.1 does not mean that it has been abandoned. The aural CSS from 2.0 reappears in CSS3 virtually unchanged. >While I can see some potential use for them in >limited applications, like intranets where Opera is used for this very [quoted text clipped - 3 lines] >the issue quite comparable to using purely browser-specific extension, for a >minority browser. Opera tends to lead the pack in implementing stuff only if there is a reasonable use case. That was the case with Opera's implementation of CSS properties & values not supported by other main browsers. Although of little use on the web they are used to good effect in Opera's user stylesheets. Their implementation of aural CSS seems to have been motivated by the hope that developers would start to experiment with creating XHTML + Voice applications, e.g. to create a UI for non desktop use. This is an area where Opera has market opportunities and ambitions more so than other manufacturers. I've found it enlightening to be able to shape the presentation in the aural domain. It allowed me to get a proper feel for what is possible with aural user interfaces. Before Opera's implementation the only option was some obscure piece of nix software called EmacSpeak that no-one that I know managed to get working. SignatureSpartanicus Hi, thanks for your infos! >> As a pseudo example of what I'm looking for: set Finnish 'fi' for >> certain td's [quoted text clipped - 8 lines] > a lang attribute _and_ a class attribute, since td.fi is well supported, > td[lang="fi"] is very poorly supported at present. Main reason for <td class="fi"> in markup: Dreamweaver MX allows very easy setting of table column class, but lang attribute just isn't there by default (would need to write a script, too much bother). Anyway. VK's code suggestion looks like a pretty good almost-CSS way to achieve this. >> but these don't contain any way to specify the language. > > They are not supposed to. Language is an inherent property of text, not > a casual suggestion on rendering. Sort of good point there... But IMHO the lang attribute can also be "casual suggestion on rendering", mainly for TTS. For example, present the speech according to British or US English without changing the content, or present in some dialect, again without changing content. Like one would change the layout presentation of a page, one could also change the speech presentation. Pity this isn't directly part of CSS, just indirectly and "almost" through aural. (thanks others too for your input!) - Jan Jan Wagner <no_spam@thanks.net> scripsit: > Main reason for <td class="fi"> in markup: I guess you mean a reason for _not_ having such markup, since your question seems to revolve around avoiding the use of markup for indicating language. > Dreamweaver MX allows > very easy setting of table column class, but lang attribute just > isn't there by default (would need to write a script, too much > bother). Huh? A table column may have a lang attribute when declared using <col lang="...">. Whether programs support this is a different issue. But indicating language is surely a job for HTML, not for CSS, still less some kludge that is not based on published specifications and requires _both_ CSS _and_ scripting to be "on" - there's no reason to assume they are, especially in situations where language information could be beneficial (e.g., speech browsers, search engines). You can write lang attributes for cell elements (<th>, <td>) if needed. If your authoring tool does not let you do that conveniently, do it in a simple though inconvenient way, or get a better authoring tool. > Anyway. VK's code suggestion looks like a pretty good > almost-CSS way to achieve this. The kludge tries to modify the document tree via client-side scripting. Why don't you just use adequate markup in the first place? This is comparable to using <foo> markup and then some kludge to change <foo> to <bar> in the browser. >>> but these don't contain any way to specify the language. >> >> They are not supposed to. Language is an inherent property of text, >> not a casual suggestion on rendering. > > Sort of good point there... It's the whole point here. > But IMHO the lang attribute can also be > "casual suggestion on rendering", mainly for TTS. No it isn't, any more than <h1> is a suggestion on rendering, even though it may be rendered in large font size, or in read, or in slow and emphatic voice. > For example, > present the speech according to British or US English without > changing the content, or present in some dialect, again without > changing content. It would be simply incorrect to label a document or part of document as, say, British English when it isn't. Even in the (rather rare) special case where the same document could be labeled as lang="en-GB" or as lang="en-US", because the document contains no expressions where the two language forms differ, it would still be a matter of _content_. The element <span lang="en">elf</span> has a _meaning_ different from <span lang="de">elf</span>. > Like one would change the layout presentation of a > page, one could also change the speech presentation. Pity this isn't > directly part of CSS, just indirectly and "almost" through aural. It's not even indirectly part of CSS. > Jan Wagner <no_spam@thanks.net> scripsit: > [quoted text clipped - 3 lines] > question seems to revolve around avoiding the use of markup for > indicating language. No - for _not_ having lang="fi" in table cells. Also since I have a large set of mixed language pages in html, and indicating the languages was a later requirement for the site, I'd obviously try to do this addition in some fastest possible way. >> Dreamweaver MX allows >> very easy setting of table column class, but lang attribute just [quoted text clipped - 3 lines] > Huh? A table column may have a lang attribute when declared using <col > lang="...">. Thanks for the info, wasn't aware of the HTML col+colgroup tags. This is definitely the simplest way to add language indication to these existing pages. :-) > You can write lang attributes for cell elements (<th>, <td>) if needed. > If your authoring tool does not let you do that conveniently, do it in a > simple though inconvenient way, or get a better authoring tool. What a stupid and unnecessary comment. If you make these, at least try to suggest a "better" authoring tool! >> Anyway. VK's code suggestion looks like a pretty good >> almost-CSS way to achieve this. [quoted text clipped - 3 lines] > comparable to using <foo> markup and then some kludge to change <foo> to > <bar> in the browser. Whatever is simpler (as in, faster to implement for existing pages). Col+colgroup looks now much better than VK's hack, though. > It would be simply incorrect to label a document or part of document as, > say, British English when it isn't. Nah, I meant label it to be read out (presented) in e.g. British English or other even if it the actual content might not be. But likely that would be better done with some attribute other than 'lang'. - Jan > > Huh? A table column may have a lang attribute when declared using > > <col lang="...">. > > Thanks for the info, wasn't aware of the HTML col+colgroup tags. I'm a bit uneasy that Jukka proposed that without further comment. http://www.w3.org/TR/CSS21/tables.html#q4 However, in the source document cells are descendants of rows, never of columns. Nevertheless, some aspects of cells can be influenced by setting properties on columns. [... followed by a very short list of properties] > This is definitely the simplest way to add language indication to > these existing pages. :-) Oh, agreed, and the meaning (of the HTML) is clear, no argument with that. Just that if one intends to use the language attribute to apply some presentational effects via CSS, I think there are going to be quite severe limits on what can be achieved with it. [...] > Nah, I meant label it to be read out (presented) in e.g. British > English or other even if it the actual content might not be. But > likely that would be better done with some attribute other than > 'lang'. It wouldn't just be "better" - mis-labelling the language (in HTML) for presentational effect would be plain wrong. Alan J. Flavell <flavell@physics.gla.ac.uk> scripsit: >>> Huh? A table column may have a lang attribute when declared using >>> <col lang="...">. >> >> Thanks for the info, wasn't aware of the HTML col+colgroup tags. > > I'm a bit uneasy that Jukka proposed that without further comment. I had a comment: "Whether programs support this is a different issue." The point is that if you declare language as a matter of principle, as good practice, with virtue as its own reward, you can do things in a simple way as defined in the specifications - but if you expect some practical gain, you need to check things out and do some testing. > http://www.w3.org/TR/CSS21/tables.html#q4 I'd regard that as irrelevant when considering the meaning and effect of lang attributes in HTML. They are not supposed to have, and they don't have, any direct effect on styling, any more than a class attribute has. If we discussed the meaning of selectors like lang(...), it would be a different (and tough) question. The HTML 4.01 specification describes, in an odd place and under a strange heading, the lang attribute as being "inherited" from columns to cells: http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.3.2.1 >> This is definitely the simplest way to add language indication to >> these existing pages. :-) [quoted text clipped - 3 lines] > some presentational effects via CSS, I think there are going to be > quite severe limits on what can be achieved with it. The lang attribute, unlike some presentational attributes like align and width, has no CSS counterpart - it is not implicitly mapped to anything in CSS. _Using_ the attribute in _selectors_ is a different matter, and here we have the restrictive principle that the pseudo-element [lang |= "..."] refers only to those elements that have the lang attribute set in markup, with no inheritance considerations. Using :lang(...) would be a different matter, but I'm afraid it has even less support. > Alan J. Flavell <flavell@physics.gla.ac.uk> scripsit: > > > I'm a bit uneasy that Jukka proposed that without further comment. > > I had a comment: "Whether programs support this is a different issue." Apologies. I was thinking more in terms of what could be achieved according to the CSS specification - rather than actual implementation details. AIUI, /some/ browsers already do things (in terms of carrying-over CSS properties from cols to cells) which the specification implies that they should NOT be doing... > > http://www.w3.org/TR/CSS21/tables.html#q4 > > I'd regard that as irrelevant when considering the meaning and > effect of lang attributes in HTML. Agreed. > They are not supposed to have, and they don't have, any > direct effect on styling, any more than a class attribute has. Hmmm... actually, some browsers will use lang attributes to influence their default choice of font, for example. I don't think such behaviour is actually wrong. > If we discussed the meaning of selectors like lang(...), it would be > a different (and tough) question. Agreed. > The HTML 4.01 specification describes, in an odd place and under a > strange heading, the lang attribute as being "inherited" from > columns to cells: > http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.3.2.1 Titled "Inheritance of alignment specifications", I see ... Now this is remarkable. I wonder how many other readers have managed to find that yet? I have to say frankly that it had completely passed me by. So, in a section which purports to explain the inheritance of cell alignment, it actually states, almost as a throwaway aside, that HTML lang, dir, and style attributes are supposed to inherit from cols to cells in the same way as valign. (I guess this calls for some tests on actual browsers, but that will have to wait for another day, unless you know some existing test suites which explore it already). This seems to mean that an explicit <style...> attribute on a col could be used to influence the presentation of the whole column, provided some other style attribute did not supervene. In ways that a class or id applied to the col and called-out from a stylesheet could *not* (other than the limited shortlist of properties which I cited before). *Is* that what it means? > The lang attribute, unlike some presentational attributes like align > and width, has no CSS counterpart - it is not implicitly mapped to [quoted text clipped - 4 lines] > considerations. Using :lang(...) would be a different matter, but > I'm afraid it has even less support. Agreed with those points. Thanks for this instructive exchange! Alan J. Flavell <flavell@physics.gla.ac.uk> scripsit: >> They are not supposed to have, and they don't have, any >> direct effect on styling, any more than a class attribute has. > > Hmmm... actually, some browsers will use lang attributes to influence > their default choice of font, for example. I don't think such > behaviour is actually wrong. Agreed, but I don't count it as an effect on styling _in CSS terms_. Though, admittedly, it would in a sense be describable as CSS rules. In reality, however, the choice of the default fonts for different languages/scripts/encodings (browser vendors really managed to mess this up) is affected by _browser settings_ outside any CSS considerations. (Besides, I do think such behaviour is often "wrong" in the sense of producing practically wrong results for pages that use language markup for, say, transliterated names or titles or passages. If I mention Dostoyevsky, writing his name as transliterated, it's still a name in Russian and lang="ru" would be adequate for it, but I dare not use it, since browsers could then do an uncalled-for font change in the middle of text.) >> http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.3.2.1 > > Titled "Inheritance of alignment specifications", I see ... > > Now this is remarkable. I wonder how many other readers have managed > to find that yet? Few, I'm afraid. And they tend to forget its existence, or at least the exact location, but I was lucky this time to manage to pick it up. :-) > So, in a section which purports to explain the inheritance of cell > alignment, it actually states, almost as a throwaway aside, that HTML > lang, dir, and style attributes are supposed to inherit from cols to > cells in the same way as valign. Indeed, and it uses the word "inherit", which is not defined in HTML terminology, so we need to take it intuitively or to assume it's analogous with the CSS inheritance concept, which is misunderstood by most people who try to understand CSS. > This seems to mean that an explicit <style...> attribute on a col > could be used to influence the presentation of the whole column, > provided some other style attribute did not supervene. In ways that a > class or id applied to the col and called-out from a stylesheet could > *not* (other than the limited shortlist of properties which I cited > before). *Is* that what it means? That's a good question. Are there any more questions? :-) Seriously, I take this is a conflict between HTML and CSS specifications, and I think the CSS approach is what we are supposed to assume - for presentational issues. I think the CSS approach is based on difficulties that would arise in visual rendering, if tables were treated as truly two-dimensional, with each cell being a "descendant" (in some sense) of a column as well as of a row. On the other hand, such issues probably do not affect lang attribute considerations, so I'd expect that they are _meant_ to be "inherited" from columns to cells, in the absence of lang attribute for the cell or its row. Some simple testing: On Opera 8.54 and Firefox 1.5.0.3, if I set <col lang="fi"> for a column, the cells in that column match the selector :lang(fi) but do not match [lang="fi"] This is what I'd expect, since the cells do not have a lang attribute but they have their language specified via "inheritance" (in the fuzzy HTML meaning) from the <col> element. IE 6 knows nothing about such selectors. IE 7 beta seems to fail to support :lang(...) at all but has at least some support to attribute selectors like [lang="fi"]. I'm not surprised at seeing that IE 7 gets the situation wrong (or at least differently from the reasonable interpretation): [lang="fi"] matches not only elements with lang="fi" but also table cells that "inherit" language information from <col lang="fi"> - or from a parent element (e.g., from <tr lang="fi">)! Thus, now and in the foreseeable future, the only way to style texts differently depending on their language, in a manner that works in the majority of browsing situations is to use class attributes and class selectors, no matter how redundant they are logically in the presence of lang attributes. > Some simple testing: On Opera 8.54 and Firefox 1.5.0.3, if I set <col > lang="fi"> for a column, the cells in that column match the selector > :lang(fi) > but do not match > [lang="fi"] > This is what I'd expect, since the cells do not have a lang > attribute but they have their language specified via "inheritance" > (in the fuzzy HTML meaning) from the <col> element. Curious. Your observations seem to be at variance with mine in this respect. Do you have a test case to compare with, or can you already see what's the difference between yours and mine please? - http://ppewww.ph.gla.ac.uk/~flavell/tests/tbltest.html thanks Alan J. Flavell <flavell@physics.gla.ac.uk> scripsit: > Curious. Your observations seem to be at variance with mine in > this respect. Do you have a test case to compare with, or can you > already see what's the difference between yours and mine please? - > http://ppewww.ph.gla.ac.uk/~flavell/tests/tbltest.html I'm getting more and more confused, and I should be in bed now, but my current test page is http://www.cs.tut.fi/~jkorpela/test/lang.html I wonder whether the differences depend on the properties we use. I guess I was first misled to think that Opera uses a background color for the cells in a column when it perhaps just uses if for the <col> element somehow and the background shines through. > http://www.cs.tut.fi/~jkorpela/test/lang.html Many thanks... > I wonder whether the differences depend on the properties we use. I > guess I was first misled to think that Opera uses a background color > for the cells in a column when it perhaps just uses if for the <col> > element somehow and the background shines through. I'm sorry to say that I think that is indeed the explanation for what your page is doing. As you know, the CSS spec calls for the background to "shine through" from the col element to the cells, if no non-transparent background intervenes.[1] I'm afraid that has confused the interpretation of the result. If I change your :lang(fi) text colour from black to red, then the last column, first two rows, remain black, whereas they should be red if the <col> language was really propagating to the <td> cells. The last row is red, of course, because of its <tr lang="fi">. thanks [1] by way of explanation if any readers need this... As usual, I shall break the rules by citing a W3C work in progress, on the grounds that it's the nearest that we've got to a current spec.: http://www.w3.org/TR/CSS21/tables.html#q4 http://www.w3.org/TR/CSS21/tables.html#table-layers [test case details] I'm afraid I just found https://bugzilla.mozilla.org/show_bug.cgi?id=915 Seems to have been open since 1998. > I'm afraid I just found > https://bugzilla.mozilla.org/show_bug.cgi?id=915 > > Seems to have been open since 1998. AFAIK, that's the oldest open Mozilla bug. Key people believe the spec is broken, so I wouldn't expect any action until Hixie writes a better spec for tables. SignatureHenri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html > Hmmm... actually, some browsers will use lang attributes to influence > their default choice of font, for example. I don't think such > behaviour is actually wrong. Oh dear, this is getting further and further away from stylesheets, but now that the thread is under way, I'm reluctant to try to restart it in the *.html group... > So, in a section which purports to explain the inheritance of cell > alignment, it actually states, almost as a throwaway aside, that > HTML lang, dir, and style attributes are supposed to inherit from > cols to cells in the same way as valign. (I guess this calls for > some tests on actual browsers, ... Here's a simple test that I threw together. I think it does what we have been discussing, and investigates the inheritance of the html attributes dir, lang, style, align and valign from the col element to the td cells in that column: http://ppewww.ph.gla.ac.uk/~flavell/tests/tbltest.html On the side it also tests the selectors [lang=ru] and :lang(ru) The first column is neutral, so it should serve as an exhibit of the browser's defaults. My test values of these attributes have been applied explicitly to the cell in the middle of the second row. And they have also been applied to the third column. Thus, if it all has worked, both cells in the third column should resemble the explicitly marked cell i.e the one in the middle of the second row. Am I making some kind of sense? Results... The only browser which is doing anything evident with the lang= HTML attribute is Seamonkey, which is changing the font for the explicitly marked cell. But not for the third column. Seamonkey is honouring the selectors for [lang=ru] and :lang=ru (the explicitly marked cell is bold and oblique). Seamonkey is not honouring *any* of the attributes for the third column: not even the align and valign. Konqueror (linux, 3.1.3) is behaving rather like Seamonkey, except that it's not honouring the :lang(ru) selector. Opera 8.54 - for the third column it is honouring the HTML align and valign attributes, but nothing more. It's applying the style rules for both [lang=ru] and :lang(ru) , but on the explicitly marked cell, only. Opera 9 beta is doing the same. IE6 is the only one, of these tested, that inherits more than the align and valign attributes of the third column: like the explicitly styled cell, it's showing the third column content in red and rtl (so it's inheriting at least style and dir from the col element, in addition to align and valign). But, as we know, it honours neither [lang=ru] nor :lang(ru) Conclusion: using col in any of these ways is not currently feasible in a WWW context. (And this is, I think, the first time in several years that IE has managed to beat the opposition in terms of meeting the specification!). That's assuming that my tests were not fundamentally flawed, which is why I'm putting them up for review. > Huh? A table column may have a lang attribute when declared using <col > lang="...">. Whether programs support this is a different issue. And a very interesting one: because neither IE nor FF nor other browser I'm aware of do not support this coding. Overall colgroup/col support on browsers except IE is very poor, especially on FF. The only attribute really recognized universally in col is width. This way <col lang="fi"> would have an academical value only: profoundly correct and utterly useless. OP is welcome to try it though as I may be trolling again. > The only > attribute really recognized universally in col is width. And SPAN - in application to WIDTH >> Huh? A table column may have a lang attribute when declared using <col >> lang="...">. Whether programs support this is a different issue. [quoted text clipped - 7 lines] > > OP is welcome to try it though as I may be trolling again. LOL... Unfortunately you weren't just trolling - it did not work with colgroup/col in my test setup, tried it in FF and IE using the JAWS demo version. <col lang=".."> was not recognized or honored, what a shame. - Jan > A table column may have a lang attribute when declared using <col > lang="...">. Whether programs support this is a different issue. Do you know of any? The HTML 4.01 spec has some pretty crazy and unimplementable stuff in the part that deals with this. "The order of precedence (from highest to lowest) for the attribute valign (as well as the other inherited attributes lang, dir, and style) is the following: 1. An attribute set on an element within a cell's data (e.g., P)." Surely style is not an "inherited attribute". Also, looking in the cell *content* for the alignment of the *cell* makes no sense. Moreover, the lang inheritance chain surely doesn't end at <table>. The safe assumption is that when supported, lang inherits in the document tree. SignatureHenri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html > > A table column may have a lang attribute when declared using <col > > lang="...">. Whether programs support this is a different issue. > > Do you know of any? Oops. I now noticed the :lang() stuff in the thread. I am actually very surprised that language inheritance into columns "works". SignatureHenri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html > > This postulates that you have <td class="fi"> in your markup. Why > > not use <td lang="fi"> instead? Well, you might have a reason to > > use _both_ a lang attribute _and_ a class attribute, since td.fi > > is well supported, td[lang="fi"] is very poorly supported at > > present. Keep in mind that lang="fi" is a property of the content itself, not merely a presentational proposal. The fact that some lesser browsers fail to honour the proposal isn't exactly a tragedy: CSS is optional by design, after all. > Main reason for <td class="fi"> in markup: Dreamweaver MX allows > very easy setting of table column class, but lang attribute just > isn't there by default (would need to write a script, too much > bother). The WWW cares not in the least what tool you used to create your content: it only cares about the result which gets extruded out of your web server. If your tool seems inadequate to the purpose - put it aside. Blaming shortcomings of the tool for inadequacies in what you publish is no kind of excuse. > Anyway. VK's code suggestion > looks like a pretty good almost-CSS way to achieve this. Does it? In the time available to me, I've been unable to distinguish VK from a common troll. It may be that it occasionally gets something right, but I'd prefer to get my advice from folks with a much better track record (and I'd obviously put Jukka into that class, with stars). > > They are not supposed to. Language is an inherent property of > > text, not a casual suggestion on rendering. > > Sort of good point there... It's more than "sort of". > But IMHO the lang attribute can also be "casual suggestion on > rendering", I can't make any sense of that remark. Are you proposing that some language-free text in HTML could be proposed in alternative languages via CSS? I've little idea how that would look! > mainly for TTS. For example, present the speech according to British > or US English without changing the content, or present in some > dialect, again without changing content. You seem to be doing nothing more than proposing different (regional) voices for rendering the same original text. The text itself in in a given language, and you can mark-up that language for what it is (in HTML). That does NOT change under your proposal. > Like one would change the layout presentation of a page, one could > also change the speech presentation. Sure. But that would not change the language of the original text! You really seem to have lost your grasp of the distinction between the original content, and a rendering suggestion. > In the time available to me, I've been unable to distinguish > VK from a common troll. That was obviously pointless trolling in my most in this thread: in each line of the working code I presented. Do not mix "trolling" with "the last century dust and rust cleaning". The first I never do - thus I never start a discussion just to have a discussion. The latter I do rather regularly - but not as the only purpose of my life. > Hi, > > can't figure this one out, what's the CSS way to specify the language? Following the link might be what you need: <http://www.w3.org/International/tutorials/tutorial-lang/> Best Regards, Oliver > Hi, > > can't figure this one out, what's the CSS way to specify the language? It seems overlooked in Aural CSS specs. Use behavior twinpair (IE 5.5+, FF1.0+, Moz Suite 1.0+, Camino 1.0+, NN8+) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html> <head> <title>Demo</title> <style type="text/css"> #p01 { -moz-binding: url(lang.xml#default); behavior: url(lang.htc); } </style> </head> <body> <p id="p01" onclick="alert(this.getAttribute('lang'))">Default content</p> </body> </html> //lang.xml <?xml version="1.0"?> <bindings xmlns="http://www.mozilla.org/xbl"> <binding id="default"> <implementation> <constructor> this.setAttribute('lang','fi'); </constructor> </implementation> </binding> </bindings> //lang.htc <?xml version="1.0"?> <public> <component> <attach event="oncontentready" onevent="constructor()" /> </component> <script type="text/Jscript"><!-- element.setAttribute('lang','fi'); //--></script> </public> > It seems overlooked in Aural CSS specs. Use behavior twinpair (IE 5.5+, > FF1.0+, Moz Suite 1.0+, Camino 1.0+, NN8+) <snip nice code> Thanks for the interesting solution! Looks pretty good, though complex (or rather, just about complex enough to suit me very well ;-)). I'll give that one a go, thx for sharing. - Jan > > It seems overlooked in Aural CSS specs. Use behavior twinpair (IE 5.5+, > > FF1.0+, Moz Suite 1.0+, Camino 1.0+, NN8+) [quoted text clipped - 3 lines] > complex (or rather, just about complex enough to suit me very well > ;-)). I'll give that one a go, thx for sharing. Oops... sorry for a typo in lang.htc file (copy'n'paste damn it) Must be: <?xml version="1.0"?> <public> <component> <attach event="oncontentready" onevent="constructor()" /> </component> <script type="text/Jscript"><!-- function constructor() { element.setAttribute('lang','fi'); } //--></script> </public> So function declaration was omited. The defective variant still works but shows warning sign in IE as you maybe already noticed. Sorry again. > Oops... sorry for a typo in lang.htc file (copy'n'paste damn it) Must > be: [quoted text clipped - 13 lines] > So function declaration was omited. The defective variant still works > but shows warning sign in IE as you maybe already noticed. Sorry again. Thanks for your help! However even this code, and some further fiddling around, did not work with JAWS in IE nor in FF. Haven't checked if it would work in HT Reader and Dolphin HAL, it just might. However since I'd rather like to have the same markup or method work with all screen readers, it looks like I'll just have to get off my lazy a.s and write that <td lang="xx"> lang attribute inserter script for Dreamweaver to get this done in the more "generally supported" way. Still, thanks for your code, much appreciated! - Jan VK wrote: > > <?xml version="1.0"?> > > <public> [quoted text clipped - 7 lines] > > //--></script> > > </public> > Thanks for your help! However even this code, and some further > fiddling around, did not work with JAWS in IE nor in FF.Haven't > checked if it would work in HT Reader and Dolphin HAL, it just might. Could you elaborate on this if you have some? (it is important to me to know for binding/behavior support). I have a weak - to say the least - idea about JAWS but of course I can gougle out for that. Yet behaviors are being applied on the parsing stage, thus then load event fired the job is already done. Maybe JAWS intercept data stream right from the server? You mean lang attribute doesn't set at all, as no behavior attached? No errors? > However since I'd rather like to have the same markup or method work > with all screen readers, it looks like I'll just have to get off my > lazy a.s and write that <td lang="xx"> lang attribute inserter > script for Dreamweaver to get this done in the more "generally > supported" way. Still, thanks for your code, much appreciated! As I'm in a creative mood :-) there is another option: use XSLT transformed with patched DTD, so resulting table cells would have default value "fi" for lang attribute (and say "Micro$oft must die!" as default for text fields). Yet it is /really/ easier to use search/replace in your editor :-)) |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.