Re: Proposal: Generalized Cascading Sheets

Hi Tom,

Thanks for making this! However, I think it would be wrong to define GCS as something that attempts to cover the existing syntax of all these examples. The examples were listed to demonstrate need, nothing more. They’re useful to look at, to see what is needed, but their syntax could have been different if GCS existed when they were made. I’m a bit worried that syntactic extensions like mixins would stall GCS if we focus too much on existing examples of CSS-like languages.

Also, while eagerness to classify existing examples and start work on GCS ASAP is great, I’m not sure an individual’s Github account is the right venue for it. Ideally, I would want it to become an agenda item for the upcoming Houdini F2F, and we can take it from there.

~Lea

> On Jul 29, 2015, at 14:09, Tom Potts <karaken12@gmail.com> wrote:
> 
> I've started making a list of some of the features of these various languages, and how similar they are to CSS, to try to work out what would be involved in a defining a GCS that covers all the proposed use cases. If anyone's interested in what I've worked out and/or contributing to it, it's here: https://github.com/karaken12/cascading-sheets/wiki/Languages <https://github.com/karaken12/cascading-sheets/wiki/Languages>
> 
> Tom
> 
> On 28 July 2015 at 14:30, Lea Verou <lea@verou.me <mailto:lea@verou.me>> wrote:
> 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 https://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0508.html <https://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0508.html>
> - CartoCSS, discussed in the NYC F2F https://www.mapbox.com/tilemill/docs/manual/carto/ <https://www.mapbox.com/tilemill/docs/manual/carto/>
> - Ulysses Style Sheets http://www.ulyssesapp.com/styles/ulss-reference/artists.html <http://www.ulyssesapp.com/styles/ulss-reference/artists.html>
> - Metapolator Cascading Properties Sheets https://github.com/metapolator/metapolator/wiki/cascading-properties-sheets <https://github.com/metapolator/metapolator/wiki/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. http://wiki.macrabbit.com/SyntaxThemes/ <http://wiki.macrabbit.com/SyntaxThemes/>
> - Cascading Tree Sheets, research project http://edwardbenson.com/papers/www2013-cascading-tree-sheets.pdf <http://edwardbenson.com/papers/www2013-cascading-tree-sheets.pdf>
> - Daniel’s ancient STTS proposal http://www.w3.org/TR/NOTE-STTS3 <http://www.w3.org/TR/NOTE-STTS3>
> - 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?
> 
> ~Lea
> 
> [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.
> [3]: https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0002.html <https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0002.html>
>