"anyone can edit the template, but a certain user right might be required to edit styling, which has more potential for vandalism"
Doesn't seem right to me. Changing CSS styling is fairly innocuous compared to the many extreme kinds of vandalism that can be wrought through editing the content of a template.
Less people understand how to use sitewide CSS compared to inline CSS so they may ignore what seems like a "trivial" but destructive change. They might also not be watching those pages so a small syntax error may render the style sheet invalid and it will take people time to realize before it propagates to thousands if not millions of pages.
That's unless the system is designed to ensure that the styles don't apply to content outside the template which is somewhat complicated.
Agree that (at least on wikis that want it that way) ability to edit this could be limited to the TemplateEditor right. Given the ability to transclude things, it seems that basic "utility" styles like odd/even table row coloring, can be templated themselves, and thus be transcludable as template style sheets into templates by anyone creating a template, without potentially harmful CSS experimentation. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 10:35, 6 February 2017 (UTC)
To be honest I would prefer that styles be placed in the template source, rather than in a separate subpage or other external location. I was just wanting to point out what I saw as an ill-conceived argument in the page.
Seems like there is potential for abuse, but in the end perhaps it's about the same as that of using inline style, so no actual change or new issue. I moderated the "should" to "could" in my comment above. For wikis that wanted TE protection, either a) they would have to protect templates that use this feature, the way they do with high-transclusion templates, templates used on the main page, etc.; or b) the style material would need to be in separate page, perhaps in a "Style:" namespace that had such protection automatically. But as I argue in the thread below, that second option seems like a lot of overhead and would complicate things like template renames/moves. So, in this end, I can't think of a reason to support making the feature limited to TE editors after all. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:21, 6 February 2017 (UTC)
I support option 1, storing CSS in the template code. Template code should live in the template. The experiment with TemplateData, which is template code that lives in the template's documentation, has been a mess and is still not fixed. See, for example, task T56140 and task T52512. Let's start off right with this feature.
I'm confused. You say that you support storing the CSS in the template code, but then you go on to say that TemplateData storing its data in the template code is a bad thing. T56140 that you link is specifically about not sorting TemplateData's data in the template code.
It's doubtful that TemplateStyles would store its data in the page properties at all, so T52512 doesn't seem particularly relevant.
TemplateData is not stored in the template page. It is template code that is stored in the template's documentation, a separate (almost always unprotected) page that, before the TemplateData experiment began, had no effect on the template's behavior. The bugs I linked above are people recommending solutions to fix this suboptimal choice.
Programming code, including TemplateData and CSS styling, should be stored in the Template itself. That way, there is only one page that controls how the template behaves, only one page that needs to be watched for changes, and only one page that needs to be protected.
There's currently nothing besides convention stopping <templatedata>...</templatedata> from being placed into the template itself instead of in the /doc subpage, although IMO it's probably a good convention since TemplateData is structured documentation. If TemplateStyles goes ahead with the in-wikitext version, there will be nothing stopping that too from being placed in a subpage that gets transcluded into the main page, although it very likely won't be the /doc subpage since that's wrapped in <noinclude>...</noinclude> and the in-wikitext storage would most likely need to not be noincluded.
I wouldn't be too surprised if someone were to make a convention for storing the styles in a subpage with a CSS content model and a template like {{documentation}} that transcludes that subpage, to get around some of the cons to the in-wikitext storage mechanism I mentioned in Topic:Tknqwttuhm7movox.
Reasonable in theory, but I'm skeptical that the CSS content model and special code editor for it is enough of a plus to counter the minuses of keeping this in a separate transcluded page, which is a tremendous amount of overhead for what in most cases will be very simple and short CSS, most often just a single declaration. We include inline CSS in templates all the time, and no one's head seem to asplode. ;-) — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 13:37, 11 February 2017 (UTC)
I think that's an offbase assessment given the development of multi-content revisions, which will move TemplateData "into" the same page as the template.
(As it is, the only reason it's a mess is because people expect it to be on a different page, as with the documentation. That's not really a fault of TemplateData IMO.)
The fault with TemplateData is it's a hassle. No one wants to maintain it, and templates rapidly fork in what they actually do from what the TD says they do. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 13:39, 11 February 2017 (UTC)
Is it possible to restrict the template css so that it can only affect things within the .mw-body-content area of the page? -- WOSlinker (talk) 21:22, 19 June 2017 (UTC)
When this Q&A was live a few months ago, the answer would have been that it does better in using #mw-content-text, so it excludes a few things like the category links at the end of the page that shouldn't be being messed with by template css.
It's doing even better than that now by restricting to the new .mw-parser-output class instead. The major difference there is that .mw-body-content and #mw-content-text also contain things like the diff tables and the edit form.
