Template talk:Documentation/Archive 10

This is an archive of past discussions about Template:Documentation. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 8

Archive 9

Archive 10

Subpages

I've just redirected a number of subpages of Template:Documentation, to the template itself or to its /doc, /sandbox, or /testcases page as appropriate. In all cases these were components of historical versions of the template that haven't been used for years (except on some user sandboxes and the like in a few cases), or their /doc pages or assorted sandbox/test pages. If anyone is interested in investigating deletion of any of these redirects, I have no objections, but I don't intend to pursue deletion of any of them myself.

Note that there are several subpages I did not redirect, since I'm not sure what's going on with them: Template:Documentation/Metapage, Template:Documentation/ruler, and Template:Documentation/start box appear to be used by other templates, and the /testcases subpages and some of the preload pages might be unused and unneeded, but I didn't investigate them. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:36, 14 June 2018 (UTC)

I undid your redirection of Template:Documentation/mirror. That template was the preload when you clicked on the "mirror" option when creating a new sandbox. I would suggest that you carefully review your other mass redirects to make sure that you didn't break anything else.

Below is a list of the pages that were redirected:

--Ahecht (TALK
PAGE) 13:42, 14 June 2018 (UTC)

Documentation/mirror is not transcluded anywhere and undocumented (it's not even mentioned on Documentation/doc), so I think I can be forgiven in thinking it was no longer used, given the large number of other subtemplates that were similarly unused and mostly poorly documented or undocumented. I didn't redirect Documentation/doc; I'm not sure why you listed it, so I removed it from the list. All the other templates you listed are as I explained above - components of historical versions of Documentation that were superseded and deprecated by Module:Documentation, along with an array of attendant documentation, sandbox, and test pages (in the case of the Documentation/core subpages, Documentation/core has been a redirect since 2013, but none of its subpages had been redirected until I did it, just to give an example of the state of most of these subpages). That being said, I've reorganized the list (and removed a duplicate entry) to allow others to more easily review my changes. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:11, 14 June 2018 (UTC)

You have broken many old versions, we often look through page history particularly with templates, in order to find out how they worked prior to being Luaised. What was the reasoning behind this change? Why was it not noted in the edit summary? Did you seek consensus for these changes? I see no reason why I should not revert every single one of these edits. --Redrose64 🌹 (talk) 19:40, 14 June 2018 (UTC)

The only old versions of anything I "broke" would be old versions of {{Documentation}}; old versions of templates are always rendered using the current versions of any transcluded templates, so old versions of other templates use the current version of {{Documentation}} instead of any of these old subtemplates. In addition, I'm not aware of any widely-accepted recommendations to preserve unused templates that were formerly widely used just to prevent old revisions from being displayed brokenly; otherwise, any time a formerly widely-used template came up at TfD, or a formerly widely-used redirect to a template at RfD, it would be snowball kept, and that's definitely not the case. I also don't appreciate you threatening to revert all my edits here, and then immediately doing so while claiming in every single revert summary that I didn't explain my edits - I left a detailed explanation here, and if you'd like me to individually explain any specific edit, I'd be more than happy to. Honestly, I'm surprised and disappointed at just how controversial this set of changes apparently is, given these pages have been unused and largely untouched for years (at least since Module:Documentation was written and deployed, and in many cases even prior to that). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 20:13, 14 June 2018 (UTC)

I'm not aware of any widely-accepted recommendations to redirect unused templates. What harm were they doing as non-redirects? You left no edit summaries. You did not discuss before making such big changes. You have not even left any justification, then or now, for redirecting all those pages, that doesn't boil down to "I did it because I wanted to".

Now, I do quite a bit of work with templates, and have done so for several years. Sometimes, a template gets converted to Lua, and its behaviour usually changes. To compare, I will copy the pre-Lua version over the current one, and preview an appropriate article (without saving the template). If the pre-Lua template had subtemplates, as Template:Documentation does, such a preview is useless if all the subtemplates have been mangled. --Redrose64 🌹 (talk) 23:10, 14 June 2018 (UTC)

Agreed. It is very useful to be able to check what an old version of a template did and there would need to be a good reason to complicate that functionality. To look at it another way, what possible benefit would there be from replacing Template:Documentation/core/doc with a redirect to some unrelated stuff? Johnuniq (talk) 02:04, 15 June 2018 (UTC)

For starters, because Template:Documentation/core was redirected to Template:Documentation years ago, and yet neither of you, nor anyone else that I've seen, have once complained about that redirect, even though that subtemplate was just as widely used as the others. But it's clear that I'm not going to make any headway here, so by all means let's leave these useless pages lying around because a small number of users likes to look at them once in a blue moon. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:14, 15 June 2018 (UTC)

"documentation" headline isn't classed as .mw-headline

this causes custom written css styles to not work very well. I'm using one that sets headlines in a serif font, but that does not apply to the "documentation" headline in the template, since css does not recognise it as a headline.

basically, to make it consistent with standard headlines across the wiki, I'd have to add class="mw-headline" to the span tag. I'm unsure as to how and where to change this, though, and I don't want to break anything. could anyone help me out here? —mountainhead / ? 16:18, 9 September 2018 (UTC)

Floating weirdness on mobile site

So I noticed floated templates can look weird on the mobile site if viewed in a browser that supports floating. Inserting {{clear}} before the documentation template fixes it, but the clearing should probably not have to be put on every template page. Looking at the generated HTML, I spotted this:

<div id="template-documentation" class="template-documentation iezoomfix">

It would get solved if we used the following instead:

<div id="template-documentation" class="template-documentation iezoomfix" style="clear:both;">

But that's the HTML. To get it we would probably have make some change Module:Documentation, where I found this:

:addClass(message('main-div-classes'))

A bit later, I found this:

:css('clear', 'both') -- So right or left floating items don't stick out of the doc box.

Maybe making a copy of that line right after the other one would solve this? I don't know for sure, but I did think of another way to solve this: applying the following CSS to the mobile site:

.template-documentation{
    clear: both;
}

That's saying floated stuff can't be to the left or right of anything of the class template-documentation. Which should push the heading down.

This issue also affects any floated templates, though it looks more distracting if they're floated to the left. – Pretended leer {talk} 12:52, 24 October 2018 (UTC)

Make it like a documentation box

Make it like a documentation box because it's weird when looked with mobile view, just like Indonesian Wikipedia. For example, see id:Templat:Dokumentasi
Rayhan6726 (talk) 11:36, 2 February 2019 (UTC)

@Rayhan6726: Make what like a documentation box? This is the talk page for Template:Documentation, which is the documentation box. --Redrose64 🌹 (talk) 17:05, 2 February 2019 (UTC)

@Redrose64: the example is on id:Templat:Dokumentasi

Here's some better links for comparison: en and id. -- WOSlinker (talk) 08:30, 3 February 2019 (UTC)

Mobile doesn’t show a green documentation box. Apparently on Indonesian Wikipedia mobile, it shows a box? PorkchopGMX (talk with me - what i've done) 21:48, 10 February 2019 (UTC)

@PorkchopGMX: yes, it's like a green box on mobile view. For example, see id:Templat:Infobox pengguna. Rayhan6726

07:25, 4 March 2019 (UTC)

Generating documentation for code point name modules

I recently added a bunch of Unicode data modules containing the names of ranges of code points, such as Module:Unicode data/names/000 (see a table listing all the name data modules at Module:Unicode data/doc § Data modules), based on the ones on Wiktionary. Ideally they should all have some text describing the range of code points that they apply to and be placed in Category:Unicode data modules. On Wiktionary the documentation of these modules is generated automatically by wikt:Module:documentation (so they do not have documentation pages). Could the same thing be done in Module:Documentation here on Wikipedia? I'm not very familiar with how the module works, and maybe it would be irregular to do it this way. I could also create a documentation template and add it to all the documentation pages of the modules. — Eru·tuon 21:00, 28 March 2019 (UTC)

Green box shows on Template pages but not on Module pages even though the Doc does show

With no response I decided to remove it from here and try somewhere else.--WikimeSteve (talk) 17:21, 18 July 2019 (UTC)

Documentation edits

It's no secret to most of us that /doc pages are usually unprotected even if their template pages are protected. Just read a conversation here that tells us that inexperienced editors might see a padlock on a template page and assume the whole page, including documentation, is protected from their editing. Shouldn't we place a brief note near the top of the /doc page that explicitly says that the documentation can usually be edited even if the template cannot be edited? or something to that effect? Paine Ellsworth, ed. ^put'r there 17:22, 29 July 2019 (UTC)

That's a good idea. It's worth noting that Module:Documentation already reads the protection levels for the template page, so wouldn't take much tweaking to also read the protection levels for the documentation subpage. It would be a little more expensive, but nowhere near any limits, and would allow the documentation text to accurately state the protection level for the documentation page separately. --RexxS (talk) 18:00, 29 July 2019 (UTC)

Actually, /doc pages with their own separate padlocks might work even better than a textual note that might be missed. Even better! Pinging Mr. Stradivarius and Jackmcbarn for help with this. Paine Ellsworth, ed. ^put'r there 02:28, 30 July 2019 (UTC)

Moving CSS

Currently, the CSS styling for this template is added in MediaWiki:Common.css based on the css class added by cfg['main-div-classes'] = 'template-documentation iezoomfix'. Rather than being specified in common.css, the css should be specified locally in the module. As seen in User:DannyS712/template sandbox 2, the current versions of the sandbox (Special:Permalink/905739909) and config sandbox (Special:Permalink/729280654) include the css locally within the template (demo: using safemode, sitewide css is ignored, but the css added by the module isn't) I propose that these changes be implemented:

Change to module: [1] (without the first line that uses the sandbox config) (and potentially leaving the class, rather than replacing it)
Change to config: [2]

This could be done without removing the html class currently used, even while removing the css from common.css, so as to remain compatable with current user scripts that may rely on the class. In time, it could be removed, but I see no hard in leaving it for now. Thoughts? --DannyS712 (talk) 17:58, 11 July 2019 (UTC)

Given the lack of comments, in a few days (unless there are objections) I will: add the css code to the config, add it to the module while leaving the current class declaration in case it is used by scripts, and then request that it be removed from the common.css. --DannyS712 (talk) 19:58, 14 July 2019 (UTC)

Doing... DannyS712 (talk) 15:14, 19 July 2019 (UTC)

Done - Special:Diff/906971056 and Special:Diff/906970692 --DannyS712 (talk) 15:20, 19 July 2019 (UTC)

I don't watchlist this page and didn't see the original request, but I'm opposed to moving CSS from classes to inline styles. It's exactly the opposite of what we should be trying to do. Adding styles inside module code is even more problematical, given the paucity of module editors. Inline styles make it difficult for editors who require modified styles because of visual impairments to override those styles. It is far better to move styling out of content and into style sheets, which allows a user style-sheet to override it. I think those edits should be reverted. --RexxS (talk) 16:56, 19 July 2019 (UTC)

@RexxS: I intentionally left the class declaration included, so that it can still be overridden by user style-sheets. Would it be better to use template styles? --DannyS712 (talk) 17:03, 19 July 2019 (UTC)

Yes. See the implementation of Module:Citation/CS1 or the bit of code at mediawikiwiki:Help:TemplateStyles#Calling from a Lua module. The styles in question should be at Module:Documentation/styles.css. --Izno (talk) 18:56, 19 July 2019 (UTC)

@Izno: Good to know - reverting --DannyS712 (talk) 20:26, 19 July 2019 (UTC)

reverted --DannyS712 (talk) 20:31, 19 July 2019 (UTC)

Besides the RexxS concerns, I have a separate concern, which is that Lua pages automatically include the documentation styling, and I don't know how those get the template-documentation class--whether that's a class that's in Extension:Scribunto itself or whether we somehow call Template:Documentation somewhere on some interface page. Anomie? --Izno (talk) 18:56, 19 July 2019 (UTC)

@DannyS712: It doesn't help to leave the class in place. The way that cascading style sheets work is that each style that is processed overwrites any previous definitions of that style. So classes are processed first from the (global) MediaWiki software, then from mw:common.css, then from user common.css, next from user skin.css, and finally styles from any inline definitions are processed. That means that normally, any inline definitions will override all earlier ones, preventing a visually impaired user from setting colours to high-contrast ones, for example, for that class in their user stylesheets. TemplateStyles fit somewhere in that sequence, probably quite late on, so we'd have to do a test to determine whether we can still override them from user stylesheets. --RexxS (talk) 19:53, 19 July 2019 (UTC)

@RexxS: we should run that test then. I'm reverting myself, but per above templatestyles is better, and we have been migrating styles out of common.css so that they aren't always loaded when they aren't needed --DannyS712 (talk) 20:28, 19 July 2019 (UTC)

@DannyS712: I very much encourage shifting from common.css to TemplateStyles and I wrote some of the initial workflows and provided examples to encourage the take-up, so I'm on your side in that. Unfortunately I've just done the test and it's disappointing. You can do the test yourself:

Add the line .thermometer-bulb { background-color:blue; } to Special:MyPage/common.css and purge the page.
Look at page Template:Thermometer and purge the page. The bulb should now be blue, but it isn't.
Use the Inspector in your browser to check the styles for the div containing the bulb. You can confirm that your user css sets the bulb blue, but then the TemplateStyles overwrites it.

That's a bad mistake in the implementation of TemplateStyles, which need to be applied before user css. I suppose we need to thrash that out in Phabricator. For now, it's possible to work around it by using user css like .thermometer-bulb { background-color:blue !important; } (which does work), but that's a poor solution to a systemic problem. --RexxS (talk) 01:26, 20 July 2019 (UTC)

@RexxS: in that case, is there any difference in the result between using TemplateStyles and using this inline style, at least for now? --DannyS712 (talk) 01:28, 20 July 2019 (UTC)

@DannyS712: Yes, if we can get TemplateStyles to cascade in the correct place, then a visually impaired user can use their own stylesheet to modify the appearance of the content without any further action. If we use inline styles, that will never be possible without also moving all of the inline styles to TemplateStyles. Google "why inline styles are bad" for more opinions, or check this blog for a good description. IMHO, we should never apply static inline styles in a module; the only good reason for applying css in the module is when the style is dynamic, i.e. the module computes a value for the declaration or the style is conditional on other module content/parameters. --RexxS (talk) 01:57, 20 July 2019 (UTC)

@RexxS: would you object to moving this to templatestyles? DannyS712 (talk) 22:14, 23 July 2019 (UTC)

@DannyS712: I wouldn't object. It does mean that we still have some work to do in meeting best practice for accessibility, but moving from Common.css or from inline styles to TemplateStyles is a move in the right direction. Cheers --RexxS (talk) 18:50, 24 July 2019 (UTC)

@RexxS: There are a few reasons why you were unable to change the color.

The first is that the extension 'hoists' each of the selectors to .mw-parser-output, which really means the selectors in the TemplateStyles CSS page are actually .mw-parser-output .thermometer-bulb rather than your suggestion, .thermometer-bulb.
The second is that the styles are injected into each page inside of a <style> element much later than the <link> elements which invoke your mw.common.css, common.css, and skin.css files, which means that those styles apply after your common.css sheet does (the last CSS at a certain specificity is king). @Anomie: I do not know if it was intended for TemplateStyles to win over user-personal styles at the same specificity; if it was, was there an engineering tradeoff? We should perhaps document this in mediawikiwiki:Extension:TemplateStyles if so.

(On an aside, this problem might explain a previous problem that Headbomb was having--I will have to go poke and see if the below workaround fixes that one as well.)

Regardless of the above, this is a matter of specificity to override. In the former case, assuming the content was added before rather than after your personal css files, you would be able to override the bulb color with just .mw-parser-output .thermometer-bulb { background-color:blue; }. In the latter case, since that is not presently a true assumption, you can trivially increase the specificity by adding some other selector, such as .mw-parser-output div.thermometer-bulb { background-color:blue; } (nevermind that !important will also work and as the sheets are user-specific, !important probably isn't a big deal). --Izno (talk) 19:57, 3 August 2019 (UTC)

@Izno: I don't recall that order of TemplateStyles CSS versus user CSS was specifically discussed, and I don't see anything along those lines on T155813. The positioning of the TemplateStyles-generated <style> within the page was dictated mainly by performance concerns, specifically that including the styles in the HTML "above the fold" would slow down time to first paint on slow connections.

As you noted, it's not very hard to adjust your user CSS specificity so the ordering doesn't matter. Anomie ⚔ 18:02, 4 August 2019 (UTC)

@Izno: Its specified at MediaWiki:Scribunto-doc-page-show --DannyS712 (talk) 20:30, 19 July 2019 (UTC)

Ok, that makes me more confident that we won't break anything from that perspective. Let's get the remaining invocations of template-documentation cleaned up in the various spaces that would otherwise break (i.e. add inline styling where appropriate) and then we should look at incorporating a TStyles page into the module. --Izno (talk) 19:16, 3 August 2019 (UTC)

I've taken care of the remaining invocations in the wild of template-documentation and I think I've successfully moved the various styles to the styles sandbox. Now I need to modify the main sandbox module for invoking the TemplateStyles page. I'm a little confused on why the metadata box invokes the message box module, but that's an aside. --Izno (talk) 18:23, 4 August 2019 (UTC)

So, I have an implementation that kind of works. It's breaking Template:Documentation/sandbox at the current revision (it works at my 'what does this do' revision previously) with an output of <p>{{ Template:Documentation/doc<style data-mw-deduplicate="TemplateStyles:r909327506">styles elided</style>}} </p>. Help is appreciated to get this over the hump. --Izno (talk) 19:58, 4 August 2019 (UTC)

There were also two tests broken as a result of this implementation in addition to the other five noted below; see testNoTrailingWhitespace and testSandboxImageBug. --Izno (talk) 20:00, 4 August 2019 (UTC)