Page MenuHomePhabricator

Add css "onlyinprint" class to hide content from anything except print output
Closed, DeclinedPublic

Description

Author: volker.haas

Description:
The Extension:Collection was recently altered as per community request. The intended result was lua support for PDF output (which was achieved).

The problem is that due to technical reasons special templates "exclude in print" and "only in print" stopped working (and the functionality can't be restored).

There is an easy work-around for this, but it requires a css class used by Wikipedia that hides elements from regular output.

.onlyinprint {display: none;}

Any content that is specially crafted for PDF output should be "marked" with the "onlyinprint" class and thus be hidden in the browser but visible in the PDFs.

The following fragment would therefore only be visible in a PDF:

<div class="onlyinprint">blub onlyinprint</div>

I hearby kindly ask for the css snippet to be included in the Mediawiki core css file.


Sidenote:
The opposite can already be achieved:
Content that is not supposed to be included in the PDF can already be marked with the css class "noprint":

<div class="noprint">blub noprint</div>


Version: 1.22.0
Severity: enhancement
See Also:

Details

Reference
bz50750

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:44 AM
bzimport set Reference to bz50750.
bzimport added a subscriber: Unknown Object (MLST).

Wouldn't this also require some changes in Collection? Adding the class in core would only change the behavior of normal "printable" version (&printable=yes).

Also, I'd use "printonly" as the class name here – it IMO sounds better and would be consistent with some other naming conventions, like noinclude and includeonly.

volker.haas wrote:

Changes to the Collection extension are not necessary. The "noprint" case is already handled - only if the css class used to suppress printing mwlib would need to be adapted.

Handling the onlyinprint/printonly case is basically isolated from the Collection extension, therefore it doesn't matter how the css class is named. However it is important that the css class name to hide things from display in the browser is used consistently in the css file and templates/articles/Collection extension help pages.

Historically, we don't really like to do hiding in 'screen' versions of the HTML. printonly would basically reintroduce 'hiddenStructure' http://en.wikipedia.org/wiki/Wikipedia:HiddenStructure, a hack that we desperately sought to get rid of because it was far from ideal for accessibility reasons. I'd not quickly care to reintroduce such a thing. Also something like Google search would have no clue how to interpret something like that.

I'm not sure if this structure would still be controversial, but I think it is important to point this out.

(BTW, we do use similar tricks for targeting content at specific user groups (sysops), but this is generally only in interface or in maintenance templates), it isn't used in content, as this might be.

(In reply to comment #3)
+1. It makes no sense to send content for the readers if it will be always hidden. If users shouldn't see it, just don't add it to the HTML of the pages.

We are still struggling on Portuguese Wikipedia to get rid of the 'hiddenStructure's:
http://pt.wikipedia.org/w/index.php?oldid=36240812

Change 94954 had a related patch set uploaded by MaxSem:
Remove template blacklisting functionality

https://gerrit.wikimedia.org/r/94954

Change 120865 had a related patch set uploaded by Apsdehal:
Adds onlyinprint class to skins

https://gerrit.wikimedia.org/r/120865

He7d3r set Security to None.

Change 120865 abandoned by Aklapper:
Adds onlyinprint class to shared css

Reason:
In the meantime, default skins have been moved into separate, different repositories. I'm hence abandoning this change as it now needs to happen in a different repo.

https://gerrit.wikimedia.org/r/120865

Aklapper lowered the priority of this task from Medium to Low.Sep 23 2015, 1:58 PM
Aklapper removed a project: Patch-For-Review.

I don't see the need for core. With TemplateStyles T164879 on the horizon, is there a remaining necessary use case for this as core style?

Another half year later, no new arguments have come up. This would be a counter-productive measurement resulting in bloating HTML with single-use CSS classes.