See also my userscript:

http://en.wikipedia.org/wiki/User:TheDJ/Print_dialog

Now available as a gadget on en.wp

News outlets often have a "print" link because their content is paginated (and contains ads). MediaWiki pages don't have the same issue(s).

That said, it looks like the gadget you've developed contains additional features that might restore some value to the inclusion of the link in the sidebar.

• Bug 56875 has been marked as a duplicate of this bug. ***

+1 on this. In fact, I think the link is of very dubious value (how many people really don't need to print?) but in any case, generating our own printable version is just a waste of everyone's time, and is bound to throw up quirks (not that I understand how we generate it, but anyway...).

• Bug 63972 has been marked as a duplicate of this bug. ***

Change 142822 had a related patch set uploaded by M4tx:
Change link to Printable version to JS's print()

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

Change 142822 had a related patch set uploaded (by M4tx):
Change link to Printable version to JS's print()

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

Patch-For-Review

Let's please do this.
And also get rid of the clogging up DOM by using class="noprint and instead including them into <link rel="stylesheet" media="print"> with (core's commonPrint.css || themes print styles like Vector's ) or an included @media print rule, where we are collecting them:

@media print {
	.selector01,
	.selector02 {
		display: none;
	}
}

And also get rid of all the code involved to make the printable flag possible.

@Aklapper mentioned in T58875#619659

(In reply to comment #1)

For stats, http://stats.wikimedia.org/wikimedia/squids/SquidReportScripts.htm
seems to suggest 17M hits for printable type urls (out of 15,254 M I think,
not sure if I'm reading that right)

There's some stats. Now is that enough or not?

Would be interesting, to see

1. how the stats have developed,
2. how many of those people have JS deactivated and therefore wouldn't find that link. Also, what browsers are those using (maybe there are still some IE 5 users among those ;) )?

@matmarex commented in T65972#681239

Just printing pages already works. (In fact, the "printable version" functions
by applying the same stylesheets that are normally used for printable media for screen media as well.)

As for the link in sidebar and the &printable=yes functionality, last time I asked the reasoning was:

1. It will be necessary to actually print pages if we ever explore something like MobileFrontend's dynamic section loading on desktop, or dynamic loading of images
2. People are used to having a "printable version", even if it doesn't do anything
3. It provides support for ancient browsers that do not support CSS media queries, including [browsers before [Firefox < 3.6 and Internet Explorer < 9]

See https://en.wikipedia.org/wiki/Help:Printable for more information.
(Pity we don't have a page like this on mediawiki.org.)

Some vaguely related bugs: bug 56786, bug 39117, bug 48234. I'm copying people
who partic[ipated] in discussions there.

[Slightly edited to reflect comment by @Bawolff two comments later and own research regarding browsers]

The functionality has been around for 10 years from my understanding, people usage/understanding of the Internet/browsers is different, how they access it is very different.
Regarding:

1. If we ever, we'll need to care about that, correct. @Jdlrobson What's the status of exploring dynamic section loading? Is there a static page option in the sleeves? Moreover, adding an explicit print option (doesn't matter if JS or no JS) on mobile is ridiculous at best. PDF option seems to be able to jump in here, which would be untouched.
2. The "printable link" would stay and get improved by progressive enhancement. Just the implementation would differ. Even W3C presents printable links as example practices.
3. <link rel="stylesheet" media="print"> is widely supported, but we might run into RL issues?! @media print is supported by all major browsers, except <IE 9.

And also get rid of the clogging up DOM by using class="noprint"

Note that noprint is primarily a CONTENT directive, not a 'chrome' directive. It's eradication, as many other issues is dependent on T483. Let's not drag noprint into this ticket though...

@TheDJ Do you mean by possibly taking away a handle for templaters to exclude elements from printing without having to touch Less/CSS?

templaters do not have access to less/css right now and that's why we have things like noprint, nomobile, nopopups, noextract etc..

To take it away is unrealistic, until there is a replacement. Remember that on any sort of reasonable large wiki, there are 10.000s of templates. The CSS for that cannot be squashed into MediaWiki:Common.css and shipped to every single pageview.

I've given noprint it's own ticket T117950.

@TheDJ Got it. I'm thinking about stateful CSS classes and classes to noprint kinda point into that direction. But I also think that in projects like Vector we should go for the best-practice/cleanest approach, which means in general no semantic class names should be integrated in DOM, as presented for example here.

Interesting, Vector indeed has class="noprint" in three places, and like you're saying it probably shouldn't. It's a separate thing from this, though.

It's been suggested to remove the entire printableversion altogether, as not having enough additional value, and just offering a JS print link.

Thoughts ?

Change 350197 had a related patch set uploaded (by TheDJ):
[mediawiki/core@master] Remove printable version in favor of JS print

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

Change 350197 merged by jenkins-bot:
[mediawiki/core@master] Print: prefer JS print over printable version.

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

Change 354998 had a related patch set uploaded (by Brion VIBBER; owner: Brion VIBBER):
[mediawiki/core@master] Put print click handler on link, not on list item

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

Change 354998 merged by jenkins-bot:
[mediawiki/core@master] Put print click handler on link, not on list item

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

@TheDJ Congratulations on this being resolved. Once we started looking at printing for the OCG sunsetting, this was one of the first head-scratchy features I noticed. I also thought it would be trivial to fix. Judging from this ticket it took almost 3 years! Why do you think it took that long? I'm not criticizing, I am just generally curious. A fantasy I have is to remove or replace these hyperlinks with icons....is that the craziest thing you ever heard?

In T24256#3368695, @JKatzWMF wrote:

I also thought it would be trivial to fix. Judging from this ticket it took almost 3 years!

Ha, I wish: "TheDJ created this task. Jan 25 2010, 2:09 AM"

Why do you think it took that long? I'm not criticizing, I am just generally curious.

Not enough people caring, not enough people understanding media queries, shifting goals (JS print vs remove printable version), indecision, etc etc.
Oh, and these more obscure parts have never really had a team at WMF that concerned itself with such trivialities.

A fantasy I have is to remove or replace these hyperlinks with icons....is that the craziest thing you ever heard?

Not the craziest. As a matter of fact I had a gadget that added icons:
https://commons.wikimedia.org/wiki/File:Sharebox_toolbox.png

Be careful though. icons are not always as universally recognized as we expect. Text is sometimes better.

You also might be interested in my Print options gadget (which ironically is slightly broken now due to this change, due to competing click handlers.

@TheDJ Thanks for the response. I like the icon look of your gadget, but more importantly, it sounds like the blockers were more about drag and friction than violent opposition to sidebar change :)

In T169920 @JackPotte points out that Firefox does not have a print preview, something that printable=yes provided beforehand.

In T24256#3413905, @Jdlrobson wrote:

In T169920 @JackPotte points out that Firefox does not have a print preview, something that printable=yes provided beforehand.

That’s not the full story: Firefox has a print preview, but with a click on “Printable version” the OS print dialogue is directly started, and this has no preview, at least in Windows.

BTW why did you close the other task as duplicate, but did not reopen this one?

Change 142822 abandoned by TheDJ:
Change link to Printable version to JS's print()

Reason:
We favored I22f7cf2 in the end.

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