Forum:Portable infoboxes -- and you

From the RuneScape Wiki, the wiki for all things RuneScape
Jump to: navigation, search
Forums: Yew Grove > Portable infoboxes -- and you
This page or section is an archive.
Please do not edit the contents of this page.
This thread was archived on 28 October 2015 by Cqm.

Hey guys :)

I was browsing an unrelated archived discussion, where I noticed that someone had said that you guys had already talked about [[community:help:infoboxes|Wikia's new portable infoboxes]] and weren't all that enthusiastic.

Well, our code has evolved a lot since then, and you should know that it's a huge priority of ours to ensure that all our sites use infobox markup that works well on all devices. We're taking the unprecedented step of having engineers work with individual communities like yours to ensure that existing code is being used to maximum effect, and in some cases to actually change the code so that it ill adapt to use cases we hadn't previously considered. After all, it's hard for even dozens of engineers to know what happens on the hundreds of thousands of wikis that we host!

Given the importance of RuneScape, both as a topic unto itself and as a community that inspires others, we'd really like to get you on board with this project.

While it's true that as a percentage of your overall traffic, mobile web is less than 10%, that still means that in the last month you had 366K uniques and a whopping *2.7 million* page views *from mobile devices*. Since the overwhelming majority of your mobile contacts came from iOS and Android devices, most actually saw the mobile skin — a place where your current infoboxes can't optimally present their information. For the sake of these millions of monthly page views alone, we think it makes sense to at least try to convert your infoboxes to the new code.

But there's another reason as well.

Embedded deep in the code of the new infoboxes are the keys to leveraging the data within the infoboxes. Though we're not there yet, we believe this pathway to structured data will ultimately help you auto populate a lot of pages here at RuneScape with all sorts of powerful queries: listing all hats that cost less than a certain amount, finding which weapons deal a certain amount of damage — that sort of thing.

But we realise that it's a big ask for you to have to do all this on your own. That's why I'd like to ge permission form you for either me or one of the engineers to create a draft version of your most ubiquitous infobox, {{Infobox Item}}. We'll probably have to add some code to either Wikia.css or Common.css, but it would deal exclusively with infoboxes, and be pretty clearly labelled.

After it's complete, you could kick the tires and help us finesse it until you were ready for it to go live.

So whaddya think? Is anyone opposed to us to providing this prototype? — CzechOut <staff /> 18:44, October 21, 2015 (UTC)


Does it interact properly with Lua? Can it handle styling and attributes? Can it actually compete with the stuff I can make Module:Infobox do? MolMan 18:49, October 21, 2015 (UTC)

Meh - Per mol's comment. What I would prefer to see you convert is our upcoming redesign of the monster infobox: User:Gaz Lloyd/cook pls, generated using Module:Infobox Monster. I believe our plan is to (eventually) convert all infoboxes to use this style and be based on Module:Infobox. If that can be fully converted, retaining all the functionality it currently has (i.e. the switch infobox component - especially if that functionality can extend to mobile), then I'll certainly reconsider. (The javascript needed to run the infobox is on the page, just put it into your console; I'm waiting on the infobox being finalised and having the code looked over before putting into common.js.) Quest.png Gaz Lloyd 7:^]Events!99s 19:09, October 21, 2015 (UTC)

Well, lemme circle back to a point Mol made. This isn't about competition. You'd have to be able to demonstrate that Lua was currently actually working on not-desktop for that to be the case. And it's not, really. For instance, I'm looking at Bronze dagger on my iPhone, and the principle Lua module involved, invoked by |exchange = GEMW, doesn't show up. All I get is an infinite "loading" message.

We have a small unit of engineers who are trying to find Lua solutions for the new infoboxes. But this should be properly understood as the first effort at making Lua work on not-desktop — not as competition for something that is currently working. Fortunately, RuneScape is not alone in the desire to see a positive outcome to the Lua issue, so I hope you'll join with us and the other Lua communities in finding a path forward! It would be very helpful indeed if you could help us get up to speed with Lua at RuneScape by briefly outlining all of the uses of Lua present in {{Infobox Item}}. — CzechOut <staff /> 19:15, October 21, 2015 (UTC)
We're not very concerned about mobile traffic because RuneScape is a game you play on a desk top/lap top. Our main focus is what people on the Oasis skin see, because that's where most of our traffic is, and where we always expect it to be. As our main focus, we make sure things work there first, and we've never been too worried about whether or not mobile users can see everything perfectly. With that said, the switchfobox functionality hinges on Lua to run properly, so we're not going to abandon it. If we can use the new infoboxes alongside Lua and have them do everything we already can do, then it's fine, and we won't have a problem changing over. But if we can't have our infoboxes function the same, then sorry, we're not interested. As far as presenting information goes, it is certainly a contest. What we have now does what we want it to do perfectly fine. If portable infoboxes can't compete, then they should just throw in the towel. MolMan 19:23, October 21, 2015 (UTC)
Also, the module used to display the exchange price works perfectly fine on mobile. The "Loading..." you see is something that requires JavaScript. JavaScript not loading on wikiamobile has been the norm for years. MolMan 19:30, October 21, 2015 (UTC)
Could you develop that point, please? When I'm looking on an iPhone at a page that uses an infobox with this Lua module, I don't see the intended output. So how is it, in your estimation, working "perfectly fine"? I'm asking to try to figure out what you would consider a "successful" conversion, so that we know what goal we should be working towards. — CzechOut <staff /> 20:45, October 21, 2015 (UTC)
If you see "117 coins", then the module is working fine. MolMan 20:47, October 21, 2015 (UTC)
To just expand what Mol is saying, the "Loading" would not be fixed by having the new portable infoboxes unless they allow for javascript to run on the mobile skin. svco4bY.png3Gf5N2F.png 20:50, October 21, 2015 (UTC)
So, if I'm hearing you rightly, you don't actually expect JS to be working in mobile — because it's not now doing so — and so that's not a requirement of measuring portable infobox success. It would therefore be helpful to enumerate which Lua elements you expect to work on mobile, and which you don't. Or maybe you could point us in the direction of a page that uses {{Infobox Item}} in such a way that it fully uses all variables, so that we can compare current infoboxes to our prototype. I'm just looking for a fair measuring stick of success.
I think it's also incumbent upon me, though it will complicate this discussion, to explain why I think it's better to focus on {{Infobox Item}} rather than the new prototype Gaz is working on.
You might already know all of what I'm about to say, but I think it's important to get a realistic view of custom JS on Wikia. In the first place, custom JS will probably never be on mobile. And in the second, we're in a whole different world of custom JS, even on desktop. Consequent to recent security issues, you're going to have to get all JS reviewed, with the real possibility that it won't be passed. If you're planning an elaborate expansion of JS here, as Gaz Lloyd has suggested, I think you need to allow for the possibility that new JS will be disqualified as a potential security threat. Of course, I'm not saying that it definitely will be rejected. We're trying to allow for some level of custom JS without exposing the whole network to attack. But I feel it would be absolutely irresponsible of me not to inform a community I've long admired that things might not go your way. Speaking not as staff, but as a fellow admin, I would strongly urge finding less JS-dependent methods for your infoboxes. That way, your time won't be wasted.
In any case, and speaking again as staff, I think it makes more sense for us to try to mock up a new version of an infobox that exists and is in heavy current use, than trying to make a version of an infobox that isn't either finished or in current use, and depends on JS elements which may never be in the final version. — CzechOut <staff /> 21:30, October 21, 2015 (UTC)
Our JavaScript is unlikely to get rejected because we have people well versed in it, and we're not looking for anything that could remotely become a threat. I don't know what you mean by Lua elements working on mobile, because everything Lua works. We can't give you examples that are of Infobox Item, because we've not looked at that for Lua yet. Lua is able to handle a lot with reading, augmenting, and manipulating variables. You can see this perfectly in Gaz's example page. Try using inspect element and looking at the div tag with the "infobox-switch-resources" class. That tag and its children is created fairly easily from the reusable table of parameters. It also supports any number of arguments (we're using "name1", "name2", etc. for example). I guess I'm not being clear enough for you. We're using Lua to construct and read infoboxes no matter what. What you need to be trying to sell to us is Portable Infoboxes working together with Lua. If we can use the infobox syntax by creating it and processing it in Lua modules, all the while outputting what we expect, we might consider the change if we see a benefit. If you can get Lua devs to create a useful library to facilitate this, you could probably see us getting on board even easier.
As for JavaScript again, we (or at least me) opt for doing as much as we can with everything else before JavaScript. Especially since the stupid review changes. But as far the mentioned functions, GECharts and Switchfo box simply cannot function any other way. The majority of our infoboxes and their functions are created with either wikimarkup or Lua. And if you can make things work enough to impress us, maybe we'll be making them with Portable Infoboxes too. MolMan 21:48, October 21, 2015 (UTC)
The insinuation that our admins would try to add malicious code is gross. Please do not treat us as the enemy. Quest.png Gaz Lloyd 7:^]Events!99s 22:49, October 21, 2015 (UTC)
He's not implying wiki admins are the enemy because they're malicious. He's implying wiki admins are the enemy because they're stupid and entitled. --Saftzie (talk) 21:09, October 23, 2015 (UTC)
haha top bantz m8 Quest.png Gaz Lloyd 7:^]Events!99s 21:11, October 23, 2015 (UTC)\
So stupid... So entitled... MolMan 21:14, October 23, 2015 (UTC)
I may be stupid but I'm not entitled ʞooɔ 21:21, October 23, 2015 (UTC)
You're entitled to be stupid. MolMan 21:23, October 23, 2015 (UTC)
Czech, this is the wrong place to start making threats about not approving our JavaScript. I get that you're trying to push portable infoboxes, but that comment is pretty transparent and disappointing.
If you have solutions to the problems we're using JavaScript for (specifically, efficiently displaying multiple infoboxes in a space and memory-efficient manner) then we'd be interested. However, given that portable infoboxes aren't up to the challenge of much simpler infoboxes, this seems unlikely. Otherwise, banging on about JavaScript approval (which, by the way, is totally ridiculous to begin with) is not relevant to the portable infoboxes debate. In fact, the only reason it even got brought up was because you chose to use the price graphs as an example of the current mobile infoboxes sucking. As others have noted, this is due to Wikia's general failure to support JavaScript on mobile, and is orthogonal to the rest of the discussion. ʞooɔ 01:53, October 22, 2015 (UTC)

