Re: A review on CSS3 module dependencies

On Thu, May 6, 2010 at 10:14 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
>
> Eduard Pascual (2010-04-11):
> >
> > I have been looking at dependencies between CSS3 modules for a while, and found out that they form a rather complex graph with several inconsistencies and circular dependencies.
>
> The transition from a monolithic spec towards a modular collection of related, but rather independent specs surely ain’t easy.

I know. And I congratulate the WG for the great work done so far. My
goal with this thread was to save the group some tedious work, so they
can focus on more interesting things. Also, the first batch of changes
I suggested would help cleaning the graph a bit, making it easier to
spot any issue and fix it.

>
> To make it easier I believe CSS modules should only rely on other CSS modules (and possibly external specs). That means no references to level 1, 2 or 2.1, except each level 3 module in working draft state should reference the exact parts of CSS2 or CSS21 it builds upon.

On terms of formal or "normative" dependencies, wouldn't this be
equivalent to a normative reference to CSS21? In any case, I still
think it'd be wise to avoid any references at all to CSS2: it has
never been actually implemented, and most probably it never will;
that's the very reason CSS21 exists (and, had the current TR Track
existed by those times, CSS2 would have never become a
recommendation).

>
> It thereby defers dependencies from other modules until it has reached a reasonably stable state, CR probably, and therefore can act as a normative reference itself.

I like this idea, but I'd rather clean the most obvious dependency
issues before going any deeper, for sanity's sake.

>
> The referencing module doesn’t have to be updated until the other module has reached a stable state in a higher level, e.g. 4. Basically the same applies when a module is split into two newer ones or – and I’m not as sure about this case – combines two older ones.
>
> > Just in case it's useful, I'm attaching a SVG version of GraphViz's output,
>
> It is useful, thanks, but actually I would have liked the source better.

Oh, that was my first idea; but I took a look at W3C's mailing list
rules and find out that "standard" formats are preferred, so I sent
the SVG version instead. But, since you ask, here it is ;-) (Note for
MS Word users: despite the .dot filename extension, this is *not* a
Word Document Template file: it's a graph description in the DOT
language; don't double-click it if it's showing with a MS Word icon :P
 )

Regards,
Eduard Pascual

PS: Another note on the attachment: I've just noticed that GMail is
describing it as application/octet-stream, probably based on its
knowledge about common filename extensions. That's just wrong (but I
don't know how to change that): the file is a BOM-less UTF8-encoded
text/plain file (and it sticks within the ASCII subset of UTF-8).