- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Tue, 19 Jul 2011 05:01:19 +0200
- To: Brian Manthos <brianman@microsoft.com>
- Cc: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
* Brian Manthos wrote: >Incorrect. Testability is just one of many things that make it >important to be crisp, if the serialization section remains >normative in the WD. I think it is important to understand and agree on what the purpose in specifying the behavior of serialization functions is. As it is, the functionality is exposed only through programming interfaces, and the motivation behind requiring certain behavior of programming interfaces is to allow programs to depend on the specified behavior. In this case that means programs do not have to implement every last detail of the CSS syntax (otherwise they wouldn't need a serialization specification). So this quite clearly seems to be about limiting complexity for users of the API, and not about verbosity and terseness. >Why? I wouldn't. For fully opaque colors, it's unnecessarily verbose >and unusual to force rgba when rgb() or #rrggbb was provided by the >author. If you make a program that takes a serialized color string and want to know the red, green, blue, and alpha values, then you only have to look for one format instead of many. What other things would you do with the serialized color string that requires having a specification for how a certain color value is serialized into a string (something that is not affected by backwards-compatibility issues)? >Should keywords such as "blue" be converted as well? That's an >unfortunate loss of expressiveness. Especially if we try to introduce >something like color-adjust-opacity(blue, 0.5) someday. If your goal is to make it easy to post-process the serialized forms, then the answer should be quite clear. If you do not care much about post-processing, then there is little reason to care much about how values are serialized (relatively speaking; programs that do not work are much worse than APIs that return, say, merely unaesthetic results). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Tuesday, 19 July 2011 03:01:24 UTC