Topic on Extension talk:TemplateStyles/Q&A

From Extension_talk:TemplateStyles:

"Storing CSS in a separate page is 1000% the right approach, it is a pretty bad idea to add yet another parser/ tag function. People will then try to use it with the {{#tag extension and create a huge mess. It will also kill any idea of making these templates mobile compatible unless they ignore things like onlyinclude, which may render part of the template in a messy way, and the rest mobile compatible. This isn't to mention the huge potential for vandalism by enabling crazy animations that are only possible using sitewide css, or the fact that proper editing tools such as code-editors or even customized GUIs won't be possible when people start embedding those in weird ways.

If anything, there would be no point in this extension adding such a construct anyway, it is claimed to work in Extension:CSS which may already have been battle tested for several years in some wiki.

There is a chance that MCR might be vapourware, so that solution might end up stalling the project indefinitely, and maybe allowing the tag extension would be the lesser evil."

I doubt that MCR is vaporware given the interest from multiple groups...

I have no particular objections to storing template style info in separate pages, though I think the concerns are overblown (CSS relating to animation can simply be filtered out), and I'm not sure we need the overhead of yet another namespace. It will complicate template page moves, too. Maybe not to a problematic level, though. In short, I don't object to this idea, nor to the parser tag approach, and am basically neutral on the question, as long as we get the functionality, which is highly desirable.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:38, 6 February 2017 (UTC)

Having slept on it, I think I support the parser tag approach marginally more, as having less unnecessary overhead.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:23, 6 February 2017 (UTC)

I think separate pages are the best approach in the general case, especially for styles that are used in many templates. That means the pages should not have to be subpages - they should be included by templates explicitly, similar to the inclusion of templates in articles.

That also means we don't need an "either/or". Just allow css on every template page. If css is used by a single template only it can have the code directly, but putting it in a subpage is also possible.

That would already be possible anyway, simply by make a template that is just template CSS code, explicitly for transclusion by other templates. WP already has lots of metatemplates and subtemplates that don't do anything complete by themselves but are only subroutines of other templates, so this would not actually be a change.

It would be a change - it would introduce . Or do I misunderstand your comment?

Yes. To clarify: This implementation method would not actually be an infrastructural change of any kind, unlike the various proposals for setting up a special subpage, perhaps with the CSS content model and the special editor for that, then a transclusion system like that used for template documentation, and blah blah blah. All we'd be doing is introducing a new parser tag, which we do all the time (or used to; I guess it's been a while).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:42, 11 February 2017 (UTC)

Right. I think that is sufficient. The individual language versions can then decide how they want to use that tag.

That's what I'm thinking. Most would use it directly in the templates, but en.wikipedia might go the complex route, due to higher levels of template-targeted vandalism. It need not be overly complicated "out of the box". Especially given that people all over the world use MediaWiki for non-WMF projects and do not have a huge staff (maybe just one volunteer). MW is already a bear to set up, so we needn't complicate it further.  :-)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:16, 11 February 2017 (UTC)