Push comes to shove in this case: <attribute name="whatever" type="color" style="color" value="black" />
Here we have an attribute that is styleable using CSS, which may specify a value in a number of ways: named color, #format, rgb(), hsv(), etc. It's pretty clear (to me at least) that the fallback/default specified in `value` should be in that same space. I should _not_ have to say `value="0"` to specify a default color of black. Therefore, I propose, at least for attributes that have a `style` property, the `value` property is assigned to the attribute using the specified type's `accept` method. On 2010-08-11, at 11:44, P T Withington wrote: > Here's an important question that needs answering, before we can really go > anywhere with this: > > If I define a new type, say `trilean`, that is stored as 0, 1, or 2, but is > meant to represent a tri-state yes/no/maybe button in a form, when I write: > > <attribute name="again" type="trilean" value="???" /> > > What is the expectation about the `value` field? > > Currently, for all the built-in presentation types, (except for color), > `value` is interpreted as the corresponding Javascript type, but maybe this > is just luck because the Javascript type and the LZX type look similar enough > no one noticed. E.g., I say: > > <attribute name="ok" type="boolean" value="false" /> > > I use the Javascript value `false`, not the representation `"false"` (which > is how a boolean would be stored in a dataset). > > If we extend that model, for my trilean, I would have to write: > > <attribute name="again" type="trilean" value="2" /> > > which is not really helpful. I would have to remember wether `2` corresponds > to "yes", "no", or "maybe". I would much rather write: > > <attribute name="again" type="trilean" value="maybe" /> > > Is this what people expect? I'm not sure how we could reconcile the current > built-in types with this new distinction. It makes me think that we need a > new property of attribute that is the "representation type"? > > <attribute name="again" type="trilean" ???="maybe" /> > > What's a good name for that? > > [that leaves open the issue of how I write Javascript code to manipulate > `this.again` -- there I need to know the corresponding values. Probably I > want to be able to say: > > if (this.again == lz.trilean.yes) ... > > or something.] > >
