W3C home > Mailing lists > Public > www-forms@w3.org > August 2009

Re: interaction between relevant and CSS display: property?

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 6 Aug 2009 09:49:45 -0700
Message-ID: <e81b48eb0908060949r5651d073o2e6b1784b9502ef8@mail.gmail.com>
To: www-forms@w3.org
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.)


On Thu, Aug 6, 2009 at 8:19 AM, C. M.
Sperberg-McQueen<cmsmcq@blackmesatech.com> 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
> ****************************************************************
Received on Thursday, 6 August 2009 16:50:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:22 UTC