Template talk:Football box collapsible

Colapsible Broke

Somehow recently the collaposible feature of this template is broken so all footballbox collapsible on Wikipedia are open and not able to be collapsied — Preceding unsigned comment added by Fulner (talk • contribs) 18:46, 20 May 2013 (UTC)

Cant get the "Hide/Show" working in Estonian wiki. Does anyone got idea what might be missing? --LeeMarx (talk) 22:50, 27 September 2014 (UTC)

Nevermind, its fine now!

Case-insensitive result parameter

I've recently seen an attempt to add a result parameter to this template which was ineffective as the 'w' was added in lowercase. Would it be possible to make the W/D/L/T result value case-insensitive? I think this would do it:

Change

#switch: {{{result}}}

to

#switch: {{uc:{{{result}}}}}

(messings about in a private sandbox appear to confirm this) but since the workings of templates scare me rigid I'd rather someone who knows what they're doing takes a look at the implications of doing it rather than me just going ahead and being bold! Tonywalton ^Talk 15:44, 18 July 2009 (UTC)

I went ahead and tried what you said and it seemed to work. Nothing was broken and it works with lower case letters now as well (I tried it on a an edit I previewed but didn't save). Thanks for the suggestion. It looks like it worked. --SkotyWA^Talk|_Contribs 23:16, 18 July 2009 (UTC)

One small step in my quest to {{find{{{out{{how templates}}}work}}!}}☺ Thanks. Tonywalton ^Talk 00:19, 19 July 2009 (UTC)

Putting the bars back

I've reverted the change that removed the bars above and below the box score because I believe it significantly degrades the overall readability of articles which use this template. For articles on specific team seasons which also make use of the W(green), L(red), and D(yellow) coloring (or make liberal use of the bg parameter) it is still bearable without the bars. However, for more "neutral" articles which cover a cup competition or a entire leagues season such as 2009 in Chinese football, 2009–10 Danish Cup, and DFB-Pokal 2009–10 (there are many more) it becomes overwhelming IMO to track from left to right and keep track of what row you're on. The goal of this template is to provide the full information on an as needed basis while compacting it to eliminate the need for massive amounts of scrolling in season and competition articles. Over 70 articles are already using/linking it now for these purposes. Changes like this that affect readability should be approached with caution as many editors are depending on this behaving (and looking) a certain way. If there is a specific need for removing these bars in a specific article perhaps a more appropriate solution would be to add a parameter which causes the bars to be hidden when set. However, I believe the default should be to keep the bars unless another idea can be proposed to address the readability problems I'm pointing out. --SkotyWA^Talk|_Contribs 03:52, 13 August 2009 (UTC)

Try using a horizontal bar (----) between each one. – PeeJay 10:42, 13 August 2009 (UTC)

Did you try that? It looks pretty sloppy. It puts a white band above and below the bar. Here's an example (I'm using "subst" so that it stays this way after I make the next change):

21 July 2009	Birmingham City	0 – 2	VfB Stuttgart	Zell am See, Austria
		Report	79' Élson 83' J. Schieber	Stadium: Zell am See Stadium Attendance: N/A Referee: Unknown

---

23 July 2009	FC Augsburg	2 – 0	Birmingham City	Westendorf, Austria
	23' T. Werner 74' E. da Costa	Report		Stadium: Westendorf Stadium Attendance: N/A Referee: Unknown

