Template talk:LoadBox

You can see examples of how this template might be used at User:Munin295/LoadBox test. &mdash;Munin295 &middot;  &middot; 02:24, 11 May 2013 (UTC)

Curse sidebar
I like the general idea, but that Compact MHC schematic is interleaved with the Curse sidebar! That is, the grid is beneath the sidebar, but the tiles float above it. Also, this would basically be one circuit per box? --Mental Mouse 11:42, 8 May 2013 (UTC)


 * I got rid of the tables and they wrap now. –ultradude25 ᐸ Talk Contribs 13:30, 8 May 2013 (UTC)
 * Thanks! Looks much better.   --Mental Mouse 15:02, 8 May 2013 (UTC)


 * Thanks, I've got the sidebar turned off so didn't see that.
 * "one circuit per box?" -- It's whatever makes sense at that point in the article. For example, some of the circuit articles currently discuss multiple circuits in a single paragraph, so they might show all the circuits in a float=none LoadBox under the paragraph. Probably a good analogy is the choice between using one or more floated image thumbs or using an image gallery (and there's no reason a schematic gallery couldn't include an image too, not to reduce load time but just to keep it with the schematics if that makes sense). &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 15:51, 8 May 2013 (UTC)

TOC Limit didn't work
TOC limit doesn't hide TOC entries by their heading level, but by their depth in the generated TOC outline, and in wiki TOCs those don't necessarily match. So it wouldn't hide the level-5 headings I was using unless they were actually preceeded by h2, h3, and h4 headings.

But I switched to using p.mw-headline and that seems to work -- in the sense that it generates a good-looking box with a "Load content" js link, like I want, but doesn't clutter up the TOC with potentially dozens of schematic titles. I hadn't tried that previously because for some reason I thought the server would strip out .mw-headline from non-h# elements, but it didn't. : )

I've given the p's an id equal to the title, so it should still be possible to link to them if you want (but only someone who has examined the LoadBox template or the generated html would know that).

&mdash;Munin295 &middot;  &middot; 03:39, 9 May 2013 (UTC)

Features requiring string functions?
So here's two features I'm thinking of adding, but they would both require using string functions (which may be slow):


 * Relative paths
 * Allowing paths to be specified as . This would require checking for an initial slash and then building the wiki links with.


 * Title defaulting to page or subpage
 * If the title isn't specified, it would check to see if the page parameter specified a subpage and use the deepest one. If no subpage was specified it would use the pagename. So,  would produce , and   would produce.

Both of these wouldn't actually provide any additional functionality, but would just be conveniences for authors.

So, how bad are string functions? Obviously the whole point of this template is to reduce load times, so… avoid completely, or maybe worth it?

&mdash;Munin295 &middot;  &middot; 05:38, 9 May 2013 (UTC)


 * Since these features wouldn't add functionality, only convenience, I decided to err on the side of not increasing server load and didn't implement them.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 02:01, 11 May 2013 (UTC)