Comment - Pretty much what TyA is referring to, the inability of WikiaMobile since WikiaPhoneOld to support CSS and JS on the mobile skins. In the past, they used to use CSS and JS, but whenever WikiaPhone was turned into WikiaPhoneOld (and the new skin was named WikiaPhone, then WikiaMobile & WikiaApp), the support ended. The WikiaApp skin doesn't support them either which is what the GameGuides use to display content. Besides, I've tried to mess with portable infoboxes with a one-off template. It didn't look nice and used too much space. Not to mention that the mobile skin is crippled by all the advertisements that present themselves like self-playing videos that launch under 5 seconds of reaching the domain. This is all too reminiscent of Venus. Ryan PM 21:06, October 21, 2015 (UTC)

Well, I understand your fears of Venus, having lived through that as a user myself. i don't think the metaphor is apt, though. The only thing this thread is trying to accomplish is to get permission to make one prototype, based on an existing infobox, and for you guys to compare the two. I hear you, Ryan, on the styling problems you may have encountered. I don't know when you made your attempt, but our engineers have been working super-hard to overcome a lot of those difficulties. And the advantage of having engineers actively work here at RuneScape for a bit is that they may well uncover ways to improve the coding, or know styling tricks you never considered in your initial attempts. :) — CzechOut <staff /> 21:39, October 21, 2015 (UTC)
Understanding that the goal of this proposal is to get the editing base to accept portable infoboxes and how they might be beneficial to the mobile audience. I'm looking at the [[w:c:reddead:John_Marston|John Marston]] and the [[w:c:readdead:Inquisitor|Inquisitor]] articles on the Red Dead Wiki and what I notice in WikiaMobile is that the styling is non-existent. I loathe having information displayed without a logical separation of the item above, below, and what is beside the focused item.
Whenever I do use my iOS device, I always use Chrome to make the site appear as Oasis. WikiaMobile needs to be improved, but for this thread I would want portable infoboxes to gain separation of elements in a more distinguishable light rather than #E6EBF2 for a section header and #F2F6FA for the rest of the infobox. I can't tell the difference unless at extreme angles. Ryan PM 22:11, October 21, 2015 (UTC)

