Skin & JS cleanup and jQuery

Translate This Post

Just a heads-up —
Michael Dale is working on some cleanup of how the various JavaScript bits are loaded by the skins to centralize some of the currently horridly spread-out code and make it easier to integrate in a centralized loader so we can serve more JS together in a single compressed request.
Unless there’s a strong objection I’d be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Common.js files by a large margin for a net savings.
If you’ve done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery — it’s sooooo nice. 🙂

Archive notice: This is an archived post from blog.wikimedia.org, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

21 Comments
Inline Feedbacks
View all comments

Wikia wholeheartedly supports this. We’re transitioning from YUI (ill-advised early decision) to jQuery.

Yes yes yes! I’ve been intending to suggest adding jQuery as a default library on pl.wikipedia, but now I don’t have to persuade anyone 😉

JQuery : making your everyday AJAX crossvbrowser nightmare a sweet dream.
I’d be very very happy to upgrade my frwiki gadgets with it 🙂

Yes, please!!!
The Collection extension currently includes its own jQuery file (which is only loaded when the Special:Book page is rendered). Lots of the other JS bits in the code could be simplified if jQuery was always available.

I highly recommend JQuery, it is by far my favorite framework.

That is really a great news!

That’s fantastic news! The only reason I didn’t add jQuery as default on hu.wikipedia yet is that it doesn’t always work well in certain crappy browsers when loaded from another script.

Wow, jQuery seems pretty popular… 😀

Oh yeah!

brion :
Wow, jQuery seems pretty popular
 😀

HELL YEAH!

Sorry for a slightly off-topic reply, but it does relate to the title of the post… Speaking of skin cleanup, is there any hope of seeing a move toward XHTML 1.0 Strict, or even better, XHTML 1.1 (for browsers that support it)? For browser caching of style information, greater control of styles, accessibility-friendliness, and less encumbered extracting of data (and for XHTML 1.1 greater speed where supported–assuming you take the necessary precautions for reviewing JS, etc. to make sure it works in true XHTML), I think Wikimedia would be (and should be) leading the way for full standards implementation. I… Read more »

In my experience XHTML 1.1 and later are a dead end; HTML 5 is where all the action is in browser support development.
There’s also no particular advantage for the “strict” DTD variants; good clean code can be written with or without it, but the “strict” deprecations are often arbitrary and require jumping through more hoops to replicate simple features.

Oh, and not overriding the prototype (as per the screenshot) is a recommended practice in JS (similar to restricting globals)…

The inclusion of jQuery into a standard MediaWiki installation and minimizing plus zipping the existing JavaScripts would be really awesome. I have in my wiki installation jQuery with it and it is simply super.

Yes, jQuery is both popular and a great library. It’s also used on other projects, and I think it has an awesome API, and a great documentation. I’m really happy to see it included in another project I love. 🙂

XHTML 2.0 may be a dead-end (or at least a far-off end), but HTML 5 also supports an XHTML 5 variant if you are already moving into HTML 5 features. It just has to be done well. If you see the well-known article “Sending XHTML as text/html Considered Harmful” at http://hixie.ch/advocacy/xhtml appendix B for “advanced authors” nevertheless allows for sending two variants according to browser support (and it points out at the top a feature of HTML 5 which actually makes it easier to send both varieties while being faithful to both). The only thing I’ve seen that is arbitrary… Read more »

(cont.) And my suggestion is not to simply move from formatting attributes to the style attribute (which admittedly can be more cumbersome than just using transitional attributes) 211;it is to move exclusively (or near-exclusively 211;see below) to external styling. Stylesheet designers can then have full control to override the styles without having to mess with the HTML code (and they can be assisted by semantic names as well), full separation of formatting from content being a well-established principle in publishing. It also makes the code more readable for programmers, as those concerned with structure don 217;t have to sift through… Read more »

I’d like to know when we will see this released in MediaWiki? If you have any idea…
@Brett : I don’t think much of “performance” in HTML/CSS code… When it takes 15s to download 300ko of JS+HTML+pictures for a web page it really doesn’t matter if the rendering of it takes 30ms or 1s … Maybe it’s just me

@Max, yes, but that’s what I was referring to. Since browsers cache stylesheets and script files, if one places CSS in a single site-wide external stylesheet and refer to that file in each page at one’s site, the user needs to download the stylesheet only one time (at least until their browser cache gets emptied). Thus, they only need to reload the HTML (unless the server gives header information indicating they can cache that too, though we don’t want stale wiki page content, so that’s not an option!), and that HTML will load faster when it does load because there… Read more »

what about the *.css files?

Brett Zamir :
@Max, yes, but that’s what I was referring to. Since browsers cache stylesheets and script files, if one places CSS …

Ok but there is no relation to XHTML here, you can do that with HTML4-5 or XHTML1.0 strict or transitional…

Yes, I think Strict HTML if not XHTML would be helpful and more important, at least as a first goal, than true XHTML, but not transitional (as Wikipedia already is, albeit text/html transitional–with styling attributes inline). But removing the formatting attributes is probably the biggest step toward doing so (that and dropping the “name” attribute on anchors (only use “id”) and dropping “lang” to “xml:lang” only). However, true XHTML is useful for: 1) including other XML dialects like SVG or MathML (not supported, at least now with HTML). There are 3d animation XML dialects, TEI for rich markup of classical… Read more »