RESOLVED CONFIGURATION CHANGED 153125
<area shape> should be ASCII-case-insensitive 
https://bugs.webkit.org/show_bug.cgi?id=153125
Summary <area shape> should be ASCII-case-insensitive
Simon Pieters (:zcorpan)
Reported 2016-01-15 06:14:31 PST
Version 9.0.2 (11601.3.9, r195011) The <area shape> attribute is compared in a Unicode-case-insensitive manner but the spec requires ASCII-case-insensitive. LATIN CAPITAL LETTER I WITH DOT ABOVE <area id="area" shape="CİRCLE" coords="20,40,10"> or LATIN SMALL LETTER DOTLESS I <area id="area" shape="cırcle" coords="20,40,10"> ...should be like shape="foobar" (rectangle state, the invalid value default), but are circles. Spec: https://html.spec.whatwg.org/multipage/infrastructure.html#enumerated-attribute Tests: https://github.com/w3c/web-platform-tests/pull/2478
Attachments
Add attachment proposed patch, testcase, etc.
Simon Pieters (:zcorpan)
Comment 1 2016-01-15 06:26:08 PST
Hmm... actually, it appears the value is compared ASCII-case-insensitively, it's just that the invalid value default depends on how many numbers are found in coords. But the spec says that shape=rect should be used...
Simon Pieters (:zcorpan)
Comment 2 2016-01-15 06:50:55 PST
In webdevdata all the ones that have a missing/invalid shape use 4 values in coords.
Ahmad Saleem
Comment 3 2022-08-01 15:25:27 PDT
From the test case links in Comment 0 from WPT (Safari 15.6 on macOS 12.5) only fails on following sub-test: even-odd rule: "100,100,200,100,100,200,150,50,200,200" (poly) http://w3c-test.org/html/semantics/embedded-content/the-area-element/area-processing.html I don't know whether it is related to this bug or not but just wanted to share updated status. Although, this seems to be more relevant: http://w3c-test.org/html/semantics/embedded-content/the-area-element/area-coords.html ^ In above, Chrome Canary 106 and Safari 15.6 passes all test but Firefox Nightly 105 fail in 22 tests.
Ryosuke Niwa
Comment 4 2022-08-01 21:19:08 PDT
I think this was fixed by Darin's case sensitivity refactoring at some point.
Darin Adler
Comment 5 2022-08-02 12:15:16 PDT
No, there was not a case sensitivity problem here even when the bug was originally filed, the bug title was incorrect.
Darin Adler
Comment 6 2022-08-02 12:16:13 PDT
Wait, my mistake. This was about which type of case insensitivity, so I did fix it.
Darin Adler
Comment 7 2022-08-02 12:17:09 PDT
Ryosuke was right, I fixed this by accident in bug 153266; I thought I was just refactoring, but I was actually fixing incorrect semantics.
Darin Adler
Comment 8 2022-08-02 12:17:52 PDT
7 years ago!
Note You need to log in before you can comment on or make changes to this bug.