368663 - label should be placed after checkbox for boolean input

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[alexander :surkov (:asurkov)]

Attachment: patch

label should be placed after checkbox for boolean inputs

Comment 1

[Steve Speicher]

Why is this being changed?

Comment 2

[aaronr]

(In reply to comment #1)
> Why is this being changed?
> 

good question.  No other XForms processor that I know of puts the label after the checkbox.  XSmiles, Novell and formsPlayer all put the label first.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #2)
> (In reply to comment #1)
> > Why is this being changed?
> > 
> 
> good question.  No other XForms processor that I know of puts the label after
> the checkbox.  XSmiles, Novell and formsPlayer all put the label first.
> 

Oh, then I r- :(

Comment 4

[Leigh L. Klotz, Jr.]

I believe x-smiles uses the caption-side CSS feature to control it.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> (In reply to comment #1)
> > Why is this being changed?
> > 
> 
> good question.  No other XForms processor that I know of puts the label after
> the checkbox.  XSmiles, Novell and formsPlayer all put the label first.
> 

Ok, at least it is valid for XUL because XForms controls should looks like analogies controls from host language.

Though I think it is fine for XHTML too, just please look at this bugzilla page to find an example :). In any way, XHTML let me to choose where to place label, but XForms dont'. So, I probably follow for Leigh, we need a way to control it, for example, by CSS.

Comment 6

[aaronr]

(In reply to comment #5)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Why is this being changed?
> > > 
> > 
> > good question.  No other XForms processor that I know of puts the label after
> > the checkbox.  XSmiles, Novell and formsPlayer all put the label first.
> > 
> 
> Ok, at least it is valid for XUL because XForms controls should looks like
> analogies controls from host language.

I disagree.  I believe that the default representation should be what is consistent across the other browser-based xforms processors, unless there is a REALLY compelling reason.

> 
> Though I think it is fine for XHTML too, just please look at this bugzilla page
> to find an example :).

Actually, the labels for the checkboxes in bugzilla that I saw were all explicitly placed after the input control that they went with.  That isn't default, that is author preference.

> In any way, XHTML let me to choose where to place label,
> but XForms dont'. So, I probably follow for Leigh, we need a way to control
> it, for example, by CSS.
> 

I am all for that.  It would be my preference that in all of our host languages (so far, just XUL and XHTML) the default label position be before the control and that we check CSS to see if the user wants the label to be after the control.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > Why is this being changed?
> > > > 
> > > 
> > > good question.  No other XForms processor that I know of puts the label after
> > > the checkbox.  XSmiles, Novell and formsPlayer all put the label first.
> > > 
> > 
> > Ok, at least it is valid for XUL because XForms controls should looks like
> > analogies controls from host language.
> 
> I disagree.  I believe that the default representation should be what is
> consistent across the other browser-based xforms processors, unless there is a
> REALLY compelling reason.

I'm not sure hte other xforms processors have right behaviour ;)

> > 
> > Though I think it is fine for XHTML too, just please look at this bugzilla page
> > to find an example :).
> 
> Actually, the labels for the checkboxes in bugzilla that I saw were all
> explicitly placed after the input control that they went with.  That isn't
> default, that is author preference.

Can you show me an example where label is placed before checkbox?

> > In any way, XHTML let me to choose where to place label,
> > but XForms dont'. So, I probably follow for Leigh, we need a way to control
> > it, for example, by CSS.
> > 
> 
> I am all for that.  It would be my preference that in all of our host languages
> (so far, just XUL and XHTML) the default label position be before the control
> and that we check CSS to see if the user wants the label to be after the
> control.
> 

Ok, what CSS is more proper for this?

Comment 8

[aaronr]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #2)
> > > > (In reply to comment #1)
> > > > > Why is this being changed?
> > > > > 
> > > > 
> > > > good question.  No other XForms processor that I know of puts the label after
> > > > the checkbox.  XSmiles, Novell and formsPlayer all put the label first.
> > > > 
> > > 
> > > Ok, at least it is valid for XUL because XForms controls should looks like
> > > analogies controls from host language.
> > 
> > I disagree.  I believe that the default representation should be what is
> > consistent across the other browser-based xforms processors, unless there is a
> > REALLY compelling reason.
> 
> I'm not sure hte other xforms processors have right behaviour ;)
> 
> > > 
> > > Though I think it is fine for XHTML too, just please look at this bugzilla page
> > > to find an example :).
> > 
> > Actually, the labels for the checkboxes in bugzilla that I saw were all
> > explicitly placed after the input control that they went with.  That isn't
> > default, that is author preference.
> 
> Can you show me an example where label is placed before checkbox?

http://www.sapdesignguild.org/resources/htmlb_guidance/checkbox_layout.html

Also, if you look at this accessibility doc:
http://www.w3.org/TR/WAI-WEBCONTENT/
In checkpoint 10.2 you'll see that they recommend the label be immediately to the left of the control.  It doesn't provide an exception for checkbox or radio button.

> 
> > > In any way, XHTML let me to choose where to place label,
> > > but XForms dont'. So, I probably follow for Leigh, we need a way to control
> > > it, for example, by CSS.
> > > 
> > 
> > I am all for that.  It would be my preference that in all of our host languages
> > (so far, just XUL and XHTML) the default label position be before the control
> > and that we check CSS to see if the user wants the label to be after the
> > control.
> > 
> 
> Ok, what CSS is more proper for this?
> 

I asked on the W3C XForms mailing list if any other processor allows for this behavior, if CSS can be used to do it, etc.  I'll let you know what they said.  I tried caption-side in XSmiles, but I didn't see any difference.  But I might have applied the rule incorrectly.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to comment #8)

> > Can you show me an example where label is placed before checkbox?
> 
> http://www.sapdesignguild.org/resources/htmlb_guidance/checkbox_layout.html

Your example shows my point ;)

> Also, if you look at this accessibility doc:
> http://www.w3.org/TR/WAI-WEBCONTENT/
> In checkpoint 10.2 you'll see that they recommend the label be immediately to
> the left of the control.  It doesn't provide an exception for checkbox or radio
> button.

Really WAI webcontent says:
"The label must immediately precede its control on the same line (allowing more than one control/label per line) or be in the line preceding the control (with only one label and one control per line)"

AaronLev, can you give some clarification?

Comment 10

[Aaron Leventhal]

First, WCAG 1.0 is on the way out, see the side by side comparison:
http://www.w3.org/TR/WCAG20/appendixD.html

The wording says "Until user agents support explicit associations"
This means the reason they had the checkpoint at all, was that in the past screen readers could not progammatically determine which label was associated with which control. They had to use a heuristic, so it was advisable to put the label to the left. We now have that capability in user agents, so the checkpoint is no longer relevant.

In any case, they really did not mean that for radio buttons. It has always been standard practice to put the radio/checkbox to the left of the label. Both users, and screen readers (for whom the original 10.2 checkpoint was created) expect that.

IMO put the checkbox to the left, otherwise users will get confused and potentially check the wrong things. Every popular app does that, and if other XForms processors do something else, the developers were misguided.

Comment 11

[Aaron Leventhal]

Instead of left, I probably should have said -- the checkbox/radio precedes the label in reading order. So, for rtl languages the I think checkbox/radio would be to the right. This allows them to line up visually beand  consistent with other user interfaces.

Comment 12

[aaronr]

(In reply to comment #10)

> IMO put the checkbox to the left, otherwise users will get confused and
> potentially check the wrong things. Every popular app does that, and if other
> XForms processors do something else, the developers were misguided.
> 

Misguided, perhaps.  But I think that users will be just as likely (or even more likely) to check the wrong things if they use formsPlayer, XSmiles, etc. in the office to do a routine form and then on a less frequent basis use Firefox at home to do the same forms.  Because even then their familiarity with the form can't save them from the misstep.

The debate has pretty much died down on the W3C mailing list.  Most seem to agree (at least no one disagrees) that something needs to be done to allow a form author to specify how to place a label relative to a control.  But they don't know what that should be.  I doubt that the question will be answered quickly.

Comment 13

[aaronr]

(In reply to comment #11)
> Instead of left, I probably should have said -- the checkbox/radio precedes the
> label in reading order. So, for rtl languages the I think checkbox/radio would
> be to the right. This allows them to line up visually beand  consistent with
> other user interfaces.
> 

Which is fine.  But until the W3C defines how this should work and Mozilla decides to support it, then we'll have to do it the old fashioned way.  We'll have to create a reversed anonymous content for almost all of our -xhtml and -xul xbl bindings that get used when the language is rtl.  Well, I assume.  I don't know how else we'd support this since we place our labels explicitly in the anonymous content now.

Comment 14

[Leigh L. Klotz, Jr.]

W3C is not going to define it until there is an XHTML+XForms integration published, and since CDF has decided not to do that, everybody is on their own integrating XForms.  Even CSS is not normative in the XForms Recommendation.  That being said, caption-side is the closest we have to a suggestion from a W3C working group on this issue.

Comment 15

[aaronr]

(In reply to comment #14)
> W3C is not going to define it until there is an XHTML+XForms integration
> published, and since CDF has decided not to do that, everybody is on their own
> integrating XForms.  Even CSS is not normative in the XForms Recommendation. 
> That being said, caption-side is the closest we have to a suggestion from a W3C
> working group on this issue.
> 

What about the XHTML working group?  XHTML2 will need to answer this issue, won't it?

In the meantime, I'm fine with using caption-side.

Comment 16

[alexander :surkov (:asurkov)]

(In reply to comment #15)

> In the meantime, I'm fine with using caption-side.
> 

But what's about default behaviour?

Comment 17

[aaronr]

(In reply to comment #16)
> (In reply to comment #15)
> 
> > In the meantime, I'm fine with using caption-side.
> > 
> 
> But what's about default behaviour?
> 

I'm fine with putting the label on the right as default, as long as a user can style it 'left' when they want to emulate the other xforms processors

Comment 18

[alexander :surkov (:asurkov)]

Comment on attachment 253294 [details] [diff] [review]
patch

cancelling review per comment 17

Comment 19

[Philipp Wagner [:imphil]]

Attachment: XHTML testcase

Comment 20

[Philipp Wagner [:imphil]]

Attachment: XUL testcase

Comment 21

[Philipp Wagner [:imphil]]

Attachment: add a new attribute for label positioning and change default positioning

This patch adds a new attribute in the new http://www.mozilla.org/projects/xforms/2009/extensions namespace, called labelposition. It takes the values "before" and "after" and places the label before or after the checkbox. The default is now that the label is placed after the checkbox (left or right depending on the reading direction). The testcases show this.

Please note that this changes the appearance of all forms using checkboxes as of now, but catches up with other XForms implementations as well as with the default UI guidelines (usually checkboxes are before the label, have a look in your favorite application or the Firefox preferences dialog). The insurance form example shows this change quite well.

I would have used a CSS property for this setting, but the previously proposed caption-side has only the deprecated left and right values, which don't take LTR languages into account. Adding a custom CSS property like -moz-xforms-label-position to Mozilla seems to be non-trivial, so I took the attribute approach.

The old discussion on the w3 mailing list mentioned in this bug is here: http://markmail.org/thread/s2ugsxkazc7tgj45

Another little change is to show the default cursor for labels instead of the text cursor. This makes XForms inputs behave the same as normal XHTML inputs. 

The XUL checkboxes now set the @label attribute if possible to make the checkboxes behave more like native XUL checkboxes.

Comment 22

[alexander :surkov (:asurkov)]

I think I'm fine with the approach and I'll do review however you should check if Aaron is fine with it as well.

Comment 23

[alexander :surkov (:asurkov)]

Comment on attachment 416331 [details] [diff] [review]
add a new attribute for label positioning and change default positioning 


>+  <!-- INPUT: BOOLEAN WITH LABEL AFTER CHECKBOX -->

>+      <constructor>
>+        // put the xforms:label node into xul:checkbox/@label

I realize what you are going to solve but

>+        var labels = this.getElementsByTagNameNS("http://www.w3.org/2002/xforms", "label");
>+        if (!labels)
>+          return;
>+        var label = labels[0];
>+        var control = this.getControlElement();
>+        control.setAttribute('label', label.firstChild.nodeValue);

label can be pretty complex

>+        this.removeChild(label);

it's bad to change explicit DOM.

Comment 24

[aaronr]

Comment on attachment 416331 [details] [diff] [review]
add a new attribute for label positioning and change default positioning 

I guess I'm fine with adding support for the attribute but I guess I don't get why saying 'before' and 'after' takes into account LTR languages any better than the CSS property.  In any event, please:

1) Test to make sure that there won't be any problems if labelposition is set yet there is no label
2) Test with complex label content (i.e. I think we support embedding html tags in labels currently)
3) Update the Mozilla-specific documentation for XForms to mention the new attribute and where it is supported.
4) Open a new bug so that we can support this attribute everywhere.  In that bug you'll have to define whether this attribute affects child content.  For example, if you set it on a select1 or a select with appearance="full", should it affect the contained checkboxes and radio buttons?  I'm guessing not.
5) I'd suggest mentioning the impending change on the newsgroup.  I think that it would be bad form to change the default layout of users' xforms (some of which may be years and years old) without some kind of warning.

I'm going to r- the patch for the reason that Alex gave, we can't be changing the author's DOM underneath them.  But other than that I don't see a problem with it.

Comment 25

[Philipp Wagner [:imphil]]

It's about time to come back to this bug ;)

To Aarons questions:
0) before and after are better than left and right if we want to correctly support RTL languages. On LTR, before=left, after=right; on RTL, before=right, after=left, just as expected by the reader.

1-2) Tested and works as expected. I created a reftest for this, and I will open a bug to add support for reftests soon to make sure we don't regress this functionality.

