Extension talk:TemplateStyles/Q&A

Help:TemplateStyles#Where can I see it in action.3F

Will there be ability to style table columns in this methodology? The Wikisources have been wishing for that capability as we need to reproduce complex tables in published works. At the moment we have to style by cells, and doing that for very ''n''th cell in a long table is messy.

For an example of some of the formatting that we have done to get around column formatting

S:en:Page:National Life and Character.djvu/358

and the master template that we have built to assist to get uniformity and some simplication (and a level of tidiness)

S:en:Template:Table style

Think how that can be when we have 15 columns wide, and 30 rows deep. It becomes very ugly, so getting this implemented will be of great assistance. We can probably offer tables for testing if required, we have plenty.

That's a CSS question that's not really related to the questions mentioned here. In CSS3, you can use :nth-child which works well as long as your table structure is regular (ie. you don't use colspan, or use it the same way in every row). CSS4 (still in draft phase) has proper column support, but is far from being supported by any browser, and the TemplateStyles CSS sanitizer won't support it either. In short, depends on how complex that table is.

@Tgr (WMF) I understand that "nth-child" can be used in common.css, it was my understanding that it was unable to be used in templates. So that was why I asking whether was now going to be undertaken this sort of implementation of templatestyles. If you are indicating that nth-child can be used in templates now, then I have a whole community who didn't realise** and we have got some reading and clean-up to do.

** [This could be the case as we are enthusiastic transcribers, though not much of the generation of style/class/objects!]

Yeah, pretty much everything form CSS3 that we don't have an explicit reason to disallow will be usable in templates.

Fantastic, that will allow us to close out phabricator tickets that ask about this functionality.

Note there's no reason css-sanitizer couldn't support Selectors Level 4 someday, but there's not much point until browsers support it.

See : Help:TemplateStyles#Where can I see it in action.3F

"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.

There haven't been any comments here the last few days, but we plan to wait until February 22 (23:59 UTC at the earliest) to give people a few more days to weigh in before we take any further steps or decisions.

(That would be now.)

TL;DR:  The team will go ahead with option 2 without magic subpages, "Store CSS in a separate page".

As someone who has no particular stake in the outcome of this (I was merely asked to keep an eye on the discussion, can't say that I have an opinion here), I told the team that my reading was "no real consensus either way", with arguments on both sides, the main disagreement probably stemming from different focus – on the one hand future development (ease of moving MCR as a strong argument; conviction that the main drawbacks of separate storage are temporary and will be addressed reasonably soon anyway), on the other hand the here and now (ease of editing right now; unwillingness to take MCR into account because you never know how long it takes before something is done). It's difficult to talk about refutation of arguments since the positions roughly align with different priorities and views on what to expect from future development. Since they had to make a decision and seemed to have a strong conviction about what would be the best solution – store CSS in a separate page – my reading of this was that they should ago ahead with that, since there wasn't enough guidance here to do things in another way.

(Also, from a !voting perspective, slightly more persons involved in this discussion seemed to favour separate storage.)

As I see it, in-wikitext storage (option 1) has the following benefits and drawbacks:

• Pro: Keeps the styles and the wikitext together now.
• Pro: Will work well with TemplateSandbox now.
• Pro: Ability to use {{#tag:}} and such allows for more flexibility, e.g. interpolating template variables into CSS property values.
• Con: More clutter in the wikitext.
• Con: CSS will likely not be automatically formatted when editing the page, or highlighted as CSS in general-purpose syntax-highlighting editors.
• Con: Ability to use {{#tag:}} and such makes it more difficult to reason about the CSS being produced.
• Con: Ability to use {{#tag:}} and such prevents catching all errors when the page is saved.
• Con: Use of {{#tag:}} and such will prevent a future move of those styles to MCR.
• Con: Line numbers in error messages will be reported relative to the start of the style block rather than to the start of the containing wikitext page.

As I see it, separate storage (option 2) has the following benefits and drawbacks:

• Pro: Editing the CSS can use a CSS code editor, as is currently the case for user and site CSS.
• Pro: Easy conversion to using MCR once that eventually comes along.
• Pro: Possible to search for styles only using CirrusSearch's contentmodel keyword.
• Con: Keeping the styles and wikitext together is harder (until MCR eventually comes along), very much like how /doc subpages work now.
• Con: Testing edits to both the template and its styles would need to use a sandbox (potentially with Special:TemplateSandbox), at least until MCR comes along.

If we have a magic subpage (or magically-associated namespace) for the separate storage, that has some additional cons. It's easy to avoid all of these if the template has to explicitly include a styles page.

• Con: The magic subpage needs to have protection cascaded from the parent page, which tends to be confusing UI.
• Con: Probably needs a way to enable it for pages used as templates in other namespaces (e.g. user pages that are intended for transclusion).
• Con: Substing the template won't carry the styles over.

Personally, I think separate storage without magic subpages sounds more functional and editor-friendly than in-wikitext storage, but I see SMcCandlish and This, that and the other below prefer in-wikitext storage. I'd like to hear your reasoning.

I agree with Anomie (separate storage without magic subpages for now, later move to MCR) as the best option.

Another pro IMO: Allows for re-use of the same CSS across templates.

@Izno: I believe they all can accomplish that. For in-wikitext and magic-subpage storage you could achieve it by putting the shared styles in/on an otherwise-empty template that you transclude in the templates that need it. For separate-page non-magic-subpage storage it would likely work more directly as something like <templatestyles src="Template:Example.css" />.

IMO having a dedicated editing interface is a big enough benefit that it outweighs the drawbacks of separate storage. (Plus I think we'll want to extend this to JS some time in the future, and in-wikitext is clearly not an option there.)

Separate pages limit flexibility somewhat (which can be both good and bad), but they don't preclude using template variables specifically. We could allow syntax like

without too much difficulty, and that could be used together with {{#tag:}}.

Depending on the delivery method, `` could actually be rather difficult. Descending into jargon from the technical RFC, this would be easy for 3A, might be problematic for 3B, and would very likely be problematic for 3C.

But isn't most of the opposition to doing it inline in the template code the very fact that {{#tag:}} would be in play at all? To also address Anomie's longer post: I don't know enough about MCR to comment meaningfully about it. I am, however, skeptical about any sort of "it's coming soon" assumptions; things are always coming soon with WMF projects, and "soon" turns into 5 or 10 years. :-) The {{#tag:}} syntax is a rarely-used workaround (and actually does work around things). We have to redevelop stuff sometimes when majors changes are made; that's just the nature of the beast. So, I don't find the cons for keep-it-in-the-template very compelling. Nor the syntax highlighting argument. The solution for that is to upgrade the regular syntax highlighting module to account for the new constructs. That seems like less work for fewer people that a forest of thousands of additional pages to maintain and transclude and protect and whatever. And syntax highlighting that accounts for CSS syntax in the middle of wikitext isn't really necessary, just nice to have.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:54, 11 February 2017 (UTC)

The extremely high-level idea behind MCR is that instead of having subpages for different pieces of what's logically one page, you have the different pieces combined in the one page and can potentially edit them all at once. I don't think there's a UI design yet, but a basic no-JavaScript version might be an edit form with two text areas, one for the template's wikitext and one for its CSS.

Personally, I'd much rather not create technical debt that we can easily avoid even if the pain of it would be a few years later.

I also think you're underselling the syntax highlighting argument, considering that syntax highlighting came in at #6 on m:2016 Community Wishlist Survey/Results. And while highlighting CSS-inside-wikitext is possible, I'm skeptical that it can be done well given how complex template wikitext already can be.

And I think you're greatly overestimating the "forest of thousands of additional pages to maintain and transclude and protect and whatever". I don't think I've ever heard any complaints about additional pages for template /doc subpages or about additional pages being needed to store Scribunto's modules.

"And while highlighting CSS-inside-wikitext is possible, I'm skeptical that it can be done well given how complex template wikitext already can be."

Plus someone would have to write the CSS highlighting logic, while for a separate page/textarea we can just pick one of the dozen off-the-shelf editors/editor plugins that already support it (just like CodeEditor does it).

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)

My opinion is that styles and scripting related to specific templates should live on separate pages. This enables MCR integration later (to some small degree--I would guess a script will have an easier time migrating CSS/JS from subpages to slots than from embedded information to slots).

Separate pages also enable separate protection mechanisms to be applied to style pages. Given the recognized potential for misuse of CSS (and especially JS, though JS is probably less relevant right now), there should be a separate protection mechanism available for the styling pages, and even enabled and "on" by default. With the current system of protection (prior to MCR), that's simply not available.

The primary difficulty with migrating embedded styles to a MCR slot, as I see it, is that the embedded styles might be being generated using {{#tag:templatestyle|...}} or by calling frame:preprocess() from a Scribunto module. Moving to an MCR slot would not want to be trying to parse the slot as some sort of wikitext.

Regarding potential misuse, the opportunity for such will be somewhat greater than for the existing inline styles but much less than for existing mechanisms such as MediaWiki:Common.css. There is nothing in this proposal about allowing JS at all.

I would very strongly suggest that both {{#tag:templatestyle|...}} and frame:preprocess() would be blocked from working for precisely this reason.

That's one of the reasons why I support separate-page storage. Making it possible for the tag function to detect that it's being used in one of these ways seems like it could be difficult.

"lm Vorlagennamensraum mag ich das noch verstehen, wenn man dann dort auch ein paar mehr CSS-Eigenschaften nutzen darf (z.B. für das Ansteuern unterschiedlicher Bildschirmbreiten). Aber das Beispiel auf der Seite ist doch blöd: man wird doch nicht ernsthaft auf die Idee kommen, das im Artikelnamensraum vor die Tabellen zu klatschen. Und im Vorlagencode sieht Otto Normalbearbeiter die Style-Anweisungen ja gar nicht, die bekommt nur der Vorlagenprogrammierer zu Gesicht und der sollte damit klarkommen. Oder hab ich das Ganze falsch verstanden?" @Hgzh