LLMs suck at CSS now, very tempting to try this and see if its simpler for LLMs to reason about
CSS as a Query Language
21–30 of 31 posts
Re: CSS as a Query Language
#22I feel like we need a name for css-the-syntax (and maybe -the-semantics) as separate from css-the-body-of-rules/functions/units/etc-defined-by-csswg.
There's juice in it, but it's hard to talk about and survey other uses without just searching GH for code using css parsers and just see what kind of shenanigans people are up to.
I've been playing around with a weird thing that's kinda like a template engine, but driven by a mix of a lightweight node-based markup language, css selectors for expressing what goes into the template, and a css-alike for controlling exactly how all of these parts come together.
Re: CSS as a Query Language
#23Earlier quoted context omitted.
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…
Yeah, that example is bad. The query doesn't require recursion, but they affirm it does by demonstrating a recursively-defined version of it. This is called "affirming the consequent"; "P -> Q" doesn't mean "Q -> P". Ironic, given the use of propositional logic throughout.
Re: CSS as a Query Language
#24Earlier quoted context omitted.
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…
Yeah, that example is bad. The query doesn't require recursion, but they affirm it does by demonstrating a recursively-defined version of it. This is called "affirming the consequent"; "P -> Q" doesn't mean "Q -> P". Ironic, given the use of propositional logic throughout.
doh, good point. will fix this, I acknowledge I sort of handwaved the example. thanks for the correction!
Re: CSS as a Query Language
#25Earlier quoted context omitted.
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...
Sure, I was more speaking to usage... I'd have to imagine that querySelector* dwarfs evaluate in actual usage. Chrome's stats put evaluate at about 5% of loads; I'm not sure they have tracking for querySelector.
Of course XPath has its place and is the better tool for some situations. On the PHP side XPath has been supported for a long time, while the querySelector stuff is quite new.
Re: CSS as a Query Language
#26I 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 w…
What's more fun is: LLMs too are really good at CSS selectors.
I've been building a document editing agent and I used this fact to present the document as HTML to LLM and make it query and pull pieces of documents into context by just specifying CSS selectors.
Works like magic!
Re: CSS as a Query Language
#27I feel like we need a name for css-the-syntax (and maybe -the-semantics) as separate from css-the-body-of-rules/functions/units/etc-defined-by-csswg. There's juice in it, but it's hard to talk about and survey other uses without just searching GH for code using css parsers and just see what kind of shenanigans people are up to. I've been playing around with a weird thing that's kinda like a template engine, but drive…
I think it's already pretty clearly separated in the standard:
https://www.w3.org/TR/selectors-3/
and this is what the DOM spec references, too (albeit at level 4):
https://dom.spec.whatwg.org/#selectors
So the common name "CSS selector" is already correct, or simply "selector"?
"DOM selector" would be nicer maybe and not contain "CSS", but also I'm not even sure if it's better, because selectors in static CSS or selectors used with different DOM engine (XML parser, PHP DOM API, whatever) and static markup outside of JS engine means we're talking about a diferent DOM than the one exposed to JS.
Also, some special selectors are directly tied to browser rendering and navigation, such as :hover or ::target-text.
So yes, maybe a minimal subset of the query syntax could benefit from a name that's not tied to the browser and CSS.
Re: CSS as a Query Language
#28I feel like we need a name for css-the-syntax (and maybe -the-semantics) as separate from css-the-body-of-rules/functions/units/etc-defined-by-csswg. There's juice in it, but it's hard to talk about and survey other uses without just searching GH for code using css parsers and just see what kind of shenanigans people are up to. I've been playing around with a weird thing that's kinda like a template engine, but drive…
I think it's already pretty clearly separated in the standard: https://www.w3.org/TR/selectors-3/ and this is what the DOM spec references, too (albeit at level 4): https://dom.spec.whatwg.org/#selectors So the common name "CSS selector" is already correct, or simply "selector"? "DOM selector" would be nicer maybe and not contain "CSS", but also I'm not even sure if it's better, because selectors in static CSS or sel…
CSS containing Stylesheet couples it pretty tightly to styling things, though. What about CSL, as in Cascading Selector Language?
Re: CSS as a Query Language
#29Reminds 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 :)
yeah sometimes you end up making something very cool almost by accident. i tried to make shell pipelines properly concatenative like forth and friends and that had a lot of unexpected neat digressions in metaprogramming
Re: CSS as a Query Language
#30I feel like we need a name for css-the-syntax (and maybe -the-semantics) as separate from css-the-body-of-rules/functions/units/etc-defined-by-csswg. There's juice in it, but it's hard to talk about and survey other uses without just searching GH for code using css parsers and just see what kind of shenanigans people are up to. I've been playing around with a weird thing that's kinda like a template engine, but drive…
I think it's already pretty clearly separated in the standard: https://www.w3.org/TR/selectors-3/ and this is what the DOM spec references, too (albeit at level 4): https://dom.spec.whatwg.org/#selectors So the common name "CSS selector" is already correct, or simply "selector"? "DOM selector" would be nicer maybe and not contain "CSS", but also I'm not even sure if it's better, because selectors in static CSS or sel…
For the generic selector naming I'd suggest "cascade selector/selectors" as that gives a hint of the origins and describes the actual function of it pretty well.