requiredness, group alerts & XForms psuedoclasses

> Adrian Baker wrote:
>> After having done a bit of fairly superficial testing of the XForms
>> engine of OPS, I've noticed a couple of things it doesn't appear to
>> support 'out of the box', so to speak.
>> - highlighting of required-ness of fields
>
> This is a known bug:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=303825&group_id=168&atid=350207 
>
>
>> - highlighting of invalid groups, including alert text
>
> Could you elaborate on this? What should happen visually to the group
> in that case? Doesn't it make more sense to highlight invalid items in
> a group? Or do you refer to a group with a ref pointing to an invalid
> group?
>
>

>>> - highlighting of invalid groups, including alert text
>>
>>
>> Could you elaborate on this? What should happen visually to the group
>> in that case? Doesn't it make more sense to highlight invalid items in
>> a group? Or do you refer to a group with a ref pointing to an invalid
>> group?
>>
>>
> The latter - I'm referring to a group pointing to an invalid node in the
> model. So examples might be
> - a group containing 5 fields, and at least one field must be filled in.
> - a group containing a repeat which can't contain more than 5 elements.
>
> In both cases you'd want the group to be highlighted as invalid somehow,
> not each individual child item (because they in themselves may be
> perfectly valid).

> After having done a bit of fairly superficial testing of the XForms
> engine of OPS, I've noticed a couple of things it doesn't appear to
> support 'out of the box', so to speak.
> - highlighting of required-ness of fields
> - highlighting of invalid groups, including alert text
>
> These would be fairly easy to add by extending/editing the right bits of
> xsl - as long as the relevant properties are readily available?
>
> Secondly, I don't see the XForms pseudo classes represented in any way
> in the resulting HTML (http://www.w3.org/TR/xforms/sliceF.html). These
> are useful for styling controls based on their state - for example if I
> want invalid controls to display with a red border. Since you can't
> output actual psuedoclasses, one approach used by Chiba is simply to
> specify them as actual classes on the outputted controls.
>
> Adrian
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

> On 11/2/05, Alessandro Vernet <[hidden email]> wrote:
>  
>> The attached screenshot shows how a control (text field) is rendered now when:
>> 1) A value is required and the control contains a value (first line)
>> 2) A value is required and no value has been entered (second line)
>> 3) The value is invalid
>>    
>
> Here is the attachment.
>
> Alex
>  
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>  

> Right, so I now understand why I wasn't seeing the pseudo-classes
> being represented in the html - I was viewing the source, whereas they
> are added to the DOM via javascript. I'm still stuck in static HTML
> mode :)
>
> Although I really like the overall approach of using a combination of
> CSS 'pseudo' xforms classes and the javascript handler, I'm not sure I
> quite agree with what I see in xforms-styles.js.
>
> Technically the top field containing 'Foo' should also have a class of
> xforms-required, which would make it red. The node is still required,
> regardless of whether it has a value or not. I don't think this is
> correct:
>
>            // Update class on elements
>            for (var i = 0; i < elementsToUpdate.length; i++) {
>                if (required && element.value == "")
> xformsAddClass(elementsToUpdate[i], "xforms-required")
>                else xformsRemoveClass(elementsToUpdate[i],
> "xforms-required");
>            }
>
> What it seems like you should be doing is marking the field *invalid*,
> using the xforms-invalid class (and I'd expect this to be reported by
> the server, rather than a check in the js file)?

