Re: SELECT display

I have in the past designed xforms and spent ages mucking about with
"appearance", and grouping in order to try to get the form to make sense 
to its users.
A form's function is often defined by more than just the controls on it.
It is common that the controls must "line up" in some way or otherwise 
relate to each other in some coherent fashion for the form to be useful. 
"Group" doesn't always get you where you need to be, and I am concerned 
that xforms I develop that are perfectly functional and make sense in a 
browser would likely be entirely unfathomable on some other devices 
simply because of their reliance on layout to help convey meaning.
I dont know what the answer is, but more elaborate x-platform display 
hints would go a long way toward minimising this problem I think. I dont 
have any problem with Mark's xsl-fo style block layout options.

Cheers
Jason.


Aaron Reed wrote:
> 
> Hi Mark,
> 
> My clarifications below.
> 
> Mark Birbeck wrote:
>>
>> Hi Aaron,
>>
>> I disagree. :)
>>
>> Although it's true that you don't necessarily want to define how
>> xf:item should appear, there is certainly nothing wrong with this:
>>
>>  xf|item { display: block; }
>>
>> or this:
>>
>>  xf|item { display: inline-block; }
>>
>> That doesn't affect device independence or accessibility.
>>
> 
> I agree that there is nothing wrong with it.  Implementations need to 
> make sure that common styling rules will not cause ill-effects to the 
> form that is displayed by their processors.  We fixed two bugs where 
> styling rules were screwing us up just this past week :-)
> 
>> The reason I said there was something missing from the XForms spec
>> though, is that we've never really said that individual pieces can be
>> styled. So for example, if a processor simply takes a select1 and
>> 'converts' it to an HTML drop-box, then there are no 'item' elements
>> to add style to. However, if a select1 is implemented as a container
>> of 'item' elements then they can be styled.
>>
> 
> My point exactly.  Here is one example where even if something exists in 
> the spec to spell out how to style xf:items and an author adds such 
> rules to his/her form, a processor could still ignore the styling rule 
> and yet be fully compliant.  A form author can only expect a processor 
> to honor the styling rule if it makes sense in the context of the 
> widget(s) that the processor chooses to use to render the xforms control.
> 
> So in the end, the results that the form author experiences will be 
> processor dependent.  Though should such rules make their way in the 
> spec, it is a good way to ensure that processors that DO want to apply 
> styles to xf:items in certain appearances or in some data type bindings 
> will have enough information to guide them in doing so.
> 
>  >
>> We've also never said that an 'itemset' becomes a set of 'item'
>> elements, which you'd also need to say in order for this to all be
>> consistent.
> 
> probably xf:choices, too.
> 
>>
>> Regards,
>>
>> Mark
>>
>>
>> On 16/10/06, Aaron Reed <aaronr@us.ibm.com> wrote:
>>>
>>> Hi Richard,
>>>
>>> I certainly see your point, but it is tough to standardize that a
>>> certain style will cause a select's checkbox items to layout in a line
>>> when there is no standardization on the fact that a select will display
>>> as checkboxes to start with.  And then you have to consider the impact
>>> of specifying something like this across all devices.  So I'm guessing
>>> that this would never become part of the XForms standard itself other
>>> than as a suggestion which processors could then ignore.  So in the end,
>>> it will still be processor dependent.
>>>
>>> Having said that, it would certainly be handy if the browser-based
>>> processors reached a consensus on different styling options for
>>> different XForms controls.
>>>
>>> --Aaron
>>>
>>>
>>> FirstTesting wrote:
>>> > Thanks Mark
>>> >
>>> > It makes sense to standardise the formatting so that it's 
>>> consistent - regardless of which XForms processor is being used.
>>> >
>>> > Regards
>>> >
>>> > Richard
>>> >
>>> > http://www.firsttesting.com
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 
>

Received on Tuesday, 17 October 2006 01:19:03 UTC