RE: [css3-images] Serialization

[Bjoern Hoehrman:]
> 
> * Brian Manthos wrote:
> >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.
> 
> I made a point about what should guide the design of this features based
> on the design goals I am aware of and gave an example to illustrate what
> that might mean in practise. How some existing constructs are serialized
> is the result of various ad-hoc decisions rather than deliberate design,
> and it may well be that legacy behavior is retained even though it's not
> consistent with rules formulated for serializing new constructs, so I've
> added that as a caveat to my example. I did not suggest to abandon com-
> patibility and I did not say I prefer using `rgba` for all RGB colours.
> 
> How serialization should be defined should be a matter of what problems
> are to be solved. If the problem is "I have stringified color values and
> need to extract the components" then representing all RGB colours using
> the `rgba` notation is likely best; if the problem is "I need to retain as
> many of the syntactical choices as possible", then it's better to
> represent "blue" in many different forms depending on the input. In any
> case, you would be looking at actual problems and how well they are being
> solved by some proposal. You would not look at "terse vs verbose".

Sure you would. If my use-case is a Firebug-style development tool I might 
well want verbose or the ability to expand to verbose. Someone implementing 
an editor may also prefer to parse verbose because not tracking which optional 
values were omitted in a complex property or a shorthand makes their life 
simpler. But while the verbose version of a complex value might be easier 
to handle than its terse counterpart, they'd probably prefer to parse #rrggbbaa 
than rgba(); until the latter is widely implemented the next best thing is to 
parse all colors the same way and that probably means rgba() so they don't 
have to branch on #rrggbb or rgba() input. The pattern here is web developers
preferring to keep their own code as terse as it can be; which is a lot
easier if browsers output the same stuff using the value types that are easiest
to parse.

I'm fine with looking at actual problems; but 'people post-processing the 
serialized value' is too vague to be useful. What they're processing the value 
for is what matters.
 
But use-cases, as a rule, do not make implementors care any less about performance and 
memory footprint and they will certainly consider the very real trade-offs of terseness 
vs. verbosity, as well as compatibility (with apps, other browsers, previous versions, 
libraries, developer expectations), simplicity and consistency (e.g. we'd like to 
serialize color values the same way everywhere if possible) and, of course, ensuring 
any value we generate can round-trip successfully.

Received on Tuesday, 19 July 2011 16:23:47 UTC