Wow! So, time for changes! Thanks Wikia!

You're welcome! Buena suerte!

This is a great tool, and perhaps you've won over 25% of the people who were against portable infoboxes. Once something is developed for styling infoboxes you'll probably get support from 99% of users because even legacy infoboxes are incredibly hard to style. People just prefer them because it doesn't require admin "permission" and most of them are already styled.

I hope that support is never added. It will simply add unnecessary complexity to the infoboxes. I've noticed that some of the attributes or parameters of the gallery are simply ignored by the portable infobox. For example, someone[1] was concerned that the caption of the tabs wasn't different from the label of the tabs, perhaps using the linktext for this will help.

It might also be worth revising other gallery options [2]  to change how it is actually presented in the infobox, and add any features Wikia deems useful.

For sure, Dessamator, and this is great feedback. 

Between you and me (and this entire forum of users), the community team has learned very well that CSSifying infoboxes is a complex undertaking, and we definitely do want to give you folks a simpler way to style them. I can't say too much about it now, but stay tuned.

And I agree about nested tabber - it's a neat trick, but goodness does it exponentially expand an infobox's complexity.

Thank you! I've been waiting for this feature to convert the last few infoboxes to PIs. However, I'm not getting the Tabber version to work, only the Gallery version. See this demo page.

Also, it ignores file names with an ampersand (&) in the name.

EDIT: Is there a way to put a caption on the tabber/gallery, or on each individual image? Just curious.

This didn't working in Monobook. Click!

1. That's bizarre, it should render correctly. We'll take a look. Figured it out:

You had plain file names:

<tabber>
4e = 4e_orc.jpg
|-|
3e = Orc.JPG
</tabber>

When you needed to invoke them as thumbnails:

<tabber>
4e = [[file:4e_orc.jpg]]
|-|
3e = [[File:Orc.JPG]]
</tabber>

2. Yay! Another bug. Thanks for reporting.

3. Not yet. We've thought about it, but we wouldn't be able to support <gallery> usage.

OH! I thought it was the same way as <gallery>, my bad!

I think this calls for a new tag. If it isn't really exactly a gallery, it should have a different tag. <tabbery>? LOL!

<tabber>
4e = 4e_orc.jpg
|-|
3e = Orc.JPG
</tabber>

<tabber>
4e = [[file:4e_orc.jpg]]
|-|
3e = [[File:Orc.JPG]]
</tabber>

Then please update the example in the OP accordingly :)

Done.

Walks away in embarrassment.

Good start but nope, not for me. I'd rather add the images via separate parameters (ie. front cover, back cover) that go into the tabber code on the template page instead of lumping them together with extra code on every individual page.

Is there any way the mobile version could work on the desktop as well? I think the mobile gallery is a much cleaner look than having a million tab buttons...

Seconding this, that looks really good.

I thought that was a product of using tabber in the first example, but seeing that it's not, I'm thirding that.

Yep, I also think the mobile version looks way better.

The problem is not with the "million tabs", it is with users who want to add a million tabs. 

More importantly, while mobile space is limited, a desktop generally has more space and having to click "million times" to see the last image is not a good user experience. Unfortunately, that's a necessary tradeoff for mobile.

Wouldn't it make better sense to use this code on the infobox's template page, where it could pull the data from multiple parameters than having to code additional galleries/tabbers on every single page that uses the infobox? For example, if I've got a wiki where a multiplicity of characters have different images based on manga/anime/game1/game2/game3, I don't want to write this on every page:

Template:infobox character
<gallery>
Red Dog 1.jpg|manga
Red Dog 2.jpg|anime
Red Dog 3.jpg|Game1
</gallery>

When I could just use standard naming scheme and a simple parameter in the infobox. This would let the infobox template deal with writing out all the labels & naming schemes:

Template:infobox character
| image = Red Dog

or even:

Template:infobox character
| image1 = Red Dog 1.jpg
| image2 = Red Dog 2.jpg
| image3 = Red Dog 3.jpg