> Adrian Baker wrote:
>
>> Right, so I now understand why I wasn't seeing the pseudo-classes
>> being represented in the html - I was viewing the source, whereas they
>> are added to the DOM via javascript. I'm still stuck in static HTML
>> mode :)
>>
>> Although I really like the overall approach of using a combination of
>> CSS 'pseudo' xforms classes and the javascript handler, I'm not sure I
>> quite agree with what I see in xforms-styles.js.
>>
>> Technically the top field containing 'Foo' should also have a class of
>> xforms-required, which would make it red. The node is still required,
>> regardless of whether it has a value or not. I don't think this is
>> correct:
>>
>>            // Update class on elements
>>            for (var i = 0; i < elementsToUpdate.length; i++) {
>>                if (required && element.value == "")
>> xformsAddClass(elementsToUpdate[i], "xforms-required")
>>                else xformsRemoveClass(elementsToUpdate[i],
>> "xforms-required");
>>            }
>>
>> What it seems like you should be doing is marking the field *invalid*,
>> using the xforms-invalid class (and I'd expect this to be reported by
>> the server, rather than a check in the js file)?
>
> Actually, this last sentence is wrong, according to the spec (4.3.5):
>
> <quote>
>
> An instance node is valid if and only if the following conditions hold:
>
>    *
>
>      the constraint model item property is true
>
>    *
>
>      the node satisfies any applicable XML schema definitions
>      (including those associated by the type model item property)
>
> *Note:*
>
> A node that satifies the above conditions is valid even if it is
> required but empty.
>
> </quote>
>
> Which confuses me, because there's no pseudoclass for
> required-but-not-filled-out, so I can't see a sensible way to style
> required fields which are left blank...

> Adrian Baker wrote:
>> Adrian Baker wrote:
>>
>>> Right, so I now understand why I wasn't seeing the pseudo-classes
>>> being represented in the html - I was viewing the source, whereas
>>> they are added to the DOM via javascript. I'm still stuck in static
>>> HTML mode :)
>>>
>>> Although I really like the overall approach of using a combination
>>> of CSS 'pseudo' xforms classes and the javascript handler, I'm not
>>> sure I quite agree with what I see in xforms-styles.js.
>>>
>>> Technically the top field containing 'Foo' should also have a class
>>> of xforms-required, which would make it red. The node is still
>>> required, regardless of whether it has a value or not. I don't think
>>> this is correct:
>>>
>>>            // Update class on elements
>>>            for (var i = 0; i < elementsToUpdate.length; i++) {
>>>                if (required && element.value == "")
>>> xformsAddClass(elementsToUpdate[i], "xforms-required")
>>>                else xformsRemoveClass(elementsToUpdate[i],
>>> "xforms-required");
>>>            }
>>>
>>> What it seems like you should be doing is marking the field
>>> *invalid*, using the xforms-invalid class (and I'd expect this to be
>>> reported by the server, rather than a check in the js file)?
>>
>> Actually, this last sentence is wrong, according to the spec (4.3.5):
>>
>> <quote>
>>
>> An instance node is valid if and only if the following conditions hold:
>>
>>    *
>>
>>      the constraint model item property is true
>>
>>    *
>>
>>      the node satisfies any applicable XML schema definitions
>>      (including those associated by the type model item property)
>>
>> *Note:*
>>
>> A node that satifies the above conditions is valid even if it is
>> required but empty.
>>
>> </quote>
>>
>> Which confuses me, because there's no pseudoclass for
>> required-but-not-filled-out, so I can't see a sensible way to style
>> required fields which are left blank...
>
> Ok, I know what you mean: the required field is always going to be
> marked, even if not empty. That is a problem, I think. Anyway,
> remember the pseudo-classe section of XForms is non-normative. We
> probably just need to create our own, and then get it into one of the
> next iteration of the XForms spec.

> Adrian Baker wrote:
> > Right, so I now understand why I wasn't seeing the pseudo-classes
> > being represented in the html - I was viewing the source, whereas they
> > are added to the DOM via javascript. I'm still stuck in static HTML
> > mode :)
> >
> > Although I really like the overall approach of using a combination of
> > CSS 'pseudo' xforms classes and the javascript handler, I'm not sure I
> > quite agree with what I see in xforms-styles.js.
> >
> > Technically the top field containing 'Foo' should also have a class of
> > xforms-required, which would make it red. The node is still required,
> > regardless of whether it has a value or not. I don't think this is
> > correct:
> >
> >            // Update class on elements
> >            for (var i = 0; i < elementsToUpdate.length; i++) {
> >                if (required && element.value == "")
> > xformsAddClass(elementsToUpdate[i], "xforms-required")
> >                else xformsRemoveClass(elementsToUpdate[i],
> > "xforms-required");
> >            }
> >
> > What it seems like you should be doing is marking the field *invalid*,
> > using the xforms-invalid class (and I'd expect this to be reported by
> > the server, rather than a check in the js file)?
> Actually, this last sentence is wrong, according to the spec (4.3.5):
>
> <quote>
>
> An instance node is valid if and only if the following conditions hold:
>
>     *
>
>       the constraint model item property is true
>
>     *
>
>       the node satisfies any applicable XML schema definitions
>       (including those associated by the type model item property)
>
> *Note:*
>
> A node that satifies the above conditions is valid even if it is
> required but empty.
>
> </quote>
>
> Which confuses me, because there's no pseudoclass for
> required-but-not-filled-out, so I can't see a sensible way to style
> required fields which are left blank...
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

