Forum:New Metabox development

The following text has been relocated from Forum:New theme proposal:

On the subject of updating Metabox, I accidentally worked up this as a new style of message box. What do you think?

 Hello! I don't have a name yet, because I'm brand new! What do you think of me?

As I said, this design was more-or-less a complete accident, much like the headers on the main page. I think it would be a pretty good replacement for Metabox, but I'd like to hear what you all think about that. Here's another "real case" example to compare the two:


 * Metabox deletion template

 Delete This page has been nominated for deletion. Reason: just because
 * "New Metabox" deletion template

You can discuss this nomination at Category talk:Candidates for deletion. Thoughts? --  LostInRiverview talk • blog  •  contribs 05:53, March 27, 2015 (UTC)


 * The metabox is excellent! It looks really pretty! But I've already told this to LiR on IRC. :p I have one thing in mind. In the above examples, you used icons from TS3 and TS4. The one from TS4 is rescaled to 60px, but all icons from TS3 are in 54x54px. You can see the "Hello!" header text doesn't align with content text.


 * This can be fixed if the header text is wrapped around, like how LiR did it with the content text by adding margin to the text. The wraparound is necessary so that the text would align if it's really long. Since header text is rarely more than 2 lines, LiR didn't use it there, and I agreed. But seeing this small problem, I think that wrapping around the header text can also solve it.

  Hello! I don't have a name yet, because I'm brand new! What do you think of me?


 * What do you think?  Nikel  Talk  –  Vote!  06:28, March 27, 2015 (UTC)


 * Another thing is that since TS3 icons are smaller than TS4 ones, the icon above looks hanging to the border... Maybe if it's centered it would look better for smaller icons? I'll try tweaking it and see how it looks.  Nikel  Talk  –  Vote!  06:31, March 27, 2015 (UTC)

  Hello! I don't have a name yet, because I'm brand new! What do you think of me?  Delete This page has been nominated for deletion. Reason: just because

You can discuss this nomination at Category talk:Candidates for deletion.


 * There. I made the div width 70px and the icon float center. It's subtle, but... I like it better.  Nikel  Talk  –  Vote!  06:38, March 27, 2015 (UTC)
 * You're right, that is an improvement. You can actually notice the header protrudes slightly more on the left now. Very good job. --  LostInRiverview talk • blog  •  contribs 06:41, March 27, 2015 (UTC)

I was kinda skeptic about this new theme, but it really looks good! I love the green color here! Øôppdëckš 08:09, March 27, 2015 (UTC)


 * I think the Metabox looks good with the fresh look. I do Nikel's improvement make it look better. I like it. -- Icemandeaf (talk) 17:00, March 27, 2015 (UTC)

  Hello! I don't have a name yet, because I'm brand new! What do you think of me?  Delete This page has been nominated for deletion. Reason: just because

You can discuss this nomination at Category talk:Candidates for deletion.


 * I added rounded borders (because I like the roundedness, but you can do away with it if you don't want it). A left margin to the icon was also added so that it wouldn't hide the newly rounded header. And I also added a bottom margin to the Metabox so that the shadow isn't completely hidden when there are multiple boxes stacked onto each other. I know it is very subtle, but it seems to make a difference to me. What do you all think? -- Icemandeaf (talk) 17:21, March 27, 2015 (UTC)
 * When I developed the theme and the main page style, I deliberately avoided rounded corners. My preference would be to keep the squared corner style going in the other templates, but of course if others would like to have the round corners instead, that's something that can be decided. My focus right now is to get Metabox in-line with the main page style, which does not use rounded corners. So, if we choose to make this box with rounded corners, then that should probably be applied to the main page style as well. As far as my own personal opinion, I would rather keep the square corners. --  LostInRiverview talk • blog  •  contribs 18:41, March 27, 2015 (UTC)
 * Understandable, and I am actually ok with that. So here is the changes without the rounded corners. Very minor stuff, but I think the margins added make it look nice. -- Icemandeaf (talk) 18:53, March 27, 2015 (UTC)

 <div style="background: #3571C3; width: auto; margin: 5px; font-side: 110%; font-weight: bold; text-shadow: 1px 1px 2px #333; color: white; box-shadow: 1px 1px 3px #777;"> Hello! I don't have a name yet, because I'm brand new! What do you think of me? <div style="border: 1px solid #E0E0E0; text-align: left; background: #F5EAFA; width: 85%; box-shadow: 1px 1px 3px #777; margin-bottom: 1px;"> <div style="background: #9932CC; width: auto; margin: 5px; font-side: 110%; font-weight: bold; text-shadow: 1px 1px 2px #333; color: white; box-shadow: 1px 1px 3px #777;">Delete This page has been nominated for deletion. Reason: just because

You can discuss this nomination at Category talk:Candidates for deletion. I do have a concern regarding font colors versus the header colors, specifically for the yellow/gold "featured content" templates. Take a look: <div style="background: #; border: 1px solid #E0E0E0; text-align: left; width: 85%; box-shadow: 1px 1px 3px #777; margin-bottom: 1px;"> <div style="background: #; width: auto; margin: 5px; font-side: 110%; font-weight: bold; text-shadow: 1px 1px 2px #333; color: white; box-shadow: 1px 1px 3px #777;">Featured Article
 * "Featured content" gold

Additionally, there are other matters that should be considered. Right now, Metabox can be displayed in two forms; the "standard" form, or a "small" form, like this for example:

I'm not sure how we would accommodate a header on this template, or even if we'd want to.

As well, right now metabox can be displayed with or without an image; what will this new template look like if an image isn't included? --  LostInRiverview talk • blog  •  contribs 21:18, March 27, 2015 (UTC)

Continued discussion
I have relocated this discussion onto its own thread so that we can further focus on the issues relevant to Metabox.

I have taken the code that we've refined above and placed it into a new template: Metabox2. Metabox2 is generally in a testing phase right now, but I feel most of the bugs are worked out. There are a few matters still up for discussion, of which I have listed out a few. I am sure this list is not exhaustive so if I've forgotten something please point it out.
 * What to do when Metabox doesn't have an image. Right now, Metabox can be utilized either with or without an icon. I have edited Metabox2 to make the image parameter optional, but I am not sure if my solution is the most elegant. Observe:


 * Simply put, I'm not sure if having that blank space on the left side of the template is ideal. Surely using an icon would be the preferred approach but in some situations it is not practical to do so. Additionally, several templates that utilize Metabox do not have images, so we need to do our best to make sure Metabox2 is backward compatible.


 * No header specified. Another matter of backward compatibility is that of the template's header when the  parameter is not specified. On Metabox,   is an optional parameter, so there are several cases where a headline is not specified. I have tried to adapt Metabox2 to this situation, while still maintaining some portion of the header bar, since the bar itself is a defining feature of the template.


 * As you can see, there are a few issues with my approach, not the least of which is that the image inside the template is larger than the template itself. As well, I have maintained a small strip of the "header bar," but is this the ideal approach?


 * Small version. In preparing for rolling-out the template, I prepared a small version, just as Metabox Prime has the option to set a small version of the template. I haven't gotten any feedback on this design, however. Check it out:


 * Legacy support for old parameters. Metabox one utilizes parameters for custom colours:  and  . Metabox2 has two custom color options as well:   and  . For sake of backward compatibility, I have set Metabox2 to interpret a bordercolor input as if it were the headercolor, and we can carry this into the full rollout of the template as well. However, it may be necessary or preferable to make other modifications to the template as well. Specifically I'm talking about changing either the names of parameters or the accepted entries for those parameters. The biggest question mark right now for me is whether we should adjust the   parameter to allow File: input or not. Right now, when specifying an image to be used in the template (on Metabox1 and Metabox2), the name of the file must be included without the File: prefix. Most other templates that utilize images require that prefix, so should this template be edited to conform to that quasi-standard? And if we chose to do that, would Metabox2 have any issues with backward compatibility?

As I said, there's a few matters still up for discussion. --  LostInRiverview talk • blog  •  contribs 18:56, March 30, 2015 (UTC)
 * I'm not really sure if I like this template or not. While it does match the new theme and the template looks good when its all filled out and in the example without the image, the headerless versions look a bit strange. I don't know how you'd go about fixing that but I'd be interested to see what it looks like without the header bar. All of the stuff you've said in regards to legacy support is fine by me, if you're trying to make it so that it will accept images regardless of whether file is present I'd be really happy with that as I've nearly slipped up and made mistakes with that several times. That's all I can think of for now.
 * Here's the template without a header:

<div style="background: #; border: 1px solid #E0E0E0; text-align: left; width: ; box-shadow: 1px 1px 3px #777; margin-bottom: 1px;">
 * As you can see it's a bit plain. I'd prefer to find a way to accommodate legacy support for templates lacking a headline, rather than throwing out the whole template. If it comes down to it, maybe we can change over the templates so that they use headline? The alternative is to find some way to spruce up the template for non-headline cases.
 * Regarding file prefix acceptance... I think I may have a way to accomplish this.
 * I haven't tested this yet to see if it will work. If someone wants to try it, I'd appreciate it. Otherwise I can get to it later on. --  LostInRiverview talk • blog  •  contribs 07:08, March 31, 2015 (UTC)
 * I haven't tested this yet to see if it will work. If someone wants to try it, I'd appreciate it. Otherwise I can get to it later on. --  LostInRiverview talk • blog  •  contribs 07:08, March 31, 2015 (UTC)


 * Overall, I like the new metabox. The theme design is pretty good to me, if it's not for the current issues. I have several things to point out:
 * For the metabox without headline, how about we add a single space as the default text? Check out my sandbox (2nd metabox).
 * For the metabox without image, how about making the text wrapper not use padding? Check that out on my sandbox too (3rd metabox).
 * For the File: prefix, I'd say let's not think about other templates first. Since metabox is used in a lot of templates, I think it's best to assure that it's backward compatible. Let's just follow how the current metabox utilizes the  parameter.
 * Do you think we should add a clr at the end of the box? If you look between the 1st and 2nd metabox in my sandbox, I added a horizontal line there. The line doesn't cover the whole width because it's crossed by the icon. It seems uncommon that an icon exceeds the box, but still, it might be something to consider.
 *  Nikel  Talk  –  Vote!  13:49, March 31, 2015 (UTC)


 * Alright, I implemented your suggestions in points 1 and 2 onto Metabox2. I did plan on implemeting clr but have encountered some issues that have caused me to temporarily remove it from the template. You can see what I mean here. I wanted to test how Metabox would interact when placed alongside other templates, specifically infoboxes like Sim. The result was... not as I had expected. I've done some experimentation and it appears that the image used on Metabox2 will continue to move downwards on the page as more instances of a Sim or Simbio template are added, and the image will align itself to the top of the final instance of the template used on that page. To be honest I'm not exactly sure of why this is - could it have anything to do with the fact that the image on Metabox2 is set to float left? I'm baffled at this point. Obviously this is a significant problem, and I wouldn't feel comfortable rolling out the changes until it's fixed. --  LostInRiverview talk • blog  •  contribs 03:02, April 3, 2015 (UTC)
 * Whoa, that's a terrible bug. I have no idea what's wrong with it either. I'll try to figure out what's wrong if I can.  Nikel  Talk  –  Vote!  04:10, April 3, 2015 (UTC)
 * I don't want to speak too soon, but it looks like you fixed it. -  LostInRiverview talk • blog  •  contribs 05:04, April 3, 2015 (UTC)
 * It looks like I did speak too soon. You did indeed fix the problem with it interacting with Sim, but a new problem has introduced itself. Behold:


 * That's the small version of the template. Whatever fix was implemented, it did not take kindly to this version. I'll take a look at what's going on. --  LostInRiverview talk • blog  •  contribs 05:08, April 3, 2015 (UTC)
 * Nope, looks like that error was my fault. It looks like it is fixed now. I see no other errors that need to be corrected. --  LostInRiverview talk • blog  •  contribs 05:12, April 3, 2015 (UTC)

Yeah, I was going to report it after having lunch, but it seems that you've found it (and even fixed it). This is why you shouldn't postpone a report. :p Anyway, there's one other side effect by adding  attribute. The height of the metabox doesn't extend to the height of the image if it's too large. Normally, it will follow the height of the image. This is pretty subtle, but I'm not sure how to fix it. We might as well put it on a low priority in the to-do list.  Nikel  Talk  –  Vote!  05:42, April 3, 2015 (UTC)
 * I had noticed that issue as well. Could we perhaps set the height of the largest element to only be a minimum of a certain height in relation to the imagesize? So the template right now is set to display images at a fixed 60px for the standard and 45px for the small version. That size can be adjusted with, and I've gotten the text and margins and everything else to re-size depending on the amount in that parameter (that's what all the calculations are for). I'll look into setting a minimum height in the outermost div bracket. --  LostInRiverview talk •  blog  •  contribs 05:58, April 3, 2015 (UTC)


 * Additionally, I've fixed yet another problem, having to do with the margins not being set correctly on small versions when an image is not specified. And I've removed the resizing right margin for text, meaning that no matter what size is used, the right margin for the text will remain 5px. This is to prevent a situation where the image size would cause the text to be squeezed together, since the margins of both the left and right sides were set by the imagesize parameter. --  LostInRiverview talk • blog  •  contribs 07:03, April 3, 2015 (UTC)
 * I was thinking of the same thing about taking the height of the largest element, but thought that it would take a complicated process. I also did notice the squeezed text problem, since the right padding depends on the width of the image. Making the right padding have a fixed length is a better solution. It seems that you've resolved both issues.  Nikel  Talk  –  Vote!  07:13, April 3, 2015 (UTC)
 * Can you think of anything else that needs to be fixed or that should be adjusted? I'm pretty satisfied with the appearance of it and I think that we've likely worked most of the bugs out of it (one can hope, at least). I'd say we're ready to implement the new design in place of Metabox. Of course I don't want to rush to that point, if you or anyone else has any particular issues. --  LostInRiverview talk • blog  •  contribs 07:23, April 3, 2015 (UTC)
 * None at the moment. It's difficult to produce a bug intentionally. It's easier for a bug to surface when we use the template along the way so we can fix it. It might not be a safe path, but if we keep waiting until the template is 100% bug-free, it will never be finished. The template is good enough to use, IMO. After all, I'm not the one who extensively tested it, so I might not have encountered as many bugs as you have.  Nikel  Talk  –  Vote!  07:30, April 3, 2015 (UTC)