Anything that can be passed through a template to an infobox can also be used directly in it. So what you want to do is entirely possible. It is simply a matter of replacing those names or images with template parameters, see the page below for an example:

• Portable infobox syntax

They just put it like that in the opening post as an example. It'll probably be clearer once the Infobox documentation is updated.

Hey Ducksoup, thanks for this. I had always been hoping for this.But is it possible to have some CSS coding that could customize the appearances of the tabbers/galleries in all portable infoboxes?

I'm working on styling the tabber to look like the original. If I get it working, I'll post the CSS. Don't hold your breath tho :-)

Don't worry. I can wait.

Easy:

/* This is for all tabs */
.portable-infobox .pi-image-collection-tabs li {
  background: #145BD4;/*your color here*/
  color: white;  
}
/* This is for the current selected tab */
.portable-infobox .pi-image-collection-tabs li.current {
  background: green; /*your color here*/
  color: white;
}
/* The whole gallery/tabber box*/
.portable-infobox .pi-image-collection {
  background: red; /*your color here*/
  border:5px solid red;
}

/* This is for all tabs */
.portable-infobox .pi-image-collection-tabs li {
  background: #145BD4;/*your color here*/
  color: white;  
}
/* This is for the current selected tab */
.portable-infobox .pi-image-collection-tabs li.current {
  background: green; /*your color here*/
  color: white;
}
/* The whole gallery/tabber box*/
.portable-infobox .pi-image-collection {
  background: red; /*your color here*/
  border:5px solid red;
}

Thanks dude. I'll be using this today, but using the colors according to my own preference of course. How did you figure it out so easily?

All major browsers provide some way of viewing (and editing) the css  used in a webpage, for example, these are chrome's instructions:

• https://developer.chrome.com/devtools/docs/elements-styles

You can also simply save the web page and view it normally but that's more time consuming.

Here is a set of CSS selectors that will make a <tabber> used in the <image> tag of a Portable Infobox look like the regular tabber. As far as I know, the PI tabber feature does not work in monobook, so I could not test it. No warranty is expressed or implied. Use at your own risk :-)

.pi-image-collection {
    margin-top: 0.5em;
    text-align: center;
}
ul.pi-image-collection-tabs {
    border-bottom: 1px solid #778;
    font: bold 12px Verdana,sans-serif;
    list-style: none outside none;
    margin: 0 0 2px;
    overflow: visible;
    padding: 0 0 4px;
    text-align: center;
}
ul.pi-image-collection-tabs li.current {
    background: none repeat scroll 0 0 #FFF;
    border-bottom: 1px solid #FFF;
    font-weight: bold;
}
ul.pi-image-collection-tabs li.current:hover {
    background-color: #FFF;
    border-bottom: 1px solid white;
}
ul.pi-image-collection-tabs li {
    -moz-border-bottom-colors: none;
    -moz-border-left-colors: none;
    -moz-border-right-colors: none;
    -moz-border-top-colors: none;
    display: inline;
    line-height: normal;
    list-style: none outside none;
    background: none repeat scroll 0 0 #DDE;
    border-color: #778 #778 -moz-use-text-color;
    border-image: none;
    border-style: solid solid none;
    border-width: 1px;
    color: #448;
    margin: 0 0 0 3px;
    padding: 3px 0.5em;
    text-decoration: none;
}
ul.pi-image-collection-tabs li:hover {
    background: none repeat scroll 0 0 #AAE;
    border-color: #227;
    color: #000;
}
.pi-tab-link.pi-item-spacing {
    padding: 3px 5px 4px;
}

Well, I wouldn't describe "users" as "the problem" myself.

Redwall is a book-related wiki. We have images of every translation, in some cases this is above 20. This, imo, would be a great usage of this new function.

However, I think that amount of tabs is aesthetically and functionally unpleasant.

Thus, if there were an option to make the mobile "slideshow" possible to be displayed on mobile AND desktop, that would be fantastic. Hoping Wikia can weigh in here, given the support above.

We've considered the idea of allowing for tabs on mobile and a slideshow on desktop. The fact that you're discussing it is great feedback that these options would provide some usefulness.