Addition - I feel like another issue here is control. Using the portable infobox code would put the display of some of the most used templates conveying the most core information further out of our direct control. And display of content being in Wikia's control hasn't worked out well for us in the past: we've had the content moved from a nice layout to one that focused on ads more when monobook was made back seat, and then again when monaco was retired in favour of the even more ad-centric oasis (nevermind that we developed a mainpage and content for years for monobook, and then monaco), the global nav got changed into a window-size limiter and most recently the font size everywhere was increased, making everything look bad for no apparent reason. Our javascript was wrenched away from us and eventually returned with a warning of "be good, we're watching your edits", despite the dedication and experience of our editors. An admin has been threatened with being de-sysoped and blocked for fixing the some terrible design decisions. You can see why we're feeling burned.

As Ryan mentioned, having CSS and JS disabled on mobile really cripples some of our stuff, but the thing is we won't go out of our way and cripple the content to accommodate that. (The worst part for me is that inline styles are stripped too, which is why the new infobox gets a lot of excess junk on mobile - it's all hidden with CSS/inline styles, but mobile just shows it anyway.) If the option comes down to the desktop users getting a cool tool and the mobile users getting something that looks weird VS nobody getting anything, I'd take the former. Especially as most mobile browsers have a Request desktop version button or mode anyway, which makes everything look fine and work as expected. (Even on my old 3rd gen iPod Touch it doesn't cause any lag, even using some of our more heavy JS calculators (anecdotal, I know).) I don't really understand why it is disabled, but fine.

