Wedge

Oh my, we need to do something about the like styling in thoughts... I guess it's going to force me to do my thought mini-menu earlier than hoped... :^^;:

rev 1902
(3 files +1, 35kb)

* Split Subs-Template's wetem object into its own file, Class-Skeleton. This was long overdue, especially considering it represented about a third of the more generic template code. (Class-Skeleton.php, Subs.php, Subs-Template.php)

* Moved <move> XML commands upstream, to avoid storing them in a variable for no reason other than legacy code. (Subs-Cache.php)

! oldIE has a very odd bug (who's surprised?), where it loads a CSS file twice if we linked to it without a protocol (i.e. //domain). Although it's unlikely you'd want to point to an external stylesheet in your code, it's still a possibility, so until further notice I'll be adding this extra regex to protect external stylesheets. (Subs-Template.php)

rev 1900
(4 files +2, 7kb)

+ Preliminary implementation of the skeleton rewrite. This involves separating skin.xml skeletons into their own files, and removing the template_skeleton function from the index template, to be replaced by a (simpler?) skeleton.xml file in the skins folder. Currently, the only drawback is that you can no longer override a skeleton just with the magic of custom.xml, but OTOH I don't really see a reason for doing that, you're better off use <move> commands in that file. Perhaps I should also add custom.xml commands to <add> or <remove> elements from a skeleton..? (Load.php, Subs-Cache.php, index.template.php, skins/skeleton.xml, Warm/skeleton.xml, Warm/skin.xml)

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... ;)

rev 1898
(3 files, 71kb)

! The jQuery CDN (code.jquery.com) doesn't support HTTPS, so don't bother using it when that particular CDN is selected. (Load.php, Subs-Cache.php)

* Committed by mistake a custom minified version of jQuery 2.0... While it was about 600 bytes smaller than the official one, it didn't compress as well. Beats me. (jquery-2.0.0b1.min.js)

Basically: keep it as it is.

What they're not telling us, or telling us in a convoluted manner, is that:

- you can use .attr() on anything (attributes and properties), jQuery will do the cleaning up,
- you should use .prop() on properties, and you REALLY should use it on properties that accept/return a boolean value (there's a list hidden in the migrate plugin, includes checked, disabled, autoplay, readOnly, etc...)....
- ...BUT you don't HAVE to use .prop() anywhere, it's just a matter of semantics really, and .prop() is also 4 times faster,
- and basically, if you want speed, you should directly access the DOM property, rather than use a jQuery method.

So, in the end: jQuery 1.9 didn't require ANY changes in Wedge, except for the .live() function being removed, and I used it a total of 3 times. The rest is just either semantics on their side, or changes that allow me to save a few extra bytes so I'm adopting them. But even then, it would be easy to come back to a v1.5 implementation.

Bump for my post above. I think that doing that robots.txt thing or htaccess or whatever should be discussed.

@Lorenzo> I'm surprised a CDN not advertised on jquery.com would offer it..? Anyway, isn't this only for cloudflare customers?
I wouldn't be fussed over whether we should add it or not, but I just don't know if they're going to keep up with jQuery's releases, precisely because they're not officially sanctioned. It'd be a disaster if I started having to check whether all CDNs provide the version I'm targeting... Right now I'm only doing a special test for beta versions -- forcing the CDN to code.jquery.com (which is the only one to host beta versions), in case a beta or RC tag is found in the filename. (I think that one's a good idea. :cool:)I'm not sure, but that's the idea :)

I've had a look at your code, and you're too kind with suggest.js, you shouldn't have kept the opt.sTextDeletItem stuff at all I'd say... ;) Who's going to change it anyway..? A plugin? Bad semantics, bad karma!

Also, I was thinking we could rename pm.js to member.js and instead include in that file all of the small functions that aren't targeted to guests... e.g. the draft auto-save, things like that. But if it forces members to load the PM JS code on every page where draft auto-saving is required (for instance), it might not be that helpful.
Haven't looked at all the functions that could benefit from being moved there.Yup, definitely the idea ;)Yep yep yep, my you're scaring me! :lol:Okay, seriously... Have I started tainting you with my madness? I'm so sorry... :^^;:

Anyway, I did a few @language stunts when I implemented the thing, then I pretty much stopped because of a bug which I only fixed recently, and then I was too busy with other things to think of it.

I looked into the code and found some more...

- txt.done in spellcheck.js -- however, I'd advise against adding it for one reason: if you're not using the default language, you'll get another instance of your language name in the spellcheck JS URL, while the txt.done string seems to be initialized only in the spellcheck popup. Actually, I'd be interested in knowing why spellcheck.js is loaded at all in the editor, when all of the operations are done from the popup (which can load the JS file by itself...)

- your very own draft auto-save code :) I don't think there's anything preventing that one from being passed on.

