Template talk:Auto images

Width Problem

There's a width mismatch between two consecutive auto images, with the second one's cont parameter set as "yes". here is an example. Windroff (talk) 20:20, 18 August 2013 (UTC)[reply]

Good catch! It seems to arise when there are a different number of images in each row. I'm not yet sure whether it's a rounding issue, in which case it is likely to be difficult or impossible to fix because of the limitations of the template language or whether there's a logic error in the width calculations. I'm investigating. Peter coxhead (talk) 21:50, 18 August 2013 (UTC)[reply]

I've implemented a fix, which seems to work on all the cases I've tested. I'm never sure if there are any browser-specific features in the display of images in this way, so please let me know if you see any consecutive sets which don't line up properly. Peter coxhead (talk) 22:56, 18 August 2013 (UTC)[reply]

By the way, it can't be guaranteed to work within 1 pixel either way because of inevitable rounding errors – each row of auto images does the calculations independently so may not come up with exactly the same total width allowing for rounding. Peter coxhead (talk) 22:59, 18 August 2013 (UTC)[reply]

Thank you very much. It works with all combinations I tested so far. Windroff (talk) 23:11, 18 August 2013 (UTC)[reply]

Caption alignment

I added a parameter to the template sandbox to set caption text alignment. You can see comparative results in the testcases page. It saves quite a lot of typing for transclusions with many images. Windroff (talk) 21:48, 7 April 2014 (UTC)[reply]

Seems a very good idea. I'll move the change to the real template. Peter coxhead (talk) 10:04, 8 April 2014 (UTC)[reply]

Done Peter coxhead (talk) 10:19, 8 April 2014 (UTC)[reply]

Thank you. I changed the parameter name to the respective HTML property name, because it sets alignment for the footer in addition to image captions, and it's more intuitive this way. Windroff (talk) 15:02, 8 April 2014 (UTC)[reply]

Ok, I like brevity myself but it's perhaps clearer now. Peter coxhead (talk) 21:09, 8 April 2014 (UTC)[reply]

Float

I added a parameter to the template sandbox to float the template. You can see comparative results in the testcases page. It should not interfere with existing transclusions that use the div enclosure workaround. Windroff (talk) 21:48, 7 April 2014 (UTC)[reply]

@Windroff: what is the difference between |align= and |float=? seems confusing to have both? If the intent is to wrap text as well, then we should add a |clear= option? Frietjes (talk) 01:58, 10 April 2014 (UTC)[reply]

@Frietjes: The goal is to let text wrap around the table without having to do it with HTML.

|align= was already there and it may be in use in several transclusions; it moves the table to the requested side and sets the opposite margin so there can be no text wrapping.

|float= acts like the CSS float property (wrapping text around)

To avoid confusion the template could be changed so if |float= is set (e.g. to "yes") the table would float to the side set by |align=, leaving the usual no-wrap behavior when unset. Windroff (talk) 05:12, 10 April 2014 (UTC)[reply]

personally, I would like to see |align= and |float= do the exact same thing, if both parameters are available, and have an option for |clear=none to avoid text-wrapping, but text-wrapping would be the default. with only 202 transclusions, we can just check all the uses and fix them to make sure there are no actual changes in the layout. Frietjes (talk) 18:37, 10 April 2014 (UTC)[reply]

okay, I added float, with possible values of 'left', 'right', 'center', and 'none', and a tracking category for align. if float is not set to one of these four values, then the template should function the same as before. but, this should allow us to get rid of the div hacks in the articles, as well as most clear hacks. the old |align=left should be essentially equivalent to the new |float=none (just like images with none). I will wait for the tracking category to populate, then check the transclusions that use align. Frietjes (talk) 19:30, 10 April 2014 (UTC)[reply]

@Frietjes: Thanks. Perhaps "none" should have a more descriptive alias ("clear_left" ? ) and another choice ("clear_right" ? ) should be added for automatic inclusion of the {{clear right}} template. Windroff (talk) 21:09, 11 April 2014 (UTC)[reply]

@Windroff: just matching the syntax of {{multiple image}} and standard picture syntax, which seems like a good idea if editors already know standard picture syntax? however, I have no problem with adding more options for |align= and/or |float=. the whole {{clear right}}/{{clear left}} template thing is confusing since you probably just want to clear both. Frietjes (talk) 21:17, 11 April 2014 (UTC)[reply]

by the way, I didn't find any usage of the non-wrapping text feature with align right in the articles that I checked, so it seems like it's not going to be needed much in practice. Frietjes (talk) 21:23, 11 April 2014 (UTC)[reply]

I just added two explicit nowrap options to the aux template sandbox. Could {{clear left}} be replaced by margin:auto or is it really needed? Windroff (talk) 21:39, 11 April 2014 (UTC)[reply]

looks good. as far as I can tell, left, right, center, and none cover all the existing usage, but I may have missed one. aligning right with no text wrapped seems very rare, if not entirely not needed. Frietjes (talk) 16:54, 12 April 2014 (UTC)[reply]

I merged the changes, adding "right_nowrap" only for the sake of completeness. I also updated the documentation, removing the "embedding text" section because it's the default behavior now. Windroff (talk) 22:08, 12 April 2014 (UTC)[reply]

Layout

I modified the table's layout to make it look more like {{Multiple image}} and plain images, and to let each row of pictures seamlessly merge with the previous one. Changes are in the template sandbox. You can see comparative results in the testcases page. Windroff (talk) 06:16, 17 April 2014 (UTC)[reply]

