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?
Yes, but not just for drag and drop.
This would mean that the editor would have to guess the language from
the text or ask the user to specify it. This is not as unrealistic as it
may first seem. Microsoft Word does such things, sometimes getting
things right, often messing things up. It typically detects change of
language too late, and often infers language from keyboard settings,
making it rather impossible to use a multilingual keyboard easily.
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 these days; authors are more than
eager to set fonts. It is true that they might specify a font list where
none of the fonts supports some characters that might be entered, and
then a fallback font would be used. However, using “annotations”
(presumably, lang attributes, along with extra <span> elements when
needed) does not sound like a feasible approach to this.
But I guess the issue is still adding a DOM property for element nodes,
specifying the language of the node, to the extent that it can be
inferred from lang or xml:lang attribute or from HTTP headers (real or
faked via <meta>). Although the use cases are somewhat rare and not
particularly important, the property would be conceptually easy and
presumably easy to implement in browsers. So it could be added, well,
just because there is no good reason not to. It may understandably
irritate authors who need language information that they know that the
browser has it (it needs it to implement :lang() in CSS) but does not
give authors access to it.
Yucca
