How to decouple submit button's value attrib from displayed text?

[kj]

Is there a simple way to decouple the value attribute of a submit
button from the text that actually gets displayed on it? In
principle, what I'm looking for is something like

<input type="submit"
name="submitted_via"
value="some string meaningless to the user"
label="Submit Request" />

such that the browser would use the content of the imaginary
attribute "label" (and not that of the attribute "value") to
determine the text that the user will see on the submit button.

I know how to achieve what I need to do with JavaScript, but this
seems like a common enough situation that there may already be a
"built-in/standard" way to do it.

TIA!

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

[Michael Fesser]

..oO(kj)

>Is there a simple way to decouple the value attribute of a submit
button from the text that actually gets displayed on it?
[...]

I know how to achieve what I need to do with JavaScript, but this
seems like a common enough situation that there may already be a
"built-in/standard" way to do it.

Common enough? That's the first time I read about it being an issue.
Why would you want that?

Micha

[Harlan Messinger]

kj wrote:

Is there a simple way to decouple the value attribute of a submit
button from the text that actually gets displayed on it? In
principle, what I'm looking for is something like

<input type="submit"
name="submitted_via"
value="some string meaningless to the user"
label="Submit Request" />

It would have been a nice feature, but it's not as though it really
exists but is being kept a secret from all but a few. No, the VALUE
attribute is where the label comes from.

[Sherm Pendley]

Harlan Messinger <hm*******************@comcast.netwrites:

kj wrote:

>Is there a simple way to decouple the value attribute of a submit
button from the text that actually gets displayed on it? In
principle, what I'm looking for is something like

<input type="submit"
name="submitted_via"
value="some string meaningless to the user"
label="Submit Request" />

It would have been a nice feature, but it's not as though it really
exists but is being kept a secret from all but a few. No, the VALUE
attribute is where the label comes from.

How well-supported are button elements? Shouldn't something like this
be suitable?

<button name="submitted_via" value="some string">Submit Request</button>

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Jukka K. Korpela]

Scripsit kj:

Is there a simple way to decouple the value attribute of a submit
button from the text that actually gets displayed on it?

No. So please start from the original problem, instead of this assumed
solution, which is probably a dead end - even though the original problem
may have a solution. Besides, reconsider the choice of group. This doesn't
seem to be a stylesheet question at all.

<input type="submit"
name="submitted_via"
value="some string meaningless to the user"
label="Submit Request" />

such that the browser would use the content of the imaginary
attribute "label" (and not that of the attribute "value") to
determine the text that the user will see on the submit button.

There are unreliable ways to do something like that, by using the button
element:

<button type="submit" name="submitted_via"
value="some string meaningless to the user">
Submit Request
</button>

The main practical problem with that is that IE does not support it, not
even in IE 7.

I know how to achieve what I need to do with JavaScript,

Do you really need to get different data depending on whether the user's
browser has scripting enabled or not?

Your form handler should just _use_ what it gets. The name="..." attribute
value can internally, in the server-side script, be mapped to whatever you
want.

Your main problem might be related to knowing which button was used to
submit the form. The short answer is that there is really no reliable way to
do that, so it's better to design things differently.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Michael Winter]

Sherm Pendley wrote:

[snip]

How well-supported are button elements?

Well, in most browsers. Not at all, effectively, in MSIE. The problems
that I'm aware of are described in a post I sent to c.l.javascript last
month.

Subject: Re: Question from newbie
Date: Mon, 06 Nov 2006 18:59:07 GMT
Message-ID: %B*******************@text.news.blueyonder.co.uk

<http://groups.google.co.uk/group/comp.lang.javascript/msg/f84a1dc2feddc40a>

Shouldn't something like this be suitable?

<button name="submitted_via" value="some string">Submit Request</button>

Unlikely. :-(

Mike

[kj]

In <tH*****************@reader1.news.saunalahti.fi"Ju kka K. Korpela" <jk******@cs.tut.fiwrites:

>Your form handler should just _use_ what it gets. The name="..." attribute
value can internally, in the server-side script, be mapped to whatever you
want.

My question clearly sought ways around this obvious but deficient
solution. Deficient because it requires the server-side code to
be aware of functionally irrelevant GUI details, i.e. the string
that the GUI designer chooses for the label on the button. If the
designer changes his/her mind (which happens all the time), the
server-side programmer must change the corresponding code. A much
better solution is to fix this value once and for all and make it
independent of the GUI representation.

Judging from the responses I am amazed, after all these years of
hearing about the importance of indirection, that the general
consensus is that such a feature is unimportant. It seems to me
*essential*, if one wants to decouple the GUI from the guts of the
program.

I hope that I'm missing something...

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

[Jukka K. Korpela]

Scripsit kj:

>Your form handler should just _use_ what it gets. The name="..."
attribute value can internally, in the server-side script, be mapped
to whatever you want.

My question clearly sought ways around this obvious but deficient
solution.

Your question is still off-topic and wrong.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Harlan Messinger]

kj wrote:

In <tH*****************@reader1.news.saunalahti.fi"Ju kka K. Korpela" <jk******@cs.tut.fiwrites:

>Your form handler should just _use_ what it gets. The name="..." attribute
value can internally, in the server-side script, be mapped to whatever you
want.

My question clearly sought ways around this obvious but deficient
solution. Deficient because it requires the server-side code to
be aware of functionally irrelevant GUI details, i.e. the string
that the GUI designer chooses for the label on the button. If the
designer changes his/her mind (which happens all the time), the
server-side programmer must change the corresponding code. A much
better solution is to fix this value once and for all and make it
independent of the GUI representation.

How about this work-around?

<input type="submit" name="button1" value="Yes">
<input type="submit" name="button2" value="No">
<input type="submit" name="button3" value="Maybe">
<input type="submit" name="button4" value="Don't care">

[On the server, in pseudo-code]
var theValue = none;
for each possible value V do
{
if EXISTS(REQUEST("button" + V))
{
theValue = V;
break;
}
}

[Or, instead]
var theValue = none;
for each name(N)/value pair submitted
{
if N starts with "button"
{
theValue = the part of N that follows "button";
break;
}
}

>
Judging from the responses I am amazed, after all these years of
hearing about the importance of indirection, that the general
consensus is that such a feature is unimportant. It seems to me
*essential*, if one wants to decouple the GUI from the guts of the
program.

I hope that I'm missing something...

I don't think it's unimportant. I thought all along that it showed a
remarkable lack of forethought. The BUTTON tag was meant to fix that
problem, but as you've been told, Microsoft never bothered to support
it. I wondering if you're interpreting the sentiment "there isn't
anything any of us developers can do about it, so let's move on" as a
sense that it isn't important.