Re: Proposal: Generalized Cascading Sheets

Sorry for the delay in reading and responding; you sent right as I
went on vacation. ^_^

Overall, this is just about exactly where I want to take the "general
CSS parsing" thing in Houdini, which I plan to have sketched out by
the f2f.  Have you seen my recent improvements to parse-css that allow
you to specify a schema?
<https://github.com/tabatkins/parse-css#canonicalizing-against-a-grammar>
I probably want to specify something in this vein for official CSS.

On Thu, Jul 30, 2015 at 3:22 AM, Lea Verou <lea@verou.me> wrote:
> While not all GCS languages are cascading, Cascade, Specificity & Inheritance are crucial parts of the syntax that I think should be in GCS, not just in CSS, even if not every GCS language uses them. Without them, you essentially have a glorified JSON-like structure with selectors as keys, which is of less interest.

Specificity comes out of Selectors, not CSS per se.  Providing a
Selector parser alongside this (integratable with, ideally) can
provide that no problem - the Selector object can just have a
.specificity property.  (Needs hooks for custom pseudo-element parsing
so you can assign specificity correctly, etc.)

Cascading and Inheritance are harder, tho.  To make those work you
need to provide a DOM to match the rules over, and you need to specify
which rules are available for matching.  Since this requires
Selectors, you'll need to specify not just how to parse the selectors,
but how to match them against a document, too - how each selector
filters the match set and each combinator mutates it.  This'll be a
significant project above and beyond parsing!  I think we can
definitely separate it out (but at least provide the vanilla-CSS
functionality for people; a lot of uses will be "here's some CSS
selectors and an HTML document, please make them work together so I
can do my cool thing using properties").

>> I would prefer something like Declarative Sheets or Declarative
>> Statement Sheets (with it convenient acronym DSS…).
>
> Statement is a term from imperative languages [2], so not sure it’s a good idea, given that these are definitely declarative.
> Declarative Sheets is too non-descriptive and gives you a two letter initialism, which is hard to google for.
>
> Anyhow, like I said, the name is TBB :)
>
> A few more suggestions:
>
> - XPS/GPS: eXtensible/Generalized Property Sheets
> - XDS/GDS: eXtensible/Generalized Description Sheets
> - XAS/GAS: eXtensible/Generalized Augmentation Sheets (from Håkon’s wording)
>
> Feel free to add your own! Having a name makes it easier to talk about something and gives motivation to work on it, so I don’t think it’s pointless at all. :)

I like "property" in the name; it's easy to say and spell, and is one
of the more salient parts of the syntax.  (We technically call them
"declarations" when speaking generally, but that's spec-ese; they're
"properties" to everyone else.)  GPS feels a little on-the-nose and
hard to google , but XPS doesn't have too many conflicts
<https://en.wikipedia.org/wiki/XPS>.

~TJ

Received on Wednesday, 5 August 2015 19:30:37 UTC