Merging into Metabox
Based on the work that we've done above, I think we're nearing the point where we can move the code from Metabox2 into Metabox itself, thus completing the template redesign. Of course, copy/pasting the code from Metabox2 to Metabox would be a simple matter, but I think it would be useful to preserve the edit history on Metabox2, especially as multiple people have worked on it and there were numerous bugfixes included in the diffs and edit summaries. That being said, page history merges are somewhat complicated even on small-scale pages. Metabox, however, is a major template on the wiki. Even if the merge isn't botched in some way, deleting then re-creating a template used by dozens of other templates and on tens of thousands of pages seems like it would cause lots of problems. Is there some way that we can merge the page histories without major headaches? Perhaps Staff assistance? --  LostInRiverview talk • blog  •  contribs 00:32, April 4, 2015 (UTC)
 * Just a thought, maybe you could just copypaste the code over from metabox2 to metabox and add a note of some sort, either through the template documentation, edit summaries or both to check the history of metabox2 to see how it was implemented. Obviously not ideal but there's no risk of anything going wrong here.
 * That would work, on the condition that we don't delete Metabox2. We could set Metabox2 to redirect to Metabox, which would preserve its history. --  LostInRiverview talk • blog  •  contribs 00:40, April 4, 2015 (UTC)
 * Wogan's idea was also my idea. Deleting Metabox to move Metabox2 over and then undeleting everything makes for an unfun ride. Especially considering that Metabox is used on tens of thousands of pages, and it may cause issues on lots of pages while we're at it. --I am  k6ka  Talk to me!   See what I have done  01:06, April 4, 2015 (UTC)