We wanted to get a first version out, see how it's received, and plan from there. This feedback is helpful.

I briefly looked through Redwall wiki and didn't find a single infobox with a gallery. Even among the most used infoboxes according to Special:Insights, so I find it hard to believe that this has suddenly become an important use-case.

The appearance of the tabs can also be changed with css. So while I don't particularly have anything against slideshows in portable infoboxes, I believe that much like galleries they should be restricted to a reasonable number, and perhaps other images can be viewed in a separate page , popup or lightbox.

Wikia is currently defining or redefining what infoboxes are, and some restrictions need to be put into place to make sure they don't become kitchen sinks.  

@Wikia Staff:

One possibility with this new tabber design is to use svg (or other) icons instead of text for the tabs, although this can probably be achieved using css. An image is worth a thousand words after all.

The special character in file names issue( e.g. & or '  ) appears to be an old bug (see Thread:908343). It seems that files with special characters uploaded before a certain date (presumably before 2015) can  cause issues with other features. Someone reported this in the forums, I can't recall the exact thread title though.

Apparently, newly uploaded files don't have this problem. Try uploading a newer version of the file with a slightly different name (keeping the ampersand).

Good catch! I gave it a try, but to no avail. The only way it worked was to remove the &. My steps:

1. I uploaded a newer version of the same file and that did not fix it (after much purging and cache clearing).
2. I uploaded a fresh copy with a slightly different file name, keeping the ampersand. That did not fix it.
3. I renamed the fresh copy to a name without an ampersand, and it worked.

Even as a concept, this did not occur to me until I saw this very thread. And when I did, I thought it was a great idea. Provided slideshow functionality was available for desktop in addition to mobile, I would roll it out immediately. "Important-use case" is entirely subjective.

Furthermore, I'd add restrictions are also entirely subjective. Wikia editors should be allowed to use this function as they see fit. If your individual wiki does not want X number of images in a gallery, make it part of your official rules. It doesn't need to be a part of the code here.

So, just to be clear, this gallery thing is only a partial replacement for tabber, since it mostly only works for images. Correct?

I believe it is true that galleries only work with images. However, I have not been able to get anything other than an image to display in a tabber passed as an argument to <image> inside a Portable Infobox. I tried plain text and in-line templates, just to see. It is expecting images and videos only.

But good news! It appears they have fixed the link problem when tables are used inside tabbers inside a PI. This demo page is now working! (The links in the tabber at the very bottom of the infobox were missing, and now they are being rendered.)

Tabbers passed as arguments to regular <data> fields seem to work fine.

I think this is a step in the right direction, but I feel it's a confusing mix of extensions/tags. I also feel it should have been implemented at the tag level, i.e. in the template itself, rather than at the argument level as the template is really where any logic or complication should be handled. A template should offer a simple, powerful and intuitive API that can be used by anyone irrespective of how little experience they have. I find it unlikely someone using VE will be able to edit a field set up in this way.

I think it would have been cleaner to offer a something more inline with what's already offered. For example:

<infobox>
  <image prefix="image-">
  ...
</infobox>

However, that example doesn't support a default. So, how about this instead:

<infobox>
  <data prefix="image-">
    <!-- other potential attributes might be "limit" to limit the number
         of parameters used and "default" to specify whether a missing
         image should default to the default tag or the first use of the
         parameter, e.g. default="1" or default="default"
    -->
    <image prefix="image-">
    <default>Default text here</default>
  </data>
  ...
</infobox>

Which could be used as:

{{infobox
 | image-1 = 
 | image-2 = 
 | image-3 = 
 ...
}}

The good thing about integrating this with the <data> tag is that it allows other parameters to have multiple values too, while adding one more attribute to the API thus keeping it relatively simple instead of having to lookup other syntax to achieve what you want.

I'd agree with Lord TBT that a large amount of tabs is aesthetically unpleasant. So what about limiting the number of buttons to 2-3 — just limit it to the what fits within a single line of the infobox — and then using a dropdown instead?

@Cqm:

The image tag can't currently be nested inside the data attribute. So that would require some changes. It is also confusing because one would need to know if the data is parsed as an image or text. What about people who mistakingly mix text, audio, and images?

How exactly would it parse that data?

Beyond that, your syntax suggestion wouldn't cover a label for each tab and its caption. Perhaps this could be as simple as :

| image-1 = File:example.png , my-caption, my-tab-label

The problem with that is that MediaWiki allows special "nonsensical" characters in files or pages, so if the filename or the caption has a comma as a delimiter , it wouldn't parse properly. Putting it inside a construct like gallery or tabber overcomes this problem, perhaps that's why they used it.

I'm not sure they want to support tabbed text or other media. This may perhaps make the infobox too complicated and hard to edit or create using a VE Gui tool.

@Dessamator I was told it worked when I wrote w:c:rs:Template:Infobox City/Draft recently and never got around to testing it. As it turns out it doesn't work properly, as you said.

With this new 'revelation', what about:

<infobox>
    <image prefix="image-">
        <!-- add alt and caption tags here -->
    </image>
    ...
</infobox>

I'd actually be inclined to move the tab label out of the image tag, and use a label or tab tag instead, to make it more flexible in the future.

To be honest, I haven't thought too much about VE, but I very much doubt the existing gallery/tabber syntax is at all easy to grasp anyway.

@Cqm:

I think Wikia did a great service to the community by allowing tabbers as arguments to the <image> field. Implemented as you describe, it would have required the editing of thousands of pages and taken up many hours of people's time. So, yay for backward compatibility. :-)

@Dessamator:

One solution to punctuation in file names would be to just require the use of the [[File:]] tag (with brackets) like it is already required for tabber. But you also have the same problem with my-caption and my-tab-label—they might contain punctuation too.

@cqm: 

You don't really need to submit the whole thing as an argument to an infobox . I'm not really sure who spread that misconception. You can embed it into the portable infobox and use the tag parser function to obtain whatever you need. In fact you can make it parse whatever format you want using lua or a simple template to create the gallery or tabber, see:

• Portable Infobox/Syntax#Alternate syntax

I still agree with you that they should provide an easy to use syntax so that  inexperienced editors can still make their infoboxes functional with minimal effort.

@Moviesign:

Getting around the delimiter issue is easy, one could adopt a similar syntax to json or something else:

|image1 ={example.png,  label = example , caption = whatever}

Or

|image2 =example2.png ,  label = example2 , caption = whatever2 

my-Image3.png, label =my-Label3 , caption = my-caption3

or 

my-Image3.png,  my-Label3  |  my-caption3

Another option is to use heredoc syntax.

@Dessamator: I'm not sure how faithfull an SVG would render on mobile, but it's certainly something what we could take a look at. I think our first order of business, though, is making sure all plantext characters render effectively.

@Cqm — Good feedback. There are pros and cons to supporting both single-parameter construction and multi-parameter construction (consistency, complexity, amount of markup, etc.) We erred on the side of simplicity for this initial version to get feedback more quickly.

That said, I 100% agree that passing <tabber> or <gallery> is not an acceptable final markup. We chose it as a "quick win" because a lot of communities are already building infoboxes in this fashion. Also, pursing a standardized markup like tabber or gallery allows us the option to run a script to convert to a new, (hopefully more flexible) solution in the future.

Ideally in the future, users who prefer a GUI over source (be it the VisualEditor or another tool) would never have to see an actual file name. They could select a photo from a visual browse/upload tool. But these flashy features come after we have our markup nailed down.

Bad link. Try (note "Infoboxes"): w:c:portability:Portable_Infoboxes/Syntax#Alternate syntax

I've been trying some of this CSS, and for some reason the background around transparent images is not the same color as the infobox background, it's taken straight from the theme designer. Is there anyway to fix this?

You can try to inherit the background color from the surrounding infobox by using:

.pi-image-collection-tab-content {
    background-color:    inherit;
}

If that doesn't work, you can replace "inherit" with a color.

Thank you very much Moviesign. Works great.

Any chance we can have the gallery feature display the mobile version identically (with swipes across etc), but simply display a group of images (not tabbed) on desktop? See: Jak.

I tried implementing the portable infobox on the Metal Gear Wiki, but the infobox images do not show in either the mobile preview on desktop or an actual mobile phone, after trying both types of coding. Any chance you could take a look?

• infobox template: w:c:metalgear:Template:Infobox_Character
• article with template embedded: w:c:metalgear:Big_Boss

Thanks.

Maybe that's a caching problem. It works properly for me.

Edit to add :

Try appending "?useskin=wikiamobile" to the url. I think that since they introduced curated pages , the mobile preview stopped working properly. Some mobile devices may also not support the CSS or javascript used to create the slideshow.

I added a test infobox to my sandbox a few days ago to restyle the tabber into what we currently have (again), but decided to stop once I noticed the images weren't (and still aren't) appearing in the mobile preview. I can't confirm they aren't appearing on mobile devices, but I wouldn't be surprised.

