Adapt syntax for new css extensions

[jeluard]

CSS extensions and media queries allow to extends CSS syntax in a number of ways that can't be easily expressed in garden. It would be nice to allow this and eventually introduce some extension mechanism to be future proof.

Some examples:

@custom-selector --heading h1, h2, h3, h4, h5, h6;
--heading { /* styles for all headings */ }

@custom-media --narrow-window (max-width: 30em);
@media (--narrow-window) {
  /* narrow window styles */
}

An idea could be to allow plain string that would be emitted as-is. Similarly at-media could admit a string as first parameter.

(css
  (list
      "@custom-selector :--heading h1, h2, h3, h4, h5, h6;"
      [:--heading
        {:color "red"}]))

[jeluard]

Note that even if those are not yet available in browsers they can be transpiled to regular CSS using cssnext.

[noprompt]

The --heading case is doable with garden.selectors. There isn't a ~~selector~~ combinator for , but it should be easy to make. The --narrow-window is easy too; it's just {:max-width (em 30)}. I'm not sure what these custom at rules can do that we can't already do in Garden or what the gain is compiling to them. Also, since this is a draft we should probably hold off until it's matured.

[jeluard]

Sure not suggesting we should do anything but that garden should be prepared those newer syntaxes. I'll take a look at how garden.selectors can help.

[jeluard]

I realize I probably misunderstood your answer. I am not looking for ways to simulate those syntax but would like to have garden literally output those constructs.

I believe there is value doing that in the mid term as it makes those constructs CSS first class citizen. For instance they might be integrated in CSSOM.

[noprompt]

@jeluard I think that's fine. We should probably start making an effort to do this anyway. As I've mentioned the Hiccup style syntax is only good for so long and I really feel like it should be the cherry on top instead of the only way.

I'm open to adding a new type to the garden.types for this. We also need to create an api wrapper for it in garden.stylesheet and figure out how to integrate it with the current compiler protocol. You can add the type for it now and the api if you like.

[noprompt]

Also for what it's worth the CSSOM argument is actually a good one. I've done a bit of exploratory coding in that area and things on the client turn out to work much better with a few extra protocols and types. I don't know if there's a spec for the JavaScript type but I'd be especially happy if we could model it closely to that as it tends feel more cohesive.

[priyatam]

@noprompt @jeluard postcsss community created many plugins based on these new extensions and our ability to write these from garden as Types, combined with data structures would open to new possibilities. I'd like to collaborate on this patch.

Next steps?

[jeluard]

Maybe try to came up with some plan that would be as much as possible CSS syntax future proof? And a nice way to plug custom syntax extension probably?