As a final note on this rant, we're some of the most dedicated editors around. A lot of us have hundreds of days of time poured into editing this wiki. Many editors have spent more time editing than actually playing. We're the most popular RS fansite, and we're very proud of that - the developers themselves even made their own wiki, and even with the makers of the game actively editing it, they couldn't compete with us so shut editing earlier this year. I criticise Wikia (on an almost daily basis) because of this dedication to the wiki - if stuff Wikia does/has done gets in the way of myself or my fellow editors adding content, or improving our layout, or creating new tools, or contributing in any way, we're going to push against it. As it looks right now, portable infoboxes would reduce the efficacy of our infoboxes, if they can't be used via/in conjunction with lua or JS. Quest.png Gaz Lloyd 7:^]Events!99s 22:49, October 21, 2015 (UTC)

Comment - Some of Wikia's devs tried to convert our infoboxes to the new syntax and last I heard our use cases were too complex for what the product supports. If that's changed feel free to have a go, but unless there's absolute surety it's possible this entire conversation is moot. Either way, it's rapidly increasing in complexity which is a reflection of just how complicated our infoboxes and general set up is and how inflexible portable infoboxes are outside the known use cases. Perhaps it's a case of distilling what it is that we need to have and building from there, but that hasn't happened and likely never will if a forum advertising a product is the main way it's been achieved so far.

Structured data is something I'm very interested in - I've been checking up on it every few months for years since an older implementation was trialled on CoD Wiki, but the insinuation here is that Wikia is mixing presentation with page data and the two are interdependent. I really hope that's not the case. cqm 15:59, 22 Oct 2015 (UTC) (UTC)

