Possible bug on query[_one] method? #1041
mindset-team
started this conversation in
General
Replies: 3 comments
-
Beta Was this translation helpful? Give feedback.
0 replies
-
Just to update, after first implementing the fully case-insensitive approach, we've decided that it'll be better to follow the Web here and go the other way, and enforce case-sensitive. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Full case-sensitivity now implemented via #1077. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
There's seems to be some case sensitivity issue with query/query_one. Here's an example app where widget id must be lower-cased in order to return a valid query result (vs. a
NoMatches
exception). The query selector seems to be case-insensitive.Above,
on_key
is simply used to trigger the query event andtextual console
opened in another terminal to monitor print output.The code above fails with
NoMatches: No nodes match <DOMQuery GridLayoutExample(title='GridLayoutExample') filter='#One'
However, changing
id=One
toid=one
(in compose method yielding the static widget) works, no exception raised and console printout is valid:Is this behavior expected? It seems counter-intuitive that a selector would be case insensitive, but id would be coerced to be lower-cased for a query to work. I couldn't find any reference to case-[in]sensitivity in the textualize.io guide, or on github (after a quick review of the textual css parsing code and def query).
Not sure this elevates to a bug (and anyway maintaining all ID's in lower-case would avoid this issue) but since many of the examples have
#One, #Two
identifiers throughout the docs, the issue seems to merit a discussion here, a clear instruction in the docs, or designating as a bug to fix. Thoughts?Beta Was this translation helpful? Give feedback.
All reactions