Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define XPath's lang() as ASCII case-insensitive #1199

Open
annevk opened this issue May 15, 2023 · 7 comments
Open

Define XPath's lang() as ASCII case-insensitive #1199

annevk opened this issue May 15, 2023 · 7 comments

Comments

@annevk
Copy link
Member

annevk commented May 15, 2023

In https://bugs.webkit.org/show_bug.cgi?id=256716 I was made aware of https://wpt.fyi/results/domxpath/fn-lang.html (added in web-platform-tests/wpt@292d532) where apparently Chromium and Gecko follow the XPath 3.1 definition of lang() matching which is not in line with how the web platform matches languages.

I think it would be better if we define this to be ASCII case-insensitive instead.

cc @tkent-google @petervanderbeken

@tkent-google
Copy link
Collaborator

I think it's ok to change it to ASCII case-insensitive.

Ahmad-S792 added a commit to web-platform-tests/wpt that referenced this issue Mar 30, 2024
Hi Team,

Based on GitHub Issue - whatwg/dom#1199

Added comment to not follow 'XPath 3.1' and referenced above issue in comment.

- fn-lang.html: Updated to use `unmatch` for U 212A handling case

Thanks!
@Ahmad-S792
Copy link

Thanks to @annevk - I have updated WPT test. What would be next steps?

@annevk
Copy link
Member Author

annevk commented Mar 30, 2024

#67 I suppose. And I guess once we're further along we need some kind of section that defines the subset of XPath we care about.

@dbaron
Copy link
Member

dbaron commented Apr 1, 2024

Is this intended to be a change to all uses of XPath (including those from XSLT) or only those from the DOM APIs?

Also, is the matching intended to follow RFC4647 like selectors does? Chromium's current matching code and Gecko's current matching code appear to do a more naive matching of an initial hyphen-separated sequence.

@annevk
Copy link
Member Author

annevk commented Apr 2, 2024

I would expect "browser" XPath to be the same in XSLT and through an API. Not sure how much it should follow Selectors. I suspect it should largely follow XPath 1.0 modulo some XPath 2.0 extensions browsers chose to implement.

@dbaron
Copy link
Member

dbaron commented Apr 2, 2024

For what it's worth, XPath 1.0's definition was vague ("ignoring case") and the definition in XPath 2.0 and the definition in XPath 3.1 specify caseless default match.

@dbaron
Copy link
Member

dbaron commented Apr 2, 2024

I wrote a CL to make this change in Chrome.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Apr 10, 2024
…low XPath Specification, a=testonly

Automatic update from web-platform-tests
Update `U 212A` handling case to not follow XPath Specification (#45436)

Hi Team,

Based on GitHub Issue - whatwg/dom#1199

Added comment to not follow 'XPath 3.1' and referenced above issue in comment.

- fn-lang.html: Updated to use `unmatch` for U 212A handling case

Thanks!
--

wpt-commits: 16f18d8135a80e89f2e910ca7548999fa2f7937e
wpt-pr: 45436
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this issue Apr 15, 2024
…low XPath Specification, a=testonly

Automatic update from web-platform-tests
Update `U 212A` handling case to not follow XPath Specification (#45436)

Hi Team,

Based on GitHub Issue - whatwg/dom#1199

Added comment to not follow 'XPath 3.1' and referenced above issue in comment.

- fn-lang.html: Updated to use `unmatch` for U 212A handling case

Thanks!
--

wpt-commits: 16f18d8135a80e89f2e910ca7548999fa2f7937e
wpt-pr: 45436
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants