Skin & JS cleanup and jQuery
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. :)
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… :D
Oh yeah!
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 might be able to offer a little help if I knew there were openness to this (and that developers who wanted to add things could restrain themselves to follow the necessary standards after things were set up)…
The site might also benefit from a thorough accessibility review, including the latest guidelines in WCAG 2.0… (at http://www.w3.org/TR/WCAG20/ )
Also, I’m not really familiar with the use of JS in Mediawiki, but maybe some JS namespacing could be done to ensure modifications don’t interfere with your own code?
brettz9 (user of yahoo)
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 in the deprecations is that they did not go quite far enough–a very small number of formatting attributes regrettably still remain in XHTML 1.1 (e.g., td align)–I haven’t studied XHTML 5 in this regard, but no doubt the strict variety is at least as strict as XHTML 1.1. (Moreover, there are problems in CSS in that the CSS model does not allow for full control over floats, so that, for example, one could add a multi-column layout without adding any additional tags.) Nevertheless, one can still adhere to a higher standard than the spec, in avoiding even those still-allowed formatting attributes.
As far as having to jump through hoops, if one defines appropriate (ideally semantically-named) classes in one’s stylesheet, some recurring style needs are just as easily expressed, and quite often more succinctly. For example, while “background-color” is admittedly longer than “bgcolor”, if you define the class meaningfully as “sidebar” or whatever, it is less of a hoop to remember “sidebar” than the exact bgcolor code, and “background-color” will just occur once in the stylesheet. It has another benefit of letting you change the color in one stroke.
(cont.)
(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)–it is to move exclusively (or near-exclusively–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’t have to sift through long bits of styling data. If you also insist on adhering to semantic naming, it also helps make clear to yourselves and others what the purpose of the styles are for.
Moreover, Yahoo, for example, did some extensive examination of their code for performance, listing at their Developer blog how moving to external JS and CSS is their rule #8 of performance enhancing lessons: http://developer.yahoo.net/blog/archives/2007/07/rule_8_make_jav.html . You have a good amount of code in the HTML that has fairly long style rules and doesn’t need to be loaded each time (especially for the no doubt many Wikipedia users who are inclined to visit more than just one page and thus can take advantage of browser caching of style data).
And for people with visual disabilities, those who just don’t want CSS (or those who are simply trying to extract data), who can forgo the stylesheets altogether (or who’d prefer aural stylesheets), that code and bandwidth is entirely unnecessary for them. Moreover, if you hard-code styling such as text-sizes, those with visual disabilities cannot adjust them so readily in their clients (see http://www.w3.org/TR/WCAG20-TECHS/C22.html and http://www.w3.org/TR/WCAG20-TECHS/ ).
There is admittedly a challenge for you with the likes of template inclusion, as they would ideally need to be designed to shuttle off CSS elsewhere (into the head, an external stylesheet, or into your site-wide stylesheet) or if not, just accept style attributes in such cases, but I think all of the advantages of external stylesheets are quite compelling (even if you can’t move to them 100%).
It just requires a little discipline in getting used to it, but I think it really is well worth doing. Thanks!
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 is not so much style information in each HTML page to increase bandwidth–and that benefit gets shared across all pages at the site, if they are using the same site-wide file(s). This is why Yahoo and others have emphasized moving to external files–if anything I’d guess CSS will slow things down in client-side performance, since the browser has to relate the element to the style rule, but that is quite negligible in comparison to bandwidth costs, as you suggest. But the point is that such a practice DOES reduce bandwidth…
what about the *.css files?
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 literature, etc., all which add richer semantics or features and enforce precision. Even if HTML is made to support some of them, it inherently will lack the same precision and portability. Maybe Mediawiki could in the future even whitelist specific XML dialects for direct inclusion. That would really be quite awesome–if the semantic web could really take off somewhere, I think it could well be Mediawiki where more meta-data could be added over time.
2) True XHTML can be parsed easily by dumb devices (you can use XSL, by the way, to automatically transform almost all XHTML pages (at least those without nested tables, which should not be common in good design) clearly to XHTML Basic for use on even the simplest of devices, e.g., from cell phones to TVs).
3) The predictable structure of true XHTML allows for use of powerful XSL stylesheets (more options for styling such as declarative sorting), as well as data munging with all of the various tools that support XML (and there are a whole lot), such as the standard XQuery language (which is like an SQL for XML) in a way that is easy for non-HTML-aware devices and which is more predictable even for devices which can attempt to convert HTML automatically to XHTML (I have a Firefox extension which does this).
3) With modular DTDs (esp. if browsers would get around to supporting external DTDs), one can very easily localize or create shortcuts for frequent text in a page.
4) It is supposed to be somewhat faster, but I bet you’re right that it still doesn’t save much in comparison with network latency. In any case, it’s nice to be forced to be precise on what your structure is, so that there is no ambiguity on how a browser should render “tag soup” or bits of “tag soup”, and there’s no need for complicated parsers to try to figure it out.