- the YUI uploader -- we need to rewrite it to use HTML5, by the way... :-/

- the upshrink description for toggles could be a 'default' instead of being explicitly set (it's the only text string that's actually sent to them, except from a few "-" here and there.) Either with something like altExpanded: 'default', or not setting it at all in the HTML -- although we'd have to ensure that it 'works' on all toggles that don't specify an alt. It's important to check on this one -- it's on every single page! :)

- message_txt_delete in wedgeAttachSelect is a given :)

- register.js always uses the same regTextStrings, with the Register page adding a few strings compared to the Reminder page. We could, instead of sending the text strings, send a boolean determining whether register.js will use one set of strings or the other.

That's all I could find for now... (Okay, "forever", since I'm unlikely to do that again!)
I searched through "JavaScriptEscape($txt", by the way, in case you know of a few places where we don't sanitize the strings when passing them to JS. I don't think there are any ;)

Do you want to do them all, or split the job, or let me do them?
Whichever you prefer. Right now I'm busy at work on splitting skeleton stuff anyway.

rev 1894 - jQuery... Can't live with you, can't live without you!
(23 files +2 -1, 182kb -- including 171kb of jQuery code.)

+ Updated jQuery from v1.5.2 to a dual v1.9/2.0, where 1.9 is used for IE 6/7/8 while 2.0 is used for other browsers. Also added support for beta and RC versions of jQuery by redirecting Google and Microsoft CDNs to the jQuery CDN if a beta version is requested (like for the current 2.0 release.) In case you're wondering, we're mainly upgrading jQuery because v2.0 is actually (for the first time!) smaller and tighter than v1.5.2. Yay. (Load.php, jquery-1.5.2.min.js, jquery-1.9.0.min.js, jquery-2.0.0b1.min.js)

* Changed .bind(), .unbind() and .andSelf() respectively to .on(), .off() and .addBack(), recommended methods in jQuery. Saves a couple of bytes off each file. (attic/Unused-SelectBox.js, attic/Unused-events.js, attic/Unused-tie.js, Admin.template.php, ManageModeration.template.php, Profile.template.php, mediadmin.js, player.js, sbox.js, script.js, suggest.js, topic.js, zoomedia.js)

* Changed .live() and .die() to custom .on() and .off() versions which should be faster. One occurrence was instead replaced with a .one() sent at editor creation time (remember that seldom used function..?), which is way more efficient than a live() call anyway. (Display.php, editor.js, editor-func.js)

* Turning some leftover <whatever /> tags to <whatever> in help files. (Admin.english.php, Admin.french.php, Help.english.php, Help.french.php)

* French translation. (ManageBans)

@ Just realized I posted this at 18:49 French time... That's an anagram of rev 1894 :p

There's only Display.php (to indicate "All pages") and the index template (template_page_index) that do this, as far as I know...?
It's just a matter of searching for [<strong> and removing the [.
I quite like the [] myself, but I'm not fussed. I think the main point in [] is that it helps differentiate the current page from other pages when neither the color contrast and font weight (depending on the used font) are enough to spot the difference.


And removing it for a sub-skin should be as easy as...


I should implement a way to entirely remove something without having to specify the code to remove... (Originally, @remove didn't even accept an extra parameter with the specific selector to impact.)