| Revision as of 18:52, 18 April 2018 editIzno (talk | contribs)Checkusers, Interface administrators, Administrators115,051 edits →Fake heading template use in articles?: com: yes, this should be ditchedTag: 2017 wikitext editor← Previous edit | Revision as of 03:26, 19 April 2018 edit undoLowercase sigmabot III (talk | contribs)Bots, Template editors2,302,427 editsm Archiving 2 discussion(s) to Misplaced Pages talk:Manual of Style/Accessibility/Archive 14) (botNext edit → | ||
| Line 18: | Line 18: | ||
| |leading_zeros=0 | |leading_zeros=0 | ||
| |indexhere=yes}} | |indexhere=yes}} | ||
| == Results of RFC == | |||
| The recent RFC at showed that there is not consensus for a general requirement that articles should stop using colon for indentation. The use of colons is a current, standard practice. It's no problem for this guideline to give optional advice, but given the outcome, it would be inappropriate to add any language that suggests that colons are deprecated, legacy, outdated, or otherwise not the standard way of doing various kinds of indentation. — Carl <small>(] · ])</small> 12:14, 13 December 2017 (UTC) | |||
| : Nah. showed that the RfC was derailed by a bloc vote from one special interest group who did not understand the wording of the RfC. It's a ]. But, it's a moot point. No one tried to "ban" using colons for indentation anyway! The RfC had literally nothing to do with that at all, only with whether two editors can filibuster against MoS subpages agreeing with the main MoS page. You're also confusing "used by many because it's convenient and we started out that way when WP was new" with "standard". They're not synonyms. When three MoS pages have agreed for years that there are better alternatives, and we know for a fact that doing it the colon way causes validation failure, and that there are better and more robust ways that are well-tested (one of them {{em|actually}} standardized as a template for this purpose on every single WMF project), {{em|and}} the page you're "defending" has nothing whatsoever to do with accessibility and layout, then it's time for you to ]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ><sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>< </span> 18:04, 13 December 2017 (UTC) | |||
| :: | |||
| :: That's completely missing the point, {{u|CBM|Carl}}. The use of colons for indentation is a long-standing, common practice. It is also ''bad'' practice, and it does nobody any favours by pretending otherwise. Good grief, most sensible web designers stopped using definition lists to produce visual indentation before the turn of the millennium, and you won't find a single other large website making that mistake. We ought to be encouraging better practice by offering editors alternatives that don't cause a nuisance to our visually impaired visitors. Using description lists for indentation is an accessibility issue, period. No amount of RfCs can alter that fact, and this page is quite right to point that out. | |||
| :: Now, don't misunderstand me: I'm not suggesting banning the use of colons for indentation. There are simply too many talk pages and archives with that poor markup to even consider that option, and Misplaced Pages editors who use screen readers will have become accustomed to the second-rate experience afforded by our ignorance. But there's no good reason why articles ever need to use colons for indentation, other than in conjunction with semi-colon markup when genuine description (definition) lists are actually required, as in a glossary or lists of characters and their characteristics in articles about TV series, for example. --] (]) 19:02, 13 December 2017 (UTC) | |||
| ::: I get the distinction between an ideal world and the actual world. But the issue I am looking at here is only: does the use of colons to indent non-blockquotes comply with the MOS? The answer to that has always been a clear "yes". A change to that longstanding aspect of Misplaced Pages style requires much more than just the input of a few editors here, or an undiscussed edit to an MOS page. It needs to be widely advertised at least on a village pump, and have a clear consensus, before changes to the MOS. Those changes would then need to be clear about what the MOS does require. At the same time, I don't object to the language here being changed provided that it remains only advisory, as it has been for a very long time, and not prescriptive. — Carl <small>(] · ])</small> 20:36, 13 December 2017 (UTC) | |||
| :::: But you don't seem to get the distinction between what we need to do to improve the experience of reading any web page for a user of a screen reader and what has been accepted in ignorance as suitable markup for Misplaced Pages. That is the only issue that applies to this page. That's neither negotiable, nor susceptible to crowd-sourced wisdom. It's just a fact. That means that you're mistaken about the answer to {{tq|does the use of colons to indent non-blockquotes comply with the MOS?}} Ever since the decision to make ] part of MOS, the answer to that question is a clear "no". The documentation provided by our policies and guidelines is ''descriptive'', not ''prescriptive'', and the MOS cannot ''require'' anything, so it's not going to force anybody to improve their bad habits. It might just encourage them, though. We don't need an RfC to make clear what should be done to improve the accessibility of Misplaced Pages, and the language here will continue to make that clear, despite a handful of editors at minority projects choosing to attempt to defend the indefensible. I don't object to you writing whatever takes your fancy at MOS:MATH as long as you don't try to remove guidance on best practice about accessibility in MOS:ACCESS. --] (]) 01:14, 14 December 2017 (UTC) | |||
| ::::: The MOS requires many things. For example, WP:MOS requires "In generic use, apply lower case to words such as president, king, and emperor". This is not descriptive - it is explicitly prescriptive, and all articles are expected to comply or be fixed. By contrast. most of the advice in WP:ACCESS is just advice (basically: "you can do this if you want, but there is no requirement, and you are free to ignore it if you want"). That is how the use of colons for indentation has always been treated by WP:ACCESS. In contrast, WP:ACCESS ''forbids'' the use of blank lines between colon-indented material ("Blank lines must not be placed between colon-indented lines of text"). There is an important difference in the way these things are worded. At the RFC, quite a few editors were explicit that colons should remain an acceptable way to indent material, just as they have always been. The accessibility issue should be handled, of course, but by improving Mediawiki rather than by changing the standard method of indentation. — Carl <small>(] · ])</small> 01:27, 14 December 2017 (UTC) | |||
| ::::: I am also fine with the longstanding wording here, as I think I have indicated - if not, that's the point of this follow up. Everything was very stable until quite recently, which suggests to me that was not actually any important disagreement in the way that the two pages WP:ACCESS and WP:MOSMATH have been read for years. — Carl <small>(] · ])</small> 01:35, 14 December 2017 (UTC) | |||
| :::::: On the contrary, the MOS does not ''require'' that lower case be applied to common nouns. It gives guidance that lower case should be applied. Take a look at {{oldid2|815058340|Malignant Metaphor: Confronting Cancer Myths}} which has lots of common nouns capitalised. There are thousands of articles with the same problem and editors have freely ignored what the MOS advises for as long as the MOS has existed. The way it works is that the MOS gives guidance that carries authority. An editor will follow the guidance of MOS to fix problems and the onus falls on anyone disagreeing with that in a particular case to demonstrate why an exception should be made. | |||
| :::::: Now, when someone fixes colon markup in an article by use of an accessible alternative, what you want is to be able to tell them "Oh no. You can't get rid of my inaccessible markup. I'm allowed to use it by the MOS." Well that simply isn't going to fly, is it? That wouldn't be using the MOS to promote good practice, just to defend a set of personal bad practices. | |||
| :::::: As for blank lines, MOS:ACCESS tells editors not to place blank lines between colon-indented lines of text. It doesn't stop them from doing it, of course, but it does justify fixing that issue when it arises. | |||
| :::::: In the RfC, some editors did ask that colons should remain an acceptable way to indent material, despite the problems they cause for the visually impaired. But like you, they fool themselves into thinking that improving Mediawiki will solve the accessibility issue. It can't. Colon markup is being used for two distinct purposes in Misplaced Pages: (1) to complement semi-colon markup in the creation of description lists; and (2) to create visual indentation at the expense of causing accessibility issues. Until somebody figures out how to replace ''either'' all of the semi-colon/colon markup for genuine description lists, ''or'' all of the colons used just for visual indentation, any change to the way that colon markup is parsed by Mediawiki software will cause chaos. If you contend I'm wrong about that, then feel free to submit your patch to the Mediawiki software that fixes the issues. Until you're willing to do that, you really ought not to be stonewalling positive steps to reduce the accessibility problem. Nobody needs colons in articles just to produce indentation, and it's a step forward to point out the accessible alternatives. --] (]) 02:13, 14 December 2017 (UTC) | |||
| ::::::: A few points I would add to what RexxS said: "Everything was very stable until quite recently" ... because keeping MoS material in sync requires real and often slow actual human effort, and because ] is obscure, and is over-controlled by people from ] with almost no input from MoS regulars. Did you know that ] (the page where nearly everyone goes for any MoS-related material involving numbers) did not even mention MOS:MATH, until I fixed that yesterday? You're welcome. The only "instability" in this situation was the two-editor flipout over nothing but recommending and illustrating more accessible markup that produces {{em|visually identical output}} and has no effect at all on the math markup. Total overreaction.<!-- | |||
| --><p>On "forbid" and "require": MoS, being a style guide, prescribes (advises, provides guidance to do or not do) many things. Due to the ] rules about what a guideline actually is and isn't at Misplaced Pages, and by MoS's own lead, it cannot literally forbid or require anything, whether it's emphatically worded or not. (Much of its more authoritarian language was added by a single party who later got topic banned; we've been slowly moving it back to more advisory wording; I do a lot this rewording myself – including today, specifically to mollify CBM's and SB's concerns ).</p><!-- | |||
| --><p>The idea (or at least one of them) at Phabricator ticket {{Phab|T6521}} is for the MW parser to detect whether a <code>:</code>-starting line is preceded by a <code>;</code>-starting line and vice versa; if not, convert to a styled span instead of list markup. There's lots of whingeing that this is hard, but MW is a marvel of making hard stuff practical, so I have faith it can be done right. It's just a matter of whether the devs finally take it seriously enough to actually make it happen. It can {{em|also}} happen that {{tag|math|o}} can be modified to support an indentation attribute; these are complementary not competing ideas. There's an obvious logic problem here, though: the naysayers' objection at ] and at the train-wrecked RfC – that there's so much math markup already indented by colons that it's just too hard to change it – is disproven by their support for changing {{tag|math|o}}, which would take exactly the same amount of work to implement in the articles. The hominid territorial instinct – "if it's not my tribe's plan it's an attack" – ] conscientiously suppressed by all of us here.<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ><sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>< </span> 05:49, 14 December 2017 (UTC)</p> | |||
| {{od}} I do not think casting this as a tribal overraction is remotely constructive. Nor is singling out two editors who have made far fewer edits to the guidelines as , simply because they happen to have a different opinion than you. So, if you wish this discussion to move forward, such characterizations really must be stopped immediately. They are totally against policy, as . | |||
| On to the more substantive ] issue, I do not see how using a special template, which would involve typing the special characters "{", "}" that require additional navigation to a menu of special characters, four times, on a mobile device, is more accessible than typing the single character ":". Do folks editing with screen readers actually find it more accessible to use a multicharacter solution, including four special characters? Evidence to the contrary exists on this very talk page is that ], who I believe uses a screen reader, uses colons for indentation. If not, then it seems to me that the only solution here is to fix the emitted HTML. This was raised several times at the RfC in question. Indeed, it seems like consensus (insofar as there was one) coalesced around that very suggestion. This would have the added benefit of fixing talk pages: I note that all participants in this discussion themselves use colons for indentation. ] (]) 14:03, 14 December 2017 (UTC) | |||
| : | |||
| : I'm afraid you've completely missed the point of Misplaced Pages. We're writing this encyclopedia for the ''readers'', not the ''editors''. If an editor finds it awkward to type "{{ }}" on a mobile device, I sympathise with them – it ''is'' awkward – and that's why I edit from a desktop PC. But that sympathy and consideration does not override the duty we owe to our readers, a significant number of whom use assistive technology to read our articles, and they will find our broken definition lists used to indent confusing and awkward, a problem they will not have encountered on any other major website. | |||
| : Like everyone else, {{u|Graham87}} included, we use colons to indent comments on talk pages. After all, it's all we have, and as ''editors'', we get used to it. But the same argument simply can't be applied to articles, particularly as the audience is completely different. Now Graham is a really nice guy; I've had the pleasure of meeting him in person, and he is remarkably good at making allowances for all the crappy markup we throw at him, but he has been able and willing to get used to it. Nevertheless I'm not prepared to tell every visually impaired ''visitor'' that they have to "get used to it" as well, simply to make life a bit easier for ''editors'' who find it hard to type "{{ }}}" on their phones. That really would be the tail wagging the dog. I hope that helps you understand why I'm so passionate about these accessibility issues, and why I want us to give advice to encourage the very best practice possible. And that doesn't mean encouraging colon markup to produce indentation. --] (]) 17:09, 14 December 2017 (UTC) | |||
| :: And folks here assure me that the reader's experience will be improved if the developers fixed the broken semantics of colon. (I'm not convinced that it makes a big difference, but I will take your word for it that it does.) This will allow editors to continue to use colons for indentation on talk pages, for indenting equations in articles, and using the style guidance of this guideline. That seems to me like the solution. ] (]) 17:56, 14 December 2017 (UTC) | |||
| ::: There are no broken semantics of the colon markup to fix. The wikimarkup parser takes the colon and renders the html {{tag|dd}} tag. If the tag is not inside an html {{tag|dl}}, it adds that as well. However, that leaves the html missing the {{tag|dt}} element, which would be created by semicolon wikimarkup. A genuine description list has perfectly good semantics and, for example, glossaries using ; and : together for that purpose are commonly (and accurately) used in Misplaced Pages. However, if you now want to ''re-purpose'' the colon to mean <code><nowiki>style="left-margin:1.7em;"</nowiki></code> – an accessible method of indentation – then you break all of the uses of colon in glossaries, etc. for making a definition list. Having the same wikimarkup produce two different results in html/css depending on context is a fundamental no-no, and I'm not surprised the devs won't touch it with a barge-pole. I know that {{u|SMcCandlish}} has a touching faith in the devs' abilities to figure out when a colon is intended to be associated with a semi-colon (a genuine description list), and deliver different code from when a colon is meant to simply produce an indent, but I'm not convinced. I can see far too many opportunities for that to break – a description list inside an indent and an indent inside a description list come to mind immediately, not to mention a description list followed by an indent – for us to have any chance of a robust solution to the issue within a reasonable timescale. --] (]) 19:44, 14 December 2017 (UTC) | |||
| ::::That's all correct (including my faith in devs to make it work). However I did say at the Phabricator ticket that since 99.99% or so of use of <code>:</code> is for visual indentation, not description/definition/association lists, that if the price we pay for fixing it is that it no longer ever does {{tag|dd}} that is acceptable triage, since a) it's not that much to clean up, comparatively, b) we have better markup for d-lists anyway, and c) the <code>:</code> way of doing is is actually extremely brittle (e.g. it breaks the list if you insert a linebreak in the item). It's anyone's guess what the devs will actually {{em|do}}, if anything. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ><sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>< </span> 20:15, 14 December 2017 (UTC) | |||
| :::: Colons ''mean'' indentation in Wiki. Furthermore, they have since the beginning. The software implementation of those semantics, regarding the colon as part of a colon-semicolon pair, is incorrect. That should be corrected. ] (]) 21:49, 14 December 2017 (UTC) | |||
| ::::: That's patent nonsense. Colons have never meant indentation at any stage of the development of MediaWiki markup. The have always produced {{tag|dd}} html, just as semicolons have always produced {{tag|dt}}. It's true that most browsers have visually displayed the {{tag|dd}} as indented, and 20+ years ago early web designers sometimes misused {{tag|dd}} to create indentation. That particular bad idea died out everywhere except for the early MediaWiki users. As long ago as 2003, the misuse of dd to produce indentation was described as outdated:<ref>{{cite book |last=Niederst |first=Jennifer |title=Learning Web design : a beginner's guide to HTML, graphics, and beyond |date=2003 |publisher=O'Reilly |location=Beijing |isbn=9780596004842 |page=104 |edition=2nd |url=https://books.google.co.uk/books?id=eN6_am2A5acC&pg=PT123&lpg=PT123}}</ref> {{talkquote|1=Unfortunately there is no "indent" function in standard HTML, so in the past, designers resorted to the creative misuse of existing tags to get text to indent.... HTML cheats include ... Using a dictionary list ({{tag|dl}}) with only definitions ({{tag|dd|o}}) and no terms to display text as indented}} So why are some editors still fighting to retain a practice that was recognised as inappropriate 14 years ago and more? --] (]) 22:53, 14 December 2017 (UTC) | |||
| :::::: Well, ] and ], and you just used colons to indent. For a more historical viewpoint, compare . shortly after the project launched. The (lack of) inclusion of indentation tags in HTML is a completely separate issue from the use of colons on Misplaced Pages. Colons are the standard way to indent ''in wikitext''. I completely agree there is an issue in the way that Mediawiki renders indentation, but that does not mean that colons are not the standard way to indent things (several people also pointed this out in the RFC). — Carl <small>(] · ])</small> 23:40, 14 December 2017 (UTC) | |||
| ::::::: Well doctors used to bleed patients to let out foul humours and that was standard practice. That didn't make it good practice, did it? "Standard" does not equal "good", and it's about time you gave up hiding your lack of argument behind your mistaken assumption about what "standard" implies. | |||
| ::::::: Of course I used colons to indent here. This is a ''talk page'' and editors have learned to accept the broken markup. I have to follow the nested description lists already in place because if I used CSS indentation, it would unwind other editors' nesting and cause an even greater mess. | |||
| ::::::: The MediaWiki software does not render indentation. Your browser does that. If you used a different user agent (say Lynx or JAWS), you'd observe a different rendering from what you get using Chrome. MediaWiki consistently produces description lists from colon indentation and that is not the issue. The issue is simply that editors have chosen to misuse {{tag|dd}} to display indentation in a way that is inaccessible, so that the same markup (<code>:</code>) is being used for two different purposes. There are accessible alternatives to using colon markup for indentation, and I have yet to see any argument why an editor who changes a colon in an article to an indentation template shouldn't be congratulated for improving the encyclopedia, not lambasted for breaching some wholly imaginary "standard". --] (]) 11:19, 15 December 2017 (UTC) | |||
| :::::::: Mediawiki renders wikitext (its input language) into HTML (its output language). Of course the browser then renders the HTML into a sequence of commands for a windowing environment, which eventually renders those onto a screen. I have not seen anyone arguing that Mediawiki should use dd/dl tags for indentation, but that is a completely separate question from how indentation is specified in Wikitext. In any case, I am OK with the current language of this page, which remains descriptive, and I don't see much benefit in continuing to go back and forth on topics that don't directly relate to changes in the page. If I see a reason to rejoin the conversation, I'll come back. — Carl <small>(] · ])</small> 11:32, 15 December 2017 (UTC) | |||
| ::::::::: Mediawiki renders wikitext into html, but it does not render indentation. The user agent is responsible for that, so your statement {{tq|"there is an issue in the way that Mediawiki renders indentation"}} makes no sense, does it? MediaWiki doesn't use tags for indentation, so your statement {{tq|"I have not seen anyone arguing that Mediawiki should use dd/dl tags for indentation"}} is equally nonsensical. | |||
| ::::::::: The issue is no more that this: (1) editors choose to use colons alone to imply indentation; (2) mediaWiki transforms colons to description lists; (3) that results in broken html that causes accessibility problems. You want to break that chain by some unspecified – and wholly improbable – change to step 2. I want to tackle the problem at source by discouraging step 1 because we can do that ''now''. There's where our disagreement lies. --] (]) 11:48, 15 December 2017 (UTC) | |||
| ::::::: Carl, please stop resorting to this "you just used colons to indent" bullshit. Everyone in this so-called debate, on every page you've dragged it out across, explicitly recognizes that we use colons for indentation on talk pages and will continue to do so, unless and until WMF provides us with functional threading software that also handles MediaWiki code samples properly. This has nothing to do with preferring more accessible markup in actual article content. All of this has been pointed out to you ], including at your own user talk page. If all you can do is childishly fall back on "you just used a colon", this means you have no argument left, and need to just ] and go do something constructive instead of continuing to try to tell accessibility specialists what's-what about accessibility. See ] and ]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ><sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>< </span> 16:13, 15 December 2017 (UTC) | |||
| {{reflist-talk}} | |||
| == Alternative text for images == | |||
| {{FYI}} | |||
| I moved ] to ], where the rest of the ] supplement pages are. All links and shortcuts to it work, it just now isn't lost in the vast sea of the "Misplaced Pages:" namespace, but is consolidated with the related material. Also fixed the old ] and ] shortcuts to work (they'd lost their anchor point when the "Purely decorative images" heading went away). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ><sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>< </span> 23:53, 20 December 2017 (UTC) | |||
| == "Animations; video and audio content" == | == "Animations; video and audio content" == | ||
Revision as of 03:26, 19 April 2018
"WT:ACCESS" redirects here. For the related wikiproject talk page, see Misplaced Pages talk:WikiProject Accessibility.| Skip to table of contents |
| Please place new discussions at the bottom of the talk page. |
| This is the talk page for discussing improvements to the Manual of Style/Accessibility page. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17Auto-archiving period: 3 months  |
 | Manual of Style   | |||||||||
