How about just .unrelated? Simple to understand, following the criteria you just mentioned. More human readable than something more technically correct such as .nommw Med vänliga hälsningar, Jan Ainali Verksamhetschef, Wikimedia Sverige 0729 - 67 29 48 Tänk dig en värld där varje människa har fri tillgång till mänsklighetens samlade kunskap. Det är det vi gör. Bli medlem.

I guess the best class name would be one that indicates that the image is for viewing 'in the flow of the article only', and isn't really meant for viewing as a standalone image (which is what you would use the mediaviewer for). So maybe something like: for-page-only media-reliant media-secondary media-navigational I guess prefixing it with 'media' would not be a bad idea as well to avoid having it clash with other classnames (that's why 'hide' or 'noshow' would probably be too generic). -- Hay On Mon, May 12, 2014 at 9:48 PM, geni <geniice(a)gmail.com> wrote: > I'd probably go with multiple descriptive classes rather than a single tag > if you are looking for future proofing. > > *navigational > *maintenance > *award > *protection >

.not-multimedia or maybe reverse the logic and only allow tagged items to appear in media viewer .multimedia with kind regards, dan On May 12, 2014, at 21:32 , Fabrice Florin <fflorin(a)wikimedia.org> wrote: _______________________________________________ Multimedia mailing list Multimedia(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

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 with kind regards, dan On May 12, 2014, at 23:19 , Fabrice Florin <fflorin(a)wikimedia.org> wrote: _______________________________________________ Multimedia mailing list Multimedia(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

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.

On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke <gwicke(a)wikimedia.org>wrote;wrote: Most images are hosted on Commons, so that would mean the Commons community would configure how images are used on other wikis. I am not sure if that is a good or bad thing. It would certainly mean less work for editors, and the work would be done by those who know the most about images. On the other hand different wikis have different conventions, and tend to take affront if conventions from other wikis are forced on them. _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke &lt;gwicke(a)wikimedia.org <mailto:gwicke@wikimedia.org>> wrote: Another option is to make this a property of the image rather than it's use site. That should cover the typical icon well, and with minimal editor effort. Most images are hosted on Commons, so that would mean the Commons community would configure how images are used on other wikis. I am not sure if that is a good or bad thing. It would certainly mean less work for editors, and the work would be done by those who know the most about images. On the other hand different wikis have different conventions, and tend to take affront if conventions from other wikis are forced on them.

We already have a class for that .metadata (also excluded from print, book collections, WP 1.0 etc) Very small images we can just exclude by algorithm, data-file-width and data-file-height will tell us this right ? 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 &lt;gtisza(a)wikimedia.org&gt; wrote: > On Mon, May 12, 2014 at 2:47 PM, dan-nl &lt;dan.entous.wikimedia(a)gmail.com&gt; > 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 >

Making it specific to the idea of a "viewer" (e.g. "no-viewer", "viewer-exclude", or "for-page-only") is better in my opinion, but only marginally so. I'd recommend aiming for something that reflects what it is and allows separation of concerns. Then have MMV use that in its filters. This may mean we'll need two instead of one if the types of images in this category are that different, but that would imho be a good thing.

<code><nowiki><span class="metadata">[[File:Foo.jpg]]</span></nowiki></code> * For images that are not metadata, but which don’t really render well in Media Viewer, consider using a '[[:w:Wikipedia:Extended_image_syntax#Images_that_link_somewhere_other_than_the_image_description_page|link parameter]]' to disable them in Media Viewer: <code><nowiki>[[File:Foo.jpg|link=]]</nowiki></code> <br>

Instead of introducing complicated syntax, would it not be better that media viewer only displays thumbs?

for example infobox main images, gallery templates, images on the main page...

The main page seems to be such an obscure case that it might be adressed when we have a better idea than forcing millions of exception edits what you think?

this is may be a long-shot, but what about allowing all files from the /images/ directory and excluding images from any other directory? the assumption being that icons and other "helper" images will come from directories other than /images/.

On May 12, 2014 4:32 PM, "Fabrice Florin" &lt;fflorin(a)wikimedia.org&gt; wrote: Probably much harder to implement... but it might be more consistent to have it as part of the file embedding syntax. E.g. [[file:foo.png|thumb|no-viewer|...]] --bawolff _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

On Mon, May 12, 2014 at 2:54 PM, bawolff &lt;bawolff+wn(a)gmail.com&gt; wrote: > > Probably much harder to implement... but it might be more consistent to

This would make our file inclusion syntax, which is an atrocity that

[various suggestions about having some sort of system picked out by users]