Summary: | text-transform:capitalize is failing in CSS2.1 test suite | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Shinichiro Hamaji <hamaji> | ||||
Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Normal | CC: | adamk, adele, ap, bdakin, darin, eric, hyatt, ian, mitz | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | OS X 10.5 | ||||||
Attachments: |
|
Description
Shinichiro Hamaji
2009-10-02 04:57:20 PDT
Created attachment 40511 [details]
Patch v0
(In reply to comment #1) > Created an attachment (id=40511) [details] > Patch v0 If we decide to make the CSS2.1 test suite pass, I'll refine this patch a bit. Comment on attachment 40511 [details]
Patch v0
Is this approach really correct? Shouldn't this be fixed inside the text break function instead?
(In reply to comment #3) > (From update of attachment 40511 [details]) > Is this approach really correct? Shouldn't this be fixed inside the text break > function instead? It seems that the word break iterator is used by selection in editing, too. I guess changing word break iterator causes regressions for selection. For example, if you double click 'o' in "(foo bar)", current implementation selects "foo". If we change wordBreakIterator, "(foo" would be selected. But, it's just my guess. I didn't confirm if my guess is true. I'll check it. Or, I'm happy if someone who knows editing well gives comments. I think we really need some input from CSS experts. We have here the ICU library’s concept of word breaks, and then the CSS concept of what words are capitalization-wise. We also are not considering the language. It’s challenging to change this without being sure what the desired behavior is. I suppose the CSS test suite makes it clear we’re wrong to be using the ICU concept? Yeah, I agree. I want advices from CSS experts. Thanks Darin for adding dhyatt into the CC lists. By the way, it seems that a microsoft person is saying that the result should be "(É.é. ÉÉ)" so IE and Firefox are OK because of the word breaking rule in Unicode. I'm not sure Unicode's rule should be applied to this style though. http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/0040.html http://www.unicode.org/reports/tr29/tr29-13.html#Word_Boundaries Any thoughts Ian or Hixie? Comment on attachment 40511 [details]
Patch v0
I don't think the test suite behavior is either correct or required by the spec. The test's expectation is just wrong. If we match any other browser, it should be Firefox. I don't think the Opera behavior gives good results. r- to either reconsider this or try a different approach. Input from experts still welcome.
(In reply to comment #8) > (From update of attachment 40511 [details]) > I don't think the test suite behavior is either correct or required by the > spec. The test's expectation is just wrong. If we match any other browser, it > should be Firefox. I don't think the Opera behavior gives good results. r- to > either reconsider this or try a different approach. Input from experts still > welcome. Thanks for the comment and sorry for the latency. I played with Firefox and found the logic is not as simple as I expected. For example, no capitalization occurs for "あfoo" but "、foo" becomes "、Foo". I think I have too few knowledges around this to fix this issue correctly. I give up to fix this issue for now :( Rebaselined a bunch of Chromium results, including t1605-c545-txttrans-00-b-ag, in http://trac.webkit.org/changeset/109625. This may be a "bad" baseline, but decided it was better to have it checked in than to keep this test marked as "failing" for years. |