Apparently IE doesn't like MS's own methods. I changed the code to conform to the DOM and now IE is happy again.
Printable View
Apparently IE doesn't like MS's own methods. I changed the code to conform to the DOM and now IE is happy again.
See - the standards work better even in IE :D
Makes no sense. It's THEIR method, and it worked so well all the other major browsers also support it. I tend to use it because it's shorter. All other things being equal, shorter code is better code, to me. But in this case for some unknown reason, all other things were not equal, so DOM it is.
Out of curiousity - what was it?
innerHTML, their method of accessing a text node (or actually much more than just the text node). Also supported by gecko browsers and Opera. I just changed that to DOM code instead. I think I also changed the call from keyup to keypress event.
I know setting innerHTML is faster. I could well imagine retrieiving it could be slower due to having to construct the code from the DOM tree.
It's also easier. With the DOM if you want to add a node as well as a textNode, you must do it in separate statements because they each have their own method (createElement() and firstChild.data) but with innerHTML you can make it all one string, which makes more sense to me. After all it's ALL just text, and the browser knows which to parse and which not to.
Yuh, but the DOM methods are safer as regards to well formed code.
Adding a node with a text node isn't too hard:
I converted a JS project from using innerHTML to DOM a while ago - made it a lot more managable when I had to change the DOM structure at all. But I know what you mean, it's more work to set up initially.Code:p = document.createElement('p');
p.appendChild(document.createTextNode('Some text'));
I know how to do it, just that it's an extra statement. I have issues with quite a few things the w3c has recommended. I have a few recommendations I'd like to make to them too.
Remember w3c DOM is not meant to be for HTML. It was designed for XML in general; often however, individual implementations have methods such as the saveXML which returns the node and its containing XML as a string.
Quote:
Originally Posted by JPnyc
Just sent them to a mail to Tim JB, and say hello from me (please don't mension that I stole his office) and they will gladly listen to as many requests as possible. It is not only Microsoft, Opera and Firefox that can come with suggestions. Just look at the automatic search. It was an open standard, and are now already adopted by two of the biggest browser vendors. But don't expect JS to make sense any time soon...
The function doesn't count quite properly. I type the first characer and it still shows 10000. I type another and it shows 9999. I press backspace and it shows 9998.
In Fx...
Well I guess it wasn't the innerHTML after all that broke the undo. Seems to not like the onkeyup event handler.
Now it's counting correctly. You found the problem?
That problem yes, but it creates another. If I use the proper event handler, which is how I originally had it, it breaks the undo function in IE, even using the DOM methods. Undo is broken in IE
I found another problem. Not sure if it was there already...
If you paste multiple strings and then try to undo by pressing ^Z (I'm using Opera), just pressing and holding ^Z doesn't work. You have to prerss the buttons multiple times.
I removed it, permanently. Too small a feature to bother about.
Your best option woluld have been to have a function that counts the length of the string at regular intervals, say every 2 seconds and subtracts that form the maximum number of characters. setInterval() or setTimeout :)
Nah, we'd have had complaints about that too, that it didn't change with each character typed. It's just not that important a feature to bother about any further, at least I don't think it is. I could probably get around the IE issue by registering an event listener but that's a pain for a little piddly thing like this
I tried that too and it didn't work either.
Tried what? Adding an event listener? MS has it's own method for that too; attachEvent().
Yes. It had the same effect as yours - counter worked, undo didn't. Also tried a few other things, none of which worked.
You're saying you tested adding an event listener to the textarea element with Vbulletin and had the same result? Hmm........curiouser and curiouser
Well actually no, I just used a regular textarea. It seems to be an underlying problem with IE's handling of keyboard events because it occured with keydown, keypress and keyup - having the event handler breaks undo. I also tried returning false and true and exiting the handler various ways if the Control key was depressed.
Damn, that means I can't fix it. Well thanks MUCHO for testing it, at least you saved my remaining hair! Guess it's ok now to sweep up the hair around my pc chair.
:lol:
OK, the event handler itself plays fine with undo - but if you so much as remotely contemplate altering the document contents from the event handler it breaks it. Even if you set a timeout and then do it.
Blah:
I give up - you could use just addEventListener and have it work in less buggy browsers.Quote:
Originally Posted by [url]http://www.codeproject.com/jscript/htmlarea.asp?df=100&forumid=4685&exp=0&select=1060812#bugs1[/url]
Ah well, we tried. It's not that useful a feature anyway, it's just that I hate giving up on stuff without resolving. It gnaws at me.
FYI I did more testing on this, with a simple page, instead of the much busier forum page, and it's definitely an IE bug. No matter how the function is written or called, undo breaks in IE 6 and 7.