What CSS syntax should we use?

[lassik]

We should have some S-expression syntax for CSS, but which one?

[amirouche]

Thanks for starting this pre-SRFI.

I was thinking about that, css can be represented with alist like:

(define root '((color black) (margin "15px" "10px") (background (rgba 200 10 10 0.6)) (padding-left "15px"))

It does not require a lot of knowledge of css syntax to convert to valid css. Most values can be symbols except things that have a measure like "15px". There is also the case of (hsla ...) and (rgba ...).

There is no need to have specific logic to translate values depending on the key, that would be too much work especially when you consider that css is somewhat a moving target, but also that the actual semantic is prolific.

[johnwcowan]

Peter Bex's blog post https://www.more-magic.net/posts/lispy-dsl-scss.html isn't quite a concrete proposal, but I think it's extremely important that anyone working on this read it carefully before making any concrete proposals. In particular, an analysis needs to be done that will enable CSS to be generated flexibly from Scheme code, rather than just sexpifying CSS directly. Too much of CSS is basically designed for hand-authoring rather than generation.

[lassik]

Thanks, Peter's blog is great!

Whoa, those CSS examples are crazy. In preparation for this pre-SRFI a few weeks back, I tried to skim and digest the CSS3 spec and it was practically impossible. I can't remember whether it even had a full grammar.

[lassik]

From his SXML post:

This is another important aspect of good DSLs; they tend to ignore surface syntax. Instead, they map the underlying tree-like structure to S-expressions.

I agree in general, but CSS is so byzantine (and will probably grow even more in CSS4) that it seems quite hopeless :-/ Would it be possible to make a complete surface syntax representation using S-expressions?

[mnieper]

You could try to design a CSS writer first, using SRFI 166. The Chibi-Scheme implementation contains a module that outputs formatted C code in the same way.

Am Mo., 21. Sept. 2020 um 16:47 Uhr schrieb Lassi Kortela < notifications@github.com>:

From his SXML post:

This is another important aspect of good DSLs; they tend to ignore surface syntax. Instead, they map the underlying tree-like structure to S-expressions.

I agree in general, but CSS is so byzantine (and will probably grow even more in CSS4) that it seems quite hopeless :-/ Would it be possible to make a complete surface syntax representation using S-expressions?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/minimal-html-css-writer/issues/1#issuecomment-696163876, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDTQZOXATTKKKV634NOSTSG5RO5ANCNFSM4RUMNBEA .

[johnwcowan]

I think the writer is the most important thing; a parser is probably not necessary at all. If your stylesheet is already in CSS, leave it that way. Similarly, many languages compile to JS, but few if any come with decompilers that turn the JS back into the original language.

But Peter's concerns are very good ones. Again I urge a careful reading of it on all interested parties (only 3000 words, including the examples). It's also worded as a tutorial, albeit a bit dense for that.

On Mon, Sep 21, 2020 at 10:49 AM Marc Nieper-Wißkirchen < notifications@github.com> wrote:

You could try to design a CSS writer first, using SRFI 166. The Chibi-Scheme implementation contains a module that outputs formatted C code in the same way.

Am Mo., 21. Sept. 2020 um 16:47 Uhr schrieb Lassi Kortela < notifications@github.com>:

From his SXML post:

This is another important aspect of good DSLs; they tend to ignore surface syntax. Instead, they map the underlying tree-like structure to S-expressions.

I agree in general, but CSS is so byzantine (and will probably grow even more in CSS4) that it seems quite hopeless :-/ Would it be possible to make a complete surface syntax representation using S-expressions?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/pre-srfi/minimal-html-css-writer/issues/1#issuecomment-696163876 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAHDTQZOXATTKKKV634NOSTSG5RO5ANCNFSM4RUMNBEA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/minimal-html-css-writer/issues/1#issuecomment-696165339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPPBSWG65M3NBOQVUPUVLSG5RYNANCNFSM4RUMNBEA .

[lassik]

Agreed, this SRFI should only have a writer, not a reader. It's very useful to be able to generate HTML from even the simplest Scheme implementations, since HTML is much nicer than text for making reports of all kinds. If the SRFI is simple, it will encourage it to be widely implemented.

A full CSS3 parser and representation is so complex it could almost be an undergraduate thesis :) But for this SRFI, it would be nice to have a S-expression representation that is a subset of a full-featured representation. So that if a full representation is invented, it wouldn't be gratuitously different in the common parts.

Racket already has one S-expression CSS syntax, but I don't think it can handle the full CSS3. IIRC there's a Common Lisp library also. And ClojureScript has something that I think I used at one point for simple stuff.

I read Peter's blog post, which was great as usual. Can't find the C emitter in the Chibi sources.

[mnieper]

https://github.com/ashinn/chibi-scheme/blob/master/lib/chibi/show/c.sld

Am Mo., 21. Sept. 2020 um 17:44 Uhr schrieb Lassi Kortela < notifications@github.com>:

Agreed, this SRFI should only have a writer, not a reader. It's very useful to be able to generate HTML from even the simplest Scheme implementations, since HTML is much nicer than text for making reports of all kinds. If the SRFI is simple, it will encourage it to be widely implemented.

A full CSS3 parser and representation is so complex it could almost be an undergraduate thesis :) But for this SRFI, it would be nice to have a S-expression representation that is a subset of a full-featured representation. So that if a full representation is invented, it wouldn't be gratuitously different in the common parts.

Racket already has one S-expression CSS syntax, but I don't think it can handle the full CSS3. IIRC there's a Common Lisp library also. And ClojureScript has something that I think I used at one point for simple stuff.

I read Peter's blog post, which was great as usual. Can't find the C emitter in the Chibi sources.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/minimal-html-css-writer/issues/1#issuecomment-696201100, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDTQ22O4DCNGADIARVQR3SG5YFDANCNFSM4RUMNBEA .

[lassik]

• Racket css-expr
• Clojure garden
• Clojure cssgen
• Clojure clj-style
• Clojure gaka
• Common Lisp cl-css

[lassik]

https://www.w3.org/TR/css-syntax-3/#parsing