Re: Proposal: Generalized Cascading Sheets

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

Tom

On 28 July 2015 at 14:30, Lea Verou <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
> - CartoCSS, discussed in the NYC F2F
> https://www.mapbox.com/tilemill/docs/manual/carto/
> - Ulysses Style Sheets
> http://www.ulyssesapp.com/styles/ulss-reference/artists.html
> - Metapolator 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/
> - Cascading Tree Sheets, research project
> http://edwardbenson.com/papers/www2013-cascading-tree-sheets.pdf
> - Daniel’s ancient STTS proposal 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
>