Template talk:Divbox

TfD nomination of 23:49, 2005 Mar 30

nomination

This portion of the discussion is now closed. Please do not alter or edit it in any way. Those who wish to continue the debate may do so at the bottom of this main section (Discussion).

Compare {divbox} to {message box}

(note this material originally appeared in Wikipedia talk: Templates for deletion#Tag location (process); this text has been edited for clarity and pertinence)

(Korath commmented (1) that {message box} should be preferred to {divbox} and (2) that the several so-called subtemplates of {divbox} are useless in any other context.)

Actually, the subtemplates are not useless outside of {{divbox}}. I don't write junky code if I can help it. The {divstyleKEYWORD} templates are usable as is anywhere anyone wants a ready-made, color-coordinated, fully appreciated specification for colors, margins, and padding. Especially if {divbox} were somehow taken away, the subtemplates would become all the more useful to editors thus forced to "roll their own".

Template:Message_box sucks; with all respect to its creator, it was written by somebody with little experience writing code for naive users, and no experience in graphic design. It gives too much freedom to the user, demands the user master too much technical stuff, and makes the user work too hard to achieve a simple end. Too much hair is exposed, making it more likely for a naive user to break something. The documentation is impenetrable.

In contrast, {divbox} gives the user freedom, but not unlimited -- unless he substs it in and edits the code by hand, which is always available -- or he writes a new style subtemplate, which is also always available. It puts soft limits around the range of possible box styles. It's easy to use. And the only keywords the user must remember are simple mnemonics, like "blue" and "amber". If the naive user copies an instance of {divbox} from one place and uses it elsewhere, and foolishly changes the color style parameter without looking at the template documentation -- say, from "amber" to "green" -- he may not get the exact result he expects, but it will be pretty damn close, and nothing breaks. — Xiongtalk 05:15, 2005 Apr 7 (UTC)

Content/Fact box

I'd like boxes like this to use for content, is that a good idea? I think we should have the possibility. Someone added a red box to High Middle Ages; I saw that the code was ugly and I cleaned it up by using this template. Using this template for content is wrong, however, because of two reasons:

• This template as class "boilerplate metadata" which is not correct if used for factboxes
• It's not desireable for it to take the full width. (in my fix above, I wrapped it in a regulating div)

So, can I create a derivative of this for factboxes? Ideally, it would use the same styles so we don't have to duplicate those. I'll try some experiments, but I don't think I can solve this myself. Regards. — Sverdrup 13:19, 22 Jun 2005 (UTC)

Of course all the box style templates may be used in other tools or within hand-coded style tags. {divbox} itself generates full-width tag-type boxes; it's not really meant to go beyond that. I've used it for other purposes by substituting it and editing over the code, but of course what is wanted for other purposes is a more flexible tool.

An example might be the 2-column layout, as seen on the Main Page. Generally, this would not be appropriate onscreen -- columns make printed text easier to read, but onscreen it forces some users to scroll down and up. I think there are exceptions, though. (See Deckard#Clues and Questions.)

Sidebars are sometimes appropriate, too. I should very much like to see a consistent, standard sidebar format. It looks unprofessional to have every sidebar show up in a different width, with different margins, paddings, and color schemes. Worse, some inexperienced editors attempt to code using CSS without understanding how browsers work or what the best choice is between multiple options. In the worst cases, this results in text overflow or overlapping content for some readers.

A single tool to serve all functions may not be the best approach. If I see a little interest in any particular tool, I shall be happy to create it. — Xiong熊talk* 2005 June 30 09:58 (UTC)

Thank you for answering. (I've been away for a while, I'm sorry.) You are absolutely right that there is no fool-proof solution -- it is only uncommonly convenient to use infoboxes like this. I see now that someone has solved it in a nice way in the article I referenced - High Middle Ages. An infobox is inserted by <div class="infobox" style="width: auto;">. Very good, and easily put into a template. 01:25, 3 August 2005 (UTC)

Yes, that kind of article content infobox is standard. The style, as it stands now, is set in one or another style sheet for class="infobox". There are advantages and disadvantages to doing it this way -- notably, all such boxes look exactly alike, as seen by a given user. Of course users with other style sheets will see such boxes differently.

I'm leaning toward a next-generation box template with much more flexibility, but I'm still not sure what can be done usefully. Part of the problem is that the template mechanism is so very primitive; there is no conditional branch and unsupplied parameters often present themselves unbeautifully. One would like to be able to use the box with a minimum set of parameters and get acceptable and standard results -- for instance, failure to supply a colorkey should result in a single standard scheme -- or supply many parameters for greater customization.

I'll see what can be done. — Xiong熊talk* 03:02, 2005 August 12 (UTC)

Divstyleblue

Complaints were made (in another context) about eyestrain. I've edited the highly saturated cyan of {{divstyleblue}} to a more tolerable light blue. John Reid 06:10, 1 September 2006 (UTC)

-- and again. John Reid 10:18, 11 September 2006 (UTC)

New box?

I was thinking that my version might be more appropriate for the job. ~ Flameviper 17:20, 26 October 2006 (UTC)

Categorize this

We need a category for "box" templates, like this, {{message box}}, and so on. I'm specifically looking for a simple template to put a box around examples to set them off from the text. Like you could have a code example and then an example of what that code outputs, with a box around the output to separate it from the text. Like {{box|here is some text}} would result in:

Here is some text

— Omegatron 19:47, 13 December 2006 (UTC)

Unbreak it please...

Someone broke this template... And I don't see exactly where it happened in the history. Can someone fix it please? --Falcorian ^(talk) 22:15, 21 April 2008 (UTC)

My divbox keeps breaking, working, breaking, and now it's working. I reverted to the version from before today, now it seems to be working. Hopefully that's it. WLU (talk) 22:39, 21 April 2008 (UTC)

Something is happening outside the template itself, I'm getting the message "Template loop detected: Template:Divbox" on and off like you did, a developer might have to look into it.▪◦▪≡SiREX≡^Talk 00:54, 22 April 2008 (UTC)

The template may work fine now, but something funny is still going on. See Category:Wikipedia formatting templates, there are many articles and subcategories that don't belong there, all transcluding divbox. Maybe the category page was not properly refreshed. GregorB (talk) 13:41, 26 April 2008 (UTC)

The mentioned category is fine now... GregorB (talk) 22:37, 30 April 2008 (UTC)

I started my own investigation of this problem (see User:B.C.Schmerker/Templates/Divbox (debugging)), and it appears that the "If exist Parameter 2" code is broken, resulting in this Template's reported malfunction. Recommend double-check the following syntax:

{{#if:{{{2|}}}|id="{{{2}}}"|}}

— B. C. Schmerker (talk) 04:10, 9 July 2008 (UTC)

Avoiding decoration

See also: Wikipedia:Village pump (miscellaneous) § Decoration in WikiProject, User and Essay spaces

Hi. I've removed this addition pending some discussion. I'd like to know more about why decoration is to be avoided in other spaces and where consensus for that is documented. :) --Moonriddengirl ^(talk) 13:01, 5 September 2011 (UTC)

As I was saying in the TfD before it closed, that's how things have trended for years, and almost all uses of this template outside of explicit Christmas tree stuff like userspace or the less disciplined WikiProject pages is evidently not useful. If there are specific use cases where this template is still currently the best solution I'd prefer them to be listed so that alternatives can be suggested. The previous documentation didn't so much derive its suggested uses of the more gaudy options this template has from existing uses so much as pluck them from thin air. Chris Cunningham (user:thumperward) - talk 17:44, 5 September 2011 (UTC)

Is there any documentation that discourages the use of decoration in other spaces? If not, I'd really like to see consensus established for that before the status quo here is changed. Nobody else at that TfD seemed troubled by the usage of the template beyond article space, which I would agree should be discouraged. --Moonriddengirl ^(talk) 17:59, 5 September 2011 (UTC)

The people in the TfD were all supporting based on userspace use because that's where they all use it. The status quo is that the vast majority of uses of this template are in userspace, and most of the ones which aren't are unusual and trivially replaced by more standard markup. I'm disinclined to go looking for yet more straw polls when there seems to be such resistance to actually explaining why a generic decoration template like this needs use outside of userspace. Chris Cunningham (user:thumperward) - talk 19:30, 5 September 2011 (UTC)

Well, then, we seem to be at a bit of an impasse, because without any evidence of consensus to support the restriction, I disagree with the change. As I pointed out at the TfD, this template is used at a variety of spaces...apparently without controversy. I can't see any sign that anybody dislikes its usage there except you. There has never been any suggestion of restricting this from project space, and WP:STATUSQUO would seem to support continuing that until consensus emerges otherwise. --Moonriddengirl ^(talk) 20:12, 5 September 2011 (UTC)

Meh. I could sit here arguing the deeper philosophical consequences of choice, consensus and the process by which Wikipedia makes decisions, or I could just quietly do something about it by fixing the bad transclusions. Once that's done I'll hopefully have a better picture of precisely what you're using it for and should be able to either come up with an alternative workflow or adjust the documentation to suit what you're actually doing. So that's what I'll do. Chris Cunningham (user:thumperward) - talk 07:06, 6 September 2011 (UTC)

This isn't my template. I didn't make it, and I'm not the only one using it. Multiple people use this in multiple spaces. You keep saying that decoration does not belong outside of userspace, but you have yet to demonstrate that this is anybody's opinion but your own. You nominated the template for deletion, and it was kept. Nobody at that discussion supported the idea of removing the template from usage in any namespace except for article namespace. If there is consensus that supports that members of a Wikiproject should not use templates of this sort in constructing their own project space, that's one thing, but I do not understand (if not) why your preference would override that of the multiple people who have used this community sanctioned template. --Moonriddengirl ^(talk) 10:01, 6 September 2011 (UTC)

"Multiple people use this in multiple places" is not evidence: it's an anecdote. I'm not spending any more time engaging in whataboutery with no concrete examples. My own investigation suggests that the vast majority of non-userspace transclusions can be removed without anyone batting an eyelid, so I'm going to work on doing that. Chris Cunningham (user:thumperward) - talk 09:39, 7 September 2011 (UTC)

Not evidence? That this template is used and has been used in multiple places is documentable. Even if you change it, it will still be documentable, because your contribution list will show how it has been used. :/ What lacks evidence is the assertion that "that's how things have trended for years". I've asked you to verify that decoration should not be used outside of user page space more than once, but instead you just seem to become irritated. If there is consensus that WikiProjects are not permitted to decorate their spaces, this should be provable. I will continue to disagree with changing the documentation of this template until there is consensus to support that change. But as I do know where to go to find other opinions, I'll see if I can help establish consensus, even though that really should be your job. --Moonriddengirl ^(talk) 10:10, 7 September 2011 (UTC)

At Village Pump. --Moonriddengirl ^(talk) 10:20, 7 September 2011 (UTC)

"Documentable" is a stretch here: Fae's documented examples (as added here) were apparently invented on the spot, and Fae did not respond to a request as to why they were chosen. The only other examples given outside of userspace were your own, and from a look through the ones on templatespace I reckon they can all (and should all) be turned into mboxes (or removed). You're asking for consensus that we shouldn't randomly add embellishment to pages: that's common sense in my opinion, but I'll take that to the village pump. Chris Cunningham (user:thumperward) - talk 11:15, 7 September 2011 (UTC)

Whether you disagree with the usages or not does not change that it's documentable that it has been so used. :) It is your assumption that the embellishment is random. I don't agree that it is. Colored boxes, for example in edit notices, attract the eye, generally to point out that something is important. This is the case with template documentation as well and likely project space. Embellishments are common in these locations. We add icons, for instance, to user talk page warning templates. Block notices are colored text. Whether or not the embellishments are necessary and desirable is subjective. Discouraging their usage is a matter of community consensus. --Moonriddengirl ^(talk) 11:30, 7 September 2011 (UTC)

Moved from /doc

Paragraph breaks

Is there a way that this can be altered to allow multiple paragraphs of text in the body of the message text? So far I have yet to find any of the quote or div box type temples that allow multiple paragraph content in them without having to manually add multiple line breaks which is a very clumsy, and visually awkward work-around (the line spacing of a single line break is too little space, and two line-breaks is way too much space. Any solutions to this would be highly appreciated. Lestatdelc (talk) 23:42, 17 March 2012 (UTC)

Changes broke edit notices

This template is used in a number of edit notices, and recent changes destroyed that functionality. When I reverted back to version as of 11:15, 17 May 2012, it again worked. I've restored it until that issue can be worked around. --Moonriddengirl ^(talk) 20:20, 17 May 2012 (UTC)

I've recoded the 4 editnotice templates that were using it to use {{editnotice}} instead. So this change can probably be reimplemented if desired. — Martin (MSGJ · talk) 09:12, 18 May 2012 (UTC)

Thanks, MSGJ. You retained the color! I appreciate that and will be able to use that method in the future. --Moonriddengirl ^(talk) 10:12, 18 May 2012 (UTC)

Single-bracket links don't work?

I am confused. A divbox like this
{{divbox|gray||foo [http://example.com/a=b bar] baz}}

causes the entire content of the divbox to disappear but
{{divbox|gray||foo [[http://example.com/a=b bar]] baz}}

works fine. What's going on here? It seems like the equals sign (=) is confusing the template parameter code, but why? Is this fixable? Aren't links supposed to be given in single brackets? jhawkinson (talk) 08:48, 17 May 2013 (UTC)

@Jhawkinson: It's not the square brackets, but the equals. This is known behaviour for template parameters: if you try to assign a value containing an equals to a positional parameter, it's interpreted as a named parameter - in the first case above, the parameter name is foo [http://example.com/a and its value is b bar] baz. To defeat this, you need to explicitly number the parameter, as in

{{divbox|gray||3=foo [http://example.com/a=b bar] baz}}

Sorry for the late reply, but this page has only 26 watchers - and I only became a watcher a few minutes ago, see below. --Redrose64 (talk) 19:06, 22 May 2015 (UTC)

Use in article space?

Is there a way that we can use this template in actual articles? I'm looking for some way to create a dividing border between several family trees in a section, and I thought that this template worked pretty well for that [1]. Can someone point me to a similar border template for article space?--Brianann MacAmhlaidh (talk) 01:25, 3 September 2013 (UTC)

Never mind, I found what I was looking for at Help:Table.--Brianann MacAmhlaidh (talk) 19:31, 3 September 2013 (UTC)

Protected edit request on 22 May 2015

Change |id="{{{2}}}" to |title="{{{2}}}". An id has to be an unique element on any page, and that would be breached by having more than one box with the same title on a page. The documentation page is a prime example and produces invalid html:

https://validator.w3.org/check?uri=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTemplate%3ADivbox%2Fdoc&charset=%28detect+automatically%29&doctype=Inline&group=0

I assume the id attribute was added because ancient versions of IE used it to show a tooltip on hover. In 2015 there's no reason why the div should have an id attribute, although a title attribute might provide some of the functionality originally intended.

You might want to consider opening the template up for editing by template-editors. -- RexxS (talk) 18:32, 22 May 2015 (UTC)

I've made the suggested change to the protection level; no comment on the actual request. –xeno^talk 18:37, 22 May 2015 (UTC)

Done --Redrose64 (talk) 18:56, 22 May 2015 (UTC)

Categories missing from most divbox/style/color sections

I imported all of these to my wiki. I edited them by changing [[Category:Wikipedia formatting and function templates|{{PAGENAME}}]] to [[Category:Formatting and function templates|{{PAGENAME}}]]. I noticed that almost all of the templates are missing categorization. The fix is very simple. Just add the category within the doc content after the divbox display. If this should be done, I would be willing to do it.

Also, some of the styles uee border radius and others do not. Is this intentional? I would have expected the styles of all the boxes to be identical. I think an editor would expect that.

Finally, the grey template redirects to gray and differs from all the rest. It has no documentation at all.

• Should each template have a category
• Should the gray template be standardized to comply with the rest? Txantimedia (talk) 18:13, 11 November 2017 (UTC)

@Txantimedia: Please give examples of pages which are miscategorised. --Redrose64 🌹 (talk) 21:39, 11 November 2017 (UTC)

@Redrose64: They're not miscategorized. They're not categorized at all. In fact, only two are categorized {{Divbox}}, which is categorized as Category:Box templates but not Category:Wikipedia formatting and function templates and {{Divbox/style/gold}}, which is categorized as Category:Wikipedia formatting and function templates. The rest are uncategorized.

If you look at {{Divbox#Parameters}}, you'll see that {{Divbox/style/fawn}}, {{Divbox/style/ivory}} and {{Divbox/style/simar}} have rounded corners (use border-radius) while none of the others do, and {{Divbox/style/lilac}} and {{Divbox/style/wordperfect}} have no border at all. ({{Divbox/style/none}}, {{Divbox/style/greenv}} and {{Divbox/style/grayh}} also have no borders, but those make sense to me, because of their design.)

Finally, {{Divbox/style/gray}} presents itself completely different from the others. If you look at it, there is no doc, and even the <noinclude></noinclude> is displayed on the screen. I tried adding a doc section to it on my wiki, but it displays the raw wikitext as well.

Finally, {{Divbox/style/sia}}, {{Divbox/style/siaaa}}, {{Divbox/style/berk}}, {{Divbox/style/darkgreen}}, {{Divbox/style/gamessage}}, {{Divbox/style/gray99}}, {{Divbox/style/lightblue}}, {{Divbox/style/n}}, {{Divbox/style/nyanza}}, {{Divbox/style/thistle}}, {{Divbox/style/teal}} and {{Divbox/style/wdl}} are not even displayed in the {{Divbox#Parameters}} section.

All of this may be intentional. I don't know the history behind their creation. But, ISTM, that at least they should all be categorized, if not standardized, and the missing templates should be displayed in {{Divbox#Parameters}}.

To see what I think it ought to look like, go to my wiki. Txantimedia (talk) 18:02, 12 November 2017 (UTC) Txantimedia (talk) 18:30, 12 November 2017 (UTC)

@Jo-Jo Eumerus: why did you set the content model of {{Divbox/style/gray}} to CSS? Was this discussed anywhere? --Redrose64 🌹 (talk) 10:59, 13 November 2017 (UTC)

Because the template content is CSS. It was part of a batch change that you queried about back then and since there was no consensus to support it should probably be reverted if it makes problems - not one of my best admin actions here. Jo-Jo Eumerus (talk, contributions) 16:42, 13 November 2017 (UTC)

So, what's the verdict? Do nothing? Fix the templates? Let somebody else do it? Txantimedia (talk) 17:29, 19 November 2017 (UTC)

What more do you want? That was nearly six days ago. --Redrose64 🌹 (talk) 21:55, 19 November 2017 (UTC)

Template-protected edit request on 14 September 2018

@Redrose64: These edits replace current sub-template system with Template:Divbox/styles.css. I've made the edits in the sandbox. It passes the test cases and some of my own testing. Using Template:Divbox/styles.css is more organized and makes it easier to add a box as .css pages identify errors while editing. – BrandonXLF ^(t@lk) 01:24, 14 September 2018 (UTC)

 Not done (need more information - feel free to reactivate request when replying). @BrandonXLF: it is not clear what you want done, do you want the contents of Template:Divbox replaced with the contents of Template:Divbox/sandbox or something else? — xaosflux ^Talk 14:57, 15 September 2018 (UTC)

@Xaosflux: My bad, I want the contents of Template:Divbox to be replaced with Template:Divbox/sandbox. Template:Divbox/sandbox already uses Template:Divbox/styles.css so no editing needs to be done beside the copy and paste. – BrandonXLF ^(t@lk) 15:01, 15 September 2018 (UTC)

 Not done Why have the classes been removed from the <div>? Why hasn't all of the inline styling been moved to TemplateStyles? The classes being targeted by the TemplateStyles CSS are not unique, to prevent conflicts with other selectors. — JJMC89 (T·C) 20:17, 15 September 2018 (UTC)

All the issues above have been addressed. – BrandonXLF ^(t@lk) 02:13, 16 September 2018 (UTC)

You didn't answer my questions. Also, there is a missing </div>. — JJMC89 (T·C) 04:07, 16 September 2018 (UTC)

@JJMC89: I fixed the missing </div>, thanks. I didn't answer your questions because I addressed them by editing the sandbox and /styles.css. – BrandonXLF ^(t@lk) 15:06, 16 September 2018 (UTC)

Neither question was addressed by editing. The classes are still removed, and there is still inline styling. Also, why are there two <div>...</div> now? — JJMC89 (T·C) 19:58, 16 September 2018 (UTC)

@JJMC89: The classes were removed because they are not needed, and the inline stylizing is to centre the text. There's two div tags because only some of the text gets centred. Before it was calling other templates, increasing load time. – BrandonXLF ^(t@lk) 03:59, 17 September 2018 (UTC)

Why aren't the classes needed? Yes, but why is the styling inline and not in TemplateStyles? The change from {{border-radius}} to style="border-radius:{{{radius|}}}" does not result in the same style. I don't see a good reason to remove {{border-radius}} and {{center}}. — JJMC89 (T·C) 04:29, 17 September 2018 (UTC)

@JJMC89: I replaced then with the code that was being implemented to reduce load time. I've tested with many browser including Chrome, Firefox, Safari, Edge and IE and see no difference. – BrandonXLF ^(t@lk) 01:10, 20 September 2018 (UTC)

 Not done please establish consensus for the change by completing the discussion above, then feel free to reactivate the edit request. — xaosflux ^Talk 20:04, 20 September 2018 (UTC)

I've gotten no reply. The previous discussion seams to be done. — Preceding unsigned comment added by BrandonXLF (talk • contribs) 15:54, 23 September 2018 (UTC)

You still haven't explained why you removed the classes, which haven't been replaced by anything. Just because you don't see a difference in modern browsers in your chosen OS, doesn't mean it doesn't have an impact for others. — JJMC89 (T·C) 17:23, 23 September 2018 (UTC)

@JJMC89: I added the classes back and added {{border-radius}} back. Is there anything else? – BrandonXLF ^(t@lk) 20:08, 23 September 2018 (UTC)

 Not done: The previous discussion with JJMC89 seams to be ongoing. Cabayi (talk) 21:13, 23 September 2018 (UTC)

I've cleaned up the stylesheet to match the CSS coding conventions and implemented it. — JJMC89 (T·C) 05:19, 25 September 2018 (UTC)

 Done as JJMC89 implemented it. – BrandonXLF :^(t@lk) 20:20, 26 September 2018 (UTC)

Template-protected edit request on 12 October 2018

Replace

.divbox-gray {

with

.divbox-gray,
.divbox-grey {

To allow for the British and Canadian spelling for grey. – BrandonXLF ^(t@lk) 12:31, 12 October 2018 (UTC)

 Done Also done for the other classes that have gray. — JJMC89 (T·C) 16:05, 12 October 2018 (UTC)