I'm astounded...
1/ There's an old jQuery blog post that mentions 'in passing' a list of properties that should be used by .prop(), and it's not "everything should use prop more or less", it's just the *boolean* properties that should go through .prop()...
2/ Even worse. I was completely misled both by the migration guide(http://jquery.com/upgrade-guide/1.9/#attr-versus-prop-) (read that particular paragraph!), and by the jQuery Migrate plugin's source code. While it does indicate that using .attr() for these shouldn't be done, it does NOT mean that the .attr() compatibility code was removed from jQuery 1.9/2.0, EVEN though the plugin proceeds to implement such compatibility... This is where I got screwed. Look for 'rboolean' in both jQuery 1.9 and jQuery Migrate plugin. They're both defined, and tested again. That's madness. I'm disgusted -- wasted a day trying to find proper documentation when all in all, it was still in it.
I sincerely hope that they never frigging enforce the .prop() behavior. If they do, I'll just resort to using it ONLY for boolean properties (the only difference is that a gzipped script.js+sbox.js will take an additional 3 bytes, as only .attr('readOnly', true) is concerned here.)
I will not waste another minute of my time trying to figure out what to do, what to change.
They still have a long list of things that should be checked against re: the upgrade guide... I'm very tempted to call it quits and just go with it.
I know I'll finish it, but I'm still pissed.
Posted: February 3rd, 2013, 10:03 AM
I sincerely hope that they never frigging enforce the .prop() behavior. If they do, I'll just resort to using it ONLY for boolean properties (the only difference is that a gzipped script.js+sbox.js will take an additional 3 bytes, as only .attr('readOnly', true) is concerned here.)
Not that it matters... As I said, it works right now, and I don't want to even think of separating the two functions.
jQuery's one and ONLY goal is to give developers helper functions to make their life easier. I don't *care* if it makes life hell for the jQuery team. It's not that I don't like them -- it's that they should be happy they're used on half the largest sites of the world. It means what they've been doing is USEFUL. It means they're making JavaScript FUN to use. It means they're making their life hell so that ours isn't. It's a sacrifice for the greater good. So I don't care that I should use .prop() instead of .attr(). So, .attr() is four times slower than .prop() when used on properties? Big deal. If my .attr() calls were time-sensitive, I wouldn't call object.attr(property) or .prop() at all -- I'd call the property directly on the DOM object, that's all.
It's not that I think they should revert their behavior, since that's what they did in 1.6.1... It's that I think they should stop telling people that using .attr() is bad. YES, we KNOW it's bad. Just like using jQuery is BAD on time-sensitive loops, but you'll never see them mention that, will you...? Nothing is bad per se. What is bad is what bothers you. What bothers me is a wasted byte in a gzipped file. That's why I switched Wedge to use jQuery 2.0 -- because it's smaller than v1.5 overall, not for the extra features or bug fixes.
Ahh... Feels good to talk about it.
Posted: February 3rd, 2013, 10:34 AM
I knew there was a Google result that made me jump to my guns and start looking into the migration plugin code! :lol:
https://github.com/bcardarella/client_side_validations/pull/466
So, I guess it was an 'unfortunate series of events' that led me to believe they'd dropped .attr() support for properties...
So... This is a totally undocumented bug. I don't know if I should care to 'report' it. I've read a bug report from v1.8 saying that the jQuery team has deprecated { async: false } in $.ajax, just because they didn't like that, basically... Apparently to them, it's important that 'A'jax is always 'A'synchronous, so synchronous calls should be done from a function called $.sjax... Lol. Well, anyway, the stuff is still there, and usable and all, but it simply doesn't return a proper responseXML. Only a responseText. So I thought about it and looked into the Wedge codebase, this is the only place where I'm doing a synchronous call, and turning it into an asynchronous call would be disastrous. So, you know what I did...?
I just rewrote Ajax.php to return a simple text string. Voilà. And it makes script.js a bit shorter, too... It's not as clean as before, but anyway we already discussed returning JSON instead of XML for all calls, haven't worked on that because it's a lot of work for a result that may not be that rewarding, but at least in that particular case, getting rid of XML felt good... ;)
Posted: February 4th, 2013, 11:25 PM
Also, you're not the Wesley Crusher of gzipping, you're the Data of gzipping. Being the Wesley Crusher makes you the smart-arse no-one likes (and one person even told him to his face that it's a good thing he's cute otherwise he could be obnoxious), whereas being the Data of gzipping means it's cool to be intense about it.