User:JimKillock/Migrating ebook features


  • optional narrow single column formats;
  • optional serif fonts for body text
  • Differing styles for headings and so on (not always underlines)
  • easy navigation bars (last page, next page)
  • optional export links to common ebook formats

Method from proposal pageEdit

We certainly can copy templates: they are all freely licensed. It's usually better to have someone with the appropriate user rights to do this via Special:Import. I brought up Wikisource only because you may be able to identify existing solutions to some of these problems you raise. —Justin (koavf)TCM 19:37, 22 April 2020 (UTC)
Thank you Justin, that is very helpful. JimKillock (discusscontribs) 21:42, 22 April 2020 (UTC)
@JimKillock: There are some differences between the provisions for css on different projects, which probably should be kept in mind when contemplating introducing advanced formatting from another project. This may both complicate things and allow some interesting new techniques. (Alas, I have some awareness of the Wikibooks infrastructure, and more about the Wikinews infrastructure, but no past experience with the Wikisource infrastructure.)
  • Different projects may have very different approaches to their customized css. Wikisource appears to have a very small, simple common.css; either there must be some additional css, perhaps induced somewhere by javascript, or perhaps it's all done using javascript instead of css. Wikibooks does a lot more in its common.css, a lot of it arranged modularly in subpages. (For contrast, the Wikinews common.css is all on the one page, which makes it considerably harder to read.)
  • Wikibooks has book-specific css pages: our common.js checks for the existence of a subpage for the book, and imports it if found. (Then again, Wikinews has page-specific css pages, also checked for and imported by its common.js.)
  • The javascript infrastructures are also different between projects. Wikibooks common.js provides for both book-specific and page-specific javascript pages, and its common.js is largely modular. The page-specific javascript, btw, is key to the dialog tools, and was adapted from Wikinews — changing the naming-convention for the page-specific javascript pages, because the Wikinews convention conflicted with the modularity naming-convention of Wikibooks. (Yes, the Wikinews common.js is all on one page, yes that makes it very hard to read, and yes I have considered modularizing it.)
--Pi zero (discusscontribs) 01:31, 23 April 2020 (UTC)

Interesting post Pi zero, but some comments on it:

  • I believe that the bulk of the Wikisource site-css is at MediaWiki:Gadget-Site.css. For some reason some mediawiki wikis use this file rather than the common.css used by others; see mw:Manual:CSS.
  • Custom CSS is now rather easy due to TemplateStyles: see mw:Extension:TemplateStyles. The chief advantage over perbook css is that you don't need admin access to edit, making it easier for most users; also it can be added to any page without the need for it to correspond to a particular book. Despite the name, TemplateStyles can be applied to non-template namespaces, and I have created Template:TemplateStyles/Oberon/styles.css to do so.
  • But if custom JS is needed it still needs to be done through perbook JS. --Jules (Mrjulesd) 12:48, 23 April 2020 (UTC)
I'm interested to hear where the css might be hiding in the Wikisource infrastructure. (Yes, I'm familiar with this sort of use of gadgets.) --Pi zero (discusscontribs) 18:03, 23 April 2020 (UTC)
Well it does actually hide in MediaWiki:Gadget-Site.css; despite its name it actually contains the bulk of the site-wide CSS. A similar situation is with the site; if you look at mw:MediaWiki:Common.css its empty, and its site-wide CSS is actually held at mw:MediaWiki:Gadget-site.css. The reason given for this is that " controls site CSS with the Gadgets extension, so MediaWiki:Gadget-site.css is used in place of MediaWiki:Common.css. This results in a slightly different load URL." --Jules (Mrjulesd)