Template talk:CSS image crop

2267: 2073: 2058: 2041: 2026: 1699: 1643: 251: 141: 1674: 1618: 21: 2753: 2652: 2099: 1829: 1247:) 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. — 2722: 2310: 2238: 444: 176: 2217: 101: 2971:{{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}} 1719:

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

1710:

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

1706:

1691:

1664:

1655:

1651:

1634:

1608:

790:

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

1599:

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

1423:

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

1269:

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,

827:

Yeah, the template is a hack of Knowledge (XXG)'s CSS, which causes it to break on the occasion that Knowledge (XXG) 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

451:

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

288:

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

311:

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

2409:

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?

1218:

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? :)

3139:{{CSS image crop |Image = Dew on grass Luc Viatour.jpg |bSize = {{#expr:400*2}} |cWidth = {{#expr:100*2}} |cHeight = {{#expr:100*2}} |oTop = {{#expr:180*2}} |oLeft = {{#expr:60*2}} |Location = center |Description = A drop of dew on grass (focus on the drop) }} 1066:

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)

221:

Actually, I figured out the problem. There was an extra 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.

721:

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.

284:

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 ?

157:

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)

592:

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

864:

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

848:

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.

568:, 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 2780: 1040:

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!) —

203:

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). —

2337:

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

3135:

This template doesn't have an option to change the scale of a cropped image without changing each parameter. I can do this by multiplying or dividing each parameter by the same number:

2695:

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.

1244: 1781:

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

1720:

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.

116: 644:. 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 958:. 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! — 1063: 2277:

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. –

1804:

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. --

979:

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,

955: 737:

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

41:. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by 1860:

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.--

1728:

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.

82: 1455:

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?--

686:

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. —

565:

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

293: 2528:

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.

1274:

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

1711: