291119 - create default styling for form controls

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect, P1)

Description

[Anne (:annevk)]

Testcase:
 <http://annevankesteren.nl/test/xml/xforms/tryouts/relevant-001>

The second form control should look disabled until the first form control has a
value greater than 2.03.

I think this should be easy to solve by copying some of the style rules here:
 <http://lxr.mozilla.org/seamonkey/source/layout/style/forms.css#252>

... to:
 <http://lxr.mozilla.org/seamonkey/source/extensions/xforms/xforms.css>

Comment 1

[Anne (:annevk)]

Attachment: something like this

I need to know to which this should apply and if we perhaps also need:
 <http://lxr.mozilla.org/seamonkey/source/layout/style/forms.css#366>

... and other similar declarations.

Comment 2

[Anne (:annevk)]

mpt, hixie: any idea what would be better? Using the styling disabled form
controls have in HTML or not displaying them at all which is what some other
XForms plugins are doing?

Comment 3

[aaronr]

based on a long series of discussions we had months ago, we decided not to have
any default styles in the browser.  After talking to the other forms processor
people and each other, we figured that most xforms are going to be just as
heavily styled as html so it is no real burden to have the form author add a few
more styles to get the controls exactly as they'd like them.  And, of course,
anyone who wants to alter their own xforms.css to provide their own default
styling is welcome to (which is what most major deployments would likely do anyhow).

Comment 4

[Anne (:annevk)]

Recognized markup should still be usable when author styles are disabled. (A
xhtml:h1 element still looks more important than an xhtml:h2 element in a visual
browser even when styles are disabled.)

Comment 5

[Matthew T (active 1999-2002)]

What Anne said: customizability is not a valid excuse for bad default behavior.

As for the original question: In ~99 percent of cases, non-applicable form
controls should be visible but unavailable. Invisibility should be used only
where the non-applicable controls (a) would add a lot of visual clutter and (b)
are fairly likely to never become applicable in the lifetime of the form. Form
providers could override the default styling in that ~1 percent of cases.

Comment 6

[aaronr]

I'm sorry to disagree, but if we are going to have a default behavior at all,
then it should be a default behavior that is consistent with other browser-based
XForms processors.  That means that 'disabled' controls are hidden, not merely
appearing greyed out.  We should strive to provide the user with a default
experience that is like the default experience that they'd get with any other
XForms processor.  Most of these are spelled out in F.3 of the spec under
http://www.w3.org/TR/xforms/index-all.html#style

Comment 7

[Allan Beaufour]

*** Bug 303849 has been marked as a duplicate of this bug. ***

Comment 8

[Allan Beaufour]

