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