User talk:FeRDNYC/Sandbox/Archive

From GodWiki
< User talk:FeRDNYC‎ | Sandbox
Revision as of 18:41, 17 December 2018 by FeRDNYC (talk | contribs) (move discussions to archive)
(diff) ← Older revision | Latest revision (diff) | Newer revision β†’ (diff)
Jump to navigation Jump to search

New infobox development 2018-12

Everything related to development and testing of the new {{Infobox}}-based infoboxes, archived now that this page is no longer home to that effort. -- FeRDNYC (talk) 18:41, 17 December 2018 (UTC)

Updated status of these templates

Row separation styling added

So I've now applied the row separations I was talking about in my last update to all of the example infoboxes. It makes them feel a little less "smooth", but I think it's worth it for the clearer formatting, especially when cells wrap to multiple lines. The background color is the infobox standard background (no shading), and I darkened the shading behind all of the data cells a little bit so that they contrast a bit more with it.

Other fixes (navbar, |worn= decoration)

In addition, I turned off the Edit links in the navbar, and fixed the two problem emoji that were discussed farther down. The decoration applied to {{Equipment|worn=...}} entries will be as follows:

  | weapon = {{Decorate item|πŸ—‘οΈ|[[:Category:Weapons|Weapon]]|where=before}}
  | shield = {{Decorate item|πŸ›‘οΈ|[[:Category:Shields|Shield]]|where=before}}
  | head = {{Decorate item|🧒|[[:Category:Heads|Head]]|where=before}}
  | body = {{Decorate item|πŸ‘•|[[:Category:Bodies|Body]]|where=before}}
  | arms = {{Decorate item|πŸ’ͺ|[[:Category:Arms|Arms]]|where=before}}
  | legs = {{Decorate item|πŸ‘–|[[:Category:Legs|Legs]]|where=before}}
  | talisman = {{Decorate item|πŸ€|[[:Category:Talismans|Talisman]]|where=before}}

Begin rollout soon?

I'm reaching a point where I'm pretty happy with these, and would like to start staged deployment. (The new {{Town}} first, I figure.) what do people think, is anything still lacking. (If it's something that's already been discussed and I haven't mentioned it again, that probably means it's slipped my mind completely, so please do remind me.) -- FeRDNYC (talk) 20:01, 12 December 2018 (UTC)

Another issue

OK, at least one other thing I have to deal with before launch: The purple label cell background for {{Town}} actually suuuuucks behind purple (visited) links, so if there are going to be hyperlinks in there (there are) then I have to tweak the color.

Brown, maybe? I've really been trying to avoid yellow, but maybe it's the right choice. Or at least, you know, differently purple-ish. Maybe magenta. Or plum. --- FeRDNYC (talk) 22:03, 14 December 2018 (UTC)


The row separation looks very good, I think it definitely aids readability in large infoboxes, and the equipment decoration is looking great as well. (I agree with your sentiments that it's a shame there aren't better emoji for some of them, but from the menu available, I think these are good choices, and a better solution than putting in a tiny [[File:...|12px]].) I think rollout's ready, I don't see why any further tweaking shouldn't be done in the wild. Starting with {{Town}} seems good to me!

There's one small request I'd like considered for the new {{Monster}}, which I put up on Template talk:Monster a little while ago. There are so many monster articles with great latin names that I feel like it deserves a place in the infobox :) I was thinking of a |latin= optional parameter which, if no |image= is supplied, would appear as a data cell, but if there is a non-blank {{{image}}} supplied would instead appear as a caption under the monster image (a bit like is done on the other wiki, e.g. wolf). Because this would be a new parameter I think if it's going to be done it's worth doing before launching the new {{Monster}} :) What do you think? -- Djonni (talk) 10:45, 14 December 2018 (UTC)

