opera 11 and changing input value
Andrew Poulos
window.onload = function() {
document.getElementsByTagName("input")[0].value = "me";
};
and the relevant HTML is simply
<input type="submit" name="submit" value="">
There is only *one* INPUT in the page. Alas Opera 11 only shows the
button with no label (whereas IE, Chrome, Firefox, Safari... updates the
button label).
Is this a bug with Opera or is there a better/correct way to dynamically
change a button's label?
Andrew Poulos
Jukka K. Korpela
> I have some js that looks like
>
> window.onload = function() {
> document.getElementsByTagName("input")[0].value = "me";
> };
>
> and the relevant HTML is simply
>
> <input type="submit" name="submit" value="">
>
> There is only *one* INPUT in the page. Alas Opera 11 only shows the
> button with no label
Works for _me_ (no pun intended), when using the code above as such, on
Opera 11.01 (build 1190), on Windows Vista SP 2.
> Is this a bug with Opera
Maybe in some specific build, or something. Please post a URL - there might
be something on your test page that causes the difference.
> or is there a better/correct way to
> dynamically change a button's label?
You could alternatively use
document.getElementsByTagName("input")[0].setAttribute("value","me");
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Web Interface Tricks
and it did.
One workaround seems to be setting the input's "type" property as
well, even if you set it to its current vlaue, "submit". This must
force a redraw or something.
You can see an example here:
http://webinterfacetricks.com/opera_submit_bug/
I also found that changing the style doesn't force the value-change,
even though the style does change.
Hope this helps.
Andrew Poulos
> It seems to be a bug in Opera. The bug didn't happen, then I upgraded
> and it did.
Annoyingly, calling
window.alert(document.getElementsByTagName("input")[0].value);
returns the updated value even though the button doesn't reflect the value.
> One workaround seems to be setting the input's "type" property as
> well, even if you set it to its current value, "submit". This must
> force a redraw or something.
Setting the type seems to force the label to "correctly" update. Thanks.
Andrew Poulos
Thomas 'PointedEars' Lahn
> Andrew Poulos wrote:
>> I have some js that looks like
>>
>> window.onload = function() {
>> document.getElementsByTagName("input")[0].value = "me";
>> };
Avoid the proprietary `onload' property, use the `onload' attribute of the
`body' element instead.
>> and the relevant HTML is simply
>>
>> <input type="submit" name="submit" value="">
Never ever name a submit button "submit". You are overriding/overwriting
the built-in submit() method.
>> There is only *one* INPUT in the page. Alas Opera 11 only shows the
>> button with no label
>
> Works for _me_ (no pun intended), when using the code above as such, on
> Opera 11.01 (build 1190), on Windows Vista SP 2.
>
>> Is this a bug with Opera
>
> Maybe in some specific build, or something. Please post a URL - there
> might be something on your test page that causes the difference.
ACK. The observed behavior would be a bug, since no form is accessed
directly. The bug can be expected, though.
>> or is there a better/correct way to
>> dynamically change a button's label?
The proper term could be "caption". Labels should be diplayed next to
controls.
> You could alternatively use
> document.getElementsByTagName("input")[0].setAttribute("value","me");
That would update the `value' attribute value, but not necessarily the value
of the `value' property that defines the actual caption of the button.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Andrew Poulos
> Jukka K. Korpela wrote:
>
>> Andrew Poulos wrote:
>>> I have some js that looks like
>>>
>>> window.onload = function() {
>>> document.getElementsByTagName("input")[0].value = "me";
>>> };
>
> Avoid the proprietary `onload' property, use the `onload' attribute of the
> `body' element instead.
>
>>> and the relevant HTML is simply
>>>
>>> <input type="submit" name="submit" value="">
>
> Never ever name a submit button "submit". You are overriding/overwriting
> the built-in submit() method.
Dang, I didn't know it mattered.
>>> There is only *one* INPUT in the page. Alas Opera 11 only shows the
>>> button with no label
>>
>> Works for _me_ (no pun intended), when using the code above as such, on
>> Opera 11.01 (build 1190), on Windows Vista SP 2.
>>
>>> Is this a bug with Opera
>>
>> Maybe in some specific build, or something. Please post a URL - there
>> might be something on your test page that causes the difference.
>
> ACK. The observed behavior would be a bug, since no form is accessed
> directly. The bug can be expected, though.
>
>>> or is there a better/correct way to
>>> dynamically change a button's label?
I tested changing the INPUT to a BUTTON
<button type="submit" name="submitme"> </button>
and then calling
document.getElementsByTagName("button")[0].firstChild.nodeValue = "me"
and it seems to work in Opera 11, IE6+...
Andrew Poulos
Jukka K. Korpela
>> Never ever name a submit button "submit". You are
>> overriding/overwriting the built-in submit() method.
>
> Dang, I didn't know it mattered.
What makes you think it does? Don't take trolls too seriously.
>> ACK. The observed behavior would be a bug, since no form is accessed
>> directly. The bug can be expected, though.
Ignore that too. There is no reason to think that this would depend on any
access to any form.
> I tested changing the INPUT to a BUTTON
> <button type="submit" name="submitme"> </button>
> and then calling
> document.getElementsByTagName("button")[0].firstChild.nodeValue =
> "me" and it seems to work in Opera 11, IE6+...
Things can of course be different for different elements, and there can be
an essential difference between an attribute value and element contents.
Instead of .firstChild.nodeValue, you could simply use .innerHTML (it might
not be theoretically ideal, but it works on all browsers worth caring about
these days).
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Thomas 'PointedEars' Lahn
> On 13/04/2011 8:21 PM, Thomas 'PointedEars' Lahn wrote:
>> Jukka K. Korpela wrote:
>>> Andrew Poulos wrote:
>>>> and the relevant HTML is simply
>>>>
>>>> <input type="submit" name="submit" value="">
>>
>> Never ever name a submit button "submit". You are overriding/overwriting
>> the built-in submit() method.
>
> Dang, I didn't know it mattered.
> […]
>>>> or is there a better/correct way to
>>>> dynamically change a button's label?
>
> I tested changing the INPUT to a BUTTON
> <button type="submit" name="submitme"> </button>
> and then calling
> document.getElementsByTagName("button")[0].firstChild.nodeValue = "me"
> and it seems to work in Opera 11, IE6+...
IE 6 does not fully support the BUTTON element; it would send something like
submitme=%26nbsp%3B instead of whatever value the element's `value'
attribute had.
But you have diverted from the actual test case. Did setting the `value'
property work in your Opera version with an input[type="button"] with a
`name' attribute value different from "submit"?
Thomas 'PointedEars' Lahn
> Andrew Poulos wrote:
>> I tested changing the INPUT to a BUTTON
>> <button type="submit" name="submitme"> </button>
>> and then calling
>> document.getElementsByTagName("button")[0].firstChild.nodeValue = "me"
>> and it seems to work in Opera 11, IE6+...
>
> IE 6 does not fully support the BUTTON element; it would send something
> like submitme=%26nbsp%3B instead of whatever value the element's `value'
> attribute had.
Having subsequently doubted whether IE 6 really would be so [censored] as to
ignore the character entity reference (i.e., not send %A0 or better %C2%A0),
I have now tested this in IE 6.0.2800.1106 on Wine and found my assumption
confirmed!
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Andrew Poulos
> Andrew Poulos wrote:
>
>> On 13/04/2011 8:21 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jukka K. Korpela wrote:
>>>> Andrew Poulos wrote:
>>>>> and the relevant HTML is simply
>>>>>
>>>>> <input type="submit" name="submit" value="">
>>>
>>> Never ever name a submit button "submit". You are overriding/overwriting
>>> the built-in submit() method.
>>
>> Dang, I didn't know it mattered.
>> […]
>>>>> or is there a better/correct way to
>>>>> dynamically change a button's label?
>>
>> I tested changing the INPUT to a BUTTON
>> <button type="submit" name="submitme"> </button>
>> and then calling
>> document.getElementsByTagName("button")[0].firstChild.nodeValue = "me"
>> and it seems to work in Opera 11, IE6+...
>
> IE 6 does not fully support the BUTTON element; it would send something like
> submitme=%26nbsp%3B instead of whatever value the element's `value'
> attribute had.
Of course IE doesn't :-(
> But you have diverted from the actual test case. Did setting the `value'
> property work in your Opera version with an input[type="button"] with a
> `name' attribute value different from "submit"?
Changing/deleting 'name' made no difference in Opera 11.
ANdrew Poulos
RobG
> On 13/04/2011 8:21 PM, Thomas 'PointedEars' Lahn wrote:
>
>
>
>
>
>
>
>
>
> > Jukka K. Korpela wrote:
>
> >> Andrew Poulos wrote:
> >>> I have some js that looks like
>
> >>> window.onload = function() {
> >>> document.getElementsByTagName("input")[0].value = "me";
> >>> };
>
> > Avoid the proprietary `onload' property, use the `onload' attribute of the
> > `body' element instead.
>
> >>> and the relevant HTML is simply
>
> >>> <input type="submit" name="submit" value="">
>
> > Never ever name a submit button "submit". You are overriding/overwriting
> > the built-in submit() method.
>
> Dang, I didn't know it mattered.
It only really matters if you want to call the form's submit method.
[...]
> >>> or is there a better/correct way to
> >>> dynamically change a button's label?
>
> I tested changing the INPUT to a BUTTON
> <button type="submit" name="submitme"> </button>
> and then calling
> document.getElementsByTagName("button")[0].firstChild.nodeValue = "me"
> and it seems to work in Opera 11, IE6+...
Careful with IE < 9, it thinks a button's value and text content are
the same thing.
--
Rob
Dr J R Stockton
t.com.au>, Wed, 13 Apr 2011 14:25:11, Andrew Poulos
<ap_...@hotmail.com> posted:
>I have some js that looks like
>
>window.onload = function() {
> document.getElementsByTagName("input")[0].value = "me";
>};
You might, instead of setting .value, set something like
.style.background. If that works, you know that your aiming has worked
correctly. Also, you could try making the function read .value and show
it in an alert.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Andrew Poulos
> In comp.lang.javascript message<dt2dnWt_mYYyuDjQnZ2dnUVZ_uOdnZ2d@westne
> t.com.au>, Wed, 13 Apr 2011 14:25:11, Andrew Poulos
> <ap_...@hotmail.com> posted:
>
>> I have some js that looks like
>>
>> window.onload = function() {
>> document.getElementsByTagName("input")[0].value = "me";
>> };
>
>
> You might, instead of setting .value, set something like
> .style.background. If that works, you know that your aiming has worked
> correctly. Also, you could try making the function read .value and show
> it in an alert.
Opera 11 returns the "correct" value for the INPUT when it read the
value back it just doesn't seem to update the caption.
Anyhow I've given up on it and I'm now using a BUTTON which Opera 11
does seem to be able to dynamically change.
Andrew Poulos
Swifty
<Point...@web.de> wrote:
>IE 6 does not fully support the BUTTON element; it would send something like
>submitme=%26nbsp%3B instead of whatever value the element's `value'
>attribute had.
Is the situation any different with IE7, 8 or 9?
I can probably test IE8, but my IE8 is damaged, and no one can find a
way of repairing it without re-installing my XP system (caused by an
unfortunate sequence of fix applying and system restores)
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Jukka K. Korpela
>> IE 6 does not fully support the BUTTON element; it would send
>> something like submitme=%26nbsp%3B instead of whatever value the
>> element's `value' attribute had.
>
> Is the situation any different with IE7, 8 or 9?
Yes. In IE 8, they fixed the bug but only in "IE8" mode.
"Internet Explorer 8 and later. When the BUTTON element is submitted in a
form, the value depends on the current document compatibility mode. In IE8
mode, the value attribute is submitted. In other document modes and earlier
versions of Internet Explorer, the innerText value is submitted."
http://msdn.microsoft.com/en-us/library/ms535211(v=vs.85).aspx
(Other documents by Microsoft mention the innerHTML value instead.)
For further confusion, my tests suggest that IE 9 works by the specs even in
quirks mode.
I guess this is because they decided that probably very few pages rely on
the previous incorrect behavior. After all, a button element is primarily
supposed to create a button for an action, not to contribute to the form
data (though it may contribute to it).
So mentioning that the implementation of button is broken on IE 6 was
basically pointless excursion/trolling/besserwisserism/whatever, because
there was no indication of any attempt at making the use of its contribution
to the form data in this case.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Thomas 'PointedEars' Lahn
> So mentioning that the implementation of button is broken on IE 6 was
> basically pointless excursion/trolling/besserwisserism/whatever, because
> there was no indication of any attempt at making the use of its
> contribution to the form data in this case.
It was a well-meant remark. Here's another one: By calling all people
a troll who disagree with you, you are only discrediting yourself.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Dr J R Stockton
t.com.au>, Fri, 15 Apr 2011 09:02:39, Andrew Poulos
<ap_...@hotmail.com> posted:
>Opera 11 returns the "correct" value for the INPUT when it read the
>value back it just doesn't seem to update the caption.
>
>Anyhow I've given up on it and I'm now using a BUTTON which Opera 11
>does seem to be able to dynamically change.
Section <http://www.merlyn.demon.co.uk/js-randm.htm#TRI>, among others,
works as expected in my Opera 11.10, Win XP pro sp3.
<input type=button name=Btn value=1 onClick="Repeats(this)">
function Repeats(Me) { if (+(Me.value^=1)) return
var F = Me.form
// ...
RptLoop.F = F
// ...
setTimeout(RptLoop, 10) }
function RptLoop() { var F = RptLoop.F, Bat, K, D1
// ...
if (!+F.Btn.value) setTimeout(RptLoop, +F.TOt.value) }
Pressing the button calls Repeats which toggles the button legend.
If that action was for "Start", RptLoop is called.
At the end of RptLoop, the button is legend consulted.
Could it be that some browsers update the visible legend immediately
whereas others do not re-draw until nothing else is happening?
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
VK
> I have some js that looks like
>
> window.onload = function() {
> document.getElementsByTagName("input")[0].value = "me";
>
> };
>
> and the relevant HTML is simply
>
> <input type="submit" name="submit" value="">
>
> There is only *one* INPUT in the page. Alas Opera 11 only shows the
> button with no label (whereas IE, Chrome, Firefox, Safari... updates the
> button label).
I cannot reproduce this.
Opera 11.01
Windows 7 Professional
The test page:
<!DOCTYPE html>
<html>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<head>
<title>Test</title>
<script>
window.onload = function() {
document.getElementsByTagName('input')[0].value = 'me';
}
</script>
</head>
<body>
<input type="submit" name="submit" value="">
</body>
</html>
Results: onload the button label is set to "me" as expected.
Andrew Poulos
I just tried this test page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Test</title>
<script type="text/javascript">
window.onload = function() {
document.getElementsByTagName('input')[0].value = 'me';
};
</script>
</head>
<body>
<form action="">
<input type="submit" name="submit" value="">
</form>
</body>
</html>
And with Opera 11.10 on 32 bit Windows Vista SP 2 the button's
label/caption is blank.
Andrew Poulos
Jukka K. Korpela
> window.onload = function() {
> document.getElementsByTagName('input')[0].value = 'me';
> };
[...]
> And with Opera 11.10 on 32 bit Windows Vista SP 2 the button's
> label/caption is blank.
Originally I commented in my reply that in my test, the button had the
specified label, on Opera 11.01 (build 1190), on Windows Vista SP 2. Now it
seems that my Opera has updated herself to 11.10, build 2092, and I can see
the same problem (bug) as you.
So it appears to be a newly introduced bug. As already mentioned in this
discussion, the element's value property gets set, as one can see using
Opera's debugging mode and inspecting the element, as well as just writing
the value out using alert(). So it's just lack of updating the appearance of
the button. And therefore, using setAttribute() doesn't help.
Long time ago I tried to use Opera's bug reporting system and found it
confusing - I didn't even find a database of _known_ bugs...
And I can't figure out any simple workaround, simpler than creating a new
element and replacing the existing element by it:
window.onload = function() {
var button = document.getElementsByTagName("input")[0];
var newButton = document.createElement("input");
newButton.type = button.type;
newButton.name = button.name;
newButton.value = "me";
button.parentNode.replaceChild(newButton,button);
};
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Andrew Poulos
I've now posted the bug to Opera.
Andrew Poulos
Web Interface Tricks
One simple workaround seems to be: reset the input's type property to
what it already was.
eg:
submit_button.type = "submit";
This seems to force a refresh or redraw of the value property. You can
see a basic example of this here:
http://webinterfacetricks.com/opera_submit_bug/
VK
The bug is not exposed under Opera 11.01
The bug is exposed as reported by OP under Opera 11.10
This way it is a newly introduced bug in the latest Opera release.
The suggested workarounds with creating new submit object or by simply
reassigning type property are theoretically reasonable but practically
dangerous. Such workarounds expose IE 6.x - IE 8.x and Opera 9.x bug
when trying to manipulate the button type property in the
straightforward DOM way will lead to "object doesn't support this
property or method" run-time error. While Opera 9.x can be now skept
from considerations, IE 6.x - IE 8.x are still an issue.
Dr J R Stockton
t.com.au>, Sun, 17 Apr 2011 22:47:40, Andrew Poulos
<ap_...@hotmail.com> posted:
>
>I just tried this test page:
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
><html>
><head>
><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
><title>Test</title>
><script type="text/javascript">
>window.onload = function() {
> document.getElementsByTagName('input')[0].value = 'me';
>};
></script>
></head>
><body>
><form action="">
><input type="submit" name="submit" value="">
></form>
></body>
></html>
>
>And with Opera 11.10 on 32 bit Windows Vista SP 2 the button's
>label/caption is blank.
Opera 11.10 Win XP pro sp3, that code, blank.
Add to the button onclick="this.value='OW'" : no OW seen.
Change type to from submit to button, me and OW appear.
The untested work-round may be to change the type of the button before
altering its value. I did that for browsers that would not recognise a
selection in a readonly textarea, as may be recalled.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
David Mark
You best be careful setting the "type" property of an INPUT. IE is
write-once (and some seemingly unrelated operations perform an implied
write to that property). In short, set it once, first and only on
elements you create.
>
> eg:
>
> submit_button.type = "submit";
Never do that.
>
> This seems to force a refresh or redraw of the value property.
You mean a repaint of the button.
> You can
> see a basic example of this here:http://webinterfacetricks.com/opera_submit_bug/
Please take that down. Thanks!
Jukka K. Korpela
>>> --
>>> Yucca,http://www.cs.tut.fi/~jkorpela/
Quoting a message that has quoted a sig, including that quotation without an
intent to comment on such usage - always a useful alert. The amount of
quoted text tends to be inversely proportional to the amount of text you
have understood.
>> One simple workaround seems to be: reset the input's type property to
>> what it already was.
>
> You best be careful setting the "type" property of an INPUT. IE is
> write-once (and some seemingly unrelated operations perform an implied
> write to that property). In short, set it once, first and only on
> elements you create.
Can you cite a document of such (mis)behavior, or describe, with a URL, how
it can be reproduced (on which versions of IE?)? If you can't, you should
refrain from making such comments until you can back them up with facts or
fact-like products.
>> This seems to force a refresh or redraw of the value property.
>
> You mean a repaint of the button.
Why do you care what words are used when everyone knows what we are talking
about?
>> You can
>> see a basic example of this
>> here:http://webinterfacetricks.com/opera_submit_bug/
>
> Please take that down. Thanks!
What?
--
Yucca, http://www.cs.tut.fi/~jkorpela/
David Mark
> David Mark wrote:
> >>> --
> >>> Yucca,http://www.cs.tut.fi/~jkorpela/
>
> Quoting a message that has quoted a sig, including that quotation without an
> intent to comment on such usage - always a useful alert. The amount of
> quoted text tends to be inversely proportional to the amount of text you
> have understood.
LOL. You must have me confused with somebody else. I just don't care
about your sig.
>
> >> One simple workaround seems to be: reset the input's type property to
> >> what it already was.
>
> > You best be careful setting the "type" property of an INPUT. IE is
> > write-once (and some seemingly unrelated operations perform an implied
> > write to that property). In short, set it once, first and only on
> > elements you create.
>
> Can you cite a document of such (mis)behavior, or describe, with a URL, how
> it can be reproduced (on which versions of IE?)?
Yes. As can almost anyone who reads this group (at least those who
pay attention). Hint: MSDN.
As for versions, IE 5,6,7 and newer in compatibility mode (if not
standards mode). In other words, most browsers in use today. Just
don't do it; live happily ever after.
> If you can't, you should
> refrain from making such comments until you can back them up with facts or
> fact-like products.
Considering that we have been over this a hundred times over the
years, your warning is ludicrous. Furthermore, the behavior is easily
demonstrated.
>
> >> This seems to force a refresh or redraw of the value property.
>
> > You mean a repaint of the button.
>
> Why do you care what words are used when everyone knows what we are talking
> about?
What "we" are you speaking for?
>
> >> You can
> >> see a basic example of this
> >> here:http://webinterfacetricks.com/opera_submit_bug/
>
> > Please take that down. Thanks!
>
> What?
>
I said: Please take that down. Thanks!
HTH
Jukka K. Korpela
> You must have me confused with somebody else. I just don't care
> about your sig.
No I didn't. You were not just clueless enough to quote extensively,
including a quoted sig, but you also keep sending cluelessness signals by
not admitting that.
>> Can you cite a document of such (mis)behavior, or describe, with a
>> URL, how it can be reproduced (on which versions of IE?)?
>
> Yes. As can almost anyone who reads this group (at least those who
> pay attention). Hint: MSDN.
That was a clear enough "No" answer. If it were that simple, you would have
posted a URL instead of babbling.
> Furthermore, the behavior is easily demonstrated.
Apparently it is not easy enough to you.
The issue was about setting an <input type="button"> element's type property
value to "button". Please confirm that you have no evidence of any risks
with that, by continuing to post absurd warnings and insults. Thank you in
advance.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
David Mark
> David Mark wrote:
> > You must have me confused with somebody else. I just don't care
> > about your sig.
>
> No I didn't. You were not just clueless enough to quote extensively,
> including a quoted sig, but you also keep sending cluelessness signals by
> not admitting that.
You've *definitely* got the wrong guy.
>
> >> Can you cite a document of such (mis)behavior, or describe, with a
> >> URL, how it can be reproduced (on which versions of IE?)?
>
> > Yes. As can almost anyone who reads this group (at least those who
> > pay attention). Hint: MSDN.
>
> That was a clear enough "No" answer. If it were that simple, you would have
> posted a URL instead of babbling.
No, you are apparently too clueless to look up the type property/
attribute in the MS documentation. The confirmation you seek is
definitely in there. You shouldn't need me to point you to the exact
page/paragraph in the manual. And if so, you are out of luck.
And, as mentioned, as this issue has been around since the late 90's
(and discussed here on numerous occasions), you are simply spewing
noise here.
>
> > Furthermore, the behavior is easily demonstrated.
>
> Apparently it is not easy enough to you.
LOL. I took care of that in My Library years ago. So yeah, I can
demonstrate it. Now you try. ;)
>
> The issue was about setting an <input type="button"> element's type property
> value to "button".
Yes, and setting that property can definitely cause an exception in
IE. See the documentation for that property in MSDN.
> Please confirm that you have no evidence of any risks
> with that, by continuing to post absurd warnings and insults. Thank you in
> advance.
Please RTFM. And thank you! :)
Eric Bednarz
> "Jukka K. Korpela" wrote:
>> No I didn't. You were not just clueless enough to quote extensively,
>> including a quoted sig, but you also keep sending cluelessness signals by
>> not admitting that.
>
> You've *definitely* got the wrong guy.
(this would probably be the right spot to note that I took the liberty
of snipping the email address from the second attribution line because
it was already fubar by David’s Usenet molester of choice)
>> The issue was about setting an <input type="button"> element's type property
>> value to "button".
>
> Yes, and setting that property can definitely cause an exception in
> IE. See the documentation for that property in MSDN.
Assuming that the write-once paradign is unconditionally correct, where
exactly on MSDN does it explain that assigning the current value to the
property again does not result in writing to it?
David Mark
> David Mark <dmark.cins...@gmail.com> writes:
> > "Jukka K. Korpela" wrote:
> >> No I didn't. You were not just clueless enough to quote extensively,
> >> including a quoted sig, but you also keep sending cluelessness signals by
> >> not admitting that.
>
> > You've *definitely* got the wrong guy.
>
> (this would probably be the right spot to note that I took the liberty
> of snipping the email address from the second attribution line because
> it was already fubar by David’s Usenet molester of choice)
Thanks!
>
> >> The issue was about setting an <input type="button"> element's type property
> >> value to "button".
>
> > Yes, and setting that property can definitely cause an exception in
> > IE. See the documentation for that property in MSDN.
>
> Assuming that the write-once paradign is unconditionally correct, where
> exactly on MSDN does it explain that assigning the current value to the
> property again does not result in writing to it?
It is unconditionally correct (in IE to date) and documented. And, it
says (as I alluded to previously) that you can only write to this
property for elements created by createElement and before they are
appended to a document. That precludes using this property to trigger
a repaint (which was the original aim). If you are saying that
"writing" the same property value on an element that exists in the
document results in a no-op, rather than an exception, that sounds
reasonable, but isn't of much interest in context.
The primary point is that if you have to pick one property to use for
such bizarre hacks, don't make it the "type" property. It will either
be destructive or completely ineffectual.
HTH
Andrew Poulos
> The issue was about setting an <input type="button"> element's type
> property value to "button". Please confirm that you have no evidence of
> any risks with that, by continuing to post absurd warnings and insults.
> Thank you in advance.
For the recorded I heeded the warning, of a number of people, about
dynamically changing an INPUT's type and instead changed the HTML I was
using so that I use a BUTTON in place of an INPUT. In my testing "all"
browsers allowed the BUTTON's caption/label to be dynamically changed.
Andrew Poulos
Web Interface Tricks
While setting it to something else ("text", for example), causes an
error in ie, setting it to its current value doesn't.
You can see an example of the difference here:
http://webinterfacetricks.com/input_type_changes/
(Note this was not tested on ie6 or earlier)
Jukka K. Korpela
>> Assuming that the write-once paradign is unconditionally correct,
>> where exactly on MSDN does it explain that assigning the current
>> value to the property again does not result in writing to it?
>
> It is unconditionally correct (in IE to date) and documented. And, it
> says (as I alluded to previously) that you can only write to this
> property for elements created by createElement and before they are
> appended to a document. That precludes using this property to trigger
> a repaint (which was the original aim). If you are saying that
> "writing" the same property value on an element that exists in the
> document results in a no-op, rather than an exception, that sounds
> reasonable, but isn't of much interest in context.
>
> The primary point is that if you have to pick one property to use for
> such bizarre hacks, don't make it the "type" property. It will either
> be destructive or completely ineffectual.
That was a longish and complex answer to a simple question, apparently
trying to avoid the simple answer "Nowhere".
The original aim had nothing to do with IE. It was about a workaround to a
bug in some versions of Opera. So all that IE needs to do with this
workaround is nothing. IE behavior would be relevant only if it suffered
from the same bug or if the workaround caused some bad effects, like an
error message.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Andrew Poulos
> David Mark wrote:
>
>>> Assuming that the write-once paradign is unconditionally correct,
>>> where exactly on MSDN does it explain that assigning the current
>>> value to the property again does not result in writing to it?
>>
>> It is unconditionally correct (in IE to date) and documented. And, it
>> says (as I alluded to previously) that you can only write to this
>> property for elements created by createElement and before they are
>> appended to a document. That precludes using this property to trigger
>> a repaint (which was the original aim). If you are saying that
>> "writing" the same property value on an element that exists in the
>> document results in a no-op, rather than an exception, that sounds
>> reasonable, but isn't of much interest in context.
>>
>> The primary point is that if you have to pick one property to use for
>> such bizarre hacks, don't make it the "type" property. It will either
>> be destructive or completely ineffectual.
>
> That was a longish and complex answer to a simple question, apparently
> trying to avoid the simple answer "Nowhere".
Have you searched MSDN? I found more than one reference that said,
basically, one can't dynamically change the type of an input element in IE.
> The original aim had nothing to do with IE. It was about a workaround to
> a bug in some versions of Opera. So all that IE needs to do with this
> workaround is nothing. IE behavior would be relevant only if it suffered
> from the same bug or if the workaround caused some bad effects, like an
> error message.
You're mistaken to think I needed a workaround for a bug in Opera that
had the potential to break IE.
Andrew Poulos
Jukka K. Korpela
> I found more than one reference that said,
> basically, one can't dynamically change the type of an input element
> in IE.
So what? The workaround being discussed was not about changing the type. It
was about assigning its current value to it, to work around a bug in Opera.
> You're mistaken to think I needed a workaround for a bug in Opera that
> had the potential to break IE.
No evidence has been given about any potential to break IE.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Andrew Poulos
Andrew Poulos
David Mark
Which would seem to contradict the (typically vague) MS
documentation. On finding such undocumented "features", you would do
well to ignore them as you can't count on them to work the same in the
future.
>
> You can see an example of the difference here:http://webinterfacetricks.com/input_type_changes/
>
> (Note this was not tested on ie6 or earlier)
Hmmm. You are likely "safe" there, but I wouldn't count on it.
David Mark
> David Mark wrote:
> >> Assuming that the write-once paradign is unconditionally correct,
> >> where exactly on MSDN does it explain that assigning the current
> >> value to the property again does not result in writing to it?
>
> > It is unconditionally correct (in IE to date) and documented. And, it
> > says (as I alluded to previously) that you can only write to this
> > property for elements created by createElement and before they are
> > appended to a document. That precludes using this property to trigger
> > a repaint (which was the original aim). If you are saying that
> > "writing" the same property value on an element that exists in the
> > document results in a no-op, rather than an exception, that sounds
> > reasonable, but isn't of much interest in context.
>
> > The primary point is that if you have to pick one property to use for
> > such bizarre hacks, don't make it the "type" property. It will either
> > be destructive or completely ineffectual.
>
> That was a longish and complex answer to a simple question, apparently
> trying to avoid the simple answer "Nowhere".
No, you have managed to string out this thread with one of your
pedantic guess matches. Thing is, I have no interest in trying to
figure out your bluster.
You'd do well to heed my warning(s) in this thread. What a ridiculous
idea to set the "type" property of an INPUT to "refresh" the control.
>
> The original aim had nothing to do with IE. It was about a workaround to a
> bug in some versions of Opera.
And I knew that was coming. You are very new here and don't yet
understand that you don't code per browser.
> So all that IE needs to do with this
> workaround is nothing.
See previous sentence.
> IE behavior would be relevant only if it suffered
> from the same bug or if the workaround caused some bad effects, like an
> error message.
You need to start over and come up with a solution that actually makes
sense and does not rely on your incomplete observations.
David Mark
> Andrew Poulos wrote:
> > I found more than one reference that said,
> > basically, one can't dynamically change the type of an input element
> > in IE.
>
> So what? The workaround being discussed was not about changing the type. It
> was about assigning its current value to it, to work around a bug in Opera.
And you are tap-dancing a little close to a well-known land mine,
aren't you? And like most pedantic blowhards, you don't appreciate
being handed a map.
Hint: try a different property (if you must).
>
> > You're mistaken to think I needed a workaround for a bug in Opera that
> > had the potential to break IE.
>
> No evidence has been given about any potential to break IE.
>
LOL. I suggest you start with my first post in this thread and re-
read until the last. You might just learn something. ;)
Web Interface Tricks
Fair enough. I would agree that as a rule it's better to avoid bugs
rather than trigger, then counter-act them, if possible. However, it's
a new bug in a minor version update, so hopefully a short-lived one.
If one absolutely must change the value of a submit button, in spite
of this bug, then any workaround - such as resetting the type property
- only needs to work on currently targeted browsers, until the bug is
fixed.
David Mark
How do you know it "works" in browsers other than those you "currently
target"? And what do you propose to do when this bug is fixed? Go
back and change the code in all of your projects? That's the way
Dojo, jQuery, etc. have "worked" for years (except for the numerous
times they have fallen apart and had to be rewritten). It's no way to
approach browser scripting.
I suggest you come up with a better solution. The "type" property is
unrelated to the problem (which would seem to be restricted to
rendering).
If you want to "trick" the browser into refreshing the rendering.
Perhaps something like this will do:-
el.style.display = 'none';
el.style.display = '';
It's still a hack, but is more closely related to the problem you are
trying to solve (forcing the re-rendering of the INPUT). It's not
going to end up a no-op (browsers aren't that smart yet AFAIK) and it
sure isn't going to throw an exception (in anything).
I'd try it, but my Opera 11.01 is stuck on 0% trying to download the
next version (which I assume is the one you have).
Web Interface Tricks
> On Apr 20, 5:59 pm, Web Interface Tricks
>
> > > > > > One simple workaround seems to be: reset the input's type property to
> > > > > > what it already was.
>
> > > > > You best be careful setting the "type" property of an INPUT. IE is
> > > > > write-once (and some seemingly unrelated operations perform an implied
> > > > > write to that property). In short, set it once, first and only on
> > > > > elements you create.
>
> > > > While setting it to something else ("text", for example), causes an
> > > > error in ie, setting it to its current value doesn't.
>
> > > Which would seem to contradict the (typically vague) MS
> > > documentation. On finding such undocumented "features", you would do
> > > well to ignore them as you can't count on them to work the same in the
> > > future.
>
> > > > You can see an example of the difference here:http://webinterfacetricks.com/input_type_changes/
>
> > > > (Note this was not tested on ie6 or earlier)
>
> > > Hmmm. You are likely "safe" there, but I wouldn't count on it.
>
> > Fair enough. I would agree that as a rule it's better to avoid bugs
> > rather than trigger, then counter-act them, if possible. However, it's
> > a new bug in a minor version update, so hopefully a short-lived one.
> > If one absolutely must change the value of a submit button, in spite
> > of this bug, then any workaround - such as resetting the type property
> > - only needs to work on currently targeted browsers, until the bug is
> > fixed.
>
> How do you know it "works" in browsers other than those you "currently
> target"?
If you don't target and test a particular browser, you don't know a
script works in that browser. They all have their own little bugs that
prevent perfectly normal, standard things from working.
You might be confident it works if you tested multiple, similar
browsers (e.g. the same product with multiple earlier versions, or
different browsers with same engine), but as this opera bug
demonstrates that's not always reliable either.
> And what do you propose to do when this bug is fixed? Go
> back and change the code in all of your projects?
Eventually, yes, there's no point having code that does nothing on any
targeted browser.
Of course, you wouldn't have to do it straight away. It's unlikely to
ever cause a problem, but if it did it won't be until some major
update of internet explore that decides to disallow something it has
allowed for five years and which all other major browsers allow.
Since it's a very specific bug fix, it should be commented as such in
the code, and in that case it would easy enough to automatically find
and delete all instances.
> That's the way
> Dojo, jQuery, etc. have "worked" for years (except for the numerous
> times they have fallen apart and had to be rewritten). It's no way to
> approach browser scripting.
We're not talking about an approach to different browser design and
(documented) features, it's a bug in a minor update. You can ignore
it, which would be perfectly reasonable since it's up to opera to make
sure their browser works, or you can add a workaround, which is by
definition going to pointless for other browsers (and the browser in
question once the bug is fixed).
> I suggest you come up with a better solution. The "type" property is
> unrelated to the problem (which would seem to be restricted to
> rendering).
>
> If you want to "trick" the browser into refreshing the rendering.
> Perhaps something like this will do:-
>
> el.style.display = 'none';
> el.style.display = '';
>
> It's still a hack, but is more closely related to the problem you are
> trying to solve (forcing the re-rendering of the INPUT). It's not
> going to end up a no-op (browsers aren't that smart yet AFAIK) and it
> sure isn't going to throw an exception (in anything).
That doesn't work (in opera). The browser must realise the display
value hasn't changed by the end of the function and so do nothing. If
you do it in two operations (one button sets the display 'none',
another sets it back to ''), the value does update.
So you could do it with a 1 millisecond timeout. This means the
workaround requires more code, and imo is kind of ugly as it means
"flashing" the button, but since it's such a short timeout, and it's
changing the text anyway, and a button's appearance is changed while
being clicked; the flash is probably not noticeable.
I've added these test to this page about the bug.
http://webinterfacetricks.com/opera_submit_bug/
Incidentally, the timeout solution is similar to a workaround for a
chrome redraw bug that someone pointed out a few months ago, and which
is still a problem (despite chrome's rapid update cycle).
http://webinterfacetricks.com/chrome_redraw_bug/
VK
Platoon! Line up! Straight up you face!
I am lousy non-professional programmer and I don't know and I don't
give a sh** about encapsulation, programming patterns, semantization
and all this West Point sh** crap. Plus my English is bad. But I went
through both Browser Wars from the draw and to the end. So if I am
telling you that the fricking gun will explode after 20 shoots then it
will explode after 20 shoots - even if you have a fricking signed
paper from the Combined Chiefs of Staff to shoot safely 100 times. I
am not saying they are wrong - they are always right. I am just saying
that we will not shoot more than 20 times.
Back in 1999 with new IE5 it appeared to be possible again to get on
hold local files by using input=file. The mechanics was: by using
input=text or input=button set value to a known Windows path, then
change it to input=file and submit. With Windows and IE prevailing it
went like a storm. So the question was not to fix it nicely but to fix
it immediately somehow anyhow without locking or breaking W3C DOM
completely. The fix affects all button-like form elements:
input=submit, input=reset, input=button, input=file, button.
Ever since and till very recently W3C DOM docs for these elements were
having a purely entertaining value during the priceless minutes of
meditation in the restroom. That is a special note to Jukka K.
Korpela. You are a novice here but I know your thinking and advising
style from c.i.w.a.s. where you were a guru. "Do like this because it
is documented like this"...
This test:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<title>Test</title>
<script type="text/javascript">
window.onload = function() {
var b = document.getElementsByTagName('input');
for (var i=0; i<b.length; i++) {
b[i].value = 'It works!';
}
}
</script>
</head>
<body>
<form action="">
<ul>
<li>Submit: <input type="submit" name="bSubmit" value=""></li>
<li>Reset: <input type="reset" name="bReset" value=""></li>
<li>Button: <input type="button" name="bButton" value=""></li>
</ul>
</form>
</body>
</html>
shows that the affected buttons are input=submit and input=reset while
input=button works as expected in Opera 11.10 (input=file is always
worbidden to rename so skept from the test).
This fact suggests that it might be not a bug but a deliberate
functionality limitation. It might be decided that the "crucial" form
buttons should not be renamed at runtime. A pure speculation from my
side of course.
A safe quick fix could be like:
form body
...
<script>
document.writeln('<input type="button" name="bSubmit" value="">');
</script>
<noscript>
<input type="submit" name="bSubmit" value="Some default name">
</noscript>
...
end of form
and your onload script then:
var b = document.forms[0].elements['bSubmit'];
b.value = 'me';
b.onclick = new Function('this.form.submit()');
// new Function is to avoid the parasite closure of your
// init function where a lot of other stuff will be I guess
// Surely feel free to spend more memory and use
// b.onclick = function() {this.form.submit();}