Last modified: 2011-03-13 18:06:27 UTC
Currently imagemaps produce images in <div>s. This prevents them from beeing used in text. If there is a link to the description page, it is obviously needed. But for "desc none" there should be an option to inline the image. I propose an option "inline", which couses the image to be inlined. "inline xxx" may affect the vetical alignment.
Created attachment 4808 [details] proposed change ((Somehow the patch was not uploaded by commitin the patch, sorry.)) It does not contain the i18n, because diff seems to eat up the utf8 characters. New error messages: imagemap_wrong_valign, imagemap_inline_desc.
This could have implications on the proposed solution to several other imagemap bugs, notably 8718, 8788 and 9126. Why would one be inlining the image? What is meant by "inline" in this context anyway? Are we talking about a tiny image that is in a line of text or an image with text flowing around it?
Yes, with "inline" I mean tiny images with text flowing around. Sorry, but my English is not this well. I do not think that this bug is related to the bug mentioned by you. By now <imagemap>s encapsulate the images in <div>, so that they produce an own paragraph. Take a look at [[de:Main page]]. At the bottom of the page the sister projects (Schwesterprojekte) are linked. Every sister project link at de: has got such an image. To make them not breaking the paragraph, a strange CSS hack is needed. I only want images without an description link to be useable in flowing text. (In reply to comment #2) > This could have implications on the proposed solution to several other imagemap > bugs, notably 8718, 8788 and 9126. Why would one be inlining the image? What > is meant by "inline" in this context anyway? Are we talking about a tiny image > that is in a line of text or an image with text flowing around it?
It's not your English - inline is used ambiguously a lot and I just wanted to clarify - thanks! This is a known problem and it relates to two of the bugs I described (the third is solved, in part, by the same solution as that for the others). I'm pretty sure this other bug fix would fix the present problem without the introduction of a new parameter. I put together a patch for those three and it was up-to-date for MW 1.10. I have it on my list of things to do to bring the patch up to MW 1.12 standards. I wish someone was able to look at this and clear the fixes. It could have been done several times in the last year and now it must wait till I have time to do the latest round of fixes.
I definitely don't see a use case for inline image maps. (If you're abusing the imagemap extension as a workaround for bug 539, well, I'd rather get a proper fix for bug 539!)
