robchur wrote:

Now feasible thanks to ParserOutput::$mHeadItems et al.

rd232 wrote:

*** Bug 31958 has been marked as a duplicate of this bug. ***

Yes, Bug 31958 (marked as duplicate) contains some scenarios. The above-mentioned include namespace should be the existing Mediawiki: namespace, but what is still missing is a parserfunction that injects a javascript from Mediawiki-namespace into a specific article page, to support custom functionalities developed by the community according to community needs for specific purposes.

This issue is coming up repeatedly still, when enhanced functionality is only needed on one page that is directly visited. If the page is visited by a link, the ?withJS link directive solve the challenge mostly, but doesn't work when visiting the page. Very hacky gadgets have been used where the gadget runs by default and checks every single page "am I on this one special page, if so run this script" - needlessly running that on every page. While gadgets work for things that are highly repeated well, minor cases still suffer. Would like to see this get implemented along the lines of <templatestyles>, and would be fine with keeping the same restrictions on ?withJS (i.e. file must be in the MediaWiki space).

I think this should be two different extensions, one that would add pages like MediaWiki:Main.js and MediaWiki:Template.js that would run in specific namespaces. This extension would also have pages like MediaWiki:Main.css and MediaWiki:Template.css for loading styles into specific namespaces. This would be similar to the MediaWiki:Vector.js and MediaWiki:Vector.css pages. This would be called NamespaceScripts.

The other extension would add the <templatescripts> tag that would allow JavaScript in the MediaWiki namespace to be run on the pages with the tag. This would be similar to Extension:TemplateStyles but for JavaScript and would be called TemplateScripts.

I was originally thinking this should be one extension, but it wouldn't make sense to no have the CSS pages like MediaWiki:Main.css and MediaWiki:Template.css.

Or I guess support for pages and namespaces options could be added to Extension:Gadgets so the gadget is only loaded when needed.

"namespace" might be ok for gadgets, but having to load lists of pages in to gadgets seems like a bad strategy

In T8883#5970383, @Xaosflux wrote:

"namespace" might be ok for gadgets, but having to load lists of pages in to gadgets seems like a bad strategy

I figured that, so I think it's best to have the namespaces option for gadgets to add css and js to namespaces and the templatescripts extension for individual pages. Although I think the pages option for gadgets might be useful for gadgets that modify specific pages such as AfD or for gadgets that add custom pages to Special:Blankpage.

An application of this feature came up on en-WP here.

The extension UseResource is now available, it allows for the inclusion of both JavaScript and CSS in the MediaWiki namespace.

@BrandonXLF has the new extension undergone the Wikimedia-extension-review-queue review process that seems to be necessary to have it added on any WMF projects (would want to test in testwiki first)

No, it hasn't.

@Xaosflux: I don't see why that would be blocking? This task is about the MediaWiki software itself, not about some Wikimedia websites.

@Aklapper - good point, suppose that extension's creation could be the resolution of this (maybe once it leaves "beta" as it is currently marked) - doubt this will go to core as even TemplateStyles is an extension?

@Krinkle forgive me if I misread you, but if your suggestion is to load common.js up with a list of conditionals for "if page = x" or "if page contains x" for any page this could be desired on that seems like a lot of overhead, not to mention scalability, as this would have to run on every single page view - am I missing something there? How is this not equivalent to templatestyles vs common.css?

In T8883#7069456, @Xaosflux wrote:

if your suggestion is to load common.js up with a list of conditionals for "if page = x" or "if page contains x" for any page this could be desired on that seems like a lot of overhead, not to mention scalability, as this would have to run on every single page view - am I missing something there?

I was describing something that works today. Optimisations don't exist in isolation and conditionally loading is just that: an optimisation. It's worth it (in the current system) to sometimes use a condition in Common.js as alternative to unconditionally loading the entire gadget and its dependencies on every page view. I think downloading one line of code for every gadget we decide not to load scales better than always loading all gadgets and all dependencies.

But, its not perfection indeed, and that's why tasks like T63007 exist and are open.

Watchers may be interested in T241524: Parser function for loading gadgets which has basically the same scope using the gadget system.

People who are interested in something closer to the workflow mentioned in the task description (for non-Wikimedia wikis) should probably look at the Widgets extension.

In T8883#5969796, @BrandonXLF wrote:

The other extension would add the <templatescripts> tag that would allow JavaScript in the MediaWiki namespace to be run on the pages with the tag. This would be similar to Extension:TemplateStyles but for JavaScript and would be called TemplateScripts.

Note that the purpose of TemplateStyles is to restrict CSS to a safe subset so that CSS editing can be opened up to all template editors. That is entirely impossible for scripts.

In T8883#7690860, @Tgr wrote:

Note that the purpose of TemplateStyles is to restrict CSS to a safe subset so that CSS editing can be opened up to all template editors. That is entirely impossible for scripts.

The main user story for this was never about opening up script editing for more editors, it was a means to allow per-page script calling, and the keeping it safe part was to allow only loading of scripts that interface administrators only could edit.

In general comment, the task @Izno mentioned (T241524) does seem to be at least getting close to solving this user story (with the added hoop to jump though of gadgetizing the script first - but that would be done by the same group of people).