Since you seem determined to get the bars out (even though you won't share your reason), I'm hoping we can work this out. I'm going to parameterize the bars so that whatever article you're seeing these in that's bothering you, you can remove them. Just add the "nobars=1" parameter. For the reasons I've stated above, I don't believe these bars should be removed across the board (70+ articles). If you can share the reasons you believe otherwise (before reverting my parameterization contribution), that would be appreciated. --SkotyWA^Talk|_Contribs 02:19, 14 August 2009 (UTC)

To be honest, I think that the template looks better without the bars anyway, and that includes the horizontal bar I suggested. Anyway, I did try adding horizontal bars to the Shelbourne F.C. season 2007 article and it looked fine, but that was probably only because the boxes weren't coloured. – PeeJay 08:16, 14 August 2009 (UTC)

Collapsed height

Is there a way we can make the collapsed height shorter? As it is now when the football box is collapsed, there is a bit of empty space. I think that empty space should be gone. Digirami (talk) 07:45, 24 August 2009 (UTC)

I've seen that sometimes too. I think it depends on what browser you're using. I use IE and Chrome and it ends up looking fine in both (no extra blank line when collapsed). The problem I believe is that the last column (with the   and which also gets the [show]/[hide] stuff) is wrapping and the space is showing up on the next line. Unfortunately, I've tried removing the space to fix this wrapping, but it screws up where the [show]/[hide] is placed when I do that. I've also tried adjusting the widths of each column to address this, but haven't had much luck there. I've run out of ideas on this (and am not often reminded of the problem because it's not manifest in the browsers I use). If you have anything you'd like to try that might fix this, I'd encourage you to try it out, but be ready to revert quickly if it doesn't look right (this template appears in 70+ articles so mistakes here affect a lot of editors). Since IE is very likely (I don't have stats to back this up) the most commonly used browser by visitors to Wikipedia, please do double check that any changes you make work well in IE (as well as your own browser if different). --SkotyWA^Talk|_Contribs 08:18, 24 August 2009 (UTC)

I see. Well I use Safari, so maybe that's why. But... I may have an idea. I'm using this template in this article, and the added space is only an inconvenience when I have used the "location" parameter. But when I just use the "stadium" parameter, such as how it is used in the non-collapsible version of this, it looks just fine. So, maybe we could eliminate the "location" parameter and just use the "stadium" like in the regular footballbox version. Digirami (talk) 08:58, 24 August 2009 (UTC)

Correction. I just noticed something. It doesn't matter whether I use one or both parameters. If the stadium's name, with the city, takes up only one line, there is still a space. Digirami (talk) 09:01, 24 August 2009 (UTC)

The stadium and location parameters are not mutually exclusive. You can use both (and it will look better if you do). The value of the location parameter needs to be limited to the city, state, country info which should fit on one line and appear "above the fold". The stadium info will appear "below the fold" only if a location is also specified. If no location is specified, the stadium value will be shown "above the fold" much like the footballbox template. Does that make sense? --SkotyWA^Talk|_Contribs 06:24, 25 August 2009 (UTC)

Inappropriate uses

Resolved

 – It was determined that MOS:COLLAPSE was inaccurate. It has been updated. --SkotyWA^T_C 04:15, 5 February 2010 (UTC)

This template violates MOS:COLLAPSE, which leads me to believe that the majority of its current transclusions are inappropriate. I'm going to start going through them to check this; if so, this template may be taken to TfD. Chris Cunningham (not at work) - talk 11:01, 17 January 2010 (UTC)

I disagree that this violates MOS:COLLAPSE. In particular I think it is right in line with the spirit of this statement: Scrolling and collapsible sections in tables or other block elements can be useful to save space and conceal at first-sight potentially superfluous information. For most readers, the outcome of the match is the only interesting information from a box score. Only readers looking for extended detail will need to expand the box scores to get all of the information. In that sense, I think the collapsed information is indeed "potentially superfluous" and therefore is an excellent candidate to be collapsed. If your concern is what's said later in the MOS, specifically these methods should not be used in the article body, then the real question is whether or not you consider the sections these appear in to be part of the article body. I believe that the prose of the article constitute the article body, and the list of matches is more of a statistical summary than real "article body" content. That's my opinion though. Another thing I'll say is that my inspiration for creating this template was from similar work done in NHL articles such as this one. These types of article "optimizations" improve the overall navigatability (if such as word exists) which don't require readers to scroll through many complete box scores. Forcing all of the uses of this template to return to using {{footballbox}} would substantially bloat the articles that it's being transcluded in. --SkotyWA^T|_C 20:43, 17 January 2010 (UTC)

Another thing to consider is the {{fb cm2 match}} template used in Sunderland A.F.C. season 2007–08 which is currently rated as a WP:GA. That template also uses collapsible tables to manage the extensive amount of match data contained in the match results section. I think both templates ({{fb cm2 match}} and this template) are basically trying to mimic the data presented in other WP:GA season articles (such as Bradford City A.F.C. season 2007–08 or Manchester United F.C. season 1997–98) while including more details for the advanced readers in the collapsed areas. In the end, User:thumperward Chris Cunningham, please consider the fact that you're talking about 100+ articles that transclude this template. While I disagree that this violates MOS:COLLAPSE, I'm willing to concede that my opinion may be in the minority. May I suggest that rather than thretening to delete the template, why don't you try suggesting an alternative way to present the data that doesn't have the same problems you think this has. Simply cutting these articles' legs off and making the editors fend for themselves is not going to be a very productive way to go about this in terms of general editor happiness as well as driving consistency across articles. I'm not saying our goal here is to keep editors happy, I'm saying that taking a dipomatic approach rather than a slash and burn approach may be wise. In terms of article consistency, again consider that 100+ articles transclude this template. Just deleting this template without providing a legitimate alternative will leave editors wondering how to deal with this. --SkotyWA^T|_C 23:18, 17 January 2010 (UTC)

If it is taken to TfD, a reasonable solution must be proposed, for instance removing the collapse function (i.e. seamlessly merging it with {{footballbox}} (including the result parameter). A template used on this scale cannot be proposed for deletion without a solution in place, MOS violation or not. WFCforLife (talk) 23:48, 17 January 2010 (UTC)

A merge would be the obvious step. I'm not in the habit of proposing that templates in moderate use simply simply be wiped out without any contingency for existing transclusions, and would appreciate it if editors didn't use that rhetoric when replying to me in future. In particular, I'm of the opinion that any time an editor considers using the phrase "slash and burn" in an argument that said editor takes a coffee break away for the keyboard for an hour or so before hitting the submit button.

The "it's used on GA class articles" argument is weak because an article's GA assessment does not somehow override MoS guidelines which contradict its contents; this can happen for several reasons including the MoS changing after article assessment, the template being added after article assessment or simple failure to notice the problem in article assessment.

As for the body of the original reply, the issue is whether the material is superfluous or not. I consider material in infobox templates to be superfluous because ideally everything included in an infobox should also be included in the article body. This is not the case for match templates like this, where the full line is (so far as I can see) never duplicated in the article body outwith this template. As such, this material may be inaccessible to users who do not use graphical browsers. This is not an acceptable situation.

From what I can see, this template started as a fork of {{footballbox}} for the specific reason of providing that template's functionality in a collapsed state. I can't see that there is a compelling technical reason to have a split template rather than adding a collapse=yes argument to {{footballbox}} in any case; it would seem that a merge which allowed for such a function would be uncontroversial in any case. However, I still cannot see that the basic accessibility problem brought up in MOS:COLLAPSE has been adequately countered. Factual statistics of this type are IMO important details in an article, and while collapsing them seems to be a neat solution for sighted readers it can cause serious problems for those who cannot navigate articles by sight. I'll wait for further responses before considering future work. Chris Cunningham (not at work) - talk 01:03, 18 January 2010 (UTC)

I apologise if my reply was taken the wrong way. But with respect you did raise the possibility of a TfD without proposing a solution. I simply took that at face value. On the wider issue (conforming to WP:ACCESS), I agree with you.

This doesn't specifically relate to this template, but it would be handy if there was a setting to decide whether such a box were collapsible in the user preferences. As Skoty says, a significant percentage of people (in my opinion the majority, but I have no statistics) using a graphic browser would want this information to be presented in a collapsed form. Now, obviously those who do not have a choice in the matter have to take precidence, hence the current guideline. But I wonder if it would be possible to accomodate both, by introducing a user setting for it (default to expanded)? The Village Pump would be the obvious place to take this further, but it doesn't sound like a very complicated thing to implement. Does anyone have an idea if it's technically possible? If it is, I propose that the collapse function is disabled, but that this template is kept seperate from {{footballbox}}, on the basis that it's primary function could be reintroduced in the future without accessibility issues. WFCforLife (talk) 01:52, 18 January 2010 (UTC)

I don't think WP:GAs override the MOS, but I do think they can provide us with an alternative interpretation than the one you present. That said, I checked, and you're right, the specific WP:GA I pointed out was promoted before MOS:COLLAPSE was added. However, I did find further clarification in the MOS here which states: Scrolling lists and boxes that toggle text display between hide and show are acceptable in infoboxes and navigation boxes, but should never be used in the article prose or references, because of issues with readability, accessibility, and printing. This appears to be in line with what I was saying above about what constitutes the "article body". The match results sections of club season articles are not "article prose or references". Therefore, I think the collapsing of boxscores in these types of sections is appropriate given the wins they provide in decreased scrolling and providing more extensive information. Also, please consider the repurcussions that not having this feature would cause. Simply going back to using {{footballbox}} is not a viable option. In many cases having expanded boxscores will increase the scroll size of an article 4x. For me this is unacceptable. The articles become unweildy to scroll through. Editors would be faced with the choice of simply removing the data opting for a simpler option which only shows the final score (similar to what is shown now when collaped), or coming up with other more "creative" options such as this. --SkotyWA^T|_C 06:38, 18 January 2010 (UTC)

I did some more investigation and discovered the following facts using 2009 Seattle Sounders FC season as my test case which makes extensive use of this template:

• I installed the LYNX browser on my machine and browsed to the page. I discovered that the full, expanded content of the boxscores (not just the first line) is visible.
• I normally use Internet Explorer when browsing Wikipedia, so I tried to "Print Preview..." the page and discovered that it expands all of the boxscores.
• I also have the Google Chrome browser installed. It does not have a "Print Preview..." feature, but when I actually printed the page, I discovered that it too expands the boxscores in it's print output.

Lastly, in the archives of WT:ACCESS I discovered this comment which explains the behavior I observed above and seems to address most (if not all) of the accessibility concerns related to collapsible content. That in connection with the fact that this template is not used to collapse prose (just match details), seems to make it pretty obvious that this indeed is not a violation of MOS:COLLAPSE. --SkotyWA^T|_C 07:09, 18 January 2010 (UTC)

If you don't believe that MOS:COLLAPSE is valid any more (which is what you seem to suggest with your browser tests) then it should be removed from the MoS. For the time being, the question seems to be whether or not this data is "article prose". IMO such material certainly is article prose, as removing it negatively impacts the informational value of a given article. Secondly, when you consider that articles would become "bloated and unwieldy" if the templates are uncollapsed, what does that say to the readability of the articles right now for users who print articles, or have JavaScript disabled, or use non-graphical browsers? It probably says that too much material is being added to the article in the first place, and then collapsing has been added to the templates to paper over this for the specific case of people using graphical Web browsers to access the content. I would say that this is exactly what the situation is with 2009 Seattle Sounders FC season, where the article is being treated like an almanac. While the previous discussion regarding that article's fancruft problems having died down since Grant Alpaugh was indefinitely blocked, it's something which should definitely be re-addressed in future regardless.

Anyway, for now, can you provide a list of differences between this template and {{footballbox}}, so that I can see if the two can be re-merged (including the collapsing function for now)? It's obviously silly to duplicate effort maintaining two templates for this even in the short run. Chris Cunningham (not at work) - talk 10:04, 18 January 2010 (UTC)

I don't believe that the definition of "article prose" is based on whether "removing it negatively impacts the informational value of a given article." That's an overly broad definition which could be applied to literally anything. I don't include tabular data (tables) in my definition of prose, it doesn't seem to match Wikipedia's article on prose, and the DYK prose size script ignores this template (and other tables) when measuring prose size.

I also don't think that this is an issue of "fancruft" either. The use of collapsible data in tables isn't specific to the 2009 Seattle Sounders FC season article, this template, or even WP:FOOTY articles in general. I randomly chose a couple of the highest quality WP:NFL and WP:NBA season articles available, and both had some form of collapsible table for showing game information (2008 Pittsburgh Steelers season; 2006–07 Toronto Raptors season). I'd suggest making a proposal to change MOS:COLLAPSE itself to explicitly state that it should be applied to tables contained within prose as well (in the same way it explicitly states that it should be applied to image galleries). Then all the sports team season article could be changed. ← George ^talk 11:34, 18 January 2010 (UTC)

Re-reading my previous reply, I would like to clarify that the issue is not in fact whether these tables are "prose": the issue is whether they are in the article body, which is the part of the article that lies between its title and the navbox templates at the bottom. MOS:COLLAPSE does not use the phrase "article prose and references" which SkotyWA quoted (I believe this is an error in the summary at the "Scrolling lists" section quoted - which is not a "clarification"), which somehow threw me into seemingly agreeing with SkotyWA's characterisation of the point being made in the MoS. There is no need for a new qualifier to be added to said section, as "article body" is unambiguous. "All sports team season articles" which use such collapsing sections already need to be changed; they are fortunately not commonplace on WP:FOOTY-related articles. As I said previously, the existence of GA-class exceptions to the MoS does not mean that the MoS is no longer applicable; nor is it sensible for WP:FOOTY-related articles to make the same mistakes as in other sports domains on WP (I think it's generally accepted that WP:FOOTY is one of the highest-quality sports projects, and we should aim to keep it that way). Chris Cunningham (not at work) - talk 12:26, 18 January 2010 (UTC)

Yes, Skotywa probably took it from here: "Scrolling lists and boxes that toggle text display between hide and show are acceptable in infoboxes and navigation boxes, but should never be used in the article prose or references..." It's still not clear to me if this would include tables or not, but either way, both statements (the one Skotywa cited from the manual of style, and the one you cited from the accessibility guideline) should be clarified and made to match each other. Obviously GA-class exceptions don't trump the MoS, but (a) I'm still not sure if the MoS applies in the first place (to tables), and (b) if many (or even most) sports related season articles of meaningful length and quality use some form of collapsible box, this very well may be one of those cases where using common sense trumps the letter of the guidelines. Even if this template were never collapsed, I have no idea how a sight impaired visitor could possibly make sense of what was being read to them out of this table. ← George ^talk 12:41, 18 January 2010 (UTC)

SkotyWA's taken the initiative and pinged WT:ACCESS and other parties who might be able to provide clarification. On the issue of whether even in uncollapsed format this template is navigable by screen reader, that's something we can come back to once this particular point has been clarified. :) Chris Cunningham (not at work) - talk 09:11, 19 January 2010 (UTC)

Through discussion/consensus on WT:ACCESS it has been determined that there are no accessibility issues with collapsible content like this template. This has resulted in updates to both WP:ACCESS and WP:MOS. For more information, please review the discussion on WT:ACCESS. --SkotyWA^T_C 04:15, 5 February 2010 (UTC)

Backporting changes, merge

Right. With the above discussion settled in favour of allowing collapsing, it's time to merge this template's changes back to the original {{footballbox}}. Chris Cunningham (not at work) - talk 08:56, 3 March 2010 (UTC)

First, I'd like to see lesser used templates, such as {{EuropaLeagueFootballbox}} and {{TeamMatchbox}} (I know there are others), merged with a much lower risk of potential disruption to articles. After that, here is a rough list of features available in this template that are not available in {{footballbox}}: bars at the top and bottom of the box, location parameter, additional referee parameters, result parameter, and the round parameter appears in the top row of the table. Given the wide usage of this template, I expect that any merge would result in no change in formatting. --SkotyWA^T_C 06:26, 4 March 2010 (UTC)

As many as possible should be merged into one main match template in order to provide uniformity across all footy articles. I especially dislike {{Fb match2}} because it screws with the display of navboxes below it in the article. However, the main footballbox would have to account for all of the various parameters and parameter names in each of the templates that would be merged in. It could require some "heavy lifting" as far as template design goes. I'd be glad to help out. JohnnyPolo24 (talk) 16:54, 4 March 2010 (UTC)

I agree that a merge is the logical step, on the understanding that the features can be retained. WFCforLife (talk) 22:11, 4 March 2010 (UTC)

It occurs to me that a merge could be accomplished pretty easily by having {{footballbox}} redirect to this one like this:

{{footballbox_collapsible |class=uncollapsed |nobars=1 |team1={{{team1}}} |team2={{{team2}}} |score1={{{score1}}} ...}}

So you make it uncollapsed and hide the bars by default, and then just pass through all of the other paramters. That seems like it would be the simplest way to merge. --SkotyWA^T_C 06:01, 8 September 2010 (UTC)

And then moving what was footballbox collapsible to footballbox over the resulting redirect. I'm not familiar with footballbox's source code, but that sounds like a good solution. --WFC-- 13:26, 8 September 2010 (UTC)

I reviewed the code for the various boxes a few months ago, but I didn't come to any simple conclusions. That appears to be a good solution, though. What would we do with all of the differently formatted boxes like {{TeamMatchbox}}, {{Fb match2}}, and others? We should try to provide uniformity/continuity throughout all footy competition articles. Though maybe we should just take this one at a time. JohnnyPolo24 (talk) 14:40, 8 September 2010 (UTC)

Man of the Match

Can we include a Man of the Match parameter to this template? Xboxandhalo2 (talk) 06:50, 12 November 2010 (UTC)

A "Note" section

Greetings,

Is there a way we can add a "note" parameter at the bottom of the template that can be used to briefly explain any irregularities with the match such why a match was postponed or re-scheduled, incorrect times with a match report.. stuff like that...? Thanks. Digirami (talk) 23:59, 20 February 2011 (UTC)

Would you want this note to appear when it's collapsed or only when it's expanded. If it's the latter, that's easy and I'm happy to add it for you if you're not sure how. If you want it to appear when it's collapsed though, there really isn't much room left for it. --SkotyWA^T_C 01:41, 21 February 2011 (UTC)

I was thinking it would be displayed when it is expanded. I think I know how to add it, but I have my doubts on my abilities. Only other request would be to have the note automatically be in small italicized text. Digirami (talk) 02:34, 21 February 2011 (UTC)

Weird display

I was editing the 2010–11 Real Madrid C.F. season article and I noticed a weird display error. Look at game "G5" under the UEFA Champions League section. I think it has to do with the red cards, so it may just be something up with that template... but just to be sure I'm bringing it up here. Digirami (talk) 05:26, 22 February 2011 (UTC)

Viewing problems in Arabic pages

The round information are glued to the team1 name. The same thing with the stadium name which is very close to team2's name. Other than that, the date and round are flipped (The round should appear before the date but that's not what is happening in Arabic pages). I can't link to an example because the page must be in Arabic, but you could search for " نادي النصر السعودي لكرة القدم موسم 2011-12 ". — Preceding unsigned comment added by MarwanMR1 (talk • contribs) 00:30, 12 September 2011 (UTC)

This template doesn't support right-to-left reading order currently. If you would like to contribute support for it, please do so. I don't know how to conditionalize the alignment based on the reading order. Sorry. --SkotyWA^T_C 02:49, 12 September 2011 (UTC)

Thank you for your answer. I will try my best to make it work. Best of luck. --MarwanMR1 (talk • contribs) 04:48, 12 September 2011 (UTC)

Display issue?

Has someone made any changes to the template during the last days? The template is "thicker" if you know what I mean? The box doesn't collapse as much as it did a couple of days ago? Is this this an error or is it a permanent change to the the template? The previous smaller version looked a lot better. --Reckless182 (talk) 22:45, 25 November 2011 (UTC)

You can hide the bottom bar of the template by using |stack=yes. This should be done if more than one box is being used in a stacked manner. --SkotyWA^T_C 00:26, 22 January 2012 (UTC)

Widths

Is there some reason that fixed percentage widths were used - it often results in wrapping of text with significant white space between columns (specifically the round/date column wrapping, and the team column having white space before the name). --Trödel 15:06, 26 March 2012 (UTC)

Proposal: remove background colours

The background colours are, I would suggest, entirely unnecessary (any reader can identify the larger number in a scoreline), the cause of argument (should matches resolved in penalty shoot-outs be indicated as draws), unrelated to any norm in the reporting of the sport, uninformative (especially when, as happens in the majority of cases, the key is omitted) and, from an aesthetic POV, ugly. I propose the removal of the result field. Kevin McE (talk) 16:56, 7 August 2012 (UTC)

Support - no need for the colours, as they do give a quick overview if you scroll past quickly, but you usually find the win-draw-loss records on the page too, and for normal acquiring of information, I for one, look at the scoreline and probably who scored the goals anyway. - Svefnpurka (talk) 18:01, 7 August 2012 (UTC)

Weak oppose. I find colours to be a small net positive, as the quickest way to skim through results to find the match you're looking for is with the assistance of colour. I accept that colours will in some cases be redundant, and that there are aesthetic gains which could and should be made – the entire template being a certain colour is excessive – but to justify removing the parameter entirely you would have to demonstrate that the prescence of colour at all is a net negative. —WFC— 18:30, 7 August 2012 (UTC)

Oppose - I don't see any negative sides of it. I find it helpful when scorlling through a season article.--Reckless182 (talk) 19:03, 7 August 2012 (UTC)

Support - agree with the nominator, colours are superfluous. As an aside to Reckless' comment, personally I don't think this template should be used in season articles, a simple table would suffice. NapHit (talk) 20:53, 7 August 2012 (UTC)

Oppose - Useful in season articles (nothing else), and as long as it's used in season articles we should keep the parameter. Forcing every season to use tables per NapHit is a different discussion. Mentoz86 (talk) 21:04, 7 August 2012 (UTC)

Support – Completely pointless, looking at the score is a far more sensible way of seeing which team won. The colours aren't needed. BigDom 21:38, 7 August 2012 (UTC)

Weak support If a season article has a 'round by round' table with colours, I guess it would be wasteful to have colours on the match by match results too. Wikilinks on the club names is a tad wasteful too, something touched upon in this GA review. Especially if that club's name has been mentioned in the main body. Lemonade51 (talk) 22:11, 7 August 2012 (UTC)

I'll just clarify what I meant by using tables instead of this template in season articles. Personally I would like to see tables such as the one used in this article rather than this template. As Mentoz states that is for another discussion, thought I'd clarify what I meant. NapHit (talk) 17:52, 8 August 2012 (UTC)

While I guess table vs template is a matter of personal taste, it's relevant to this discussion to point out that the table you are recommending also makes use of colour. The table's use of colour is more elegant, no question, but it still uses it. —WFC— 17:58, 8 August 2012 (UTC)

To be fair those tables leave out the goalscorers for the other team, yellow and red cards, the venue and the referee. All information I find very helpful. Especially to see all goal scorers and not having to look at the pages of both teams to find out all the info. - Svefnpurka (talk) 19:22, 8 August 2012 (UTC)

When colour is used to indicate something (in this case whether a team has won or lost) a symbol must also be used. So using this table in its current guise in season articles is going against WP:ACCESS. The table I linked does not as it uses W,D,L as the symbols, so the use of colour is justified, that is the main reason i prefer the table. NapHit (talk) 21:53, 8 August 2012 (UTC)

It doesn't have to be a symbol, it just has to have the same information conveyed via some other method as well. In this case, the win/draw/loss is also conveyed via the score. --Bobblehead ^(rants) 22:15, 8 August 2012 (UTC)

Bobblehead is right – a symbol is only necessary where it isn't possible for a colourblind reader to get the information. —WFC— 23:46, 8 August 2012 (UTC)

Oppose The main reason for this is because I find the scores themselves to be less important than the results and I find identifying the result for a specific game much easier to do via color than having to process the scores. However, I do understand that some may find the use of color across the entire row to be jarring, so perhaps a compromise could be developed that would allow the use of colors, but not across the entire row? --Bobblehead ^(rants) 21:05, 8 August 2012 (UTC)

Oppose The results coloring provides quick, at a glance, info on the result of a game and, in season articles especially, the sequence of wins and losses over a period of time. I would even argue that the results-by-round table is almost unnecessary in a season article where results coloring is used. --SkotyWA^T_C 04:49, 21 August 2013 (UTC)

Oppose per previous comments. Colours are useful to find a result, give a quick overview and impression of form, save a second or two identifying whether the team in question was home or away and registering the score, and I disagree that they're aesthetically unattractive anyway. No harm in duplicating information from the "Results by round" section (which may not always be present). Dave.Dunford (talk) 11:43, 10 November 2013 (UTC)

"Notes" section?

Hello! Could someone please add a "notes" section to the footballbox, where brief significant extra info can be added if necessary? e.g. "match abandoned in 83rd min" etc? Thanks! BigSteve (talk) 10:38, 12 August 2012 (UTC)

Referee Flags

I was wondering if flags are allowed as a way to mark referee nationality. Thanks! 50.153.150.184 (talk) 04:41, 14 December 2014 (UTC)

This is regard to the referee parameter. The docs currently state

The referee's national federation in parenthesis is optional but recommended when the box score is for an international competition.

The first part of the question is, should a flag be present for the referee rather than a link to the federation? The second part of the question is, should nationality be signified for league-only seasons or tournaments?

The question is in relation to adding the national flag for MLS matches. Walter Görlitz (talk) 00:30, 26 December 2014 (UTC)

Proposal: prefer single-line height (while collapsed)

Earlier discussion

The documentation for this template specifically states: "The goal with this template is to only consume one line of text (when collapsed) for each match". Unfortunately, it takes up the height of two rows if the browser screen is not wide enough. As a result, long lists of collapsed matches are twice as long as they need to be. I found a fix for this, but it seems my fix for it gets reverted, so let's see whether I can get support for this change here :) Here's the explanation: in the very last column, there is a   which is something like a placeholder for the [show] / [hide] links. But unless your screen is very large, that character is wrapped to the second line, resulting in a two-row height, even when all of the columns needed only a single row-height. Before: Belgium v Australia Friendly 4 September Belgium 2–0 Australia Liège, Belgium   20:45 UTC+2 Mertens 18' Witsel 78' Report Stadium: Stade 'Test' Maurice-Dufrasne Attendance: 16,850 Referee: Michael 'Test' Oliver (England) The reason for this is that the .collapseButton has float:right, pushing the   (coming after it) to the next line. The most ideal solution would be to turn off that css rule in this particular case, but since we can't access the css rules, turning off the wrapping is the only way to fix it. It was never meant to wrap since it's only 1 show/hide button. So that's why I added the white-space:nowrap css to the table cell that holds the hide/show buttons. This ensures that the row will never take up more than 1 row (unless the content in the other columns is too long, of course). After: (edit 27 August: this now includes various other improvements as well) Belgium v Australia 4 September Friendly Belgium 2–0 Australia Liège, Belgium 20:45 UTC+2 Mertens 18' Witsel 78' Report Stadium: Stade 'Test' Maurice-Dufrasne Attendance: 16,850 Referee: Michael 'Test' Oliver (England) I don't understand how this would look worse than the original; it's the intended behaviour of the template, is it not? I.e. taking up only a single line. Please explain if that is not correct, and if so, whether the documentation should be updated to reflect that. Sygmoral (talk) 21:27, 10 May 2015 (UTC) Any comments on this? If not, I'll just apply this change again, since the template documentation clearly states it is meant to be like that. Sygmoral (talk) 17:28, 20 August 2015 (UTC) I just fixed it in a different way: the core issue was that the [Show] link does not fit in a 4% column on window sizes below 1560 pixels wide. So I made that column a little bigger, fixing another issue at the same time: that of contents shifting around when you click Show/Hide. Also see this discussion on WP:FOOTY. Sygmoral (talk) 17:48, 20 August 2015 (UTC) People keep reverting my fix for the height issue, I am getting annoyed about that. My latest fix, which tweaks the column sizes, does not make the entire box higher, thinner, wider, or anything like that! All it does is create enough room for the [Show] link on a larger range of browser's window sizes. On screens wider than 1560 pixels, it already looked exactly like that - I only made it more consistent for less wide screens. On less wide screens, that last column wrapped a space onto the next line, causing an entire extra empty row. The documentation says The goal with this template is to only consume one line of text (when collapsed), so that was undesired. If this template is no longer meant to produce a single-line row, that would be a change. I do realise that long "round"-parameters can cause the date to wrap to the second line, but that is also how it is currently designed in the code. Nevertheless, please do provide links to any articles that are believed to be adversely affected by this fix, I will be happy to check them out to see if a more elegant fix can be applied for them. It's my profession, after all :) Sygmoral (talk) 12:12, 24 August 2015 (UTC) Basically readers are used to seeing a "bigger" boxes with extra row and now with a single line there is a completely new look when the boxes are stacked and I dont like it (perhaps it takes a while since it is a new look). Qed237 (talk) 12:20, 24 August 2015 (UTC) I understand that. What if I add an extra parameter to force that double-height, would that help? Something like |height=2, which would then force all lines to indeed take up 2 rows (I already figured out a way to implement that). It could be useful for pages where the round-parameter causes some lines to take up two rows, while others take up only one line -- which indeed looks messy. In general however, for long lists (that don't have huge round-parameters), it is very handy if it takes up only one line as it makes the overview cleaner then. Sygmoral (talk) 12:35, 24 August 2015 (UTC) Example: Belgium national football team results – 2010s Sygmoral (talk) 12:37, 24 August 2015 (UTC) That could be one solution, but not sure it would be good to have it. What I realised looking at the Belgium example is that piping could reduce the double row issue. Why is "UEFA" not shown making it "Euro 2012 Q" and not "UEFA Euro 2012 Q" (to wide), while "FIFA" is shown in "2014 FIFA World Cup Q" where "2014 World Cup Q" or even "Word Cup Q" or "2014 WC Q" might be enough. Qed237 (talk) 13:01, 24 August 2015 (UTC) Very true, and I also believe that is the best solution! Simply keeping the round-parameter short enough so that it does not cause the date to wrap underneath it. Indeed, the page I linked could use some work on that too. Sygmoral (talk) 13:28, 24 August 2015 (UTC) In fact, another thing I've noticed is that it is a bit inconsistent that the date has such a large font compared to the round-information... it would wrap a little bit less quickly if the date had an equally small font. But anyway, that's another discussion. Sygmoral (talk) 13:28, 24 August 2015 (UTC) The only time anything appear on the second line is penalty-shoot-out result. There is no other usefulness for the second line. For league results where there is no pso, the extra line is not needed. Harvardton (talk) 02:49, 27 August 2015 (UTC) Motivated by your comments (Qed237 and Harvardton), I have gone ahead and added several other minor improvements (in my sandbox). To be concrete, I vertically aligned the round and stadium text with the rest of the text (since they used to always be aligned 'a little higher'); included the "show/hide" button in the same table cell as the stadium/location (instead of in a separate cell which took up invisible space; this will allow referee names etc to run all the way to the right border); gave the cell where the Round parameter goes a tiny bit more space (by making the score-cell a tiny bit smaller), and fixed several other things in the code (redundant code and a few actual coding errors). Of course all of these changes are barely noticeable, but you can check the end result in my original post above: the second one uses the sandbox version.

Do I have your blessing to publish these improvements and defend them against reverts from people that aren't used to the single-line look? Feel free to suggest any more tweaks before I'd publish. —Sygmoral (talk) 13:20, 27 August 2015 (UTC)

Yes, as far as I am concerned. Based on your analysis, this change is really a code fix. Quite frankly, I don't see why a 20 round league should be displayed with 20 lines of blank lines between them. Harvardton (talk) 03:04, 28 August 2015 (UTC)

I have deployed the changes. To anyone concerned: voice your concerns! Sygmoral (talk) 17:43, 29 August 2015 (UTC)

My only concern is it looks weird now when stacked with games that have gone to pens (which show across two rows). I don't have a particular preference as to two or one row really, but I think consistency is important otherwise it places undue attention (and weight) on matches that went to pens. Paul  Bradbury 16:01, 30 August 2015 (UTC)

I can't figure out an elegant solution to that; it doesn't look very nice when the penalty score is placed on the right of the match score. On the other hand, (aet) already does appear to the right of it... perhaps we should do it anyway? Makes it look like this:

Brazil v Venezuela

21 June 2015 Copa América	Brazil	2–1	Venezuela	Santiago, Chile
18:30 (UTC-3)	Thiago Silva 9' Firmino 52'	Report	Miku 85'	Stadium: Estadio Monumental David Arellano Referee: Enrique Cáceres (Paraguay)

Brazil v Paraguay

27 June 2015 Copa América	Brazil	1–1 (3–4 p)	Paraguay	Concepción, Chile
18:30 (UTC−3)	Robinho 14'	Report	González 72' (pen.)	Stadium: Estadio Municipal de Concepción Referee: Andrés Cunha (Uruguay)

(the penalty details do not appear when opening because the |penaltyscore parameter is not present, but that can be changed) —Sygmoral (talk) 18:09, 31 August 2015 (UTC)

@Sygmoral (talk) Yes! What you have done there with the pens looks good. Infact, everything you have done has been great. I really hated the double line effect that was going on before. Keep up the great work! —Eccy89 (talk) 14:23, 9 September 2015 (UTC)

Thank you for your kind words! I'll implement this some time soon, then :) —Sygmoral (talk) 14:55, 9 September 2015 (UTC)

I'm actually in doubt now about this change, because most collapsible boxes with penalties also have "aet" set. Can't really put both aet and the penalties result next to the main score. But that leads to the question: can a football match ever go to penalties if it doesn't first go to extra time? If not, we could just hide the (aet) for matches that were decided by a penalty shootout, since the aet part is implicit. We might need to discuss this on the WP:FOOTY talk page since it seems like a big change, though. —Sygmoral (talk) 16:03, 10 September 2015 (UTC)

@Sygmoral: I think that works for me, however as you pointed out how does this look with aet? There are matches that are decided on pens without aet, such as those in this years pre-season tournament the international champions cup. Not sure on the best answer. Paul  Bradbury 08:51, 11 September 2015 (UTC)

Bold Team Names

The current template bolds the team names regardless of the winner of the match; however, many tournament pages unbold the loser of the match so that the winner's name stands out on a glance without having to process the score. See 2014–15 FA Cup and 2015 Lamar Hunt U.S. Open Cup for examples. Could we add a parameter to the Result that instead of coloring the row (since the box is used on a page that is not specific to a team - so coloring the winner doesn't make sense, that automatically unbolds the loser of the match. Parameters could be Result=WinTeam1 or WinTeam2. For a draw no change would be needed since both team's names would remain bold. Thoughts? --Trödel 13:34, 17 August 2015 (UTC)

Don't see a need for that. Kante4 (talk) 22:34, 29 August 2015 (UTC)

It makes sense to me and would help with those who are vision impaired and can't distinguish between the background colours. Paul  Bradbury 16:03, 30 August 2015 (UTC)

Looks like there are more people that would like this, so let's figure out how this could best be done.

• Option 1: expand the parameter "result". This is a more complicated parameter than you'd think, but I checked that its current workings would not be disrupted if we added the following options: team1, team2 and none. They respectively bold only team 1, only team 2, or neither of them.
• Option 2: Add a parameter "winner", taking those same values. If the parameter is not present, it still defaults to making both team names bold.

The only difference between the two is that Option 2 allows setting BOTH a background and overriding the bold behaviour. However, that may be pointless (why would you want both?), and then Option 1 would make more sense.

What say you? —Sygmoral (talk) 21:12, 2 September 2015 (UTC) (edited for clarity: 17:23, 5 September 2015 (UTC))

Why wouldn't you want both??? :-P Actually, I manually debolded the losers with the coloured background setting. It looked slightly off. TBH it doesn't really matter for me which option is chosen, just whatever is easiest for the person making the changes. I'd be leaning towards option 1. —Eccy89 (talk) 14:14, 9 September 2015 (UTC)

I don't like either proposal. My personal preference would be the for bold code to be removed from the template and manually embolden the winners on the article pages where necessary. TheBigJagielka (talk) 15:44, 10 September 2015 (UTC)

For an entirely new specification, I could agree. But the problem is that a vast majority of people are now used to seeing team names in a bold font, so it would disrupt the experience of lots of people if tons of articles suddenly default to non-bold team names.

Note also that the bold default makes it consistent with the regular football box template (as used on this page for example), where it makes sense to bold both team names in order to make them stand out from the goal makers. It's the most important important information of that box after all: both team names, and the score. If we change that default, I feel like it should also be changed on the normal football box template, which should probably need to be discussed on the WP:FOOTY talk page. —Sygmoral (talk) 15:58, 10 September 2015 (UTC)

Wrap {{penalties1}} with #if

The current template always shows the penalty list if the match was decided on penalties, but when the penalty shootout details are not entered into the template it just displays {{penalties1}}. (Same for {{penalties2}}, of course.) See 2015–16 Copa del Rey any of the first or second round matches decided by penalties as examples. AF4JM (talk) 15:32, 10 September 2015 (UTC)

You're right! I just fixed it now. —Sygmoral (talk) 15:49, 10 September 2015 (UTC)

Needed: a parameter for text color when the background color makes the default foreground color illegible

Selection of a team color for the background (bg) color can make the default font color (fg) illegible. As of 2016-10-06, this is the case with the use of this template in the 2016 season section of Cascadia Cup (please see the sections where the Timbers won). Is there a way we can change this template to specify the font color? Peaceray (talk) 17:00, 6 October 2016 (UTC)

Hmm... to be honest, I question whether those custom backgrounds for competitions should even be supported. In the past year, custom colors were removed from the Squad tables because it makes an article look more like a fan page than an encyclopaedic article. I see that only two minor competitions have these background colors supported on this template. I personally believe we should take this to WP:FOOTY's talk page to decide whether we actually want custom backgrounds. Perhaps it would make more sense to indicate the winner by whether its name is bold or not, for example (which is not currently supported though). –Sygmoral (talk) 18:10, 6 October 2016 (UTC)

I would welcome anything that would enforce legibility. I have worked with software development in the past, & one of the principles we strived for was to prevent users from making a choice that was a mistake. Picking a background category that makes text illegible is clearly a mistake. Perhaps we could limit the options for background color to a few that would not obscure the text. Peaceray (talk) 18:55, 6 October 2016 (UTC)

Not enough space for Round

There isn't enough space for the first column "Round" on this template. On common desktop widths, anything much longer than "Friendly" next to a longer month name is getting pushed to a second line. I'm seeing this on Firefox, Chrome and IE. There is plenty of room between "Date" and "Team1". Can someone move the Date column a bit to the right and increase the size of the "Round" column? Example from Australia national soccer team#Results and fixtures. - Mnnlaxer | talk | stalk 03:05, 22 October 2017 (UTC)

Thailand v Australia

15 November 2016 World Cup Qualifier	Thailand	2–2	Australia	Bangkok, Thailand
19:00 UTC+7	Teerasil 20', 57' (pen.)	Report Report (FIFA) Report (AFC)	Jedinak 9' (pen.), 65' (pen.)	Stadium: Rajamangala Stadium Attendance: 36,534 Referee: Fahad Al-Marri (Qatar)

Video Assistant Referees

Is there any possibilitiesthat someone whith access to edit this template to add VAR and Assistant VAR as possible features? It seems that this proves to be a success in the current World Cup, and thus might be applied in other major tournaments in the future.Ormstunge (talk) 06:07, 29 June 2018 (UTC)

Gentle reminder. Ottomanor (talk) 11:37, 23 August 2023 (UTC)

Would certainly be nice to add a VAR referee section. Seems like VAR referees are playing a bigger role in the result of the game, and it would be nice to have that section! DatunEast (talk) 03:05, 29 March 2024 (UTC)

Template-protected edit request on 14 October 2018

The |report= parameter currently generates a hidden inline external link. It should format this as a reference so that it appears as a citation in the reflist. This can be achieved by changing

{{#ifeq:{{str_sub|{{{report}}}|0|4}}|http |[{{{report}}} Report] |{{{report|}}}}}

to

{{#ifeq:{{str_sub|{{{report}}}|0|4}}|http |{{#tag:ref|[{{{report}}} Report]}} |{{#tag:ref|{{{report|}}}}}}}

This I tested in the sandbox and testcases. — Frayæ (Talk/Spjall) 23:24, 14 October 2018 (UTC)

I would say a discussion should be opened at WP:FOOTY first, given this is a highly visible template and that reports have been formatted as links since the template's creation in 2009. S.A. Julio (talk) 23:40, 14 October 2018 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Per SA Julio's concerns. A discussion here, publicised at WT:FOOTY would do just as well. Cabayi (talk) 08:40, 15 October 2018 (UTC)

"note" issue

Calls to the "note" parameter are invariably returning the string Template:Br separate entries. Can someone with the appropriate privileges please investigate? It was functioning correctly at approximately 18:00 UTC 16October2018 but was producing the above error by 05:30 UTC 17October2018. Same symptom produced in Opera browser on Windows 7 and Chrome browser on Android mobile device. Thanks in advance.  EclecticArkie  (talk) 04:54, 17 October 2018 (UTC)

fixed. Frietjes (talk) 17:16, 17 October 2018 (UTC)

@Frietjes: Also, it seems the template no longer has a bottom border, could this be fixed? S.A. Julio (talk) 18:04, 17 October 2018 (UTC)

S.A. Julio, typo, should be fixed. Frietjes (talk) 18:08, 17 October 2018 (UTC)

@Frietjes: Also, there is a small difference with the alignment of the city and show/hide button, it no longer seems vertically centered, unlike the date and teams, is this possible to fix? Thanks, S.A. Julio (talk) 17:35, 30 October 2018 (UTC)

S.A. Julio, the entire top row has vertical-align:top. this is true for both the old (non-lua) and new (lua) versions of the template. we could make it vertical-align:middle, but this would be a change from the old version. unless I am missing something. if you have an example which really shows the issue, please put it in the testcases. Frietjes (talk) 21:09, 30 October 2018 (UTC)

@Frietjes: Hmm, strange. In two browsers I've used, the alignment looks slightly different in the old version as compared to the present version. S.A. Julio (talk) 04:34, 31 October 2018 (UTC)

Expand font size bigger with no location details

Team 1 v Team 2

1 May 2019	Team 1	v	Team 2	Anytown
19:45				Stadium: Recreation Park

Unknown team v Team 4

3 May 2019	Unknown team	v	Team 4
19:45

As you can see from the above example, where a location or stadium parameter is not used, the expand text is larger. Looks like something in the CSS is setting the expand text in the first match to font-size: 85%. Should be fixed so are the same size. Boothy m (talk) 12:17, 12 April 2019 (UTC)

Boothy m, this should be fixed now. Frietjes (talk) 22:22, 11 November 2019 (UTC)

Looks like it's fixed in the example above, thanks Boothy m (talk) 23:59, 11 November 2019 (UTC)

@Frietjes, looks like the bug is back on? LaUr3nTiU (talk) 20:30, 7 August 2024 (UTC)

Boothy m, should be fixed now. Frietjes (talk) 13:53, 8 August 2024 (UTC)

Result data pages

@Frietjes and Vanisaac: Is it really necessary to have this template rely on a lot "Module:Football box collapsible/result/XXX" data pages, all of which are only used on one article and possibly Template:Football box collapsible/testcases as opposed to passing that information as parameters from the relevant articles? * Pppery * _{it has begun...} 20:09, 11 November 2019 (UTC)

Pppery, we could probably do something about the ones that are infrequently used. if I recall, you can manually set the coloring using |bg=, which isn't any more verbose. the particular structure was directly imported from the corresponding templates which _should_ all be orphaned at this point (outside of uses in the old version kept in sandbox). Frietjes (talk) 21:19, 11 November 2019 (UTC)

yes, looks like this works, is less verbose, and helps ensure consistency in coloring with the legend, so a win-win-win. Frietjes (talk) 21:34, 11 November 2019 (UTC)

@Frietjes: As far as I can tell, at this point all of these are now used only on the testcases page. This thus suggests that the code should be cleaned up by removing the code for result subpages entirely and deleting all of the unused subpages. * Pppery * _{it has begun...} 22:09, 11 November 2019 (UTC)

Pppery, yes, I already orphaned the non-default subpages, and already merged the default into the main code. I would like to wait until the pages have recached before deleting the subpages (i.e., once one of the sub-modules has zero transclusions we can delete it). Frietjes (talk) 22:13, 11 November 2019 (UTC)

Pppery, yes, I know, see this thread. Frietjes (talk) 22:37, 11 November 2019 (UTC)

Pppery, you can probably have "Module:Football box collapsible teamname" deleted, only used in a fork of this template/module as far as I can tell. Frietjes (talk) 22:42, 11 November 2019 (UTC)

@Frietjes: Module:Football box collapsible teamname is still used on two pages. * Pppery * _{it has begun...} 23:49, 11 November 2019 (UTC)

Pppery, now added directly below the only template that is using it. Frietjes (talk) 14:48, 12 November 2019 (UTC)

Pppery, nomination was reverted. maybe you will have better luck. Frietjes (talk) 15:21, 12 November 2019 (UTC)

Template-protected edit request on 7 May 2020

Please deploy these changes to Module:Football box collapsible, so that it makes use of the core classnames, instead of the old local wikipedia classnames. —TheDJ (talk • contribs) 09:34, 7 May 2020 (UTC)

 Done * Pppery * _{it has begun...} 13:39, 7 May 2020 (UTC)

League position parameter

Hi. After recent discussion on the WikiProject talk page about cataloguing the league position of club(s) after match days; would it be desirable and possible to add additional parameters to this template so that league positions can be captured and displayed, ideally in the collapsed view either adjacent to the round number or the right hand margin? --Ratchet8865 (talk) 15:31, 29 August 2020 (UTC)

Text slightly offset if no location

Lebanon v Akhaa Ahli Aley

12 July 2000 Non-FIFA friendly

Lebanon

7–0

Akhaa Ahli Aley

Beirut, Lebanon

Lebanon v VTJ Topoľčany

20 July 2000 Non-FIFA friendly

Lebanon

0–0

VTJ Topoľčany

In the case that the location parameter is left blank, the text (second example) is slightly offset to the left. Is this fixable? Nehme₁₄₉₉ (talk) 23:58, 27 September 2020 (UTC)

@Frietjes and Pppery. Nehme₁₄₉₉ (talk) 00:50, 25 October 2020 (UTC)

@WOSlinker, Frietjes, and Pppery Can anyone help out? Nehme₁₄₉₉ (talk) 16:51, 15 February 2021 (UTC)

Line 320 of Module:Football_box_collapsible sets a width values in css if location is not blank. While setting it would fix the issue, I'm not sure how it would affect all the existing uses. -- WOSlinker (talk) 17:06, 15 February 2021 (UTC)

I don't see an offset, but I have updated the logic. I am not sure why there is a difference for some browsers since the width of all the other cells are set with percentages, so the last should just by 100 minus the sum of the others. maybe the better solution would be to never set the width of the last cell? Frietjes (talk) 16:25, 16 February 2021 (UTC)

Ok perfect, I don't see it offset anymore this way. Nehme₁₄₉₉ (talk) 17:11, 16 February 2021 (UTC)

Misnested tag error when bold used inside of team1= parameter

I would fix this myself, but I am unable to parse the Lua code. When |team1= contains bold markup, as in this version of 2020–21 Coupe de France (|team1=ASU Grand Santi '''or''' [[US Sinnamary]] {{flagicon|French Guiana|local}}), the result is a misnesting of bold markup and span tags, like this:

<td class="vcard attendee" style="width:23%;text-align:right">'''<span class="fn org">ASU Grand Santi '''or''' [[US Sinnamary]] <span class="flagicon">[[File:Flag of French Guiana.svg|23x15px|border |alt=French Guiana|link=French Guiana]]</span></span>'''</td>

One fix would be to swap the bold and span markup at the beginning and at the end of the encoding, like this:

<td class="vcard attendee" style="width:23%;text-align:right"><span class="fn org">''' ASU Grand Santi '''or''' [[US Sinnamary]] <span class="flagicon">[[File:Flag of French Guiana.svg|23x15px|border |alt=French Guiana|link=French Guiana]]</span> '''</span></td>

Simplified new code:

<span class="fn org">''' [parameter value] '''</span>

To avoid unintended problems from moving the bold markup inside the span tags, I have added a space after the initial bolding and before the final bolding. This should avoid problems if someone has used italic or bold markup inside the |team1= parameter.

Is there someone here who can modify the Lua code to implement this change? – Jonesey95 (talk) 19:56, 29 November 2020 (UTC)

I've moved the bold and added the spaces in the sandbox version. -- WOSlinker (talk) 22:52, 29 November 2020 (UTC)

Super, thanks WOSlinker! I have copied that code into the live module, and it appears to work fine. Please post here if this change causes any problems in articles that were working fine before. – Jonesey95 (talk) 00:06, 30 November 2020 (UTC)

Replacing the templates with tables

This is a thorny and recurring issue that has recently been raised about a party that advocates replacing this vastly used template in sports articles with simple tables because that is consistent with a style guide created back in 2007. Is this required now that the encyclopedia is full with this template? Is the template really inconsistent with the accessibility guide as demanded by the advocates of the tables? And if that was the case, why did we reach this stage?--Sakiv (talk) 14:17, 11 March 2021 (UTC)

Please link to the original discussion. The tables in that linked page do not comply with MOS:ACCESS, so I don't see the point in replacing this template with such a table. If this template does not comply with MOS:ACCESS, we should be able to make it accessible. – Jonesey95 (talk) 14:31, 11 March 2021 (UTC)

We have discussed at length at Talk:Argentina national football team results (2020–present) because it was this article that started the controversy.--Sakiv (talk) 14:38, 11 March 2021 (UTC)

It appears that the objecting editors are unaware that this template uses table formatting code and that |class=collapsible is available to show all results boxes in full by default. I think adding that parameter and value to each template would satisfy their concerns about accessibility. – Jonesey95 (talk) 15:21, 11 March 2021 (UTC)

@Jonesey95, @Stevie fae Scotland stated on the Argentina results talk page that "it was to do with how screen readers are able to read a table vs a football box template and how the pre-collapsed nature of the football box template acts as a barrier to information as it hides most of it". Nehme₁₄₉₉ 02:30, 23 March 2021 (UTC)

Adding |class=collapsible should resolve the concern about content being hidden. – Jonesey95 (talk) 05:49, 23 March 2021 (UTC)

Thanks for your help Jonesey95 regarding MOS:ACCESS. Any further information that can be provided re screen readers would be helpful, as I've said before I don't use one so I don't know the exact problems and it was a few years ago now that someone pointed it out to me.

Regardless of the accessibility concerns, the use of the football box template in last articles does not conform with MOS:LIST and this has been established and agreed numerous times including in discussions here, here and here as well as this featured list nomination. I feel that starting a discussion here is just another attempt circumvent consensus that has already been established. When used appropriately, the football box template is an asset to Wikipedia but list articles are not an appropriate use of it. Stevie fae Scotland (talk) 14:18, 23 March 2021 (UTC)

I don't understand the reason for all this resistance to using a template that is so often found in football articles. The claim that the national team results are nothing but lists is not correct and cannot be compared to the lists of countries by population or area etc. in which the tables must be used. As has been said, you should start an extended discussion to seek the opinion of the community instead of continuing this difficult discussion here or on the Argentina article.--Sakiv (talk) 18:56, 23 March 2021 (UTC)

At the risk of being uncivil here but can you not understand that a list of results is a list? I don't need to do anything here, I've pointed out four discussions that have views from a range of contributors including one that I had no involvement in whatsoever and all of them came to the same conclusion - football box templates are not suitable for list articles. End of story. I'm really frustrated and fed up with this, to be honest, because no matter what I say, no matter what everyone else says, you just aren't going to listen. It's utterly pointless so don't expect me to read any more comments that you add because the discussion was over long ago and you just can't accept it. Stevie fae Scotland (talk) 20:48, 23 March 2021 (UTC)

Uncivil??!! You have not right to consider the discussion concluded. I did not ask you to respond to me, but you are the one who wants to waste our time on things that are considered trivial. I raised the issue on third opinion, and the participant said loudly that it is not possible to deal with the issue by dividing it and making it as if it pertains to one article as you want. The problem is bigger and deeper than that. Do not accuse me of being uncivil because it may be considered harassment and personal attack on your part as you have done this repeatedly. MOS:LIST itself says: The titles of stand-alone lists typically begin with the type of list it is (List of, Index of, etc.), followed by the article's subject, e.g., List of vegetable oils.--Sakiv (talk) 21:13, 23 March 2021 (UTC)

Scotland national football team results (1872–1914) is a Featured List. Nehme₁₄₉₉ 21:47, 23 March 2021 (UTC)

It looks like this replacement is continuing. Was there a consensus discussion for this sort of mass replacement? Pinging B1GLAX2, who may be able to point to such a discussion. – Jonesey95 (talk) 13:59, 4 August 2021 (UTC)

@Jonesey95 Frankly, I was unaware that there was a debate. I replaced the template list with the table for that page based on what I had seen over at Heritage Cup (MLS), which uses a similar table to delineate results. The original template list on Portland Timbers–Seattle Sounders rivalry was broken into many different categories and often had missing information on attendance and goal scorers. I thought the new table would better condense the length of the page while retaining information in a more visually appealing way, along with better separating the different eras of the rivalry. I'm not sure if there was a consensus discussion or not but I think the template is more useful when there is a shorter list of results (like for an individual season or tournament) and a table is better for longer lists (like a rivalry page or a list of historical results for a national team). Happy to hear any feedback about this! B1GLAX2 (talk) 05:37, 6 August 2021 (UTC)

A good number of other rivalry pages like List of El Clásico matches and Basque derby utilize tables for longer match lists as well, instead of the templates. B1GLAX2 (talk) 05:56, 6 August 2021 (UTC)

Preview warning and hatnotes moving to templatestyles

Page watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles Izno (talk) 00:22, 29 April 2021 (UTC)

Use of white text in unlinked Team1 / Team2 parameters on Wiki app

In the last week or so there has been a change in the behaviour of this template when viewed on the Android app. Is it possible to revert any recent changes that may have led to this or debug the current code to restore the previous performance?
When team1 or team2 parameters have been defined with plain unlinked text (i.e. no [[ ]]) then the resulting text is currently appearing in white when viewing pages on the Wiki android app. This means that the text is invisible when listing future fixtures with an empty result parameter. On many pages relating to specific teams it is current practice not to link multiple references to that team say in a list of a season of fixtures. Until recently where plain text was used it would appear in the default colour (usually black). It seems to have only recently changed to appearing in white. This does not seem to apply when pages are viewed on web browsers. Thanks --Ratchet8865 (talk) 09:51, 17 June 2021 (UTC)

report parameter edge case

Please see this discussion at Template talk:Football box. If a solution is implemented there, it should probably be replicated here. – Jonesey95 (talk) 19:28, 18 September 2021 (UTC)

Alternative colours for Won/Lost On Penalties

With several competitions (off the top of my head, EFL Trophy, FA WSL Cup and MLS Next Pro as a minimum) now favouring the idea of settling drawn league/group stage games with a penalty shootout, and the winner of the shootout going home with two points rather than one or three, is it perhaps time to consider a unique colour scheme for games won or lost on penalties? Perhaps a lighter shade of green/red, or a single mid-range colour with a darker shade for the winner and a lighter shade for the loser? Falastur2 ^Talk 22:21, 1 April 2022 (UTC)

@Falastur2: Just letting you know that your suggestion has been implemented with a "SW" or "PW" in the result field to color the background light blue. SounderBruce 23:17, 6 September 2023 (UTC)

Box editing broken

Tried to update results, but clicking apply changes completely breaks it. Unable to click "Confirm edit" or "Discard edit". Deleting the box and replacing it doesn't solve the issue. Never encountered the issue before, and I don't think it's client side as I'm able to edit other boxes on the season's page. POTH94 (talk) 17:41, 23 July 2022 (UTC)

I've also encountered a similar problem. Seems to be a wiki-wide issue. Nehme₁₄₉₉ 18:11, 23 July 2022 (UTC)

Still getting this issue, don't know why it hasn't been fixed yet. Fixtures need updated and added, so this should be a high priority fix. I'm not sure whether it's cos I've not got a match report included, but I've never encountered this issue when editing without a match report. Please PLEASE get this fixed asap. POTH94 (talk) 00:13, 27 July 2022 (UTC)

Template-protected edit request on 5 September 2023

Add the following at line 29:

	["SW"] = "PW", ["PW"] = "BBF3FF"
	["V"] = "P", ["P"] = "BBBBBB"

This would add a blue background for matches won through a penalty shootout to decide a draw in regular season matches, such as those in MLS Next Pro (and historically, MLS and NASL). SounderBruce 05:35, 5 September 2023 (UTC)

@SounderBruce: Could you please provide an example of a page where this would do something? I also note that the second line is already present in the module. * Pppery * _{it has begun...} 14:47, 6 September 2023 (UTC)

@Pppery: I've just changed 1996 New England Revolution season to use the proposed colors; previously, the article had marked shootout wins as simply wins, which isn't accurate due to the different points awarded for the two results. The second line is just there as a reference point and would simply overwrite. SounderBruce 20:00, 6 September 2023 (UTC)

Thank you.  Done * Pppery * _{it has begun...} 20:02, 6 September 2023 (UTC)

Retrofitting WP:ACCESS compliance into the template

Would it not be possible to simply add a place for the result to be displayed in the collapsed template? Without bringing up the old discussion over the tables versus this template, I'd prefer to see that accessibility compliance be brought here without having to overhaul the 24,000 pages that use the collapsible football box. This was spurred by a comment at this ongoing FAC that I would prefer to continue using the detailed boxes instead of a generic table that strips away key information. SounderBruce 01:30, 22 January 2024 (UTC)

After poking around in the sandbox module a bit, I have added a way to display the result parameter next to the date; ideally it'd be spaced out a bit more to the right in its own "column" but it still fixes one of the accessibility issues. See the testcases for an example. SounderBruce 21:31, 25 January 2024 (UTC)

Template-protected edit request on 28 June 2024

On the Android APP, if either team1 or team2 is NOT a Wikipedia-link, the team name appears as white font on white background - when not using dark mode. On a Desktop/Laptop browser, this is not the case as the font is black, on white background. LaUr3nTiU (talk) 14:51, 28 June 2024 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. There is no actionable code change requested here. Please link to an affected article so that we can troubleshoot this problem report. – Jonesey95 (talk) 16:33, 29 June 2024 (UTC)

Please inspect 2024–25 ASC Oțelul Galați season#Friendlies on the Android mobile app. You will notice that the name Oțelul Galați does not show up in the unplayed matches (2 and 3), but it does show up as white in the 1st one. I assume this happens because that font is white on the Android App, but black on a Desktop/Laptop browser. LaUr3nTiU (talk) 10:30, 30 June 2024 (UTC)

Jdlrobson, can you replicate this? I have no access to Android. I think it may be related to the styles.css subpage. – Jonesey95 (talk) 16:56, 1 July 2024 (UTC)

The page was updated in the meantime, and now matches 1 and 2 are with White font on Green background, while the 3rd match is with White font (presumably?) on white background. Please note that the 2024–25 ASC Oțelul Galați season#Matches were added and there are currently 30 of these that show. I am not running my Android on dark-mode, if that helps replicate this. LaUr3nTiU (talk) 17:13, 1 July 2024 (UTC)

I reached out to the apps team and they confirmed this is a bug on their side. They are going to open a bug and when they've done that I will add it here! Thanks for the report! 🐸 Jdlrobson (talk) 02:16, 5 July 2024 (UTC)

Tracked in Phabricator
Task T369438

🐸 Jdlrobson (talk) 03:24, 8 July 2024 (UTC)

Hi @Jdlrobson. Do you have any updates on this? Thanks! LaUr3nTiU (talk) 20:27, 7 August 2024 (UTC)

Nevermind. I just saw the Phabricator task. LaUr3nTiU (talk) 20:32, 7 August 2024 (UTC)