- From: Brian Manthos <brianman@microsoft.com>
- Date: Thu, 2 Feb 2012 18:46:18 +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>
Tab: > Yes, explaining some design decisions is important for clarity, > particularly when they can be captured in examples. > > However, capturing *every* design principle is unrealistic - there's > no reason to copypaste the design principles behind at-rules into the > List spec, for example. If following one of them led to a > particularly unintuitive design, it should be documented, but not if > it's a fairly normal thing. How many times have various flavors of "why does background-position have ..." come up? You'd think that at some point an editor's time could be more efficiently used capturing FAQ and publishing them, rather than explaining they percentage/length oddity, or the parameter ordering constraints, etc. every time it comes up. I didn't say anything about pasting design principles into every module. I was saying that design principles that form the framework for a specification should be part of the spec. It's useful in a similar way to having a glossary so that your terminology is clearly understood. I don't think a wiki separate from the versioned/levelled specifications is a good enough. I'm not suggesting a 200 page, single spaced thesis. I'm just suggesting known design choices and/or oddities get captured and attached *to* the specification itself, rather than found via web searches for "what the f is up with xyz property" on css-love-hate sites. I guess we'll just have to agree to disagree here.
Received on Thursday, 2 February 2012 18:46:58 UTC