Example currently live at: https://test.wikipedia.org/wiki/MediaWiki:Blockedtext

Unstyled output:

When displayed to the blocked user it is not inside the main parsed content. Adding the mw-parser-output class to the outer div should fix it. See the first bullet at mw:Extension:TemplateStyles#Caveats.

Thank you @JJMC89 - one of those annoying parts of tempaltestyles I forget!

We could add .mw-parser-output to some UI elements on the software side - blockedtext is pretty clearly intended to include templates. The question is, would it be more or less confusing than the status quo, where it's at least easy to know when to expect your template to be automatically wrapped in that class?

Right now I assume everything in the interface doesn't have it added. Adding it for select messages could be confusing. Could it be added by the function that is used to fully parse messages? (IIRC, not all messages are fully parsed.)

In T329966#8626313, @Tgr wrote:

We could add .mw-parser-output to some UI elements on the software side - blockedtext is pretty clearly intended to include templates. The question is, would it be more or less confusing than the status quo, where it's at least easy to know when to expect your template to be automatically wrapped in that class?

I would favor messages which run through the parser use a function that wraps that output in .mw-parser-output. That idea has previously been "declined". I don't recall there being a specific ticket or where I saw the discussion. I also know that seems like a lot of work.

I don't think that's all messages, so I think the followup question is reasonable. Today, the issue is largely that it's hard to know what might pop out in the context because the software doesn't know to add it, so we get cases like this. Adding the div preemptively to every MediaWiki message isn't feasible since many are inline, or are used as more as a preload, so you're still mostly as stuck as otherwise on the user side trying to figure out whether something relying on TemplateStyles will break if you put it in MW space (come to think of it, I have a mess to clean up because I added it to the wrong message).

If I were setting up a new instance of MW I also would not generally expect the default to be that TemplateStyles doesn't work in the namespace without the little help documented.

You can get an idea of the wreckage. I've been bit once when I forgot (that was for deploying Template:Hlist/styles.css, see Common.css talk), and as mentioned above, when I added it without need to (see Move-redirect-text talk), but otherwise I've managed to dodge user complaints (I like to think that's because I did a good job). See also this previous discussion which Xaosflux was amusingly party to :) for some of my logic on how English Wikipedia's done it.

In T329966#8626441, @Izno wrote:

I would favor messages which run through the parser use a function that wraps that output in .mw-parser-output. That idea has previously been "declined". I don't recall there being a specific ticket or where I saw the discussion. I also know that seems like a lot of work.

Yeah, I don't remember the exact place where we discussed that either, but basically, parsing a message doesn't necessarily result in a single element which could have that class added (it could result in just plain text, or multiple elements), and manually wrapping all parser output in an extra element would cause all kinds of breakage (especially given that there isn't really any way to differentiate between messages used for internationalization and messages used for customizing the contents).

The only viable approach would be to find all the places where the software outputs a message that's intended for community customization, and add the class on the appropriate parent block, which is probably hundreds of places; given that TemplateStyles has no official maintainer, it would take a long time and it would be very confusing during that time as some places would have that wrapper and some wouldn't. If template maintainers consider that less confusing than the status quo, we could go that way, but there is value in the clarity of always making it the template author's responsibility to add the class, IMO.

you're still mostly as stuck as otherwise on the user side trying to figure out whether something relying on TemplateStyles will break if you put it in MW space

I think the answer to that is yes - if you put a template in a MediaWiki: namespace page without a .mw-parser-output wrapper, that's always going to break. I don't think there are any MediaWiki messages which are used within the main content area and there's a reasonable use-case for putting a template in them.
(Also, an unecessary .mw-parser-output wrapper doesn't do any harm. So always using it in the MW: namespace around templates is a good rule of thumb IMO.)

In T329966#8626560, @Tgr wrote:

...but basically [...] which is probably hundreds of places

Right, "I also know that seems like a lot of work."

given that TemplateStyles has no official maintainer, it would take a long time and it would be very confusing during that time as some places would have that wrapper and some wouldn't.

I saw a patch go through the other day (I think for GrowthExperiments?) where they took a patch that added the class. And then there's also the work that got it added for page indicators. And half a dozen other extensions where one might expect such things.

If template maintainers consider that less confusing than the status quo, we could go that way,

Yeah, I don't like the options much either.

Adding the div preemptively to every MediaWiki message isn't feasible since many are inline, or are used as more as a preload, you're still mostly as stuck as otherwise on the user side trying to figure out whether something relying on TemplateStyles will break if you put it in MW space

I think the answer to that is yes - if you put a template in a MediaWiki: namespace page without a .mw-parser-output wrapper, that's always going to break.

I think the whole quote here is necessary for my point, it's that the user also has no idea if the context of the message is safe to put the div and class in. Example: message A gets dropped into a <div>, all is fine and dandy. Message B on the other hand gets dropped into a <p>, and now we are sad, because <div> doesn't go in <p>.

Moving it into the software would be safer on that point, and it scales up better; this task was created because someone was trying to support Meta, and it didn't work because I already fixed en.wp.

Or, <div class="mw-parser-output"> gets added to a MediaWiki message that gets left behind by moving a page (as linked already). Now I have a mess to clean up. (Which I actually can't find with Special:Search on en.wp because I can't search redirects. Really do need to go see if there's a task for that.) And the reason it's important to clean messes up is cargo wiki editing; I want to avoid exposing (most) users to the idea of this div and class if I can.

I don't think there are any MediaWiki messages which are used within the main content area and there's a reasonable use-case for putting a template in them.
(Also, an unecessary .mw-parser-output wrapper doesn't do any harm. So always using it in the MW: namespace around templates is a good rule of thumb IMO.)

Yes, that is true, an extra one doesn't normally do any harm (see above). Besides that a task like this one gets created every time you have someone new interacting with these things. ;)