This should be right aligned

As I understand it, «Location = right» should position the image box on the right of the page. This is no longer working. Would anybody be able to fix this? (Location = tright is a poor workaround; the thumb then lacks padding on the right) —WOFall (talk) 17:58, 28 May 2010 (UTC)[reply]

 Done —CodeHydro 22:21, 12 September 2010 (UTC)[reply]

Thanks, I wasn't sure it was the right solution. I made a further edit to give the same padding as normal right-aligned images get (although I don't entirely understand why it was necessary). —WOFall (talk) 23:24, 12 September 2010 (UTC)[reply]

• Actually, I figured out the problem. There was an extra style="..." in the code in the first div tag. It has been fixed. I also made it so it doesn't matter if you use tright or right, tleft or left; it should work either way in case some folks did the workaround. —CodeHydro 23:36, 12 September 2010 (UTC)[reply]
• And now, this has been even further fixed to allow for empty descriptions without creating the thumbs box like this:

—CodeHydro 00:32, 13 September 2010 (UTC)[reply]

Hello, If I crop different portions of the same base image several times in the same article, is this unique base image sent several times over the internet to the browser, or is it sent once and then reused from the browser memory buffer ?

The idea is to create a base image representing a gallery of portrait thumbnails (about 30 people), and then crop this gallery to extract the right portrait to the right place (genealogy). If I had to dynamically resize all the individual portraits, the page size would be huge (about 50 Mb) and the downloading would also take too much time.

You can find here an example of what I wish to achieve visually -- but want to avoid technically. -- Olivier1961 (talk) 10:47, 15 October 2010 (UTC)[reply]

• Hi, the whole image is downloaded either once ever (until your clear your browser's cache), or once per page load--depending on your browser and its settings. Any reasonably-designed browser should not download more often than once per page load; those that do, if they exist, probably cannot hold onto more than 0.01% of internet users in today's competitive browser market. —CodeHydro 17:49, 18 October 2010 (UTC)[reply]
  • Thank you for your answer, you confirmed what I suspected already, I just wanted to be sure before going on with my project! -- Olivier1961 (talk) 21:40, 18 October 2010 (UTC)[reply]

This template needs a sandbox. I will use Template talk:CSS image crop/sandbox in the meantime. 84.127.80.114 (talk) 16:09, 20 August 2014 (UTC)[reply]

I'm not sure I understand, but I guess you couldn't create the sandbox because you're an IP user? Moved to Template:CSS image crop/sandbox. —WOFall (talk) 16:35, 20 August 2014 (UTC)[reply]

Thanks. 84.127.80.114 (talk) 17:00, 20 August 2014 (UTC)[reply]

Please compare List of Presidents of the United States (mobile) with List of Presidents of the United States (desktop). On mobile, the images seem resized instead of cropped. -- [[User:Edokter]] {{talk}} 17:33, 29 August 2014 (UTC)[reply]

 Done Heh, mobile version of Wikipeida didn't even exist when I had originally re-built this template back in 2010. Fixed now. Three separate CSS parameters had to be patched to get it to work and I had to read through most of the 300+ paragraphs of CSS code in Wiki mobile's style sheet to find the little buggers :\ —CodeHydro 23:30, 29 August 2014 (UTC)[reply]

@Edokter: do I understand correctly that you've replaced the magnify-link parameter with Link? The documentation needs to reflect the change if so. I'd also suggest including it in one of the testcases you created. Cheers. —WOFall (talk) 13:27, 6 December 2014 (UTC)[reply]

I did replace it... mainly because it wasn't documented at all. So I don't know if it is even in use, but I figured that |Link= is closer to the original image syntax. (I may also add/replace |Description= with |Caption= and make the parameter names case insensitive.) -- [[User:Edokter]] {{talk}} 13:42, 6 December 2014 (UTC)[reply]

The change is fine, but you're mistaken about it not being documented (I agree however that it's probably very rarely used). I've removed magnify-link from the doc page, and also added Link because there doesn't seem to be a reason for it to be hidden. |Caption= sounds fine too, apart from the obvious migration concerns. —WOFall (talk) 15:42, 6 December 2014 (UTC)[reply]

