Template talk:Strong

Bad bot behavior?
As of this writing, I believe that the bot known as is replacing all instances of   HTML code it finds with   wikimarkup, which is just plain wrong (  is equivalent to   HTML code, not the   element). There are probably others, as there are certainly editors who do this semi-automatedly with AWB. — SMcCandlish  Talk⇒ ʕ(Õلō)ˀ  Contribs. 10:06, 29 September 2010 (UTC)

Substitute parser functions
I think the parser functions should be substituted to ease substitution of this template (similar to and ). (SUBST states that templates with parser functions should not be substituted.) I've already created a version at Template:Strong/sandbox. Anon 126  (notify me of responses! / talk / contribs) 19:35, 24 April 2014 (UTC)

Use in lead sections of articles
"In the lead section of an article, the article's title and its synonyms be marked with . Example: 'The, or, or , is the bulbous end of a neuron.' , this is not yet common, but users should not revert it (nor criticize anyone for not using it)."

I disagree. The MDN documentation says  should be used for keywords, not including any special importance. On the other hand, I believe Special:Diff/1034851022 is a more appropriate example of use. As also noted with Special:Diff/1033844764, this has not gained widespread adoption for at least over nine years -- and I kind of hope it doesn't. 84.250.14.116 (talk) 06:05, 22 July 2021 (UTC)


 * I hope it does! To me, our boldface usage in the leads is an indication of importance, and the styling is properly applied. Firefangledfeathers (talk) 01:45, 23 July 2021 (UTC)
 * I've been regularly editing for years and only now did I encounter an editor who used strong for bolding in the lede. The template documentation does encourage this use (and has done so since it was written in 2010), but I can't find the basis for it. The manual of style (MOS:LEDE) doesn't mention this template, instead recommending the usual wikimarkup. I've scanned its talk archives since 2010, and the only discussion I found was this thread from 2018. There were three participants: one who strongly believed strong should be adopted, one who argued the template was the correct option but had doubts about its eventual widespread adoption, and one who considered this use of the template semantically incorrect. If that's all there is to go by, then the current template documentation is wrong. The best it can say is that there's no consensus for this use (and probably worth emphasising that this concerns only the bolding of the title in the opening sentence, not the synonyms, no-one is suggesting these should be in anything other than regular bolding: see the brief comments in this 2015 thread).
 * So, I'm going to update the template documentation to reflect the existing (absence of) consensus. Now, my personal view is that if the template were to be used in article ledes, we'd need good reasons for that, not the least because it comes with some drawbacks (minor though they are: it slightly complicates the wikicode, makes the text a bit more difficult to edit with the visual editor, and it hides the encompassing text from the preview pop-ups). – Uanfala (talk) 14:06, 10 November 2022 (UTC)
 * I had not used it in the Lead until the Symphyotrichum pilosum article and only because I had read the use cases in the template documentation. I can understand why it needs to be there for the semantic meaning for screen readers, specifically. As someone who may end up blind one day, I tend to think about these things. But if Wikipedia is only for those who can see, then so be it. – Elizabeth (Eewilson) (tag or ping me) (talk) 14:15, 10 November 2022 (UTC)
 * I use this template routinely and have never organically encountered any other user that does so. I have no objection to saying that there is no consensus for its use. Firefangledfeathers (talk / contribs) 14:16, 10 November 2022 (UTC)
 * Wikipedia talk:WikiProject Usability/Archive 3 and the follow-up at Wikipedia talk:WikiProject Accessibility/Archive 2 have information about the 2010 change. The usage of this template and its cohort Em falls primarily under the WikiProject Accessibility. It's probably a good idea to discuss this there and hold off on the note on consensus. – Elizabeth (Eewilson) (tag or ping me) (talk) 14:39, 10 November 2022 (UTC)
 * Jumping in here from WikiProject Accessibility; I hadn't encountered this template before myself, but I do add em to articles regularly. I don't think we should assume that just because we don't see editors adding strong in regularly, it doesn't have a place here; it may well be that this is because it isn't mentioned in MOS:LEAD, and due to a lack of emphasis on accessibility throughout our various guides on writing articles. (It's a sort of "no accessibility is provided" → "therefore people who need it don't turn up" → "therefore there's no need for it" → "therefore no accessibility is provided" loop, if you get me.)
 * I'd be more than happy to see strong used in articles if it would be for bold text what em is for italicised text. Wider recognition of accessibility standards in Wikipedia editing feels slow-going at times, but I've managed to convince other editors to use features like language templates in the articles they edit before now. Even if it feels like I'm the only person I see adding certain accessibility templates to my little corner of Wikipedia at times, it doesn't mean these templates aren't needed, and that their wider use couldn't convince others to think more of accessibility in their edits.—Ineffablebookkeeper (talk) (&#123;&#123;ping&#125;&#125; me!) 17:09, 10 November 2022 (UTC)
 * The "Infinite Loop of Inevitable Inaccessibility" (ILII).
 * I continue to correctly use these templates (Strong and Em) in my little Wikipedia world. I think that putting the comment that it is not MOS consensus in the template documentation is acceptable for now, so that can be modified a bit, and completely removing the bullet point describing when to use it in the Lead should not have been done. So I'm going to make that modification in order to more accurately represent the situation. Because this template falls under Project Accessibility, I think it is up to the keepers of that project to take the next steps, which are, as I see it, getting both templates, and any other related ones, in the MOS so they are noticed. Twelve years is better late than never, right? – Elizabeth (Eewilson) (tag or ping me) (talk) 17:44, 10 November 2022 (UTC)
 * Guys, the question here is not whether we want our articles to be accessible or not, but whether using this template in this particular way will help accessibility or hinder it. In the one thread where there was discussion of that issue (in the guise of a question about semantically correct html) there wasn't agreement. – Uanfala (talk) 18:07, 10 November 2022 (UTC)
 * It seems a proposal needs to be made and has not been. What it looked like to me after reading the 2018 discussion was that it kinda just fizzled out. See what you think about the changes I'm making to the documentation. About ready to publish. – Elizabeth (Eewilson) (tag or ping me) (talk) 18:16, 10 November 2022 (UTC)
 * Also pointing out it is addressed at WikiProject Usability/Scannability, which is a hatnote in the when to use section of the template documentation. – Elizabeth (Eewilson) (tag or ping me) (talk) 18:23, 10 November 2022 (UTC)
 * , the threads you've linked above have to do with the initial creation of strong, and they don't have any discussion at all of the template's use in an article's opening sentence. In the two threads where the issue was actually discussed (the current one as well as the one from 2018), there's disagreement not just over whether that use should be encouraged, . The crucial question is: does strong result in html output that's semantically appropriate for this case. That's where the disagreement lies. If the template isn't semantically more appropriate than mere bolding here, then its use won't be better for accessibility, it will be worse. But even apart from the above, this addition to the template's documentation is problematic. Effectively, it' saying "X should be done", but then the footnote immediately goes like "Well, actually, there's no consensus for that..". If there doesn't exist consensus for a particular use, then we shouldn't have the project pages recommending that use. – Uanfala (talk) 20:17, 11 November 2022 (UTC)
 * Okay, I tweaked it. I'm too tired to do it tonight, but I want to pursue getting a consensus or not from the MOS project on whether it should be used in the Lead. If it's a go, then to see it added to the MOS. What was in this documentation, "users should not remove it [from the Lead] (nor criticize anyone for not using it)", remains and IMO is a good statement. Kind of a live and let live outlook. I think you're right that it needs to be further investigated as to the syntactical correctness in the HTML code, and if not, what is the best course of action for accessibility if  won't work to provide that type of strong emphasis necessary for screen readers and other disability-related tools. I am not an HTML expert and wouldn't even know where to look or how to test for that, but hopefully someone who is will help gather that information. – Elizabeth (Eewilson) (tag or ping me) (talk) 21:07, 11 November 2022 (UTC)
 * Your latest change to Use cases makes sense, and you are right, it reflects the current status. Thank you for your diligence. I haven't had a chance to pursue a proposal. – Elizabeth (Eewilson) (tag or ping me) (talk) 15:17, 22 November 2022 (UTC)
 * Sorry, I forgot to reply earlier. I agree with your "live and let live" approach and I think it's a good thing to have a diversity of technical means available, at least until one of them is ultimately selected as the most appropriate. I don't know much about HTML either, I was just going by what was said in the previous discussions. Looking into whether "strong" tags are syntactically correct here is a good first step forward, and I think WP:VPT may be one of the places to ask for further comments. – Uanfala (talk) 15:50, 22 November 2022 (UTC)