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

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 get used?
> 
> Yes, but not just for drag and drop.

Sure, also for copy-and-paste, etc. The point is that browsers need to 
provide this for at least some of the cases.


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

How would an author use innerHTML here?


I agree that there's a use case for providing language information, my 
point is just that this use case seems to need more than just that: it 
also needs that browsers add language annotations during drag-and-drop and 
copy-and-paste, at least. Is there anything else that it needs?

Will putting language information on drag-and-drop or copy/paste content 
have any Web compat impact?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 16 September 2013 22:03:45 UTC