interaction between relevant and CSS display: property?

[C. M. Sperberg-McQueen-2]

Working on a simple XForms exercise today, I ran across an
unexpected interaction between the relevant attribute on
the xf:bind element and my CSS stylesheet -- or what looks
to me at first glance like such an interaction.

Following the example shown at

   http://en.wikibooks.org/wiki/XForms/Address_Aligned

I have used CSS to style fieldset, xf:input, xf:label,
and the CSS pseudo-element xf|input::value with the
values table, table-row, and table-cell, respectively,
for the CSS display property.  This worked rather nicely,
I thought.

But when I added a relevance test to the appropriate
bind elements, I was a little surprised to see that
although the 'relevant' attribute seems to have the
expected effect on the submitted XML (that is,
irrelevant elements are omitted), it doesn't seem to
have any effect on the display, when using the Mozilla
XForms extension.

Is this the prescribed behavior?  A legal behavior? A
shortcoming in the current implementation of the
Mozilla extension?  An error on my part?  Zero or more
of the above?

I had expected (perhaps naively) that the CSS properties
assigned to forms widgets would apply only when the
widgets themselves were relevant, but it appears from
this side of the keyboard that the use of table-related
display properties is overriding the relevance setting,
as far as visibility is concerned.

Does the XForms spec specify the interaction between
the setting of visibility using the 'relevant' attribute
on xf:bind, and the setting of CSS properties?  Is the
behavior I'm seeing a bug in the Mozilla extension?
Or is interaction with style mechanisms explicitly
left implementation-defined or implementation-dependent?

I've tried to replicate the problem using Orbeon, but
there the display: table, display:table-row, and display:
table-cell clauses in my CSS appear to have no effect,
so I haven't succeeded in using Orbeon's implementation
to test for interaction between CSS and XForms
visibility.

As you can tell, I'm not even sure what questions to ask
here.  If it's a bug in the Mozilla implementation, I
should be raising this on one of their implementation-specific
discussion lists, not here.  But at the moment, I think
I'm mostly trying to learn what obligations the spec
imposes on implementations in situations like this one.
Any illumination readers of this list can throw on
my problem would be gratefully accepted.

I attach the form that illustrates the phenomenon.  When
the table styling is commented out, the selection of the
'Cash' option causes the credit-card number and expiration
date to disappear, but when the CSS table styling is
present, the credit card details are always visible.

--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

[Erik Bruchez]

In Orbeon Forms, we don't (yet) support the pseudo-classes suggested
by XForms (which are non-normative). Instead, we use classes such as
xforms-submit, xforms-label, xforms-disabled, etc. In theory it is
possible to write a translation layer between CSS with pseudo-classes
and classes understood by the browser, which is why I said "yet" ;)

Now this said, my understanding is that non-relevance:

* renders the control non-available for data input/output, event
handling, etc. It is basically a dead control.
* non-normatively allows CSS to match on a pseudo-class or class (e.g.
:disabled or xforms-disabled), typically to completely hide the markup
associated with the control.

In our implementation, that's what we do. In fact, we have fairly
strong default CSS rules to hide non-relevant items. By making these
rules strong, we reduce the likelihood that some rules written by the
user will override them.

Note that to make things work properly with IE and funny interactions
between layout and certain JavaScript-enabled controls, some tricks
have to be employed (following techniques implemented by JavaScript
frameworks like YUI). Here is how our basic relevance CSS looks like:

html body .xforms-form .xforms-disabled-subsequent { display: none }
html body .xforms-form .xforms-disabled { top: -10000px; left:
-10000px; visibility: hidden; position: absolute }

(The rules could be made even stronger by using ids.)

-Erik

On Thu, Aug 6, 2009 at 8:19 AM, C. M.
Sperberg-McQueen<cmsmcq@...> wrote:

> Working on a simple XForms exercise today, I ran across an
> unexpected interaction between the relevant attribute on
> the xf:bind element and my CSS stylesheet -- or what looks
> to me at first glance like such an interaction.
>
> Following the example shown at
>
>  http://en.wikibooks.org/wiki/XForms/Address_Aligned
>
> I have used CSS to style fieldset, xf:input, xf:label,
> and the CSS pseudo-element xf|input::value with the
> values table, table-row, and table-cell, respectively,
> for the CSS display property.  This worked rather nicely,
> I thought.
>
> But when I added a relevance test to the appropriate
> bind elements, I was a little surprised to see that
> although the 'relevant' attribute seems to have the
> expected effect on the submitted XML (that is,
> irrelevant elements are omitted), it doesn't seem to
> have any effect on the display, when using the Mozilla
> XForms extension.
>
> Is this the prescribed behavior?  A legal behavior? A
> shortcoming in the current implementation of the
> Mozilla extension?  An error on my part?  Zero or more
> of the above?
>
> I had expected (perhaps naively) that the CSS properties
> assigned to forms widgets would apply only when the
> widgets themselves were relevant, but it appears from
> this side of the keyboard that the use of table-related
> display properties is overriding the relevance setting,
> as far as visibility is concerned.
>
> Does the XForms spec specify the interaction between
> the setting of visibility using the 'relevant' attribute
> on xf:bind, and the setting of CSS properties?  Is the
> behavior I'm seeing a bug in the Mozilla extension?
> Or is interaction with style mechanisms explicitly
> left implementation-defined or implementation-dependent?
>
> I've tried to replicate the problem using Orbeon, but
> there the display: table, display:table-row, and display:
> table-cell clauses in my CSS appear to have no effect,
> so I haven't succeeded in using Orbeon's implementation
> to test for interaction between CSS and XForms
> visibility.
>
> As you can tell, I'm not even sure what questions to ask
> here.  If it's a bug in the Mozilla implementation, I
> should be raising this on one of their implementation-specific
> discussion lists, not here.  But at the moment, I think
> I'm mostly trying to learn what obligations the spec
> imposes on implementations in situations like this one.
> Any illumination readers of this list can throw on
> my problem would be gratefully accepted.
>
> I attach the form that illustrates the phenomenon.  When
> the table styling is commented out, the selection of the
> 'Cash' option causes the credit-card number and expiration
> date to disappear, but when the CSS table styling is
> present, the credit card details are always visible.
>
> --
> ****************************************************************
> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
> * http://www.blackmesatech.com
> * http://cmsmcq.com/mib
> * http://balisage.net
> ****************************************************************
>
>
>
>
>
>