I’d also like to see a such feature, but I’m also concerned about allowing it to be used by anyone. Constraining it to interface admins could be done through T17075 (simply create a CSS-only gadget that applies this rule), once—and in case—it’s implemented.

Yeah, TemplateStyles forces selecting something inside the parser output, not the parser output wrapper itself. Changing that doesn't seem dangerous (although custom user page wrappers are a bit of an abomination IMO).

In T271588#6733143, @Tgr wrote:

Yeah, TemplateStyles forces selecting something inside the parser output, not the parser output wrapper itself. Changing that doesn't seem dangerous

Yeah, doesn't seem dangerous to me. I can't think of any particular abuse that you could do with the wrapper that you couldn't already do inside it, seeing as it's not the scaffolding or anything on the page structure.

although custom user page wrappers are a bit of an abomination IMO.

Yeah, but it's not the only page I've seen it on. I don't know if it's worth supporting. I know parser team looks on them somewhat askance. :^)

The relevant code is generating the hoistableMatcher from the hoistableComponentMatcher.

From DiscussionTools' perspective, the problem isn't the unclosed <div>, but rather the fact that it comes from a transcluded page, which makes the transclusion cover the entire page (until the automatically generated closing tag at the end). If the same <div> was directly on the page rather than transcluded, DiscussionTools should work.

Is there a well-justified use case for this? Other than colouring the whole page in a different colour, I mean. Allowing people to attach generic styles to the container itself seems like a potential problem with separation of concerns.

In T271588#6926602, @stjn wrote:

Is there a well-justified use case for this? Other than colouring the whole page in a different colour, I mean. Allowing people to attach generic styles to the container itself seems like a potential problem with separation of concerns.

Well, not just colors; whole page fonts in general as well as background colors... which is basically CSS anyway for most people. I haven't seen a use in my travels but I mostly work on en.wp. It might be appreciated on e.g. Wikisource.

With Page Forms and multiple templates on a page, you would like to do something like use flexbox to position them in a certain way. But you can't do that because you can't put a container element around the templates without breaking page forms.

I think this probably needs some level of agreement that this is a good idea, so I don't think good first task is a good tag for it. ("Tasks are self-contained, non-controversial issues with a clear approach.", emphasis mine.)

As one particular BEANSy thing to do, it would be more trivial to disrupt a page with something like display: flex with something like this, but that's doable even without being able to target mw-parser-output.

I don't think we should allow .mw-parser-output to be styled directly. It was intentionally created such that it allows a logical restriction to be placed upon its contents with no display or semantic meaning on itself. If we were to allow this, your styles would work only for the article container and now anywhere else. This class is meant to be used quite a lot without those container elements being expected to change their styling at same time.

In terms of layout, it should suffice I think to wrap such pages in an element that has the styling in question without it affecting the page element. This also can't be allowed for security reasons since we need to be able to apply overflow and z-index on these reliably, for example, also for skins to be able to position containers such as indicators, site notices, or in VisualEditor modal dialogs.

The only thing that came up is custom styling for user talk pages

I did present another use case with page forms. It doesn't change the conclusion though, because I think it can be worked around by using https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms#Embedded_templates

Those use cases could maybe also be solved with something along the "header" and "footer" type elements that are in wikisource pages maybe? The use cases being described aren't really so much about styling that element, but being able to have have a section above and below the wikitext that isn't disturbed by editing the primary wikitext; such section could certainly still be wikitext itself.

I don't know much about PageForms, but that sounds like a limitation of the extension - if you want to lay out a set of templates in a certain way, surely you'd want to put them into some kind of container (which can use different classes for different layouts, can coexist with other blocks etc) instead of relying on static styles on the entire content block?