Making this bug with a narrower scope than bug 76364 since the first patch doesn't deal with SVG.
Created attachment 130943 [details] Patch
Comment on attachment 130943 [details] Patch r=me assuming this passes in Firefox, otherwise let's discuss any differences first.
Thanks for the review. This tests mapping of lang to -webkit-locale which I think doesn't have an analogue in Firefox. One thing I'll try to do is confirm that Firefox computed language is the same as all the -webkit-locale values here, by using the CSS :lang selector or in the inspector. I don't know if there is a way to programmatically get the computed language.
Makes sense to me.
I found Firefox computed language has the same behavior, with one change: Firefox does not set xml:lang with setAttributeNode but does with setAttributeNodeNS. It looks like it's incorrect to use setAttributeNode for namespaced attributes, so I've revised the patch to use setAttributeNodeNS. Also, both Firefox and WebKit do an interesting thing when lang is set to the empty string. According to the HTML 5 spec, the empty string means the language is explicitly unknown, which I think means that lang shouldn't be inherited from the parent. But for the CSS :lang selector, both browsers inherit lang, while for font selection, lang is not inherited. For example, in: <div lang="ko" id="x1">x1 <div id="x2">x2</div> <div id="x3" lang="">x3</div> </div> x1 and x2 are in the font for Korean and get CSS styling for :lang(ko), while x3 has CSS styling for :lang(ko) but is not in the font for Korean. For WebKit, this happens because the :lang selector implementation climbs the DOM tree until it finds a non-empty lang. In contrast, font selection depends on -webkit-locale, which is mapped to "auto" when lang is empty, instead of being inherited. This behavior is the same regardless of whether lang is set dynamically or not. I'm thinking it's okay to keep the behavior as is, since at least it matches Firefox and setting lang to the empty string is probably an uncommon use case. (Also, I just tested IE, and it looks like it does the same thing.)
Created attachment 131295 [details] use setAttributeNodeNS
Comment on attachment 131295 [details] use setAttributeNodeNS > I found Firefox computed language has the same behavior, with one change: Firefox does not set xml:lang with setAttributeNode but does with setAttributeNodeNS. It looks like it's incorrect to use setAttributeNode for namespaced attributes, so I've revised the patch to use setAttributeNodeNS. This sounds like a bug that needs to be fixed in WebKit, correct?
Comment on attachment 131295 [details] use setAttributeNodeNS Clearing flags on attachment: 131295 Committed r110440: <http://trac.webkit.org/changeset/110440>
All reviewed patches have been landed. Closing bug.
(In reply to comment #7) > (From update of attachment 131295 [details]) > > I found Firefox computed language has the same behavior, with one change: Firefox does not set xml:lang with setAttributeNode but does with setAttributeNodeNS. It looks like it's incorrect to use setAttributeNode for namespaced attributes, so I've revised the patch to use setAttributeNodeNS. > > This sounds like a bug that needs to be fixed in WebKit, correct? Yes, I think so.