Proposal: Generalized Cascading Sheets

This is something I’ve been pondering for a while and discussed in person with many csswg folks, so I finally decided to write up some rough thoughts to test the waters. I think it very closely aligns with the goals of Houdini, so it’s perhaps an idea whose time has come. :)

In the last few years, we have seen a proliferation of languages with CSS-like syntax and rules, but different specifics (different properties, pseudos etc), something we also discussed in the recent CSS F2F. Here are a few examples off the top of my head:

- Tab’s Cascading Attribute Sheets proposal
- CartoCSS, discussed in the NYC F2F
- Ulysses Style Sheets
- Metapolator Cascading Properties Sheets
- SVG’s flavor of CSS could be considered one such language
- Many text editors use a CSS-like syntax for styling themes, e.g.
- Cascading Tree Sheets, research project
- Daniel’s ancient STTS proposal
- I’ve been in the middle of several discussions about more such languages (both in the industry/standards world, as well as in academia), though not all have produced something I can publicly link to.

I’m sure you can add even more to this list. It’s indisputable that CSS’ syntax is a familiar and fairly intuitive way to declaratively apply a set of properties to an existing structure [1], and this is something that is needed in way more cases than just styling.

In most of these cases, authors had to re-implement CSS parsing, cascade and specificity. I believe it’s within Houdini’s scope to include APIs to make this easier. However, I think there is a lot of value in the syntax, parsing, cascade & specificity rules of CSS *as a language framework*. I imagine GCS [2] as a first-class Web language to make creating such syntaxes easier. *Something that is to CSS what XML is to SVG* (or SGML was to HTML < 5).

I imagine browsers would ship with a GCS parser, parsing anything with a MIME type of text/gcs) and automatically create an OM akin to the CSSOM. CSS Syntax and CSSOM would be defined as extensions on that, potentially with post-processing steps that are special to them, to account for the peculiarities of CSS that we wouldn’t want to transfer to a generalized language. Authors could also take advantage of the browser’s GCS parser to parse CSS without dropping unknowns, to create polyfills, which is one of Houdini’s existing goals. There is a lot of browser magic that Houdini wants to expose to authors via APIs. These could be just be GCS APIs from the get go, without much additional effort. Events such as the ones proposed in [3] would be useful here as well.

Ideally, there would also be something that defines the specifics of the language, like what DTDs are to XML: Something that would define the allowed properties, their values, which shorthands correspond to which longhands, which pseudo-classes, pseudo-elements, @rules, functions are permitted etc, perhaps even which selectors language to use (see [1]). One issue is that CSS depends a lot on microsyntaxes for its property values, which would be tough to define in a structured way, however that does not have to be part of GCS in its entirety (though css-values might still be useful in GCS, I think).

Some benefits of defining a generalized language framework instead of just exposing a set of CSS APIs are:

- Easier to write tools for such languages, such as validators
- Easier to define future Web languages such as CAS (I’ve even heard from a couple csswg people that a HTML transformation language with CSS-like syntax is the future)
- More motivation for third parties to use a GCS-derived syntax than to leech off CSS (compare the proud "we’re using an open XML-based format" vs the awkward "we’re saving in something like HTML, but with different tags") and authors benefit from familiar syntax
- More interested parties working on the core aspects of CSS, since they would now have way more applications than just styling

Soo, thoughts?


[1]: That structure could be XML/HTML or anything that can be queried by a Selectors-like syntax. Or perhaps the selector syntax could be extensible as well! E.g. someone’s GCS-derived language could use XPath or JSONiq as a selector language!
[2]: Yes, I gave it a name, to facilitate discussion. It’s obviously TBB. :) eXtensible Cascading Sheets (XCS) might be more on par with XML.

Received on Tuesday, 28 July 2015 13:30:32 UTC