Editing explain xkcd talk:Editor FAQ

Feel free to enter any question about editing this Wiki and don't forget to sign you comment. --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 21:18, 31 May 2018 (UTC)

== Formatting of explanations ==

Many pages contain tables where a definition list would be 1) easier to read 2) mobile friendly, for example: [https://www.explainxkcd.com/wiki/index.php?title=1957:_2018_CVE_List&oldid=160469 1957]. 

I was also involved in rewriting the transcript for [[1963]], where the discussion came up about how those should be styled. ("as if you were reading the comic to someone")

I think we should have a small style guide to encourage sane formatting. What else should such guidelines contain? 

Edit: One more thing I'd love to see: semantic headlines (i.e. < h3> headlines for explanation subchapters instead of < h2> which is the same level as the explanation itself)

<small>(Sidenote: I've been active on explainxkcd for quite some time, but only now got around making an account.)</small> [[User:Gir|//gir.st/]] ([[User talk:Gir|talk]]) 15:01, 19 August 2018 (UTC)

:Thanks for your remarks. First: There is no need to start every new sentence at a new line. Tables are meant for small content in all other cases it's bad layout. I recently changed this [[2034: Equations]] to a proper floating text. At the transcript tables should never be used, even when there is a table in the comic image it should be described by text. The guide here was mainly written by me because there was nothing like this here before. Some people already helped and I'm happy for any further remarks to enhance it. And this table issue is definitely one; I just not wanted to be the only (arrogant) layout master. Your help is welcome to write something, otherwise I will do so soon.
:For headlines we don't use HTML-code but WIKI-code. The main headlines are written like this: <nowiki>==Explanation==</nowiki>, <nowiki>==Transcript==</nowiki>, and (optional) <nowiki>==Trivia==</nowiki>. Headlines inside that chapters should be done in this way: <nowiki>;Subtitle</nowiki>. The preceding semicolon causes the entire line to be rendered in bold. Only when the explanation really needs sub-chapters it can be done by this: <nowiki>===Sub header===</nowiki> (three equal signs before and after the text). I will put this also into the FAQ.
:Welcome and thanks for helping. PROTIP: Always use the preview button to check the layout before saving. --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 13:39, 20 August 2018 (UTC)
::hi, I'm aware about the headlines and stuff, it was just shorter to write it this way in the comment. I see you started a bit with a styleguide already; I hope I can contribute to it next week, when things cool down at work a bit. //gir.st/, who is to lazy to log in [[Special:Contributions/172.68.51.190|172.68.51.190]] 06:51, 24 August 2018 (UTC)

So, one more thing, regarding 'What is the proper layout for headers?'. I think we should better use small <code><nowiki>====headings====</nowiki></code> instead of just description titles (<code><nowiki>;bold text</nowiki></code>), since it makes the intent clearer. what is your reasoning behind suggesting it the other way round? greetings, [[User:Gir|//gir.st/]] ([[User talk:Gir|talk]]) 14:49, 25 August 2018 (UTC)
:Thanks for your input and of course Wiki markup headers should be valid. I just believe that the simplest way should also be valid for less experienced writers. When a new explanation starts it's often awful and chaotic; giving a simple but effective structure at the beginning helps against this chaos. So, I'm thinking about dividing the section "What is the proper layout for headers?" (it's a question because it's a FAQ) into two subsections:
:*easy: a semicolon, the colon at the following paragraph may be mentioned - but I'm not sure about the colon because it should be ''easy''
:*advanced: <code><nowiki>===headings===</nowiki></code> if the comic really can be divided into chapters; <code><nowiki>====headings====</nowiki></code> as a replacement for the semicolon; and <code><nowiki>==headings==</nowiki></code> is forbidden because it belongs to expl, trnsc, trivia. The semicolon, colon issue should be mentioned here.
:Please consider that there was many chaos in the past and many writers will do their edits without reading this FAQ. So keeping this simple as possible seems to me to be inevitable. And dividing sections by using the semicolon for a header is still much better than many of those tables. --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 17:41, 25 August 2018 (UTC)
::Based on this discussion I edited the current comic here: [http://www.explainxkcd.com/wiki/index.php?title=2037%3A_Supreme_Court_Bracket&type=revision&diff=161880&oldid=161841] and compare it to this former version [http://www.explainxkcd.com/wiki/index.php?title=2037:_Supreme_Court_Bracket&diff=prev&oldid=161841]. Do not focus on the edits, just scroll down to the resulting page.
::This brought me to another important issue: NO links in a header. At Wikipedia this is also not welcome. This site isn't Wikipedia but in this case I feel this is a good rule. But the TOC (Table of content) is shown in the preview while it's not at the resulting page. The result is preferred but the TOC in the preview may confuse editors here.
::So, I'm still looking for simple instructions, layouts which advanced people always can enhance.
::And consider that some editors are probably younger than xkcd is. Not sure about this but there are definitely young people here and I welcome them all. And I'm NOT getting old like Randall sometimes feel, I like to support every editor despite any other background. And this has to be simple on the first place. STOP(I could talk much more) --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 20:49, 25 August 2018 (UTC)
:::Sorry, I missed this. I'd personally go with the "advanced" option, but mentioning both is fine too. Nice work on 2037! Really enjoying our conversations about this, I hope i'm not a bother ;-) [[User:Gir|//gir.st/]] ([[User talk:Gir|talk]]) 11:20, 28 August 2018 (UTC)
OK, after a few days and some more edits (for example see here: [[2035: Dark Matter Candidates]]) I believe this would be the best guide:
*<code><nowiki>====headings====</nowiki></code> should be preferred because the advantage is that each header has it's own edit button. One other advantage is that the header text will be shown at the summary in the history.
*The semicolon may be used as a preliminary layout for new comics until it's clear of what content the explanation is composed of.
*On more rare circumstances the <code><nowiki>===headings===</nowiki></code> may divide the explanation into different larger chapters.
*<code><nowiki>==headings==</nowiki></code> is reserved to the general layout and has not to be used.
And I still oppose to the colon at the beginning of any paragraph at all. Any thoughts? --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 13:17, 29 August 2018 (UTC)

== Please '''''do not''''' use semicolon-lines as "headings" ==

Hi, sorry to butt in, but I was going to mention this here anyway after I saw it in the FAQ. Please ''don't'' continue to give this advice to editors:
<blockquote>For headlines you have to use Wiki-style code. The simplest way is a preceding semicolon at the beginning of the line which causes the entire line to be rendered in bold.<ref>§ [[explain xkcd:Editor FAQ#What_is_the_proper_layout_for_headers.3F|What is the proper layout for headers?]] of the [[explain xkcd:Editor FAQ|Editor FAQ]]</ref>

====References====
<references/>
</blockquote>

The [[explain xkcd:Editor FAQ#In_which_case_tables_are_meaningful_and_when_not.3F|previous Editor FAQ section]] has it right: in wikicode, the semicolon opens a ''description list'', and will be translated into equivalent HTML. In other words, the wikicode is processed as follows:
{| class="wikitable"
|-
! Wikicode !! HTML
|-
| style="vertical-align:top;" |<pre>; xkcd
: a popular webcomic</pre>
|<pre>&lt;dl&gt;
&lt;dt&gt;xkcd&lt;/dt&gt;
&lt;dd&gt;a popular webcomic&lt;/dd&gt;
&lt;/dl&gt;</pre>
|}

One or more lines started with a semicolon ''must'' be followed by at least one line that starts with a colon, to provide the <code>&lt;dd&gt;...&lt;/dd&gt;</code> part of the description list block.

It is a {{w|Help:List#Common_mistakes|common mistake}} to use semicolon-lines as "headings". Unfortunately the result is '''invalid HTML''', since the HTML spec requires that a <code>&lt;dl&gt;</code> block contain:
<blockquote>Zero or more groups each consisting of one or more dt elements followed by one or more dd elements</blockquote>
It's fine to have multiple semicolon-lines in a row (as the HTML standard allows for groups of several <code>&lt;dt&gt;...&lt;/dt&gt;</code> blocks in sequence), but they must '''always''' be followed by at least one <code>&lt;dd&gt;...&lt;/dd&gt;</code> block, created in wikicode by following a line started with a semicolon with another line that starts with a colon. 

Just like lines started with <code>*</code> or <code>#</code>, a line started with a <code>;</code> creates a list element, and has syntactic requirements that must be followed. Abusing the description-term wikicode for purposes other than description-list creation not only breaks the HTML on the resulting page, but it makes the content much harder for screen readers and other assistive technologies to parse and accurately reproduce. 

(And, yes, technically Mediawiki's use of <code>:</code>-lines for indenting, as on talk pages, is also invalid since it creates a <code>&lt;dl&gt;&lt;dd&gt;...&lt;/dd&gt;&lt;/dl&gt;</code> block with no <code>&lt;dt&gt;</code> element. So it's bad enough on talk pages, it's 100x worse to encourage doing it on '''article''' pages.) Please consider removing this bad advice from the Editor FAQ. Thanks. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 05:48, 5 September 2018 (UTC)

:Thanks for your remarks, that's why I started this FAQ and the discussion about it. Especially the header section is still preliminary, just check the section above here at the talk page.
:My first purpose is to keep it as simple as possible for writers having not much or no knowledge about wiki code or HTML. After that an advanced section should follow and define the rules for a complete article.
:Please check my summary from 29 August 2018 just above here. You're right the semicolon isn't a header, that's why I'm saying it should be used only temporary. And after reading your remarks here I would propose a single line with bold text and a following empty line instead of that semicolon thing.
:Keep it simple for people who just want to write something here; advanced users will change it to an appropriate layout later. Consider: When a new comic is out the explanation often starts in chaos. And for now I'm really happy that the overwhelming usage of tables is stopped.
:Let me know what you do think about the bold text line (not by semicolon) and the more sophisticated header guidance for the final layout as I've mentioned on 29 August 2018. --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 12:45, 5 September 2018 (UTC)
::And of course the usage of a semicolon should also be mentioned together with the colon because it's a list. An entire paragraph "How do I format lists?" has still to be written yet. --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 12:51, 5 September 2018 (UTC)
::One more: I've checked the definition for <code>dd/dt/dl</code> and it's clear the <code>dd</code> tag must be followed by at least one (either <code>dt</code> or <code>dl</code>) child. This tells me that the indent done by a colon is proper HTML. This is very important because every transcript since the first comic uses this indentation. --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 13:20, 5 September 2018 (UTC)

==Incomplete tags==
The FAQ says to use <code><nowiki>{{incomplete transcript|YOUR REASON}}</nowiki></code> but instead of rendering like this (like with the incomplete template):

{{notice|'''This transcript is incomplete:''' ''YOUR REASON'' <br/>If you can address this issue, please '''[{{fullurl:{{{target|{{FULLPAGENAME}}}}}|action=edit}} edit the page]!''' Thanks.}}

It renders like this:

{{notice|'''This transcript is incomplete.''' Please help [{{fullurl:{{{target|{{FULLPAGENAME}}}}}|action=edit}} editing] it! Thanks.}}

Can someone please change this? [[Special:Contributions/172.68.133.180|172.68.133.180]] 02:55, 13 October 2018 (UTC)
:The FAQ also says: "The reason at the transcript is not shown to the viewer." You can see it when you edit the transcript. And because the reason for the comic is also often not given this should be enough for the transcript. --[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 16:49, 15 October 2018 (UTC)

== math markup ==

Just to note - I was curious about the "math markup" message at the top of each page, and duly followed the link to the Editor FAQ as instructed, but ther--e is no mention of why it shouldn't be used... (no account yet, as I've not made any edits - yet! and i use google data saver, so this is not my ip -->)  --[[Special:Contributions/162.158.34.22|162.158.34.22]] 23:49, 11 December 2018 (UTC)

:damn, I'm tired - just re-read the section titles, and there it is.  It's late, so sorry! --[[Special:Contributions/162.158.34.22|162.158.34.22]] 23:54, 11 December 2018 (UTC)

::I think the reason given is incomplete, but wanted to check here before I amended it. Transcripts are for the benefit of visually-challenged visitors, so using math markup, and thus rendering the text as images, is counterproductive. Right? -- [[User:Dtgriscom|Dtgriscom]] ([[User talk:Dtgriscom|talk]]) 15:06, 20 March 2019 (UTC)

:::The explanation is (in my opinion) somewhat silly, as the image generated by MathML has an alt tag for text browsers/accessible use. Further, if this wiki's settings were chosen correctly, the image would be output with MathML alongside, which is the ''actual'' (non-plaintext) accessible solution for displaying mathematical formulas on the web. See also: https://accessibility.princeton.edu/about/blog/mathml-accessible-math-markup [[User:DimeCadmium|DimeCadmium]] ([[User talk:DimeCadmium|talk]]) 02:20, 12 October 2019 (UTC)

== Create page for new comic ==

Should there be a paragraph about this?
Since the bot is not working anymore, people need to do this. I know I have seen isntructions somewhere on this wiki, but cannot find them... [btw: there is a new comic up, right now, as I post this line, which is not yet in the wiki. SO if you know how to do it, do it before explaining it on the FAQ :)] --[[User:Lupo|Lupo]] ([[User talk:Lupo|talk]]) 13:27, 3 January 2020 (UTC)

== Page targeted by Spam ==

The page is currently targeted heavily by Spambots. I am not sure why they target this specific page. It might be, because it is linked in the header? Since Admins (who could protect the FAQ) seem to  be currently absent from the page, anyone got any ideas what to do about it? leave it to spam and create a seperate FAQ with the same content? --[[User:Lupo|Lupo]] ([[User talk:Lupo|talk]]) 10:08, 26 February 2020 (UTC)

== Spaces ==

Seriously, why oh why is [[1285:_Third_Way|1285]] not linked into the statement about the one space / two space [[1285:_Third_Way | controversy]]?  This feels like an inexplicable gap.  Is there a policy insisting the FAQ remain fastidiously humorless in all ways?  [[Special:Contributions/162.158.107.231|162.158.107.231]] 02:10, 29 January 2021 (UTC)

== Duplicating the hover text/title in the transcript section? ==

Is there a reason not to duplicate the title/hovertext in the transcript section, so a screenreader user can be sent there and not have to page back up for that bit (besides "one or more editors would need to check all entries and edit it in where missing")? [[Special:Contributions/141.101.68.43|141.101.68.43]] 00:11, 28 November 2021 (UTC)
:For my two (or three) cents:
:1) You'd be duplicating it, so you ought to lose the sub-image record if you do that or you could get silly with all kinds of repeating of everything..
:2) It's a Transcript to try to record/present the text (and imagery) you cannot already screen-read.
:3) It doesn't need manual editing (and manual editing is more likely to have mistakes, anyway).
:...Perhaps some Template(-pair?) could be developed to sit post-template to "display:screenreader-only" (or whatever the markup format would be) the upper-templated titletext field? [[Special:Contributions/172.70.86.12|172.70.86.12]] 04:00, 28 November 2021 (UTC)

== it's/its typo ==

At §[[explain_xkcd:Editor_FAQ#How_do_I_enter_mathematical_or_chemical_formulas.3F| How_do_I_enter_mathematical_or_chemical_formulas?]] please change “it's Wikipedia help page” to “'''its''' Wikipedia help page” (for the same reason that "our" and "their" don't have apostrophes).
[[User:Kurahaupo|Kurahaupo]] ([[User talk:Kurahaupo|talk]]) 23:44, 29 January 2022 (UTC)
: Came here to say this, but I see I'm two months too late. [[Special:Contributions/172.70.86.64|172.70.86.64]] 12:32, 9 April 2022 (UTC)

== Punctuation inside quotes and parentheses ==

Can we add a section saying <tt>."</tt> or <tt>,"</tt> is always better than putting the quotation mark first, and <tt>.)</tt> or <tt>.")</tt> are similarly preferable to <tt>).</tt> and <tt>").</tt> please? We also need to remind editors that numbered hyperlinks come after periods, commas, and parentheses, not before them. [[Special:Contributions/172.69.33.83|172.69.33.83]] 03:30, 3 September 2022 (UTC)
:...Erm. For quotes, it depends. If a proper sentence(-fragment) then I'd put punctuation in front (entry and exit), with ','=>'.' or vice-versa, as required by the full container sentence, but retaining notable exclamation- and question-marks. <tt>He said, "Erm," with a hint of hesitation, "For quotes, it depends."</tt> I know this is how I was taught to deal with quoted speech (close on fifty years ago), although I know standards change, and it may not even then have been so necessary for non-speech quotations. Yet certainly if I were to mention a set of randomish words like "Red green blue" (or "Red", "Green" and "Blue", perhaps) I would unhesitatingly consider it utterly wrong to move punctuation within any such quotation section. And note that an Oxford Comma (even without the quotes) would confuse matters in that second example.
:As for <tt>.)</tt> (etc), I've seen somebody ''wrongly'' do this. Do not do it if you have a in-sentence parenthesis (like this). I have never seen any suggestion that you'd do that (like this.) [<= Deliberately wrong!] And, even if it works "like a quote", it ''really'' looks wrong to me. (The clear exception is when you entirely make a sentence parenthetical, like this.)
:Now, this is just my own experience/preference/habituation. I have no doubt there are alternative points of view, which I would welcome to be added hereafter. But, whilst supporting the ''initial'' idea to precede quotes with punctuation (yet content to let it slip when others have prior authorship and it causes no additional confusion), I rail against it as an unwavering/absolutist style for all quotes ("quotes" ''and'' 'quotes', and maybe even «quotes» and the rest?) and especially it having any bearing at all in any bracketting/bracing/parenthesi(s|z)ing situations where full and proper start/end mark nesting should be adhered to as the ''only'' useful criteria.
:An interesting counter-examplee, however, might even mean individualised punctuation either side of a close-paren (if the sentence somehow does not require the same mark as the aside somehow begs, whether that be exclamation, question or even… ellipsis…?!?). Just so. But I'd normally consider rewriting that, as too stream-of-consciousness-like. [[Special:Contributions/162.158.159.73|162.158.159.73]] 04:25, 3 September 2022 (UTC)
::This is covered in sections [https://www.chicagomanualofstyle.org/16/ch06/ch06_sec005.html 6.5] and [https://www.chicagomanualofstyle.org/16/ch06/ch06_sec009.html 6.9] of the ''Chicago Manual of Style''. The intent is to aid readability. The reasons for variation from such style guidelines are evident when they are compelling, but whether a quotation doesn't actually end with a comma is simply not a compelling reason to write typography which distracts the ordinary reader. [[Special:Contributions/172.70.206.213|172.70.206.213]] 09:32, 3 September 2022 (UTC)
:::(Chicago links need registration to access, so no idea whose arguments/what alternative it supports.)
:::There are many Style Manuals (I'd defer to H. W. Fowler's ''Modern English Usage'', if forced). But, I would say, clarity is king above all. And I think the original suggestion is incorrect in that regard.
:::And depends upon medium. I was taught to put a little finger between words when learning to write with nibbed-pens (and don't smudge/flick the ink!) and a thumb-width indent to each paragraph's first line. Later two spacebars between sentences (and four as indent) when typing.
:::But that's old-hat (and  doesn't   survive     whitespace      condensing     in    XMLish   context,  etc, anyway). Spell things correctly (or, because of where Randall lives, all Americanised!) and try not to be accidentally ambiguous! And "-1" to original suggestion. [[Special:Contributions/172.70.91.80|172.70.91.80]] 12:04, 3 September 2022 (UTC)
::::A Google search on, "Fowler's Modern English on quotation," returns the question, "What is the correct punctuation for quotes?," in the second paragraph of results. Clicking on it shows the answer, "Commas and periods always go inside the quotation marks in American English; dashes, colons, and semicolons almost always go outside the quotation marks; question marks and exclamation marks sometimes go inside, sometimes stay outside."[https://www.grammarly.com/blog/quotation-marks/] Does ''Fowler'' diverge from ''Chicago'' in any of these respects? The paywall has a free 30-day trial, and it isn't difficult to find citations to those sections elsewhere. [[Special:Contributions/172.70.206.163|172.70.206.163]] 21:38, 3 September 2022 (UTC)
:::::(On principle, I don't do 'free trials', but that's just me and a comment on being asked to check something that has hoops to it.)
:::::Like I said, ''if forced'', I'd defer to Fowler of the many options, after the clear suggestion that Chicago was effectively the ''Académie Française'' of English, no matter which flavo[u]r of the lingo you're defaulting to. And [https://www.thepunctuationguide.com/british-versus-american-style.html this article is interesting], but I'm not sure I agree with its single-/double-quotes mark primacy suggestion.
:::::Anyway, when it's an actual speech-quoting-quote I'd probably adhere to preceding the quotation marks. But was resonding to OP's (your?) suggestion that it "is always better". And, coincidentally, just there it is not. Furthermore, Fowler does suggest that where a sentence is equally clear with and without punctuation, one should leave it out. I may not always stick to that myself, with an inordinate love of comma-bound sub-clausing, but I find it a decent principle to aspire to.
:::::As for "Foo (bar.)"-form sentences. No. Just no. Though "(Foo bar.)", and then always so in that case! Noting that you've not defended this part of the original idea, so I don't feel the need to continue to flog that aparently terminal equine.
:::::It's all just opinions, however, just to demonstrate my feelings on the subject as sympathetic to the gist of OP's first respondant. I have no idea if OP and Chicago-linker (and, in turn Chicago-trialler) are the same person or just separately of the opposing opinion. Let those who actually administer the site have the ultimate say (if they wish to have), naturally. [[Special:Contributions/172.69.79.201|172.69.79.201]] 23:18, 3 September 2022 (UTC)
::::::The reason we don't try to assign identities to the sources of ideas when we discuss them, is because we believe, as Oscar Wilde once said, the value of the idea is greater than the value of the person expressing the idea. Would you please answer the question about whether ''Fowler'' diverges from ''Chicago?'' [[Special:Contributions/172.69.33.83|172.69.33.83]] 23:49, 3 September 2022 (UTC)
:::::::I have yet to delve into the Windy City's precise text. And Fowler has said much, but how about:
       [...] Neatness is the sole consideration; just as the ears may be regarded as not hearing organs, but 'handsome volutes of the human capital', so quotation marks may be welcomed as giving a good picturesque finish to a sentence; those who are of this way of thinking must feel that, if they allowed outside them anything short of fine handsome stops like the exclamation and question marks, they would be countenancing an anticlimax. But they are really mere conservatives, masquerading only as aesthetes; and their conservatism will soon have to yield. Argument on the subject is impossible; it is only a question whether the printer's love for the old ways that seem to him so neat, or the writer's and reader's desire to be understood and to understand fully, is to prevail."
:::::::And later, as part of a conclusion, the interesting:
       [...] We recommend that the Times method should be abandoned, and the first or second of the others used according to circumstances.
        The next question is, Whence is this income derived?—Times.
        The next question is 'Whence is this income derived?'. (Full direct quotation. Observe the 'monstrosity' stop)
        The next question is whence this income is derived. (Indirect quotation)
        The next question is 'Whence this income is derived'. (Indirect quotation with quotation marks, or half-and-half quotation, like the Borrow sentence)
:::::::Far too much to copypasta. The concluding para just over-eggs my already eggy pudding, so above are just two of the many interesting bits that popped up in the source given at the top of my own definitive search (by exactly the same terms as given above), that demonstrate the evolution of what might be considered acceptible (and why) going into the future, ''[https://www.bartleby.com/116/406.html from 1908]''! [[Special:Contributions/162.158.159.11|162.158.159.11]] 10:06, 4 September 2022 (UTC)

==Math Formatting==
Math formatting seems to be broken.  For example, the following (from [[2435: Geothmetic Meandian]]) doesn't compile:

<math>\left(\prod_{i=1}^n x_i\right)^\frac{1}{n} = \sqrt[n]{x_1 x_2 \cdots x_n}</math>

Perhaps a configuration error?  The LaTeX markup is correct, and it works on Wikipedia and TeX processing systems like Overleaf, but not here.  Simple things like <math>E=mc^2</math> seem to work, but more slightly more advanced things like uppercase greek letters (e.g., ''\Pi'') and delimiters (e.g., ''\left('' or ''\right)'') don't seem to.

Or is this by design, and math formulas really shouldn't be part of explanations?  That seems a bit odd to me (especially for an xkcd explanation wiki), but I'm new here and I'm not sure.

:Math formulas should be a part of the explanation. I think this is an error. I am having trouble with this too. I am correcting a formula on 2117. A simple change of superscript positioning triggers the same error for me. [[Special:Contributions/172.69.58.141|172.69.58.141]] 19:15, 14 October 2023 (UTC)

== Clarify "removing Discussion (from main comic article) if it gets too long" ==

''What'' gets too long: Article or Discussion (or the net sum of both)? How much ''is'' too long? Is there a 'hmm maybe' buffer, given the inconsistencies in application across articles? Do you just scrap {{template|comic discussion}} (noting header-tab to the Talk: page is always there), or do you leave an explanatory surrogate link for the no-longer-embedded section (especially as others may arrive later and presume that it was missed/removed for no good reason, never mind actually disagreeing over the utility...). And do you do it unilaterally/anonymously, or is it better to posit the change (RFC it, on the relevent Talk: page, or perhaps a Community Portal-like global review page/section) ''before'' stepping in to do so without opposing voices?

I can see why it's a sensible guideline, but I'm not confident that it is being consistently applied (one way or another, or both), and it could do with concensus rather than seemingly arbitrary application at the whim of any old editor. [[Special:Contributions/172.70.91.235|172.70.91.235]] 10:06, 30 October 2023 (UTC)