Hello! As some of your on the wiki may be aware, I joined Vanguard last year, which is a Fandom-led community initiative of volunteers and Fandom staff dedicated to offering feedback on, and demonstrating to communities, new technologies and processes aimed at making community and wiki content future-proof for current and future display devices.

It's no secret that the mobile experience on this wiki is poor, so much so, that even the /r/yugioh subreddit jumped at the opportunity to voice how much they want a decent experience on mobile devices, sentiments that I know have been echoed here many times. I think it's time we fixed that.

In the wake of that thread, we proceeded with the creation of some Infoboxes to get the ball rolling on what the community can expect. The current Infoboxes we've created drafts of are:

These new Infoboxes offer a streamlined syntax, designed to make creation of Infoboxes easy for just about everyone. This new syntax has also been built from the ground up to support Fandom's Mercury mobile skin. We plan to extend this Infobox syntax to the other Infoboxes on the wiki in due course. Questions can be fielded below.--TwoTailedFox (talk) 23:31, February 15, 2017 (UTC)

The problems with the mobile experience have far more to do with the absolutely terrible ad situation than anything else. In comparison with that, the current infoboxes are perfectly fine (see for example Starter Deck: Kaiba); tell me, please, how that "doesn't work" on mobile. The main valid area you can point o for our content not working on mobile is our OCG/TCG card pages, and even there, the only reason for that is because the template that controls their display hasn't been updated to the new style yet; that new style is perfectly mobile-friendly (see for example Dark Magician).
There is also no merit whatsoever to your claim that PIs offer streamlined syntax when compared with our current method for generating infoboxes. It is literally more effort to write an infobox using the PI syntax than to do the same using the Template:Infobox syntax (which makes it even more dubious to call it an "improvement" to convert a Template:Infobox infobox to PI)! If you want to see improvements to our infoboxes, you'd have a much better time convincing staff to whitelist the HTML tags that PIs generate so they can be used directly by editors - not just us, but everyone on Wikia, and not just through Wikia's own Not-Invented-Here, walled-garden syntax. ディノ千?!? · ☎ Dinoguy1000 23:55, February 15, 2017 (UTC)
Really? I can call an Infobox by declaring <infobox>. I can assign groups of content with distinct headers by using <group>, <header> and <data>. That puts the power of infobox creation directly into the hands of both experienced and novice editors.
The current Infobox looks extremely poor. Extra lines everywhere, with the navigation box at the bottom not even respecting the fact that it should be on the same level. The new syntax actually has section headers, absent from the old version. The colors also contrast much better, and add definition to the content. The old infoboxes just happen to work on mobile, barely. This is dedicated support vs. barely bit for purpose.--TwoTailedFox (talk) 00:57, February 16, 2017 (UTC)
I can do exactly the same by declaring {{Infobox, | group# = , | header# = , and | data# = , and much more besides (including controlling styling on an article-by-article basis, without requiring those styles to be loaded on every single pageload).
Those are complaints about the specific way that specific infobox is styled, they are not by any means valid complaints for all the current infoboxes. In addition, saying it "looks extremely poor" isn't a valid argument, you're just saying you don't like how it looks. As for the navigation links at the bottom, they're not on the same level because they aren't meant to be. There is certainly an argument for redesigning them so that they are, but that's simply an alternative style; it is not objectively better. You still haven't provided any evidence on how the current infoboxes "just happen to work on mobile, barely". ディノ千?!? · ☎ Dinoguy1000 01:11, February 16, 2017 (UTC)

Funny, it looks much poorer when compared side-by-side. As I said earlier, this syntax has been designed from the ground up to work with Mercury. You don't agree? Not a problem. Just that that opinion seems to be in the minority.--TwoTailedFox (talk) 01:27, February 16, 2017 (UTC)

The Fox is not wrong about these skins looking far better on mobile. When it comes to default though, the originals look better in my opinion, primarily due to how large the Japanese text appears (it's particularly a problem regarding the episode pages). I'm not going to lie though, it's been a while since I've browsed extensively on mobile, I didn't realize that so many of the problems had largely been fixed. Sanokal K-T (talkcontribs) 00:59, February 16, 2017 (UTC)

  • We can definitely fix the text size if it's too big.--TwoTailedFox (talk) 01:30, February 16, 2017 (UTC)

I'd like to see a background color that isn't white. I think infoboxes should look more distinct from the rest of the page and the white background makes the separation less clear. Cheesedude (talkcontribs) 01:43, February 16, 2017 (UTC)

The PIs look better in the mobile than the traditional infoboxes, in general. They were made to look better without any support. That's an advantage over the traditional infoboxes. However, with CSS support, I believe the traditional infoboxes could look, at least, as good as the PIs, but since Wikia doesn't want to grant access to CSS on mobile, this will be complicated.
In terms of mark-up, I prefer the regular one, rather than the new infobox mark-up. Sure, it may be simpler for newcomers, who are not acquainted with the extensions (parser functions, etc.). However, they'll only be able to do simple things solely with the new mark-up. You can't emulate a whole template, that constantly needs checks here and there, by using a PI, even if that means it may look better on mobile. You'll just lose accessibility and flexibility, with the PIs. Also, in the end, I have the feeling a complex infobox will have a code that looks more complicated as a PI than as a regular infobox (you have to type more stuff and all).
Also, with Lua, we should be able to come with something better than PIs. Though we don't have any Lua programmers.
There's also the problem of ads. With this mark-up, Wikia would have more control over what's being displayed; they could throw ads in the middle of the infobox (as it has happened before). This will be awful in terms of user experience, especially for mobile. That's a risk I am not willing to take.
So, for now, I'm hesitant to change to the PIs. I think there are better solutions, like allowing CSS on mobile; we'd have more flexibility, we could do more; we wouldn't be confined to a unique mark-up.
TTF, the major difference on the pics you posted is that the PI has colored headers. May look slightly better, but not enough to convince me to adopt these. Not for now, at least. Becasita Pendulum (talkcontribs) 14:03, February 16, 2017 (UTC)
Fandom does not intend to offer CSS modification to the mobile skin at any point in the future. Our experience has shown that such modification when controlled by users tends to make the result unstable and puts high strain on mobile device data plans and capabilities; as more types of devices access your content, we have balanced elegance and simplicity in the mobile skin. At most, we may offer a set of predefined color themes per community.
Regarding Lua: Fandom considers Lua an essential language for many communities, and does not intend nor want to make things more difficult for them. Some functions created by Lua make templates much more powerful and efficient than can be accomplished in wikitext. It is not a panacea, and should not be seen as a complete replacement for all extensions nor Portable Infoboxes (nor CSS nor JavaScript); it can replace ParserFunctions and wikitext effectively in many situations. The learning curve can be steep, and as a result we do not consider Lua as simple to use as other solutions. At this time, our Lua processor should be considered stable and as feature complete as we intend to make it. We will continue to maintain it where it is in use on existing communities for the forseeable future. We will set a clear end-of-life date should that position change, and will give communities ample time to prepare if and when that decision is made.
To be clear:
  • If you are using Lua for discrete functions (rather than to create full elements), there is no cause for concern.
  • If you are using Lua to make infoboxes, we strongly suggest you use Portable Infoboxes instead.
  • If you are invoking Lua INSIDE portable elements, like PIs, there may be cause for concern and you should consult with a Vanguard or Community Technical Staff.
  • If you are using Lua to make navboxes or other complex elements, we want to hear from you. This is an opportunity for us to identify gaps in our product line. There's also an excellent chance your creations are not portable or mobile-compatible, and that should be a concern to you; it is to us.
With ads, there is always a balance to be struck. We are actively looking for ways to improve the ad experience, but ads will always be necessary. We're trying to have fewer ads overall and no bad ads. It is something of an exaggeration that we puts ads in the middle of an infobox; this was an A/B test bug that was the result of one department not communicating with another, and was confined to a single community for less than one hour. We make absolutely sure in our quality control now that there are no ads inside PIs, and consider it a priority bug when that happens inadvertently in testing.
Finally, it is a fact that the best possible experience on mobile Fandom communities will come from portable code. This system is a long term investment and leads into other future products, so it is not going anywhere. So long as Yu-Gi-Oh exists on Fandom, it is to your benefit to use this technology we've created for the premium experience. It is not intended to become obsolete for many years, and has been optimized for efficiency over inline styling. If and when the time comes for change, the future replacement should natively migrate this code. That benefit was not possible with the largely unstructured wikitext templates.
FishTank @fandom (wall) 15:21, February 16, 2017 (UTC)


As there has been no further discussion, and as no valid points have been raised against it, the decision is hereby made that the new style Infoboxes will go live as of 00:00 UTC May 1, 2017. From that point on, the syntax will be systematically applied to remaining Infoboxes as time goes on, and over time, will replace psuedo-infoboxes as well.

To prevent reversion and edit warring, I have asked Fandom staff to patrol this wiki, and deal with anyone that reverts these changes, including but not limited to, reverting back to the new syntax, removal of rights for those that make repeated reverts, and temporary bans for those that persist in doing so.--TwoTailedFox (talk) 23:49, April 23, 2017 (UTC)


Is it okay if we remove the non-English names from above the image? I think it's a bit overwhelming having so many. They're also listed below with labels. -- Deltaneos (talk) 20:00, June 18, 2017 (UTC)

Please, yes. Becasita Pendulum (talkcontribs) 00:01, June 19, 2017 (UTC)
*Disclosure: Some of the links above are affiliate links, meaning, at no additional cost to you, Fandom will earn a commission if you click through and make a purchase. Community content is available under CC-BY-SA unless otherwise noted.

Fandom may earn an affiliate commission on sales made from links on this page.

Stream the best stories.

Fandom may earn an affiliate commission on sales made from links on this page.

Get Disney+