I'm cool with it β€” I don't know if it matters whether it happens before or after the rollout, since the rollout isn't going to involve editing any articles anyway. But sure, might as well flesh it out sooner rather than later, regardless of the rollout.
Anyway, like I said, I'm cool with it being a field. As far as the placement... well, I mean, because of the fallback image, there's always going to be an image in the infobox, and I'm not crazy about the idea of any field moving around based on which image is showing. If the text shouldn't be in the caption of the fallback image, then it shouldn't be in the caption period. Which is fine, there are plenty of other places I can put it:
  1. In a subheading field above the image, below the title
  2. In a header field below the image (regardless of that image's nature)
  3. At the bottom of the box, in the below line between the data rows and the navbar
...Ok, I guess there are three other places I could put it. I'm sure I could think of more, but I'd just be exhausting technical possibilities, not throwing out anything realistically desirable.
Another thing is that... on the other wiki, the image captions are set using the infobox parameter image_caption, and the convention of putting latin names in the caption is just that: mere convention. But the captions are written first and foremost to describe the image they caption.
Some of our existing Monster infoboxes, like Pastafarian and Queen Kong for example, don't really lend themselves to having their existing image captioned with a latin description of the monster in question, because the images aren't simply "photos of" the monster in question.
All of which is to say, if we're going to have an image caption field, I'd rather it be an image caption field, and people can caption with latin phrases if they like. But the caption field will only be valid with an explicitly-set image to caption, and would not display otherwise. If OTOH we're going to have a "latin name" field, I'd prefer it not be placed in the image caption, because there's no way to ensure that it will serve as an appropriate caption for the infobox's displayed image in every case. -- FeRDNYC (talk) 20:49, 14 December 2018 (UTC)
Just to editorialize a little, though, I should also say that I think it's possible to overdo it on the whole Latin thing. Every time I look at {{Navbox dragons}} I have to remind myself that the text under the title is supposed to look that way, and someone didn't actually vandalize the navbox or fall asleep on the keyboard while editing it. -- FeRDNYC (talk) 20:53, 14 December 2018 (UTC)
You suggestion of making it a subheading field, above the image but below the title, seems quite logical. And much simpler and saner than it moving around and becoming a caption. Perhaps it's worth us taking a look at how it goes on T-34 — Machina terminatura (future active participle of termino, feminine nominative, "machine about to terminate") seems suitable.
And that "Hc Svnt Dracones" was originally me testing |above= and I ended up keeping it in on a whim, but if you find it so distracting we can take it out ;) -- Djonni (talk) 18:11, 15 December 2018 (UTC)
It's fine, I'm just amazed it's actually Latin (is it?). Who knew they were so... line-noisey? (Line-noisesque?) Anyway, I'll put together a preview of the T-34's latin field, and get the color of the Town infobox sorted out, and then these will finally be ready to go. ...Actually, maybe I'll do that in the opposite order, since I still do want to roll out Town first. Monster should probably be last given that it's the most transcluded, and the most complex. -- FeRDNYC (talk) 18:27, 15 December 2018 (UTC)

Status of these templates

So I think at this point, I'm pretty happy with things the way they are. I added just the barest possible 87%-transparent shading to the data rows and behind the image (in the label/header color, but like I said, mostly-transparent), which I think helps tie them together better, as does the navbar-line styling.

The only change I'm still mulling over is possibly reintroducing some of the inter-cell spacing that I eliminated when I ported from Wikipedia. There, the cells don't touch each other, each one has about a 2px gap between it and any of the adjoining cells. I don't want to turn that back on between each cell, only between each row. Because I think it can get hard to match the labels up with their data, when a lot of label lines are all stacked on top of each other and some of them wrap to multiple lines. I fixed some of that by changing "Map abbreviation" to "Map abbrev." (thus using the HTML <abbr> element to expand the abbreviation for... abbreviation #InceptionBWONNNNNNG), so it shouldn't ever wrap to two lines, but still... like, take a look at the Terminator T-34 example. It's not awful, but it feels like the rows run together just a little, to me.

Anyway, any thoughts on that, or anything else about these? Or should I plan to make them live soon, hopefully? -- FeRDNYC (talk) 09:09, 9 December 2018 (UTC)

