Re: Proposal: Generalized Cascading Sheets

Hello Lea,

Tuesday, July 28, 2015, 3:30:04 PM, you 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. :)

I agree that it is aligned with the goals of Houdini. Although Houdini
is focussed on APIs as mechanism, the scope is to remove magic, expose
parts of CSS that are otherwise needlessly re-implemented - and this
fits very well there.

I added it to the agenda for the Paris Houdini meeting, on that basis.
https://wiki.css-houdini.org/planning/paris-2015?&#proposed-agenda-topics

> - Metapolator Cascading Properties Sheets
> https://github.com/metapolator/metapolator/wiki/cascading-properties-sheets

I was quite unprepared for that one, when meting it for the first time
at this year's Libre Graphics meeting in Toronto. it is operating on
an XML tree (UFO, which is an XML representation of the binary
Opentype/SFNT structure), uses selectors, specificity, and a whole new
set of application=specific properties. It is one-shot, not dynamic.

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

Yes (and parsing is already one of the specs under development).

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

Well put. I don't see that Houdini necessarily has to restrict itself
to APIs if there is a better, and indeed declarative and more
convenient, way to do something.


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

I was slightly worried that all such grammars would be constrained to
be a strict subset of what CSS-the-language needs. I'm glad to see
that an extension mechanism is envisaged straight away (and indeed,
used for CSS itself).

Whilst it is natural that CSS will tend to be 'primus inter pares' in
this language family, it is certainly good to allow extension as well
as subsetting.

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

Yes, i strongly believe that the 'dropping unknowns' should be a
separate and css-specific phase. Indeed, not all css processors do it
- editors for example should not. So it is rather a css-in-browsers
specific feature, a performance optimisation.

> 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

I agree in general but would be wary of trying to define the
specifics. I know DTD was used as a generalized shorthand here but
hopefully lessons can be drawn from the XML Schema vs. RelaxNG wars on
how best to proceed here, with a lightweight and implementation-driven
approach.

> (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).

That does worry me since a lot of the discussion time in CSS WG is
spent refining the per-property microsyntax (compared to, say, and XML
representation which would however be frightfully verbose). But the
forwards-compatible, skipping past errors to recover part of CSS could
help here; provide a blob to the microparser, the main parser only
needs to recognise unambiguously the end of a property value.

Overall, this proposal seems like one whose time has come. It is also
a good way to avoid feature creep for special purpose applications
(without totally blowing off users of same) by allowing them to build
their own languages without reinventing and re-implementing
everything.

In turn, that makes consistency the path of least resistance, which
makes learning easier among the language family.

-- 
Best regards,
 Chris  Lilley
 Technical Director, W3C Interaction Domain

Received on Wednesday, 29 July 2015 20:58:25 UTC