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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
