W3C home > Mailing lists > Public > www-style@w3.org > February 2012

RE: [css3-2d-transforms][css3-images] <position> grammar is duplicated or points to the wrong spec

From: Brian Manthos <brianman@microsoft.com>
Date: Thu, 2 Feb 2012 18:04:34 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Brad Kemper <brad.kemper@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
Message-ID: <9710FCC2E88860489239BE0308AC5D170EB31BC9@TK5EX14MBXC264.redmond.corp.microsoft.com>
Another example to put in the list...

"Why is calc(2em/1em) not allowed?"  I remember the "why" but I don't know anywhere besides the alias archive where it's documented.

> -----Original Message-----
> From: Brian Manthos
> Sent: Thursday, February 02, 2012 10:02 AM
> To: 'Tab Atkins Jr.'
> Cc: Brad Kemper; Sylvain Galineau; L. David Baron; www-style list;
> fantasai
> Subject: RE: [css3-2d-transforms][css3-images] <position> grammar is
> duplicated or points to the wrong spec
> 
> > I've captured precisely that in the wiki as a design principle.  It
> > wouldn't be captured in a CSS spec, because it has nothing to do with
> > CSS-as-it-is-used - it's a design principle that we as spec authors
> > need to follow.
> 
> Going OT slightly...
> 
> Haven't we had prior discussions where it became abundantly clear that
> the spirit and intent of the design not being up-front to authors is
> one of the problems that needs to be addressed?
> 
> As such, shouldn't the design principles be documented *within* the
> specification perhaps as an appendix.
> 
> For example, when reading a CSS2.1 spec that a CSS3 spec is based on
> there are often "surprises" from a literal reading of the text.  Then
> someone raises a question on this (apparently high traffic) alias
> asking for clarity and the answer comes back "oh, that was a minor
> adjustment in CSS2.1 because CSS1 was written by candle light and so
> ...."  Relying on (a modern analog of) oral tradition to understand the
> specification's literal text as well as its intent seems a mistake to
> me.  Lastly, it would be nice to *see* the shift in design principles
> from 1 to 2 to 2.1 to 3 -- both for the completion of 3, and with an
> eye toward planning what shifts will be necessary for 4.
> 
> A wiki can be a great place to collaborate and build consensus, but
> capturing a snapshot of the current design principles *with* each
> specification seems an appropriate additional step.

Received on Thursday, 2 February 2012 18:05:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT