Spelling
This section contains rules and guidelines about spelling,
grammar and writing style.
(B1) No spelling, grammar or
markup errors
No document that is visible to the public or the members
should contain any spelling, grammar or markup errors, unless
the error is on purpose or the text is clearly marked as not
having been written by W3C staff. We want to show we are
capable of quality, even in details and even in pages that
have temporary content and are expected to be updated soon.
After writing a page, take a break (as long a break as
possible) and then carefully reread what you wrote. Always
use a spell checker and a validator. If possible, ask a
colleague to copy-edit the page. (See also ‘content review’.)
To validate the markup, you can use the online markup validator
(also available as a comma tool on our main site: add
‘,validate’ after the URL) or a local validating parser:
- opensp (command-line checker for HTML4, XHTML, and some
XML-based formats),
- xmllint (command line checker for XHTML and other
XML-based formats),
- nxml-mode in Emacs (text editor for XHTML and XML-based
formats),
- other validating XML editors (Oxygen, XMLSpy, XMetal,
etc.) or
- BlueGriffon (WYSIWYG editor for HTML4, HTML5 and
XHTML1).
If you wrote any CSS, validate that, too, with the CSS validation
service.
[Can we restart the weekly service
that reported to <w3t@w3.org> the 25 invalid pages on our
site that were most popular during that week?]
(B3) Quote marks
The recommended quote marks in English text are the left
and right single quotes: ‘’. They are sufficient
to quote a word and don't take up much space. Nested quotes
get left and right double quotes: “”. If those are
too difficult to type, you can use ASCII straight double
quotes at the first level ("") and ASCII apostrophes at the
second (''). Or use the SGML/XML character entities: ‘’ (‘’) and “” (“”).
(B4) Punctuation around quote
marks
When punctuation (comma, period, semicolon, colon, question
mark, exclamation mark) follows a word or a phrase in quotes,
the punctuation is put after the closing quote:
A meeting, also called a ‘ftf’, may be held.
Are all documents ‘resources’?
But when the quoted phrase itself ends with an exclamation mark (!) or question mark (?),
that exclamation mark or question mark is inside the quotes:
A company called ‘Yahoo!’ was one of them.
That piece was called ‘Why?’.
If a complete sentence that originally ended with a period
is quoted, it loses its period:
The last sentence, ‘The focus is on privacy’, was
underlined.
Didn't it say ‘This is a draft’?
The exception is if a sentence that ends with a period is
quoted at the end of a sentence that would also end with a
period. Then the period inside the quotes is kept and it is
the one after the quotes that is omitted:
The last sentence is: ‘The focus is on privacy.’
[The last two rules are hard to read.
Need a rewrite.]
(B5) Lowercase headings
Do not Capitalize Every Word In A Heading, as you find in
American newspapers. Making the text bold or a little bigger
is enough to make it stand out. Without the capitals, the
text is easier to read, especially for people not used to
American newspapers. (The tradition to capitalize words dates
from the days when newspapers were set with lead type and
printers didn't have a lot of different sizes. The use of
capitals made the text look a bit bigger.)
Also do not write headings in all-caps. ALL-CAPS MAKES THE
TEXT SLOWER TO READ, AS YOU CAN SEE HERE. And it is
especially difficult for people with reading difficulties or
low vision.
(B6) Capitalized words
Here is a list of words to write with an initial capital
letter:
- Web (as in: ‘the Web’)
- Internet (as in: ‘the Internet’)
- Advisory Board
- Advisory Committee
Here is a list of words to write, in general, without an initial capital letter:
- web (in combinations: web page, web browser, etc.)
- internet (in combinations: internet age, internet
connection, etc.)
- home page
- pubrules
- working group
- interest group
- open source
(B7) Names of W3C
technologies
Write acronyms and abbreviations of W3C technologies as
they are written in the corresponding specifications (e.g.,
‘SMIL’, ‘WebRTC’ and ‘HTML’, not ‘S.M.I.L.’, ‘Web-RTC’ and
‘H.T.M.L.’)
(B8) Acronyms and
abbreviations
Unless they are very well-known (e.g., because they are in
everyday English, such as ‘e.g.’ or ‘viz.’), abbreviations
and acronyms should be marked up with an abbr element that
contains the expansion, at least the first time they appear
on a page. If possible, there should also be a hyperlink to a
page describing the meaning. E.g.:
<a
href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol"
><abbr title="Transmission Control Protocol"
>TCP</abbr></a>
(B9) Reader vs user
To refer to the people or agents reading our pages, use
either ‘user’ or ‘reader’, but if there is any possibilty of
confusion with other kinds of users (e.g., ‘users of HTML’,
who aren't readers, but authors; or ‘users of CSS’, who
aren't readers either, but designers), then use ‘reader’.
(B10) Cell vs mobile
Prefer ‘mobile phone’ over ‘cell phone’ (even though the
latter is American English and the former British English),
because our related activities are known as the ‘Mobile Web
Initiative’, ‘Mobile Web best Practices’, ‘Mobile
Accessibility‘, etc.
(B11) ‘a’ vs ‘an’
Use ‘a’ before an abbreviation if the pronunciation starts
with a consonant. Use ‘an’ if it starts with a vowel: an HTML page (aitch-tee-em-el), an XML
document (ex-em-el), a W3C workshop
(double-you-three-see), a CSS rule (see-es-es),
a REC (rec), an SVG graphic
(es-vee-gee), a WG (double-you-gee), an
IG (aye-gee), an AC meeting (ai-see), a
TPAC registration (tee-pack).
(B12) Plural s
Plurals of abbreviations and acronyms get an ‘s’ without an
apostrophe: RECs, TPACs.
(B14) Collective nouns
Collective nouns are words that refer to a group of people,
but grammatically they are singular:
W3C publishes… (not: publish)
The working group meets… (not: meet)
The audience was… (not: were)
Look at IBM. It wants… (not: they)
(B15) E-words
The prefix ‘e’ (for ‘electronic’) is often attached to
nouns to indicate the digital equivalent or the digital part
of something: ebook, e-commerce, email, e-reputation,
e-wallet….
Use e-words if they are common, otherwise use a
description. They are all written with a hyphen, except email
and ebook, which we prefer without. In particular:
| E-word |
Use instead: |
| e-book |
ebook (preferred) |
| e-business |
online business |
| e-commerce |
- |
| e-government |
- |
| e-learning |
- |
| e-mail |
email (preferred) |
| e-marketing |
online advertising |
| e-reputation |
online reputation, reputation |
| e-tailer |
online shop |
| e-wallet |
digital wallet |
| e-zine |
online magazine |
(B16) Cyberwords
A similar prefix to ‘e-’ is
‘cyber’: cybercrime, cyberattack, cybercafé, cyperspace, etc.
It is always written without a hyphen.
As of 2018, many technical people see ‘cyber’ as a word
used by politicians, where an engineer would rather put
‘online’, ‘digital’, ‘Internet’, ‘network’, ‘web’ or some
such. So be careful who your audience is: ‘Cyber’ is useful
when talking to policy makers, but better avoided when
talking to programmers.
(B17) Em dash and en dash
A long dash can be used as an alternative for a comma or
parenthesis. The Dutch name for it – gedachtenstreepje, literally ‘thought dash’ – is
evocative of its function.
The tradition in American English is to use the em dash
(‘—’ or —) with no spaces around it—like this.
However, I (Bert) think this looks ugly. It connects words
that do not normally form a compound. So I suggest we use in
this case the British custom of using the shorter en dash
instead (‘–’ or –), which is used with
spaces – like this. In fact, Robert Bringhurst (in The elements of typographical
style, version 2.5, 2002) agrees with me.
(B18) En dash for ranges
The en dash is also used, in both traditions, to indicate a
range of numbers, times or dates, in this case without spaces. E.g.: 14 August–5 September, levels
7–10, 14:00–14:30.
If for some reason it is too difficult to type an en dash,
use an ASCII hyphen-minus (-).
(B19) Ellipsis
An ellipsis (…) normally indicates that something is
omitted, but can also be used as a short pause, when a comma,
semicolon, en dash, period
or paragraph break is not enough.
If you are sure the text will be rendered in a monospace
font, use three dots with no spaces in between (like
this...), otherwise use an ellipsis character (‘…’ or
…).
This differs from what The Chicago Manual of Style
recommends. It makes an ellipsis out of three periods with
spaces before, after and in between ( . . . ). But, with Bringhurst (cited above), we
think that makes the ellipsis much wider than needed. The
ellipsis character, in most fonts, has tighter spacing, while
still being clearly visible. It is used with no space before
it and one space after it, except at the start of a sentence,
where it has a space before and no space after. (Mathematics
has its own rules, but usually there is no space on either
side.)
When the ellipsis indicates that something is omitted, it
should not be preceded by ‘for example’ and not be followed
by ‘etc.’, because that would be redundant:
Use any element: A, EM, VAR…
Use any element, e.g., A, EM or VAR.
Use any element: A, EM, VAR, etc.
When omitting something from a quotation, enclose the
ellipsis in square brackets. E.g.:
In her book on the ellipsis […] Anne Toner suggests that
the first use of the punctuation in the English language
dates to […] 1588. – Wikipedia
If an ellipsis occurs at the end of a sentence, omit the
period that would normally end the sentence.
(B20) Compound modifier
When an adverb or a noun precedes an adjective in a noun
phrase, check carefully if the two shouldn't be connected
with a hyphen to make the meaning clear. Some examples
(stolen from Wikipedia):
- ‘Man-eating shark’ (as opposed to ‘man eating shark’,
which could be interpreted as a man eating the meat of a
shark)
- ‘Wild-goose chase’ (as opposed to ‘wild goose chase’,
which could be interpreted as a goose chase that is out of
control)
- ‘Long-term contract’ (as opposed to ‘long term
contract’, which could be interpreted as a long contract
about a term)
- ‘Zero-liability protection’ (as opposed to ‘zero
liability protection’, which could be interpreted as there
being no liability protection)
(B21) He/she
[This section needs more input. There
are people who claim the second example below sounds correct
to their ears and some even say the first sounds incorrect.
Make a different recommendation? Make no
recommendation?]
[There are people who want to be
referred to neither as a man nor as a woman. At this point in
time that seems to be rare enough that we don't need any
rules.]
When you rewrite a sentence because you want to avoid the
words ‘he’, ‘him’ and ‘his’, make sure the result is
grammatical. E.g.:
‘Each user creates his own profile.’ (Correct.)
* ‘Each user creates their own profile.’ (Incorrect, user
is singular.)
* ‘Each user creates her own profile.’ (Incorrect, you
don't know if the user is female.)
‘All users create their own profile.’ (Correct, use
plural throughout.)
‘Each user creates an individual profile.’ (Correct,
avoids pronouns.)
When inventing personas to explain a process and their
gender is not important, it is good style to alternate male
and female names. E.g., cryptographers traditionally use
Alice (the sender of a message), Bob (the receiver) and Eve
(the evil party or the eavesdropper).
(B22) Smileys
Avoid smileys and other emoticons on web pages. Restrict
their use to informal written conversations only. If you do
use one on a web page, use the corresponding Unicode
character, not the ASCII transcription:
| ASCII |
Character |
HTML |
:-) |
☺ |
☺ |
:-( |
☹ |
☹ |
;-) |
😉 |
😉 |
:-\ |
😕 |
😕 |
:-O |
😃 |
😃 |
(B23) Numbers
Numbers up to twelve inside a sentence are normally written
with letters: ‘I wrote three pages in two hours.’ Larger
numbers use digits: ‘There are more than 2000 lines.’ If a
sentence has both large and small numbers, use digits for
all: ‘There are 2 rooms for 80 people each.’ Avoid to start a
sentence with digits. Rewrite the sentence or use letters
instead.
Numbers with units are
always written with digits: 2 km, 9%, 5 GB.
The thousands separator in English is the comma. It can be
omitted for numbers below 10,000, especially if there are no
higher numbers in the same text. But it is recommended for
other numbers: 2000 or 2,000, 7500 or 7,500, 17,500,
1,000,000, 375,300.
Years and page numbers are always written without a
thousands separator: the year 2018, on page 1073.
(B24) Numbers with units
Try to put a ‘narrow no-break space’ ( ) between
a number and its unit. It is easier to read 50 m than
50m and 50 m is too wide. If you can't type the narrow space,
use at least a ‘no-break space’ ( ), to avoid a line
break after the number.
However, when writing about CSS it is probably better to
omit the space, because that is how dimensions are written in
a style sheet: 5px, 3.7em
There is no space before percent signs: 25%, 100%
Currency symbols come before the number, without
a space: $20, ¥4500. (If you are using ambiguous signs, such
as $, make sure the context makes it clear which country is
meant, or make it explicit: US$20.) When using the currency
abbreviation instead of the symbol, there should be a
no-break space between it and the number: USD 20, EUR 5.50.
Units do not get a period nor a plural ‘s’: a
5 MB. file, the file is 5 MBs.
(B25) kB, kb, MB, MiB…
Lowercase b is for bit, uppercase B is for byte (eight
bits). The prefixes k, M, G, etc. stand for kilo, mega, giga,
etc. (see the table below) and represent 1,000, 1,000,000,
1,000,000,000, etc.
When followed by a lowercase i, they represent powers of
1,024 instead: 1,024, 1,048,576, 1,073,741,824, etc.
| Decimal |
Binary |
| Symbol |
Name |
Value |
Symbol |
Name |
Value |
| kB |
kilobyte |
1000 |
kiB |
kibibyte |
1024 |
| MB |
megabyte |
10002 |
MiB |
mebibyte |
10242 |
| GB |
gigabyte |
10003 |
GiB |
gibibyte |
10243 |
| TB |
terabyte |
10004 |
TiB |
tebibyte |
10244 |
| PB |
petabyte |
10005 |
PiB |
pebibyte |
10245 |
Note that there are no dots: not ‘5 G.B.’ but
‘5 GB’.
(B26) Electronic addresses
To make email addresses and URLs easier to copy, avoid
putting a comma or period after them. Rewrite the sentence or
enclose the address in angle brackets:
<webmaster@w3.org>.
(B27) Pixels
A pixel (from ‘picture element’) is the
smallest dot a bitmap screen can show. But there are screens
now that can show very small dots, sometimes more than 300
per inch. So in many cases, when people talk about a pixel,
they mean in fact the CSS pixel (called ‘px’), which
corresponds to a visual angle: the effect on the eye of a dot
of 1/96th of an inch (about 0.26 mm) on a desktop
computer screen viewed from a normal viewing distance. (Which
is how a pixel looked on an average monitor in the 1990's.)
When HTML refers to a size in pixels, it means the size in
px. (For example in images: <img src=...
width=350> indicates the image is meant to be
350 px wide.) When a browser displays a raster image
(such as JPEG or PNG), it maps one image pixel to one px,
even if that means it occupies in reality four, nine or even
more actual pixels on the screen.
So, when talking about pixels, check if there is
possibility of confusion and, if so, clarify whether you are
talking about hardware pixels or the visual size.
(B28) That vs which
In American English, the relative pronoun ‘that’ is used to
identify an object:
The cable that is on my desk is too short
(There are several cables, but this sentence only talks
about the cable on the desk.) The relative pronoun ‘which’ is
used to give information that is not essential for
identification:
The cable, which is on my desk, is too short.
(You can omit the ‘which’ phrase and it is still clear
which cable is meant.)
There is a comma before ‘which’, but not before ‘that'.
In British English, you can use ‘that’ instead of ‘which’
and it is the comma that determines whether the phrase
identifies something or can be omitted: ‘The cable, that is
on my desk, is too short.’
To avoid confusion for people used to American English, it
is recommended to use the American convention.
(B29) Citing titles
Put the title of a ‘larger’ work (a book, a film, a
journal, a work of art, etc.) in italics. Put the title of a
smaller work (an article, a chapter, a report, etc.) in quote
marks:
He played in Hamlet.
See the section ‘Type Field’ in ‘Tags for Identifying
Languages’.
Did you see the elephant in Gone with the
wind?
Note that the full stop (.) after ‘Hamlet’ and the question
mark (?) after ‘wind’ are included in the italics, even
though they are not part of the title. See ‘Punctuation after bold or
italic words’.
(B30) Punctuation after bold
or italic words
If a word is followed by punctuation and you know the word
will be in bold or italics, then include the punctuation in
that style, unless that leads to ambiguities (e.g., in a code
example):
Do you call that green?
It is actually made from wood: cherry wood.
Did you type cvs up Overview.html?
Otherwise there may be too much space before the
punctuation.
(B31) It's, he's, doesn't,
can't, we've…
Contractions of ‘is' and ‘has’ to ‘'s’, and of ‘not’ to
‘n't’, generally sound less formal, closer to spoken text.
Most of our web pages should use the long form: ‘it is’,
‘it has’, ‘he is’, ‘he has’, ‘does not’, ‘cannot’, ‘we have’,
etc.
(B32) Phone numbers
Always start with a + and a country code (unless it is a
number that cannot be dialed from another country). Put
spaces between groups of digits. Try to group the digits in
the way most common for the country from which the number
comes.
In the US, it is common to group digits 3+3+4:
+1 617 555 5555 (+ for accessing an international line, 1 for
the USA, 617 for Cambridge MA, 555 5555 for the local
number).
In France, it is common to group digits in pairs:
+33 5 55 55 55 55 (+ to get an international line, 33 for
France, 5 55 55 55 55 for the local number). Note that
somebody in France could dial this number as 05 55 55 55 55,
but the international form works everywhere, including in
France.
(B33) Periods inside and
outside parentheses
When a whole sentence is inside parentheses, the final
period is also inside the parentheses:
It is available from the Web. (At least it was
yesterday.)
We use Noto Sans. (Sans means sans-serif.)
But when only part of the sentence is in parentheses, the
final period is outside:
The preferred color is #EEE (a very light gray).
You can click on it (unless it is hidden).
(B34) Punctuation in lists
If a bulleted or numbered list has (some) items that are
whole sentences, or even several sentences, then each list
item starts with a capital letter and ends with a period. For
example:
The blue process has three steps:
- Take the item and inspect it.
- Inspect it again. Maybe inspect it a third time.
- Leave it overnight.
If the list has only short items, not whole sentences, each
item starts with a capital letter and has nothing at the end,
neither a period nor a comma:
The choices are:
- Margherita
- Pepperoni
- Daily special
If such a list might be displayed inline as well in some
cases (‘The choices are: margherita, pepperoni and daily
special.’) due to a device-dependent style sheet, some
compromise, or some clever style rules, may be needed.
(B35) Chicago manual of style
[We are still looking for a good
resource that is available online without a paid
subscription.]
Except where this style guide says otherwise, apply the
recommendations of a recent Chicago manual of
style (say the 13th edition or later).
(B36) Other style guides
The conventions for writing Linux man pages include a style
guide, which also has useful rules to follow. The link in the
previous sentence goes to an online copy on the Debian site.
You can also type man 7 man-pages on any Linux
computer.
The European Union's style guide describes the structure of
various publications, language-independent conventions for writing country
names, addresses, telephone numbers, etc. and rules for writing in English.
Wikipedia's (English) Manual of Style also has many style rules that are
generally useful.
Interaction with human readers
and automated agents
This section contains rules and guidelines about metadata
(all the elements, attributes and protocol headers that inform
a reader about the type, provenance and history of a page) and
about making pages faster to load, parse and read.
(C1) Mobile
The most important pages should work well on
mobile and on devices with cumbersome interaction (smart
TVs), other pages should at least be functional.
This characteristic of pages is known under many names:
device-independence, fluid design, responsive design,
adaptive design and mobile-first. It involves layout that
adapts to different screen sizes (either by not setting
large, fixed sizes or by providing multiple styles), and
interaction that does not rely on particular input mechanisms
(a mouse, a keyboard).
For more info on making pages or web applications
mobile-friendly, see the summary of Mobile Web Best Practices or the draft of a W3C
Note on Mobile Accessibility. The quickest way to learn
how to make a page device-independent used to be to run the
W3C Mobile
Checker on it, but as of June 2019 the checker is not
running. An alternative, of course, is to find a smartphone
and a smart TV and just try it out…
[Are there other good how-to
guides?]
(C2) Print
Make sure pages print reasonably well. It is more important
for some pages (meeting agendas…) than others. But all pages
may get printed some day by somebody leaving on a trip.
If you use one of the style sheets under /StyleSheets/, the author of the
style should have taken care of it. (If your page doesn't
print well, and the style sheet's documentation doesn't
explain what to do either, file a bug report with the Comm
team.) If you write your own style sheet, make sure that the
page prints well with it, or add special style rules for
print.
[Need to find (or write) a small
tutorial on how to link to a print style sheet or add rules
for print to an existing style sheet. There is a good
resource in French, ‘Faire une feuille de style CSS print pour
l'impression’. Is there something similar in
English?]
The ‘,pdf’ comma tool
may be useful: It returns a PDF version of the page.
(C3) Screenscraping
Among W3C's goals are a Web that works in browsers and
other user agents and a Web that is semantic. And,
of course, W3C's own websites should be the best possible
examples.
Another way to say that is that W3C's websites should make
‘screenscraping’ easy. (‘Screenscraping’ is the process of
extraction of information from a page by a computer, e.g., by
a web spider or a virtual assistant, that precisely does not involve rendering the page on a screen and does
not require human eyes. I.e., it relies solely on
interpreting the text and the markup. The name comes from the
days when data produced by some old (financial) applications
was only easily available in the form of screendumps from
text terminals. Other terms are data scraping and Web
scraping.)
A consequence of the screenscraping goal is that using
embedded scripts to put content in a document (‘AJAX’) is not allowed, because links in JavaScript are
very difficult to find (the ‘halting problem‘). See ‘JavaScript’ for more on embedding scripts.
If a document contains data that originally comes from a
database or a non-HTML file (e.g., a file in XML, JSON, CSV
or RDF), then convert the data to HTML on the server side.
(C4) Section removed
[The content of this section was moved
elsewhere. The heading will be removed later.]
(C5) Raw data
On the other hand, if you have the main content of an HTML
document available in an easy-to-parse format (such as XML,
JSON or CSV), do put a link to that data in the
document, and give it a rel=alternate attribute. Anybody
planning to write a screenscraper can then extract the data
from the other format instead, with less programming.
Make sure the alternative format does indeed have the same
data. The best is to have an automatic process that ensures
it.
(C7) rel=canonical
Pages that have multiple URLs, or pages that have
essentially the same content as other pages (print version,
mobile version, single-page version vs multi-page version,
PDF version, etc.) should have a link to the URL that is
considered the ‘canonical’ version. The canonical version is
the one whose content includes the content of all the other
pages (see RFC
6596). Search engines may index that canonical page in
preference to the other pages, or list it before the other
pages.
The link to the canonical page should be a link in the head
part if it is an HTML document:
<link rel=canonical href="URL-of-canonical-document">
If the document is not HTML, but is served over HTTP, the
link should be in the HTTP headers:
Link: <URL-of-canonical-document>;
rel="canonical"
Exception: As of July 2018, the pubrules still requires the
opposite for Technical Reports. The link with rel=canonical
does not point to a document that has the same content, but
to a document that has potentially newer content. (The idea
is that this makes the latest versions appear higher in
search result, although with the risk of making text from old
drafts impossible to find.)
(C8) Author link
The name and address in the signature (see Signed) should have a machine-readable
link with rel=author:
<a rel=author
href="mailto:john.doe@w3.org%20(John%20Doe)">John
Doe</a>
or, alternatively, should be accompanied by a link with
rel=author in the head part of the document:
<link rel=author
href="mailto:john.doe@w3.org%20(John%20Doe)">
See ‘Examples of signed
pages’ for code snippets.
(C9) Photo of the author
It is recommended that the signature contains a photo of
the author, unless the page is mainly generated. This helps
give W3C a more friendly face and distinguishes us from
standards organizations whose public face is an anonymous
secretariat.
[Any idea for making generated pages
more friendly as well?.]
[Check these sizes.] The
preferred size for such a photo is 150×200 pixels (3:4 aspect
ratio), and it should be scaled to a width of 4 times the
default font size (in CSS: ‘width: 4rem’).
See ‘Examples of signed
pages’ for suggested markup.
(C10) Last-modified date
Pages should say when they were last changed and that date
should correspond closely to the HTTP Last-Modified header.
How closely depends on how often the page changes. For a
page that changes less than once a day on average, it is
probably enough if the dates are the same; the hours may be
different or omitted.
An acceptable way is to include one of the CVS keywords
$Date$ (as in the signature of this guide) or $Id$.
They produce, respectively, something like
But note that these keywords are only correctly expanded in
HTML pages that are maintained in CVS. Not in pages written
in PHP, in a wiki, in WordPress, in PlanetPlanet or otherwise
generated by a CGI program; nor in pages that are redirected
to GitHub or other external servers.
Wikis, WordPress and PlanetPlanet include dates
automatically. In PHP, consider using the function date().
The best technique for other pages will differ.
See also ‘unambiguous dates and times’.
(C11) Creation date
It is recommended that pages also say when they were first
created.
(C12) Copyright notice
At the bottom of a page, there should also be a copyright
notice with a link. That way people know where to go if they
want to republish some of our content.
That link should go to https://www.w3.org/Consortium/Legal/ipr-notice#Copyright and have an attribute rel=copyright, to make it easy to
find for robots. See ‘Examples
of signed pages’ for suggested markup.
The same link should also be in a link element in the head
part, for software that only looks for such links in the
head:
<link
href="../../Consortium/Legal/ipr-notice.html#Copyright"
rel="copyright" title="Copyright">
[Check with legal if it is recommended
to include ‘ © 2019 W3C ® (MIT, ERCIM, Keio, Beihang)’ after
the ‘Copyright’.]
(C14) Internationalization
The recommended character encoding for text documents
(including HTML) is UTF-8. But whatever encoding is used, it
should be declared explicitly in the document. Use either a
meta element like this (valid in all versions of HTML):
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
or like this (HTML5 only):
<meta charset="utf-8">
HTML documents must have a lang attribute on the html
element, and on any element that has a different language.
<html lang="en-us">
(‘en-us’ means American English; use a different language
as appropriate.) Hint: Use the i18n checker to find
(potential) problems on a page. The checker is at
https://validator.w3.org/i18n-checker/check
but the easiest way to call the checker is to append
‘,i18n’ to the URL of the document to check, e.g.:
https://www.w3.org/,i18n
(C15) Image sizes
Although you can use CSS to scale a raster image in an HTML
page to any size you like, it is recommended to scale images
down to (approximately) the right size before
putting them in a web page. That avoids that a user has to
wait for a megabyte of image to download, when the image is
only going to be displayed at a size of a few hundred pixels.
If the image may be displayed at different sizes, including
large ones, and the page is in HTML5, you can use HTML5's picture element to provide two or more different sizes
of the image, so that the larger ones only have to be
downloaded when needed. E.g.:
<picture>
<source media="(min-width: 45em)" srcset="large.jpg">
<source media="(min-width: 32em)" srcset="med.jpg">
<img src="small.jpg" alt="The wolf runs through the snow.">
</picture>
(C16) Headings and
subheadings
Use plenty of headers (h2 and h3), make them short,
descriptive and use the actual key words from the text (i.e,
not a metaphor you will only understand after you
read the section).
(C17) Shallow structure
Don't nest sections too deeply. There is no need to group
sections under a common heading if their relation is clear
enough without. Too many levels may confuse readers rather
than help them.
A rule of thumb is to use a single h1 for the page title
(see title and h1 below), and
h2 & h3 for sections & subsections. If you find
yourself needing an h4, check carefully if one of the levels
above isn't redundant, if the h4 itself shouldn't be replaced
simply by a bit of vertical space, or if the fourth level
isn't in fact a list (ol, ul, dl).
(C18) Title
Make the page title context-independent as much as
possible. Somebody who finds the title in a search engine or
in a list of bookmarks among unrelated pages should be able
to make a good guess as to what the page is about.
(C19) Title and h1
Use a single h1 element that is the same or similar to the
title element (because not all browsers make it easy to see
the title).
(C20) Speed
Hypertext is text with links that you can resolve almost
instantaneously. It should not take longer than three
seconds. If it takes longer, it feels like an old-fashioned
book. You can follow the links in a book, but not quickly:
you need to go to your bookcase, to a library, to an book
shop…
Of course, the network conditions and the user's computer
have some influence on the speed with which a link is
resolved, but do try to keep documents small (no redundant
markup), with small style sheets and small images.
Speed can also suffer if the server has to do a lot of
work, in particular if it has to generate the document on the
fly (e.g., with PHP). If the document isn't very
dynamic, e.g., if it doesn't change more than once a day,
consider generating a static document once a day by means of
a cron job or similar.
There are cases where the user doesn't mind waiting. If you
offer a link to get, e.g., ‘all data in one file’ and warn
that it is a few megabytes long, the user can balance the
convenience of having all data in one file against having to
wait.
(C22) Search
It is a good idea to put a search box at the right end of
the navigation menu. Some people prefer to browse, some
prefer to search, but even those that browse sometimes have
to resort to searching.
W3C's site search is located at https://www.w3.org/Help/search.
Here is an example of markup for a navigation menu with a
search box at the end:
<nav>
<form action="/Help/search">
<ul>
<li><a href="..." rel="bookmark">Foo home</a>
<li><a href="..." rel="bookmark">Learn & use</a>
<li><a href="..." rel="bookmark">Tools</a>
<li><a href="..." rel="bookmark">Specifications</a>
<li class="search"><input accesskey="E"
name="q"><button accesskey="G" type="submit"
name="sa"><img alt="Search" title="Search"
src="../../2008/site/images/search-button"
></button>
</ul>
</form>
</nav>
(C24) Date and time
When writing about something that has a date and a time
(‘we will publish tomorrow’, ‘the group met last week’, ‘the
deadline is August 15’), consider when the next time is that
you update the text. And also how likely it is that you don't
update it then. In other words, if people read the page next
week, next month, next year or in ten years, will the text
still make sense?
If in doubt, write the text differently and include the
year.
This doesn't hold for a blog post. It normally has a date
at the top and people expect blog posts to be outdated.
(C25) Unambiguous dates and
times
Always write the date or time in an unambiguous way for an
international audience. Is 9/11 in November or in September?
Is 6 o'clock in the morning or in the evening? And in what
time zone? Use ISO dates (2001-09-11) or include the month in
letters (September 11), the latter is preferred. Use a
24-hour clock with leading zeros (06:00 or 18:00) or add
AM/PM (6 AM, 6 PM), and add a city name or time zone name
(Paris, CET, Boston, EST) when the time zone isn't clear.
City names are best: People who don't live in Boston do know
Boston, but not necessarily that its time zone is called EST.
[The date command on GNU/Linux
generates AM/PM (uppercase, no dots) for the en_US locale. As
that command is likely to be used when generating pages,
shall we recommend that spelling, or rather a.m./p.m., as
some style guides prefer? (The date command on MacOS
generates 24-hour times for the en_US locale.)]
(C26) Hyperlinks
Make a word or a phrase into a hyperlink to additional
information whenever you think a reader might be interested
in that information. That saves the reader from having to
look it up.
But only link the word or phrase once, viz., the first time
it occurs. If the reader wasn't interested the first time, he
probably isn't interested the second time either. And the
extra link suggests there is more information than there
actually is.
However, in technical specifications it is useful to
consistently link every occcurence of a term to
its definition. People don't read specifications linearly.
You never know what they read before coming to a particular
section and its very possible they haven't seen this term
before.
(C27) Hyperlink behavior
To help users recognize hyperlinks, there should be some
feedback when the mouse pointer hovers over it (this is
obviously not possible with a touch interface) and when the
link has the keyboard focus. Browsers do this by default,
e.g., by changing the shape of the mouse pointer, showing
something in the status bar or drawing an outline around the
link. This feedback may be enhanced with style rules (using
the ‘:hover’ selector in CSS), but it should not be
suppressed. In particular, it is not recommended to change
the mouse pointer (with the ‘cursor’ property in CSS).
Likewise, when the user has activated a hyperlink, there
should be feedback to indicate that the action has been
registered, especially when the target may take some time to
appear. Browsers do this typically by showing an animation,
e.g., a spinning mouse pointer. This feedback may be enhanced
(with the ‘:active’ selector in CSS), but should never be
suppressed.
(C28) Do not open new windows
Do not use the target="_blank" attribute on
a elements to open a new window when a user
clicks a link. It makes it impossible for the user to use the
Back button to return to the previous page. Indeed, the user
may not notice what happens (because the new window overlays
the previous one, or the action only created a new tab), and
become confused why the Back button doesn't work.
(C30) No automatic
customization/personalization
The content of a page at a given URL should depend only on
the URL, on the user's preferred language expressed via the
Accept-Language header in HTTP, the user's preferred data
format via the Accept header, and on the time, because many
pages change over time. Of course, this applies only to
successful requests (when the server returns a 200 status
code). If there is no content at the URL, the user isn't
authorized to get the content or some other error occurs, the
returned content, if any, should rather describe the error.
However, the result of submitting a form that uses the POST
method (rather than the GET method) may, and probably does,
differ, depending on what the user filled in the form. We may
assume users know this.
E.g., if you bookmark a page and come back to it later, you
get the same content, unless the page has been updated in the
mean time. Or if you get a URL from somebody else, you should
see the same content as that somebody. And if you use two
browsers, or other HTTP clients (such as wget or curl), all
of them should get the same content, as long as you
configured them to ask for the same languages and data
formats.
Any adaptation to the environment (such as the window size)
should be done through the style, or, if there is no other
way, through JavaScript, but such that saving the page
locally always saves the same content, no matter if you used
a client with a big window, a small window, or no window at
all.
E.g., it is not acceptable (as some wikis do), to return a
200 status and a page with a password form when the client
isn't authorized to see a page at a given URL. If the server
isn't able to send the proper content of the page, it should
reply with an error (e.g., a 401 or 403 status code). Because
otherwise a robot or any software that doesn't read HTML will
never know that a password was expected.
(C31) Linking to non-HTML or
non-public content
When linking to a non-HTML document, indicate the type and,
if the file is big, also its size, so the user knows what to
expect.
When linking to non-public content (password-protected),
indicate that, too.
One way to indicate the type of the target is to add the
type in square brackets:
… the agenda [PDF]… this video clip [MP4,
16 MB]… a summary [member-only]…
(C32) Citations
When copying (quoting) text that is more than four or five
words, indicate the source: the name of the author and/or the
title of the document, maybe also the year; or link to the
source.
When you copy substantial parts (or all) of a document,
make sure the copyright license allows that, or get
permission from the copyright owner first. (When a document
has no explicit license, or a restricted one, it doesn't mean
reuse is forbidden, it means you have to ask first.)
(C33) Cool URIs don't change
As Tim explained, a
URL, once public, should never again be removed. Choose it
wisely (see ‘URLs’). And when the
contents at that URL are no longer needed, either make a
redirect to what replaces it (and document it, see ‘History of redirects’) or
make it clear to a visitor of the page that the content is of
historical interest only.
See ‘Examples of outdated pages’
for suggested text and styles.
See ‘How to make redirects’ for
ways to create redirects.
(C34) Shorten the text
When writing longer texts (blogs, manuals, press releases,
tutorials, etc.) it is easy to write too much. It is a good
idea to go through the paragraphs and try to remove what
isn't critical or necessary.
Likewise, check each sentence to remove unnecessary words.
Words like ‘very’, ‘currently’ or ‘actively’ are often
unnecessary.
Orwell's Six Rules contain more good advice on writing
clearly.
(C36) Alternative channels
A web page, or a group of related pages, that changes often
can benefit from having alternative, ‘push’ channels to its
readers, in the form of newsletters, Atom/RSS feeds, or Twitter/Mastodon feeds. That
allows readers to come back when there is new information.
Examples of pages that should have at least an Atom/RSS
feed: blogs, pages with news and mail archives.
(C37) Easy to unsubscribe
It should be as easy to unsubscribe from a newsletter as it
is to subscribe. There should be clear and easy-to-find
instructions in the same place as the instructions on how to
subscribe.
(C38) Confirmation email
When people unsubscribe from an email list, they should get
a confirmation notice.
(C40) Changing documents that
should not change
Some documents, or parts of documents, are supposed to be
published and not change. Dated technical reports are the
obvious example, but also news items, press releases and
archived e-mail messages are expected to always stay as they
were the day they were published.
Nevertheless, it may be necessary to make changes to them,
e.g., to correct factual errors that may have negative
effects, remove insults, or remove information that has a
negative impact on somebody's life (‘right to be forgotten’).
In such a case, the document should clearly indicate
- that it has been modified,
- the nature of the change, and
- the date of the change.
Note that technical reports and e-mail archives have their
own, more precise rules, both about how to decide to make a
change and how to indicate the change. See the in-place modification
policy and the archive editing policy.
(C41) Translations
Link to translations with an anchor written in the language
it links to: Nederlands, Français, Русский, 简体中文. After all,
the link is meant for people who have trouble reading the
English page. But other people may be curious what the link
is to, so it is good practice to include a TITLE attribute
with the name of the language in the language of the page
itself.
Hint: It may be hard to find the name of a language in some
other language, especially if you speak neither of them. The
list of translations of some popular topic on Wikipedia is a
good source. But if in doubt, just put the English name in
the TITLE.
(C42) Limited use of
cutting-edge features
The use of very recent technology, such as from
Recommendations that are less than two years old, should be
avoided.
The exception is on pages that are about that
technology. They can even show examples of technologies that
only have Candidate Recommendation status or equivalent, as
long as the maintainer of those pages is able to update them
if the specifications for those technologies change.
For example, the SVG home page could include examples of
SVG 7 as soon as SVG 7 reaches CR. The Fonts home page should
not. On the other hand, the Fonts home page could use WOFF 5
when that specification becomes CR.
In any case, a page that uses recent technology should be
functional, if less beautiful, when read with older browsers
and other software.
(C43) Pull quotes
Long texts with few section headings may benefit from pull
quotes, to show people at a glance what the text is about.
In HTML versions < 5, mark them up with
<blockquote class=doc-pullquote>
<p>...
</blockquote>
And in HTML5 and higher with
<aside role=doc-pullquote aria-hidden=true>
<p>...
</aside>
You can leave off the attributes if it is not possible to
add them. (E.g., software for blogs or wikis may not allow
them.).
See Digital Publishing WAI-ARIA Module 1.0 for more info on
the ARIA attributes for pull quotes.
(C44) JavaScript
Pages should not contain JavaScript that changes the
content of the page (see ‘Screenscraping’). Scripts that only change the layout
are acceptable if there is no solution with a style sheet.
(Style sheets are usually faster and especially they are
easier for a reader to override.)
Scripts that change the interaction (the way the mouse,
keyboard or touch events work) should not be used. They
confuse users who don't use the page very often and reduce
users' confidence that the page will do what they expect.
The exception are slide shows,
because
- We prefer to use HTML or SVG over other formats.
- There currently are no slide viewers that accept HTML.
- There is currently no possibility in CSS to render
documents as slides.
- The scripts we use can be turned off, because they work
by hiding content that is visible by default. (I.e., when
the script is blocked or JavaScript turned off, the
contents of all slides is visible.)
Visual elements
This section collects rules and guidelines about graphical
elements of a page: logos, colors, fonts, icons, etc.
Note that the easiest way to apply the right styles for fonts
and colors is usually to use one of the existing style sheets
under /StyleSheets.
(D1) W3C logo usage
As said in W3C logo, all web
pages should have a small W3C logo in the upper left corner.
The full rules for using the different W3C logos are below.
(These rules are based on and replace the historical rules.)
The full W3C logo is used in printed materials
(e.g., business cards, letterhead, envelopes, folders,
labels, folio, T-shirts and bags) and on signage (e.g.,
banners, architectural signage, display units and conference
booths).
The logo is meant to be used on a white background.
Available formats: SVG, PNG, GIF, EPS, Adobe Illustrator (PDF).
This logo was designed in September 1996 by Sally Khudairi
and Georges Ouanounou of INRIA.
The W3C standalone logo with bars is used for
web pages and for signage.
The logo is meant to be used on a white background.
The W3C standalone logo without bars can be used
if there is a strong aesthetic reason not to use the bars, if
the background is light but not white, or on physical objects
(e.g, embroidery, mugs, bags, pins, business card cases and
podiums).
The white W3C standalone logo is an alternative
to the logo with bars and is meant to be used on a background
that is W3C blue (#005a9c) or close to it.
The background of the logo without bars and of the white
logo has to extend outside the logo by a certain amount. This
is especially so as not to cut off the top of the invisible
‘C’. The padding at the top has to be at least 21% of the
height of the logo (i.e, 7px at the default size of 68 by
34px), the padding at the bottom at least 18% (6px at the
default size), the padding at the left at least 6% (4px at
the default size) and the padding on the right side at least
1.5% (1px).
For all of the above, the ALT text should be ‘W3C’.
Note: you may find versions of the logos without the small
® mark on the right. These are old and should not be used.
[Logos for Member, Office,
Evangelist…]
[Add a link to the (public) page ‘Logos and
icons’ and make sure this guide and that page
agree.]
[Images should be replaced by the new (‘revamped’) logos in 2023.]
(D2) Fonts
The font in the W3C logo is Base Twelve Sans from Emigre
Graphics.
In print materials, we use Gill Sans for the
main body of text.
On the Web, it is not necessary to specify fonts, allowing
the reader to read text in their preferred font. If you do
specify fonts, one good combination is Gill Sans
for the body text, with headings in the normal weight (not bold) of OFL Sorts Mill Goudy. (OFL Sorts Mill Goudy is a free
font, derived from Goudy.)
Note that Gill Sans is only available for the Latin and
Cyrillic scripts. Noto Sans may be an alternative
for most other scripts.
Line height in the main text should be between 1.3 and 1.5.
It may be more in certain environments, in particular in
forms; and should be less in headings when they have a larger
font size than the main text.
When choosing the line height, take into account the
following important factors:
- The overall grayness of the text: Look at a block of
text while squinting or from a distance and compare how
dark that block looks compared to blocks on other pages.
Adjust the line height to get a similar level of gray.
- The expected line length: When the lines are long (or
could be, on some screens), choose a bigger line height
than when they are short. This helps the eye to follow the
line and find the start of the next line.
- The font: If the text is in a known font, rather than a
generic sans-serif, the font may require adjustments to the
line height for optimal readability.
If you specify fonts, you can use WebFonts to make sure that people see a page with the
intended font (at least if they have CSS turned on). There is
a shared collection of WebFonts under /assets/fonts/ (including Gill
Sans, Noto Sans, OFL Sorts Mill Goudy and League Gothic
Regular) with instructions for use. [Check that this is true.]
When you make a new WebFont, it is recommended to install
it under that directory, so that others can find it and reuse
it without duplicating effort. Please, add some documentation
and/or an example of its use (and sign and
date it).
If you plan to use a WebFont other than those mentioned
above for the body text or the headings, please see with the
Communications Team first, to verify if it fits in the W3C
style.
[Google's fonts have a license that
allows them to be used directly from their CDN, i.e., without
the need to install copies on our server. Do we recommend
that?]
(D3) Font size
The font size of the main body should be left to the reader
(i.e., it should not be specified, or specified as 1em or
medium). Smaller text (no smaller than 90%) may be used only
for very short, footnote-like pieces of text. Bigger text can
be used te emphasize blocks of text or for headings.
(D5) Colors
When you need colors (besides black and white), pick them
primarily from the W3C blue (#005a9c [color sample]) and the
contrasting orange (#cb6628 [color sample]), or from
lighter, darker or greyer variants of these. (This is most
easily done with the hsl() color notation in CSS: just keep
the hue at 205 or 23. See the figure below for examples.)
The blues should be dominant, the oranges should occur only
in small quantities,
hsl(205,100%,18%), #00355bhsl(205,100%,25%), #004a7fhsl(205,100%,28%), #00538ehsl(205,100%,31%), #005a9c
W3C bluehsl(205,100%,34%), #0065adhsl(205,81%,34%), #10629chsl(205,100%,38%), #0071c1hsl(205,60%,38%), #266a9bhsl(205,16%,54%),
#758c9chsl(205,42%,90%),
#dae7f0hsl(23,70%,38%), #c16125hsl(23,67%,48%),
#cb6628
contrast orangehsl(23,54%,56%)hsl(23,44%,64%),
#cb997a
Some variations of W3C blue and contrast
orange.
When printing with a Pantone-based process, use Pantone
293C. The ‘C’ means the color as it appears on coated paper.
If unavailable, Pantone Reflex Blue may be used instead.
(Pantone-based color printing means printing with pre-mixed
dyes, as apposed to a four-color process, in which cyan,
magenta, yellow and black inks are overprinted to produce a
desired color. It is rare for paper, but it may occur for
printing on objects.)
(This section replaces the page W3C brand colors.
That page still has some useful advice.)
(D6) Text color
The main text on a page should be black on white. Blocks of
text can be set off with a background of #f1f7fb (a light
blue), #dae4f0 (another light blue) or #eeeeee (a light
gray).
Short pieces of text (menu, title, button, motto, etc.) may
also have white text on blue: #084b7b (a dark blue), #005a9c
(W3C blue).
In the case of small blocks of text, the background may
also be a very slight color gradient centered around one of
these colors. The darkest blue background may also have a
subtle pattern.
The background of text blocks with a colored background
should have a visual padding of between 1 and 2 rem. I.e.,
the background should extend above, below and on the sides of
the text by one to two times the font size of the main text.
Note that there are different ways to achieve this in CSS.
What counts is the final visual effect.
This padding should be consistent for all colored blocks on
the page.
(D7) Link colors
On a light background, unvisited links should be
hsl(207,100%,30%), a.k.a. #059 ([color sample]). This is a
blue close to W3C blue. Visited links should be
hsl(280,100%,30%), a.k.a #609 (purple, [color sample]).
[The home page currently uses
hsl(210,100%,20%) = #036 ([color sample]) and
hsl(207,100%,39%) = #006ec6 ([color sample]), but the
former is too close to black to be distinguished, so that
links need an underline; and the latter is too different from
purple.]
When the text is white on blue, use a very light blue for
links: hsl(200,97%,88%), #c2eafe ([color sample]).
(D8) Heading colors
Headings should be the same color as the text after them
(except in technical reports, which have headings in W3C
blue).
[If we do want a color for headings,
it should probably not be blue, despite the TRs. TRs don't
have headings that are links, but other pages may. The
current W3C home page, e.g., has many headings that are
links, and the fact that links and headings have the same
color makes it impossible to know if a heading is clickable,
other than by putting the mouse pointer or the focus on
it.]
(D9) Underline
Avoid underlining text that is not a hyperlink. Readers
expect that underlined text is clickable.
(D10) Icons
[… library of icons for certain
concepts (e.g., search, atom feeds, ); visual style of
additional icons…]
Icons that are shared by several pages can usually be found
under /Icons/ and new, shared icons
should be placed there. Some icons for slide presentations
are under /Talks/Icons/.
See Appendix D for more
collections of icons.
(D11) Signature style
The author's name and copyright statement at the bottom of
a page should be in an address element and in
italics or oblique (which is the default style for address in
most browsers, even without CSS).
(D12) Animation
Avoid animation for decorative purposes. Animation can be
used for two purposes: (1) in a graphic, if something is
better explained by showing a change occurring, e.g., how a
scrollbar works or how a horse's trot differs from galop; and
(2) in the form of a short (less than half a second),
one-time transition.
A short transition is actually a good way to give visual
feedback after a user action. E.g., if a clicked button
changes color, changing the color over 0.2 seconds instead of
immediately makes the effect more visible and more natural,
without slowing the user down. (The CSS property ‘transition’
is ideally suited for this kind of use.)
If you do use animation to attract attention,
make sure that you don't use fast blinking (an accessibility problem) and that the animation either
stops by itself after ten seconds or so, or that the user can
turn it off.
Also watch out for unintended fast blinking, due to
elements appearing too briefly on key or mouse actions.
For an example of a purely decorative animation that the
user can turn off, see some balloons
animated through CSS or the CSS20 animated
GIF.
(D13) Similar pages
Pages that have similar roles should look similar. It is a
good idea to look for existing pages on our sites that
fulfill similar purposes and copy visual elements from those.
For example, there are many pages that present news items, a
calendar of events, a Working
Group, an email archive,
an online survey (questionnaire), a specification, a list of
contacts, a technology (an area
home page), meeting minutes or a meeting agenda.
If our existing pages don't provide clear visual elements,
look elsewhere on the Web for the typical look of pages of
that kind.
The goal is that people, at least those that come to our
site more than once, can see immediately that a page is a
specification, or that it provides news items, etc.
See also Appendix C
for some example pages.
TPAC and AC
TPAC and AC meeting pages, apart from being W3C pages, also
have an identity as part of the TPAC and AC series.
The Events Team coordinates their development and writes most
of the content, the Web Design Task Force of the Comm Team does
the layout. Please, contact either team when changes are needed
in TPAC or AC material.
(K1) TPAC/AC style
A new style was made for TPAC 2019 and enhanced further for AC 2020 and TPAC 2020. This style is
meant to be reused, with minor variations (notably the
artwork) for future TPAC and AC
meeting pages. Instructions for authors are in the user
manual.
(K2) Printed agenda
One characteristics of TPAC and AC pages is that a part of
their content is also made into a hand-out that is given to
participants at the registration.
The recommended practice is to base the hand-out on the
page with the detailed schedule. That page is printed after
applying a style sheet that is optimised for printing. This
‘single source’ process avoids inconsistencies or omissions
and reduces the work.
Parts of the page that are only relevant online (such as
how to register) or only relevant when printed (e.g., visible
URLs) can be specially marked up to hide them from view.
The printed and online styles are different, but related.
They use the same fonts, same logos, same overall
organization of the page, and the same colors, but details
differ: the colors may be used in different places (e.g.,
colored backgrounds vs colored borders), the text may be
justified on paper, the printed page has page numbers,
different margins, etc.
(K3) Signs and posters
Information boards or signposts at the TPAC venue (e.g.,
lists of meeting rooms and meeting times, directions to the
registration desk), should use the same style as the handout
(colors, fonts, logos), adapted to the format of the signage.
It is recommended to generate these from the same source as
the handout, to avoid inconsistencies, at least if they
contain room and time schedules. This online PDF
generator was used in 2019. (It may need to be updated.)
Depending on the venue, some of the signage may be
displayed on monitors instead of printed on paper or plastic.
The size of the signs may also depend on the venue (American
or ISO print sizes, size of display stands). To avoid
requiring the intervention of designers for every variation,
ask the Web Design Task Force for one or two templates. The
meeting organizers can then fill these with different
content. A template could, e.g., be in the form of a
Powerpoint slide with the artwork already in place and an
empty box for text.
(K4) Name badges
Name badges shoould contain a recognizable element from the
TPAC or AC pages, such as a fragment of the banner image.
Printing of the badges can be left to a local printer
(except for a few blanks held in reserve for on-site
registration), which means creating artwork that can be given
to the printer (usually in PDF), but leaving the details of
the design to the printer.
(K5) TPAC & AC slides
Usually, (the Web Design Task Force of) the Comm Team
prepares slide templates for talks at AC and TPAC meetings
with the specific visuals of that meeting. (Example: the template for TPAC
2019 slides.)
![[Photo: a red pencil]](181511a-pencil.png)
![[Manuscript illumination: a writer at his desk]](Roman_de_la_Rose_f._28r_(Author_at_writing_desk).jpg)
![[image: white-on-blue W3C logo]](../../2008/site/images/logo-w3c-mobile-lg){kind=logo}
) with
![[Print: some black and red Hebrew letters, digits, lines and circles arranged in four crossing diagonal lines]](Design_by_El_Lissitzky_1922.jpg)
![[Painting of a young girl reading]](Fragonard_The_Reader.jpg)
![[Painting: head made out flowers, fruits and vegetables]](portraett_rudolf_ii_som_vertumnus._guiseppe_arcimboldo_-_skoklosters_slott_-_87582.jpg)
![[diagram of the padding around the logo]](W3C-logo-diagram.svg){kind=logo}
![[Painting: impressionist painting of a stone and steel bridge, with small boats]](La_Seine_a_Argenteuil.jpg)
![[Painting: A carpenter bores a hole in a piece of wood, while he is lighted by a boy with a candle]](La_Tour.jpg)
![[Painting: several long and short horizontal and vertical black lines forming rectangles of various sizes, some of which are filled with blue, red or yellow.]](490px-Trafalgar_Square_1943.jpg)
![[Painting: a group of men sitting and standing behind a long table, discussing in small groups]](800px-Ultima_Cena_-_Da_Vinci_5.jpg)
![[Print: An 18th century Japanese workshop with women making prints]](Utagawa_Kunisada_-_Printmaking_triptych.jpg)
![[Painting: Sitting woman with a lute and a letter talking to a standign woman, in a 1th century Dutch interior]](517px-Johannes_Vermeer_-_'De_liefdesbrief'_-_Google_Art_Project.jpg)
![[Prehistoric painting: several heads of European Cave Lions]](Lions_painting_Chauvet_Cave_(museum_replica).jpg)
![[image: red vertical bar with a small white coffee cup near the top]](https://www.w3.org/StyleSheets/team.gif)
![[image: business card of Bert Bos]](../../People/Bos/businesscard.svg)
.jpg){kind=link}
.jpg){kind=link}
(M3) Social media
See the ‘W3C Social Media Participation Guidelines’.