So I went and had a go at the new infoboxes with one of our simpler examples: Template:Infobox City/Draft. The lack of inline styling for anything that isn't part of the argument and it's formatting a huge concern as it's a high use template that should be styled in the Common.css (assuming we can reuse the styles for multiple infoboxes). Some CSS issues we'd need to address however:
  • The labels shouldn't be wrapped. In tables this is simple to fix, but this uses extra padding and flexbox which make it harder.
  • The theme really sucks. No idea how much work that is to fix, probably a lot even with a custom class to hook off.
  • No caption tag as it's not a table so we'd need to adjust the switch'fobox script a to account for that. No idea how much work that is, but it wasn't a big script last I looked.
  • Need to center the image placeholder text (minor issue).
  • Bottom links need to be right aligned or centered and shrunk.
  • Caption needs more bold.
I'm hesitant about such heavy styling changes because this is supposed to be in active development and could therefore break at a moments notice. And because Common.less is uneditable as because staff removed the editinterfacetrusted right meaning we're back to a 50kb stylesheet. cqm 20:48, 22 Oct 2015 (UTC) (UTC)

Oppose - you are putting ads inside the new infoboxes, and a video since CzechOut is implying that I've photoshopped it --Iiii I I I 20:52, October 22, 2015 (UTC)

No wonder Wikia's so keen on the new info boxes (づ。◕‿‿◕。)づ Korasi's sword.png Archmage Elune  TalkHS Void knight deflector.png fetus is my son and I love him. 20:55, October 22, 2015 (UTC)
Looks shopped. I can tell by the way the box clearly shrinks and expands accommodate the ad when it's a bug. Korasi's sword.png Archmage Elune  TalkHS Void knight deflector.png fetus is my son and I love him. 02:15, October 24, 2015 (UTC)

Absolutely fuck no - Putting ads where information is? NO! MolMan 20:51, October 22, 2015 (UTC)

Support Wikia putting ads in Mol's signature. --Saftzie (talk) 21:16, October 23, 2015 (UTC)

