Jump to content

Wikipedia talk:TemplateStyles/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Mobile vs. Desktop sizing

I suggest we add something about being consistent in making a distinction between mobile'ish and desktop'ish sizing for template styling, as having items jump around multiple times in an unpredictable matter can be rather annoying. The cutoff point between mobile and tablet/desktop styling for Minerva is currently 720px and 1000px. I suggest we therefore start with these values and ask people to discuss any other media query settings before applying. —TheDJ (talk • contribs) 11:34, 24 May 2018 (UTC)

  • Forgive me if I misunderstood, but I read that as saying only media queries with 720px or 1000px would be allowed. I object to this. I have numerous use cases for 320px & 480px breakpoints, which are basically essential for any useful mobile responsivity if there is anything except the simplest layout going on. Additionally it is a cornerstone of modern web design that your mobile and desktop interfaces should share common features and look much the same so as to not annoy or confuse the viewer - but this is best achieved with more breakpoints, not less. Also if someone has designed something that jumps design so dramatically, then that is a problem with that specific design, not the overall system. In short I want there to be flexibility in setting media queries as appropriate to the specific design, or if they must be set, a minimum selection of commonly used viewports. JLJ001 (talk) 17:37, 24 May 2018 (UTC)
  • For comparison, the breakpoints in Timeless are – mobile: up to 850px; then desktop-small: up to 1099px; then desktop-mid: up to 1339px; and then desktop-large. - Evad37 [talk] 03:09, 25 May 2018 (UTC)

How about something like this:

  • Media queries for screen width should normally use one or more of the following standard values. This limits the number of times content can jump around multiple times in an unpredictable matter.
    • 320px (small mobile devices)
    • 480px (medium mobile devices)
    • 720px (large mobile/tablet devices)
    • 1000px (small desktop screens)
    • 1400px (large desktop screees)
  • Responsive designs should take care to avoid dramatic changes across breakpoints.

- Evad37 [talk] 03:32, 25 May 2018 (UTC)

Turns out they are actually documented now for Wikimedia:
    • 320px (minimum size for a modern mobile device)
    • 720px (minimum size for a tablet)
    • 1000px (minimum size for desktop screens)
    • 1200px (large desktop screen)
    • 2000px (extrawide desktop)
—TheDJ (talk • contribs) 07:23, 25 May 2018 (UTC)
I think that is reasonable. I also think that +- 5px on these breakpoints should be acceptable. JLJ001 (talk) 12:10, 26 May 2018 (UTC)
@JLJ001: "I also think that +- 5px" What sense does that make, can you clarify ? The whole point of having cutoffs is to not change layout every 5px. —TheDJ (talk • contribs) 20:00, 26 May 2018 (UTC)
Imagine I wanted to set a breakpoint at 321px for some reason, this is close enough to 320px that it shouldn't be changed if it was done this way. But 326px would be too far off the agreed point and need a good reason to be so. To give an example, I often ( probably wrongly :D ) code min-width and max-width media queries to be 1px separate from each other to avoid an overlap, eg 600px and 601px. JLJ001 (talk) 20:08, 26 May 2018 (UTC)

To clarify all these combined plus some I just added is:

    • 320px (small mobile devices)
    • 480px (medium mobile devices)
    • 600px (small phablet devices)
    • 720px (large mobile/tablet devices)
    • 850px (Timeless breakpoint)
    • 1000px (small desktop screens)
    • 1100px (Timeless breakpoint)
    • 1200px (medium desktop screen)
    • 1400px (large desktop screens)
    • 2000px (extrawide desktop screens)
Tracked in Phabricator
Task T165945
I'm fairly certain there is now a task in the Timeless project to sync the cutoffs to the documented cutoffs. --Izno (talk) 21:18, 27 May 2018 (UTC)
If that was done we could safely ignore 1100px and 850px, maybe also cut 600px. JLJ001 (talk) 21:22, 27 May 2018 (UTC)
phab:T165945. --Izno (talk) 20:16, 28 May 2018 (UTC)

RFC: Adopt as a guideline

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There is an unanimous consensus to checkY adapt the dicussed page as a guideline.Best,∯WBGconverse 13:15, 18 June 2018 (UTC)
See also: Wikipedia:Village pump (technical)/Archive 166 § RfC: Enabling TemplateStyles

Pinging those who commented at the VPT discussion: @Jc86035, Galobtter, TheDJ, Richard0612, Epicgenius, Headbomb, Anomie, Mr. Stradivarius, Cesdeva, Xaosflux, JJMC89, Amorymeltzer, Pppery, and Redrose64:

Should this page, Wikipedia:TemplateStyles (WP:TSTYLE), be adopted as a guideline? - Evad37 [talk] 08:19, 22 May 2018 (UTC)

Survey

Discussion

I didn't realise that, that's enormously useful. looks like error checking is built in. While I am thinking about it, is it possible to list all pages using TemplateStyles / all pages with TemplateStyles errors? JLJ001 (talk) 16:38, 26 May 2018 (UTC)
You can find all style pages (i.e. pages with the TemplateStyles "sanitized CSS" content model) by searching for contentmodel:sanitized-css from Special:Search (e.g. [1]). You can find all pages using a particular style page using Special:WhatLinksHere, just as you can find transclusion of a particular template that way. There's no straightforward method that I know of to find pages with these errors or to find all pages using any TemplateStyles CSS page. The latter seems rather unlikely to be implemented, but a tracking category for pages with errors could be added easily enough (file a request for one in Phabricator, being sure to tag it with TemplateStyles). Anomie⚔ 17:54, 26 May 2018 (UTC)
Ok thanks. I am not feeling evil enough to throw extra work at the people implementing this at the moment, but it's nice to know that it's an option if needed. JLJ001 (talk) 18:18, 26 May 2018 (UTC)
There's no harm in requesting it. If the developers don't think it's important enough to make time to do it, they'll just leave it in a backlog. BTW, there's also the fact that one of the two people likely to implement it is me with my other hat on. ;) Anomie⚔ 20:50, 26 May 2018 (UTC)
Tracked in Phabricator
Task T195676
Ok I did that. Although I am not used to that exact system, I am pretty sure it's assigned to you so you should see it. JLJ001 (talk) 21:08, 26 May 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Citation templates

Could some TemplateStyles expert comment on Help_talk:Citation_Style_1#Arbitrary_break, and at least tell us if styling citation templates with TemplateStyles would be possible? Headbomb {t · c · p · b} 00:58, 6 July 2018 (UTC)

