Re: @label, @help, @hint, @alert

All,

A few more thoughts on what to do with `@value`.

We could have deprecated `output/@value` since `@ref` can now return
an atomic value. But then variables use `@value` too, and there it
make too much sense to be removed as it is too common in programming
to talk about a variable's name and value.

Also, my proposal of:

    <item label="New York">NY</item>

falls short because it is exactly the opposite of HTML, which has:

    <option value="NY">New York</option>

So unfortunately, I think we either have to:

- keep `@value` an XPath expression everywhere
- or allow `@value` to be a literal on `xf:item` specifically

Both solutions break some kind of consistency.

-Erik

On Wed, Mar 5, 2014 at 9:51 AM, Erik Bruchez <erik@bruchez.org> wrote:
> Steven,
>
> Quick comments:
>
> 1. `filename="{@filename}"` and `mediatype="{@mediatype}"` won't work,
> because AVTs evaluate to a string value. What these two attributes
> specify is the ability to *write* to a node. So for these you would
> need something like `filename-ref` and `mediatype-ref`.
>
> 2. We could, as discussed in that older thread, say that item and
> itemset support constant values as text:
>
> <item label="New York">NY</value>
>
> And `@value` would remain an XPath expression.
>
> 3. xf:copy
>
> `@copy` could be an XPath expression. If `@value` is one, then at
> least we would have some consistency here.
>
> 4. Styling
>
> There was a suggestion to use pseudo-elements as well. So couldn't we use:
>
>     xf|label, :xf|label { ... }
>
>
> -Erik
>
> On Wed, Mar 5, 2014 at 8:49 AM, Steven Pemberton
> <Steven.Pemberton@cwi.nl> wrote:
>> It's probably too late for this draft, but here is my view of the label as
>> attribute situation.
>>
>> 1. It would be easy to add @label, @help, @hint, @alert to the attribute set
>> UICommon, which would mirror the content set of the UICommon elements.
>> 2. Of the core controls
>> (input|secret|textarea|output|upload|range|trigger|submit|select|select1),
>> only <output> is the odd one out, where <label> is optional.
>> 3. group, dialog and choices only have <label> (no help hint and alert)
>> 4. switch and repeat have none of them
>>
>> Now the special cases.
>>
>> 1. upload has a filename child element, which for consistency we might want
>> to mirror in an attribute
>>         <upload ref="mail/attachment" accept="video/*,image/*,.txt,.pdf">
>>           <label>Select attachment:</label>
>>           <filename ref="@filename" />
>>           <mediatype ref="@mediatype" />
>>         </upload>
>> =>
>>    <upload ref="mail/attachment" accept="video/*,image/*,.txt,.pdf"
>> label="Select attachment:" filename="{@filename}" mediatype="{@mediatype}"
>> />
>>
>> 2. <item> has <label> and <value>. The problem here is that @value would
>> operate differently from @value on other elements, where it is an
>> expression, while here it would be a string/AVT. Not sure what to do.
>>
>>         <output label="Total" value="total"/>
>>
>>         <item label="New York" value="NY" />
>>         <item label="{@name}" value="{@code}" />
>> or
>>         <item label="New York" value="'NY'" />
>>         <item label="{@name}" value="@code" />
>>
>> Difficult.
>>
>> 3. itemset label value|copy. Copy is empty, and you only use it for the ref,
>> so do we make it an AVT or an expression?
>>         <select model="cone" ref="my:order">
>>           <label>Flavors</label>
>>           <itemset model="flavors" ref="my:flavor">
>>             <label ref="my:description"/>
>>             <copy ref="my:description"/>
>>           </itemset>
>>         </select>
>> =>
>>         <select model="cone" ref="my:order" label="Flavors">
>>             <itemset model="flavors" ref="my:flavor"
>> label="{my:description}" copy="my:description"/>
>>         </select>
>> or
>>         <select model="cone" ref="my:order" label="Flavors">
>>             <itemset model="flavors" ref="my:flavor"
>> label="{my:description}" copy="{my:description}"/>
>>         </select>
>> ?
>>
>> Priority
>>
>> I suggest a behaviour that if an element has both an attribute and its
>> matching element, the attribute gets priority (offering backwards
>> compatibility).
>>
>> Styling
>>
>> CSS styling is not a problem, but we might want to discuss it:
>>
>>         *[label]:before {content: attr(label); ... other styling...}
>>         *[hint:hover:before {content: attr(hint); ... other styling...}
>>         *[alert]:invalid:before {content: attr(alert); ... other styling...}
>>
>> Steven
>>

Received on Tuesday, 11 March 2014 22:34:01 UTC