Jump to content

Wikipedia talk:Manual of Style/Layout

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

See also section status

[edit]

My experience and general observation is that see also sections are slowly being trimmed back and deprecated during the article development process. This is because most of the time, as an article progresses from a stub, entries in the see also section can often be incorporated into the article and eliminated. However, at least one editor feels differently, and is keeping the spirit of the early 2000s alive. ("It's the 90s 2000s, Colin!") Instead of using the see also section for articles that can be incorporated into the article during the expansion process, they are using the see also section purely as a navigational tool. In this instance, they are using the see also section in a wide variety of articles to point to "list of x" articles that are generally related to the biographical subject, such as a list of their paintings or books, etc. In most cases, this usage duplicates links in the footer template. The user has several justifications as to why we should use the see also section as a navigational tool instead of the footer template, often having to do with limitations on mobile users and the uptick in article hits (or so it is claimed) when the see also navigational link is used. I don't have any strong feelings on this, but I think adding see also sections as a navigational tool is slightly unusual and isn't spelled out or explained anywhere in the MOS, and is also, in many cases, duplicating the link in the footer template. More input would be appreciated. @Randy Kryn: courtesy ping. Viriditas (talk) 21:13, 22 October 2024 (UTC)[reply]

Any examples. I see that there have been a few talk about dropping footer.templates all together since only about 20% of our readers have access to them. Moxy🍁 21:59, 22 October 2024 (UTC)[reply]
It might be easier to just look at Randy's contribs. He's committed to this like peanut butter on jelly. However, if you just want to look at one article instead of a bunch, you can take a look at The Gust of Wind (Renoir), where the see also duplicates the same link in the footer (which I've now collapsed). I guess I'm just not familiar with Randy's position that the see also should be used for navigation, and that's not something I've seen in the MOS, although I could be missing it. My objection to footer templates is that they look terrible, so I wouldn't be sad to see them go. If there was a way to make them look professional, then I would be in favor of keeping them. Viriditas (talk) 22:09, 22 October 2024 (UTC)[reply]
I see the link at The Gust of Wind (Renoir) as a good addition as the footer is not see by the vast majority of our readers. This reminds me of what we do for country articles linking an index or an outline of the topic.... that is links that lead to a vast amount of information about the topic. Moxy🍁 22:15, 22 October 2024 (UTC)[reply]
Great, could I see an example of such a country article link? I'm not familiar with it. Viriditas (talk) 22:16, 22 October 2024 (UTC)[reply]
Canada#See also as outlined at the essay WP:COUNTRYSECTIONS "See also – 'See also" sections of country articles normally only contain links to "Index of country" and "Outline of country" articles, alongside the main portal(s).". Moxy🍁 22:22, 22 October 2024 (UTC)[reply]
That's great, because it limits and restricts the type of entries at the project/country level. I'm not sure that applies or is relevant to biographies, works of art, literature, etc., but I could see how one could loosely apply it. I don't see anything at Wikipedia:Manual of Style/Biography or any the other relevant projects, however. Viriditas (talk) 22:33, 22 October 2024 (UTC)[reply]
It's something they should develop...... or at the very least develop some sort of anti-template spam that is seen at Meryl Streep#External links....that is one of the many examples used to justify why nav footers aren't visible in mobile view..... all related to masslink spam to loosely related articles and template limit concerns. WP:BIDIRECTIONAL is one of the worst ideas the MOS has and is simply ignored by those working on academic topics that are concerned about accessibility and structure of an article. WP:BIDIRECTIONAL results in mass template span that really only affects pop culture and biography articles and if one of the main reasons footers aren't seen in mobile view.Moxy🍁 22:43, 22 October 2024 (UTC)[reply]
Thank you for the education. I'm more confused than before I started this thread, but over time I've come to learn that's a sign of progress. Viriditas (talk) 22:51, 22 October 2024 (UTC)[reply]
@Moxy: I’ve been thinking about this, and I don’t really see how the link is all that helpful in see also sections about individual paintings. Yes, it should definitely appear in a top-level article about the artist, but in an article about an individual painting I don’t find it helpful or informative. There is virtually no useful content, such as info about his different periods and styles, and the accuracy of the information is probably in doubt. If it was a verified list with relevant material I wouldn’t have a problem with it, but it’s not. We just have one editor spamming the list to every article about Renoir, and I don’t like that. How does the link help the reader of the article? I don’t find it helpful, so I don’t see how anyone else does. I also don’t think it’s the job of the article to facilitate navigation, but rather understanding. For this reason, I would prefer to remove the see also section and merge the link into the article itself. Viriditas (talk) 04:16, 23 October 2024 (UTC)[reply]
I think having the most important related articles in the "See also" section (provided they weren't already mentioned in the article text) is a good thing, since we should not forget that mobile readers (which are clearly the majority, as far as I know) won't see footer templates at all, so having the "See also" section as a kind of mini-footer template will certainly help them. It's indeed no longer the 2000s, and we should try to think "mobile first" now. Gawaon. (talk) 07:16, 23 October 2024 (UTC)[reply]
Yeah, I’m a bit confused by that, honestly. 90% of all cell phones are smartphones, and many people browse in desktop mode. So where is this whole mobile users aren’t seeing footer templates thing coming from? I assume you are talking about people using the app? Viriditas (talk) 07:53, 23 October 2024 (UTC)[reply]
I see now that you are referring to https://en.m.wikipedia.org, specifically. Viriditas (talk) 08:26, 23 October 2024 (UTC)[reply]
Navboxes are coded to prevent their display on the Mobile Web site. This is because the layout is horrendous when the screen is 2.5 inches wide.
You can approximate the problem if you visit a page like Template:The Beatles and make your browser window as narrow as possible. The more 'nested' the template, the worse the problem. See Template:Concepts in infectious disease for an example of that. Navboxes were designed as wide tables, and those just don't fit into the smartphone format. WhatamIdoing (talk) 08:30, 23 October 2024 (UTC)[reply]
I don't have a problem with navboxes and templates in iOS (except for playing video) but I assume other people do. Viriditas (talk) 08:51, 23 October 2024 (UTC)[reply]
Scroll to the end of https://en.m.wikipedia.org/wiki/Multidrug-resistant_bacteria on your phone. Make sure you are on the default-for-iOS mobile site, not switched to the desktop view. Do you see a navbox at the end of the page? WhatamIdoing (talk) 18:34, 23 October 2024 (UTC)[reply]
Yeah, I got it. Thanks. Viriditas (talk) 18:38, 23 October 2024 (UTC)[reply]
I talk about people using browsers on mobile, not about the app. When I open Wikipedia on my smartphone's browser, I don't see any navboxes. It happens automatically based on one's screen size, as far as I know – which is very reasonable. Like WhatamIdoing said, navboxes on phone screens would be a terrible user experience, and I'm quite happy that they are automatically hidden. But of course that means that we can't rely on them for anything essential. Gawaon (talk) 17:06, 23 October 2024 (UTC)[reply]
I edit and write from my phone on a daily basis, but I use desktop mode, not mobile. Viriditas (talk) 02:21, 24 October 2024 (UTC)[reply]

Placement of the "Bots" template?

[edit]

Greetings and felicitations. Where should a "Bots" template be placed in an article? —DocWatson42 (talk) 14:42, 6 December 2024 (UTC)[reply]

Use of template "further". Does it need clarification?

[edit]

I work a lot with tennis articles and many have the {{main}} template placed above the lead. Lots and lots of them. Example 2024 ATP Finals – Singles. I was shown awhile ago that template "main" is never to be placed in the lead and it says so right in the template documentation. Several of us have been changing "main" to the template "further" to fix this disparity. Today I look at the template "see also" and it also says not to be used in the lead, only at the top of article sections. That got me to thinking why is the "further" template not clear on this placement? It says top of sections but says nothing about the article lead. Is this a mistake of not being clearer? I ask because Tennis Project is slowly fixing the "main" template to "further" and I don't want to find out later that no template at all should be in the lead. Should we be removing {{main}} completely, changing it to {{further}} or something else? And should the {{further}} template be made more clear as to its proper placement? Thanks. Fyunck(click) (talk) 22:03, 13 January 2025 (UTC)[reply]

{{Broader}}? Moxy🍁 02:23, 14 January 2025 (UTC)[reply]
{{Broader}} is also just meant for sections, I'd seems. I'd rather avoid any such template in the lead but instead integrate the information into the running text: During the 2024 ATP Finals, Jannik Sinner defeated Taylor Fritz ... Gawaon (talk) 04:14, 14 January 2025 (UTC)[reply]
"Broader" has the same issue as "further" does. It says section and it talks about being used as a replacement for "main" and "see also" which are already listed as not being suited for the lead. I think what we need is something in the documentation of "further" and "broader" that says this can be used in the lead, or this should not be used in the lead. So editors will know. I'm not sure where I stand which is why I brought it here to discuss. We know "main" and "see also" do not get used in the lead. What do we do with "further" and now "broader?" Allow it, not allow it, encourage it's use or disuse? Fyunck(click) (talk) 07:09, 14 January 2025 (UTC)[reply]
Is this mostly for tennis articles, or is there similar use elsewhere? Putting on my reader's cap, at a glance it looks like the disambiguation hatnotes I through banner blindness don't read unless and until I'm somehow not on the page I want. I would be more likely to look for it in the lead, as mentioned above, or in the template where it seems to already be located. CMD (talk) 08:14, 14 January 2025 (UTC)[reply]
I'm not sure of all the articles these items are used in. It's easy to see what links to {{main}} or {{further}} but not easy that I know of to search for those links only in the lead. You will see it also at the Olympics such as Badminton at the 2020 Summer Olympics – Women's singles or Table tennis at the 2008 Summer Olympics – Men's singles They have certainly proliferated in tennis articles for some reason. And in fixing the known "main" issue in the lead I don't want to compound the problem by changing "main" to "further". Certainly we can get rid of all those templates in the lead but I wasn't sure if that was correct either. I looked for guidance in the templates themselves and only got it with "main" and "see also". I thought my betters here could shed some light. Fyunck(click) (talk) 10:56, 14 January 2025 (UTC)[reply]
I've used {{Broader}} for this purpose, for example Multicast address. The hatnote it creates there says "For broader coverage of this topic, see Multicast." so it looks appropriate. I guess hadn't looked carefully at the documentation because, you're right, it only talks about use in sections there. I would support updating the documentation to describe its use to create a hatnote at the top of the article. ~Kvng (talk) 16:45, 17 January 2025 (UTC)[reply]
I'd forgotten about "Broader" but that fits in the same pattern. Should it be used in the lead or only in sections of prose? And I'm sure if we allow it in the lead, some will be scratching their heads for a good reason why we treat "Main" and "See Also" differently. I think it should be clear in all these templates on where they can be used. Should we put the same updated documentation in all these templates that the lead is perfectly acceptable, other than "main" and "see also"? Fyunck(click) (talk) 19:18, 17 January 2025 (UTC)[reply]
Since the only response on what to do didn't have a problem using "broader" and "further" at the tops of articles, I will make it clear in the templates that they can be used there. Fyunck(click) (talk) 00:35, 31 January 2025 (UTC)[reply]
 Done Per these discussions and also WP:RELATED. Only the templates "see also" and "Main" cannot be used above the lead, and I fixed their documentation. Fyunck(click) (talk) 00:50, 31 January 2025 (UTC)[reply]
FWIW, to the extent concerns are raised about using these sorts of hatnotes in the lead or other other awkward places, you can simply use {{Crossref}}, an inline hatnote. As in: Some article text here. (For additional detail see: Underwater basket weaving.) A bunch more article text here.  — SMcCandlish ☏ ¢ 😼  20:13, 6 February 2025 (UTC)[reply]

Semi-protected edit request on 28 January 2025 fix contradiction with WP:MOSSIS

[edit]
−
If the article has no "External links" section, then place the sister link(s) in a new "External links" section using inline templates.
+
If the article has no "External links" section, then place the sister link(s) at the beginning of the ''last section'' of the article.

Copy from, and fix contradiction with, WP:MOSSIS. Background: [1]. 173.206.40.108 (talk) 22:23, 28 January 2025 (UTC)[reply]

This is an ancient issue, spurred by some unclear wording years ago. Although I hadn't realised it had propagated here too.
The inconsistent change was introduced as part of this: [2]. A change that was wrong at the time, is still wrong, was contentious then and certainly had no consensus for a change so potentially major, despite the apparently small change to the text.
There are two important axiomatic aspects to this. Everything else follows logically from that (although logic is not a strongpoint of WP editing, especially around the bureaucracy of styleguides).
  • The project link boxes are CSS floated. That means that they are not really 'within' a section, although they appear in the wikitext inside that section. But their screen placement is more complex. So they need to be placed in the last section (of the wikitext), whether that's EL or not. That is the crucial aspect, not any semantics of them being 'external links'. The EL section (to the rendered appearance) doesn't include them - its content (and whether it's empty or not) is the content that's still left-justified (i.e. actual ELs).
  • We value consistency of presentation, hence the whole point of having MoS. So the presentation of a sister project box should not change arbitrarily just according to whether or not there are any ELs present.
A past wording unclarity could be interpreted to mean that if we removed all the ELs, then suddenly we'd reformat a Commons link from a clear, visible box into one of the overlooked inline form - for no other reason than that.
A corollary of the first is that (as we've always done, and MoS describes elsewhere) is that we don't add an empty EL section just to 'contain' (because it doesn't contain it!) a project link box.
There are some other questions still in play: Is a Wiktionary link useful here (for a dictionary entry that merely restates the first sentence of the lede? No.)
Then, are there multiple sister project links? Because in such a multiple case, we might reformat to either the list form (with its poor usability) or else the container box form. But otherwise we stick with the well-recognised single floated box form. Andy Dingley (talk) 23:09, 28 January 2025 (UTC)[reply]
So, let's change the text of this page as suggested by OP. Right? Gawaon (talk) 03:06, 29 January 2025 (UTC)[reply]
No. These templates should go in the "External links" section if it exists, but in the last section of the article otherwise. What we don't want is for an EL section to be created simply to hold such a template.  — SMcCandlish ☏ ¢ 😼  20:14, 6 February 2025 (UTC)[reply]
Didn't you mean: "Yes, change the page as suggested"? Right now this page says one should create an "External links" section for them if none exists yet. Gawaon (talk) 03:10, 7 February 2025 (UTC)[reply]
Converted to RfC 173.206.40.108 (talk) 03:28, 16 February 2025 (UTC)[reply]

Title language

[edit]

Hi there! Where should {{Title language}} fit it? It seems to me like it fits with {{DISPLAYTITLE}} and {{italic title}} in level 2. Thanks! GoingBatty (talk) 01:33, 13 February 2025 (UTC)[reply]

Yes. In its code it uses DISPLAYTITLE. Gonnym (talk) 08:37, 14 February 2025 (UTC)[reply]
[edit]
WP:Manual of Style/Layout § Links to sister projects reads
If the article has no "External links" section, then place the sister link(s) in a new "External links" section using inline templates. ...
  • Box-type templates (such as {{Commons category}}, shown at right) have to be put at the beginning of the "External links" section of the article so that ...
  • ...
If an external link is added and/or exists in the "External links" section, the "inline" templates linking to sister projects can be replaced with their respective box-type templates.
WP:MOSSIS reads
Most box-type templates such as {{Commons}} shown at right should be put at the beginning of the last section of the article (which is usually, but not necessarily, the "External links" section) so that ...
... [only in special cases], consider using "inline" templates, such as {{Commons-inline}}, in the "External links" section

Which style should be used? 173.206.40.108 (talk) 03:28, 16 February 2025 (UTC)[reply]

The last ==Section== on the page should be used, no matter what the section heading is called. ==External links== sections should not be created for the purpose of putting a large box on the right-hand side of an otherwise empty section. Compare:
Comparison of the two options
The good approach The space-wasting approach
Further reading
  • Brown, Rebecca (2006). "Size of the Moon", Scientific American, 51 (78).
  • Miller, Edward (2005). The Sun. Academic Press.
  • Expert, Alice (2008). The Sun is Really Big. University Press.
Further reading
  • Brown, Rebecca (2006). "Size of the Moon", Scientific American, 51 (78).
  • Miller, Edward (2005). The Sun. Academic Press.
  • Expert, Alice (2008). The Sun is Really Big. University Press.
External links
This was settled some 15 years ago and hasn't been seriously disputed since then, so I really don't think we need to have a whole RFC about the wording here. This was probably the result of a couple of edits resulting in the text accidentally 'drifting' over time from the real rule/widespread practice. It's not the big of a problem. I suggest withdrawing the RFC and just fixing the text. WhatamIdoing (talk) 04:15, 16 February 2025 (UTC)[reply]
I agree. Gawaon (talk) 08:35, 16 February 2025 (UTC)[reply]
Withdrawn as requested. Not reactivating the semi-protected ER for now. @WhatamIdoing: Can you help with just fixing the text please? 173.206.110.217 (talk) 02:28, 17 February 2025 (UTC) (same nom, new IP)[reply]
 Done. NB that the above text doesn't really contradict; it just preferred a less typical solution (i.e., it preferred putting Template:Commons category-inline in an ==External links== section over putting Template:Commons category in the ==References== section). Both approaches are acceptable. WhatamIdoing (talk) 04:03, 17 February 2025 (UTC)[reply]

Semi-protected edit request on 18 February 2025 duplicate word

[edit]
−
in in
+
in

Thanks for the rewording. One small problem: There is a duplicate word. 173.206.110.217 (talk) 05:17, 18 February 2025 (UTC)[reply]

Fixed, thanks! Gawaon (talk) 08:42, 18 February 2025 (UTC)[reply]

Alphabetic order

[edit]

The style guide says that the "See also" and "Further reading" sections need to be in alphabetic order, but not the references. In practice, we normally do the opposite. Hawkeye7 (discuss) 18:23, 23 February 2025 (UTC)[reply]

Perhaps different groups practice differently. The pages I work on have {{reflist}} references in citation order, alphabetical See Also, and random Further reading. Johnjbarton (talk) 23:12, 24 April 2025 (UTC)[reply]
It will depend upon the reference style. References within {{reflist}} always appear in the same order that they appear in the page text. If you use WP:CITESHORT, the first part (described there as "Notes") also appears in the same order that they appear in the page text, see NBR 224 and 420 Classes#Notes; but the second part (described there as "References") can be in any order you like - I use alphabetical order by author, then by year, then by title. See NBR 224 and 420 Classes#References. --Redrose64 🌹 (talk) 17:06, 25 April 2025 (UTC)[reply]
My experience is also random Further reading and External links sections. If we're going to ask that these be alphabetized, we're going to need to specify what to alphabetize them by. In light of this, I don't see a better option than random. ~Kvng (talk) 15:15, 29 April 2025 (UTC)[reply]
"Further reading" should always be sorted alphabetically in my opinion, as it tends to be books and articles with authors where that's trivially possible. That also tends to be the case in the articles I have seen/edited. As the "External links" often don't have specified authors, how to sort them is a trickier problem, hence they often are more or less unsorted. Gawaon (talk) 18:28, 29 April 2025 (UTC)[reply]
Authors are not always identified in Further reading. I guess a full cleanup would improve that formatting. Still, I doubt it is always possible to sort all entries by author. But, I guess that doesn't mean we shouldn't try to. ~Kvng (talk) 20:13, 3 May 2025 (UTC)[reply]
I don't think that alphabetic is always the best answer. For ==See also==, that can result in putting less-relevant articles at the top, and burying a link to the most relevant one (e.g., a List of whatever the article is about).
I think the main thing to know is that the lists are usually semi-random unless and until someone deliberately imposes a sensible order on them, and that a sensible order is a desirable thing. WhatamIdoing (talk) 22:10, 3 May 2025 (UTC)[reply]

Level 1 headings

[edit]

MOS:OVERSECTION says never appropriate within the body of an article. That should be changed to never appropriate within the body of a page, unless I'm missing something? Paradoctor (talk) 04:42, 22 April 2025 (UTC)[reply]

I think we're actually trying to say should never be explicitly used in wikitext or somtheing like that. Is there ever a case where = Heading 1 = is used? ~Kvng (talk) 15:20, 29 April 2025 (UTC)[reply]
Some talk pages. In particular, talk pages that are split by date get a =January 1= section heading. (This is more common at other wikis.) WhatamIdoing (talk) 22:11, 3 May 2025 (UTC)[reply]
You mean talk page archives? Could you provide an example? Paradoctor (talk) 22:52, 3 May 2025 (UTC)[reply]
User talk:Mjroots. --Redrose64 🌹 (talk) 00:18, 4 May 2025 (UTC)[reply]
That is just a case of a user violating the rules because they either don't know how to comply, or don't care about. It's not really hard:
  • Level 2 headings for sorting
  • Level 3 headings for individual topics
Or move topics to subpages and transclude them from there.
Or use WP:Labeled section transclusion to get the same effect without subpages, which can be done fully transparently, in full compliance with WP:TPL, either on the talk page itself, or on one or more custom access pages.
Tons of options. Customization does not necessitate MOS violations. Paradoctor (talk) 09:11, 4 May 2025 (UTC)[reply]
The "Add topic" tab always generates a level 2 heading (as here). Mjroots desires that new topics appear under the "New messages" primary heading, which since we cannot expect every person who creates a new thread to immediately go back and alter it from level 2 to level 3, means that "New messages" must therefore be at level 1. They've done it this way since 14 January 2008, and I don't recall there being any complaints about this in the past. --Redrose64 🌹 (talk) 12:05, 4 May 2025 (UTC)[reply]
Please add new subjects to the bottom of the relevant section; If you are unsure where to add your contribution, the "New messages" section at the bottom of the page will be fine. I'll move it myself if necessary.
Mjroot doesn't expect every person to do more than just hit "Add topic", but he does ask for more: He wants users to hit either "edit page" or "edit section", then navigate to the appropriate place , and manually create a section heading.
there being any complaints about this Why should there be? A polite request to do things a little differently which one is entirely free to grant or not is not a problem.
You'll note that I did not ask for squashing a dissident, I merely said that there are ways of customizing that conform with policy. Paradoctor (talk) 12:45, 4 May 2025 (UTC)[reply]
The MOS is for article space. Level 1 headings pop up here and there outside of it; Template talk:Did you know uses one, all the Wikipedia:Reference desks use them for dates in the way WAID mentioned. CMD (talk) 12:52, 4 May 2025 (UTC)[reply]
MOS:GOODHEAD: Level 1 headings, automatically reserved for the article title, should not appear within the article's body text.
WP:MOS: provisions related to accessibility apply across the entire project, not just to articles (my emphasis) Paradoctor (talk) 13:13, 4 May 2025 (UTC)[reply]
You'll need to make the specific accessibility case to overturn the longstanding use of these headers. Entirely possible that there has been an issue this entire time, but it certainly isn't a guaranteed assumption. CMD (talk) 13:20, 4 May 2025 (UTC)[reply]
No, I don't. What we have here is a contradiction between practice and rules that needs resolving. Which one, to which degree, is a community problem. To that end, I invited some expertise. Paradoctor (talk) 13:38, 4 May 2025 (UTC)[reply]
As a screen reader user, I've never had a problem with level 1 headings at places like the reference desks. They're almost unheard of in the rest of Wikipedia (and that should remain the case) but they're not a showstopper where they are used in a standard way. This part of the Manual of Style is only about articles and is usually not applied elsewhere (hence the quoted text above), so I don't think there's a contradiction here. I do occasionally fix first-level headings on talk pages where they can also interfere with the table of contents, among other things; here's an example diff I found using the edit summary search tool. Graham87 (talk) 15:13, 4 May 2025 (UTC)[reply]

As you're talking about me, I may as well respond. MOS:OVERSECTION does not prohibit level 1 headers outside of articles. By having level 1 for sections, and level 2 for threads, it makes archiving easier for me. I archive manually because I don't trust bots to do it the way I want it. Yes, I do ask that threads are started in the relevant section. Some editors do this, some don't. I have never, ever, complained if an editor has started a new thread at the foot of my talk page. I reserve the right to move the thread to an appropriate section, either at the time, or when I have one of my periodic sessions moving threads around. I am not aware of any accessability issues in using level 1 headings. Mjroots (talk) 15:21, 4 May 2025 (UTC)[reply]

MOS:OVERSECTION does not prohibit level 1 headers outside of articles See above: GOODHEAD is part of WP:ACCESSIBILITY. Paradoctor (talk) 15:35, 4 May 2025 (UTC)[reply]
GOODHEAD is about articles, not talk pages. Explain exactly what the accessibility issue is, apart from seeming to be WP:IDONTLIKEIT. Mjroots (talk) 15:49, 4 May 2025 (UTC)[reply]
🤦 Paradoctor (talk) 15:55, 4 May 2025 (UTC)[reply]
Yes, it's at MOS:ACCESS. But read the literal words in GOODHEAD: "Level 1 headings, automatically reserved for the article title, should not appear within the article's body text." Note the absence of any words in GOODHEAD that sound even remotely like "Not only is using a Level 1 heading something you shouldn't do 'within the article's body text', it's also something that we've banned on absolutely every single page on wiki". WhatamIdoing (talk) 19:48, 4 May 2025 (UTC)[reply]
Since Graham87 has stated above that I've never had a problem with level 1 headings at places like the reference desks. They're almost unheard of in the rest of Wikipedia (and that should remain the case) but they're not a showstopper where they are used in a standard way, it's pointless continuing along the accessibility road. --Redrose64 🌹 (talk) 20:36, 4 May 2025 (UTC)[reply]

Looking at the underlying accessibility question: the W3C guidance on headings is for the levels to match the hierarchy of sections on the page. Whether or not there should be more than one first-level heading on a page has long been a debate in the web design community. WCAG's technique on "Using h1-h6 to identify headings" explicitly notes that the first heading in peer sections of the page could have the same heading level "such as an h1". For articles, the community hasn't found any reason for another section on the page to have the same rank as the article's topic. But there are some project pages where for convenience, the first part of the page is devoted to a description of X, and the second part has requests related to X. (The second part may be within the actual source of the page, or transcluded from another page.) Although it's not my personal preference to have two level 1 headings on a page, I acknowledge that as long as the heading hierarchy within each section accurately reflects the structure of the sections, there isn't any accessibility issue in practice. isaacl (talk) 16:39, 4 May 2025 (UTC)[reply]

Help Magic Words

[edit]

The page Help:Magic words says:

  • see MOS:ORDER for guidance on where to place magic words that are behavior switches.

but upon arrival I am greeted with silence rather than guidance. Johnjbarton (talk) 23:10, 24 April 2025 (UTC)[reply]

It was added by Jonesey95 (talk · contribs) with this edit, at which time MOS:LAYOUT looked like this. It's not at all clear to me what Jonesey had in mind. --Redrose64 🌹 (talk) 17:18, 25 April 2025 (UTC)[reply]
Any idea where in the page {{TOC Limit}} is properly placed? Johnjbarton (talk) 17:23, 25 April 2025 (UTC)[reply]
That note, or the edit summary, does not make sense to me two years later. I scoured the docs for location-dependent switches and couldn't find anything. I have removed it. As far as I know, TOC limit can be placed anywhere on the page, but the top usually makes sense, since that is where the TOC appears in some skins. – Jonesey95 (talk) 17:32, 25 April 2025 (UTC)[reply]
Thanks! Johnjbarton (talk) 17:35, 25 April 2025 (UTC)[reply]
@Johnjbarton: Personally, anything that controls the table of contents (such as TOC limit) I would put at the same place that the TOC itself is displayed in all skins apart from Vector-2022; that is, just before the first section heading. --Redrose64 🌹 (talk) 12:27, 26 April 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Layout&oldid=1288799883"