Author: mike.lifeguard+bugs
Description:
This would allow a stylesheet to apply to only a particular book. Important mostly for the Wikijunior project, but would be useful as well for any Wikibooks. Should also allow per-book javascript.
Version: 1.14.x
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61007
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add root title class to <body> | mediawiki/core | master | +2 -1 |
Sounds you you would want some tag that would enable you to set which .css in the MediaWiki: namespace should be used.
Is that what you mean?
wknight8111 wrote:
Yes, that sounds like exactly what they are talking about. The ability to switch .CSS files (and possibly .JS files too!) depending on the name of the book.
Hello!
Wouldn't be a better approach to have CSS and JS per *categories*?
Then, since all pages of a wikibook is usually in the category with the name of the book, the CSS would be applied without having to tag each page of the books.
Using categories, this would also be useful for Wikipedia, because it is common to have all pages from a category sharing the same style, mainly by means of the templates/infoboxes ([[Category:Wikipedia template categories]] and [[Category:Infobox templates]]);
The same would be great for javascript, because if we could load a script only if the page is at some category we would be able to load a script which is useful only for some pages exactly on those pages, not in every one. For example, not every page has a sortable table ([[Help:Sorting]]) or a collapsible content ([[Help:Collapsing]] and [[Wikipedia:NavFrame]]), but such scripts are loaded for all pages (NavFrame and Collapsible tables are at [[MediaWiki:Common.js]] and sortable tables at http://en.wikipedia.org/skins-1.5/common/wikibits.js). This also happens in other projects then Wikipedia.
Maybe this could be at [[Category:Name of category.css]] and [[Category:Name of category.js]], similar to what we have for user scripts/css.
Helder
By the way, there are other situations where per category scripts would be useful, and I just find another:
Currently, [[MediaWiki:Common.js]] has a script which "Adds editintros on disambiguation pages and BLP pages."
It load EditIntros according to the categories the articles belongs to...
Helder
This bug was mentioned recently in a wikitech thread about inline stylesheets:
http://www.gossamer-threads.com/lists/wiki/wikitech/282115#282115
http://www.gossamer-threads.com/lists/wiki/wikitech/278870#278870
https://www.mediawiki.org/wiki/Deprecating_inline_styles
This is about page rendering and the load queue of scripts (which eventually end up loaded with ResourceLoader).
About as related to ResourceLoader as it is to Apache (which delivers the code eventually).
Change 281253 had a related patch set uploaded (by coren):
Add root title class to <body>
https://gerrit.wikimedia.org/r/281253
Change 281253 merged by jenkins-bot:
Add root title class to <body>
https://gerrit.wikimedia.org/r/281253
So… the underlying request of per page styling is now possible thanks to Ib16e380. This has been marked as depending on T17071: Wikibooks/Wikisource needs means to associate separate pages with books which is presumably for the "page:X" and "page:Y" are both part of the same "book" concept for Wikisource; on Wikibooks for e.g. https://en.wikibooks.org/wiki/LaTeX this is complete as well.
Can we mark this as fixed?
@Jdforrester-WMF , the rootpage-X class definitely helps, but I think we need to ensure we have an end-user solution for this task, before it is closed. Maybe we already have the technical tools we need, and only need to outline how they can be used together now, and ensure that the WMF approves of the tools being (ab)used.
(I'll focus on en.ws, but if you look through the comments on this task there are several other distinct use-cases which dont have a 'solution' yet.)
On English Wikisource, many years ago, we had discussions about how to hack a solution for this, but the community didnt want hacks that we couldnt rely on *forever*-- we need supported features, if we're to rely on it. Wikisource is a very different use-case to all of the other Wikimedia sites, as it explicitly does not want to impose any global style/branding on the work- every 'book' may have its own style.
If we ignore the JavaScript part of this task, so we dont get bogged down in the many problems with people writing malicious JavaScript, and focus only on the CSS (also possible to be malicious, but easier to lock down..)...
At the moment (after that has been deployed), I believe the only way to add per-book CSS is to edit MediaWiki:Common.(js|css) or resources that it loads. That was possible for an administrator to do before the rootpage-X ; @coren's code only made it possible to do it much more efficiently.
If I am not mistaken (just starting on first coffee of the day..), we could already have a component of MediaWiki:Common.js that loads a custom stylesheet called <root name>.css (or similar), if it exists. It used to be a bit hackish to determine the root name, but that problem is definitely solved.
I assume that we dont want that -- generally speaking, css files loaded by our readers shouldnt be editable by anyone. The currently available approach is to put the custom styles in MediaWiki:<root name>.css , or admin protect <root name>.css (or similar). That doesn't scale very well on Wikisource where every book has its own style oddities, and the admin corps are typically quite small.
The two outstanding tasks that I am aware of that would provide a better solution are
I don't think so, since we do not have the JS part of this request, and even for the CSS part we would still need to add code to all pages in order to style the pages of a specific book, since MediaWiki:Common.css is loaded everywhere.
I'm not minded to allow the JS part of this suggestion at this point. Though I can see the value, scoping (as we're going to do for the CSS) is not possible.
for the CSS part we would still need to add code to all pages in order to style the pages of a specific book, since MediaWiki:Common.css is loaded everywhere.
Yeah, that's T483: RfC: Allow styling in templates as @jayvdb says; we can mark that as a blocker then?
Only if you are going to require that for each book we make edits to add the same template to each page of the book, in all Wikibooks/Wikisource projects (instead of loading a CSS file automatically on every page of the "book", as defined by whatever solves T17071).
The TemplateStyles extension allows turning on the features for namespaces other than Template; if you combine that feature with a generic template that transcludes the "right" one according to the page root name, it seems to be it would work fairly easily.
Relying on global CSS with a rootpage-* selector should only be necessary for bits of styling that are restricted for security reasons (much like inline styles) such as specifying background images or using url() values.
It would still require one to add the "generic template" into all pages, of all books, ...
TemplateStyles solves most of the CSS issue in a not perfectly scalable (a template needs to be placed on all pages) but project-independent way, however, there’s still no solution for JavaScript and restricted CSS. I think a solution similar to TemplateStyles could work: <resourceloader module="ext.gadget.mybookgadget" /> (tag name subject to change) would load the ext.gadget.mybookgadget ResourceLoader module. The gadget is subject to the usual protection and thus can contain JavaScript and potentially unsafe CSS, while non-gadget ResouceLoader modules are even more protected, as they can be changed only on Gerrit. It’s even safer if the value of the module attribute is restricted, like to only allow gadgets in a pseudo-namespace (the module name should match e.g. the ^ext\.gadget\.includeable\..+ regexp).
I don’t think that the recent proposal should be implemented. It is a rather hard break in usual cooperation of interface, page content and JavaScript gadgets.
But what if not the template is transcluded, only its sandbox? The module may or may not need to be loaded; this is not deterministic and known only to the—potentially non-IA—user testing in the sandbox. Or when one wants to preview a change to a template that adds or removes a gadget dependency? This latter one is not only organizationally, but also technically impossible to support with the architecture you propose.
- Introduction of new <elements> will destroy the separation of HTML content, as provided by wikitext, and JavaScript which is part of current interface and basically independent of HTML. CSS is quite close to HTML presentation.
If we want to support certain templates with JavaScript, the JavaScript will depend on the page content no matter what. The templates present on the page are determined by the content, after all. Also, there are several extensions that already load JavaScript based on parser tags. Graph and Kartographer rely exclusively on this, but for example Scribunto also loads a JavaScript RL module to show script error details in popups.
- Gadget administration should be done in a central place, not scattered over source code of templates or even articles.
Configuration of a certain template should be done in a central place, not scattered over the template page and MediaWiki:Gadgets-definition.
The comment before is cross-posting at T241524 so I feel free to answer by C&P here as well.
This entire proposal has high risks of misuse. It has no benefit which would not be available via extended Gadget Definitions, but creates double work and complicated additional framework for a single exotic purpose.
You was the one who started the C&P… But let’s forget this, and continue exclusively there.
This is simply not true. The following post has opened a doubled thread for <resourceloader module="ext.gadget.mybookgadget" /> here.