To clarify, so far as I can see, this change is solely to the numbers in the calculation of ht. I can only say that I arrived at the original numbers by a lot of trial and error, including viewing on different browsers and different operating systems. For example, the values I used at first, which worked under Firefox under Mac OS X (my normal combination), did not work for IE under Windows 7. I'm certainly not saying that other values such as yours won't work, but I would urge great caution in changing these values until you have checked complex layouts with as wide a range of browsers as possible. There are significant differences in the way in which browsers handle some kinds of layout. Peter coxhead (talk) 08:45, 17 April 2014 (UTC)[reply]

While there's a rationale behind the change of numbers, I see no improvement over the originals in the cases I tested so far. As for the layout changes, they are here {{Auto images/aux/sandbox}}. Windroff (talk) 20:57, 17 April 2014 (UTC)[reply]

I'm not quite sure what you're saying about the version you left in the sandbox. Are you saying that as a whole it isn't an improvement over the originals? It would be useful to see a page with complex sets of images laid out using the current template version and the sandbox version. Then we need to check them with different browsers and operating systems. When I was developing this template, I found that apparently small or even irrelevant changes altered appearance on some systems. Peter coxhead (talk) 09:08, 18 April 2014 (UTC)[reply]

I mean that your original numbers also work well for the modified template in aux/sandbox, so I restored them (although because these numbers are bigger, the table gets slightly reduced due to ht being smaller) Update: I set the padding numbers to "4" (2 to the left, 2 to the right) to fix a width mismatch between rows with different number of images (testcases "Complex 2" and "Complex 3")

Please have a look here. There are several examples using both the current template and the sandbox versions, including a quite complex case at the end. More should be added to compare the final appearances. Windroff (talk) 21:24, 18 April 2014 (UTC)[reply]

The narrower margin version at Template:Auto images/testcases#Float left doesn't work in Safari, Firefox or Chrome under Mac OS X 10.9. Instead of "Echinopsis candicans" over two lines, I see "Echinops candican", with only part of the following "i" and "s". So the wider margins seem to be necessary. The problem only occurs with italic caption text, so far as I can see: this is slanted to the right, and so goes beyond the right bounds of the image above. (It probably depends on the font used as well.)

Which browsers and platforms have you checked? Peter coxhead (talk) 08:58, 21 April 2014 (UTC)[reply]

That's intended and should work that way on every CSS2 browser. In the original template if any word is too long for the caption box width, text simply overflows and doesn't look right. It becomes worse with thinner margins, so the sandbox template adds the property "overflow:hidden" to clip the excess. The real fix is to increase total_width.

Display is fine in Chrome and Firefox on Windows 7. There are top border draw issues in IE

I added another testcase here to show the hiding overflow behavior. Windroff (talk) 02:58, 22 April 2014 (UTC)[reply]

Ah, I haven't expressed myself clearly. Obviously if there's a long word in the caption which is wider than the image above, there will be overflow. (I slightly prefer not having "overflow:hidden" because the error is then obvious and editors are more likely to correct it, but that's another matter.) The issue is that some captions display correctly with the current version of the template, but won't if the changes are implemented – that's the case with the example at Template:Auto images/testcases#Float left. So if this change is moved over to the main template, every use will have to be manually checked. Is it really worth doing this?

I suspect it's more likely to be an issue with italic caption text, since whether it extends further to the right is system and font dependent. So it's possible to have text which looks ok on one browser/system/font, because the italics are implemented within the same "character box" but not on another combination, where italics are implemented by right-skewing. (You see the same issue with some editors putting double spaces between italic text and following roman text because the spacing looks wrong on some set-ups.) My feeling is that allowing a reasonably generous margin is less likely to cause a editor using a particular set-up to choose a total width which looks right to them, but won't to viewers with a different set-up. Peter coxhead (talk) 11:28, 22 April 2014 (UTC)[reply]

have you tried 'overflow:auto' (adds a scrollbar instead of chopping the text)? Frietjes (talk) 14:46, 22 April 2014 (UTC)[reply]

@Frietjes: This was meant to account for browser specifics, hiding perhaps half a letter in some cases without altering much the aspect of the table. Options such as "overflow:auto" and "word-wrap:break-word" produce too drastic changes for even the tiniest overflows. Windroff (talk) 15:36, 22 April 2014 (UTC)[reply]

@Peter coxhead: Please have a look at the actual HTML in the previous aux sandbox. The clipped text that you saw is due to the 2px margin on each side of the caption box, that I added to avoid long text being visually fused between consecutive images. This causes the actual content space to become smaller and thus any excess to be cut out. In the testcases I set the same "total_width" in every pair of examples for the sake of fair comparison, but this shouldn't happen in real usage where editors would simply pick the "total_width" that looks good.

My issue with wide margins is that they are inconsistent with {{multiple image}} and plain [[File:]] images and in small tables they take quite a bit of space that should be for the pictures themselves.

I removed the 2px caption margins and the overflow control here, so it should behave like your original version now. Nevertheless I think that some overflow handling should be enabled. Windroff (talk) 15:22, 22 April 2014 (UTC)[reply]

I think that any change to the template which can alter the appearance of existing articles should be avoided unless it fixes a bug, although I agree that ideally the visual appearance should imitate {{multiple image}}. (I didn't start with the idea of having wide margins; they just evolved by trial and error until my test examples looked more or less the same on all the browsers I was able to try.) Peter coxhead (talk) 21:43, 22 April 2014 (UTC)[reply]

is there any reason why we don't just make this a frontend for {{multiple image}}, and just have this template compute the widths? Frietjes (talk) 00:31, 23 April 2014 (UTC)[reply]