On Wednesday 2013-05-01 01:01 -0700, Elliott Sprehn wrote:
On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil pocci...@gmail.com wrote:
I have no objection to the name baseLang rather than language as the
name of the DOM attribute.
But if there isn't more interest or you decide not to add this
On Wed, Sep 18, 2013 at 11:10 AM, L. David Baron dba...@dbaron.org wrote:
In Gecko it's also implemented through CSS inheritance, but it's not
exposed to Web content as a CSS property. (Internally it's
'-x-lang', but that name isn't exposed.)
We use the language for:
* font selection
*
On Fri, 2 Aug 2013, Jukka K. Korpela wrote:
2013-08-02 2:43, Ryosuke Niwa wrote:
Are you saying that for HTML contenteditable-based editors that want
to support drag-and-drop editing, they need to be able to annotate
the outgoing HTML fragment with the effective language so that
On Thu, 1 Aug 2013, Ryosuke Niwa wrote:
Are you saying that for HTML contenteditable-based editors that want
to support drag-and-drop editing, they need to be able to annotate the
outgoing HTML fragment with the effective language so that when it's
embedded somewhere, the right fonts
Apparently, the use cases I mentioned before have not been discussed yet:
- Localization of form controls in languages where browser support
is lacking, such as some minor languages.
- Localization of HTML elements, especially date formatting of span
and div elements in the page's default
On Mon, 16 Sep 2013, Peter Occil wrote:
- Localization of form controls in languages where browser support is
lacking, such as some minor languages.
- Localization of HTML elements, especially date formatting of span and
div elements in the page's default language [...]
You said these
On Aug 8, 2013, at 7:29 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
2013-08-08 2:57, Ryosuke Niwa wrote:
On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
[...]
But regarding the effect of language markup on fonts, the effect is
limited to situations where the
2013-08-08 2:57, Ryosuke Niwa wrote:
On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
[...]
But regarding the effect of language markup on fonts, the effect is
limited to situations where the font is not specified in a style
sheet. This is a rather uncommon scenario
On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
2013-08-02 2:43, Ryosuke Niwa wrote:
Are you saying that for HTML contenteditable-based editors that want to
support drag-and-drop editing, they need to be able to annotate the
outgoing HTML fragment with the effective
2013-08-02 2:43, Ryosuke Niwa wrote:
Are you saying that for HTML contenteditable-based editors that want to
support drag-and-drop editing, they need to be able to annotate the
outgoing HTML fragment with the effective language so that when it's
embedded somewhere, the right fonts get used?
On Jul 16, 2013, at 11:25 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 16 Jul 2013, Takayoshi Kochi ($B2OFb(B $BN4?N(B) wrote:
IIUC WebKit uses internally node's language to determine which font to use
to render text,
e.g for Han unification
On Tue, 16 Jul 2013, Takayoshi Kochi (河内 隆仁) wrote:
IIUC WebKit uses internally node's language to determine which font to use
to render text,
e.g for Han unification (https://en.wikipedia.org/wiki/Han_unification)
WebKit has to choose
a proper glyph depending on its lang attribute for the
IIUC WebKit uses internally node's language to determine which font to use
to render text,
e.g for Han unification (https://en.wikipedia.org/wiki/Han_unification)
WebKit has to choose
a proper glyph depending on its lang attribute for the same Unicode
codepoint.
Matt (falken@) knows more about
(resending from correct address)
On Tue, Jul 16, 2013 at 10:18 AM, Takayoshi Kochi (河内 隆仁)
ko...@google.com wrote:
IIUC WebKit uses internally node's language to determine which font to use
to render text,
e.g for Han unification (https://en.wikipedia.org/wiki/Han_unification)
WebKit has to
On Fri, 12 Jul 2013, Peter Occil wrote:
Well, my true hope is that such a DOM attribute like language will be
specified in the HTML or DOM spec. Especially since it's not currently
possible to get the language of a node through JavaScript methods alone.
What's the use case for having this
There are several use cases:
- Localization of form controls in languages where browser support
is lacking, such as some minor languages.
- Localization of HTML elements, especially date formatting of span
and div elements in the page's default language, see especially [1].
When it comes to
On Wed, 24 Apr 2013, Peter Occil wrote:
Well in my case, I have written an HTML parser in Java and C# [1][2],
which parses HTML documents and returns an object that implements a
subset of the DOM, so far. As far as possible, I included only methods
and attributes that were specified in
Well, my true hope is that such a DOM attribute like language will be
specified in the HTML or DOM spec. Especially since it's not currently
possible to get the language of a node through JavaScript methods alone.
See [1] and its replies.
--Peter
[1]:
On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil pocci...@gmail.com wrote:
I have no objection to the name baseLang rather than language as the
name of the DOM attribute.
But if there isn't more interest or you decide not to add this DOM
attribute, I encourage you to at least:
fwiw WebKit
On Wed, May 1, 2013 at 1:49 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, May 1, 2013 at 8:01 PM, Elliott Sprehn espr...@chromium.orgwrote:
fwiw WebKit (and Blink) implement this through CSS inheritance since you
need to know the lang for all kinds of things and walking up the DOM
On Wed, May 1, 2013 at 9:01 AM, Elliott Sprehn espr...@chromium.org wrote:
fwiw WebKit (and Blink) implement this through CSS inheritance since you
need to know the lang for all kinds of things and walking up the DOM
repeatedly would be expensive.
-webkit-locale is inherited by default and
On Wed, Apr 24, 2013 at 6:49 AM, Peter Occil pocci...@gmail.com wrote:
While a language attribute on Node may also be useful to
HTML+RDFa processors in JavaScript, I have no plans to implement
such a processor in JavaScript, though.
There's https://www.w3.org/Bugs/Public/show_bug.cgi?id=16489
I have no objection to the name baseLang rather than language as the
name of the DOM attribute.
But if there isn't more interest or you decide not to add this DOM
attribute, I encourage you to at least:
* define a DOM attribute to get the value of the document's Content-Language
header
I believe there should be a DOM attribute that returns the language of a node,
as defined in section 3.2.3.3 The lang and xml:lang attributes.
While there is a lang DOM attribute, it's inadequate because it's only
affected by the element's lang content attribute. Also, I don't see a way to
(13/04/23 16:44), Peter Occil wrote:
I believe there should be a DOM attribute that returns the language
of a node, as defined in section 3.2.3.3 The lang and xml:lang
attributes.
What's your use case? If you want to style a particular language then
there's the CSS :lang() pseudo-class.
Use
25 matches
Mail list logo
