Template talk:LoadBox

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)