Hi, all. Greg Trzeciak: I did not know about Garden, thank you for the reference. In particular, I liked the way he talks about decoupling selectors and declarations. It is something I have been doing in my CSS for a long time: previously with SASS mixins, now with my library and calls to Racket functions in a CSS rule. But I had never thought about the practice in terms of decoupling selectors and declarations. It is a nice new frame for an existing picture.
Matthew Butterick: > None of the below is meant to deter your voyage of discovery! On the contrary, your feedback encourages to move on! :) > 1) Perhaps have a look at the approach used by the `xml` and `html` and `json` > libraries, which is 1) parse data from string, 2) store data in nested > structs, 3) generate new string from nested-struct thingy. I understand this approach, but I do not understand how it is better than what I proposed. Can you please elaborate on that? > 2) Maybe a metalanguage that embeds at the reader level, and expands certain > source strings into S-expressions? See http://docs.racket-lang.org/debug/ for > an example, where the `#R` prefix in source takes on special meaning. This idea of prefixing is interesting. I view it as separate from the previous one, though. I could have (or not) prefixes to either strings or S-expressions—in fact, in “debug”, the “#R” prefix is for S-expressions. I actually had a similar thing in a previous iteration of my language. Not at the reader level, but as macro called “css”. Here is an example: “(css [body {…}])”. I decided to drop it because it was nothing more than “#`”. What else do you think the prefix could do? How is it better than the macro version? > Notationally, how is this an improvement over regular CSS? And if it's not, > why not use regular CSS notation, and parse it? I believe it is easier to build syntactically correct S-expressions than it is to concatenate strings to form syntactically correct CSS. At the very minimum, there is a guarantee that there are no missing semicolons or closing braces. I also believe it is a simpler approach: parsing S-expressions with “syntax-parse” is simpler than parsing text. > 1) To write a library that actually parses and generates good CSS, I'd have to > keep up with the CSS spec, and all the browsers, and that gives me the > shivers. Then you will be happy to know that I did the work that gives you the shivers. I read the CSS specifications to make sure my library only generates syntactically correct CSS. Yes, it took me a while :) And yes, I plan on updating the library with respect to changes to the specification. Most changes to CSS are not syntactical, so it should not be too hard. > 2) Most of what I need is basic computational work — variable substitution, > math operations, string expansions — and I couldn't figure out what a separate > library would add that I couldn't already do with simple Racket functions > embedded in a Pollen source file. There are some things that are impossible to do with text manipulation alone. For example, to nest rules (in particular, “at rules” with media queries) and attributes. I believe those are powerful features because they allow for better organization and maintainability. So, even if I were to use Pollen preprocessor on stylesheets, I would be generating SASS. But, if “the book is a program” why shouldn’t the stylesheet be a program as well? :) * * * I plan to release this library for the general public. My idea is to publish it as soon as I finish working on the new version of my website, which is serving as testbed. But I am doing the strange things I mentioned on my original posting so I decided to collect feedback as soon as possible. Please keep the comments coming and stay tuned for the release of the library. I am not committing to any schedule, but I expect it to be ready by the end of this year. And thank you Greg Trzeciak and Matthew Butterick for the insightful messages! -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
