3 ms·
Hmmm. I kind of like CSS but I hate the creep-up of complexity. It's not that I don't understand the rationale - any programming language offers more power tha
by shevy-java 5mo ago
Hmmm. I kind of like CSS but I hate the creep-up of complexity.
It's not that I don't understand the rationale - any programming
language offers more power than a non-programming language. But
I'd rather think here that something else could instead replace
all of HTML, CSS and JavaScript, rather than constantly wanting
to make everything more complex. I don't use most of the new
elements in HTML5, largely because I don't see the point in
using specialized tags for micro-describing a webpage. I succumbed
to the "it is a div-HTML tag and it has a unique ID"; that's what
I think mots of those containers actually really are. I even wanted
to have aliases to such IDs, simply to use as navigational href
intralink.
[data-theme="dark"] [data-theme="light"] :focus {
outline-color: black;
}
And I also don't like this. It takes my brain too long
to process all of that. It is no longer elegant and simple.
On the other hand:
h2 {
color: red;
}
That is still simple.
So ancestor(X, Y) :- parent(X, Y). means: “For all possible values of X and Y, X
is an ancestor of Y, if X is a parent of Y.”
See - I already don't want to have to think in such terms. What is the :- anyway, looks like a smiley.
@container style(--theme: dark) {
.card { background: royalblue; color: white; }
}
I stopped there.
I think this is a problem with CSS - too many people are
ruining it. It is strange to see how standards that used
to work, are degraded over time.
- evnc 5mo agoyeah I mean, to be clear, I'm less proposing "What if we add even more syntax and semantics to CSS" and more "what if we steal ideas from CSS, notice their similarity to logic / relational query languages, and use them to build something new". I probably could have articulated some of this better. eg this example: [data-theme="dark"] [data-theme="light"] :focus { outline-color: black; } means, in English/pseudocode, roughly: "If you have an element X with attribute data-theme="dark", and X has a child Y with attribute data-theme="light", and Y is focused, then the outline-color of Y is black". so we could write this also as, e.g.: outline-color(Y, black) if data-theme(X, "dark") and parent(X, Y) and data-theme(Y, "light") and focused(Y) that's Datalog, except I went ahead and replaced :- with "if" and "," with "and". if we want even more syntax sugar, we could do: Y.outline_color := black if X.data-theme == dark and Y.parent == X and Y.data-theme == dark and Y.focused imagine `X.attr == val` <==> `attr(X, val)` as a kind of UFCS for Datalog to make it palatable to Regular Programmers, right the declaration and scope of these variables is implicit here; if you want something even more ALGOL-family, we could write forall Y { Y.outline_color := black if Y.data_theme == "dark" and Y.focused and Y.parent.data_theme == "light" } here we've explicitly introduced Y, and made one of our joins implicit, and it looks even more like Regular Programming now, except the Datalog engine (or equivalent) is kind of running all these loops for you, every time one of their dependencies changes, in an efficient way ...
- evnc 5mo agoone more, for completeness: SELECT 'black' AS outline_color FROM elements parent JOIN elements child ON parent.id = child.parent_id WHERE parent.data_theme = 'light' AND child.data_theme = 'dark' AND child.focused = true there's a lot of ways to express the same thing! it's interesting to notice the connections between them, I think, and their strengths and weaknesses, e.g. I probably wouldn't want to write my whole design system in SQL, but since it's relational queries over the elements structure and properties, you could.