3-5) I will do this as soon as the patch is commited.


For HTML: The HTML bindings look great and don't show any difference to the plain HTML ones.


For XUL: I changed the patch to not change the DOM for the XUL binding. This works, but requires me not to use the xul:checkbox element any more, but a html:input. I tried to get the exact look as on xul:checkbox, but that turned out impossible/unnecessary hard for a couple of reasons:
- CSS and binding are platform dependant
- label before checkbox is not supported by XUL

So I tried to find a reasonable look, that comes close to the "native" look of a xul:checkbox (see the attached screenshots for Linux and Mac) and I guess that's good enough.

There are also two functional differences:
- the focus box in xul:checkbox is drawn around the label, not the checkbox (this is the other way round in html:input). a xf:input/boolean in XUL will have a focus behavior like in HTML, meaning a focus box around the checkbox and not around the label. This makes it possible to have a focus indicator even if no label is set, which I think is the better behavior.

- in xul:checkbox (on Linux at least) the checkbox slightly changes color (from gray to blueish) on mouseover of the label. This is now not the case for the xf:input/boolean, but I think that difference is too minor to worry about it.

Comment 26

[Philipp Wagner [:imphil]]

Attachment: patch v2

Comment 27

[Philipp Wagner [:imphil]]

Attachment: screenshot XUL on linux

