In fact something has been done, at least partially, possibly even  
based on your suggestion!

Check for the class xforms-invalid-visited on controls. You have to  
add your own CSS to use this. See e.g. how Form Runner uses it. If you  
want to add the bit where upon submission all the errors show, you  
have to enable all the classes with your own JavaScript.

Note that this turns out to be still an unsatisfactory solution,  
because the "visited" algorithm does not work in all cases. In  
particular it fails to be generic enough for:

* Dialog open/close/open: are controls visited or not?
* Same question for groups or cases shown/hidden/shown.
* Initial page show where data happens to need to show errors.

Possibly, custom MIPs can help solve this (i.e. the "visited" state  
would be controlled by the application).

BTW regarding the XForms spec, I don't think it can be inferred from  
it that any such behavior must be implemented. If I had to decide, I  
would lean towards the opposite, because:

* xforms:alert visibility is strictly controlled through CSS.
* I would expect that at any time, the :valid and :invalid classes  
reflect the control's bound node's MIPs. That means when controls  
first show, and then at each refresh.
* Certainly, there is no logic implied by XForms whereby only the  
visited controls would update their pseudo-classes at the first post-
initialization refresh.

Anyway, there is nothing wrong for implementors to innovate based on  
real-life experience. On the contrary, this is what should drive the  
standard :-)

Note that custom MIPs are planned for a future version of XForms.

-Erik

On Jan 26, 2009, at 2:57 PM, Adrian Baker wrote:

>
> As far as I can tell this is still a problem - has any easier way of
> supressing alerts on initial display emerged over the last couple of  
> years?
>
> http://forge.objectweb.org//tracker/index.php?func=detail&aid=308803&group_id=168&atid=350207
> has made this problem much worse.
>
> Adrian
>
>
> 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
>>
>>
>
> --
> View this message in context: http://www.nabble.com/not-showing-xforms-required-empty-on-intial-display--tp4788228p21674222.html
> Sent from the ObjectWeb OPS - Users mailing list archive at  
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the ops-users@ow2....  
> mailing list.
> To unsubscribe: mailto:ops-users-unsubscribe@ow2....
> For general help: mailto:sympa@ow2....?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/