Page MenuHomePhabricator

Per book, category and/or template CSS and JavaScript
Open, LowPublic

Description

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

Details

Reference
bz15075

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
DeclinedNone
DeclinedNone
ResolvedLegoktm
ResolvedNone
ResolvedNone
ResolvedNone
DeclinedNone
DeclinedNone
ResolvedNone
DeclinedNone
ResolvedLegoktm
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
DeclinedNone
DeclinedNone
DeclinedNone
ResolvedNone
InvalidNone
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
DeclinedNone
ResolvedNone
DeclinedNone
DeclinedNone
DeclinedNone
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedTgr
ResolvedAnomie
Resolvedtstarling
Resolvedcoren
ResolvedAnomie
DeclinedBUG REPORTNone
ResolvedAnomie
ResolvedEsanders
ResolvedEsanders
Resolvedssastry
ResolvedAnomie
ResolvedCKoerner_WMF
Resolvedjhsoby
ResolvedTgr
DeclinedTgr
Resolvedcoren
ResolvedAnomie
ResolvedTgr
DeclinedNone
Resolvedssastry
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedDeskana
ResolvedCKoerner_WMF
ResolvedWhatamidoing-WMF
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedUrbanecm
ResolvedTgr
ResolvedTacsipacsi
ResolvedTgr
ResolvedCKoerner_WMF

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:21 PM
bzimport set Reference to bz15075.
bzimport added a subscriber: Unknown Object (MLST).

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

See also the option mentioned in bug 2212#c9.

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

Jdforrester-WMF added a subscriber: Jdforrester-WMF.

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

Can we mark this as fixed?

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.

Can we mark this as fixed?

I don't think so, since we do not have the JS part of this request

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

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

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.

  • T204201 Extend MediaWiki:Gadgets-definition capabilities would solve the JavaScript loading issues much better. It serves much more cases and is flexible enough, e.g. by loading JavaScript if a certain template is transcluded.
  • 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 more related to HTML presentation.
  • Gadget administration should be done in a central place, not scattered over source code of templates or even articles (book content).
  • T204201 Extend MediaWiki:Gadgets-definition capabilities would solve the JavaScript loading issues much better. It serves much more cases and is flexible enough, e.g. by loading JavaScript if a certain template is transcluded.

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.

  • The proposal is also creating a risk of undiscovered vandalism.
    • Malicious users, even every anonymous user can trigger all available gadgets and increase client load of all visitors. Since not useful in current situation, no gadget will have any visible effect and attack may be detected years later.
  • It is not clear what is taken precedence over explicit user opt-out. Will the proposed element override user option?
  • There are not many templates which have a reasonable connection with a specific template.
    • A template for coordinates may trigger the local adaption of WISWOSM. That can be administrated by the new syntax of T204201 and narrow such gadget calls to pages where coordinates really occur.
    • If a gadget is related to a particular template it is up to inventors to tailor the usage precisely that transclusions and gadget loading are matching well.
    • It is even possible to define a dummy template which creates no wikitext output at all, and has the one and only purpose to trigger gadget loading. That is exactly what the proposed new element shall do, but limited to exactly those gadgets which are defined for such assignment.
  • There will be only very, very few templates which are related to a gadget.
    • The total number of gadgets is not very large, and it is an exception that a template is related to a possible gadget in that wiki.
    • There is not a huge number of applications with relation of content and JavaScript. Table sorting, collapsible elements. Those as well as extensions like Graph and Kartographer are under MediaWiki control.
  • Management of gadgets shall be kept limited to interface administrators by maintaining Gadget Definitions specifications.

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.

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.