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=""/> ??
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.