Oppose - Agree with everyone else. (also if you're putting ads there, then no way.) jayden

nty - lol ads in infoboxes haha nice one Star Talk ayy lmao ( ͡° ͜ʖ ͡°) 20:59, October 22, 2015 (UTC)

Oppose - These featureless infoboxes are not going to work for us, and realistically there's no level of support that you could give that would come close to what we need just to maintain the status quo. We're not going to give up wide-ranging functionality for dubious claims of a better mobile experience (by the way, that 2.7 million pageviews number you're quoting is incorrect -- it includes [[w:c:2007.runescape]] and all other subdomains). I'm curious about the structured data, but I have the same concerns as Cqm (and I'm curious whether there's anything DPL can't replicate with more control). I don't know if the ads in infoboxes are even related to this, but shame if they are. Here's an idea: if you want to make the mobile experience better, how about making the ad situation a bit less atrocious? You guys are the reason AdBlock exists. ʞooɔ 21:23, October 22, 2015 (UTC)

[1] Korasi's sword.png Archmage Elune  TalkHS Void knight deflector.png fetus is my son and I love him. 21:36, October 22, 2015 (UTC)

Oppose - per the cook man Korasi's sword.png Archmage Elune  TalkHS Void knight deflector.png fetus is my son and I love him. 21:36, October 22, 2015 (UTC)

Hey guys :) I can understand that you're incensed by the surfacing of this artwork which appears to show ads in infoboxes. I am, too. I've talked to a number of people more senior that me, and they've all reacted with shock and horror. This isn't supposed to be happening, and I've never seen it anywhere else. Nor can I reproduce it. I've logged out and tried multiple browsers and multiple IPs all over the world. And nothing works to trigger the ads for me.
I would very much appreciate it if you could give me some time, maybe as much as a day, to figure out what's going on. If anyone else can reproduce, it would be extremely helpful to take screenshots and list your general geographic location (country is fine) here. — CzechOut <staff /> 21:41, October 22, 2015 (UTC)
The fact that this can happen at all is concerning. Even if this isn't meant to happen, the fact that it's even able to kills what little interest I had for portable infoboxes to begin with. MolMan 21:46, October 22, 2015 (UTC)
Reproduction steps: open in Firefox without any extensions. Opens up after 5-10 seconds, disappears within a minute. [2] appears to be loading from Location is Seattle, WA, United States. Nice to know that portable infoboxes at least have *some* functionality our infoboxes don't. ʞooɔ 21:52, October 22, 2015 (UTC)
That repro doesn't actually work for me, which is why I've had some initial difficulty in helping. But engineers at Wikia have now found the bug and are going to quash it. Thank you for helping us identify this rogue ad. Not only are we going to fix the coding error itself, we're going to outright block the advertiser on your site so that it never happens again.
Although I've not been an employee at Wikia for very long, I — like many of you — have had long term responsibility for the technical maintenance of a wiki. Who among us can really say that we've never made a coding mistake that temporarily made a site worse? Of course we all have, because code is complex and we can't always remember that this adjustment we made on, say, 2 December 2011 is going to screw with something we're doing today. C'mon, that happens all the time. Please, let us fix this, and then create just one infobox to see if they could possibly work for you. — CzechOut <staff /> 22:00, October 22, 2015 (UTC)
Though I hesitate to draw any sweeping connections between this (hopefully isolated) incident and our overall feeling towards portable infoboxes, it's hard not to see the obvious one -- portable infoboxes are a black box, controlled by Wikia, that we should probably expect to drastically change at a moment's notice, or behave incorrectly, or do things that we as a community don't like. We don't have that problem with our current infoboxes, because it's literally just a collection of HTML, CSS and some isolated JavaScript that we have complete control over. Even if these portable infoboxes did everything we want, it would be a hard sell for that reason alone. Given that they do none of what we want, you can understand why everyone's opposing. ʞooɔ 22:09, October 22, 2015 (UTC)

Oppose - Can portable infoboxes perform to RSWiki's needs? No? Then they're not needed here. Also lol @ the ads, stay classy. Dragon 2h sword old.pngCallofduty4 Talk 03:21, October 23, 2015 (UTC)

Oppose - One pretty big complaint that most unregistered users have of us is our ads. I know you "quashed" that one in those awful new infoboxes, but who's to say it won't happen again? That was completely unprofessional if you ask me, even if it was a so called "bug". Also as someone said earlier, RuneScape is not a mobile game - it is really playable only on desktops and laptops. I've only used the mobile version of the wiki like...twice ever. And it sucked. Even though I'm not the only person who used it ever, I can guarantee you that the mobile version is not our priority now. 7kyt1iT.gif --WINE OF GOOD HEALTH (Actually Stinko) 15:15, October 23, 2015 (UTC)

Plenty of others think the mobile experience is god-awful, and it's not because of the infoboxes looking a bit weird: it's because of the cancerous levels of ads. eg Quest.png Gaz Lloyd 7:^]Events!99s 15:40, October 23, 2015 (UTC)

Strong oppose - The ads are bad enough as is, and we don't need another place for them, especially not in a place that should let you access the most vital information quickly. User talk:ThePsionic.png: RS3 Inventory image of User talk:ThePsionic ThePsionic Special:Contributions/ThePsionic.png: RS3 Inventory image of Special:Contributions/ThePsionic 15:28, October 23, 2015 (UTC)

EDIT: Read the comment streak above, still strongly oppose per Cook at the bottom of those rants. User talk:ThePsionic.png: RS3 Inventory image of User talk:ThePsionic ThePsionic Special:Contributions/ThePsionic.png: RS3 Inventory image of Special:Contributions/ThePsionic 15:30, October 23, 2015 (UTC)

Hey again everyone :) I wanted to thank you all for expressing your views. Even though they were largely negative, they were obviously borne of a place for deep concern for this community. That's a way better result than just passive acceptance, in my book. I can't promise you that you won't hear of this again, but my job here was to try to get you some direct attention by our engineers in Poland this week, and they've already gone home. Nevertheless, your comments have definitely been heard by our engineering team, and will go into our deliberations as we go forward.