(In reply to comment #6)
> I'm sorry to disagree, but if we are going to have a default behavior at all,
> then it should be a default behavior that is consistent with other browser-based
> XForms processors.  That means that 'disabled' controls are hidden, not merely
> appearing greyed out.  We should strive to provide the user with a default
> experience that is like the default experience that they'd get with any other
> XForms processor.  Most of these are spelled out in F.3 of the spec under
> http://www.w3.org/TR/xforms/index-all.html#style

So, should we do this? That is:
*:disabled { visibility: hidden; }

People seem to expect this behaviour, and that's what other processors do AFAIK.

Comment 9

[Allan Beaufour]

We should also look at default styling for required too for example. Still the
minimal amount IMHO.

Comment 10

[Anne (:annevk)]

[e-mail], why should we act similar to other XForms processors? It
would be better to be compatible with form controls that already exist on the
web. The ones people are familiar with, imho.

Comment 11

[Kevin Brosnan]

*** Bug 312479 has been marked as a duplicate of this bug. ***

Comment 12

[aaronr]

(In reply to comment #10)
> [e-mail], why should we act similar to other XForms processors? It
> would be better to be compatible with form controls that already exist on the
> web. The ones people are familiar with, imho.

As people begin evaluating XForms for use in their corporate intranets (the most
likely early adopters of XForms), they will probably be comparing one processor
against another as they develop their forms and even as they learn XForms in
general.  I personally think that if they try their forms in XSmiles,
formsPlayer and Novell's plugin and get pretty similar behavior and then try our
processor and get a very different rendering, then they will not be encouraged
by the XForms story.  Sameness and compatibility among client-side processors
will go a long way in helping to portray XForms as a solid technology.

And as we've come to learn the more we talk about this, no matter what we pick
as our default style, the form author will most likely want something else for
at least some of the pseudoclasses that they use.  If we start at the same point
that other client-side processors do, then when they write stylesheets, they'll
be heading in the same direction no matter which processors they may be
deploying with.  I would think it be much easier to maintain a stylesheet over
multiple versions if the styles for the different platforms were all trying to
accomplish the same thing rather than having different style rules for different
processors trying to meet in the middle.

That is why I think that we need to be compatible with the other processors. 
Now why THEY chose these particular defaults, I assume that it is to reflect the
state of the data.  For example, if irrelevant controls are just grayed out but
I see that they contain data, then it may be easy for someone to wonder why they
saw the data in front of them but it wasn't submitted.  But that is just a guess
on my part.

Comment 13

[alexander :surkov (:asurkov)]

If I understand right then aaronr insist on we shouldn't have styles for MIPs (model item properties). In instance it means if instance data has relevant="false()" MIP then I should be able to edit it and set focus. But specification says: "The relevant model item property provides hints to the XForms user interface regarding visibility, focus, and navigation order. In general, when true, associated form controls should be made visible. When false, associated form controls (and any children) and group and switch elements (including content) should be made unavailable, removed from the navigation order, and not allowed focus.". Aaronr, what do you exactly mean when you say "we decided not to have
any default styles in the browser"?

Comment 14

[Allan Beaufour]

(In reply to comment #13)
> If I understand right then aaronr insist on we shouldn't have styles for MIPs
> (model item properties). In instance it means if instance data has
> relevant="false()" MIP then I should be able to edit it and set focus. But
> specification says: "The relevant model item property provides hints to the
> XForms user interface regarding visibility, focus, and navigation order. In
> general, when true, associated form controls should be made visible. When
> false, associated form controls (and any children) and group and switch
> elements (including content) should be made unavailable, removed from the
> navigation order, and not allowed focus.". Aaronr, what do you exactly mean
> when you say "we decided not to have
> any default styles in the browser"?

That's an old comment. I _think_ "our view" is that we should enable some minimal styling so we look like Novell/X-Smiles out-of-the-box.

Comment 15

[aaronr]

Yep, in comment #12 you can see my opinion.  I don't mind a few default stylings to maintain compatibility with some other processors, as long as the defaults can be completely overridden by the form author.

Comment 16

[Allan Beaufour]

Attachment: Do not display disabled controls

This seems to be what users expect, and what other processors do.

Comment 17

[Anne (:annevk)]

I'm not convinced that users expect disabled controls to be hidden. In most UIs they are displayed, but greyed out.

Comment 18

[aaronr]

(In reply to comment #17)
> I'm not convinced that users expect disabled controls to be hidden. In most UIs
> they are displayed, but greyed out.
> 

The appearance to the user is the concern of the form author, not the processor.  If the form author feels like his users would like disabled controls rather than hidden controls, that is certainly something he should be able to provide via the processor.  And if that is not possible, then that is a bug in our processor.

But the defaults of the processor should be what is most convenient to the xforms author.  And I believe, as I have stated before, that what would be most convenient to the XForms author is a default behavior that is consistent among other XForms processors.  That way the form author will have to use similar styling across ALL processors to get the desired behavior rather than having to mix and match styling on different processors to get the desired outcome.  

Comment 19

[aaronr]

Comment on attachment 204353 [details] [diff] [review]
Do not display disabled controls

works for me

Comment 20

[Allan Beaufour]

Checked in on trunk

Comment 21

[aaronr]

checked into MOZILLA_1_8_BRANCH via bug 323691.  Leaving open for now until it gets into 1.8.0

Comment 22

[aaronr]

verfied fixed on MOZILLA_1_8_BRANCH