Basicaly some way to spesify an id and class value for an image *from the image description page*
Not sure what kind of syntax would be best for this, "traditional" magic words don't take parameters so something like __META id ="ifd" class="ifd"__ might seem "ugly" or strange, on the other hand a more function-ish appraoch like {{#meta: id="ifd"|class="ifd"}} would not be expected to have the effect I'm suggesting. Ideas on this would be most welcome ("meta" is probably not the best name either).
Anyway the general idea is this: By whatever means is deemed the best syntax it should be possible to spesify an arbitrary id and class value (except one that colide with existing "hard coded" values, maybe prefix all user spesified values in some way to avoid problems) for an image from it's description page. The "thumbnailing code" would then apply this to either the div or img tag of the image (depending on wether or not it's framed). The admins on any given Wiki are then free to add JavaScript functions and CSS classes to interact with the image in just about any way they can imagine.
For Wikipedia projects a few obvious uses are: "Highlighting" images that are marked for deletion, or as missing source info and so on in various ways. This may be as simple as adding a red border around the image, or making use of a JavaScript to superimpose a warning on top of the image or adding something to the image caption, add a explanatory tooltip or any number of other possibilities that are best left to each project to descide.
Replacing the visible thumbnail with a warning sign if a fair use image is used in User: space.
Optional (add some code to your user CSS/JS page) ability to have fair use, featured and various other kinds of images marked in special ways.
With a bit of effort it might even be used in combination with a template like {{fair use in}} to have a warning appear on the image if it's used in any other page than the one(s) mentioned in the tag (take the page name as the class parameter and have a JavaScript check against it).
I'm sure there are lots of other creative uses I can't think of right now.
I guess this would reqire a new row in the image table to store these values.
If at all possible this should work across wikis too, so an image marked for deletion on Commons would expose it's "deletion" class to all projects that use the image too (leaving it up to them how to "mark" the image localy).
Any reason something like this would *not* be possible (or desierable). There might be problems I haven't though about, but I think it would be a quite usefull feature. If allowing users to set arbitrary values are too "hard" a handfull of hard coded magic words (like __DELETION__ or whatever) would still be better than nothing, but the more flexible the better I would say. Accessability should not be a problem, if someone doesn't have JavaScript or CSS eneabled the worst that can happen is that everyting looks just like it does today with no extra "markings" on any images. Projects just have to be carefull not to use this layout purposes, just like they already have to be carefull not to rely on fancy CSS to make articles "work" properly.
If this is not totaly shot down I'm planning to submit a feature request via bugzilla, just wanted to get a bit of input from you guys first (like what would be the best syntax, any additional fetures that would be usefull related to this etc).
On 11/5/06, Sherool wrote:
Basicaly some way to spesify an id and class value for an image *from the image description page*
Not sure what kind of syntax would be best for this, "traditional" magic words don't take parameters so something like __META id ="ifd" class="ifd"__ might seem "ugly" or strange, on the other hand a more function-ish appraoch like {{#meta: id="ifd"|class="ifd"}} would not be expected to have the effect I'm suggesting. Ideas on this would be most welcome ("meta" is probably not the best name either).
Anyway the general idea is this: By whatever means is deemed the best syntax it should be possible to spesify an arbitrary id and class value (except one that colide with existing "hard coded" values, maybe prefix all user spesified values in some way to avoid problems) for an image from it's description page. The "thumbnailing code" would then apply this to either the div or img tag of the image (depending on wether or not it's framed). The admins on any given Wiki are then free to add JavaScript functions and CSS classes to interact with the image in just about any way they can imagine.
I assume the images have some unique id in the database anyway, so maybe it would be easier to just use that as the id, unless people didn't want to expose that for some reason.
It seems a little difficult because when I load an article with a image pending deletion tagged with, say, a {{DELETE}} magic word, where is the trigger to change the class for that image coming from? The parser would need to look at all the image pages every time it loaded an article checking for these magic words I guess. That might not be super difficult I don't know.
It does seem like a useful feature though, since so many images get added back, you start to think people don't realize why they were removed in the first place. :)
On Sun, 05 Nov 2006 18:47:44 +0100, cohesion cohesion@sleepyhead.org wrote:
On 11/5/06, Sherool wrote:
Basicaly some way to spesify an id and class value for an image *from the image description page*
Not sure what kind of syntax would be best for this, "traditional" magic words don't take parameters so something like __META id ="ifd" class="ifd"__ might seem "ugly" or strange, on the other hand a more function-ish appraoch like {{#meta: id="ifd"|class="ifd"}} would not be expected to have the effect I'm suggesting. Ideas on this would be most welcome ("meta" is probably not the best name either).
Anyway the general idea is this: By whatever means is deemed the best syntax it should be possible to spesify an arbitrary id and class value (except one that colide with existing "hard coded" values, maybe prefix all user spesified values in some way to avoid problems) for an image from it's description page. The "thumbnailing code" would then apply this to either the div or img tag of the image (depending on wether or not it's framed). The admins on any given Wiki are then free to add JavaScript functions and CSS classes to interact with the image in just about any way they can imagine.
I assume the images have some unique id in the database anyway, so maybe it would be easier to just use that as the id, unless people didn't want to expose that for some reason.
I was not thinking about a unique id, rater something like <img id="ifd">, although I just realised that this is not valid HTML since ID's are in fact supposed to be unique. So the ID bit, we can easily write a "getElementsByClass" function and just check for a given "class" value on all images in the article instead.
It seems a little difficult because when I load an article with a image pending deletion tagged with, say, a {{DELETE}} magic word, where is the trigger to change the class for that image coming from? The parser would need to look at all the image pages every time it loaded an article checking for these magic words I guess. That might not be super difficult I don't know.
I was thinking along these lines: When the image description page is updated and it contains the "magic word" the defined class name(s) are saved in a new database colum in the image table (isn't that roughtly how #REDIRECT works?, it's a bit in the database, the wikicode is not actualy parsed to see if a page is a redirect or not every time). When you call an image from an article I asume you have to look up the image table anyway to find the physical file location, so retrieving this class value in addition should (hopefully) be trivial. Then the "rendering" code would just check if the image have a class asosiated and stick it on the resulting <img> tag. Then it is up to the admins on the Wiki to actualy implement the CSS class and/or JavaScript code needed for this to result in any special formating/functionality to be applied to the image. At least that's how it would work in my head, not sure how compatable that is with the way MediaWiki actualy work :P
It does seem like a useful feature though, since so many images get added back, you start to think people don't realize why they were removed in the first place. :)
"cohesion" cohesion@sleepyhead.org escribió en el mensaje news:aa08c93c0611050947h40700292l4b6231e4ad5f4d4@mail.gmail.com...
On 11/5/06, Sherool wrote:
Basicaly some way to spesify an id and class value for an image *from the image description page*
Not sure what kind of syntax would be best for this, "traditional" magic words don't take parameters so something like __META id ="ifd" class="ifd"__ might seem "ugly" or strange, on the other hand a more function-ish appraoch like {{#meta: id="ifd"|class="ifd"}} would not be expected to have the effect I'm suggesting. Ideas on this would be most welcome ("meta" is probably not the best name either).
Anyway the general idea is this: By whatever means is deemed the best syntax it should be possible to spesify an arbitrary id and class value (except one that colide with existing "hard coded" values, maybe prefix all user spesified values in some way to avoid problems) for an image from it's description page. The "thumbnailing code" would then apply this to either the div or img tag of the image (depending on wether or not it's framed). The admins on any given Wiki are then free to add JavaScript functions and CSS classes to interact with the image in just about any way they can imagine.
I assume the images have some unique id in the database anyway, so maybe it would be easier to just use that as the id, unless people didn't want to expose that for some reason.
I think the unique id is the proper image name :-)
It seems a little difficult because when I load an article with a image pending deletion tagged with, say, a {{DELETE}} magic word, where is the trigger to change the class for that image coming from? The parser would need to look at all the image pages every time it loaded an article checking for these magic words I guess. That might not be super difficult I don't know.
It wouldn't be a problem. If it's stored as a new row on the db (as it should), the db is already queried when a image is stored on a page (does the image exist? what's their filename? etc) so getting another field there won't make trouble. I think the problematic bits would be on the cache. Cached pages don't check the db and they'd need to be purged (in fact some deleted iamges still show for a while on articles). Although we could rely on the job queue, i think it's impractical for rerendering all uses of a commons image (the same reason why checkusage spends so much time).
It does seem like a useful feature though, since so many images get added back, you start to think people don't realize why they were removed in the first place. :)
I like the idea. Good for those guys which are making an article and don't even see the warnings on their commons talk page of the fair use violations. Yes, it should be a class not an id. getElementsByClass may not need to be necessary. CSS may do everything needed.
wikitech-l@lists.wikimedia.org