But I did at least want to you see an example of a fully Lua-ed up, fully styled, portable infobox, so that maybe you'd have a truer idea of the potential of PIs. Don't worry; we didn't touch RuneScape. :) As you know, the guys at Marvel are pretty au fait with Lua, so [[w:c:marvel:Iron_Man_With_Portable_Infobox|here's the portable version of a character infobox]] and [[w:c:marvel:Kurt Wagner (Earth-2182)|here's the non-portable]]. I think they're pretty damned close stylistically, and it definitely proves Lua can indeed work with PIs. — CzechOut <staff /> 18:14, October 23, 2015 (UTC)

Sorry, but this completely misses the point of our Lua concerns. Your example shows a portable infobox with a bunch of Lua module invocations inside of it. Our issue has never been that "Lua invocations don't work inside portable infoboxes" - it would have been pretty screwed up and surprising if they didn't. Our issue is that you can't return a portable infobox from a Lua invocation, like we do on Module:Infobox_Monster (p.main) for normal infoboxes, which, by the way, is pretty simple for normal infoboxes because it's just returning HTML. The Marvel Lua portable infobox example is nowhere near being suitable for us -- it's just tiny Lua invocations inside a portable infobox, instead of the entire control flow being determined by Lua. ʞooɔ 01:59, October 24, 2015 (UTC)
I don't even know where to begin with how bad and stupid that example is. That still relies entirely on portapotty infoboxes to fetch and work with parameters, and only uses Lua to do I don't even know what. Your example is literally the opposite of au fait. Those modules shouldn't even be modules, they're simple parser functions.
Using multiple invoke statements like that is so awful it enrages me. What I actually mean with Lua, is something like [[w:c:camtest:Module:Infobox]]. This doesn't work, but it's pseudo code of what we'd actually be interested in, if we still were.
So why doesn't your bad example work? Because it can only handle whatever basic functions portapotty infoboxes can. Check out Module:Infobox Monster. Portapotty infoboxes can't even come close to replicating function slayerarg to any degree of efficiency. Can we use custom attributes? It looks like we can't. No matter where I put it. Which sucks. I can do that with the current infoboxes though 7:^]. Current infoboxes also look better. And, most importantly of all, we control how they work. MolMan 02:01, October 24, 2015 (UTC)

Closed - As of right now, I don't feel this feature will gain consensus to be implemented here. Aside from the advert issue, which is hopefully an isolated incident, there's a variety of reasons it does not meet our needs.

In the interests of improving portable infoboxes should we ever want to revisit this idea, a list of features that are currently lacking, as brought up above, are as follows:

  • Inline styling.
  • Custom attributes on a per infobox/row/group/label/argument field/etc. level, e.g. data-*, classes, and other standard attributes.
  • Ability to integrate with our switch infobox setup (or at least provide similar functionality). To quote Cook above, we're essentially looking for the ability to "efficiently [display] multiple infoboxes in a space and memory-efficient manner".
  • Lack of sane Lua integration - use of #invoke within the XML source of the template is not considered superior to the previous use of ParserFunctions due to concerns of readability and maintainability when constructing an infobox. A pseudo-code example I mocked up that is closer to the functionality wanted can be seen at [[w:c:camtest:Module:Infobox]].
  • Lack of per-wiki control. As this is an actively developed feature, it's reasonable to assume it's API is unstable. While the tags are updated in cases where they become obsolete or deprecated (or so I believe), there are concerns over stylesheets potentially breaking along with certain features being forced on us irrespective of whether they're desired. This may improve over time as PI becomes more stable, but it remains a concern right now.

I'm sure we'd like to give mobile viewers a decent experience for what we offer, even if it is a cut down version of desktop in terms of functionality and depth of information. However, isn't enough to warrant compromising the desktop site on any level. cqm 12:15, 28 Oct 2015 (UTC) (UTC)