Topic on Extension talk:TemplateStyles/Q&A

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