Help talk:Infoboxes/Tags

Formatting needs to be rethought
While this page is helpful in learning about the infobox tags, the current formatting leaves a lot to be desired.

The example "output" listings, in particular, are extremely difficult to read due to the extremely narrow page width. (Effectively locked even if you widen the browser, the only responsive change is that the font size grows larger.) All examples of any meaningful complexity will require extensive horizontal scrolling inside a narrow box. The effect feels like peeking at bits of the code through a peephole, with no way to comfortably take in the entire block all at once, or even get a good sense of the overall structure.

Some sort of pop-out feature to view the block inside a wider, floating frame would probably make things slightly better. But a page design that didn't squash the content into a thin column (and then further split that in half, by using a side-by-side structure for the input/output code blocks!) would really turn this into a useful and readable resource. -- FeRDNYC (talk) 07:59, July 13, 2017 (UTC)


 * Interim CSS fix deployed (which allows wrapping in code). The page can be rewritten (and reorganized), but it is still very useful to have that code side-by-side. Thanks for the tip! FishTank (wall) 16:37, July 14, 2017 (UTC)


 * Hey hey :) Just dropping by with a li'l reminder of an oddity about Community Central. Help pages are considered content and so they render in Mercury here -- something that is not the case on most wikis. That means we need to be mindful of how the content of this page looks on portable devices. And, because it's shared help, we also need to ensure that the page works just as well on batman.wikia.com (which doesn't have access to any local Community CSS or JS) as it does here.


 * Things like:
 * "Some sort of pop-out feature to view the block inside a wider, floating frame would probably make things slightly better."
 * ... just aren't possible because of both Mercury and the fact that this is shared help. 17:14: Fri 14 Jul 2017


 * I know it's been nearly 2 years already, but I just wanted to thank for putting in all the work to convert all of this page's code/output samples from side-by-side to vertically stacked. It makes a world of difference, the thing's practically readable now! Muchos kudos. Your efforts do not go unnoticed. (...Eventually.)) -- FeRDNYC (talk) 14:25, April 16, 2019 (UTC)

Span Attribute
It is mentioned that  is an attribute of , but I can’t seem to find anywhere on the Portability Hub or in any help pages what this attribute is for. Does anyone know?
 * Bit late to answer, but span is used on data items in . It's horizontal grouping that flows responsively. Put   inside the group and it will span two units out of.

 https://i.imgur.com/SjANenX.png


 * • speedy • 🔔&#xFE0E; • 🚀&#xFE0E; • 19:48, November 2, 2017 (UTC)

Alt text and title HTML attribute
Is there a way to add alt text to an image in a portable infobox without also adding a title attribute? - Citrusellaeditswikis (talk) 23:02, October 27, 2019 (UTC)

PortableInfobox tags treated differently in FandomDesktop TOC
On FandomDesktop, the table of contents remove the PI tags from display. They're actually there in the page source (Oasis and Hydra render the tags without issue) and appear for a brief moment. Adding additional escapes to make it appear result in worse URL anchors, but can prevent the tags from disappearing.

I propose that we just use the plain tag name without  and. This has the additional benefit of a simpler anchor (i.e.  instead of  ). If the reader needs to visually understand what a "tag" is, they can look at the section text where we have more flexibility and has no impact on the ToC and URL anchors.

Live example
Below are the three different headers to allow comparison of what it would look like in ToC and section headers (check page source, use dev tools, or preview it in Special:ExpandTemplates):
 * 1) only tag name
 * 2) tag name with less-than-greater-than
 * 3) tag name with escaped HTML codes lt and gt

HTML output comparison
Here are the comparisons of wikitext and the resulting HTML output in ToC and section headers.
 * Note: the source code requires an additional escaping of HTML entities to correctly render in page; this is a MediaWiki limitation. As such, please use the rendered output and not the wikitext source code for comparison.

Hopefully, this gets resolved before FandomDesktop is fully released. --BryghtShadow (talk) 06:21, 8 June 2021 (UTC)
 * I went ahead and removed &lt; and &gt; from each section (Special:Diff/3447935). They are now rendering on both skins, and the anchor is simpler. --BryghtShadow (talk) 12:45, 18 June 2021 (UTC)

