Wikimedia Bugzilla is closed!

With
 ul.gallery { display: inline-block }
instead of
 ul.gallery { display: block }
the gallerycaption would be in the middle.

But look at bug 3276, comment c33 for the reason of ul.gallery { display: block }

An other possible solution would be to limit the width of li.gallery to something like

 $width = number of images * 164px
 li.gallerycaption { max-width: $width }

A simple solution for Firefox would be

 ul.gallery { width: -moz-fit-content; }

> $width = number of images * 164px
> li.gallerycaption { max-width: $width }

With free flow gallery, you in theory can have 200 images, so you would get a rather strange number there, but I guess it can be done that way.

See Bug #27577 for more gallery issues.

Not a blocker for tarball but should be fixed.

display: inline-block instead of display: block works for me in Safari 5.

when there's a floating wrapper around the .gallery it works too.]

We should do some cross-browser testing first (IE6+, FF2+, Safari 3+, Opera, Chrome), but I dont expect any problems.

I think we switched from inline-block to block due to floating problems. Are you sure inline block works with all floats?

*** Bug 30010 has been marked as a duplicate of this bug. ***

I discovered a simple workaround: It seems wrapping the gallery in a div constrains the width to only the necessary width, then the gallery caption neatly centers over the images. 

That's probably an extremely easy way to fix this bug. Once fixed, the workarounds won't be necessary anymore, but still probably won't be affected if people are using them.

Did I just solve this bug?

The fix was tested on Opera and Google Chrome. I haven't tested other browsers.

