Last Comment Bug 291119 - create default styling for form controls
: create default styling for form controls
Status: RESOLVED FIXED
: fixed1.8.0.2, fixed1.8.1
Product: Core
Classification: Components
Component: XForms (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: ---
Assigned To: Allan Beaufour
: Stephen Pride
Mentors:
: 303849 312479 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-20 03:27 PDT by Anne (:annevk)
Modified: 2006-07-07 11:29 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
something like this (1.33 KB, patch)
2005-04-20 03:38 PDT, Anne (:annevk)
no flags Details | Diff | Review
Do not display disabled controls (795 bytes, patch)
2005-11-28 07:00 PST, Allan Beaufour
aaronr: review+
bugs: review+
Details | Diff | Review

Description Anne (:annevk) 2005-04-20 03:27:20 PDT
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) 2005-04-20 03:38:46 PDT
Created attachment 181266 [details] [diff] [review]
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) 2005-04-20 04:41:29 PDT
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 2005-04-20 05:37:06 PDT
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) 2005-04-20 05:45:57 PDT
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 Paul Thomas 2005-04-21 22:34:12 PDT
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 2005-04-22 09:41:24 PDT
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 2005-08-08 00:42:05 PDT
*** Bug 303849 has been marked as a duplicate of this bug. ***
Comment 8 Allan Beaufour 2005-08-18 01:11:25 PDT
(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 2005-10-17 01:23:59 PDT
We should also look at default styling for required too for example. Still the
minimal amount IMHO.
Comment 10 Anne (:annevk) 2005-10-17 01:51:46 PDT
aaronr@us.ibm.com, 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 2005-10-17 05:02:48 PDT
*** Bug 312479 has been marked as a duplicate of this bug. ***
Comment 12 aaronr 2005-10-18 01:59:23 PDT
(In reply to comment #10)
> aaronr@us.ibm.com, 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 2005-11-17 01:18:11 PST
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 2005-11-17 06:54:46 PST
(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 2005-11-17 09:34:11 PST
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 2005-11-28 07:00:22 PST
Created attachment 204353 [details] [diff] [review]
Do not display disabled controls

This seems to be what users expect, and what other processors do.
Comment 17 Anne (:annevk) 2005-11-28 09:02:04 PST
I'm not convinced that users expect disabled controls to be hidden. In most UIs they are displayed, but greyed out.
Comment 18 aaronr 2005-11-28 09:29:22 PST
(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 2005-11-29 08:33:11 PST
Comment on attachment 204353 [details] [diff] [review]
Do not display disabled controls

works for me
Comment 20 Allan Beaufour 2006-01-11 00:20:56 PST
Checked in on trunk
Comment 21 aaronr 2006-02-02 17:30:23 PST
checked into MOZILLA_1_8_BRANCH via bug 323691.  Leaving open for now until it gets into 1.8.0
Comment 22 aaronr 2006-07-07 11:29:11 PDT
verfied fixed on MOZILLA_1_8_BRANCH

Note You need to log in before you can comment on or make changes to this bug.