Templaters do not have access to Less/CSS right now and that's why they use a class like .noprint. It's a replacement for their inability to use media queries.
MediaWiki:Common.css has stopped being sufficient for their needs, because it is shipped to every pageview, and thus only the most common usages of templating usually make use of MediaWiki:Common.css
Classes noprint and nomobile are very useful functions for templates to have, because when all they want to do is toggle whether or not a thing is visible, why should they need to delve into the bowels of css for that? Even with full template css it will be a repeat of the same code every time they do it, probably on completely different pages, so really this sort of thing is exactly what CSS classes are for.
Mind you this only applies to the content (usually templates themselves); we should be moving away from using noprint in the software itself as it's much more trivial to just slap a bunch of blah, blah, blah { display: none } when you're dealing with a lot of other styles anyway. But templates are relatively separate entities usually, which tend not to need much styling in the first place. (Just more than they have access to now.)
@TheDJ Do you have any ideas aside from a certain CSS class to enable templaters doing this? CSS class seems to me like a low hurdle approach?!
TemplateStyles is out and about now, so that's the obvious replacement for specific templates that you don't want to control via MediaWiki:Print.css (further comment on Print.css below). Ad hoc application out and about is generally bad practice I'd say. Which leaves this class without any real necessity I think. That would leave us at "find where it is used and remove it".
To be clear though, I think MediaWiki:Print.css should continue to be preferred for removing templates in print. It's much lower cost to support Print.css because you only receive the CSS if you request a print version of the page (vice needing to media query a display none onto a TemplateStyles page which ends up in the load delivered to everyone All The Time).
(I do agree with Isarra about nomobile btw for its MF-removing properties, but that's a different task if indeed relevant.)
But wouldn't the main way to set hiding when printing via a Print.css be to specify a class, such as .noprint, that can be widely reused to apply the style within content as needed?
And isn't reusing a common class generally better practice than setting the same styles individually for multiple things (especially if it's not part of a common selector, as it would not be when using templatestyles and the like)?
To be clear though, I think MediaWiki:Print.css should continue to be preferred for removing templates in print. It's much lower cost to support Print.css because you only receive the CSS if you request a print version of the page (vice needing to media query a display none onto a TemplateStyles page which ends up in the load delivered to everyone All The Time).
Basically, this. A basically one-liner class definition seems far more efficient (and user-friendly in terms of applying) to apply, especially where many such templates may not even necessarily need special styles at all, otherwise. (Simple navtemplates reusing skin toccstyles for their screen appearance comes to mind as a likely common usage.)
Not really. It's very low cost to add something to MediaWiki:Print.css. You might have a user discoverability problem, but eventually someone is going to say "this is useless in print how do I/we remove it", which is the normal wiki lifecycle. Discoverability is still an issue with "noprint" too.
At the end of the day, you target the class or ID or whatever that offends in Print.css, and voila, done. No changes to templates necessary even (unless you need to do something vile in TemplateStyles or otherwise like !important on display CSS, but then it's a just a matter of specificity). Print.css is also nice control because you can target interface elements as well.
Not really. It's very low cost to add something to MediaWiki:Print.css. You might have a user discoverability problem, but eventually someone is going to say "this is useless in print how do I/we remove it", which is the normal wiki lifecycle. Discoverability is still an issue with "noprint" too.
Why should every individual wiki need to go through this and add it individually? It's a common usecase, a common application. Something likely to commonly be used by templates, that are often copied and migrated off of larger wikis. Users then later having to go manually add something to their own MediaWiki:Whatevers.css to fully support them is something that really needs to become a thing of the past.
For one, every wiki may not want to remove all the same templates/classes/content/whatever, and I'd assert that the pain of forking a specific template or Tstyles page to control printing of all things is greater than asking for centralized print control.
For two, both noprint and Tstyles add to every pageload in CSS and with noprint HTML. Both not very much, but non zero. Print.css does not.
If someone really wants to hide Stuff a la noprint, they Also have access to generic TemplateStyles as in a {{noprint}} template (rather than add a media query to each particular template's TemplateStyles directly). I'm not personally a fan of that direction either, but that means there's yet another way to decide whether something should be hidden from print that isn't this globally supported MW class.