> Erik Bruchez wrote:
> > Adrian Baker wrote:
> >> Adrian Baker wrote:
> >>
> >>> Right, so I now understand why I wasn't seeing the pseudo-classes
> >>> being represented in the html - I was viewing the source, whereas
> >>> they are added to the DOM via javascript. I'm still stuck in static
> >>> HTML mode :)
> >>>
> >>> Although I really like the overall approach of using a combination
> >>> of CSS 'pseudo' xforms classes and the javascript handler, I'm not
> >>> sure I quite agree with what I see in xforms-styles.js.
> >>>
> >>> Technically the top field containing 'Foo' should also have a class
> >>> of xforms-required, which would make it red. The node is still
> >>> required, regardless of whether it has a value or not. I don't think
> >>> this is correct:
> >>>
> >>>            // Update class on elements
> >>>            for (var i = 0; i < elementsToUpdate.length; i++) {
> >>>                if (required && element.value == "")
> >>> xformsAddClass(elementsToUpdate[i], "xforms-required")
> >>>                else xformsRemoveClass(elementsToUpdate[i],
> >>> "xforms-required");
> >>>            }
> >>>
> >>> What it seems like you should be doing is marking the field
> >>> *invalid*, using the xforms-invalid class (and I'd expect this to be
> >>> reported by the server, rather than a check in the js file)?
> >>
> >> Actually, this last sentence is wrong, according to the spec (4.3.5):
> >>
> >> <quote>
> >>
> >> An instance node is valid if and only if the following conditions hold:
> >>
> >>    *
> >>
> >>      the constraint model item property is true
> >>
> >>    *
> >>
> >>      the node satisfies any applicable XML schema definitions
> >>      (including those associated by the type model item property)
> >>
> >> *Note:*
> >>
> >> A node that satifies the above conditions is valid even if it is
> >> required but empty.
> >>
> >> </quote>
> >>
> >> Which confuses me, because there's no pseudoclass for
> >> required-but-not-filled-out, so I can't see a sensible way to style
> >> required fields which are left blank...
> >
> > Ok, I know what you mean: the required field is always going to be
> > marked, even if not empty. That is a problem, I think. Anyway,
> > remember the pseudo-classe section of XForms is non-normative. We
> > probably just need to create our own, and then get it into one of the
> > next iteration of the XForms spec.
> Yes I agree with trying to get this covered in the spec. I suppose this
> area is non-normative because it deals specifically with HTML, whereas
> the spec is meant to be platform agnostic? (Otherwise why else? It's
> certainly something which is important to have applied consistently, or
> as least as much as possible given you can't output genuine
> pseudoclasses. Perhaps because it's expected CSS3 will specify these?).
>
> The other question this raises for me is whether the <xforms:alert> text
> gets displayed. Maybe in many cases you'd be happy with the engine
> specific handling/styling of required-but-not-filled-in, but what if
> your required-ness is a complex condition, in which case you'd really
> want to define an alert specifically ("Because of X Y Z you must provide
> a A B C value")? I suppose you could try messing around with a
> <xforms:message> that gets displayed conditionally... but really in this
> situation the form developer *and* the form user you really wouldn't
> want to have to distinguish between 'invalid' and
> 'required-but-not-filled-in', both in terms of styling and defining
> validation messages.
>
> Anyway, something for the w3c list perhaps.
>
> > And yes, "valid" and "required" are completely different properties.
> > When you submit an instance or subset thereof, the XForms engine
> > checks both for invalid nodes and "required but empty". This has been
> > made clearer in the 2nd edition of the spec.
> >
> > -Erik
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

> 2) The <xforms:alert> message is tied to the control validity. The
> control being required or not, empty or not does not have an impact on
> the alert message being displayed (only validity does).
>
> Erik, is this also your understanding?
>
> Alex
>
> On 11/3/05, Adrian Baker <[hidden email]> wrote:
>  
>> Erik Bruchez wrote:
>>    
>>> Adrian Baker wrote:
>>>      
>>>> Adrian Baker wrote:
>>>>
>>>>        
>>>>> Right, so I now understand why I wasn't seeing the pseudo-classes
>>>>> being represented in the html - I was viewing the source, whereas
>>>>> they are added to the DOM via javascript. I'm still stuck in static
>>>>> HTML mode :)
>>>>>
>>>>> Although I really like the overall approach of using a combination
>>>>> of CSS 'pseudo' xforms classes and the javascript handler, I'm not
>>>>> sure I quite agree with what I see in xforms-styles.js.
>>>>>
>>>>> Technically the top field containing 'Foo' should also have a class
>>>>> of xforms-required, which would make it red. The node is still
>>>>> required, regardless of whether it has a value or not. I don't think
>>>>> this is correct:
>>>>>
>>>>>            // Update class on elements
>>>>>            for (var i = 0; i < elementsToUpdate.length; i++) {
>>>>>                if (required && element.value == "")
>>>>> xformsAddClass(elementsToUpdate[i], "xforms-required")
>>>>>                else xformsRemoveClass(elementsToUpdate[i],
>>>>> "xforms-required");
>>>>>            }
>>>>>
>>>>> What it seems like you should be doing is marking the field
>>>>> *invalid*, using the xforms-invalid class (and I'd expect this to be
>>>>> reported by the server, rather than a check in the js file)?
>>>>>          
>>>> Actually, this last sentence is wrong, according to the spec (4.3.5):
>>>>
>>>> <quote>
>>>>
>>>> An instance node is valid if and only if the following conditions hold:
>>>>
>>>>    *
>>>>
>>>>      the constraint model item property is true
>>>>
>>>>    *
>>>>
>>>>      the node satisfies any applicable XML schema definitions
>>>>      (including those associated by the type model item property)
>>>>
>>>> *Note:*
>>>>
>>>> A node that satifies the above conditions is valid even if it is
>>>> required but empty.
>>>>
>>>> </quote>
>>>>
>>>> Which confuses me, because there's no pseudoclass for
>>>> required-but-not-filled-out, so I can't see a sensible way to style
>>>> required fields which are left blank...
>>>>        
>>> Ok, I know what you mean: the required field is always going to be
>>> marked, even if not empty. That is a problem, I think. Anyway,
>>> remember the pseudo-classe section of XForms is non-normative. We
>>> probably just need to create our own, and then get it into one of the
>>> next iteration of the XForms spec.
>>>      
>> Yes I agree with trying to get this covered in the spec. I suppose this
>> area is non-normative because it deals specifically with HTML, whereas
>> the spec is meant to be platform agnostic? (Otherwise why else? It's
>> certainly something which is important to have applied consistently, or
>> as least as much as possible given you can't output genuine
>> pseudoclasses. Perhaps because it's expected CSS3 will specify these?).
>>
>> The other question this raises for me is whether the <xforms:alert> text
>> gets displayed. Maybe in many cases you'd be happy with the engine
>> specific handling/styling of required-but-not-filled-in, but what if
>> your required-ness is a complex condition, in which case you'd really
>> want to define an alert specifically ("Because of X Y Z you must provide
>> a A B C value")? I suppose you could try messing around with a
>> <xforms:message> that gets displayed conditionally... but really in this
>> situation the form developer *and* the form user you really wouldn't
>> want to have to distinguish between 'invalid' and
>> 'required-but-not-filled-in', both in terms of styling and defining
>> validation messages.
>>
>> Anyway, something for the w3c list perhaps.
>>
>>    
>>> And yes, "valid" and "required" are completely different properties.
>>> When you submit an instance or subset thereof, the XForms engine
>>> checks both for invalid nodes and "required but empty". This has been
>>> made clearer in the 2nd edition of the spec.
>>>
>>> -Erik
>>>      

>  Absolutely.
>
>
>  Alessandro Vernet wrote:
>  Hi Adrian,
>
> I have been also fooled in the past by the fact that XForms considers
> empty required fields as not necessarly invalid. So we all understand
> that a field can independently be valid or not, required or not.
>
> Now I agree with you that we should always leave xforms-required on
> required fields. Since it is a common scenario to have the empty
> required fields flagged in a certain way, we could add and remove the
> classes xforms-required-empty and xforms-required-filled. I think that
> would be more consistent. Would you agree?
>
> Alex
>
> On 11/3/05, Adrian Baker <[hidden email]> wrote:
>
>
>  Adrian Baker wrote:
>
>
>  Right, so I now understand why I wasn't seeing the pseudo-classes
> being represented in the html - I was viewing the source, whereas they
> are added to the DOM via javascript. I'm still stuck in static HTML
> mode :)
>
> Although I really like the overall approach of using a combination of
> CSS 'pseudo' xforms classes and the javascript handler, I'm not sure I
> quite agree with what I see in xforms-styles.js.
>
> Technically the top field containing 'Foo' should also have a class of
> xforms-required, which would make it red. The node is still required,
> regardless of whether it has a value or not. I don't think this is
> correct:
>
>  // Update class on elements
>  for (var i = 0; i < elementsToUpdate.length; i++) {
>  if (required && element.value == "")
> xformsAddClass(elementsToUpdate[i], "xforms-required")
>  else xformsRemoveClass(elementsToUpdate[i],
> "xforms-required");
>  }
>
> What it seems like you should be doing is marking the field *invalid*,
> using the xforms-invalid class (and I'd expect this to be reported by
> the server, rather than a check in the js file)?
>
>  Actually, this last sentence is wrong, according to the spec (4.3.5):
>
> <quote>
>
> An instance node is valid if and only if the following conditions hold:
>
>  *
>
>  the constraint model item property is true
>
>  *
>
>  the node satisfies any applicable XML schema definitions
>  (including those associated by the type model item property)
>
> *Note:*
>
> A node that satifies the above conditions is valid even if it is
> required but empty.
>
> </quote>
>
> Which confuses me, because there's no pseudoclass for
> required-but-not-filled-out, so I can't see a sensible way to style
> required fields which are left blank...
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> 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: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

> On 11/9/05, Erik Bruchez <[hidden email]> wrote:
>
>>The spec is not very detailed on the subject. It just says the following:
>>
>>"The optional element alert provides a convenient way to attach alert or
>>error information to a form control. Rendering of this element is
>>implementation-defined, and there is no default level such as modal or
>>ephemeral for the displayed message."
>
>
> Right now, next to each control we generate a label that looks like:
>
> <label for="control-id" class="xforms-alert-inactive">Error message</label>
>
> The "error message" comes from the <xforms:alert>, and the class on
> that label can be either xforms-alert-inactive or xforms-alert-active
> depending on the validity of the node bound to the control. This means
> that one can change the CSS to setup what an "active" and "inactive"
> label looks like, but can't setup with CSS what makes the label active
> or inactive. There is maybe something we need to do there to provide
> more flexibility.

>>However, visibility is meant to be controlled with CSS, as per the
>>following example rules:
>>
>>*:valid   > xforms|alert { display: none; }
>>*:invalid > xforms|alert { display: inline; }
>
>
> And how would one go about displaying the alert if the control is
> invalid or required but empty with this type of CSS, which seems like
> a reasonable scenario?

> > And how would one go about displaying the alert if the control is
> > invalid or required but empty with this type of CSS, which seems like
> > a reasonable scenario?
>
> Maybe something like this:
>
> xforms|alert { display: none; }
> *:invalid > xforms|alert { display: inline; }
> *:required-but-empty > xforms|alert { display: inline; }
>
> Of course, the second pseudo-class is not specified by XForms, but
> that's a problem, as we know.