Last modified: 2012-09-30 16:29:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T31157, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29157 - noprint content is hidden
noprint content is hidden
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.20.x
All All
: Normal normal with 2 votes (vote)
: Future release
Assigned To: Nobody - You can work on this!
:
: 33189 36742 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-26 19:56 UTC by Chris Buckley
Modified: 2012-09-30 16:29 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Chris Buckley 2011-05-26 19:56:49 UTC
https://github.com/hcatlin/wikimedia-mobile/commit/e833f5364048254761d9206f17b3b1ccd5791ddd

The above commit adds .noprint to the list of items to be removed from the page. Presumably its intention is to hide {{invitation to edit}} templates. However, some (e.g. time-dependent) content marked as noprint is desirable on mobile.

It would probably be better to add a more specific class to the table in the template, which can then be removed by the mobile parser. Best guess would be editsection, which is already removed by the parser anyway.
Comment 1 Tomasz Finc 2012-03-12 18:44:15 UTC
*** Bug 33189 has been marked as a duplicate of this bug. ***
Comment 2 MZMcBride 2012-03-12 21:33:30 UTC
Copying this comment from bug 33189 comment 1:

Re-using the "noprint" class is clever, but ultimately unwise. Sometimes you want things to not be on mobile and sometimes you want things to not be on print. They're distinct categories, with some overlap. Luckily, CSS supports multiple classes.

There should be a "nomobile" class that should be used when people want to hide things from mobile. Currently it looks like people are inserting dummy classes to trick the mobile parser (cf. <https://en.wikipedia.org/w/index.php?tiitle=Template:Birth_date_and_age&diff=479816119&oldid=436607844>). This is bad.
Comment 3 Jon 2012-04-19 15:25:42 UTC
+1 to MZMcBride's comment such a convention would also help problems in the mobile site (for example bug 20030)
Comment 4 T. Gries 2012-05-13 20:44:17 UTC
so we need 

.nomobile
.noscreen
.noprint
Comment 5 T. Gries 2012-05-13 20:45:16 UTC
*** Bug 36742 has been marked as a duplicate of this bug. ***
Comment 6 T. Gries 2012-05-15 07:08:05 UTC
changing component to MediaWiki. Issue is not only "mobile" related.
Comment 7 p858snake 2012-05-15 07:09:17 UTC
(In reply to comment #4)
> so we need 
> 
> .nomobile
> .noscreen
> .noprint

Is there ever a case for content to be not on the screen?
Comment 8 T. Gries 2012-05-15 07:14:06 UTC
(In reply to comment #7)
> (In reply to comment #4)
> > so we need 
> > 
> > .nomobile
> > .noscreen
> > .noprint
> 
> Is there ever a case for content to be not on the screen?

Yes. I have a case in my enterprise wikis: 

I show a shortcut Url in a specific form 

+ screen url=http://tinyurl.com/xyz" text="tinyurl/xyz" (to keep text as short as possible on screen)
+ print url=text="http://tinyurl.com/xyz" 

in the print version.
Comment 9 T. Gries 2012-05-15 07:15:30 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #4)
> > > so we need 
> > > 
> > > .nomobile
> > > .noscreen
> > > .noprint

When we fix this issue, we should simply add such a ".noxyz" class for any media xyz in a standardised form.
Comment 10 Andy Mabbett 2012-07-30 16:39:36 UTC
We should not have classes like "noprint" (which is a presentational description). Instead we should class elements descriptively, like "time-sensitive", "navigational", etc; and then style such classes to print, or not, as appropriate.

Probably too late now, though...
Comment 11 Mark A. Hershberger 2012-09-30 16:29:12 UTC
(In reply to comment #10)
> Probably too late now, though...

Certainly too late for 1.20 tarball.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links