472,971 Members | 1,949 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,971 software developers and data experts.

specify 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
May 17 '06 #1
37 4107
"Jan Wagner" <no*****@thanks.net> wrote:
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

td.fi {
lang: fi;
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.

May 17 '06 #2
Jan Wagner wrote:
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.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
May 17 '06 #3
> "Jan Wagner" <no*****@thanks.net> wrote:
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).

Jukka K. Korpela wrote: In theory, yes. In practice, few programs make any sensible use of
language information.


Screen readers do.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
May 17 '06 #4
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
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.

--
Spartanicus
May 17 '06 #5
Jan Wagner wrote:
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

May 18 '06 #6
"Johannes Koch" <ko**@w3development.de> wrote:
Jukka K. Korpela wrote:
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.

May 18 '06 #7
"Spartanicus" <in*****@invalid.invalid> wrote:
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.

May 18 '06 #8
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
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?


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
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.


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.

--
Spartanicus
May 18 '06 #9
Jukka K. Korpela wrote:
"Johannes Koch" <ko**@w3development.de> wrote:
Jukka K. Korpela wrote:
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.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
May 18 '06 #10
VK

Jan Wagner wrote:
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>

May 18 '06 #11
Hi,

thanks for your infos!

Jukka K. Korpela wrote:
"Jan Wagner" <no*****@thanks.net> wrote:
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;
}


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.


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
May 18 '06 #12
Jukka K. Korpela wrote:
"Johannes Koch" <ko**@w3development.de> wrote:
Jukka K. Korpela wrote:
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.


JAWS supports quite a few.

The MS Speech API with 3rd party extensions does, also.
http://www.microsoft.com/speech/eval...y/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
May 18 '06 #13
VK wrote:
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
May 18 '06 #14
Jan Wagner <no*****@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.

May 18 '06 #15
On Thu, 18 May 2006, Jan Wagner wrote:
Jukka K. Korpela wrote:
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.
May 18 '06 #16
VK

Alan J. Flavell wrote:
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.

May 18 '06 #17
Jukka K. Korpela wrote:
Jan Wagner <no*****@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.


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
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="...">.


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.


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.


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
May 19 '06 #18
On Fri, 19 May 2006, Jan Wagner wrote:
Jukka K. Korpela wrote:
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.
May 19 '06 #19
VK

Jukka K. Korpela wrote:
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.

May 19 '06 #20
VK

VK wrote:
The only
attribute really recognized universally in col is width.


And SPAN - in application to WIDTH

May 19 '06 #21
Alan J. Flavell <fl*****@physics.gla.ac.uk> scripsit:
On Fri, 19 May 2006, Jan Wagner wrote:
Jukka K. Korpela wrote:
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/stru...tml#h-11.3.2.1
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.


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.

May 19 '06 #22
On Fri, 19 May 2006, Jukka K. Korpela wrote:
Alan J. Flavell <fl*****@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/stru...tml#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
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.


Agreed with those points.

Thanks for this instructive exchange!
May 19 '06 #23
VK

Jan Wagner wrote:
VK wrote:
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.


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.

May 19 '06 #24
VK wrote:
Jukka K. Korpela wrote:
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.


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

May 19 '06 #25
VK wrote:
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.


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 ass 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
May 19 '06 #26
VK
VK wrote:
<?xml version="1.0"?>
<public>
<component>
<attach event="oncontentready" onevent="constructor()" />
</component>
<script type="text/Jscript"><!--
function constructor() {
element.setAttribute('lang','fi');
}
//--></script>
</public>

Jan Wagner wrote: 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 ass 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 :-))

May 19 '06 #27
On Fri, 19 May 2006, Alan J. Flavell wrote:
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.

--

May 19 '06 #28
Alan J. Flavell <fl*****@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/stru...tml#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.

May 19 '06 #29
On Fri, 19 May 2006, Jukka K. Korpela wrote:
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
May 19 '06 #30
Alan J. Flavell <fl*****@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.

May 19 '06 #31
On Sat, 20 May 2006, Jukka K. Korpela wrote:
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
May 19 '06 #32
In message <44***********************@authen.yellow.readfreen ews.net>,
Johannes Koch <ko**@w3development.de> writes
Jukka K. Korpela wrote:
In theory, yes. In practice, few programs make any sensible use of
language information.


Screen readers do.


What about search engines?

--
Andy Mabbett
Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>

Free Our Data: <http://www.freeourdata.org.uk>
May 19 '06 #33
On Sat, 20 May 2006, Jukka K. Korpela wrote:

[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.
May 19 '06 #34
Andy Mabbett <us**********@pigsonthewing.org.uk> scripsit:
In message <44***********************@authen.yellow.readfreen ews.net>,
Johannes Koch <ko**@w3development.de> writes
Jukka K. Korpela wrote:
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.

May 20 '06 #35
In article <No****************@reader1.news.jippii.net>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
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.

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
May 27 '06 #36
In article <hs****************************@news.fv.fi>,
Henri Sivonen <hs******@iki.fi> wrote:
In article <No****************@reader1.news.jippii.net>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
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".

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
May 27 '06 #37
In article <Pi******************************@ppepc20.ph.gla.a c.uk>,
"Alan J. Flavell" <fl*****@physics.gla.ac.uk> wrote:
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.

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
May 27 '06 #38

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Jon Davis | last post by:
I recently learned how to do an <OBJECT> alternative to <IFRAME> in current browsers using: <object id="extendedhtml" type="text/html" data="otherpage.html" width="250" height="400"></object> ...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
0
tracyyun
by: tracyyun | last post by:
Hello everyone, I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
3
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
1
by: Teri B | last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course. 0ne-to-many. One course many roles. Then I created a report based on the Course form and...
3
by: nia12 | last post by:
Hi there, I am very new to Access so apologies if any of this is obvious/not clear. I am creating a data collection tool for health care employees to complete. It consists of a number of...
0
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
3
by: GKJR | last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.