The tag parser function does not support infobox panels ?
There is no mention that  is not supported by the   parser function. The following only works fine when the parser functions are replaced with normal XML tags or when the whole tab feature with panel and sections is removed:

Maybe this code is doing something wrong but I tried various things to no avail. Any suggestion? If that truly is unsupported, it should be mentioned in the article IMO since the tag parser function supports the rest of infobox tags fine. &mdash; Haximus Thunderburp (talk), 21 July 2021
 * I have no idea of the code-base, so I wouldn't be able to give a definitive answer as to why tag does not support panel. But this is probably counter-efficient to just building an infobox normally. Besides being able to pass in variables where you normally wouldn't, why do you need to build an infobox with ? --BryghtShadow (talk) 18:40, 21 July 2021 (UTC)
 * I wanted to alter layout and labels at my leisure, and I found it'd be perfect with conditionals like,  , etc, considering the limited insight I have into &lt;infobox>. The &lt;infobox> tag has config options to alter layout and such but that kind of thing is never flexible enough, not very dynamic and needs to be learned. From where I stood, using parser functions to subtly alter an infobox layout and labels based on input seemed like a lower hanging fruit that's also more tasty =) &mdash; Haximus Thunderburp (talk), 21 July 2021

Tab B        Group header B }} &lt;section> Tab B        Group header B }}
 * First things first,  is a tag extension. None of the other tags used within portable infoboxes are tag extensions by themselves, they are just text in XML format parsed by the   tag extension parser.   is meant to be used for actual tag extensions.
 * So why do all other tags "work" when used through  that way? Because, when   is passed what isn't a real tag extension, it returns plain text of what should have been the usage of tag extension. That plain text was supposed to be parsed by the parser (as an actual tag extension), but isn't (because it isn't a tag extension). For example,   will return you.
 * What this means is that your infobox could have looked like this, with the same semantics:
 * But this still doesn't work. Why? Well, it turns out the problem isn't, but  . As you can see on Special:Version,   is an actual extension tag, used by the Labeled Section Transclusion extension. You can go around this, by escaping your use of  :
 * Try it, this one works for me. I don't think it's worth documenting this strange behavior, though, as none of the tags used in PI markup are supposed to be used through, and it wouldn't make sense for them to be used like that. Also,   is discouraged in the first place.
 * As BryghtShadow also asked above, why do you need to do this? -- Cube - shaped   garbage can  19:20, 21 July 2021 (UTC)
 * Great answer, thanks! May I ask why  is discouraged? Not robust enough?


 * I don't think it's worth documenting this strange behavior, though, as none of the tags used in PI markup are supposed to be used through
 * The inner tags sure, but the behaviour occurs when  is only used with infobox as you've shown. Aren't more people than just me bound to hit this issue then? The solution is quite straightforward to explain, too.


 * It isn't mentioned that  is discouraged on this MediaWiki page, Help:Infoboxes or Help:Infoboxes/Tags either, shouldn't it be added? (I'd do it myself but I don't feel legitimate touching help pages of something I haven't used a lot)


 * As for why I was testing this out: Short answer, I've been experimenting with what can and can't be done with infoboxes so as to not stutter and bump into trivial issues once some larger project is started. I hoped using  would lift some limitations.


 * Long answer: I learned from one of the doc pages that the &lt;infobox> tag extension only allows parser functions in specific places, like between &lt;format>, &lt;default> or &lt;title> tags. I was thinking, maybe this is like HTML and PHP, where you can either include bits of PHP inside an HTML document, or output an HTML document from a PHP script. So maybe the  parser function allows to build infoboxes in more "conditional" ways by allowing me to use ,  ,  , etc. more freely.


 * For example I may want to group horizontal items 2 per line in certain conditions, 3 per line in others, or switch to vertical display for the group. Maybe I want to set some tab labels dynamically based on which template keys have been given a value by wiki contributors. More generally, anything that could alter the infobox layout and labels based on input should benefit from parser functions being more liberally usable. I know the Infobox tag extension provides some options that allow some flexibility but not on the same level, and I'd avoid having to learn such an "API" altogether with conditional output. =)


 * Note: I removed the  bit from my sample code. It was an unrelated leftover that semantically fit by coincidence, though it would have no effect on the output of the sample as you said. ^_^' 


 * Sorry it was a bit long, but you asked for it!! &mdash; Haximus Thunderburp (talk), 21 July 2021