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