Comment 28

[Philipp Wagner [:imphil]]

Attachment: screenshot XUL on Windows 7

Comment 29

[Philipp Wagner [:imphil]]

Attachment: screenshot XUL on linux

Comment 30

[Philipp Wagner [:imphil]]

Attachment: screenshot XUL on Windows 7

Comment 31

[alexander :surkov (:asurkov)]

I would prefer to not share event handlers for XUL and HTML bindings (command for XUL, click for HTML - btw, is space press proceed by click event handler?)

Comment 32

[Philipp Wagner [:imphil]]

The space key is processed correctly in XUL and HTML bindings. 

I'm not sure I completely understand the first part of your question. The command handler is not used any more, as the XUL binding uses a html:input, too (which responds to click). That makes the event handlers equal for XUL and HTML. Or did you mean something else?

Comment 33

[alexander :surkov (:asurkov)]

Comment on attachment 495233 [details] [diff] [review]
patch v2


>+  <binding id="xformswidget-input-boolean-label-after"
>+           extends="chrome://xforms/content/input-xul.xml#xformswidget-input-boolean">
>     <content>
>-      <children includes="label"/>
>-      <xul:checkbox anonid="control" class="xf-value"
>-                    xbl:inherits="tabindex"/>
>+	    <html:input anonid="control" type="checkbox" class="xf-value"
>+	                xbl:inherits="tabindex" />

