Re: Proposal: Generalized Cascading Sheets

Hi, Lea.

Sorry if I gave the wrong impression, but I started the list for my own
benefit (because I didn't recognise most of the examples you listed) and
decided to put a link up here in case anyone else might find it useful.

I agree that if GCS is ever going to gain any traction it will need to
start as the simplest possible shift from CSS; from that point of view I
don't think the syntax extensions of these other languages are important,
but I wanted to be as complete as possible in classifying them.

Regards,
Tom

On 29 July 2015 at 12:30, Lea Verou <lea@verou.me> wrote:

> 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
>
> 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
>>
>
>
>