View source for Wikipedia:Manual of Style/Computing (failed proposal)

{{Failed proposal|WP:MOSCOMPOLD|date=November 2020|reason=Was not subject to any [[WP:PROPOSAL]] process.  When examined for cleanup in 2017 at [[WT:MOS]], [[Wikipedia talk:Manual of Style/Archive 197#Bring MOS:COMPUTING back into line with MoS and reality|the extensive discussion]] did not come to a consensus that this is or should be a guideline, that its content represents much more than the disputed opinions of one or two editors, nor that any of it should be imported in any form into MOS. Proposals to merge some of it into the better-accepted [[Wikipedia:WikiProject Computer science/Manual of style]] have twice (2011, 2018) met with failure.}}

This page contains style guidelines for creating and editing articles on computers, software, networking, the Internet and information technology. Other policies and guidelines should also be followed, and the general rules from the [[Wikipedia:Manual of Style|Manual of Style]] also apply.

== Trademarks ==
{{Main |Wikipedia:Manual of Style/Trademarks}}
For computer technology trademarks, adhere to Wikipedia policies and style guidelines regarding trademarks. For trademarks in all capital letters or all small letters, use an initial capital letter, as is standard with proper nouns in English. For example, [[Unix]] instead of UNIX. There is no reason to explain this in the body of each article.

== Avoid common mistakes ==
Keep in mind [[Wikipedia:What Wikipedia is not|what Wikipedia is not]]. Since it is not a dictionary, each term or product does not always get its own article. Often, they are combined into topics that can be the subject of a single high quality encyclopedia article.

=== Product directory===
An article about a product should include a history of its development and major improvements. But, in the spirit of Wikipedia not being [[Wikipedia:What Wikipedia is not#Wikipedia is not a directory|a directory]] nor [[WP:INDISCRIMINATE|indiscriminate]], avoid a complete step-by-step record of every release or update. Common sense must be applied with regard to the level of detail to be included.

Avoid just pasting lists of features into the article, since they can become dated or removed as advertisement or copyright violations. Avoid [[WP:RELTIME|relative time references]] (such as "currently", "lately" or "now").

=== Version versus product name ===
Each software product version must be referred to with [[Wikipedia:Article titles#Common names|the most common name]].

Software vendors often use one of the following approaches to refer to a specific version of a software product: 
# They include the version number in their reference, e.g. '''WinRAR 4''', '''WinRAR version 3''' and '''WinRAR v2'''.
# They change the product name with each release, e.g. '''[[Windows Vista]]''' and '''[[Windows 7]]'''.

Video games add a twist to this scheme. Video game vendors often make sequels and prequels for their most notable products. They use numbers in their video game titles to show their relationship. For instance '''''[[Command & Conquer: Red Alert 2|Red Alert 2]]''''' and '''''[[Command & Conquer: Red Alert 3|Red Alert 3]]''''' are two distinct but related video games. However, numbers that are part of the title are not version numbers. A separate version number may still be used. For instance, '''''Red Alert 2'' v1.008''' is an updated version of ''Red Alert 2''.

Consistently use the most common product name. For example, use {{xt|Windows XP}}, not {{!xt|Windows v5.1}} or {{!xt|Windows NT v5.1}}. Do not confuse and combine these methods, e.g. never use {{!xt|''Red Alert v2''}} or {{!xt|''Red Alert version 2''}} to refer to {{xt|''Red Alert 2''}}. Do not invent novel short forms and abbreviations.

=== Service pack ===
''[[Service pack]]s'' or ''service releases'' are computer software that modify other computer software to fix their bugs or improve them. When referring to service packs, make proper distinction between ''the version of software product which is serviced via a service pack'' and the ''service pack itself''.

To refer to a service pack, write down the full name of service pack. For example:
* {{xt|Windows XP Service Pack 2}}
* {{xt|WinZip 9 Service Release 1}}

To refer to a software product updated with a service pack, write: {{bracket|Product name}} with {{bracket|Service pack name}}. For example:
* {{xt|Windows XP with Service Pack 2}}
* {{xt|WinZip 9 with Service Release 1}}

Alternatively, where applicable, you can specify the [[Software versioning|version identifier]] of the software product for conciseness. For example:
* {{xt|Windows XP SP2}}
* {{xt|WinZip 9 SR-1}}

Try to use only one of these two styles consistently throughout the entire article prose. Using both may confuse the readers with little technical knowledge as they may not understand that both forms refer to the same entity. However, if both forms are frequently used in mainstream media (as was the case with Microsoft Windows service packs), the article must introduce both and establish their relation, before consistently using one.

=== x86 versus IA-32<span class="anchor" id="X86"></span> ===

Exercise care while using the term "[[x86]]" because it can cause ambiguity. x86 is a type of [[CPU]] first developed by [[Intel]], and later by others. There are two different variations of x86 in widespread use: [[IA-32]] and [[x86-64]]. However, due to the dominance of IA-32, the term "x86" is often used to refer to IA-32 through [[metonymy]]. Therefore, these terms must be used with care.

{| class="wikitable" style="font-size:90%; min-width:570px"
|+Examples of use
! style="width:25%" | Correct use
! style="width:25%" | Incorrect use
! style="width:50%" | Notes
|-
| {{xt|"This computer program runs on IA-32 or x86-64."}}
| {{!xt|"This computer program runs on x86 or x86-64."}}
| Because x86-64 is one of the x86 variants, writing "x86 or x86-64" is at best redundant.
|-
| {{xt|"This computer program runs on IA-32 but not x86-64."}}
| {{!xt|"This computer program runs on x86 but not x86-64."}}
| Because x86-64 ''is'' x86, "x86 but not x86-64" is self-contradictory. 
|-
| {{xt|"This computer program runs on x86, ARM and PowerPC"}}
| {{!xt|"This computer program runs on x86"}}
| x86, ARM and PowerPC are incompatible (mutually exclusive) CPU architectures, hence comparing them at cross-architecture (macroscopic) level is correct, even though the accuracy might not be sufficient in the more technical contexts. But, because "x86" alone is ambiguous, it must not be used without additional qualifiers.
|}

=== 32-bit and 64-bit ===
Do not use the terms "[[32-bit]]", "[[64-bit]]" or other such terms of bit lengths to refer to computer, CPU or software architectures. These terms are too vague and can cause a lot of ambiguity or misinformation.

These terms are often used to refer to two well-known CPU architecture types: [[IA-32]] (a 32-bit variant of [[x86]]) and [[x64]] (a 64-bit variant of x86). However, neither is IA-32 the only 32-bit CPU architecture, nor is x64 the only 64-bit CPU architecture.

Example of correct usage:
*{{xt|"This software application only runs on x64 CPUs."}}
*{{xt|"The IA-64 edition of this product [...]"}}
*{{xt|"The .z80 build created specifically for Zilog Z80 and compatible CPUs [...]"}}

Examples of incorrect usage:
*{{!xt|"This software application only runs on 64-bit CPUs."}}
*{{!xt|"The 32-bit edition of this product [...]"}}

=== Linux vs. GNU/Linux <span class="anchor" id="LINUX"></span> ===
{{See also|Talk:Linux/Archive 41#Page move: GNU/Linux|Talk:Linux/Referring to this article}}

Use "[[Linux]]" instead of "GNU/Linux" to refer to the family of operating systems based on the [[Linux kernel]]. The term "GNU/Linux" may still be written as part of the proper names of individual operating systems and [[Linux distribution]]s.

The [[GNU/Linux naming controversy]] does exist, and "GNU/Linux" is a name advocated by the [[Free Software Foundation]] (FSF). Wikipedia, however, prefers the [[WP:COMMONNAME|name that is most commonly used]] (as determined by its prevalence in [[WP:RS|reliable English-language sources]]). The consensus of discussions in [[Talk:Linux/Name]] is that the point of view of the FSF is not the common English-language usage.

=== Oft-neglected sources ===
{{Main|Wikipedia:Verifiability|Wikipedia:Identifying reliable sources}}
In Wikipedia, everything needs sources, including but not limited to software release dates, software package sizes, name and number of supported languages and the programming languages used to develop software products. Avoid any unreferenced assertions, including but not limited to "multilingual", "written in C++" or "developed for Windows".

=== Collocation ===
Avoid using strange forms of language. On the contrary, editors must stick to the most commonly used forms to make sure the readers feel at home. Do not use synonyms of a certain words just because they are synonyms; [[English collocations|collocation]] is very important.

For instance:
# Computer programs that are no longer developed are called {{xt|"abandonware"}}. Do not use {{!xt|"forgottenware"}} or such novel terms. (See [[abandonware]])
# The act of ceasing development of a software product is called {{xt|"discontinuation"}}. Do not use {{!xt|"abandonment"}} or similar alien terms. (See [[software release cycle]] and [[end-of-life (product)]])
# Computer programs {{xt|run on}} a certain operating system or platform. Do not use "{{!xt|run under}}" or "{{!xt|run beneath}}".
# Computer programs run {{xt|in context}} or {{xt|within the context}} of a [[user account]]. Do not use "{{!xt|under}}", "{{!xt|beneath}}", "{{!xt|on}}", "{{!xt|inside}}" or "{{!xt|over}}". While these variations may be okay in informal speech, [[Wikipedia:Featured article criteria]] demands the use of professional style.
# "{{xt|Log on}}", "{{xt|Log in}}" and "{{xt|Sign in}}" are all verbs that mean to "supply credentials for authentication". However, users either "{{xt|log on to their computers}}" or "{{xt|log in to their computers}}". They never "{{!xt|sign in to their computers}}". "Sign in" is only used for the authentication over the Internet.{{efn|For the first time, [[Windows 8]] has used "sign in" instead of "log in" but as of October 2012, this exception has remained a negligible minority.}} (See [[login]])
# "{{xt|Disc}}" and "{{xt|disk}}" both refer to digital storage media. However, "disc" collocates with [[optical disc|optical media]] as in {{xt|Compact Disc}} and {{xt|Blu-ray Disc}}, while "disk" collocates with [[magnetic media]] as in {{xt|hard disk}} and {{xt|floppy disk}}.

=== Tense <span class="anchor" id="TENSE"></span> ===

{{See also|Wikipedia:Manual of Style#Verb tense}}

Always use present tense for verbs that describe genres, types and classes, even if the subject of the description (e.g. program, library, device) no longer exists, is discontinued or is unsupported/unmaintained.

The following example is incorrect:
* {{!xt|TrueCrypt was a disk encryption program, released by TrueCrypt Foundation.}}

This sentence suggests that TrueCrypt is not a disk encryption program, although it once was. (Assume TrueCrypt has never changed its nature during its development lifecycle.) [[Grammatical deletion]] hides the fact that there are two "to be" verbs in this sentence; the more elusive fact, however, is that these two "to be" verbs are grammatically different: The first is a [[stative verb]] that does not change throughout its duration while the second is a [[dynamic verb]] which may cease to be valid after a duration when [[End-of-life (product)|discontinuation]] occurs.

Use either of the following, whichever is more appropriate:
* {{xt|TrueCrypt is a discontinued disk encryption program. It was released by TrueCrypt Foundation.}}
* {{xt|TrueCrypt is a disk encryption program, released by TrueCrypt Foundation.}}

== Optional styles ==
{{See also|MOS:STABILITY}}
The [[Wikipedia:Arbitration Committee|Arbitration Committee]] has ruled that editors should not change an article from one guideline-defined style to another without a substantial reason unrelated to mere choice of style. Revert-warring over optional styles is unacceptable.{{efn|See {{section link|Wikipedia:Requests for arbitration/Jguk|Principles}}, {{section link|Wikipedia:Requests for arbitration/jguk 2|Principles}} and {{section link|Wikipedia:Requests for arbitration/Sortan|Principles}}}} Where there is disagreement over which of the styles to use in an article, maintain [[status quo]].

Hence, avoid disputes over:
* Choosing one of the many synonyms for a concept, e.g. "shareware", "trialware" or other synonyms; "x64" or "x86-64"; "proprietary software" or "closed-source"
* Using one word or many words for the same concept, e.g. "x86" or "IA-32 and x64"
* Ascending or descending sort order
* Inserting one of the multiple URLs that all point to the same place and none has any advantage over the other
* Any other multiple forms of the same thing

== Screenshots of software ==
{{Main|Wikipedia:Software screenshots
}}

== Command-line elements <span class="anchor" id="Command-line examples"></span> ==
<!-- This Anchor tag serves to provide a permanent target for incoming section links. Do not move it out of the section heading, even though it disrupts edit summary generation (you can manually fix the edit summary before you save your changes). Do not modify it, even if you modify the section title. It is always best to anchor an old section header that has been changed so that links to it won't be broken. See [[Template:Anchor]] for details. (This text: [[Template:Anchor comment]]) -->
This section outlines the guideline for incorporating elements of [[terminal emulator|terminals]] or [[command-line interpreter]]s into Wikipedia articles, including syntax of [[Operating system shell|shell]] commands or [[Computer program|programs]].

===General guidelines===
*When providing command-line examples or discussing command-line elements, maintain clarity and simplicity.
*Command-line elements should be presented in a [[monospaced font]]. For inline references, use {{tag|code}} tag pair. In case of presenting multiple lines of command-line code, either prefix each line with a space character or enclose them all in a {{tag|pre}} tag pair.
*Avoid referencing [[environment variable]]s, dates, [[working directory|working directories]], [[username]]s, and [[hostname]]s unless they are relevant in the example.
*Adhere to the following terminology:
**An ''[[Command-line option|option]]'' or ''switch'' is something that modifies the general behavior of the command.
**A ''parameter'' is a specific value, such as a file name or host name.
**An ''[[Command-line argument|argument]]'' is any set of characters that follow a command name, including both options and parameters. See {{section link|Parameter (computing)|Parameters and arguments}}.
*When presenting arguments, maintain simplicity; specify them only when necessary and with clear explanations. Remember that Wikipedia is not a substitute for [[Unix manual|manual pages]]. Do not document the entire list of options associated with a command unless such descriptiveness has [[WP:NOT|encyclopedic purpose]].
*Identify parameter placeholders with logical names in italics. These names should not contain spaces, as spaces are used to separate multiple arguments on the command line. The following are some examples:
**<code>(prompt) command ''parameter-name''</code>
**<code>(prompt) command ''ParameterName''</code>
**<code>(prompt) command ''parameter_name''</code>
**<code>(prompt) command ''parametername''</code>
*Enclose optional arguments with square brackets: [ and ].
*Specify repeating parameters using one of the following styles:
**<code>(prompt) command ''parameter0'' [.. ''parameterN'']</code>
**<code>(prompt) command [''parameter'' ...]</code>
*Zealously maintain consistency in applying optional styles explained above for the entire article.

===Platform-specific guidelines===
====Microsoft Windows====
The most common desktop operating system in use today is [[Microsoft Windows]], whose command-line syntax has once been based on that of [[MS-DOS]] and [[OS/2]]; with the increasing popularity of [[Windows PowerShell]], however, the style has moved towards that of Unix-like systems and programming languages. As such, stick to the [[#DOS|DOS and OS/2 guideline]]s for command-line elements and examples of [[CMD.EXE|Command Prompt]] and [[Recovery Console]]. In case of the Windows PowerShell, however, adhere to the [[#Unix|Unix-like systems and Windows PowerShell guideline]]s below.

====CP/M, DOS and OS/2====
{{anchor|CP/M|DOS|OS/2}}
The following additional guidelines are for command-line examples of the [[CP/M]], [[DOS]] and [[OS/2]] families of operating systems:
*Write the names of internal or external commands, file and directory names (for as long as they fit into the [[8.3 filename|8.3]] scheme) and [[environment variable]] names in all upper-case letters (such as <code>DIR</code>, <code>AUTOEXEC.BAT</code> or <code>%PROMPT%</code>).
**'''Note:''' As mentioned at the beginning of this section, this rule applies to command-line examples only. For the use of capital letters in the rest of the prose and in the article title, see {{section link|Wikipedia:Manual of Style/Capital letters|All caps}} and {{section link|Wikipedia:Article titles|Use commonly recognizable names}}.
*While in principle DOS and OS/2 (and Windows) support both [[backslash]] (<code>\</code>) and [[forward slash ]](<code>/</code>) as a separator for directories, some programs (including most shells in their default configuration) support only the backslash. Therefore, use the backslash in examples of directory paths on local volumes unless it is important to indicate otherwise.
*Various DOS systems support a user-configurable [[SwitChar]] (typically either a forward slash (<code>/</code>) or a [[hyphen-minus]] (<code>-</code>)), but not all programs adhere to it. Therefore, if the program supports it, use the default <code>/</code> in examples, unless it is important to indicate otherwise.
*Standard options (of the form <code>/C</code> or <code>-C</code>, where <code>C</code> is some character) should also be upper-case, unless they are case-sensitive.
*Contrast program names against [[Shell builtin|built-in]] command names by appending their [[file extension]]. If a program is not included with certain versions (such as <code>[[XCOPY.EXE]]</code> or <code>[[EDIT.COM]]</code>), then the versions for which it is known to be included should be indicated.

====Unix-like systems and Windows PowerShell====
{{anchor|Unix|PowerShell}}
* [[Shell builtin]] commands and [[cmdlet]]s (such as {{Mono|[[cd (command)|cd]]}} and {{Mono|[[history (Unix)|history]]}}) should be indicated as such.
* Avoid shell-specific commands or utilities (such as the [[for loop|{{Mono|for}} loop]] or certain stream behaviors) whenever possible, because of the great variation in shells across Unix-like systems. If a shell-specific sequence is required for proper explanation, provide an example for the [[ALGOL]]-like shells ([[Bourne shell]], [[Korn shell]], and [[Bash (Unix shell)|Bash]]) as well as one for the [[C (programming language)|C]]-like syntax of [[C shell]] and [[tcsh]].
* Adhere to case-sensitivity requirements of the shell. The names of most commands on Unix-like systems are entirely in lower-case characters while the shell and operating environment are both case-sensitive. Windows PowerShell is not case-sensitive; so write cmdlet names in their natural English form to ease reading and memorizing. Write Unix-derived aliases (such as {{Mono|ls}} and {{Mono|cp}}) in lowercase. Use the [[Template:Lowercase title|Lowercase title]] or [[Template:Wrongtitle|Wrongtitle]] template when necessary.
* Differentiate commands that normally require [[Privilege (computing)|privileged access]] from those that do not require it.
* In some cases, the value of a parameter will commonly contain shell [[metacharacter]]s. In these cases, it may be wise to specify [[Quoting (shell)|quoting]] in the example to prevent users from receiving errors that to them will seem strange and unrelated.
* Always specify the minimum (and, if applicable, the maximum) version number of the shell that supports the command. Linux (owing to its open-source nature) and Windows PowerShell may introduce new commands at any time.

===Providing sample output===
It may often be useful to provide a sample of the output that a command generates. In these cases, the full command and all arguments as they were typed are given. The output of the command will therefore be specific to environment and other variables. The tags {{tag|pre}}, {{tag|nowiki}} and {{tag|SyntaxHighlight}} (with proper arguments) prevent conflicts with the wiki markup syntax.

===Examples of usage===

====DOS examples====
The {{Mono|[[dir (command)|DIR]]}} built-in command on DOS, which lists files and directories:
 > DIR [''options''] [''pattern'' ...]

The program {{Mono|MOVE.EXE}} on MS-DOS, whose behavior had to be emulated prior to its introduction:
 > MOVE.EXE ''source'' ''target''

====Unix examples====
The {{Mono|[[ls]]}} command on Unix-like systems, which lists files and directories:
 $ ls [''options''] [''file'' ...]

The {{Mono|[[mkfs]]}} command, which creates new file systems. It usually requires privileged access, so the [[Command prompt|prompt character]] is {{code|#}} instead of {{code|$}}
 # mkfs [-t ''fstype''] [''fs-options''] ''device''

The {{Mono|[[wget]]}} program, one of the [[GNU]] utilities, which retrieves files given a [[Uniform Resource Identifier]] (URI). URIs can sometimes contain shell meta-characters, and so the parameter is usually quoted to prevent errors.
 $ wget [''options''] "''URI''"

The {{Mono|if}} built-in structure, whose syntax varies. In Bourne shell, Korn shell and Bash:
 $ if ''command'' ; then ''command'' ; ... ; fi

In C shell and {{Mono|tcsh}}:
 % if (''expression'') then ''command'' ; ... ; endif

Sample output of the {{Mono|[[Df (Unix)|df]]}} command, which lists disk space usage on mounted [[file system]]s:
<syntaxhighlight lang="console">
$ df -P
Filesystem          512-blocks      Used Available Capacity Mounted on
/dev/hda2             39331760   7398904  29834768      20% /
</syntaxhighlight>

== License ==
Try to specify the licensing terms of the subject of a computer program article accurately and concisely.

License agreements usually specify one or more of the following:
# '''Environment''' of use (e.g. commercial, non-commercial, personal, educational, non-military, etc.)
# '''Cost of use''' (e.g. free of charge, one-time payment, subscription-based, etc.)
# '''Applicable licensees''' (e.g. unrestricted, one computer, one user account of a computer, one user, volume licensing, etc.)
# '''Other rights''' (e.g. the right to study, modify, reverse-engineer, etc.) or restrictions (e.g. of use for producing pornographic contents)

Wikipedia has articles about the most common software licensing schemes. Therefore, most of the times, one or two wikilinked words in the infobox can describe the licensing scheme. For instance [[GPL]], [[Freemium]], [[BSD license]] or [[Proprietary software|Proprietary]] [[commercial software]] <small>(Write: <nowiki>[[Proprietary software|Proprietary]] [[commercial software]]</nowiki>)</small>. Avoid vague or outright non-informative phrases like {{!xt|"''Vendor''’s EULA"}}, {{!xt|"Multiple"}} and {{!xt|"Unknown"}}.

== Website addresses <span class="anchor" id="WEBADDR"></span> ==
{{See also|Wikipedia:Manual of Style/Linking}}

=== Exposed URLs ===
Certain areas of Wikipedia such as infoboxes require [[URL|website addresses (URL)]] to be exposed in print. To maintain readability and conciseness, certain parts of the web addresses may need to be hidden or their shorter forms used.

A web address consists of several parts, with the following examples showing some of the most commonly seen ones:

{| class="wikitable" style="margin:auto"
! scope="col" | Scheme
! scope="col" | Fully qualified domain name (FQDN)
! scope="col" | Request
|-
| <code>http://</code>
| <code>www.wikimedia.org</code>
| <code>/</code>
|-
| <code>http://</code>
| <code>windows.microsoft.com</code>
| <code>/en-US/internet-explorer/products/ie/home</code>
|-
| <code>https://</code>
| <code>commons.wikimedia.org</code>
| <code>/wiki/Main_Page</code>
|}

However, the reader does not need to see all of these somewhat unappealing and hard-to-remember items, thanks to the web browsers and web servers' ability to infer them. Often, the following parts can be omitted:

# '''Scheme''': Omit <code>http://</code> in the displayed URL but not in the underlying link; the {{tlx|URL}} template hides this scheme automatically. Other schemes like <code>https://</code> and <code>ftp://</code> need to stay.
# '''Request''': When the request part is only a single slash character (<code>/</code>), omit it; the {{txl|URL}} template hides this automatically. Users often omit the single slash character as the only request specification and expect the URL to work properly.

The omission is only sanctioned when the functionality is undeterred. Always test the resulting URL. In the rare cases that <code>www.</code> or <code>/</code> are required, it is recommended to leave an invisible wiki-markup comment to notify future editors.

If the target website provider has provided shorter alternative URLs to the webpage, use them. The only exception to this instance are short URLs that use hard-to-remember numbers. For instance:
{| class="wikitable" style="margin:auto;"
! scope="col" | When the following are valid...
! scope="col" | ...avoid the following
|-
| {{xt|microsoft.com/ie}}
| {{!xt|windows.microsoft.com/en-US/internet-explorer/products/ie/home}}
|-
| {{xt|<nowiki>https://commons.wikimedia.org/</nowiki>}}
| {{!xt|<nowiki>https://commons.wikimedia.org/wiki/Main_Page</nowiki>}}
|-
| {{xt|beautyoftheweb.com}}
| {{!xt|1=go.microsoft.com/fwlink/?LinkId=214371}}
|}
Do not use [[URL shortening]] services such as [[bit.ly]]. Such URLs are maintained by independent entities and are susceptible to [[Wikipedia:Link rot|link rot]]. {{crossref-print|(See also: {{section link|URL shortening|Shortcomings}})}}

=== Choosing between HTTP and HTTPS ===
In the event that the linked website serves contents over both [[HTTP]] and [[HTTPS]] protocols, i.e. it accepts URLs with both <code>http://</code> and <code>https://</code> schemes, observe the following:{{efn|The original discussion can be found in {{section link|Wikipedia:Village pump (policy)/Archive 111|As WP uses HTTPS, should (some) external links, too?}}}}
* Use <code>https://</code> scheme for sites that only serve contents over HTTPS, or which support both HTTPS and HTTP. This also includes websites that do accept <code>http://</code> addresses but redirect them to <code>https://</code>.
* Use <code>http://</code> scheme for sites that do not support HTTPS at all.
* Wikipedia formerly used [[WP:PRURL|protocol relative links]] for sites that support both HTTP and HTTPS (for example: {{mxt|//example.com/}} instead of either {{!mxt|<nowiki>https://example.com/</nowiki>}} or {{!mxt|<nowiki>http://example.com/</nowiki>}}).  However, as Wikipedia itself now requires HTTPS, this is now deprecated.

== See also ==
* [[Wikipedia:WikiProject Computer science/Manual of style (computer science)|WikiProject Computer science/Manual of style]] (draft)
* {{section link|Wikipedia:Manual of Style/Dates and numbers|Non-base-10 notations}}

== Notes ==
{{Notelist}}
{{style wide}}
[[Category:Wikipedia style guideline proposals]]