Bug reports
As the merge is now complete, we are now using the newest version of Metabox! However, there may still be some snakes in the grass, so bugs and glitches with the template may be present.

Please leave any bug reports or issues with the template below. --I am  k6ka  Talk to me!   See what I have done  13:28, April 4, 2015 (UTC)


 * I believe I have found a bug related to the Metabox, although I don't know exactly what it is. If you look here, you will see something odd with the move metabox. -- Icemandeaf (talk) 17:03, April 4, 2015 (UTC)


 * Fixed by LostInRiverview. --I am  k6ka  Talk to me!   See what I have done  17:12, April 4, 2015 (UTC)
 * Fixed. The Move template was missing a closing tag on an element on the template, which goofed up Metabox. I fixed the code on Move so it should be okay now. --  LostInRiverview talk • blog  •  contribs 17:12, April 4, 2015 (UTC)


 * Here's another error. As you can see, Metabox clips into and "falls behind" the image posted on the right of Small pet. I'd be curious to see whether the same issue occurred with the old Metabox template... I'll do some testing. --  LostInRiverview talk • blog  •  contribs 15:07, April 6, 2015 (UTC)
 * Okay, it has been a couple days, and to be honest I haven't been able to fix a couple problems with the template. There is the matter that I pointed out above, but a more serious problem has also presented itself. On a number of articles where Metabox is used alongside an infobox, the box itself "falls behind" the infobox, especially on lower resolution displays. By some stroke of luck, the text on the metabox does not fall behind the infobox but actually wraps as necessary, but the box-behind-infobox still looks bad. If anyone wants to experiment with possible fixes, I've created a test template for Metabox; the first version of that page in the page history is identical to the current Metabox design, so you can use that as a base to make changes. I'll keep looking at it but this might be beyond my level of knowledge to fix. Worst-case scenario, we do have a few drastic options. First, I can hard-code a maximum width to the template and force the template to always display as left-aligned, so that the template will never interfere with an infobox. Alternatively, we can roll back to the old Metabox design, which I've tested and does not display the same problem (that trait in itself might also lend itself to a solution to the problem). Obviously, these are last-ditch ideas. --  LostInRiverview talk • blog  •  contribs 05:50, April 9, 2015 (UTC)