Blocks and Items Template
Is this template going to be used for Template:Blocks and Template:Items? Or was the discussion in the Community portal about something else? –Goandgoo ᐸ Talk Contribs Edit count 02:43, 11 May 2013 (UTC)


 * I honestly hadn't thought of that (and we all were just talking about it!). It wasn't designed specifically for those, but I suppose it could. Here's one possibility:
 * It's a little plainer than the current navbox. Right now much of the content of the redstone circuit articles is offloaded with LoadPage into article fragments because the schematics are taxing on the server. I created this template so that we could offload only the schematics instead of entire sections, so one of my design goals was to put as little load on the server as possible. But it probably wouldn't be too much to add some aesthetic options, the same way navbox does, if folks want.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 04:12, 11 May 2013 (UTC)
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 04:12, 11 May 2013 (UTC)


 * If you can add an option to center the title, I'd call that a close enough facsimile of the current navboxes. As long as the other admins are happy with it, I think this can be put into operation. -- Orthotope 10:12, 11 May 2013 (UTC)


 * Yeah I'm fine with it, setting the title bar to display none was quite clever and a nice simple solution until this can all be fixed properly, and now that the border is removed, it even almost fits in.
 * My only issue now is that it requires moving the content to a separate page. I think using noinclude we may be able to keep it together, which I'm going to test now. –ultradude25 ᐸ Talk Contribs 10:30, 11 May 2013 (UTC)


 * Yep there we go User:Ultradude25/Blocks. All kept in one page.
 * –ultradude25 ᐸ Talk Contribs 10:39, 11 May 2013 (UTC)
 * –ultradude25 ᐸ Talk Contribs 10:39, 11 May 2013 (UTC)


 * Oh and look at that I got it styled pretty similar to the actual navbox. –ultradude25 ᐸ Talk Contribs 10:59, 11 May 2013 (UTC)


 * LoadBox's main div has its own default style attribute, and the style parameter may try to override that in the same attribute (for example, ultradude's example currently generates html: ). Do all browsers resolve such conflicts the same way? Maybe move the current defaults to a css class, which a style attribute can override, and make the style attribute only generate if style is specified?
 * EDIT: CSS does have rules to cover this situation (later overrrides previous), so it should be fine. (and I've changed LoadBox's default border to match other boxes on the wiki, which negates that specific example)
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 14:53, 11 May 2013 (UTC)


 * If everything's on one page, we'd still have to keep it protected, because someone could just replace the LoadBox call with thousands of sprite templates (and will the various noincludes keep regular edits from creating the ripple slow-down?). If we split Blocks (et al.) into two pages, we can keep the LoadBox call protected on the main template page, but allow the content it loads to be edited by anyone without ripples (it could still be vandalized, but the vandalism won't be able to bring down the wiki).
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 15:38, 11 May 2013 (UTC)


 * That's a very good point. In that case it would certainly be best to have the page separate. I believe the best way to execute this would be to move the pages to the /content sub-page with redirect, then replace the redirect with the loadbox template, which will be then locked sysop-only.
 * As per the CSS thing, that's the whole idea with Cascading Style Sheets. ;) –ultradude25 ᐸ Talk Contribs 17:48, 11 May 2013 (UTC)


 * That's exactly the procedure I was thinking of; keeping the redirect avoids breaking everything during the transition. Putting it all on one page is a cute trick, though, and could work for some of the less-used navboxes such as Environment. -- Orthotope 18:11, 11 May 2013 (UTC)

Would it make sense to future-proof the Blocks revision as much as possible by moving the styling (including the float removal) to Common.css? We could wrap the LoadBox call in, say, a  div to differentiate it from other kinds of LoadBox calls (e.g., schematics) and then apply styling by position or adding hang classes to the elements generated by LoadBox. This will allow admins to change/adjust the styling in the future without editing Blocks which would force the server to regenerate 100s of page caches. &mdash;Munin295 &middot;  &middot; 20:00, 14 May 2013 (UTC)


 * As long as we're all happy with how it is right now, and are ready to apply it. –ultradude25 ᐸ Talk Contribs 20:25, 14 May 2013 (UTC)


 * Looks good to me! Non-admin says let's do it!
 * Maybe just test the process on a less critical navbox first?
 * : ) &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 20:51, 14 May 2013 (UTC)


 * As I somewhat mentioned in my recent post on the community topic, my contribution to consensus is that this is good.  21:11, 14 May 2013 (UTC)


 * The main nav templates are Items, Blocks, Entities, Minecraft, Environment, Mojang, Gameplay, Pocket Edition, and Xbox 360 Edition, in descending order of number of transclusions. Mojang and Xbox 360 don't use spritesheets, and Minecraft and Pocket Edition only have a handful, so those probably don't need to be converted (though we might anyway for consistent styling). Since there seems to be general agreement among everyone who's voiced an opinion on this, I'm going to apply it to Gameplay and Environment. If we're happy with how those work, it can be rolled out to the highest-use templates. -- Orthotope 02:33, 15 May 2013 (UTC)


 * Implementing this isn't too hard, mostly need to make a few style changes to the navboxes (shamelessly stolen from Ultradude's mockup above). It doesn't respect tags, so they need to be replaced with . Also ran into a MediaWiki bug: moving a page to a subpage of itself, and choosing to move subpages, ends up moving the page twice. -- Orthotope 06:21, 15 May 2013 (UTC)


 * Oh, shoot. We're going to have to protect LoadBox now, aren't we? Every edit to LoadBox will propagate to 1000s of pages. : ) &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 06:40, 15 May 2013 (UTC)


 * Yep. That's why I started by only applying it to two of the less-used navboxes: to see if any more tweaks are needed before it's protected. -- Orthotope 06:48, 15 May 2013 (UTC)


 * Oops. Didn't think of that. I jumped the gun.  06:50, 15 May 2013 (UTC)


 * Looking at Redstone circuits, which has both an old-style navbox and the new-style Gameplay navbox, it looks like the old navbox uses margin-top for spacing, while I used margin-bottom for LoadBox spacing (which made sense when I was thinking the default would be a right-floated box aligned to the top of its accompanying paragraph). Perhaps add  to the style parameter when using LoadBox for navboxes?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 07:02, 15 May 2013 (UTC)

I have moved the styling to common.css. The documentation, categories and talk should be kept with the real template, not the content. This is especially true for the includeonly categories, since those won't work at all unless on the real template. –ultradude25 ᐸ Talk Contribs 16:33, 15 May 2013 (UTC)

Do we want to move the load button to next to the edit button? So it'd be [load] [edit]? Or even potentially remove the edit button altogether, the original navbox doesn't have one. –ultradude25 ᐸ Talk Contribs 16:51, 15 May 2013 (UTC)


 * With the default state now "collapsed" the navbox doesn't stand out, so if someone does notice it you want them to immediately figure out that there's something they can do with it, and having the load link right next to the title helps that.
 * From a usability standpoint, having edit links on these boxes is more important than having edit links on article sections, because it's a lot harder to figure out how to edit these. Only remove the edit links if vandalism is too risky.
 * If we keep the edit link, don't move it next to the load link -- that would make it harder to figure out what to do with this gray box at the bottom of the page (choices are a barrier to usability).
 * Maybe the titles should be changed to make it more obvious what these gray boxes are for: "Block Navigation", "Block Links", "All the Blocks", etc.?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 17:27, 15 May 2013 (UTC)