256716 2023-05-12 10:02:25 -0700 DOMXPath- failing (fn-lang.html) due to U+212A handling 2025-05-22 10:41:30 -0700 1 1 1 Unclassified WebKit XML Safari Technology Preview Unspecified Unspecified RESOLVED CONFIGURATION CHANGED https://github.com/whatwg/dom/issues/1199 BrowserCompat, InRadar, WPTImpact P2 Normal --- 1 ahmad.saleem792 webkit-unassigned annevk ap cdumez darin mmaxfield rniwa webkit-bug-importer ysuzuki oldest_to_newest 1955026 0 ahmad.saleem792 2023-05-12 10:02:25 -0700 Hi Team, While going through WPT test cases, came across one sub-test failure: Test Case - https://wpt.fyi/results/domxpath/fn-lang.html?label=experimental&label=master&aligned Link - http://wpt.live/domxpath/fn-lang.html ___________ Researching bit on when this was added and against which bugs, it seems to be U+212A handling issue either in CSS or DOM level. Just raising, so we can fix it. Thanks! 1955313 1 ap 2023-05-14 12:05:37 -0700 // U+212A should match to ASCII 'k'. // XPath 1.0 says: // ... such that the attribute value is equal to the argument ignoring that suffix // of the attribute value and ignoring case. // XPath 3.1 says: // ... true if and only if, based on a caseless default match as specified in // section 3.13 of The Unicode Standard, testFirstChild('lang("ko")', '<root><match xml:lang="&#x212A;o"/></root>'); ------- So this test says that U+212A KELVIN SIGN should match letter "k" in lang attribute, which seems weird, at least initially. The Unicode Standard reference here is obsolete, but is almost certainly about "caseless matching" in https://www.unicode.org/versions/Unicode15.0.0/ch05.pdf. Which indeed has this behavior, but the rest of the Web platform does not AFAIK. Notably, even Chrome doesn't have this behavior for CSS selector matching. I think that this is a bug in the standard, and Chrome is internally inconsistent, so we shouldn't be following it. CC'ing some folks who've done more recent work in this area to weigh in. 1955314 2 466349 ap 2023-05-14 12:05:56 -0700 Created attachment 466349 CSS selector test 1955349 3 annevk 2023-05-14 23:47:22 -0700 Looking at the source of the test it seems this was done based on an XPath 3.1 clarification, but indeed we use ASCII case-insensitive for language matching across the web platform. Let's change this test and add a clarification to DOM/HTML with regards to what kind of matching the XPath lang() function uses. 1956524 4 webkit-bug-importer 2023-05-19 10:03:20 -0700 <rdar://problem/109571692> 2024854 5 ahmad.saleem792 2024-03-29 16:36:09 -0700 Modifying the test upstream in WPT - https://github.com/web-platform-tests/wpt/pull/45436 2119014 6 ahmad.saleem792 2025-05-22 10:41:30 -0700 Syncing test here - https://github.com/WebKit/WebKit/pull/45768, so I don't think anything else to do here since we updated test upstream. Marking this as `RESOLVED CONFIGURATION CHANGED`. 466349 2023-05-14 12:05:56 -0700 2023-05-14 12:05:56 -0700 CSS selector test test.html text/html 137 ap PHN0eWxlPgpkaXZbbGFuZz1rb10gewpjb2xvcjogZ3JlZW47Cn0KPC9zdHlsZT4KCjxkaXYgbGFu Zz0i4oSqbyI+4oSqbyAod2l0aCBVKzIxMkEpPC9kaXY+CjxkaXYgbGFuZz0iS28iPktvPGRpdj4K PGRpdiBsYW5nPSJrbyI+a288ZGl2Pgo=