I can view the images by doing the above for the mobile preview on desktop. However, images on mobile devices are still a no show.

Interesting that works for you because that doesn't work for me either.

FYI the mobile preview while editing on the desktop skin is totally wrong and does not reflect the accurate mobile presentation at all.

Please direct all complaints to Special:Contact/feedback. It really should be Special:Contact/bug (you can use that too), but we'll pretend it is an oversight.

It is not meant to be an exact 1:1 preview . That is actually impossible because there are possibly more than a dozen different form factors for mobile. For example, how exactly would it preview the way it shows on a Google Glass mobile device, or a dual-screen device ?

It would also have to account for custom widgets and apps that users install that may alter the screen.

Ultimately, since this is a portable tool, it should work on most relatively recent mobile devices. If it doesn't then it is either a bug, something that will still be developed, or simply a device that isn't supported.

P.S. At least using the chrome developer tools you can actually simulate the screen size of a mobile device, so it does help somewhat.

Does anyone know of some CSS coding where I can place a border around the content when using the <gallery> tabs? I'd like to make a Portable infobox to look at least just like the tabber image holders (where you can see the sample of the border of the tabbers--I'm not taking about the border of those tabber sections by the way--in a sample here) in this infobox I will be converting into a Portable version soon.

To put a border around the image, you can do this:

.pi-image-collection .pi-image-thumbnail {
   width:  85%;
   height: 85%;
   border: 3px solid purple;

If you want to get really fancy, scroll up a ways you will see some CSS that I posted to make the Portable Infobox tabber/gallery look like the regular <tabber>. You can modify that to match your color scheme. Note that it currently only works if the tabs don't extend beyond the edge of the infobox, but it can handle two tabs just fine. Post a message on my wall if you have questions.

Another issue I've noticed is that images used to represent articles in categories no longer select the first (and usually most recognizable/relevant) image from the article, if that image is in the portable gallery infobox. The image that is selected instead is usually one that is not as recognizable or desirable.

Yes, looks like the feature reading images for the preview for articles in categories (and 'see also') can't read the image in the <image> tag, and instead finds an image from any <data> tag instead.

For example: an infobox featuring a photo of a person (image), then a flag for nationality (data); the flag will be the featured image for that article.

Good catch :) This is definitely not intended. We'll get it fixed.

using:

<group collapse="closed">
    <header>GRID</header>
    <group layout="horizontal">
        <data source="textA1"></data>
        <data source="textA2"></data>
        <data source="textA3"></data>
    </group>
    <group layout="horizontal">
        <data source="textB1"></data>
        <data source="textB2"></data>
        <data source="textB3"></data>
    </group>
</group>

This is a way to make a nice grid that can be collapsible; but this won't work as you can't put a group inside a group. This is a wanted feature, or if there's a solution?

I definitely agree there. It's impossible to use a collapsible and horizontal groups together, that should be fixed.

As the founder of a wiki where we were using tabbers on infoboxes before this came out (example on my wiki/example on the Sword Art Online Wiki, where I found the coding), I'm all for this.

Definitely behind that, as well.

