Talk:UN report: climate change and food shortage major problems for Earth's future

Block based content supplied to template only accepting SPAN.

{{editprotected}} The quoted portion of the report includes a list. {{QuoteRight}} which is used here, only accepts a SPAN based run of text, other input breaks the run of the formatting apparently.ShakespeareFan00 (talk) 18:31, 9 September 2020 (UTC)

Done
•–• 18:39, 9 September 2020 (UTC)

@ShakespeareFan00, Acagastya: The replacement code doesn't work right, though, while the original code did. ShakespeareFan00, what made you think there was something "wrong" with this in the first place? I'd really like to understand this as there seems to be something wrong with the way some of these problems are being identified. --Pi zero (talk) 23:57, 9 September 2020 (UTC)

The error was identified by the LintHint script, (working from the LintErrors data) as a missing /stripped SPAN error pair (because the block level element generated by the list doesn't nest within the SPAN used for text passage), and was correctly detected. You can't put a LIST inside a SPAN. This is a KNOWN limitation of Mediawiki currently. ShakespeareFan00 (talk) 00:04, 10 September 2020 (UTC)

I repeat, the replacement code did not work right, while the code before replacement did work right. Saying it's a current limitation of Mediawiki does not change the fact that it was working correctly and then it wasn't. I feel there is something that's not being said here, that would be valuable to clarify. --Pi zero (talk) 01:03, 10 September 2020 (UTC)

Neither the old or new version generates well-formed HTML (if it did the parser wouldn't have to attempt to insert tags in attempt to self. If the old version worked better then the attempted repair though...

The actual problem, is as stated that the Template being used doesn't appear to be able to accept block-level content. Paramater 1 - which is the text of the relevant extract is wrapped as <span style="color: #0000CC; font-family: Verdana, sans-serif"><small>'''{{{1}}}'''</small></span>. Per HTML structuring rules, only inline elements can be placed inside a SPAN. A UL (in this instance the list markup generated either by Mediawiki or directly, is a block level element, not an inline one.

This isn't a misdetection, just one that's detected in a different way ( A Missing SPAN, Stripped SPAN pair.) Ideally what Mediawiki/Linter should be doing is recognise that an attempt's been made to put a block level element (UL) inside a SPAN, and report it at as such.

A possible repair is to fork {{QuoteRight}} to a {{BlockquoteRight}} so that the block level content concerned can be placed inside an appropriate block level element.ShakespeareFan00 (talk) 07:34, 10 September 2020 (UTC)

@ShakespeareFan00: This is an interesting case, I think, worth examining more closely.

• A fundamental error in all of this is that these supposed "lint errors" are based on the deeply mistaken pretense that wiki markup is shorthand for html. Wiki markup is the language in which wiki pages are written, while html is a moderately humanly usable language, but less so than wiki markup, into which wiki pages are translated. Any html errors in the generated html —especially when we're talking about wiki markup that has no pseudo-html in it— are mistakes made by the wiki software, not mistakes by the authors of the wiki text. The reason wiki markup exists is that html is not as human-oriented as one would like. I have perceived for many years, but would have hoped not to encounter such an explicit demonstration, that the Foundation has, outright foolishly (and I'm understating by saying that), failed to see that wiki markup is their biggest asset, and so they have wasted many years and done tremendous damage to the sisterhood by looking for ways to undermine wiki markup; cf. Hanlon's Razor. I'm realizing, as we discuss this case, part of what's bothering me is that this lint approach implies a really over-the-top emphasis on html, when authors writing wiki markup should not ordinarily think about html at all.
• Specifically: One of the basic rules of wiki markup is that when you come to the end of a paragraph, any outstanding italics or bolding are canceled; reset to plain text. That is an important principle, because wiki markup is supposed to be rugged, able to handle whatever is thrown at it in the most useful way it can; it's going to be edited routinely by folks who will make little slips here and there, and cannot and should not be asked to deal with complicated fussy rules, and when there's an unmatched double-apostrophe or triple-apostrophe, the consequences of that should be limited to that one paragraph, so you don't end up bolding or italicizing the entire rest of a document, possibly without even noticing.
• The first parameter to {{QuoteRight}} is, in fact, surrounded in the template with triple-apostrophes. This means that if the parameter text is all on a single line, it comes out bolded. It also means that if the parameter text is more than one line, only the first line is bolded. That is what is supposed to happen, given the expected behavior of wiki markup (and it has nothing whatever to do with html; that's a red herring). And in this particular case, the authors' intent evidently was that the first line should be bolded, and the text heading each bulleted list should be bolded, while the bulleted items would not be bolded. In order to make this happen, the first line isn't touched, because the markup in the template causes that to be bolded, and then each of the headings is explicitly bolded via triple-apostrophes in the parameter-value, and the bulleted items have no bolding markup on them where they appear in the parameter.
• It would not be of any help to fork the template, because the behavior in the subtemplate would still be wrong. Afaics, the only practical way to get the correctly expected behavior is to rely on the wiki platform to behave correctly. If the wiki platform were broken by incorrectly extending mismatched italics/bolding to the entire document, that would break all wiki text that depends on the platform doing what it should do — and would, of course, be a betrayal of both the wiki contributors who have for decades relied on the platform doing its job in good faith, as well as a betrayal of the fundamental philosophy of wiki markup that it is not some sort of second-class shorthand for html but is the primary interface language to be supported for contributors. (Sorry to put it so strongly, but, there it is.)
• I'm thinking that this particular class of coding practice, which isn't wrong (merely politically inconvenient for the Foundation's misguided agenda), should not be something we go out of our way to correct. (Also @Acagastya:.) There are some other cases of this sort of thing, where tolerant behaviors by the wiki software (and thus, good faith by those who maintain the software) are relied upon by wiki authors, sometimes in pure wiki markup and sometimes involving angle-bracketed tags; one that comes to mind atm is that template documentation pages are given a blue background by means of, last I saw, an unmatched opening div tag.

--Pi zero (talk) 12:55, 10 September 2020 (UTC)