3 ms·
In your example you say "Once in memory, this structure can be easily outputted as CSS." I think you may be underestimating how hard this will be. CSS may loo
by haberman 15y ago
In your example you say "Once in memory, this structure can be easily outputted as CSS." I think you may be underestimating how hard this will be. CSS may look like it's just a bunch of maps, but there is more to it than that. Consider something funky like:
#id > p a.red:visited {
background: url(foo.png) white;
margin: 0 3px 5em 80% ! important;
}
There's a lot going on here. CSS isn't just key/value maps.
Also, I don't think you want a data language to be Turing-complete. PostScript was Turing-complete but PDF is not; this makes PDF easier to deal with because it's easier to analyze and there's no risk of it getting into an infinite loop.
- andrewflnr 15y agoTrue, I'll confess I didn't know much about the more arcane CSS selectors when I wrote that (still don't). Complicated properties, though, are not too hard, and the important thing is that it starts off in a form that's easy to process. I don't intend it to be just a data language. What I've been moving toward in my daydreams is a DAG of, for lack of a better word, function calls (some interesting data doesn't really fit in a tree), some of which are generators. If Turing-completeness is a problem in your context, you can reject some or all generators and/or just not evaluate them, i.e. take them as pure data. But I don't want to limit myself. I would have no problem if it turned into a general purpose language with a nice data-oriented subset.