please make indent correct (use spaces)

> html|*:root label {
>   -moz-binding: url('chrome://xforms/content/xforms-xhtml.xml#xformswidget-label');
>+  cursor:default;

add space between cursor: and default

Comment 34

[alexander :surkov (:asurkov)]

(In reply to comment #32)
> The space key is processed correctly in XUL and HTML bindings. 
> 
> I'm not sure I completely understand the first part of your question. The
> command handler is not used any more, as the XUL binding uses a html:input, too
> (which responds to click). That makes the event handlers equal for XUL and
> HTML. Or did you mean something else?

I misread your patch. I think taken approach is fine.

Comment 35

[Philipp Wagner [:imphil]]

Attachment: v2.1

fixed Alex's nits and removed a wrong comment in input.xml.

Comment 36

[aaronr]

Comment on attachment 495789 [details] [diff] [review]
v2.1

The patch looks fine to me.

Just a reminder to do 3-5 so that this doesn't catch people off guard.

Comment 37

[Philipp Wagner [:imphil]]

http://hg.mozilla.org/xforms/rev/e9c5d0f4d982

Added documentation to
https://developer.mozilla.org/en/XForms/User_Interface_Elements/Input
https://developer.mozilla.org/en/XForms/Mozilla_XForms_Specials

Opened bug 617461 to support other input elements.

Sent notice to the newsgroup: http://groups.google.com/group/mozilla.dev.tech.xforms/msg/24c5008e4600bd6e