I find CSS selectors a lot easier to write than XPath. I recently gave a talk on how PHP's new DOM API makes working with HTML and CSS selectors natively very easy (previously you had to convert CSS to XPath).[1]
It's a shame that because CSS is still primarily for browser use and styling, we don't get nice things like the ability to select based on text content like we can with XPath. My understanding is that this was proposed but didn't make it into the spec because it could lead to performance issues in a browser rendering context.
Yeah, querySelector/querySelectorAll are totally widespread in client-side, it's nice to finally have them in PHP's newer DOM. Definitely what people are used to doing.
For instance, currently you can conditionally change a parent based on its children. For example, this `pre` could either have 16px or 0px of padding. Zero when its direct child is a `code` element.
tbh, this started as a connection of two disparate ideas ("hey, this thing looks like this other thing"), and then just kind of explores it in different directions.
I think the conclusion (which I may not have made clear enough) is less like "These are limitations of modern CSS which ought to be fixed" and more "Maybe a CSS-like syntax could be added to a Datalog-like system and that would be helpful for making it more accessible to more engineers, navigating tree-shaped data, etc"
The article describes a syntax for modifying the underlying data (adding new child elements or attributes to the DOM) for matching selectors, not resolving style changes in a single pass like you've shown.
I suspect they are replying to this part of the article:
"What you actually want to say is: “an element is effectively-dark if it has data-theme=”dark”, or if it has an effectively-dark ancestor with no effectively-light ancestor in between.” That’s a recursive relational definition. CSS cannot express it. CSSLog can:"
The entire article doesn't seem to mention the existence of :has() which is rather surprising given how recently it was written. Not even in the footnotes.
I find CSS selectors a lot easier to write than XPath. I recently gave a talk on how PHP's new DOM API makes working with HTML and CSS selectors natively very easy (previously you had to convert CSS to XPath).[1]
It's a shame that because CSS is still primarily for browser use and styling, we don't get nice things like the ability to select based on text content like we can with XPath. My understanding is that this was proposed but didn't make it into the spec because it could lead to performance issues in a browser rendering context.
[1] https://speakerdeck.com/keyvan/parsing-html-with-php-8-dot-4...
Yeah, querySelector/querySelectorAll are totally widespread in client-side, it's nice to finally have them in PHP's newer DOM. Definitely what people are used to doing.
document.evaluate is also widespread client-side.
https://developer.mozilla.org/en-US/docs/Web/API/Document/ev...
The project pyastgrep https://pyastgrep.readthedocs.io/en/latest/ can use CSS selectors as a query language for Python syntax (default is XPath).
e.g.:
pyastgrep --css 'Call > func > Name#main'
oh this is neat! Feels like exactly the sort of thing I was gesturing towards. Thanks :)
Reminds me of seeing this presented at a conference years ago https://github.com/braposo/graphql-css
It was a joke but I really like the way it pointed out how we copy and reapply patterns in different contexts and that might enable unexpected things.
oh this is fun
> we copy and reapply patterns in different contexts and that might enable unexpected things
yeah, that's exactly what I am trying to do here. Mostly it doesn't go anywhere, but it's interesting for the hacker spirit within me :)
Not sure I follow the scenario this would solve.
For instance, currently you can conditionally change a parent based on its children. For example, this `pre` could either have 16px or 0px of padding. Zero when its direct child is a `code` element.
tbh, this started as a connection of two disparate ideas ("hey, this thing looks like this other thing"), and then just kind of explores it in different directions.
I think the conclusion (which I may not have made clear enough) is less like "These are limitations of modern CSS which ought to be fixed" and more "Maybe a CSS-like syntax could be added to a Datalog-like system and that would be helpful for making it more accessible to more engineers, navigating tree-shaped data, etc"
thanks for the feedback, anyway!
The article describes a syntax for modifying the underlying data (adding new child elements or attributes to the DOM) for matching selectors, not resolving style changes in a single pass like you've shown.
I suspect they are replying to this part of the article: "What you actually want to say is: “an element is effectively-dark if it has data-theme=”dark”, or if it has an effectively-dark ancestor with no effectively-light ancestor in between.” That’s a recursive relational definition. CSS cannot express it. CSSLog can:"
The entire article doesn't seem to mention the existence of :has() which is rather surprising given how recently it was written. Not even in the footnotes.
Nice