Maybe make it an option. I'd like the tabs, displaying multiple images, and slide across galleries to all be possible with the gallery tag in infoboxes. They would all display with the same slide like on mobile, but differently on desktop.

Another issue: I cannot seem to view the different gallery infobox images when checking the desktop preview, whereas the previous tabs allowed you click on them to see how it would look, while editing.

I think that's just a general JS issue. On several wikis, tabs don't work in preview, though on others they do.

Best of luck @RapidsLurker15! If you have questions on how infoboxes work, these Community Central forums are your best resource.

Tabs in infoboxes aren't working on Monobook or Oasis editor preview yet. We've got them logged and will try to fix them soon. We're also thinking about providing a slider experience on desktop — glad you all like it!

As for groups within groups. I totally understand the use of this — perhaps you should start a new thread to discuss it so it doesn't get lost in this discussion?

Someone, get on with this. This is something we need to easier designing infoboxes. Collapsible grids is one major thing.

I would prefer if the data tag used a "type", that defaulted to text, for this purpose. In this scenario, you would use the label tags for captions. This would make the infoboxes much more flexible, and allow for the tabber/gallery feature to be an aspect of the "group" tag. As an example of how this might work, see:

<group collapse="closed">
    <header>GRID</header>
    <group layout="horizontal">
        <data type="text" source="textA1"></data>
        <data type="text" source="textA2"></data>
        <data type="text" source="textA3"></data>
    </group>
    <group layout="gallery">
        <data type="image" source="File:textB1.jpg|alt=textB1"></data>
        <label>TextB1 described</label>
        <data type="image" source="textB2.jpg|alt=textB2"></data>
        <label>TextB2 described</label>
        <data type="image" source="textB3.jpg|alt=textB3"></data>
        <label>TextB3 described</label>
    </group>
</group>

Edit: And yes, I'm a HUGE fan of the idea of nested groups.

Will this do? :D