A 2px gap could work well, while looking into the history of wikipedia:Template:Navbox (this to be precise) I noted the use of <tr style="height:2px;"><td></td></tr> to achieve that effect. I didn't try to copy it to see how it looks, but if some separation like this works well in the infoboxes it's worth considering putting something similar in {{Navbox}} too, using the same solution, whatever it is.
I have no idea how <abbr>...</abbr> interacts with screen readers, but it doesn't seem to work great on mobile (styles the text with a dotted underline, but doesn't seem able to show the title), perhaps just "Map code" might be a simpler solution? -- Djonni (talk) 10:50, 9 December 2018 (UTC)
Oh, {{Navbox}} already has cell separation, since the table gridlines are visible. There's no need to add anything additional there. No, it's the fact that the table grid structure is (intentionally) suppressed in {{Infobox}} that can cause things to run together, especially since I squished them together even further. But I have a |rowstyle= I can stuff a little padding-top or padding-bottom into, whichever works out better. (Or both, even, for simplicity.) I just have to decide what I want to do.
I have no idea how <abbr>...</abbr> interacts with screen readers, but it doesn't seem to work great on mobile Arrrrgh, fucking W3C! What the hell use is a technical specification without an implementation specification!?
"Here's this cool semantic markup you can apply to text, to give it additional meaning beyond the displayed content."
"Oh, neat, and browsers will present that to the user in some obvious and consistent fashion?"
"Ummm... I guess a few of them might. Sure, why not? It's definitely possible. That's not really our area."
perhaps just "Map code" *sigh* Yeah, I guess so. Thanks for pointing that out. Fucking W3C. -- FeRDNYC (talk) 20:57, 9 December 2018 (UTC)

Regarding the artifact info boxes

I vastly prefer the "Double Cross" variant, where the background behind the item name is separate from the background behind the information categories. The way the background in the "Apothecary in a Bottle" flows through behind the picture makes it easy at first glance to mistake the information pertaining to the item to be something separate. If all of the changeable fields (picture, information items) have the same background and all of the permanent fields (title, information categories) have the same different background, it becomes easier to sort at a glance for what one needs to know. --SourceRunner 29NOV2018

Hm... OK, yeah, I can see that. Thanks, that's helpful. I'm guessing your preference would be for Terminator T-34 version 1 over version 2, then, along those same lines?
Although, regarding the Double Cross image, I had already planned on cropping that tighter anyway β€” done, in fact, just now; it might require a forced reload to update your browser's image cache before the change is visible β€” and I'd even toyed with the idea of making the white background transparent, so the image is only the coin itself. I wonder how that would look, in the different infobox formats? Hmm... maybe I'll give it a try. -- FeRDNYC (talk) 02:03, 30 November 2018 (UTC)
Transparent image edit done and uploaded (as File:Double Cross Coin.png), two additional versions of Double cross added to Sandbox. -- FeRDNYC (talk) 02:35, 30 November 2018 (UTC)
With the transparent background, it makes clear to me that I'd personally prefer the Double Cross version 3 and the Trojan Horse version 1, with the image background matching the variable field backgrounds, and subtle accent colours. I think the overall colour shades are pretty much spot on there. -- Djonni (talk) 11:40, 30 November 2018 (UTC)
Completely agreed with Djonni over the info box format preferences, now. They look great. -- SR 30NOV2018

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ Oh, good β€” I hated the shaded versions of the infoboxes (second Terminator T-34, Mace of amnesia), I just didn't want to say anything for fear it might bias reactions. But I think they came out just plain awful. (I've been terrified someone might actually prefer them.)

Double cross version 3 is actually == Double cross version 1 (my only change was inserting the transparent version of the image, the infobox structures are identical), and structurally that's also equivalent to the first two monster infoboxes (Trojan horse and the first Terminator T-34), so I think we'll consider that basically the plan going forward β€” including the Pet and Boss accent colors for {{Monster}} infoboxes. Though I think I'll mute the Pet coloring a bit, it's a little too day-glo right now.

