RE: Proposal: Generalized Cascading Sheets

> De : Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> 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>.

XPS is a document format, however. Just like I think "Property-Declarations File" is a poor choice because another file format share the same acronym, I also think "eXtensible Property Sheet" isn't a great choice.

In the same sorry-it-does-not-work category, I would add "Rule-based Description Format" (RDF). Its sibling "Rule-based Description Sheet" (RDS) does work, though (and I kinda like it).

Received on Thursday, 6 August 2015 17:13:53 UTC