Is there nothing that be done about this then? (forgive me, JS isn't my strong suit.) It seems quite inconvenient not to be able to see if the gallery will look any good, without having to save your changes every time.

Without writing your own JS code to replace the default tabbers, unfortunately not. It sounds like Wikia are aware of the problem and could be working on a solution, though.

Yes, we have a bug ticket filed and we'll get to it. Thank you for being patient.

Dark Series Wiki has many book pages with infoboxes showing the current cover and galleries in the article showing the previous covers and translation covers. Example: Dark Prince. It's pretty interesting to see how romance novel covers have changed over the years and in different cultures.

I made a mockup of the gallery inside the infobox and it looks terrible on the desktop. The images don't even show up on mobile. Example: Dark Prince mockup.

You've only proved my point. Infoboxes are not "meant" to hold too many images. Even if the slider is implemented on the desktop, it will still have the same problem. If a user wants to see only image 13 the user will  have to click through 12 images to get to it.  

For mobile devices it is worse, unlike a desktop, a mobile device has limited bandwidth, limited connectivity, and in some cases bad reception. These will affect how long the page takes to load, and in some cases the page may not load at all. 

That looks redundant, currently a gallery can only contain images or video. So if the group has a gallery layout, its child tags don't need a type.

And this is exactly what I'm talking about, and why I want the mobile-style available for desktop.

The issue about what infoboxes are meant to hold is subjective. The example has 10 images and you could argue that's too many for an infobox, but some communities obviously want to use infoboxes in this way. If it's possible on mobile, it should be possible on desktop. Each community can decide for itself how to use infoboxes.

The issue about clicking through a lot of images or the use of bandwidth applies to galleries whether they are inside an infobox or somewhere else on the page. Thus it doesn't really apply to a discussion about desktop tabs and portable galleries in infoboxes.

I sense we're not going to agree on this, but I want the developers to know that there's demand for galleries in infoboxes.

Just thought I'd add, this seems to be an issue with the portable infobox's images in general, not just when using the gallery.

Although I personally would not advise using galleries in infoboxes the way the mock ups have been shown with 10+ images (as someone who works on game wikis, we use alternate cover art just in galleries below on the page because we don't see it as practical), I do have to agree that it should be left up to the community to decide what works for them. I would like portable infobox galleries to have sliders and multiple image display options on desktop, but for all three desktop styles to display only as the sliders on mobile.

I don't disagree that my example has redundancies. It was meant to show you an example of what I was trying to explain about using data types. However, if you wanted to incorporate a secondary image, say a character image as the primary and further down the infobox an image of a map to the character's location as the secondary image, you could do this with my example. It would also make it easier to pull the tabber info from the groups, rather than having to learn tabber syntax.

e.g. -

<infobox>

<group layout="tabbed">
    <header>Tabbed Infobox</header>
    <group>
        <data type="image" source="File:VideoClipA1.jpg|alt=textB1"><label>VideoClipA1 described</label></data>
        <data type="text" source="uniquetextA1"></data>
        <data type="text" source="uniquetextA2"></data>
        <data type="text" source="uniquetextA3"></data>
    </group>
    <group>
        <data type="image" source="File:ImageB2.jpg|alt=textB2"><label>ImageB2 described</label></data>
        <data type="text" source="uniquetextB1"></data>
        <data type="text" source="uniquetextB2"></data>
        <data type="text" source="uniquetextB3"></data>
    </group>
    <group>
        <data type="image" source="File:ImageC3.jpg|alt=textB3"><label>ImageC3 described</label></data>
        <data type="text" source="uniquetextC1"></data>
        <data type="text" source="uniquetextC2"></data>
        <data type="text" source="uniquetextC3"></data>
    </group>
</group>

<group layout="horizontal">
   <data type="text" source="shared1"></data>
   <data type="text" source="shared2"></data>
   <data type="text" source="shared3"></data>
</group>
...etc...
</infobox>

I could easily see: group type="gallery" overriding default of text for a particular group. I was just under the impression that we were trying to encourage the use of text data in infoboxes, hence the default being text. If you want to have a variable default, that's fine. If you don't want a default, then you could have the type be explicit (as I used in my earlier example).

Portable info boxes need to support features that admins want to use, otherwise they are an inconvenience with very little payoff. Arguing that PIs should have this or that in them is almost purely personal opinion. I'm sure there are desired features for PIs that are beyond the boundaries of realistic implementation, but PIs should support most of the features that you can put in wikitext infoboxes until a good argument can be made not to (like too difficult to implement, not used by more than a couple small wikis, security risk, etc.).

This thread is super long so I'm not sure if it's been brought up or not, but could images be made to point to the file's page instead of directly to the file? (Why even make it point directly to the image file?)

This should work already. See Help:Galleries,_Slideshows,_and_Sliders/wikitext#Example_with_variations.

I used this method, but somehow my images aren't the same width, so it looks really ugly. Click.

Your second image is simply smaller than the infobox's width. Infoboxes don't scale images up.

Is there a way to change the size of the second image?

You could either resize your images or adjust them using css, e.g.:

.portable-infobox .pi-image img {
  width: auto;
  height: 230px;
}

.portable-infobox .pi-image img {
  width: auto;
  height: 230px;
}

That's perfect, thanks!

How are the images on this page displaying on your mobile device? Can you view it properly? The mobile viewer isn't displaying the images at all, I just want to make sure. I'm using gallery tag btw.

Also, can someone tell me what's the difference between gallery tag and tabber tag?

I'm trying to insert an image to my Infobox but it doesn't show up, what am I doing wrong?

You're using the [[File:filename]] syntax, not just the filename, right?

I believe the two display the same thing: a slideshow-y thing on mobile, and tabs on desktop.

This is probably due to the different interaction patterns on different devices, as desktop users are more likely to click smaller targets whereas mobile users would find it easier to scroll. So they just took both display options, made them depend on device type, and gave two tags that could stand for the functions the same overall purpose.

No, I'm just using the file name.

You have to put the filename in double square brackets and have File: before it to display a picture.

Okay.

Same thing, it doesn't show up I did to insert the image and it still doesn't show up. (I didn't put the words filename.)

Anyone there?

Someone please answer me

I'll take a look and see if I can spot something.

@TheSonic103ify

You just need to upload some images to your wikia. I added one of your three existing images to the page you were working on and it does indeed work. You do not need the File: or the brackets, just the exact file name of an image in your File List. Good luck with your new wikia!

@Moviesign

Thank you so much!

When using <gallery> tags, you don't need to use File:, but it's good practice.

Unlike traditional image links, gallery tags will not display anything if the image does not exist.

Yes, but a local image/video filename doesn't need the File: prefix to work in gallery tags.

Oh, it was a gallery?

oops

It's true that you don't need the File: prefix for images in a gallery. However, if the image doesn't exist (isn't uploaded) on the wiki it will not show that image in the gallery (unlike other images, which show as redlinks). If no images exist by the names listed in the gallery, the gallery may not show at all (until at least one image is uploaded to the wiki). Galleries do not prompt a user to upload an image by default.

Question: Could one make it so that not only the image changes but also some of the facts written?

Example: I have a character that can be either female or male in the game, but has the same purposes storywise. So the name, the image and some other facts might differ from female to male.

This is my character --> http://kendallandkyliegame.wikia.com/wiki/Rival

So could I make it so that when I switch image Male>Female that some of the facts switch too?

Currently, the portable infobox doesn't support that and will probably never support it due to its complexity. The only way to get that working would be using javascript which will not show up on mobile devices anyway.

I still don't understand where I should add the gallery tab thingies... I only get confused and have no idea where to add them... can someone help? Sorry if I'm dumb... I really messed up, it wont show images anymore....

You can add it directly into the infobox, as you fill it out, in the "image" section.

{{Infobox
|title    =
|image    = <gallery>
            Image1.png|Title1
            Image2.png|Title2
            </gallery>
|whatever =
}} 

Very nice concept for 140px+ multi image display. But, I had 4 small(soon to be 8) gif. It is easier to use an HTML table in a 'data' tag, so all the gif are displayed together. The Infobox will maintain the image tag(blanked on small gif pages) for alternative methods as discussed here. -thanks for the info

That's an interesting use case. It makes sense to have different ways of displaying the images. In this particular case, it could be something like the default mediawiki gallery squeezing some images side by side, instead of tabbed. Although, one would still need some way of limiting the number of images so they can actually display in a reasonable way.

Eight images in such a tight spot seem to be somewhat excessive, unless they are really small.

They are width:50px~60px gifs(height a little less). Two rows(4/row) looks nice on mobile, though the wiki is desktop/tablet centric.

Is it possible for you to composite the GIFs into one image and use them in that manner? If the GIFs are directly relevant to each other, this could help a lot.

Yes, but since the images may be utilized elsewhere and may have differing timing; I prefer to keep them separate to reduce their file size. Gifs with motion over a large area can get unwieldy. The page in question is here. Wasn't a problem just a remark for alternate ways of doing things.

Hello. May I know how to maka the 'tab' in center? Mine somehow stuck on the left. Thank you.

@Tantrumbunny Please post a link to an example page so we can see what it is you desire.

@Moviesign http://treeofsavior-thelore.wikia.com/wiki/Wizard

The female & male 'tab'. I follow the tips to make tabbed image with < gallery > and it works, but while the example above in the center of infobox, mine in the left?

It's because you have europa-theme enabled in your wikia features.

To center them, you can:

• Turn off the feature on the page I linked

or...

• Add css below to your MediaWiki:Wikia.css or MediaWiki:Common.css

.pi-europa .pi-image-collection-tabs {
    text-align: center;
}

.pi-europa .pi-image-collection-tabs {
    text-align: center;
}

Thank you very much! I'm adding the css code and it now look better. Thank you!

I can't get it to wor please help!!!!

Could you be more specific and describe the problem and post a link to the page please?

I have been trying to post image's with tab's like te image above, but I just can't figure out how to do it

here's the link http://crow-land.wikia.com/wiki/Undertaker

I have made two edits to your page. See the edit comments and hopefully that example will help you see what you need to do. You can post a message on my wall if you have more questions.