Now I just have to work up a similar style / color scheme for Equipment. (I think I'll keep the orange, just apply it in the same manner as the preferred artifact/monster styles. And purple can be the {{Town}} color scheme, which I might as well implement since if we're going to do this then the town articles should really be part of the first round β€” they're the ones with the most consistent infobox use across the entire wiki.)

I also have to work out whether I want to apply any additional styling to {{Artifact}} for any of the |type=healing/activatable/bold, and if so, what/which/how much. -- FeRDNYC (talk) 23:48, 30 November 2018 (UTC)

Well there's no fields that are subordinate to |type= like there are with |boss= or |pet=, so I don't think it needs any header-like styling. But it might be nice to have it link to the corresponding Category:Type artifacts.
Although, now that I think about it, there could be fields subordinated to |type=activatable, if we so wished.
Also, historically all activatables were bold, and fishing introduced non-bold activatables. I don't know if it's worth worrying about that distinction in the taxonomy of artifacts in the GodWiki in general, but it's worth keeping in mind if we're discussing artifact typology. It could be that |healing=yes, |bold=yes, and |activatable=yes is now a more sensible parameter design. -- Djonni (talk) 00:32, 1 December 2018 (UTC)

Well there's no fields that are subordinate to |type= like there are with |boss= or |pet=, so I don't think it needs any header-like styling.

No, but I was thinking more broadly β€” could be anything. Shading the background of the Type field, changing the shading of the infobox entirely (different levels of green?), adding an icon somewhere... no limits but my imagination! And, you know, good taste. But I like features that provide at-a-glance differentiation between different groups of articles, IMHO that's one of the major benefits of article infoboxes β€” the ability to both summarize and differentiate the various articles they're placed on.

But it might be nice to have it link to the corresponding Category:Type artifacts.

Meh. The article already will, at the bottom β€” I think that's probably sufficient. I prefer linking to articles over linking to category lists, generally, for in-article links. Especially when the categories are known to be as incomplete as ours are (except for Category:Towns). If you think about it, a link to, say, List of Monsters is a lot more useful & informative than a link to Category:Monsters, where you'll find just a random, relatively-small subset of the game's monster population represented. -- FeRDNYC (talk) 07:25, 1 December 2018 (UTC)

... a link to, say, List of Monsters is a lot more useful & informative than a link to Category:Monsters, where you'll find just a random, relatively-small subset of the game's monster population represented.

Actually, yeah, you're completely right. :)

Shading the background of the Type field, changing the shading of the infobox entirely (different levels of green?), adding an icon somewhere... no limits but my imagination!

I've been thinking about this, and I particularly like the icon idea :) Maybe adapting {{Decorate artifact|where=before}} for this would be clever. If we're sticking to emoji/Unicode, you could use βš•οΈ for healing items (Type: βš•οΈHealing); maybe πŸ’° for bold (Type: πŸ’°Bold); perhaps simply @ with some kind of embellishment for activatable ({{Decorate artifact|where=before|<div style{{=}}"font-weight: 900; color: blue;">@</div>|Activatable}}, for example, would give us: Type:
), and for normal I... Haven't got any clever ideas. (But maybe normal would be unembellished anyway).
I'm sure something similar could be achieved with 17x17px images, Γ  la {{god}}, too, but that technique doesn't scale with font sizes and isn't particularly accessibility friendly. -- Djonni (talk) 15:05, 2 December 2018 (UTC)
Not saying that I'm committed to doing this, but for the sake of argument, other possibilities for Activatable: ▢️ πŸ”› (The second one says "ON!" below the arrows, at least in my emoji font, but wow is that small.) ...The size thing also may be an issue with πŸ’°, which I had to copy-paste into my emoji picker to find out was supposed to be a money bag. -- FeRDNYC (talk) 14:11, 5 December 2018 (UTC)
{{Decorate artifact|where=before|<div style{{=}}"font-weight: 900; color: blue;">@</div>|Activatable}} Heh, you really like <div>s inside <span>s, huh? πŸ˜‰ -- FeRDNYC (talk) 14:16, 5 December 2018 (UTC)
For Bold artifacts, another option would be to just write the word in Bold. -- FeRDNYC (talk) 05:21, 8 December 2018 (UTC)

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ OK, I've added an example Town infobox, restyled the Equipment infobox along the lines of the others and added some emoji-decoration to it (nothing for Artifact (yet?), I did the Equipment thing since I was working on it anyway), and pruned out the rejected example formats, so there's only one style of each infobox active. (Some may have more than one example, still, but they're all using the same template version.) Any further thoughts or reevaluations welcome. -- FeRDNYC (talk) 05:25, 8 December 2018 (UTC)

Heh, you really like <div>s inside <span>s, huh? πŸ˜‰ Shhhh πŸ˜‹ that was just a brain fart that time, I temporarily swapped my divs and spans. ::facepalm::
Looking at that town example (which looks great), I'm wondering if there's an opportunity for some more eye candy, that's actually handy at-a-glance info. What do you think of something like this:
<span style="border: 1px solid #aaa; background: #ffdddd; padding: 1px;">{{Decorate item|πŸŽ‰|Lavish parties|where=before}}</span>: πŸŽ‰Lavish parties
<span style="border: 1px solid #aaa; background: #ddffdd; padding: 1px;">{{Decorate item|🏦|Good savings|where=before}}</span>: 🏦Good savings
<span style="border: 1px solid #aaa; background: #ffdddd; padding: 1px;">{{Decorate item|πŸ™|Weaker prayers|where=before}}</span>: πŸ™Weaker prayers
πŸŽ‰Lavish parties β€’ 🏦Good savings β€’ πŸ™Weaker prayers
(Loosely based on {{god}}'s styling). Details like what emoji, padding, etc notwithstanding, what do you think? Fine line between at-a-glance visual clarity and too much... And I think I'm too tired for good judgement right now πŸ˜… -- Djonni (talk) 21:45, 8 December 2018 (UTC)
Well... TBH I kind of hate the {{god}} styling, always have (boxes around text, ugh) β€” it kind of killed me emulating it for {{Guild link}}, but consistency is important. I don't think I want to spread that any further, tho. There are other ways to achieve... whatever the goal is, there.
But the bigger issue is that, right now, the "Known for" data is a free-form text field, and I'm not really sure how it could be made anything other than a free-form text field, without massively complicating the template. I think even if we were going to style the contents of that field, the best way to do it would be with a template for that purpose, something like a |known={{known for|+parties|-prayers|+savings}} or whatever (syntax subject to revision obviously, if we even decide it's a good idea at all) β€” point being, development of that has nothing to do with the infobox code directly, so I think it's best to take one thing at a time and worry about that after the boxes themselves are sorted out. -- FeRDNYC (talk) 09:18, 9 December 2018 (UTC)
Very true. If you like we can revisit the styling of {{God}}, {{Guild link}} and {{Pantheon link}} once the dust's settled on these other changes -- Djonni (talk) 10:39, 9 December 2018 (UTC)
Forgot to mention — I think the emoji highlight for equipment type (πŸ—‘οΈWeapon) looks really good. Looking at the set in the template:
  | weapon = {{Decorate item|πŸ—‘οΈ|[[:Category:Weapons|Weapon]]|where=before}}
  | shield = {{Decorate item|πŸ›‘οΈ|[[:Category:Shields|Shield]]|where=before}}
  | head = {{Decorate item|⛑️|[[:Category:Heads|Head]]|where=before}}
  | body = {{Decorate item|πŸ‘•|[[:Category:Bodies|Body]]|where=before}}
  | arms = {{Decorate item|πŸ’ͺ|[[:Category:Arms|Arms]]|where=before}}
  | legs = {{Decorate item|πŸ‘–|[[:Category:Legs|Legs]]|where=before}}
  | talisman = {{Decorate item|🧿|[[:Category:Talismans|Talisman]]|where=before}}
I note that the Nazar amulet for Talismans doesn't render in Chrome and many other browsers (it was only added to Unicode and Emoji versions 11.0 in 2018, that batch is not yet widely supported). A handful of alternative options with wider rendering: πŸ“ΏPrayer beads πŸ’ŽGem stone ✨Sparkles
Yeah, I was disappointed to see that the amulet didn't show up in mobile Chrome (or the Godville app browser, more critically), since it was really the only option I even halfway liked out of the entire emoji database. I think I might actually go with the ring πŸ’, at least until the amulet is more widely supported. The other options would be sports medal πŸ… or military medal πŸŽ–οΈ, both of which make me unhappy. I guess if I wanted to really stretch, there's always the four-leaf clover πŸ€.
Besides that one, the Android rendering for the "helmet with white cross" emoji is so awful β€” it's an icon tile, not a "real" emoji, and looks like flat ass β€” that it has to go, as well. Which means it's probably going to end up being the baseball cap 🧒, even though I was trying to avoid that after using both the t-shirt and jeans. But the top hat 🎩 is just too "much" (and too male), the woman's hat πŸ‘’ is just too "much" the other direction (and too female), and the crown πŸ‘‘ is way too painfully cliche. I suppose I could use this: 🀠 (It's certainly different.) FeRDNYC (talk) 16:09, 11 December 2018 (UTC)
I also think the shield emoji is better here than in {{Guild link}}, so I'm going to change the Guild symbol to a fleur-de-lis: ⚜️ -- Djonni (talk) 08:18, 11 December 2018 (UTC)
Oh, OK... if you think it's necessary to change it. I was conscious of the fact that they used the same icon, but I didn't think it was a problem. But if uniqueness is important, that's cool. I think the fleur-de-lis works as a choice. -- FeRDNYC (talk) 16:16, 11 December 2018 (UTC)
TBH after I hit save I thought it was a bit too impulsive to change it unilaterally, and thought I should have suggested the change, rather than just done it... so I won't take it personally at all if you undo the edit! :) -- Djonni (talk) 17:05, 11 December 2018 (UTC)
Enh, I like first instincts on questions like that β€” if your immediate reaction was that it shouldn't be the same, then it probably shouldn't, because other people will probably have that same reaction (at least some). -- FeRDNYC (talk) 18:01, 12 December 2018 (UTC)

Null/whitespace parameter values and default behaviour

As a general observation on infobox behaviour:

I'd like to add a quick start copy-paste blank template to the documentations for infoboxes, to help new editors, particularly those that are working entirely through the GodWiki mobile apps, who can't easily switch back and forth between tabs/pages while editing without losing their work.

Example 1

The trouble is, with the current way that the default "Unknown" values are produced, that doesn't work very well, since if a parameter is included but left blank, the Unknown doesn't get rendered. As in:

({{picture}} suppressed in examples)

Monsters of Godville
| image = 
| class = 
| habitat = 
| description =

Example 2

Monsters of Godville
Class: Partially filled-in example
Habitat: All over the wiki
| image = 
| class = Partially filled-in example
| habitat = All over the wiki
| description =

Example 3

To have the template render "Unknown" when a parameter isn't filled in, it has to look like this, which is much less helpful and clear to future inexperienced editors:

Monsters of Godville
Class: Partially filled-in example
Habitat: Unknown
Description: Unknown
| image = 
| class = Partially filled-in example
| habitat 
| description 

Can we make the behaviour of the new infoboxes consistently such that including |class/habitat/description=blank will still render the "Unknown" default? -- Djonni (talk) 12:14, 6 December 2018β€Ž (UTC)

Example 4

To clarify, I'd make a quick-start template something like this:
| image = 
| class = 
| habitat = 
| description = 
| boss = no
 | boss-type = dungeon/1ab/2ab/3ab/above/dig/quest
| pet = no
 | levels = 
 | feature = Rideable/Dungeoneering/Sailing
which I would expect to render, if pasted as-is, like:
Monsters of Godville
Class: Unknown
Habitat: Unknown
Description: Unknown
and so on in a predictable way, as parameters were set. (I realise suddenly that that would probably require adding some logic to {{{feature}}} as well.) At the moment, it renders the same as the first example above. -- Djonni (talk) 11:33, 6 December 2018 (UTC)
Absolutely, that's the way it's intended to work, and any errors are just that. (It's an easy thing to get wrong in implementation, and really most of our template code suffers from inadequate testing (mostly due to limited use) that would catch these things.)
If the new infoboxes are going to go live any time soon, though, it's questionable whether it's really worth fixing this in the old ones. It might be more productive to just accelerate the release of the new ones. (Certainly, this should be tested on those and fixed wherever needed, before release.) -- FeRDNYC (talk) 08:29, 7 December 2018 (UTC)
Yeah, that's why I thought I'd mention it here with the new boxes, rather than just going in and fixing the existing ones (I could be wrong, but I think it's just the difference between using a {{{parameter|Default}}} construction vs an {{#if: {{{parameter|}}} |... construction).
As for acceleration, I didn't mean to imply it needs to be all nailed down post-haste, it wasn't my intention to apply pressure or anything :) Life first, game second. --Djonni (talk) 09:01, 7 December 2018 (UTC)
Oh, no, I'd rather get them live sooner than later. I made an edit a few hours ago that fixed this for all parameters on all of the existing new-infobox implementations @ User:FeRDNYC/Template Sandbox. I was working on adding a Town infobox to the set, and restyling the Equipment version along the lines of the styles we'd settled on for Artifact and Monster... but I was editing the code in an offline editor, and my system decided to freak out crash while I was working on it, so that was fun and I lost those changes. I'm working on them again now, alongside half a dozen other things I tell myself I'm doing at the same time. (Which probably means I'm making progress on none of them. Then again, I did get this posted so that's progress?)
[Re: Example 3, headings added for reference purposes] Just for the record, BTW β€” example/boilerplate transclusions should never be written like that, since it's not the same at all. While it's true that none of our infoboxes currently use unnamed parameters for anything, that definitely isn't something that can safely be assumed for the future. Passing in random parameter names as unnamed parameter values would be playing a dangerous game. Far better that the template being illustrated be fixed, before we even consider creating examples/boilerplates that encourage inserting wrong parameters into template transclusions. If we ever wanted to make use of the unnamed parameters for anything (which isn't likely with infoboxes, but is a possibility with other templates, so it's a bad precedent to set), we'd have to scour the wiki looking for instances of copy-pasted transclusions that still have 'dummy' unnamed parameters set. -- FeRDNYC (talk)

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ And for reference / in the interest of testing...

Monsters of Godville
Class Unknown
Habitat Unknown
Description Unknown
{{User:FeRDNYC/Template Sandbox|template=monster
{{User:FeRDNYC/Template Sandbox|template=artifact2
Equipment of Godville
Worn Unknown
{{User:FeRDNYC/Template Sandbox|template=equipment
Towns of Godville
Home milestone Unknown
Map code ??
Known for Unknown
{{User:FeRDNYC/Template Sandbox|template=town

...Heh, writing these tests made me realize I hadn't actually found a fallback town image yet, I just threw "Town.jpg" in there as a placeholder β€” shouldn't be surprised that there's already an existing file with that name, though. I suppose it works well enough.)

Looking at them all together like this, they still need... a little something more, in the most-default/barebones instances. I'm not sure what. Might be as simple as continuing the colored-background styling down to the below row, where the navbar lives (assuming we're going to court disaster by leaving that instead of turning it off)... but I'm not sure. I think part of what I don't like is that the image is slightly narrower than the rest of the rows, and the shading doesn't extend behind it. I know you guys said you liked that better, but... something feels off about it, to me. I'll play with it a bit more. -- FeRDNYC (talk) 07:49, 9 December 2018 (UTC)

Well, you won't be able to tell now because I re-worked the styling, so you'll only see the new versions here. But trust me, it used to be different. I took a screenshot. I think at this point I'm pretty happy with things the way they are. -- FeRDNYC (talk) 09:02, 9 December 2018 (UTC)
They're looking good, I think extending the styling to the bottom is a good call, and it looks like you fixed the image widths (I assume by pulling the padding out of the cell holding the image), and that's definitely looking better.
... where the navbar lives (assuming we're going to court disaster by leaving that instead of turning it off) We had toyed with the idea (somewhere... so many concurrent talk threads!) of switching the Β· E off for infoboxes. I agree that having the one-click encouragement to edit the template on every page is... ill-advised. (I suppose it would also work as a plainlink to{{FULLPAGENAMEE}}&action=edit, rather than a link to edit the template directly.)
Oh, and Towns.jpg happens to be the header image at Towns, which I think works out just fine! :) -- Djonni (talk) 09:54, 9 December 2018 (UTC)
Afterthought: does max-width work for table columns? A max-width: 50%; on the header column might help the balance on those default value templates. -- Djonni (talk) 09:56, 9 December 2018 (UTC)
It appears that it does not, either in percentages or em β€” it's just ignored, and the column is damn well wider anyway. So I just set the data column min-width, which I was already setting on the label column to avoid that side getting too squished. Which I guess may be the source of the imbalance in the first place (though it's only min-width: 8em inside a 25em-wide infobox), since TBH I'm really surprised that it's overbalancing past 50%-per-side when both sides' content fits comfortably in that width. I would've expected it to gravitate towards balanced columns unless something pushed past the allotted width.
Anyway, with the data columns styled min-width: 12em everything looks more even. -- FeRDNYC (talk) 22:42, 11 December 2018 (UTC)