| ||||||||||
 | Accessibility | |||
| ||||
 | Misplaced Pages Help B‑class Mid‑importance | |||||||||
| ||||||||||
"Animations; video and audio content"
"Animations, video and audio content" looks like typo for "Animations; video and audio content", "Animations – video and audio content", or something, because the construction isn't parallel.
This is minimally reparable with a serial comma: "Animations, video, and audio content". It's not perfect but it's more easily parseable without having to do a double-take and a head-scratch. Please see MOS:SERIAL: Use a serial comma by default, and definitely when the result is weird without one: "A serial comma (also known as an Oxford comma or a Harvard comma) is a comma used immediately before a conjunction (and or or, sometimes nor) in a list of three or more items .... Editors may use either convention so long as each article is internally consistent". This page is already using the serial comma ("... a substitute for the image for blind readers, search-spiders, and other non-visual users", etc.). While MoS doesn't technically apply to its own content, we try to keep it in compliance with it as a best practice, or it looks hypocritical to not do so, inspiring editors to ignore it when writing articles, and venting on the MoS talk pages about MoS not taking its own advice.
This would actually be better with more of a rewrite. Any of these would work:
- "Animated, video, and audio content"
- "Animated, video and audio content" – if people really want to go to war against a comma
- "Animations, videos, and audio content" – the comma cannot be omitted in this one
- "Animations and other audio-visual content"
- "Animated and other audio-visual content"
- etc.
An argument can also be made that "Animat" is actually redundant with "video" anyway.
This short version is: omission of the serial comma is lazy journalese, is not found in most academic writing, and makes it more difficult to tell that a list is a list and what is or is not a discrete item within it. There's a reason that The Chicago Manual of Style and other style guides that aren't for newswriting recommend it. — SMcCandlish ☏ ¢ >ⱷ҅ᴥⱷ< 03:03, 22 December 2017 (UTC)
- Most of the early image animations were animated gifs and they were not conventionally considered video, although technically there's little difference. So to most folks' minds, I expect animations not to be redundant with videos. Any heading that needs time to be decoded is a candidate for re-writing. Personally I'd prefer the much clearer "Animations and other audio-visual content" which eschews the comma. --RexxS (talk) 23:31, 22 December 2017 (UTC)
- I do, too, especially given that we use more animations than actual video (or it seems that way to me – this could be a factor of the kinds of articles I read and work on). However, just "Audio-visual content" would probably work fine, now that I think about it, if people like that concise option. But eschewing a comma isn't actually a good reason to do a rewrite; except in terrible writing (like the bad example given at MOS:COMMA), such punctuation doesn't decrease clarity, but increase it at near-zero cost. That said, I'm not going to argue further on it, and I apologize for the grumpy WP:REVTALK about this; I was in a crabby mood for external reasons.
PS: I created the DAB page WP:Manual of Style/Audio as a place for the then-missing but obvious MOS:AUDIO to go; I think I included every relevant page, but could have missed something. Need to do similar for MOS:VIDEO.
— SMcCandlish ☏ ¢ >ⱷ҅ᴥⱷ< 17:12, 23 December 2017 (UTC)- Sorry, I really wasn't clear there. I meant to say "I prefer this title for clarity. As a bonus it avoids arguments about commas." Maybe my original comment needed a comma in there somewhere?
--RexxS (talk) 17:52, 23 December 2017 (UTC)
- Sorry, I really wasn't clear there. I meant to say "I prefer this title for clarity. As a bonus it avoids arguments about commas." Maybe my original comment needed a comma in there somewhere?
- I do, too, especially given that we use more animations than actual video (or it seems that way to me – this could be a factor of the kinds of articles I read and work on). However, just "Audio-visual content" would probably work fine, now that I think about it, if people like that concise option. But eschewing a comma isn't actually a good reason to do a rewrite; except in terrible writing (like the bad example given at MOS:COMMA), such punctuation doesn't decrease clarity, but increase it at near-zero cost. That said, I'm not going to argue further on it, and I apologize for the grumpy WP:REVTALK about this; I was in a crabby mood for external reasons.
Short descriptions
FYI Misplaced Pages talk:Manual of Style/Layout#Short descriptions. --Redrose64 🌹 (talk) 20:55, 17 February 2018 (UTC)
Discussion notice: Observe MOS:FONTSIZE in infobox templates
You may be interested in the proposal/discussion at Misplaced Pages:Village pump (proposals)#Observe MOS:FONTSIZE in infobox templates. ―Mandruss ☎ 00:27, 17 March 2018 (UTC)
Fake heading template use in articles?
Does the use of Template:Fake heading comply with MOS:GOODHEAD and WP:PSEUDOHEAD?
In this diff an editor removed the normal headers to use the fake heading template. I don't think this is the intended use of this template, but clearly it is happening regardless. I also don't think this template should be normally used in article space. In addition, I don't think this template supports anchors.
I started a conversation about this template on its talk page here: Template talk:Fake heading#Using this in articles? Does it comply with the MOS in article space? but I also wanted to see if there should be an explicit mention of not using this template in MOS:GOODHEAD and WP:PSEUDOHEAD. I don't think it complies with those guidelines and I think it should be made clear that this template should not be used in articles. Thanks, - Paul/C 16:58, 18 April 2018 (UTC)
- It is really bad practice to make something out to be a heading when it's not actually marked up as a heading. It is markedly inaccessible as a result. There's probably a valid TFD to get consensus on where this template may be used (outside mainspace is probably appropriate/livable). --Izno (talk) 18:52, 18 April 2018 (UTC)