Template talk:Chart top

Width and center
From my talk page:


 * is obsolete; with 100% it is redundant. --  Gadget850talk 16:16, 4 April 2015 (UTC)

As it is:

width=100%

width=100% with

User:Gadget850 please could you explain further -- PBS (talk) 16:40, 4 April 2015 (UTC)


 * is obsolete in HTML5. Proper centering of tables is described at HELP:TABLECENTER.
 * But, if 100%, then centering the table has no visible effect. A full width table has no margins.
 * But, the temple is already centered since it uses the  class.
 * Thus is not needed.


 * I added align to the sandbox, but since the table is already centered, it is only needed if you want to float left or right, so it may not be needed. (I did not immediately realize that  would center the table)

--  Gadget850talk 17:57, 4 April 2015 (UTC)

Ah I see the misunderstanding the is not being added to centre the outer table (as you point out it is centred -- I now understand you first comment which had baffled me up to now), it is being added to centre the the content inside the table. I have renamed the three examples I created before, see the difference between Chart 2 and Chart 3 and where the chart boxes appear. It can be added by using align=center |- |align="center"|

|- |align="center"|

The reason I have not done this are several:
 * 1) because this is template is a deliberate copy by me of
 * 2) because there are lots of example of  with
 * 3) because to change the default behaviour of   could affect 7154 transclusions
 * 4) because for most editors  is easier to understand than:

-- PBS (talk) 19:41, 4 April 2015 (UTC)


 * The  attribute is also obsolete. The proper markup would be  . Again if 100% then center is redundant. --  Gadget850talk 19:54, 4 April 2015 (UTC)


 * You use  when modifying the script in the sandbox, and I took the   from Help:template. I do not understand why you keep stating "if 100% then center is redundant." when one can clearly see that there is a difference in appearance between Chart 2 and Chart 3 when they are opened. -- PBS (talk) 08:42, 5 April 2015 (UTC)
 * OK. Center is being applied to the inner element. chart/start supports centering with margin: 1em auto;. No updates are needed. --  Gadget850talk 09:39, 5 April 2015 (UTC)

It would be better to alter the code to do the same thing automagically, as I can not think of an example where one would not want the "inner element" to be centred. The example I gave (Chart 4) does that, and it is easy to add that code to the template. You say that  in that example is obsolete, so what would you suggest in its place? -- PBS (talk) 11:05, 5 April 2015 (UTC)


 * Again, you want the chart centered in, so use


 * Having centered by default seems reasonable. I will do a sandbox. --  Gadget850talk 15:09, 5 April 2015 (UTC)


 * Template talk:Chart. --  Gadget850talk 16:12, 5 April 2015 (UTC)

New code copied from template:Ahnentafel top
See Template_talk:Ahnentafel_top. The previous code did not display when in "Mobile view" because it's built on navbox, one of whose classes has display:none on mobile. I have copied the code from template:Ahnentafel top the only difference is that I have changed "Ancestors of" to "Family of". -- PBS (talk) 17:46, 1 January 2018 (UTC)

auto-collapse
From the edit history user:SMcCandlish wrote:
 * This cannot auto-collapse by default, per MOS:DONTHIDE. It should never be auto-collapsed on purpose in mainspace with this parameter, either, for the same reason. Collapsing stuff is potentially less objectionable in other namespaces. See also MOS:ACCESS for usability and accessibility issues. And use Template:Yesno-no, to interpret values like "Y", "false", etc. Also permit "collapse" not just "collapsed".

The don't hide argument has been around for many years and has been agreed as the best solution for things like the appendix sections. Ie everyone should have unimpeded access to the references section.

However I do not think that you should have changed this template without discussing it first. The reason for collapse by default is that many editors do not think that ancestry charts belong in Wikipedia articles. Collapsing them by default was agreed as a compromise. By expanding them unilaterally you are taking sides in a dispute that has rumbled on for years. I understand the reason for you doing it, but it can be argued that forcing both sighted and sighted challenge readers to have to wade through this trivia to get to more pertinent facts lower down the page is not in the interests of anyone. -- PBS (talk) 14:46, 31 March 2021 (UTC)
 * This is a backwards argument. If "many editors do not think that ancestry charts belong in Wikipedia articles", then we should have an RfC about deprecating the practice and removing them from articles; we should not cause accessibility problems for entire classes of users as some kind of half-assed "meta-hint" to readers that editors are having an internal squabble. That's like kicking your dog because you're mad at your neighbor.  A handful of editors in a particular topic area squabbling amongst each other for years cannot, for "their" topic, magically undo a site-wide accessibility guideline.  This kind of crap is why WP:CONLEVEL policy exists and why ArbCom has reinforced in case after case that wikiprojects and other little knots of editors cannot make up their own pseudo-rules that conflict with the site-wide ones.  If you think MOS:DONTHIDE is wrong, you're welcome to take up a proposal to change it at WT:MOSACCESS or WT:MOS.  Finally, absolutely no one needs prior permission from you or anyone else to bring a template into compliance with policies and guidelines; there would have to be a massive and site-wide showing that consensus had changed on that matter and that the guideline or policy was to be rewritten, to prevent that. And even then it would be post hoc; by default, ever template that is not complying with extant policies and guidelines should be corrected to comply with them, unless and until the applicable P&G changed.  — SMcCandlish ☏ ¢ 😼  15:06, 31 March 2021 (UTC)

