Last modified: 2014-02-12 23:39:53 UTC
From bug 27488 comment 72: --- This bug is blocking deployment of the tabbed languages gadget on the English Wiktionary ([[wikt:en:MediaWiki:Gadget-TabbedLanguages.js]]), which was approved by vote a few months ago: [[wikt:en:Wiktionary:Votes/2012-10/Enabling Tabbed Languages]]. It requires loading from the top for a number of reasons, such as conditional running of CSS based on cookies. --- He's referring to bug 27488, of course. Splitting this issue out to a separate bug report, as whatever issue this gadget is hitting is obviously divergent (if not tangential). Possibly related to bug 27488, possibly not, and possibly solved by a different solution.
I seem to remember some rule like "extensions can set CSS/JS at the top, but gadgets and user scripts can't" or something. Is that right? Could this just be ported to a MediaWiki extension? The English Wiktionarians are wary of MediaWiki extensions as the past process for getting them reviewed and deployed has been pretty awful for them (and many other projects). But I think our processes in this area have improved dramatically recently, so this seems like a viable option. Please tell me to shut up if I'm wrong about any of this. :-)
From bug 27488 comment 75: --- Um, gadgets used to load from the head. This is a feature we had before, and it was then removed. Gadgets (and scripts in general) being moved to a position where everything done is delayed caused many significant problems. I assume that the benefits of these actions made them make sense overall, but gadgets are rather important to many wikis, and I'm not sure that inadvertently impairing them and then generally ending maintaining/fixing resulting issues because of a possible distant-future replacement is completely appropriate. I suppose if no one has the time to devote to this bug in particular to due more pressing/important issues, all the resulting problems will just have to wait however many months or years until 2.0 is ready, but I don't agree that "feature requests" like this on lost features should just be ignored as a rule, hm? --- From bug 27488 comment 76 and bug 27488 comment 77: --- Yair, it won't be years until Gadgets 2.0 is out. Like Krinkle, I don't know a clean way (without breaking backwards compatibility) to do this in the current implementation. When 2.0 comes out, it should be up to the gadget, like it is for regular ResourceLoader modules (https://www.mediawiki.org/wiki/Manual:$wgResourceModules). In the meantime, I don't see why TabbedLanguages *has* to be loaded from the top. The DOM, CSS, and cookies all provide full read-write access at the bottom. The only thing you can't do is document.write. You may get certain UX benefits from doing it at the top, but it's not impossible to make a working gadget now. Also, I forgot to note, the version at https://en.wiktionary.org/wiki/MediaWiki:Gadget-TabbedLanguages.js does not use document.write. --- From bug 27488 comment 78: --- The gadget needs to have the styles run before the body starts loading, and it needs to be disableable for non-logged-in users. The only way to do that is to have the script itself check for a cookie, and set up styles depending on its contents. --- From bug 27488 comment 79: --- Are you trying to load the styles before the body to avoid a flash of unstyled content? I agree that's annoying, but the flash should be brief, so that's not necessarily a blocker. There is nothing position-related about the cookies. They can be manipulated from either place. --- From bug 27488 comment 80: --- The unstyled content means that the entire page is essentially unusable, until the script runs. The community has made it clear that that is not acceptable, which is why we've been waiting until this bug is fixed. ---
(In reply to comment #1) > I seem to remember some rule like "extensions can set CSS/JS at the top, but > gadgets and user scripts can't" or something. Is that right? Could this just > be > ported to a MediaWiki extension? Yes and yes (though I didn't really take a look at the code)... I don't see why position=top couldn't be implemented in the gadget extension though (performance issues maybe?)
(In reply to comment #1) > I seem to remember some rule like "extensions can set CSS/JS at the top, but > gadgets and user scripts can't" or something. Is that right? Could this just > be > ported to a MediaWiki extension? > > The English Wiktionarians are wary of MediaWiki extensions as the past > process > for getting them reviewed and deployed has been pretty awful for them (and > many > other projects). But I think our processes in this area have improved > dramatically recently, so this seems like a viable option. > > Please tell me to shut up if I'm wrong about any of this. :-) Yes, extensions have control over top/bottom, and it defaults to bottom. (https://www.mediawiki.org/wiki/Manual:$wgResourceModules). So that is another possible work-around. (In reply to comment #3) > (In reply to comment #1) > > I seem to remember some rule like "extensions can set CSS/JS at the top, but > > gadgets and user scripts can't" or something. Is that right? Could this just > > be > > ported to a MediaWiki extension? > Yes and yes (though I didn't really take a look at the code)... > I don't see why position=top couldn't be implemented in the gadget extension > though (performance issues maybe?) I believe they will be in the Gadgets 2.0 branch. They just don't want to do a special-case before the branch is done.
Okay, so the options here are for the English Wiktionarians are: * try to work around whatever issue they're hitting in local JavaScript/CSS alone; * port this gadget to a MediaWiki extension; or * wait for Gadgets 2.0 (sometime in the latter half of 2013, I'll say). Did I miss any?
I don't know exactly when Gadgets 2.0 will be done. However, those options generally make sense. Devs may be able to offer some help with getting the gadget working.
(In reply to comment #5) > Okay, so the options here are for the English Wiktionarians are: > > * try to work around whatever issue they're hitting in local JavaScript/CSS > alone; The problem is, there isn't any way to have any locally-defined JS run before the DOM is finished loading, and that's far too late. JS alone can't do anything about this if we can't use any JS at all until it's too late. > * port this gadget to a MediaWiki extension; or Extensions need to be reviewed. In my experience, that simply doesn't happen. (Additionally, I'm not sure any Wiktionarians are even able to make extensions.) If extensions actually were feasible, it would be kind of silly to have TL do the very sub-optimal work of reworking the entire contents of the page entirely via JS, while a pile of CSS, which is allowed to load earlier, is used so that it doesn't look wrong before the script does its work. > * wait for Gadgets 2.0 (sometime in the latter half of 2013, I'll say). Yeah, that's probably what's going to happen. I mentioned in the Wiktionary Beer parlour in April 2011, ten months after TL was first developed by Atelaes, that we just have to wait until the issue with the script delays is fixed. I didn't expect it to take 2.5 years, though. Sigh...
