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
<hartman.wiki(a)gmail.com> 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 <gtisza(a)wikimedia.org> wrote:
> On Mon, May 12, 2014 at 2:47 PM, dan-nl <dan.entous.wikimedia(a)gmail.com>
> 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
> Multimedia(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/multimedia
>