Template-protected edit request on 13 April 2023
Please prevent rendering of extra line spacing above / below transclusions (cf., e.g., at Al-Hafiz). Hildeoc (talk) 22:32, 13 April 2023 (UTC)


 * @PrimeHunter (in case you're interested): Any ideas? Hildeoc (talk) 22:18, 14 April 2023 (UTC)


 * looked at your link [here] and see no white space below the template, and it seems the white space above the template can be erased just by erasing the blank line in the code above the template. Like this:

The Hafizi branch, inextricably bound to the Fatimid regime, survived in Egypt until the fall of the Fatimid Caliphate in 1171, but it disappeared quickly after, unlike its two rivals, which survive to the present day. The last holdout of Hafizi Isma'ilism was Yemen, where significant communities survived into the 13th century.


 * When that blank line is removed, it looks like the following:

The Hafizi branch, inextricably bound to the Fatimid regime, survived in Egypt until the fall of the Fatimid Caliphate in 1171, but it disappeared quickly after, unlike its two rivals, which survive to the present day. The last holdout of Hafizi Isma'ilism was Yemen, where significant communities survived into the 13th century.


 * or are you describing something completely different from this?  P.I. Ellsworth &thinsp;, ed.  put'er there 00:48, 15 April 2023 (UTC)
 * A blank line before a table shouldn't give as much whitespace as it does at Al-Hafiz. The problem is that if the first thing a transclusion returns is table start code  then MediaWiki sometimes inserts a newline before , probably to ensure it ends up at the start of a line as required by the syntax. If there was already a blank line before the transclusion then you can get two blank lines and that gives extra whitespace. I don't know the precise circumstances where MediaWiki adds a newline. Maybe it happens here because the table start is transcluded through two templates, first from Chart top to Nizari-Hafizi-Tayyibi schism and then to the article. Maybe that means MediaWiki doesn't discover it's already after a blank line and doesn't need an inserted newline. If the call of Nizari-Hafizi-Tayyibi schism is replaced with the entire source text of Nizari-Hafizi-Tayyibi schism then it doesn't happen. That is not a suggested solution, merely an observation. The simple solution in specific cases is to just avoid blank lines before such calls. I don't know a good general solution. PrimeHunter (talk) 01:32, 15 April 2023 (UTC)
 * Pretty cool! and you're right – must have something to do with transcluding through the second template. Disabling this edit request because the solution is to simply remove the blank line between the text and the template as shown above.  P.I. Ellsworth &thinsp;, ed.  put'er there 01:51, 15 April 2023 (UTC)
 * Thanks a lot for your interest and efforts! However, I would like to point out that this is not a real solution for the actual reason of the formatting issue in question but rather merely a "quick and dirty" workaround. No offence though. Warm regards, --Hildeoc (talk) 21:28, 15 April 2023 (UTC)
 * None taken, editor . When one of the best template editors on WP doesn't know a good general solution, then the "quick and dirty" kind is all we can muster. There are only a handful of articles that use the Nizari-Hafizi-Tayyibi schism template, and the ones that needed fixing have been done (some already had been fixed). Feel free to open a bug report if you think it's needed, but the devs seem to be working their butts off against a large backlog. Best to you!  P.I. Ellsworth &thinsp;, ed.  put'er there 21:48, 15 April 2023 (UTC)
 * Just did a search on Phab. – – and this has come up before in one form or another. Seems to be a pretty gnarly challenge.  P.I. Ellsworth &thinsp;,  ed.  put'er there 22:00, 15 April 2023 (UTC)
 * Edit template-protected is about getting somebody with rights to make the edit. When there is no clear way to achieve the goal and the problem is not critical, it seems suitable to not leave the edit request open. You could try Requested templates if you want others to look for a good general solution but I'm not sure it exists. Some table-generating templates avoid the issue by using HTML per Help:Table. But Chart top only makes part of a table and interacts with other templates in a way that would be problematic here. It doesn't work to just start a table with  and continue with wikicode syntax. PrimeHunter (talk) 22:56, 15 April 2023 (UTC)
 * I see. In this case, I certainly won't make a fuss here. So thank you both very much indeed, once again, for taking the time and trouble to look into this. Have a nice Sunday! Hildeoc (talk) 23:04, 15 April 2023 (UTC)