Closed Bug 70746 Opened 24 years ago Closed 24 years ago

[XUL Syntax] Replace value="..." and .value with label="..." and .label

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: hyatt, Assigned: bugzilla)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [XUL1.0]) 

All uses of the value attribute and the value property should be replaced (when
appropriate) with a label attribute and a label property.

The notable exception is <textfield> for which .value makes sense.  All other
widgets (menus, buttons, checkboxes, radios, etc.) should be converted to use label.

In addition <titledbox> should be converted to use label instead of title.

Tabs, trees, and lists should also use label.

When this bug is fixed, the only uses of .value and the value attribute should
be on textfields.
Status: NEW → ASSIGNED
Whiteboard: [XUL1.0]
Depends on: 70753
No longer depends on: 70753
Blocks: 70753
mass-targetting to mozilla1.0, adding helpwanted keyword
Keywords: helpwanted
Target Milestone: --- → mozilla1.0
I guess I'll do this, since I'm everybody's bitch...
Some notes after chatting with blake:

<text> and <html> should continue to use value.  When they are converted to 
<block> and <label>, they will continue to use value.

<menulist> will be converted to use label instead of value, and at the same
time, menulist.data will become menulist.value.

Also, on the progressmeter, value should stay value, and progresstext should 
become label.

What about editable menulists?  Using label doesn't seem to make much sense, 
since textfields use value (and editable menulists contain a textfield)...
Hmmm.  Editable menulists are really a very different kind of widget that maybe
should be split into a whole separate tag name.  IMO .value on an editable
menulist is still just setting some non-visible data on the menulist.

I'll talk this over with ben and see what he thinks.

Taking this...

Ben is reviewing all 20,000 lines of this the day after .8.1 branches.  Per our 
prior (one-sided) agreement, I'm completely ignoring and backing out anything 
he checks in before this.
Assignee: hyatt → blakeross
Status: ASSIGNED → NEW
The fix for this is up at http://www.mozillazine.org/jason/diffs/blake-
label.txt. It was too big to attach.
URL: http://www.mozillazine.org/jason/diff...
r=hewitt, a=ben. kerz and prass finished the necessary commercial changes, and 
this has been tested on windows and linux.  Pending mac testing, this is ready 
to go. Any help would be appreciated.
Status: NEW → ASSIGNED
sr=hyatt, although no checkin is allowed until the entire commercial tree is
also ready to go and has also been tested.

This needs a carpool.  We should arrange it with the build guys.

kerz and prass only did the aim changes. I need another sucker--er, person to 
do the remaining changes.
By the way, having sat on these changes for over two weeks (and enduring 
multiple merge conflicts), I'm not particularly interested in waiting until 
someone finds the time to fix the other commercial cases.  These changes are 
going to break Alphanumerica and MozDev products also, as well as potentially 
any other xul-based app out there, and while I'm certainly willing to help, 
they're not waiting until every commercial vendor's branch is ready (such is 
pre-1.0 development).
at least for buttons, isn't this just making an inconsistency between XUL and
HTML? (and therefore acception levels more difficult) HTML uses value for it's
label:
input type=button value="this is my label" name="user does not see this"
XForms (the new version of HTML forms) use <caption>.  These changes actually
put us more in line with the next generation of HTML forms.

Also, the HTML4 form controls have some of the worst syntax imaginable. :)

Blake, I feel your pain, but I work for Netscape, and therefore can't approve a
patch that will bust up the commercial tree.

Are there any volunteers to convert the rest of commercial (outside of AIM)?  I
would do it myself, but this kind of bug just kills my hands.

Hyatt: acting as module owner, you certainly _can_ permit a change that will
break a closed source base, especially after the developer (Blake) has gone to
such reasonable lengths to get someone to fix said closed source base.  There
are lots of other source trees, as Blake points out, that will break because of
this (in the short term), and he's offered to help with the ones whose authors
are not actively preventing them from providing such assistance (as is
Netscape/AOL, in this case).  We held off until 0.8.1 to minimize the pain of
this checkin, and the time has come to bear what pain remains.

If you don't feel that your employer will let you fulfill your
Mozilla-module-owner responsibilities, please let us know, because that's the
kind of problem that we have to solve quickly.

Module owners whose employers pay them to keep commercial add-ons working along
with their Mozilla modules have to wear two hats: one for their employer, one
for Mozilla.  If there's a conflict, Mozilla wins, or we need a new module owner
(at least _pro tem_).  Life's rough.  Let's get these changes landed.

It sounds like all but Mac builds have been tested in any case.  True?

/be
Blake is going to need another Mac build buddy if he wants to get this landed 
soon as I'm down for at least 24 hours (had followup eye surgery today)

Sorry, I didn't mean to start an argument over this.

scc was testing this on mac earlier, it looks from IRC that a couple patches 
failed to apply (I was away), I'll try to help with that.

My only concern is that I can't find someone to do the other changes. I've 
already petitioned the usual suspects, with no luck.  Maybe Ben can do it 
(since he keeps laughing at me about this bug? ;)


In response to Joe:

See what hyatt said :).  HTML has some terrible syntax, and emulating it would 
be a big mistake.  Since we make no real effort to follow it anywhere else, I 
don't see the value inconsistency as a problem (if anything, I think HTML is 
wrong in that regard).
Ok, brendan and shaver have spoken.  Blake, you have a go, although you should
coordinate with kerz at least so that he can land the AIM changes at the same time.


Fix checked in.  Prass helped do the rest of comm (besides AIM), so in the end, 
nothing to worry about.  Thanks for the help all.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I'm not sure how this turned out, but I've just started using editable menulists
and it seems to me that ".value" should be used. It gets/sets the "value" for
both the embedded textfield *and* the menulist, correct?
I'm not what ".label" would mean!

I think .label is still correct.  .value represents values you wish to associate
with items that are picked from the list.

"When this bug is fixed, the only uses of .value and the value attribute should
be on textfields."

After <textfield> is replaced with <textbox> then there's no "value" left, right?


value is now used for other things. so i think that statement would ened a lot 
of rehab.
And after <title> is replaced by <label> would we get <label label=""/> or, and
that makes more sense to me, <label value=""/> ??
H-J: see hyatt's comments in http://bugzilla.mozilla.org/show_bug.cgi?id=70745
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.