(In reply to comment #9)
> I discovered a simple workaround: It seems wrapping the gallery in a div
> constrains the width to only the necessary width, then the gallery caption
> neatly centers over the images. 

Doesn't work here http://translatewiki.net/wiki/User:Raymond/gallery_with_caption
Div is a block-level element, meaning that it normally extends to the 100% width

I see, it looks like it needs to be floated for this trick to work:

<div style="float:left;">
<gallery caption="Cologne">
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
</gallery>
</div>

So, it's not quite as straightforward as I thought it was going to be, but I suppose it could still be workable like this:

<div style="clear:both;"></div>
<div style="float:left;">
<gallery caption="Cologne">
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
</gallery>
</div>
<div style="clear:both;"></div>

I think that would keep it from floating around more than expected, but it's starting to look like a dirty hack now, and limits user layout options. But, it does seem that the float property causes the width to be constrained to only the amount required. 

It quickly and easily solves the problem, but maybe causes new ones? I suppose with some more testing, it can be decided whether the ease of fixing the bug this way is worth the potential inconvenience of having it floated by default.

(In reply to comment #12)

> It quickly and easily solves the problem, but maybe causes new ones? I suppose
> with some more testing, it can be decided whether the ease of fixing the bug
> this way is worth the potential inconvenience of having it floated by default.

It looks better, but I don't like the last example here:

http://en.wikipedia.org/wiki/User:MarkAHershberger/Bug_Examples#with_the_div_hack

On my screen (1200px wide), the next section comes up without the "clear: both" hack.  With it, the way the first two float together would be prevented.

Another minor issue is that when an image gets pushed down to a new row on a smaller screen, the gallery caption/title still isn't quite centered until the screen is resized to displace the area that the pushed-down image used to occupy.

It looks like that happens in all cases, even without the div hack. As the rows of images wrap, the containing element isn't snapping to the minimum possible size - instead it remains bumped up against the edge of the screen. That extra width causes the "center" to be in the center of that portion of the screen instead of the center of the gallery.

Although the div hack is an improvement in most cases, the underlying problem seems to remain to a lesser degree on screens small enough to cause the gallery row(s) to wrap.

Given that the "clear:both" hack is always necessary to prevent wildly floating galleries, and the div hack in general works most of the time, but still has a flaw in screen sizes that result in gallery wrapping, is it acceptable, given the simplicity of this solution? 

Is there another problem that I didn't notice? When do we decide the hack works good enough, versus not good enough? I'm afraid I'm not talented enough at this to offer something better yet, but it would be nice if we could do it without hacks that might frustrate somebody trying customize the gallery positioning themselves.

So, I think it is time for a patch.

I suggest making this patch depend on the perrow attribute

Care to take a stab at that?

Look at includes/ImageGallery.php around line 232: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/ImageGallery.php?revision=92341&view=markup#l232

I think that you can do this if you test if $this->mPerRow == 0 and, in that case, set $output up with the first part of the div hack.  Then go down to line 352 and make sure the second part of the div hack gets added when perrow == 0.

If you can write the patch, I'll review it and apply it.

(In reply to comment #15)
> So, I think it is time for a patch.

We don't need the rather ugly div hack. display:inline-block has exactly the same effect and exactly the same downfalls as well:

A floated image before an multirow gallery behaves differently then before. I say differently, not worse, because previously it was weirdly inserted into the gallery, now it's just above, so neither case strikes me as being better than the other one. Anyway, some quick evaluation revealed, that these constructs actually display a bit different in IE, and even FF vs. Chrome, so it's not breaking anything  that was reliable before.

(In reply to comment #14)
> Another minor issue is that when an image gets pushed down to a new row on a
> smaller screen, the gallery caption/title still isn't quite centered until the
> screen is resized to displace the area that the pushed-down image used to
> occupy.

This is not easily soved with CSS, I even tried those new display: -moz-box, but that's not for us here.
We could just left-align the caption and the problem would be much less visible

-mox-fit-content would be the best solution, if it were understood by others.. 
Fixed wih inline-block in r93581 . 
I'll leave this open for now, regarding a left align of the caption: Any opinions on that?

I like your solution.  At least on Opera, FF and Chrome.  Someone should test IE.

(In reply to comment #19)
> I like your solution.  At least on Opera, FF and Chrome.  Someone should test
> IE.

Incidentally, it was already fixed there ( due to the zoom:1, display: inline !ie; hack, which is applied to both ul and li )

I am enthusiastically in favor of simply left-aligning it. I don't think the advantages of centering it are worth all this developer/tester/debugger attention. There are more important things to work on.

I am usually dissatisfied with fancy things that don't work well, when given the choice to have less fancy things that are boring, predictable, and simple, but work flawlessly every time, for everyone.

I think the best solution would be to drop the attribute caption for gallery. Content in an attribute is bad because it is not possible to use Wiki syntax. I suppose the attribute caption was added to gallery a few years ago to create the HTML element caption for the gallery table. Now gallery uses ul instead of table. The caption is now in the first li element. This is a bad semantic. When somebody wants a caption for a gallery he can use a table with caption:

{|
|+ Caption ''with'' Wiki syntax
|<gallery>
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
Image:Köln Panorama.jpg
</gallery>
|}

I think that is a good solution also, and much simpler. I like having a caption, but if it is semantically incorrect, I can do without it.

It really is a problem with Europium. Do you see any problems with display: inline? It works suprisingly well, floats are as before and the width is correct as well.

(In reply to comment #24)
> It really is a problem with Europium. Do you see any problems with display:
> inline? It works suprisingly well, floats are as before and the width is
> correct as well.

I'm getting lost.  Is your fix applied now or what?

The HTML5 idea of a caption is the element figcaption: http://www.w3.org/TR/html5/grouping-content.html#the-figcaption-element . figcaption can be used as the first or last child of a figure element. figure with figcaption can also used for other things besides images.

I think we should drop the attribut caption for gallery and add a new capability to create a universal caption with full [[wiki markup]] for galleries and other situations.

The Semantic MediaWiki people have standardized to call this universal caption parameter "intro" in all their parameter settings. Whenever there's a leading title caption thing, regardless of what it's on, you always set it with the "intro" parameter.

(In reply to comment #27)
> The Semantic MediaWiki people have standardized to call this universal caption
> parameter "intro" in all their parameter settings. Whenever there's a leading
> title caption thing, regardless of what it's on, you always set it with the
> "intro" parameter.

Do you think of intro/outro from http://semantic-mediawiki.org/wiki/Help:Inline_queries ?

{{#ask: [[Category:City]] [[located in::Germany]]
| intro=Intro ''with'' [[Wiki markup]]
| outro=Outro ''with'' [[Wiki markup]]
| ?population 
| ?area#km² = Size in km²
}}

intro/outro just create normal inline text but with the condition that the result of the query is not empty. outro is funny because it creates a pre element, when the first character after = is a space. intro/outro has nothing to do with figcaption.

For resolving this bug I suggest the following:

* Switch back to ul.gallery { display: block } because of the floating problem in [[de:Europium]].
* Remove li.gallerycaption { text-align: center; } to get a left-aligned caption which has no problems with aligning.
* Open a new bug for an universal caption with full wiki markup which uses figcaption.
* When this is implemented make the attribute caption for gallery deprecated.

You picked an example that, by itself seems to not be related. That is only one usage of intro and outro. Like I said, it's standardized, which means it's used other places too. 

For example, semantic results format "gallery" uses the standard "intro" to set the gallery caption. Everywhere, it is standardized as "intro".

(In reply to comment #18)
> -mox-fit-content would be the best solution, if it were understood by others.. 
> Fixed wih inline-block in r93581 . 

That change was reverted by r105995. Galleries are back to display:block;

ul.gallery {
	max-width:  intrinsic;         /* Safari/WebKit */
	max-width:  -moz-max-content;  /* Firefox/Gecko */
}

should work in Chrome, Firefox and Safari (https://developer.mozilla.org/en/CSS/max-width#Browser_compatibility).

An other possibility would be:

ul.gallery { display: table; }
li.gallerycaption { display: table-caption; }

It's not always 100%.... Look.. The WP-Example works, the second one not (if you use a screen like me... at least 1680px width)

https://de.wikivoyage.org/wiki/Benutzer_Diskussion:DerFussi#Gallery_Test