BTW. thinking of noprint made me curious what would happen when printing a MMV view:
Basically it shows backgrounds of the arrows and close/fullscreen widgets, and an ugly table underneath the page, but other than that, quite nice and could be useful with a few small tweaks. I have filed a PDF of the print in bugzilla under: 65287. DJ On Wed, May 14, 2014 at 10:52 AM, Derk-Jan Hartman <[email protected]> wrote: >> - things that don't really belong to the article content (such as >> maintenance templates, icons in signatures on a talk page) > > We already have a class for that .metadata (also excluded from print, > book collections, WP 1.0 etc) > >> - things that belong to the article but MediaViewer does not offer a good >> user experience for them (some people suggested very small images) > > Very small images we can just exclude by algorithm, data-file-width > and data-file-height will tell us this right ? > >> - things that belong to the article but are technically too tricky to work >> with MediaViewer (e.g. various CSS map hacks) > > I like .noviewer It aligns with several similar classes that are in > wide use like: nopopups, noprint, nourlexpansion, nowrap, nounderlines > > DJ > > > > On Tue, May 13, 2014 at 12:12 AM, Gergo Tisza <[email protected]> wrote: >> On Mon, May 12, 2014 at 2:47 PM, dan-nl <[email protected]> >> wrote: >>> >>> i may be mis-understanding the goal … >>> >>> 1, it looks like you want to distinguish between elements on a web page >>> that should be viewable in mediaviewer vs those that should not. >>> >>> 2. you want to use a css class to distinguish these elements. >>> >>> 3. you mentioned that there may be future or other use cases and so you >>> want a generic css class; what would the other use cases be? >>> >>> if the idea is to distinguish between items that should be viewable in >>> mediaviewer vs those that should not, then i like >>> >>> .mediaviewer >>> .mediaviewer-item >> >> >> Basically >> >> - we want to distinguish between images for which MediaViewer is a good user >> experience vs. those for which it is not >> - we want to do it in such a way that places the community in control (CSS >> classes are an easy way to do this, there could be others) >> - it should be as generic as possible as MediaViewer might not be the only >> tool that has to make this decision (is the image suitable for >> HoverCards/navigation popups? should it be included in the print/PDF view? >> etc) >> - should not be too much work for the community to do it (e.g. adding a CSS >> class to every article maintenance template is probably easy since they tend >> to use common frameworks; adding a parameter to the thumbnail wikicode in >> every such template is probably not so easy). >> >> Some things that should be excluded: >> - things that don't really belong to the article content (such as >> maintenance templates, icons in signatures on a talk page) >> - things that belong to the article but are technically too tricky to work >> with MediaViewer (e.g. various CSS map hacks) >> - things that belong to the article but MediaViewer does not offer a good >> user experience for them (some people suggested very small images) >> >> One option could be to leave the details to each wiki community, e.g. read a >> jQuery selector from a MediaWiki page or a JS variable, or even use a hook. >> >> _______________________________________________ >> Multimedia mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/multimedia >> _______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
