- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Thu, 01 Aug 2013 16:43:31 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG <whatwg@whatwg.org>
On Jul 26, 2013, at 11:20 AM, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 24 Jul 2013, Ryosuke Niwa wrote: >> On Jul 16, 2013, at 11:25 AM, Ian Hickson <ian@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
Received on Thursday, 1 August 2013 23:43:56 UTC