Last modified: 2014-04-15 13:59:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T29540, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27540 - width of <gallery> always 100%
width of <gallery> always 100%
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.17.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://translatewiki.net/wiki/User:Ra...
:
: 30010 (view as bug list)
Depends on:
Blocks: 27577
  Show dependency treegraph
 
Reported: 2011-02-18 16:27 UTC by Raimond Spekking
Modified: 2014-04-15 13:59 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Raimond Spekking 2011-02-18 16:27:59 UTC
Related to bug 3276: fluid width of the gallery. 

The width of the <gallery> is always 100% now. Therefore the caption is not centered above the exisiting files, see example.
Comment 1 Fomafix 2011-02-18 19:19:59 UTC
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 }
Comment 2 Fomafix 2011-02-18 22:38:35 UTC
A simple solution for Firefox would be

 ul.gallery { width: -moz-fit-content; }
Comment 3 Derk-Jan Hartman 2011-02-19 12:46:52 UTC
> $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.
Comment 4 Mark A. Hershberger 2011-02-20 13:46:03 UTC
See Bug #27577 for more gallery issues.
Comment 5 Mark A. Hershberger 2011-04-04 18:19:42 UTC
Not a blocker for tarball but should be fixed.
Comment 6 Krinkle 2011-06-13 18:17:48 UTC
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.
Comment 7 DieBuche 2011-06-13 18:55:57 UTC
I think we switched from inline-block to block due to floating problems. Are you sure inline block works with all floats?
Comment 8 Mark A. Hershberger 2011-07-23 00:48:17 UTC
*** Bug 30010 has been marked as a duplicate of this bug. ***
Comment 9 badon 2011-07-27 06:08:06 UTC
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?
Comment 10 badon 2011-07-27 06:09:07 UTC
The fix was tested on Opera and Google Chrome. I haven't tested other browsers.
Comment 11 DieBuche 2011-07-27 08:16:11 UTC
(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
Comment 12 badon 2011-07-27 16:32:55 UTC
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.
Comment 13 Mark A. Hershberger 2011-07-29 01:27:23 UTC
(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.
Comment 14 badon 2011-07-29 19:46:27 UTC
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.
Comment 15 Mark A. Hershberger 2011-07-30 02:39:15 UTC
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.
Comment 16 DieBuche 2011-07-31 08:56:08 UTC
(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.
Comment 17 DieBuche 2011-07-31 09:07:39 UTC
(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
Comment 18 DieBuche 2011-07-31 09:27:17 UTC
-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?
Comment 19 Mark A. Hershberger 2011-08-02 13:54:48 UTC
I like your solution.  At least on Opera, FF and Chrome.  Someone should test IE.
Comment 20 DieBuche 2011-08-02 14:47:20 UTC
(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 )
Comment 21 badon 2011-08-03 05:18:55 UTC
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.
Comment 22 Fomafix 2011-08-17 17:28:16 UTC
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>
|}
Comment 23 badon 2011-08-17 17:31:12 UTC
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.
Comment 24 DieBuche 2011-08-18 15:36:55 UTC
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.
Comment 25 Mark A. Hershberger 2011-08-18 21:54:23 UTC
(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?
Comment 26 Fomafix 2011-08-23 09:04:30 UTC
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.
Comment 27 badon 2011-08-23 21:15:50 UTC
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.
Comment 28 Fomafix 2011-08-24 10:46:34 UTC
(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.
Comment 29 badon 2011-08-24 17:43:38 UTC
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".
Comment 30 Antoine "hashar" Musso (WMF) 2011-12-13 09:26:49 UTC
(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;
Comment 31 Fomafix 2011-12-19 12:48:47 UTC
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).
Comment 32 Fomafix 2012-01-26 22:14:24 UTC
An other possibility would be:

ul.gallery { display: table; }
li.gallerycaption { display: table-caption; }
Comment 33 Stefan Fussan 2014-01-05 11:34:26 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links