Right now, I have a somewhat fix to this problem, on Template:Metabox/test. The test version of the template will no longer overlap with or be overlapped by infobox templates. However, the template has a default width and it will not display in the correct location if that default width exceeds what is available to it; instead, the template will be pushed down the page until a suitable space is found to display at specified width. What we need is a template that will base its width on the space available to it, not on the size of the page itself. On top of this, the new code doesn't display the template in the same way that the current code does. This doesn't affect it functionally, but it would be nice to get the fixed Metabox and current Metabox to look the same. --  LostInRiverview talk • blog  •  contribs 16:28, April 9, 2015 (UTC)


 * This is probably not much different than the fix you just mentioned (although I haven't been able to look at it more closely), but what about adding the style "display:table-cell;" to the main DIV? -- Icemandeaf (talk) 19:17, April 9, 2015 (UTC)
 * There's a few things to consider when looking at this. For ease of reference, I've constructed a simple table comparing and contrasting the four Metabox designs we have - the old Metabox design which was recently replaced, the current Metabox, the revamped form of Metabox on the test page, and a form of Metabox based on Icemandeaf's suggested fix.


 * Icemandeaf's design is the best of the three "new" designs, in that it actually works. However, it doesn't have an adjustable width. The width of the template is completely dependent on the width of the content within it, bound only by the size of the space that it can occupy. Is there a way around that issue? --  LostInRiverview talk • blog  •  contribs 20:20, April 9, 2015 (UTC)


 * At first I didn't understand what you meant, but now I do. How about placing the style in the center tag instead. Does that help? -- Icemandeaf (talk) 22:27, April 9, 2015 (UTC)
 * I don't understand what you mean. --  LostInRiverview talk • blog  •  contribs 23:20, April 9, 2015 (UTC)
 * I could be wrong, but I see a just above the DIV. Since placing "display:table-cell;" within the same DIV that has the width adjustable counteracts the ability to adjust the width, placing it in the element just above it should make it so the resizing is still possible. So that is why I was saying to place the styling in the center tag like this: <center style="display:table-cell;"> -- Icemandeaf (talk) 23:33, April 9, 2015 (UTC)
 * It appears to work as intended. Looking on the Sandbox, the design does not collide with floating elements (infoboxes and images), fits alongside instead of wrapping down, and is re-sizable. --  LostInRiverview talk • blog  •  contribs 23:59, April 9, 2015 (UTC)
 * Everything I said above is true, however there is a problem - the template still defaults to the width of the content inside it. Observe:


 * Now, the template is set to have a default width of 85%, but it's being ignored unless there's enough text to fill the template. The same goes for a customized width - the width is only used if the text inside goes from end to end. --  LostInRiverview talk • blog  •  contribs 00:53, April 10, 2015 (UTC)
 * Hmm... that's odd. That is completely not the behavior that I was expecting. How about using an overflow style instead of the display style. I think "overflow: auto;" or "overflow: hidden;" should get the behavior I was expecting. -- Icemandeaf (talk) 03:30, April 10, 2015 (UTC)

Okay, it looks like that fixed it (knock on wood). Let's run down the checklist.
 * Re-sizeable - check
 * No collision - check
 * Displays alongside floated elements - check
 * Defaults to specified size - check

Alright. Who wants to test it some more? --  LostInRiverview talk • blog  •  contribs 03:52, April 10, 2015 (UTC)
 * I tested it out on some problem pages, and have noticed that the problems are fixed. As such, I've implemented the code to the main template, since the bug that exited was pretty significant. If there are additional issues we can resolve them in due course. Hopefully there are not. --  LostInRiverview talk • blog  •  contribs 04:15, April 10, 2015 (UTC)

I came across a minor bug with Fanon-premade where the image extends well below the metabox. -- Icemandeaf (talk) 04:50, April 13, 2015 (UTC)
 * Okay, I've looked into it. The issue lies in how the image is displayed. We were forced to set the image to  in order to prevent other problems. This unfortunately means that clr or setting   or   in the code simply won't work. If we could clear, it would force the box to re-size to match image size. The workaround that was implemented involves setting the height of the box (the outermost div tags containing the main box style) to be determined by the image size as specified by default (60px) or by the parameter imagesize. However, the size changes horizontal, not vertical size of the image. Most of the images that we tend to use are icons and are generally square-ish or wider than they are tall. So my recommendation in this case is to make edits to the templates on an individual basis, to re-size the image to fit appropriately.
 * Tl:dr Bug won't affect most uses of the template, and fixing it would cause other more significant problems. Unless of course there's a way to have our cake and eat it too, as it were. -  LostInRiverview talk • blog  •  contribs 06:21, April 13, 2015 (UTC)