Closed Bug 308455 Opened 15 years ago Closed 15 years ago

Move labels

Categories

(Core Graveyard :: XForms, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: peter.nunn, Assigned: peter.nunn)

Details

(Keywords: fixed1.8)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050914 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050914 Firefox/1.6a1

Most xforms processors have labels before the content and the alerts/help/hint
after the content.
The default behavior is to place all decorations before the content of the control.

Reproducible: Always
Patch moves controls to after the xforms content but leaves labels before the
content
Attachment #196026 - Flags: review?(smaug)
(In reply to comment #1)
> Created an attachment (id=196026) [edit]
> Fix to move labels before content and all other xforms after
> 
> Patch moves controls to after the xforms content but leaves labels before the
> content

Please, don't use tabs, but spaces. And I didn't check whether you're using
\r\n line endings. It must be \n.


Comment on attachment 196026 [details] [diff] [review]
Fix to move labels before content and all other xforms after

Ok, there were no \r\ns.
But please replace tabs with spaces. r+
Attachment #196026 - Flags: review?(smaug) → review+
Comment on attachment 196026 [details] [diff] [review]
Fix to move labels before content and all other xforms after


>   <!-- LABEL: <DEFAULT> -->
>   <binding id="xformswidget-label"
>            extends="chrome://xforms/content/xforms.xml#xformswidget-base">
>     <content>
>       <html:span anonid="content"></html:span>
>       <html:span anonid="anoncontent">
>-      <children/>
>+				<children/>
>       </html:span>


And what is this change? Remove it.

>     <content>
>-      <children/>
>+			<children includes="label" />

Remove the space before \>

>                   onkeypress="if (event.keyCode == event.DOM_VK_RETURN) this.parentNode.dispatchDOMActivate();"
>                   xbl:inherits="accesskey"/>
>+      <children />

Remove the space before \>


>   <binding id="xformswidget-textarea"
>            extends="chrome://xforms/content/xforms.xml#xformswidget-base">
>     <content>
>-      <children/>
>+			<children includes="label" />

Remove the space before \>
Attachment #196026 - Attachment is obsolete: true
Attachment #196071 - Flags: review?(smaug)
Comment on attachment 196071 [details] [diff] [review]
Patch to move labels before content

Aaron, what do you think about this?
Attachment #196071 - Flags: review?(smaug)
Attachment #196071 - Flags: review?(aaronr)
Attachment #196071 - Flags: review+
Comment on attachment 196071 [details] [diff] [review]
Patch to move labels before content

or doron?
Attachment #196071 - Flags: review?(aaronr) → review?(doronr)
Attachment #196071 - Flags: review?(doronr) → review+
Checked in to trunk
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: xf-to-branch
Assignee: aaronr → peter.nunn
Status: ASSIGNED → NEW
Should 'output' element have the same behaviour?
(In reply to comment #9)
> Should 'output' element have the same behaviour?

Hmmm, yes I guess it should. I do not know whether we just missed it, or
somebody had a reason for not including it? (I just forgot about it)
Attachment #197412 - Flags: review?(smaug)
Attachment #197412 - Flags: superreview-
Attachment #197412 - Flags: review?(smaug)
Attachment #197412 - Flags: review?(doronr)
Attachment #197412 - Flags: review+
Comment on attachment 197412 [details] [diff] [review]
Move label for output too

oops, I don't know how I managed to set the sr flag
Attachment #197412 - Flags: superreview-
Attachment #197412 - Flags: review?(doronr) → review+
It seems to me label for checkbox is right behind label. Should <xf:input
type="xsd:boolean" have the same behaviour or not?
(In reply to comment #11)
> Created an attachment (id=197412) [edit]
> Move label for output too

Checked in to trunk
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #13)
> It seems to me label for checkbox is right behind label. Should <xf:input
> type="xsd:boolean" have the same behaviour or not?

I'm no big UI wiz. I just assume that XForms labels appear before the control.
So I do not know...
(In reply to comment #15)
> (In reply to comment #13)
> > It seems to me label for checkbox is right behind label. Should <xf:input
> > type="xsd:boolean" have the same behaviour or not?
> 
> I'm no big UI wiz. I just assume that XForms labels appear before the control.
> So I do not know...

Looks like we are being consistent with the other processors, too.  An
individual boolean input will have the label before the checkbox, just like the
label is before a regular input.  However, if you have a select with
appearance='full', then the labels will be after the checkboxes in the group.
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #13)
> > > It seems to me label for checkbox is right behind label. Should <xf:input
> > > type="xsd:boolean" have the same behaviour or not?
> > 
> > I'm no big UI wiz. I just assume that XForms labels appear before the control.
> > So I do not know...
> 
> Looks like we are being consistent with the other processors, too.  An
> individual boolean input will have the label before the checkbox, just like the
> label is before a regular input.  However, if you have a select with
> appearance='full', then the labels will be after the checkboxes in the group.

Ok. It's just a question. I looked at xul:checkbox and I thought it would be good.

(In reply to comment #14)
> (In reply to comment #11)
> > Created an attachment (id=197412) [edit] [edit]
> > Move label for output too
> 
> Checked in to trunk

I have a question. Since patches were checked when bug will be fixed and when
patched will be included into trunk? From what does it depended on?
> (In reply to comment #14)
> > (In reply to comment #11)
> > > Created an attachment (id=197412) [edit] [edit] [edit]
> > > Move label for output too
> > 
> > Checked in to trunk
> 
> I have a question. Since patches were checked when bug will be fixed and when
> patched will be included into trunk? From what does it depended on?

To "branch" I guess you mean. We do not have a good procedure for that for
now... we'll probably update branch in batches, or maybe we could just build an
XPI for branch manually occasionally.
checked into branch 20051004
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
Keywords: fixed1.8
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.