That seems a bit iffy. It might be possible, but might require some excessively weird HTML. TemplateStyles is enabled on testwiki if you want to try things there, or you could try using your common.css here to test things out (being aware of certain CSS features that aren't supported in TemplateStyles, such as CSS variables). Anomie⚔ 13:14, 6 July 2018 (UTC)
The issue is stupid LUA for the CS1 templates which means I can't test much there. You might as well ask me to write something in Chinese. I might be able to hack something in wikitext, and someone else might convert that in a proper LUA thing. Headbomb {t · c · p · b} 13:29, 6 July 2018 (UTC)
@Headbomb: I think it would be quite unwieldy to do it with TemplateStyles (if you were to do it by adding a parameter to {{Reflist}}), since you would probably have to have HTML classes hardcoded into every name (e.g. <span class="name"><span class="first"><span class="initial">W</span>illiam</span> <span class="last"><span class="initial">S</span>hakespeare</span></span>) and you would also have to have them such that you could show the text in the orders needed; you'd basically be adding display: none to all of the superfluous text. You would also not be able to affect citations not based on the CS1 module. Using Lua inside the cite templates seems far more manageable and should be implementable as you proposed, although the module would have to be able to handle cases like hyphenated names.
@Anomie: Please correct me if I'm wrong about this. Jc86035 (talk) 14:10, 6 July 2018 (UTC)
Yup, it's probably much simpler to do with LUA, but for a proof on concept, it's much easier to spend 10-20 hours fiddling with stuff and abusing CSS like crazy than spend months to learning LUA so I can get to a point that I'm sort of able to hello world my way out of a paper bag. Headbomb {t · c · p · b} 16:07, 6 July 2018 (UTC)

How do I edit sanitized-css stylesheets?

I've made a version of the {{clade}} template to use TemplateStyles, using the {{cladeN}} template. It mostly went smoothly with testing using my custom.css. I copied the working css to a style subpage {{cladeN/styles.css}} before templatestyles was enabled earlier today. This more or less worked as expected. However, since TemplateStyles was enabled I can't edit the style sheet further. The message is You cannot edit this revision because its content model is sanitized-css, which differs from the current content model of the page wikitext. I assume this is a privileges issue, but it gives no further information.   Jts1882 | talk  16:30, 19 July 2018 (UTC)

This might be Special:ChangeContentModel but I don't know what to change it to. Clearly the default syntax highlighting doesn't recognise sanitised CSS. --Redrose64 🌹 (talk) 20:00, 19 July 2018 (UTC)
According to WP:TSTYLE#Tips, they use the sanitized-css content model. Since the page was created before the TemplateStyles extension was enabled, it was created as wikitext content model, so an admin would need to change it. See also: mw:Content handlers. — AfroThundr (u · t · c) 22:39, 19 July 2018 (UTC)
I fixed it for you. Apparently MediaWiki gets a bit confused if the default content model of a page changes, I had to change it to something else then back to Sanitized CSS. I think some upcoming work for multi-content revisions will fix that behavior, eventually. Anomie⚔ 00:58, 20 July 2018 (UTC)

Tree list

FYI, I recently converted {{Tree list}} and was able to remove it's styling from MediaWiki:common.css, as well as making two of its' subtemplates: {{Tree list/final branch}} and {{Tree list/final branching}} unnecessary. Progress baby... —TheDJ (talk • contribs) 08:21, 26 July 2018 (UTC)

A simple test case: Talk quote inline

I've made a simple test conversion of Template:Talk quote inline (aka {{tq}}). I have a thought or two--maybe someone will disagree.

We should probably use semantic naming for our classes where possible. "talk", "talk2", and "talk3" are not very semantic. Which leads to a question: What should one do when there are already existing classes, not named well, which might be used by various and sundry people to style this template already (basically, what to do with old class names)? I would prefer not to retain, or even leave for deprecation in any significant period for a simple template such as this one, the old class name. I'd also not like to have to bug an (technical) administrator to make the changes for me.

A second question: In the above case, I have all of the styles in one sheet. Some however will not be used in a single invocation (italic and sans-serif, in particular). Does that mean that there should be more than one styles page? It seems from the above discussion I can invoke as many templatestyles invocations as I please (and maybe I might please to put them inside the conditional expressions... is that verboten? :). Or, if the particular class doesn't appear on the page, I've now shipped some CSS not needed for that page (which is minimal, but it would not have happened prior even though every infovocation in the end-HTML would have gotten it, so that of course would be larger than the CSS). Thoughts appreciated. (Maybe these are cached on the user side and it's mostly a non-issue?) --Izno (talk) 22:53, 25 July 2018 (UTC)

On the first question, I'd be very much in favour of semantic names for the classes, such as inline-quote-italic instead of inline-quote-talk2, etc. I'm pretty sure that I'd simply replace the previous names with better names in the template and its TemplateStyles stylesheet if existing class names are poor. Then the older names would simply be unused and somebody would eventually remove them from common.css (if that's where they are). The only chance of affecting anybody else is if they use the old class names in their user css to provide overrides. I guess an insource search for definitions of the old class names within userspace should turn up any. Then it would be just a matter of leaving a note to the user that they need to update their user.css. --RexxS (talk) 00:16, 26 July 2018 (UTC)
A non-specific followup: should the template emit both a talk-quote-inline and a talk-quote-italic? So someone can target the whole template? --Izno (talk) 00:57, 26 July 2018 (UTC)
That would make sense if you wanted users to be able to target the entire thing with their own CSS. There isn't any specific reason I can think of why you couldn't just add the class even if you weren't currently using it. If the names are unique (properly namespaced) the extra class wouldn't affect anything. — AfroThundr (u · t · c) 04:54, 26 July 2018 (UTC)
Please, also remember that bots (on wmflabs) and scrapers might have expectations with regard to the presence of certain classes. So i'd take significantly extra care with templates that are part of processes etc. —TheDJ (talk • contribs) 08:28, 26 July 2018 (UTC)

Idiot's question: substing

What happens when I subst a template with a template style invocation? None of the docs pages I looked at indicated that anything different should happen (all were silent on the matter, in fact), in which case I would expect the template style sheet tag to be added to the page on which the template is being substituted.

Is that the case? --Izno (talk) 15:45, 25 July 2018 (UTC)

@Izno: Here's what I get when I {{subst:thermometer}}:
The source of the styles is still there in the <templatestyles /> tag. The thermometer renders correctly, so the styles are applied. That can be checked by using the browser inspector. --RexxS (talk) 15:56, 25 July 2018 (UTC)
Should templates with template styles be substed? If a different question: should templates meant to be substed use template styles? Do the styles load once with each invocation or once per page when there are multiple tags pointing to one place? --Izno (talk) 16:06, 25 July 2018 (UTC)
The problem with all of this is that the classes "leak out" onto the page, which means we need to pick unique class names, otherwise we can get all sorts of unexpected interactions. --RexxS (talk) 16:10, 25 July 2018 (UTC)
Text inside a div
The div has a class name matching one used in a TemplateStyles tag on the page.
It doesn't make any difference as far as I can see. The classes will be available to the rest of the page content whether we subst or not. I would expect each invocation to call the stylesheet, as I can't see any reason why it wouldn't. Should be easy enough to test. --RexxS (talk) 16:10, 25 July 2018 (UTC)
First calling {{Thermometer/sandbox1}}: The sandbox version has blue fill, and because it uses the same class names, it overrides the red in the original.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Then calling {{Thermometer}}: Contrary to my expectation, calling the original template once more does not restore the red colour. I infer then that subsequent template invocations do not reload the original style sheet. You can confirm that subst: makes no difference by previewing the section with the templates subst'ed. --RexxS (talk) 16:24, 25 July 2018 (UTC)
Do the styles load once with each invocation or once per page when there are multiple tags pointing to one place – once per page, per mw:Help:TemplateStyles#In_which_order_do_CSS_styles_override?
we need to pick unique class names, otherwise we can get all sorts of unexpected interactions – yes, hence the third bullet point of these guidelines. - Evad37 [talk] 16:31, 25 July 2018 (UTC)
There is a stray blue thermometer bulb on the page.
The example is calling two different templates, each inserting an inline stylesheet. Calling the red one again doesn't restore the red as it uses the earlier inline style and the sandbox style with the blue is later in the page.
It does demonstrate the importance of unique class names.   Jts1882 | talk  16:44, 25 July 2018 (UTC)
The "stray" bulb is deliberate (I've just made that clearer). It demonstrates what happens when you use a class name on a div that is the same as one used in a templatestyles stylesheet. "Calling the red one again doesn't restore the red as it uses the earlier inline style and the sandbox style with the blue is later in the page." There are no inline styles here. If you subst the templates you get exactly the same effect. That would show that even though the second call to Template:Thermometer/styles.css (red) is later in the page than the first call to Template:Thermometer/sandbox1/styles.css (blue), the software does not load the first (red) stylesheet again, as you might expect that it would for cascading style sheets. Cheers --RexxS (talk) 19:45, 25 July 2018 (UTC)
It's safe to subst templates using TemplateStyles, you'll just get the <templatestyles /> in the wikitext. Note there's no way to "subst" the current version of the stylesheet, much like you can't "subst" a specific version of an image.

Substed or non-substed, either way multiple uses of the same stylesheet are deduplicated.

We probably should avoid having substed templates litter the wikitext with <templatestyles />, much like how we avoid littering it with {{#if:}} and other complicated unreadable stuff. Anomie⚔ 18:14, 25 July 2018 (UTC)

Agreed. We probably ought to give the advice not to bother converting to TemplateStyles any templates that are routinely subst'd. --RexxS (talk) 19:48, 25 July 2018 (UTC)
@RexxS: the classes "leak out" onto the page, which means we need to pick unique class names, otherwise we can get all sorts of unexpected interactions - this is what I was afraid of, see my two comments at Wikipedia:Village pump (technical)/Archive 166#If allowed - default protection?. --Redrose64 🌹 (talk) 20:19, 25 July 2018 (UTC)
The vandalism issues probably dictate that a TemplateStyles stylesheet needs to have the same protection level as the template where it is used (which has implications if a stylesheet gets used for more than one template). It is imperative that class names are chosen to be unique to a template, as the above demonstrates. Do you think that we can make any improvements to the guidelines to reinforce those points? --RexxS (talk) 20:29, 25 July 2018 (UTC)
there's no way to "subst" the current version of the stylesheet I'm okay with that given all the discussion about 'in-page' styles that I know has been had.
Substed or non-substed, either way multiple uses of the same stylesheet are deduplicated. Good
We probably should avoid having substed templates litter the wikitext with <templatestyles /> I wonder how often this happens. I know there are a few templates which set "this template must be substed" and then a bot goes around and substs them (that's yours!). And, I wonder how many times these templates have styling. Let's see if we can find that out before we ban template styles in substed templates? It seems like we lose out on templatestyles otherwise just for this class of template. --Izno (talk) 23:17, 25 July 2018 (UTC)
A template that's been subst'd is no longer a template of any kind. --RexxS (talk) 23:51, 25 July 2018 (UTC)
Which is entirely irrelevant? --Izno (talk) 00:04, 26 July 2018 (UTC)
You might as well say that we're missing out on using the <templatestyles /> tag directly to style pages, and then calling that a "class of template" with just the tag in it. --RexxS (talk) 00:28, 26 July 2018 (UTC)
... We are? :) (There are explicit plans to mark up Main page using template styles.) But, most subst-only things are talk page templates I think with a few templates like the German infoboxes scattered around (and we obviously wouldn't add template styles to those templates because we prefer our templates). Either way, that's why I wanted to survey what we have today to see what we lose/gain. It's a basic decision analysis. --Izno (talk) 00:45, 26 July 2018 (UTC)
(I agree generally we should avoid having templatestyles invoked in mainspace [chaos], but I've also seen plans to use them so that we can mark many things up better than we do today e.g. our table stylings across the board. Best we start talking about that--maybe in a separate thread. --Izno (talk) 00:52, 26 July 2018 (UTC))

Another point comes to light. Because a /sandbox page shares the documentation with the main template, you can't use {{Uses TemplateStyles}} to point to a different "sandbox" version of the stylesheet for testing changes to the stylesheet. To avoid confusion, I've now shifted to Template:Thermometer/sandbox1, Template:Thermometer/sandbox1/styles.css and Template:Thermometer/sandbox1/doc to use when testing changes to the styles. --RexxS (talk) 20:55, 25 July 2018 (UTC)

I think Template:Example/styles.css and Template:Example/sandbox/styles.css are reasonable/fine. --Izno (talk) 23:17, 25 July 2018 (UTC)
I think the latter is neither reasonable nor fine for testing changes to styles. The documentation for Template:Example/sandbox will state that it's using Template:Example/styles.css, but it won't. It will be using Template:Example/sandbox/styles.css if you want to test changes to styles. What's the point in having documentation that's wrong? Just use sandbox1 and the problem goes away. --RexxS (talk) 23:48, 25 July 2018 (UTC)
So fix the documenting templates? --Izno (talk) 00:04, 26 July 2018 (UTC)
I'd be interested to hear how that would be done. --RexxS (talk) 00:21, 26 July 2018 (UTC)
Get the name of the template css pages in the module and insert a /sandbox/, then provide that in the use templatestyles box? IMO it would be preferable either way to link these things at the bottom of {{documentation}} with all the other standard subpages. (Categorize if you want since I don't think {{documentation}} does that today.) --Izno (talk) 00:42, 26 July 2018 (UTC)
{{Uses TemplateStyles}} just adds a normal wikitext link to the styles... it doesn't stop you using a sandbox version of the styles in the template's sandbox. - Evad37 [talk] 01:10, 26 July 2018 (UTC)
The real problem is that testcases for changes to styles will have to be on separate pages. - Evad37 [talk] 01:13, 26 July 2018 (UTC)
Yes this is an interesting issue that I don't think any of us really considered so far... —TheDJ (talk • contribs) 08:22, 26 July 2018 (UTC)
@Evad37: I don't know how many times I have to explain this, but the /sandbox uses the documentation page for the main template, not a separate one. You only get to use {{Uses TemplateStyles}} once for both templates. So which .../styles.css do you target in {{Uses TemplateStyles}}? the one for the main template or the one for the sandbox? Whichever one you pick, it will be right for one of those templates and wrong for the other. --RexxS (talk) 10:44, 26 July 2018 (UTC)
Please don't get exasperated. I replied to you above (00:42, 26 July 2018 (UTC)) regarding what could/should be done. --Izno (talk) 16:53, 26 July 2018 (UTC)
Sorry I misunderstand before. I've changed {{Uses TemplateStyles}} so that if the sandbox version exists (as a subpage of /sandbox/), it will be included in brackets after the main link. See the box above the documentation at Template:Uses TemplateStyles for an example. - Evad37 [talk] 17:06, 26 July 2018 (UTC)
The other thing you could do is have some page name logic for the page transcluding the doc, e.g. with {{when on basepage}} - Evad37 [talk]
I filed phab:T200441 to see if there is a reasonable technical solution. --Izno (talk) 16:53, 26 July 2018 (UTC)

@RexxS, TheDJ, Evad37, and Izno: Should text like "Do not use TemplateStyles in a template that should be substituted; in templates with TemplateStyles, use Module:Unsubst or Module:Unsubst-infobox to prevent accidental substitution" be added to the guideline? Jc86035 (talk) 10:54, 26 July 2018 (UTC)

I think recommending use of Module:Unsubst or Module:Unsubst-infobox is going too far. Use those modules on templates that people tend to incorrectly subst, but don't worry about the majority where no one tries to subst them. Anomie⚔ 12:05, 26 July 2018 (UTC)
[2] was premature--especially since Substituting a template which uses TemplateStyles leaves the <templatestyles /> tag in the resulting code, which may negate many of the benefits of using TemplateStyles in the first place. strikes me as wrong. What is the benefit which is being negated? As for confusion, I admit it may be confusing in wikitext but that doesn't strike me as some overriding concern, even given the discussion above. Lastly, no-one responded to "what templates would be affected if we banned templatestyles in substed templates?", above. --Izno (talk) 16:53, 26 July 2018 (UTC)

TemplateStyles in Modules

Hello. I am trying to add templateStyles CSS in a module I am working on in the sandbox (Module:Sandbox/Ita140188/chart2). Is there any way to test the module with a sanitized-CSS without creating subpages of Template:Template sandbox or similar? I tried with User:Ita140188/sandbox/styles.css but of course it would not work ("Page User:Ita140188/sandbox/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "CSS")."). Is there a way to make an exception for specific pages? Thank you. --Ita140188 (talk) 05:36, 30 July 2018 (UTC)

An admin can set the content model for a particular page. I don't know whether there would be any further problems. Please post the final result here. Johnuniq (talk) 05:53, 30 July 2018 (UTC)
What's the problem with having them in subpages? That's what we do for Modules with Module:Sandbox - Evad37 [talk] 05:57, 30 July 2018 (UTC)
@Evad37: I have no problems with subpages. However, it seems I cannot create a CSS page under Module namespace (it is interpreted as a Lua script), CSS pages under User namespace are not sanitized, and I cannot create CSS pages in template namespace per WP:G2. So where should I create this subpage? --Ita140188 (talk) 06:02, 30 July 2018 (UTC)
@Ita140188: I just created Template:TemplateStyles sandbox as a pseudo-namespace for TemplateStyle sandboxes, operating much like Module:Sandbox. - Evad37 [talk] 06:12, 30 July 2018 (UTC)
@Evad37: It works! Thanks! --Ita140188 (talk) 06:51, 30 July 2018 (UTC)

CSS / HTML / TemplateStyles experts at Help talk:Citation Style 1#CSS for citation templates please?

We need help figuring out a couple of details here. Any help would be appreciated. In particular, we're trying to a apply a class to them that lets access locks be treated as external links icons, which can be displayed/hidden independently of other external link icons. Headbomb {t · c · p · b} 22:47, 30 July 2018 (UTC)

hlist

Should hlist be a template style? If so, where should it live? --Izno (talk) 21:25, 30 May 2018 (UTC)

I don't think it currently can be, it's too widely spread. Better focus on easier stuff first. —TheDJ (talk • contribs) 13:24, 18 June 2018 (UTC)
@TheDJ: Mobile currently needs class="hlist-separated" anyway because someone decided to re-use hlist for something in the Minerva interface, so it wouldn't hurt. Jc86035 (talk) 14:23, 18 June 2018 (UTC)
Yeah, that was my thought. Just figured I'd throw the question out. :) --Izno (talk) 21:51, 18 June 2018 (UTC)
@TheDJ: Putting the hlist styles into their own CSS page might fix some display problems with applications which don't load MediaWiki:Common.css, like Dictionary.app. I created {{Arrowlist}} for one specific navbox, and the "arrow lists" appear perfectly fine in Dictionary.app whereas the lists with hlist class are only displayed as regular bulleted lists. Jc86035 (talk) 18:55, 31 July 2018 (UTC)

Wikipedia:Village pump (technical)/Archive 166#Weird behaviour at Afd

I believe TemplateStyles could be used here to fix this issue. Basically, if using MiniveraNeue, make the {{AFD help}} box have a 100% width. I lack the skills to do this however. Headbomb {t · c · p · b} 19:40, 2 August 2018 (UTC)

@TheDJ: might be able to help here.Headbomb {t · c · p · b} 19:41, 2 August 2018 (UTC)

In the context of meta templates

Right now Template:Infobox, Template:Navbox, and Template:Sidebar all allow custom styles (usually with multiple parameters). What approach should we take for template styles here?

My inclination is to add a parameter to each (|template style= or similar using frame:extensionTag) with the name of the TemplateStyles page. This would also allow us to track those templates where |style= is still used for conversion. Such a parameter would also allow us to track color combinations for accessibility.

The immediate alternative is that we just use a normal invocation on each template page, but I'm not really in favor of that one.

Thoughts? --Izno (talk) 01:35, 27 July 2018 (UTC)

Arguably related: Template_talk:Infobox#Width?. Chicbyaccident (talk) 11:51, 3 August 2018 (UTC)

Sandbox naming convention

What should the sandbox version of a TemplateStyles page be named? This affects the way Module:Uses TemplateStyles looks for such a sandbox page.

  • Template:Example/styles.css and Template:Example/sandbox/styles.css, which came up in discussion § Idiot's question: substing above
  • Template:Example/styles.css and Template:Example/styles.css/sandbox, which is what this change to the module would suggest
  • Template:Example/styles.css and Template:Example/styles.css/sandbox.css – similar to above, but would allow for creation with sanitized-css content model for non-admins

Or something else? - Evad37 [talk] 01:55, 30 July 2018 (UTC)

Template:Example/styles.css/sandbox seems best to me, for consistency with all other sandboxes of subpages, which follow the name pattern "Template:foo/subpagename/sandbox", not Template:foo/sandbox/subpagename". Inability to create directly isn't a problem; non-admins can just do what I did with a move. {{3x|p}}ery (talk) 02:05, 30 July 2018 (UTC)
Extra work for no observable reason. The fact that it is a sandbox style page is quite apparent with the /sandbox/styles.css variant. --Izno (talk) 02:14, 30 July 2018 (UTC)
Having CSS pages not deviate from the standard sandbox naming convention totally is an "observable reason". {{3x|p}}ery (talk) 02:16, 30 July 2018 (UTC)
Having CSS pages not deviate from the standard CSS pages naming convention, as described in mw:Help:TemplateStyles #Usage, seems like a good reason to have pages that end in ".css". I'm unconvinced that a sandbox page has to end in "sandbox". --RexxS (talk) 08:18, 30 July 2018 (UTC)
There is indeed more than one possibility, determined by context. Consider these two questions: (i) what is it a sandbox of? (ii) what is this stylesheet intended to affect? Imagine we have an existing template, Template:Example; that template has a stylesheet at Template:Example/styles.css but it also has a sandbox, Template:Example/sandbox. The page that we are trying to decide a name for might be the sandbox for Template:Example/styles.css which would make its name Template:Example/styles.css/sandbox. Or, the page might contain the stylesheet for Template:Example/sandbox which would make its name Template:Example/sandbox/styles.css. So it comes down to: what are we intending to demonstrate/test. --Redrose64 🌹 (talk) 08:39, 30 July 2018 (UTC)
I'll have to disagree with the possibility of two contexts. A sandbox for Template:Example/styles.css is unusable per se, because Template:Example does not point to it. Any sandbox version of Template:Example/styles.css is necessarily also the stylesheet for Template:Example/sandbox, which would be the template that points to it. Template:Example/sandbox/styles.css seems the right choice to me. --RexxS (talk) 09:07, 30 July 2018 (UTC)
By the same fallacious argument, a sandbox for {{db-multiple/item}} is unusable because {{db-multiple}} does not point to it. But that clearly isn't true -- I even personally used that sandbox for a deduplication of the code of {{db-multiple}}. Again, I'm failing to see why TemplateStyles CSS is special here. Presumably, {{db-multiple/item/sandbox}} could also be interpreted as the /item subpage of {{db-multiple/sandbox}}, creating the same dicontextual dilemma. But yet the /sandbox part has found itself at the end, so the same convention should apply to TemplateStyles CSS {{3x|p}}ery (talk) 13:59, 30 July 2018 (UTC)
There's nothing fallacious about the argument. Your analogy is faulty because the template Template:Db-multiple/sandbox calls Template:Db-multiple/item/sandbox, which is where you tested your changes (and could view the results in Template:Db-multiple/sandbox). Unless you create a template to see the effects of changes to a stylesheet, you can't test the changes.
The template Template:Example contains a tag <templatestyles src="Example/styles.css"/>, which "pairs together" the template and its associated stylesheet. If you want to test changes to the stylesheet in a stylesheet-sandbox, you need a corresponding template that is paired with the stylesheet-sandbox, because the changes won't show up in Template:Example. In what template are you going to put the modified <templatestyles /> tag that links to the stylesheet-sandbox?
There is no "second context" where you can test the effects of changes to a stylesheet-sandbox without having a paired template-sandbox to display the effects.
Templates and stylesheets go in linked pairs, so it's obvious that we would use Template:Example/sandbox and its associated stylesheet Template:Example/sandbox/styles.css.
There is no obvious template that should pair with Template:Example/styles.css/sandbox, which is why it's a poor choice of name. --RexxS (talk) 14:34, 30 July 2018 (UTC)
On purely technical grounds, I wouldn't like .../styles.css/sandbox because of the content model issue, and I have no idea why anyone should have to go around the issue since this isn't reader facing. Stylesheet sandboxes can be tested in tandem with the template sandbox or with the user's web browser's inspector utility. .../sandbox/styles.css makes more sense to me than .../styles.css/sandbox.css because in order to test this hypothetical TemplateStyles sandbox the sandbox template would have to be used. Personally, for {{Routemap}} I used a copy on the German Wikipedia as the sandbox before TemplateStyles was enabled here. Jc86035 (talk) 15:24, 30 July 2018 (UTC)
That just makes no sense. TemplateStyles is not special here in any way that I'm understanding -- there's no technichal reason why the MediaWiki developers couldn't have coded it so that instead of typing <templatestyles src="Foo.css" /> to add a CSS page, you could just add them like you do regular templates, as {{foo.css}} (note: I'm not endorsing this hypothetical as it would be confusing, just presenting it for the sake of argument), which would make it literally the same as my {{db-multiple/item}} case above.
Let's take another example of a non-standard type of page: module /datas. All of your arguments seem to apply there:
  1. Module:Good article topics (arbitrarily chosen) includes mw.loadData("Module:Good article topics/data") which "pairs together" that module and its data page. Testing changes to the /data page requires a corresponding paired module.
  2. There is no "second context" where you can test the effects of change to a datapage-sandbox without having a paired module-sandbox to mw.loadData it.
  3. Modules and datapages go in linked pairs, so according to you it's obvious that we would use Module:Good article topics/sandbox/data
  4. There is no more reason for Module:Good article topics/sandbox to go with Module:Good article topics/data/sandbox than there is for Template:Example/sandbox to go with Template:Example/styles.css/sandbox
and yet, despite all of this, Module:Good article topics/data/sandbox is not called Module:Good article topics/sandbox/data, as it should be. TemplateStyles should be exactly the same. {{3x|p}}ery (talk) 20:38, 30 July 2018 (UTC)
Good. So we agree then that when a template and its stylesheet are paired, testing changes to the stylesheet requires a pair of sandboxes: a template-sandbox and a stylesheet-sandbox. You agree then that you can't have a stylesheet-sandbox without having a template-sandbox. We agree so far. That means that Redroses's two possibilities reduce to one, because the sandbox of the stylesheet is indistinguishable from the stylesheet of the sandbox. Have you accepted that yet?
There is no doubt that the template is named Template:Example and its template-sandbox is named Template:Example/sandbox.
There is no doubt that the stylesheet is named Template:Example/styles.css. I assume all of that is common ground.
Now that we've agreed there are not two different possibilities for the stylesheet-sandbox/sandbox-stylesheet because they are necessarily the same thing, that returns us to the original question: how to choose between Template:Example/styles.css/sandbox and Template:Example/sandbox/styles.css?
In favour of Template:Example/sandbox/styles.css are that:
  1. we seem to append "/styles.css" to any template to create its stylesheet.
  2. there are recommendations at mw:Help:TemplateStyles #How does it work? that state "The recommended usage pattern is to store the styles for Template:Foo under a subpage like Template:Foo/styles.css" and at Wikipedia:TemplateStyles that state "In general, this means that a style page should be a subpage of the related template".
  3. creating pages that end in ".css" fits with the requirement at mw:Help:TemplateStyles #How does it work? that stylesheet pages "must have the sanitized-css (Sanitized CSS) content model, which is the default for subpages in the Template namespace that end with .css" and technical advantage that we automatically get a sanitized-css page if we end it in ".css".
In favour of Template:Example/styles.css/sandbox is that we normally append "/sandbox" to a template to create a sandbox for testing. However, I'm not aware of any documentation that indicates that, nor any technical advantage in using that scheme.
Have I missed anything out of that summary? --RexxS (talk) 22:17, 30 July 2018 (UTC)
We do seem to be agreeing over the facts, but not over the reasons. The whole "styles of sandbox vs. sandbox of stylesheet" business also applies to module data pages, where it is debunked by actual practice, and therefore holds no water. Next comes the guidelines, which I think you're misinterpreting/applying too strictly, as it is a (future/experimental) stylesheet for Template:Example, which it is a subpage of. The only argument left after that is the technichal one about contentmodel, which I have no refutation for but think is trumped by standard naming conventions (which you disagree with) and in any case leaves the "/sandbox.css" option open. {{3x|p}}ery (talk) 22:39, 30 July 2018 (UTC)
There are 25 cs1|2 templates and each of those has a sandbox. Because all of the live templates use Module:Citation/CS1 I have created Module:Citation/CS1/styles.css. I would like to have a sandbox of that for use with the sandbox templates that all use Module:Citation/CS1/sandbox. I had thought to create Module:Citation/CS1/styles-sandbox.css so that the name kept .css at the end and the name also reflected its status as a sandbox style sheet but I could be just as happy with Module:Citation/CS1/sandbox/styles.css.
—Trappist the monk (talk) 13:11, 3 August 2018 (UTC)

I'm going to poke this a bit: I see 5 or 6 heads who all agree that the page should end with .css, to Pppery's 1 without. Of the larger group, I see a general consensus for /sandbox/styles.css. Do we actually need to go to some sort of technical RFC or should we call that consensus? --Izno (talk) 18:21, 5 August 2018 (UTC)

I too, support the myTemplate/sandbox/styles.css convention, per the points in RexxS's summary above. It seems to make the most sense and clearly links the two, without raising the problems that myTemplate/styles.css/sandbox would. — AfroThundr (u · t · c) 02:23, 6 August 2018 (UTC)

Adopt MediaWiki coding convention for CSS

Would it be valuable to adopt the CSS coding convention for MediaWiki? In part or in whole? --Izno (talk) 20:00, 9 August 2018 (UTC)

@Izno: in general its a good idea, but we shouldn't beat anyone (or edit war) over things like whitespace. — xaosflux Talk 20:23, 9 August 2018 (UTC)
I'm trying to preempt the edit wars. ;) --Izno (talk) 20:36, 9 August 2018 (UTC)
I can go with all of the whitespace conventions except the one about indenting declarations with tabs. If I press the tab key in the edit window, I'm taken to the edit summary window. I normally use two spaces for this indent. --Redrose64 🌹 (talk) 21:33, 9 August 2018 (UTC)
CodeEditor seems to provide a tab for you, so I'm not sure that's too much of an issue. --Izno (talk) 01:49, 10 August 2018 (UTC)
I'm fine with all of those coding conventions. They are pretty commonly used anyway, so shouldn't be much of a problem in adopting in toto: spacing, naming, capitalisation, annotation, layout. I do agree that these sort of guidelines just aren't worth edit-warring over, but are worth encouraging folks to use. I prefer tabs to spaces, but I tend to use an external editor most of the time. --RexxS (talk) 23:10, 9 August 2018 (UTC)
The one I wasn't sure about was the naming prefixes. mw- and ext- are not appropriate in our case, I think. --Izno (talk) 01:49, 10 August 2018 (UTC)
Indeed. I was assuming that we'd want follow the principle of using prefixes, but we'd use something derived from the associated template (like person- in Template:Infobox person/styles.css). --RexxS (talk) 12:23, 10 August 2018 (UTC)
Please see Template talk:Gallery##mobile: Please drop usage of inline styles - use TemplateStyles since Template:Gallery/styles.css is absolutely stuffed with !important. --Redrose64 🌹 (talk) 07:02, 11 August 2018 (UTC)

Experiment with article-space: tables

I recently created Template:American Open Wheel driver results legend/styles.css for Template:American Open Wheel driver results legend. The way I structured the CSS, it also allowed me to make this edit. Who feels good/bad with this? Should we generally enable this kind of replacement for tables with legends (or tables generally)? (I note the existence of phab:T176272 for this particular question.) --Izno (talk) 18:16, 5 August 2018 (UTC)

Where are those classes like gold, silver, topten etc. defined? --Redrose64 🌹 (talk) 18:57, 5 August 2018 (UTC)
I wonder if that's a serious or a rhetorical question--if the former, in the styles.css page for the legend. --Izno (talk) 19:04, 5 August 2018 (UTC)
That has selectors like table.aow-driver-results tr td.gold - why was it not possible to use table.aow-driver-results tr td.aow-gold etc.? See Wikipedia:TemplateStyles#Guidelines third bullet. --Redrose64 🌹 (talk) 19:12, 5 August 2018 (UTC)
The first selector "table.aow-driver-results" makes the latter selector "td.gold" only apply within the specific table, so doing that is unnecessary. (this is basically doing "use .myTemplate tr rather than tr") Galobtter (pingó mió) 19:25, 5 August 2018 (UTC)
Not per se unnecessary, just unlikely that I would have a collision with another template so long as the CSS related to the gold or silver class in the other template also takes good practice into account (i.e., .mytemplate-gold for any old class or table.mytemplate tr td.gold for another table, etc.). --Izno (talk) 19:51, 5 August 2018 (UTC)
(edit conflict) @Izno: It looks like a perfectly good use of the functionality to me, even if it was not intended by the developers. Obviously you have to have the templatestyles tag somewhere on the page, but I assume that the table will always co-exist with the legend template, so that is taken care of. Should the functionality of the tag be constrained to its template at some point in the future (i.e. no "leakage" onto the rest of the page), then you could create a template to hold both the table and the legend and apply templatestyles to that. I see no downside to what you've done.
@Redrose64: Since the classes "gold", "silver", etc. are selected only when inside a table whose class is set to aow-driver-results, I think that satisfies the reasoning behind "Use selectors and class names that are highly likely to be unique to the style page." There's certainly no problem with using the longer classnames for the table cells that you suggest, but I don't think it would yield any increase in specificity in practice. The shorter names would be more intuitive for other editors to pick up and use, so there is some advantage in using Izno's convention. --RexxS (talk) 19:32, 5 August 2018 (UTC)
Indeed. --Izno (talk) 19:51, 5 August 2018 (UTC)
Tgr on Phab indicates that, because of the placement of the template relative to the table, we might have a flash of unstyled content. --Izno (talk) 19:53, 5 August 2018 (UTC)
That's a possibility in some cases, but in 2014 Florida Winter Series (and presumably in similar articles), the table is "below the fold" by default on anything less than a 4K monitor, so that's nothing I'd worry about. --RexxS (talk) 20:36, 5 August 2018 (UTC)
Does the response here mean the following bullet is still consensus?

The style must apply only to the associated template's output. It would be confusing if adding a template to one part of a page were to completely or partially change the display or styling of an unrelated part of the page.

--Izno (talk) 16:17, 13 August 2018 (UTC)
I think in general, yes – e.g. adding a template in the middle of an article shouldn't affect how unrelated sections (e.g. the references at the bottom) are styled. Guidelines do allow for occasional, common sense exceptions, which I think would include a template that builds part of a table applying styles to the whole table, as might also be the case for foo-start and foo-end templates styling the wikitext in-between them. - Evad37 [talk] 02:04, 14 August 2018 (UTC)

Template:User OS:Dos/style.css

Something needs to be done about this stylesheet: it's misused across like ten or so different templates as a generic means of implementing blinking text. {{3x|p}}ery (talk) 22:59, 4 March 2019 (UTC)

@Pppery: like what? And why is this an issue? Looks to all be userspace stuff. — xaosflux Talk 23:33, 4 March 2019 (UTC)
There's very few transclusions outside of User and User_talk namespaces, where it seems to generally be used for a single blinking character in userboxes like Template:User OS:Dos. Perhaps it should just have a tracking category for usage outside of these namespaces in a css comment. - Evad37 [talk] 23:41, 4 March 2019 (UTC)
I don't think that's possible. {{3x|p}}ery (talk) 23:45, 4 March 2019 (UTC)
I would nominate it for deletion. Blinking text is not accessible. --Izno (talk) 03:37, 5 March 2019 (UTC)
@Izno: In the template's original usecase, the "blinking text" is just an underscore, mimicking the flashing cursor of a command prompt. That doesn't seem like a massive accessibility violation. {{3x|p}}ery (talk) 03:48, 5 March 2019 (UTC)
Oh, that's not that bad. You just added some text to the page today about templates working. Why do you not think a {{main other}} would work (I don't think that's possible.)? --Izno (talk) 03:54, 5 March 2019 (UTC)
@Izno: My understanding is that CSS pages are only parsed as wikitext on the CSS page itself, and not on pages that include it. That is adding /* [[Category:Foo]] */ to a CSS page will add the CSS page itself to Category:Foo, but not any pages that use the stylesheet. {{3x|p}}ery (talk) 04:01, 5 March 2019 (UTC)
Have you tried it? :D --Izno (talk) 04:02, 5 March 2019 (UTC)
Yes, otherwise all pages using citation templates would show up in Category:Wikipedia pages with incorrect protection templates. {{3x|p}}ery (talk) 04:06, 5 March 2019 (UTC)

I recommend, if no one else comments, creating a {{blinking cursor}} and converting all the uses for a blinking cursor to that template, while removing the blinking from any templates that use it for something other than a cursor. Template:Statustop is one example of the latter. @Izno, Evad37, and Xaosflux: Any comments? {{3x|p}}ery (talk) 04:14, 5 March 2019 (UTC)

Seems like overkill, however if you want to improve Statustop to its own template style go right ahead. — xaosflux Talk 06:02, 5 March 2019 (UTC)

Issue with style being applied to other, unrelated code

I have an issue. In Template:Awards table5/styles/sandbox.css I was trying to make the text in the last column be centered, but a user reported that the style is leaking to other tables on the page. I then used edited Template:Awards table5/styles.css to use ".awards-table-5", but that just made the code not work anymore. Any idea on how to make it work and not leak? --Gonnym (talk) 09:49, 12 August 2019 (UTC)

Shouldn't it be "table.awards-table-5"?   Jts1882 | talk  10:20, 12 August 2019 (UTC)
Rather, you could just get rid of table. However, this will not always work. td:last-child will always select the last td element in every row, so if the table contains a combined ref cell (with rowspan), the style can spill over to other columns. But since {{won}}/{{nom}}/etc are centered anyway, one way to prevent it is to never use rowspan for a cell in the Results column (which is the recommended way anyway). Nardog (talk) 10:54, 12 August 2019 (UTC)
Thank you both. --Gonnym (talk) 11:40, 12 August 2019 (UTC)
For anyone reading this later, the trick to making ".awards-table-5" work was adding that class to the template as in Special:Diff/910479092 or Special:Diff/910483702. Anomie⚔ 11:44, 12 August 2019 (UTC)

Substed templates r2

So, I did some hunting/poking. For templates which are regularly substed, we can make it so the templatestyles tag is not substed along with the rest of the template. This came up in the context of Template talk:Allcaps where I noted a solution like Template:Smallcaps would work.

I'd like to change the guidance accordingly.

The one question I have is whether, when substing, we should output an inline-styled version (as in that version) or a style-less version. My preference is for the style-less version. Opinions are welcome. --Izno (talk) 17:48, 8 October 2019 (UTC)

I made an edit. --Izno (talk) 03:42, 15 November 2019 (UTC)

initial and unset

Why does the code editor warn against using initial or unset? Nardog (talk) 19:36, 23 February 2020 (UTC)

Nardog, the linter in the code editor is rather old, it needs to be updated. —TheDJ (talk • contribs) 09:45, 24 February 2020 (UTC)
Both of these keywords are intended to be introduced as part of CSS Cascading and Inheritance Level 3 which is still at the W3C Candidate Recommendation stage, so browser vendors are not obliged to support them. --Redrose64 🌹 (talk) 18:15, 24 February 2020 (UTC)

Solved. Need help making a 2nd header row sticky in a table using TemplateStyles

The table is using the same styles.css page as the above discussion. See discussions:

Mfb found a partial solution by shortening the header names, and putting the sorting icons back with the header names. See:

But there will be a need for a sticky sorting row in other partially collapsed tables.

Solved. See discussion here:

And see partially closed table with sticky sorting row here:

--Timeshifter (talk) 03:32, 29 October 2020 (UTC)

Group of users interested in changes to CSS

Watchers of this page may be interested in Wikipedia talk:Manual of Style/Accessibility § Group of users interested in changes to CSS. Izno (talk) 22:07, 20 December 2020 (UTC)

Solved. Need help with multiple templated tables on the same page using the same styles.css

Quantocius Quantotius provided some wikitext to add a collapse button to all the 3 partially closed tables at the top of this article:

Wikitext for "Show all" button:

<div class="covid-show-table" style="font-size:80%;font-weight:500;">[[#covid19-container|[show all]]]</div>

Wikitext for "Collapse" button:

<div class="covid-collapse-table" style="font-size:80%;font-weight:500;float: right;">[[#top|[collapse]]]</div>

The 3 table templates:

The "Show all" and "Collapse" buttons work on the separate template pages.

But the buttons only work on whatever is the top table in the article itself. If I click "Show all" on the bottom 2 tables they only open up the top table. The collapse button only shows up on the top table.

Any ideas? Any help would be appreciated. Here is the TemplateStyles css page:

I created a second CSS page to use for experiments:

Solved. See discussion here:

How to do "/doc" template styles?

TL;DR: What is best practice for {{documentation}} of a TemplateStyles css subpage?

Long: It's in templatespace ;-) I noted, one cannot & doesnot add the habitual "<noinclude>{{documentation}}</noinclude>" to a .css page. All fine. OTOH, I'd like to work with these css pages, off css-coding. Think background categorising, track usage, planning standardisation.

-DePiep (talk) 22:43, 20 February 2021 (UTC)

For sufficiently 'longterm' comments, the styles page itself is fine. For shortterm comments, use the talk page of the primary template as is normal for coordination. --Izno (talk) 22:50, 20 February 2021 (UTC)
Not just comments, I meant. More like automate, categorise. Categorise by talkpage you mean? The horror; see also this GA talk scroll #bottom cats. Such indirect trackings are a load on editors like me. I do understand the TSTYLE of course, and its consequences. So we'll have to discover documentation along. (I remember module-user-sandbox setup) -DePiep (talk) 23:37, 20 February 2021 (UTC)
YAGNI. Whatever you think you need or want to do, you probably don't. --Izno (talk) 23:41, 20 February 2021 (UTC)
No WP:DOC for T:css subpages then, while I actually have described the need. So I'll have to scrape our WP screen, plaste it into a spreadsheet, and ... whatever. -DePiep (talk) 00:34, 21 February 2021 (UTC)
Anything but categories can and should be placed on the main template’s documentation subpage. Categories may not be applicable there; if they are really useful, they can be included as CSS comments (/* [[Category:Foo]] */), and they will appear at the bottom of the page. —Tacsipacsi (talk) 00:52, 21 February 2021 (UTC)
Do you have a live example of /* [[Category:Foo]] */? Would be great. -DePiep (talk) 00:57, 21 February 2021 (UTC)
I don’t have one at hand, but you can just edit a TemplateStyles page and click preview. While searching for a test page, I found Template:MongolUnicode/fonts.css, which includes {{pp-template}} (rather than a literal category) in the same manner, and it works. However, I don’t know what performance implications these categories/templates have (one of template documentation subpages’ purposes is to improve wikitext processing performance), so I’d use this technique very cautiously and rarely. —Tacsipacsi (talk) 01:06, 21 February 2021 (UTC)

HTML 5 compliance issues relating to TemplateStyles

W3C's validator is throwing errors when I test a page that uses {{sronly}}, which depends on TemplateStyles [3]:

Error: Element style not allowed as child of element p in this context. (Suppressing further errors from this subtree.)

From line 72, column 133; to line 72, column 187

...est</span><style data-mw-deduplicate="TemplateStyles:r993651011">.mw-pa...

Contexts in which element style may be used:
     Where metadata content is expected.
     In a noscript element that is a child of a head element.
Content model for element p:

     Phrasing content.

And:

Error: A link element must not appear as a descendant of a body element unless the link element has an itemprop attribute or has a rel attribute whose value contains dns-prefetch, modulepreload, pingback, preconnect, prefetch, preload, prerender, or stylesheet.

From line 81, column 209; to line 81, column 291

.../a></span><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r993651011"/><span...

The second would seem fixable by giving it an itemprop value, or adding a value to rel, if that wouldn't break anything. Dunno about the first. And maybe these are both just general issues with templates that use TemplateStyles.
 — SMcCandlish ☏ ¢ 😼  04:07, 15 December 2020 (UTC)

The use of the style/link tags and why TemplateStyles are injected as inline as they are is documented in phab:T155813. It does not look like HTML validation was chief among the decision criteria in so far as it doesn't seem to have been considered at all. Obviously browsers don't mind loading the CSS for <style> wherever it is found in the page. I am not sure if it is worth it to add a Phab task for this, at least as documentation that the use of TemplateStyles will cause HTML validation to fail, or e.g. better to put something in mw:Extension:TemplateStyles as a warning to users. Or both.
I don't see itemprop mentioned in Phabricator for the design of TemplateStyles, so that may be something that can be fixed. Recommend a phab task for this regardless of the other. --Izno (talk) 22:18, 20 December 2020 (UTC)
Its not valid html5 and a known issue, but it falls within the parsing rules for foreign/invalid content and all browsers support it (because of shadowcontent, webcomponents and scoped css legacy). It's part of the "we are not valid for validness sake, but for actual valid results"-policy (similar to how we used to include 'invalid' IE specific stuff to make certain things work in IE). —TheDJ (talk • contribs) 20:19, 22 December 2020 (UTC)
btw. this might change at some point when we fully switch to Parsoid, as it is easier to postprocess HTML with Parsoid to correct something like this. —TheDJ (talk • contribs) 20:25, 22 December 2020 (UTC)
It's part of the "we are not valid for validness sake, but for actual valid results"-policy Right, I left that unspoken, and apparently so did the RFC participants. That's why I am not sure whether it should be a Phab task or a note on the extension page. You say it's a 'known' issue but I see no evidence of it being known. ;) (I am fully supportive of TemplateStyles, just casting some doubt on the documentation, which is nothing new for most software projects ;).) --Izno (talk) 21:06, 22 December 2020 (UTC)
Izno, its known as in so far that it was brought up at some point when initially reviewing the code when choosing solutions. The reason is also why T200206 isn't yet fixed, so you could say it is captured there. —TheDJ (talk • contribs) 12:16, 24 December 2020 (UTC)

Maximum tool compatibility

For maximal compatibility with browsers and other tools, it would be best if this emitted <link rel="..." /> instead of <link rel="..."/>. While the space is not required in HTML 5, it is in XHTML and is also expected by various parsing tools (even some of our own internal ones like the syntax highlighter gadget will barf on <br/>, and mis-highlight the entire page after that point, which doesn't happen with <br />).  — SMcCandlish ☏ ¢ 😼  04:08, 15 December 2020 (UTC)

@SMcCandlish: Is it really invalid in XHTML, not only in HTML4? As far as I remember, XHTML (XML) doesn’t require spaces before self-closing slashes, it’s just a custom in order to prevent old HTML4 parsers from failing on this. But HTML4 is long dead, so probably we can go without supporting it. Anyways, TemplateStyles uses MediaWiki core’s Html::rawElement indirectly, which can, of course, be changed, but this change may (or may not) have larger impact by adding a lots of bytes to page HTMLs. Feel free to open a Phabricator ticket about this if you think it’s really important (and find no existing ticket about it). —Tacsipacsi (talk) 14:39, 22 December 2020 (UTC)
Correct, it is not invalid XHTML. The space is indeed traditional to help HTML 4 parsers from when XHTML was initially developed (15 years ago now). Modern web browsers have no issue parsing either version these days, most older web browsers have no issue parsing either version, and I expect most web spiders are operating as expected as well. Even systems like Notepad++ have no issue with either version. --Izno (talk) 19:58, 22 December 2020 (UTC)
MediaWiki outputs HTML 5 as identified by the doctype at the beginning of each HTML page. Not HTML 4 and not XHTML (1, 2, or its HTML 5 flavor, which is given barely-passing mention in the specification). Anyone parsing anything that is output by MediaWiki with another model is wrong or is choosing to do something dumb at the end of the day. (The particular syntax highlighter gadget has previously been noted as failing in that regard and its author has been recalcitrant in correcting the issue. It is his choice to do so, but given his recalcitrance I would suggest that tool as a terrible example. The syntax highlighter natively supported in 2010 and 2017 wikitext editors by MediaWiki has no issue parsing most constructs of this sort [though amusingly enough the templatestyles tag itself has an issue, phab:T263694].) --Izno (talk) 19:58, 22 December 2020 (UTC)
In HTML5 / HTML5.1 / HTML5.2, the space preceding the slash is optional. It is covered by After the attributes, or after the tag name if there are no attributes, there may be one or more space characters. --Redrose64 🌹 (talk) 00:11, 24 December 2020 (UTC)
Whatever. My memory may be getting rusty about when the space-slash convention was first introduced. The fact that it's optional in HTML 5 is not a reason to stop using it, when it breaks things if you do so.  — SMcCandlish ☏ ¢ 😼  18:51, 24 December 2020 (UTC)
The space is optional in XML and XHTML, but was required in HTML 4 if an empty element tag ended with the /> character pair instead of the simple > character. If a syntax highlighter chokes when the space is omitted, that's a bug in the syntax highlighter and not indicative of a problem in the code that it is parsing. --Redrose64 🌹 (talk) 00:37, 26 December 2020 (UTC)

Lua in-module templatestyles

What are the options to apply an existing .../styles.css into a module? For example, use {{Frac}} hardcoded into the module. The TS required is not known (=dymamic, by template input), so defining the TS in the implemented template (before the module call #invoke) is not possible. Any examples? -DePiep (talk) 11:28, 8 May 2022 (UTC)

You can load templatestyles from a module in the same way you can call out to any other extensions tag. with frame:extensionTag. An example can be found in Module:Sidebar, for instance. Just make sure to output it in a sane spot (generally before the content). —TheDJ (talk • contribs) 12:19, 8 May 2022 (UTC)
Module:Convert is too complicated but searching it for add_style and get_styles shows a generic solution. The code calls add_style when it knows a certain style is needed, and get_styles is called to get all the styles (if any) which are then output before the normal convert result. Johnuniq (talk) 23:53, 8 May 2022 (UTC)

Column alignment

I have started a discussion about using a general templatestyles page directly in articles to align a whole column without code in each cell: Wikipedia:Village pump (technical)#Column alignment. PrimeHunter (talk) 14:59, 13 December 2022 (UTC)

Duplicate styles

This question relates to a RfC at Wikipedia talk:Manual of Style/Tables#Template:Sort under and a discussion at the {{Sort under}} template talk page. One user expressed an interest in having two classes with identical styling for reasons he feels makes the template easier to use. Example:

  • sort-under-center
  • sort-under-right
  • sort-under ["popular choice" with identical styles to sort-under-right]

It's my understanding that only essential styles are added to MediaWiki:Common.css to help keep size and load times minimal, amongst other reasons. Do template styles follow the same practice? Are there any unforeseen problems? Keep in mind that duplicating the styles would add an extra 16 CSS selectors (thus far) to Template:Sort under/styles.css. Jroberson108 (talk) 09:31, 5 February 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Please observe WP:TALKFORK. --Redrose64 🌹 (talk) 12:15, 6 February 2024 (UTC)
Common.css is a huge file. One of the reasons for TemplateStyles was to lessen the size of Common.css. So the CSS for TemplateStyles would only be pulled as needed.
Some additional text for one more class in TemplateStyles is a very small addition. And it is very simple to do. But it greatly increases the ease of use of that template in my opinion. I edit a lot of tables. In fact, I have written large parts of Help:Table and its subpages. People copy what they see done on other tables. So they can copy it without having to wade through template docs, and make class choices.
So far, there seems to be consensus for the first 2 classes. 2 editors want class=sort-under in addition. Jroberson108 is opposed.
class=sort-under-center
class=sort-under-right
class=sort-under - with it being the popular choice so far: right.
I want to use class=sort-under because it is easiest to remember. If I remember the template name, then I just add a dash and I then have the class name. That is how most of the table templates I use work:
{{static row numbers}}{{sticky header}}{{sort under}}
{| class="wikitable sortable static-row-numbers sticky-header sort-under"
And it is easier for less experienced table editors than me. The pattern is obvious. They can just copy the above 2 lines to many other sortable tables without problems. --Timeshifter (talk) 10:03, 5 February 2024 (UTC)
@Timeshifter: WOW, there is no reason to duplicate the RfC here. I kept the question as concise and unbiased as I possibly could for a quick answer to verify the practice is acceptable before returning to RfC. They are capable of clicking on a link to read more. Jroberson108 (talk) 10:16, 5 February 2024 (UTC)
I didn't think your post was clear or specific enough. And the other discussion is focused on multiple questions, not just this one. --Timeshifter (talk) 10:20, 5 February 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:TemplateStyles/Archive_1&oldid=1241389383"