[webkit-reviews] review denied: [Bug 76701] Use content-language to set document locale and font : [Attachment 123711] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 24 09:33:50 PST 2012


Alexey Proskuryakov <ap at webkit.org> has denied Matt Falkenhagen
<falken at chromium.org>'s request for review:
Bug 76701: Use content-language to set document locale and font
https://bugs.webkit.org/show_bug.cgi?id=76701

Attachment 123711: Patch
https://bugs.webkit.org/attachment.cgi?id=123711&action=review

------- Additional Comments from Alexey Proskuryakov <ap at webkit.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=123711&action=review


> Source/WebCore/ChangeLog:3
> +	   Use content-language to set document locale and font

Does this work in Firefox and/or IE?

> Source/WebCore/css/CSSStyleSelector.cpp:1238
> +    if (!document->contentLanguage().isEmpty())
> +	   documentStyle->setLocale(document->contentLanguage());

What guarantees correct precedence of these hints? In tests, I see that a lang
attribute on a node takes precedence. Are there any locale hints already
implemented in WebKit for which precedence needs to be tested?

> Source/WebCore/css/CSSStyleSelector.cpp:1272
> -	   const AtomicString& stdfont = settings->standardFontFamily();
> +	   const AtomicString& stdfont =
settings->standardFontFamily(fontDescription.script());

It's not a new name, but "stdfont" is of course not in accordance to WebKit
coding style.

> Source/WebCore/dom/Document.cpp:1096
> +void Document::setContentLanguage(const String& language)

I think that this name should make it clear that we're parsing it in accordance
to pragma rules. "This pragma is not exactly equivalent to the HTTP
Content-Language header. [HTTP]"

HTML5 itself calls this "pragma set default language".

> Source/WebCore/dom/Document.cpp:1102
> +    size_t pos = strippedLanguage.find(' ');

Please check for all HTML whitespace characters, not just U+0020. I don't think
that simplifyWhiteSpace() gets you exactly that, not to mention that it's
unnecessarily slow to modify the string.

> Source/WebCore/dom/Document.cpp:1107
> +	   recalcStyle(Force);

I don't know if it's OK to make this call here. We don't do that often in
Document.cpp.

Could you please check with a layout&rendering expert?

> Source/WebCore/dom/Document.cpp:2715
> +	   if (contentLanguage().isEmpty())
> +	       setContentLanguage(content);

It may be a mistake in the spec that an empty or invalid Content-Language can
be overwritten with a later pragma. Why the special case?

> Source/WebCore/dom/Document.cpp:2716
> +    } else if (equalIgnoringCase(equiv, "x-dns-prefetch-control"))

Unrelated to this patch, but I wonder if any other pragmas need to be respected
only once. It can be important to not let attacker controlled content override
these values.

> LayoutTests/fast/text/content-language-multiple-tags.html:4
> +<meta http-equiv="content-language" content="zh-CN"/>

These are all HTML files - why do you put the slash in the end? It's just
ignored by the parser.

> LayoutTests/fast/text/content-language-multiple-tags.html:7
> +<link rel="stylesheet" href="../js/resources/js-test-style.css" />

Ditto.

> LayoutTests/fast/text/international/content-language-font-selection.html:4
> +<meta http-equiv="content-language" content="zh-tw"/>

It looks like all tests have a lower case "content-language" string. Please
test that it's case insensitive.


More information about the webkit-reviews mailing list