not showing xforms-required-empty on intial display?

FYI,

Here is a new idea we got today: let the XForms engine add to controls a class called xforms-control-visited upon DOMFocusOut. This will allow you to style with CSS so that upon initial page load, required controls are "white". However, as you navigate between controls, the class gets added and if the control is also xforms-required-empty, you can style the controls in "red".

Now I can see how this doesn't solve the case where you press the "save" button. For that one, maybe a slightly more complex strategy where, upon xforms:submission, the controls bound to the instance to submit would automatically be marked as visited would do the trick. In other words, press "save", and then in case of error the fields that participated in the submission become "red". This part is a little more difficult though.

-Erik

Adrian Baker wrote:

Erik Bruchez wrote:

Adrian Baker wrote:
> Has anyone implemented a tidy approach for not displaying the
> .xforms-required-empty class when form first displays? I mind less about
> *invalid* fields being highlighted, since generally a form won't start
> with invalid data (although this is still also somewhat of an issue).
>
> It seems a little unfair to users to complain to them that they haven't
> filled in required fields before they even have a chance to enter
> anything. For example, invoking the 'New Form' link on the DMV example
> displays a new form which is blazing with red required-but-not-filled-in
> fields & alerts.

> Ideally the form wouldn't display these on startup, and only display
> them as the user moves through each field one by one. As soon as the
> user attempts to submit the form then at this point everything can light
> up with xforms-required-empty, but not before.

I believe both ways are realistic, depending on how you style the
"required-empty" elements. But I get your point, there should be a way
to not show required fields in bright red initially in certain
situations.

> One rather burdensome way to approach this is to use an attribute on
> every node which tracks the dirty/has-user-moved-through-me state of
> the field, and calculates required-ness using this (with an override
> triggered by the submit). This is really bad though because the form
> loses any indication that the field is required before it's changed
> or the form is submitted - which means the user doesn't know that a
> field is required until they screw up.

Well, you wouln't need one attribute per node, right? Just one global
node that tells you whether a first submission has occurred or
not. Then you could write, for each "required" expression:

<bind nodeset="my-nodeset"
      required="my-boolean-condition
                and instance('control')/show-required = 'true'"

Then before doing your first submission, do:

<setvalue ref="instance('control')/show-required">true</setvalue>

This is not a perfect solution, as you have to add something to every
@required, but at least you have perfect control over when you switch
over.

Using a single global flag allows you to indicate to the user missing required fields when they try and submit, but ideally they'd also be told as soon as they move out of a field which is required and which they have left blank (since they've now had a chance to provide a value). And again you still lose the ability to communicate that a field is required ahead of time using the xforms-required class.

As to what the ideal solution would be, I am not sure. If you look at
this as a pure styling issue, then having the ability with XForms to
change a class on an element would be a solution. You could have an
enclosing div, on which you could have two classes,
e.g. "show-required-true" and "show-required-false", and then CSS
rules like:

.show-required-true .xforms-required { /* bright red! */ }
.show-required-false .xforms-required { /* nothing */ }

Being able to change CSS classes using XForms would be great - is this on the horizon? I wouldn't say this is ideal because you'd still have to write a bunch of actions to update the classes when appropriate, just to achieve what I'd argue is sensible default behaviour - and of course IE can't handle CSS rules like this ;) But I guess the default engine behaviour can't cater to everyone's tastes :)

Note that it's not the xforms-required class which is at issue - I *want* to communicate to the user that a field is required, right from startup. The problem class is xforms-required-empty, which tells them they've left a required field blank. But the same solution would work for xforms-required-empty of course.

> It's hard to see what the spec says about this (particularly because
> it doesn't even specify anything like the xforms-required-empty
> class).

It doesn't say anything AFAIK.

> But the initialisation section implies to me that perhaps the engine
> isn't required on startup to display alerts - see
> http://www.w3.org/TR/xforms/slice4.html#evt-modelConstruct (item 5)
> where it explicitly states that the xforms-refresh event is *not*
> fired on startup.

> And as far as I can see, this is the only event which involves
> updating the UI with invalid-ness (does this mean that the initial
> UI state is not specified at all?), so can this be taken to mean
> that fields *don't* have to be highlighted as
> invalid/required-but-empty in the initial display?

I think that is probably reading too much into the spec ;-) Upon
xforms-model-construct-done, form controls are bound to nodes (or
non-relevant). I would assume that this means that the controls
reflect isntance data, as the spec doesn't appear to even say that the
control should display the value of the node it is bound to.

-Erik

Ok, well given that the spec is silent on the issue, what do you think is a sensible default behaviour for the XForms engine when a form is first displayed? To output xforms-required-empty *in addition* to xforms-required classes? This means it's outputting markup which is saying not only "hey this field is required", but also "you've left this required field blank!". I guess with the OPS default style this isn't too bad (partly because it doesn't actually style xforms-required itself in any way, but just relies on xforms-required-empty) but semantically it still strikes me as quite incorrect.

Perhaps in some cases you might wish all alerts & empty required fields be highlighted on startup, but a <xforms:refresh> invocation on startup could achieve this.

Anyway, this is probably something I should raise on the w3c list rather than here, since there's no clear solution at this stage. I have similar issues with alerts being displayed on startup which I have to work through as well.

Adrian




------------------------------------------------------------------------


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
  

Adrian Baker-2 wrote

Has anyone implemented a tidy approach for not displaying the
.xforms-required-empty class when form first displays? I mind less about
*invalid* fields being highlighted, since generally a form won't start
with invalid data (although this is still also somewhat of an issue).

It seems a little unfair to users to complain to them that they haven't
filled in required fields before they even have a chance to enter
anything. For example, invoking the 'New Form' link on the DMV example
displays a new form which is blazing with red required-but-not-filled-in
fields & alerts.

Ideally the form wouldn't display these on startup, and only display
them as the user moves through each field one by one. As soon as the
user attempts to submit the form then at this point everything can light
up with xforms-required-empty, but not before.

One rather burdensome way to approach this is to use an attribute on
every node which tracks the dirty/has-user-moved-through-me state of the
field, and calculates required-ness using this (with an override
triggered by the submit). This is really bad though because the form
loses any indication that the field is required before it's changed or
the form is submitted - which means the user doesn't know that a field
is required until they screw up.

It's hard to see what the spec says about this (particularly because it
doesn't even specify anything like the xforms-required-empty class). But
the initialisation section implies to me that perhaps the engine isn't
required on startup to display alerts - see
http://www.w3.org/TR/xforms/slice4.html#evt-modelConstruct (item 5)
where it explicitly states that the xforms-refresh event is *not* fired
on startup. And as far as I can see, this is the only event which
involves updating the UI with invalid-ness (does this mean that the
initial UI state is not specified at all?), so can this be taken to mean
that fields *don't* have to be highlighted as invalid/required-but-empty
in the initial display?

Adrian