RE: [css3-images] Serialization

> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> 
> * 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

How are you defining "programming interface"?  Is javascript included?  Is CSS included?  Is HTML included?

"Exposed only through programming interfaces" either limits it to outside of CSS itself, or not.  I'm not seeing how this "only" changes the discussion.

> motivation behind requiring certain behavior of programming interfaces
> is to allow programs to depend on the specified behavior. In this case

Concur, and more.  It allows humans as well as programs to depend on the specified behavior.

Abandoning compatibility because you prefer using rgba() across the board seems counter to that goal -- in the form of compatibility with existing content and implementations.

> that means programs do not have to implement every last detail of the
> CSS syntax (otherwise they wouldn't need a serialization
> specification).

My interpretation of what you're saying is that an incomplete specification being normative isn't a problem.  I disagree completely.

It's like saying "we'll define the radius 3 of the 4 wheels, and leave the 4th undefined".  The car doesn't move very smoothly.

If I'm misunderstanding, please elaborate.

> So this quite clearly seems to be about limiting complexity for users
> of the API, and not about verbosity and terseness.

I don't reach the same conclusion.  Brevity is about more than simplicity; in fact it's often the reverse.

> >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).

That's a potential goal, but that's not the only goal.

Round-tripping has been a goal in the past.  As has been compatibility.  As has been concision.

If you'd like to argue that the only goal is a canonical form that you happen to have chosen, that's fine -- but it needs to be consistent across CSS not defined arbitrarily and incompletely in one module, and made normative.

Received on Tuesday, 19 July 2011 08:19:14 UTC