• I just discovered that magnify-link is actually used on a hundred pages which have been broken. A lot of them appear to be transclusions via templates [1], with the magnify-link allowing each section of the image to navigate to a different wikipedia article (as opposed to the image file, which they have been doing when magnify-link was removed). Added a category to track it at Category:CSS image crop using invalid Link format —CodeHydro 14:44, 14 December 2014 (UTC)[reply]
  • I did that on pupose... Even though the image itself can link to anything, the magnify icon should always link to the image being displayed. (Even though 'real' thumbs don't do that.) But fine... We need a bot to clean this up. Also, the {{magnify icon}} template is rather pointless and only requires unneeded parser functions. -- [[User:Edokter]] {{talk}} 17:41, 14 December 2014 (UTC)[reply]
    • On closer examination, magnify-icon should be a separate parameter from Link. See how [2] is a cropping of [3]. Now that I've separated them, I can see that templates such as {{IrinotecanPathway WP229}} are not entering a file into the Image parameter, but instead using {{Annotated image}}. Since that which is being cropped is not an image file, magnify-link must be specified so that there is a link to the image file. Moreover, note that the way it's set up for {{IrinotecanPathway WP229}}, clicking on the image leads to an article rather than the image. —CodeHydro 16:12, 15 December 2014 (UTC)[reply]

It should probably be pointed out that the way they're using CSS image crop is completely invalid, and I'm amazed that it renders properly in the end. —WOFall (talk) 16:27, 15 December 2014 (UTC)[reply]

Your latest series of edits re-introduced the <p>...</p> bug again. I have protected the template; test all your edits in the sandbox and then discuss them here. Also, if this keeps going, we end up right where we started. So we should decide on parameters now; Any invalid parameter in use is just bad luck. -- [[User:Edokter]] {{talk}} 16:37, 15 December 2014 (UTC)[reply]

Well sorry for the introducing an extra line break into the description. That was however much less visible than the display bug you caused when you removed {{magnify-icon}}, which rendered the description completely unreadable for pages that used magnify-link. —CodeHydro 16:49, 15 December 2014 (UTC)[reply]

@Edokter: Thanks for your recent patch. Just be careful about removing "redundancies" as it did break the template under certain conditions. Some redundancies are to allow the template to tolerate input based on older versions of the template. Anyhow, I have fixed it. Good job re-organizing the code to make it more human-readable. Would certainly make it easier for others to maintain. Good job! —CodeHydro 19:42, 6 December 2014 (UTC)[reply]

It was broken either way. How many pass bSize with 'px'? If just a few, then those should be fixed. -- [[User:Edokter]] {{talk}} 19:49, 6 December 2014 (UTC)[reply]

Yeah, the template is a hack of Wikipedia's CSS, which causes it to break on the occasion that Wikipedia decides to change the CSS class names. In any case, it's really hard to tell how many pages use px or not. I have no idea how many pages pass 'px' with bSize, but considering that the original documentation specified to include px, it's quite likely not a small number. —CodeHydro 19:55, 6 December 2014 (UTC)[reply]

CSS is not the issue here; it's louzy parameter setup and documentation. There are several forks as well, all with their different parameter names and specs. I intend to merge them all, the functionality is now working as it should. -- [[User:Edokter]] {{talk}} 20:07, 6 December 2014 (UTC)[reply]

Yeah, I would have set it up differently if I had created it, but the situation is as we inherit it. Actually done a lot of work on merging versions, though it's proven to be quite the endeavor; One of the most interesting forks in in s:Template:Css image crop which added image rotation. But merging those features here without breaking anything may be a challenge. —CodeHydro 20:19, 6 December 2014 (UTC)[reply]

if you are going to remove the px stripping from bSize, you should remove it in all locations, not just in one. Frietjes (talk) 16:01, 7 December 2014 (UTC)[reply]

added transitional code and Category:CSS image crop using invalid bSize format to track pages requiring cleanup before the {{replace}} can be removed. Frietjes (talk) 16:46, 7 December 2014 (UTC)[reply]

I have created a tool that should make it easier for some folks to use this template available at User:Codehydro/Auto CSS image crop. You may audit the source code at User:Codehydro/Auto CSS image crop/script.js. I'm pretty sure that user scripts in my namespace cannot be edited by anyone other than myself, so as long as you trust me, then the script is safe ;) Happy cropping! —CodeHydro 16:42, 8 December 2014 (UTC)[reply]

Thanks for the script. I think it was broken yesterday, but it works for me now. I think we should mention it somewhere, at least under "see also". Opinions, Edokter? —WOFall (talk) 17:12, 8 December 2014 (UTC)[reply]

Edit: It works well in chromium. In firefox it "works", but doesn't display the raw template for copy-pasting. —WOFall (talk) 17:17, 8 December 2014 (UTC)[reply]

Firefox issue fixed. Good catch! —CodeHydro 18:39, 8 December 2014 (UTC)[reply]

• Major upgrade to the template generator! Made it even more easier to use. New features such as "click to crop". See advanced section for more details. (It's about as user-friendly as you can get in 14 KB of code!) —CodeHydro 00:45, 17 December 2014 (UTC)[reply]

• I've moved most of the functions to User:Codehydro/Auto CSS image crop/functions.js and left a relatively small loader in scripts.js so that users won't be downloading the whole tool every time they refresh the page. The loader will however provide a button for quick access to the tool when editing pages unless disabled (see documentation) —CodeHydro 21:29, 17 December 2014 (UTC)[reply]

As mentioned above, certain templates ({{IrinotecanPathway WP229}}) are using |Image={{Annotated image}}, and specifying |magnify-link= to fix the magnify-icon. Assuming we bless this template combination, I suggest:

• Drop |magnify-link=
• Add |AnnotatedImage={{Annotated image}}, always combined with |Image=underlying-image.

Image would always be used as the magnify-icon link.

This would also clean up the output, rather than generating [[File: ...]] with the output of {{Annotated image}} (a div block) dumped in the middle. Otherwise we could consider this combination broken and remove magnify-link anyway. —WOFall (talk) 19:15, 15 December 2014 (UTC)[reply]

As above but with the name |ImageDiv= rather than |AnnotatedImage=, see Template:CSS image crop/testcases § Annotated Image. —WOFall (talk) 21:10, 15 December 2014 (UTC)[reply]

• While that may have been the better route if suggested when the first guy decided to use Annotated Image with CSS image crop, but implementing this now would just be a big hassle. Though they're not ideal, the current parameters work just fine IMHO. Why fix what isn't broken? :) —CodeHydro 21:34, 17 December 2014 (UTC)[reply]

Would you call it a big hassle? I'm imagining this is only done in a handful of "master" templates (these?) where occurrences could be quickly replaced by hand (reinstating the magnify-link tracking category would help). I don't see the hassle, but it will hardly upset me if the change isn't made. If we thought this combination would be used in future it'd be best to change it now to make sense, but in reality the existing usages are exceptional and probably singular. —WOFall (talk) 22:15, 17 December 2014 (UTC)[reply]

Well, if it is actually restricted to just the master templates then perhaps it wouldn't been overly difficult. However after the magnify-link fiasco, I'd be wary of making assumptions about how limited in scope certain implementations may be. Don't get me wrong, it's not a bad idea. But in the end, we don't know how many pages combine CSS image crop with another template. There may even be cases where something other than Annotated image is used on single articles. Because of the nature of the CSS in this template, I imagine it doesn't matter if it's not fed an image; we could use {{chart}} and it should work as long as we'crop it in a way that the extra [[File:..]] tags are hidden beyond the crop. Perhaps the more flexible thing would be just to rename this CSS crop and provide a parameter like not_an_image = true to suppress the File tags. heck, I'll test it out....

Yep {{chart}} works as I expected XD Imagine the possibilities this opens!!! —CodeHydro 13:53, 18 December 2014 (UTC)[reply]

• Just wanted to see if I can cut @Edokter: in half to show how most information in letters in conveyed by the top half of Latin letters:

Edokter Edokter

Edokter Edokter

Ah, the wrath of a white hacker... take that Edokter :P (PS: This is meant to be silly rather than any ill will. Please do not take offense) —CodeHydro 14:25, 18 December 2014 (UTC)[reply]

Why you... The fact is, the CSS is pretty basic and you can basically feed it anything with a fixed size. This template however works specifically with wiki-formatted images. And the main problem is there is a wildgrowth in parameter names. So my initial goal is to turn this into a meta template and make the rest into wrappers, and let those die out or be replaced by a robot. -- [[User:Edokter]] {{talk}} 15:32, 18 December 2014 (UTC)[reply]

Is there a version for wikipedia in Spanish ? Thanks

Initial testing shows this can also support PDF files, but I'm unable to set a specific page. Is there a way to do it or does it need to be introduced?--Uwe a (talk) 12:48, 14 May 2015 (UTC)[reply]

How does one normally display a pdf and set a page? (The help page doesn't say.) If I know that it should be easy to add. -- [[User:Edokter]] {{talk}} 13:12, 14 May 2015 (UTC)[reply]

by using something like [[File:PIRETRINAS Y PIRETROIDES.pdf|page=3]]; but I dont know how to apply that to the template .--Uwe a (talk) 14:07, 14 May 2015 (UTC)[reply]

That is easy. I have added support for the |Page= parameter. -- [[User:Edokter]] {{talk}} 16:01, 14 May 2015 (UTC)[reply]

The template now shows even the file name in the captions if the Description parameter is used. A mod should check it out. Penpaperpencil (Talk) 16:49, 12 June 2016 (UTC)[reply]

Do you have an example? -- [[User:Edokter]] {{talk}} 17:19, 12 June 2016 (UTC)[reply]

Yes, the dew drop image in the template page itself is formatted like that. http://imgur.com/W95mYbL Penpaperpencil (Talk) 11:54, 24 June 2016 (UTC)[reply]

Hello. I'm looking into using this template on Wikibooks, where it could potentially be very useful. However, I'm running into an issue when an image needs to be anchored somewhere in the middle of a paragraph. The template causes long paragraphs to break where this is not wanted. (comment continues below)

Unwanted paragraph breaks[edit]

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

A drop of dew on grass

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Desired result[edit]

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

🗗A drop of dew on grass

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

(continued from above)[edit]

I'm not saying the above is necessarily the best possible way to achieve this, but MediaWiki has some annoying parser bugs and this is the best I could think of for the moment. If you can think of a better way, please edit away. I also think the ability to specify the crop coordinates in terms of the original image coordinates, not the resized coordinates, would be very helpful. I think that to achieve that an extra parameter would be needed specifying the original image size.

Is it possible to add Scale option to this template ? For now it seems to use only 100% scale, so it's not possible to use huge cropped images in articles. Mnavi (talk) 21:27, 5 August 2017 (UTC)[reply]

Mnavi: you can set any size in |bSize=. That will be the scaled original file, on which the crop is made. -DePiep (talk) 18:27, 18 September 2017 (UTC)[reply]

As reported on phab:T183822, the thumbnails' captions are not displayed correctly with Timeless: you can see it by scrolling down this Timeless view to the second caption.

Waiting for Timeless's skin to take this into account, it could be fixed either by copying the Vector/Monobook/... style applied to the ".magnify a" links to Timeless pages (using Mediawiki:Common.css), or simply by removing the discrete "Englarge" button. Automatik (talk) 17:49, 30 December 2017 (UTC)[reply]

As a workaround, I insert a pipe and space in magnify link, then this problem disappeared in testcase page. I hope adninistrators can receive my improve soon. --Great Brightstar (talk) 11:10, 14 January 2018 (UTC)[reply]

This HTML class will create a border the cropped image. This class should be actived by |Description= parameter if this image have a caption text, thus making the same appearence as other thumbnails in an article. I was already implemented in sandbox page.--Great Brightstar (talk) 16:49, 12 January 2018 (UTC)[reply]

Please could you give an example of how it looks now and how it will look after? — Martin (MSGJ · talk) 09:22, 15 January 2018 (UTC)[reply]

OK, but it's hard to accurate describe how it will look after, I give screenshots to you.

This is snipped from template dicumentation showing what it looks like: https://i.imgur.com/zLU8iCj.png

And here is what it will look with thumbimage class, snipped from test cases: https://i.imgur.com/vuigCiY.png

If you resize these images in 200% size, you will see a deep gray frame surrounding the image after using thumbimage class. This HTML class is already used in {{Annotated image}}. But since this template is full protected, I decided to implement in {{CSS image crop/sandbox}}, you can done just via pressing Ctrl + A to copy source code from sandbox page. --Great Brightstar (talk) 14:11, 15 January 2018 (UTC)[reply]

With this revision you'll also fix a bug with Timeless skin as above describe. --Great Brightstar (talk) 14:12, 15 January 2018 (UTC)[reply]

Okay well you seem to know what you're talking about, and no one has objected, so I have made the change. — Martin (MSGJ · talk) 09:16, 16 January 2018 (UTC)[reply]

Is it possible to insert cropped images in galleries? Eccekevin (talk) 00:13, 6 March 2021 (UTC)[reply]

@Eccekevin: It is possible to arrange a group of cropped images inside a frame, as shown here.

Cropped images in a frame

MediaWiki usually use additional <div> tag with center class to cover a thumbnail image for centering, I made the adoption in {{image frame}}, {{pseudo image}} and {{scalable image}}, and now I hope administrator can follow them soon. The proper code available at sandbox page and you can see the effects at test case page. Great Brightstar (talk) 04:29, 2 March 2022 (UTC)[reply]

Is there a reason that some of the sandbox cases do not match the live template? – Jonesey95 (talk) 05:08, 2 March 2022 (UTC)[reply]

And it's also curious that "Location" is used instead of the usual "align" parameter. Why the change? Won't that be confusing? P.I. Ellsworth - ed. ^put'r there 10:45, 2 March 2022 (UTC)[reply]

 Not done as there is ongoing testcase and concerns raised above. Once resolved feel free to reactivate the immediate edit request. — xaosflux ^Talk 15:06, 2 March 2022 (UTC)[reply]

 Done The Align parameter is added. --Great Brightstar (talk) 05:36, 3 March 2022 (UTC)[reply]

 Not done for now: The testcases are worse than they were before, because the live template does not have an |Align= parameter. Please reactivate this request only after the testcases match, or if they do not match, provide an explanation for why the non-matching cases differ. – Jonesey95 (talk) 06:13, 3 March 2022 (UTC)[reply]

OK, I got it. --Great Brightstar (talk) 01:04, 6 March 2022 (UTC)[reply]

 Done Thank you for your attention to detail on the testcases page. – Jonesey95 (talk) 05:47, 6 March 2022 (UTC)[reply]

I am attempting to use a cropped image in the infobox for an article, however the image is not automatically resized (shrunk) to fit the infobox. Does anyone know how to achieve this, as the Extended_image_syntax doesn't appear to work with a template image? Dpschramm (talk) 20:16, 16 April 2022 (UTC)[reply]

I'm asking the question too. If anyone have an answer that'd be great OtharLuin (talk) 11:50, 16 November 2022 (UTC)[reply]

@Dpschramm and OtharLuin: A bit late, but try Template:Easy CSS image crop: It lets you state the desired width, and then just state the percentage you want cropped off each side, which is probably easier. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 02:36, 3 February 2024 (UTC)[reply]

I got the rotation param to partially work with this template on Wikisource-en, but there's a problem with cropping. E.g. if you rotate 90 degrees, then both oLeft and cWidth crop from the left edge, though oTop and cHeight seem to be okay. Could someone check if it can be fixed?

See test wiki and a test image on my user page there, [4]. (I'm trying to crop to the left-hand illustration.) Thanks. — kwami (talk) 00:13, 28 August 2022 (UTC)[reply]

On the regular page everything is ok, but on mobile the image looks very weirdly cropped. --Oleh325 (talk) 20:43, 7 September 2023 (UTC)[reply]

Those links are to the Ukrainian Wikipedia. Do you have a link to a page that is not working on the English Wikipedia? – Jonesey95 (talk) 13:20, 8 September 2023 (UTC)[reply]

Here is a good example. Thom Yorke's page, his image is aligned to the left even though it is aligned to the center (on mobile at least) Aternias (talk) 23:44, 20 October 2023 (UTC)[reply]

See below for fix. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 19:28, 5 February 2024 (UTC)[reply]

Go to Thom Yorke's page on mobile and you'll see his image is aligned to the left visually even though it is suppose to be aligned center according to CSS Image Crop. Aternias (talk) 23:48, 20 October 2023 (UTC)[reply]

@Aternias: I've put forth a requested that should fix this. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 09:43, 4 February 2024 (UTC)[reply]

@Frietjes: Unlike {{Multiple image}}, {{CSS image crop}} doesn't have a border=infobox parameter to display the image with a caption in an infobox. Can we add this feature to this template as well? Jarble (talk) 17:45, 5 January 2024 (UTC)[reply]

Usually captions are handled by the infobox. Just set caption = [caption] in the infobox. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 02:44, 3 February 2024 (UTC)[reply]

Change the opening code to:

{{#if:{{{Image|}}}|{{#switch:{{{Location|{{{Align|}}}}}}
| center | centre = <div class="center">}}<div class="{{#if:{{{Description|}}}|thumb <!--
-->{{#switch:{{{Location|{{{Align|}}}}}}
 | none | tnone | center | centre = tnone
 | left | tleft = tleft
 | right | tright = tright
 | #default = tright }}|<!-- if no description:
-->{{#switch:{{{Location|{{{Align|}}}}}}
 | none = floatnone  <!--  This line was changed -->
 | center | centre = center <!-- This line is new -->
 | left = floatleft
 | right = floatright}}}}">

It's that simple. You can leave out my two comments, they're just there to make it clear what's changed.

I've checked the test cases, and none of them change except the broken centering in the "without description" section under mobile view. Which is the bug being fixed, and also the only significant difference between mobile and non-mobile view.

This fixes the problem Aternias brought up. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 09:34, 4 February 2024 (UTC)[reply]

 Done * Pppery * _{it has begun...} 01:46, 6 February 2024 (UTC)[reply]

West Bengal Film Journalists' Association Award for Best Actress was using {{border}} templates on images. Then someone added an image with {{CSS image crop}} and wrapped it with {{border}}, which caused a div-span-flip lint error. The quick fix was to remove {{border}} from all the images. According to Redrose64, "regular images don't use <div>...</div> elements any more. They used to, but the MediaWiki software was altered at some point in the last few months so that images are enclosed in <figure>...</figure> elements." Can a similar fix be implemented to modify {{CSS image crop}} so as to to have inline-level output instead of block-level output? That way, it will be possible to put a {{border}} around {{CSS image crop}} images, just like regular images. —Anomalocaris (talk) 06:01, 26 March 2024 (UTC)[reply]

No, because <figure> tags in wikitext don't render at all, as you can see here. * Pppery * _{it has begun...} 01:18, 31 March 2024 (UTC)[reply]

Also, putting the border template around an image appears to be a misuse of that template, per its documentation. – Jonesey95 (talk) 20:12, 1 April 2024 (UTC)[reply]

Jonesey95: Why do you say that? Documentation says, "Basic usage is {{border|element}}, where element is the image, text, etc around which the border is to appear." —Anomalocaris (talk) 03:58, 4 April 2024 (UTC)[reply]

I was just going by the first section of the /doc, which is then contradicted by the body. Oh well. I have added |div= in {{border/sandbox}} to swap a div tag for the default span tag. You can see it working on the testcases page for that template. – Jonesey95 (talk) 14:14, 4 April 2024 (UTC)[reply]

Jonesey95: The offending markup that started this discussion was

{{border| {{CSS image crop
|Image =  The Team of MEGHNADBADH RAHASYA at the screening of their film, during the 48th International Film Festival of India (IFFI-2017), in Panaji, Goa on November 22, 2017.jpg
|bSize = 1200
|cWidth = 100
|cHeight = 145
|oTop = 130
|oLeft = 500
|Location=center|95px}}|width=2px|style=solid |color=gold}}

substituting {{border/sandbox}} doesn't make the div-span-flip error go away. —Anomalocaris (talk) 18:00, 4 April 2024 (UTC)[reply]

You need to use |div=yes, as I did at {{Border/testcases}}. – Jonesey95 (talk) 21:29, 4 April 2024 (UTC)[reply]

Since the change appears to work fine, I have implemented my sandboxed change to {{Border}} and updated its documentation. To wrap this template, use {{Border}} with |div=yes. – Jonesey95 (talk) 17:21, 5 April 2024 (UTC)[reply]

* Pppery *: As I can see where? —Anomalocaris (talk) 03:58, 4 April 2024 (UTC)[reply]

In the very comment I wrote. If <figure> tags were supported then the raw HTML in that comment and this one wouldn't be displayed. Instead, they are. * Pppery * _{it has begun...} 03:58, 4 April 2024 (UTC)[reply]

* Pppery *: Yes, I figured it out, but you had already replied, thanks. —Anomalocaris (talk) 04:14, 4 April 2024 (UTC)[reply]