[whatwg] HTML: A DOM attribute that returns the language of a node

Thu Aug 1 16:43:31 PDT 2013

On Jul 26, 2013, at 11:20 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 24 Jul 2013, Ryosuke Niwa wrote:
>> On Jul 16, 2013, at 11:25 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> 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 same Unicode 
>>>> codepoint.
>>> 
>>> Sure, but internal UA uses aren't use cases for the Web.
>>> 
>>> The use cases Peter gave over the weekend are valid, though.
>> 
>> The fact browsers use the "effective" language for font selection is 
>> very relevant in HTML editing. For example, consider the following 
>> document:
>> 
>> <!DOCTYPE html>
>> <html lang="ja>
>> <html>
>> <body>
>> <section lang="zh">
>> <p id="source">僧廐埩</p>
>> </section>
>> <blockquote>
>> <p id="destination"></p>
>> </blockquote>
>> </body>
>> </html>
>> 
>> If you were to get the innerHTML of #source and insert it into 
>> #destination, the effective language changes from Chinese and Japanese 
>> and the three characters transform their shapes because browsers will 
>> use different fallback fonts.
> 
> It's unclear to me what use case you are describing here.
> 
> 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?

Yes, but not just for drag and drop.

> This seems like something that browsers should just do automatically for 
> copy-and-paste and drag-and-drop, I wouldn't want to require that every 
> contenteditable-based editor have to reimplement this. That seems like a 
> lot of redundant work, and in particular, seems to be work that most 
> editor implementors would forget. If the browsers just did the annotation 
> automatically, then this would work even in editors whose implementors 
> didn't worry about i18n.

How are browsers supposed to do this if the author was simply using innerHTML?

I don't see how we can automatically annotate innerHTML.

- R. Niwa