Local Navigation
- S&G Home
- S&G About
- Policy
- Infrastructure
-
Technical
-
Application Development
- Audio-Video Standard
-
Barlesque Implementation
-
Barley Implementation
- Browser Support
- C++ Coding
-
Clickthrough (Go-) Tracking
- Cookies
- CSS
- Customising Content
- Database Design & Development
- Downloads
- File Extensions
-
.htaccess
- JavaScript
- Mapping
- Multimedia Plug-ins
- Perl Coding
-
RSS
- Semantic Mark-up
- XHTML Integrity
- XML
-
XSSI (eXtended Server Side Includes)
-
Application Development
- Design & Editorial
- Interactivity
- Accessibility
- Glossary
- Contacts
HTML Integrity Standards v1.4
Note:
This standard has been superseded by the XHTML Integrity Standard.
1. Doctype
1.1. The BBC currently adheres to the HTML 4.01 Transitional specification from the W3C while retaining some proprietary elements to maintain consistency of presentation on older web browsers and in the case where the page is XHTML-compliant code (as described in 5.3) is consistently lowercase and closes unary tags.
1.2. All bbc.co.uk HTML pages which use Barley MUST include the HTML 4.01 doctype on the first line, with no public identifier, to ensure modern browsers use backward compatible rendering techniques:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">1.3. All news.bbc.co.uk pages MUST include the following doctype:
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">For further information, see Appendix 1.
2. Validation
2.1. All HTML code MUST reflect the DOCTYPE definition at the top of the file, with the following caveat:
2.1.1 Validation against HTML 4.01 (using tools such as the W3C validator) will normally identify errors due to those proprietary elements needed to maintain consistency of presentation on older web browsers.
2.1.2 Some Validation errors are acceptable, but each error MUST be known and be justifiable.
2.1.2.1 The current list of acceptable validation errors can be found in Appendix 2 of this document.
3. Accessibility
3.1. The BBC has statutory obligations, in terms of the Disability Discrimitation Act (DDA), to produce accessible content. For details of this see the Accessibility Checklist.
3.2. Your pages MUST comply with bbc.co.uk Accessibility Standards.
3.3. You MUST NOT provide core content or services via associated technologies (e.g. Javascript, Flash) without providing an alternative for browsers which do not sufficiently support these assistive technologies (see the Browser Support Standards).
3.3.1. Due to accessibility concerns, you MUST NOT use sIFRs on bbc.co.uk without first discussing this with the Editor, Standards and Guidelines.
4. Browser support
4.1. The BBC supports certain browsers, listed in the Browser Support Standards.
4.2. Character sets and supported languages
4.2.1. You MUST set the charset for the document at only one place in the document:
4.2.1.1 When specifying the character set of the document, you MUST use charset iso-8859-1, unless you need additional language support, in which case you SHOULD use UTF-8, if it is suitable.
4.2.1.2. If you are using Barley, you MUST use its default character set (iso-8859-1) unless you require another character set, which you MUST set via Barley's bbcpage_charset variable.
4.2.1.3. If you are not using Barley, you MUST set this in the metadata tag in the head of the HTML.
4.2.2.4. If you have a form input text box which expects a different charset than the page on which it resides, you SHOULD specify this using charset-accept = charset.
4.2.3. If you wish to use any symbols which require a particular character set to be viewed (e.g. mathematical symbols, or the Euro character etc.) you SHOULD NOT assume that viewers of your pages will have the character set you are relying upon. For any of these characters, you SHOULD either not use them (e.g. the Euro character can be replaced with EUR) or use a graphical representation.
4.3. You MUST also specify the base language of the page - see Accessibility Checklist.
5. Code style
5.1 Code Layout
5.1.1. Code which is produced and maintained by content production systems SHOULD be as compact and comment-free as possible, to minimise file size and Download Time (see the Download Standards).
5.1.1.1 If this is done, a readable version of the pre-published code SHOULD be available for maintenance purposes.
5.1.2. Code which is manually produced and maintained SHOULD be well laid out to ensure readability. Reasonable use of blank lines, indenting and comments to denote different sections of the page is encouraged. However their use SHOULD be balanced with the same file size considerations, as in 5.1.1.
5.1.3. Please also be aware of code layout sensitive bugs in supported browsers (e.g. use of on the next line from the and indentation of lines in table cells in Netscape).
5.2 Well-formed HTML
5.2.1. Documents SHOULD be well-formed:
5.2.1.1. All opened HTML tags MUST have a closing tag (unless it's a unary tag - see 5.3.4).
For example:
<p>This is a paragraphSHOULD read:
<p>This is a paragraph</p>5.2.1.2. All HTML tags SHOULD nest properly.
For example:
<b><span>Project Name</b></span>is incorrectly nested, whereas,
<span><b>Project Name</b></span>is correctly nested (and XHTML compliant).
5.2.1.3. All HTML elements and attributes MUST be written in lower-case (for XHTML compatibility - in XHTML <p> and <P> are treated as different tags)
5.2.1.4. All tag attributes MUST be quoted, usually in double-quotation marks but single-quotation marks are also acceptable when using JavaScript or XSSIs.
For example,
<img alt=apple /> or <td width=25>are incorrect and SHOULD be written
<img alt="apple" /> and <td width="25">5.2.2. Any instance of an id attribute on a page MUST be stated only once. If you require multiple instances of a style, you MAY use class attributes.
For more information on HTML specifications, see w3c.org.
5.3 XHTML-compliant HTML - unary tags
5.3.1 You MUST use either XHTML or HTML unary tags (illustrated below) consistently.
5.3.1.1 - i.e. you MUST NOT mix the two different types of unary tag in the same bbc.co.uk HTML page, UNLESS you are including feeds or third-party content where you are unable to specify XHTML when commissioning the feed.
5.3.2. To ensure consistency with Barley templates, all Barley pages MUST use XHTML unary tags.
5.3.3. Non-Barley pages MUST be internally consistent, and SHOULD use XHTML unary tags
5.3.4. XHTML unary tags MUST be terminated in the following way: <tagname />
For example, <br> or <hr> are incorrect and SHOULD be written <br /> or <hr />
5.3.4.1. Note that there MUST be a space character between the end of the tag name and />.
5.3.4.2. The following is a list of common tags that require this termination:
<br>, <hr>, <img>, <link>, <input> and <meta>
Like so :
<br />, <hr />, <img />, <link />, <input /> and <meta />
5.3.4.3. For more details on XHTML see w3c.org/XHTML 1.0 The Extensible Hypertext Mark-up Language.
The reasoning behind the BBC's adoption of XHTML-compliant HTML can be found in Appendix 3 of this document.
5.4 Prohibited tags
5.4.1 You MUST NOT use <blink> or <marquee> tags. This is due to accessiblity and browser support issues.
6. Appearance of bbc.co.uk pages and use of Barley
6.1. The navigational appearance of all bbc.co.uk pages MUST comply with the bbc.co.uk Page Layout Standards, except those stated in 6.1.1.
6.1.1. Exceptions to this standard include:
6.1.1.1 Some World Service sites due to language issues.
6.1.1.2 HTML versions of long documents (such as those documents published under the Freedom of Information publication scheme) - these documents do not need to include the toolbar and left-navigation, but MUST include BBC copyright and privacy information.
6.2 All bbc.co.uk pages MUST include a link to a text-only or low-graphic version of the page in the banner/top left-hand area of the page and a "skip to main content" invisible-gif shortcut to aid screenreader users as the first links in the toolbar.
6.3 Use of Barley to implement bbc.co.uk Page Layout standards
6.3.1. All bbc.co.uk pages, except pop-ups and those detailed in Appendix 4, MUST use the bbc.co.uk standard templating system, currently Barley.
6.3.1.1 Barley provides a standard system for implementing the bbc.co.uk Page Layout standards, by including modular elements (e.g. the toolbar) within a flexible template structure.
For further details, see Using Barley (Implementing Page Layout Standards).
7. Separation of semantics from presentation
7.1. You SHOULD use semantic markup rather than presentational markup - e.g. use <strong> and <em> rather than <b> and <i>.
7.1.1 If you want to present content in bold or italics visually, without the corresponding semantic meaning you SHOULD use CSS.
7.2. Semantic markup SHOULD be combined with CSS to convey both the semantic meaning and the required design appearance of the page.
7.3. If you use CSS for layout* you MUST semantically code your markup.
7.3.1 * This is where CSS is used for laying out the content on the page. If you are using tabular layout instead, your use of CSS SHOULD NOT result in loosing the semantic meaning, when CSS is disabled; and 7.3 does not apply.
7.4. <p> tags
7.4.1. You SHOULD use <p> tags to specify the semantics of paragraphs, and then combine them with a style sheet to create the right appearance for your page.
7.5. <h1>...<h6> tags
7.5.1. You SHOULD also use <hx> tags to specify the semantics of headings.
7.6. HTML list tags (<ol> , <ul> etc.)
7.6.1. You SHOULD use HTML list tags (<ol> , <ul> etc.) whenever possible, but it MUST be remembered that they often indent further than the design they are implementing.
7.7. <pre> tags
7.7.1. You SHOULD only use <pre> tags for code and ceefax-shared data, and not tabular data, as the layout abilities of the tag are not accessible.
7.8. <font> tags
7.8.1. You MAY use <font> tags only for the sizing of text. (For css sizing options see the css standards)
7.9 You SHOULD use span tags for other inline formatting of text (e.g. font cases and colours) unless already in a containing element which can be styled (e.g. font, em, strong, li).
8. CSS
8.1. You SHOULD use CSS to minimise the amount of code required to render a site. Used properly, CSS can provide users of recent browsers with a more satisfying experience and faster rendering of a page, and also retain accessibility and speed of rendering for low-end browsers which do not support CSS.
8.2. You SHOULD use CSS in all circumstances, where permitted under the CSS standards.
8.3.HTML pages MUST be readable without style sheets (i.e. if style sheets have been turned off in the browser).
9. Specification of fonts
9.1 Specification of font face
9.1.1. Font face MUST be defined in CSS, not in <font> tags.
9.1.2. You MUST specify Arial/Helvetica, Verdana, Trebuchet or Tahoma for use in body copy and links. See Appendix 5. Other fonts MAY be used in other, particular circumstances, for specific purposes (e.g. headings, to highlight quotes).
9.1.3. The font face MUST offer a generic font family (which is available on all partially-supported browsers) as a last alternative, e.g. sans-serif.
9.2 Specification of font size
9.2.1. Fonts MUST be resizable in all supported browsers.
9.2.2. You SHOULD specify font sizes by CSS methods, where possible. You MAY specify the font size in the html <font> tag. See CSS standard.
9.2.3. You SHOULD specify the font size as a relative value (e.g. font size="-1" or font size="-2").
10. Images
10.1. All images used in <img> tags MUST be in either GIF or JPEG format.
10.2. PNG files MAY be used, but MUST degrade gracefully and still allow for the core content of the site to be conveyed.
10.3. If you use PNG files, they MUST ONLY be included in the page by CSS or JavaScript controlled CSS means.
10.4. The height and width attributes MUST be specified for all images.
10.5. These MUST NOT be used to rescale images to provide thumbnail versions of the full image - a separate, resized image SHOULD be used instead.
10.6. Alternative text MUST be provided for all images referenced using an <img> tag - see the Textual Equivalents (Accessibility) Standards.
10.7. You MUST NOT use images referenced in CSS or JavaScript for core content (absence of alt attributes makes these images inaccessible) where alternative content is not supplied.
10.8. If an image or table is floated/aligned using the align attribute (i.e. in the html not in CSS) it MUST be followed by <br clear="all" /> if the intent is for the content to continue below the object.
10.9. The hspace and vspace attributes of an image MUST be specified if the align attribute is present.
10.10. A border MUST be specified for all image links or form submit images. In most cases where this is specified in the html, this will be set to 0. Where this is specified in CSS it will often be none.
10.11. Any images which are not links MUST NOT have a border="0" attribute (as it is extraneous code).
10.12. Spacer gifs (used for layout) which are links MUST have a border="0" attribute.
10.13. Your spacer gifs MUST use the location in the Download Standards rather than /furniture/tiny.gif (or any site-specific instance).
11. Imagemaps
11.1. You MUST NOT use server-side imagemaps.
11.2. Imagemaps MUST have alt text specified for all elements.
11.2.1 For further details, see the Textual Equivalents (Accessibility) Standards.
11.3. Where possible, you SHOULD use rectangular and circle definitions rather than poly-definitions, because this minimises code size.
12. Code Comments
12.1. You MUST NOT have any comments in your code which endorse any company or individual unless there is a copyright issue that requires it.
12.1.1. For internal systems you SHOULD highlight the location of support documentation.
12.2. You MUST NOT have any comments in your code which include more than two concurrent 'x' characters. Putting 3 'x's anywhere in your page might identify your page as containing adult content, to applications which restrict such content.
13. Form layout
13.1. The space created by using <form> tags SHOULD be removed using CSS (e.g. using form{margin:0px;}).
14. HTML page colours
14.1. You MUST NOT put any colours in the body element of your page.
14.2. A full default set of definitions for colours (equivalents of text, link, alink, vlink and bgcolor in html) MUST be specified in the page's CSS style-sheet. This will enable the document to be readable with CSS turned-off, and will allow users with visual impairments to change the colours of the page to their preferred settings.
14.3. All other colour changes or background images within a document MUST be specified using CSS - see the CSS standards.
14.4. Whether CSS is used or not, colour changes MUST use a consistent method to allow graceful degradation of presentation.
14.5. You MUST always define a page background colour in your CSS even if it is white.
15. Frames
15.1. You SHOULD NOT use iframes as there are usually alternatives which are not as browser-dependent.
15.2. You MUST NOT use frames (as distinct from iframes) on pages, except in pop-up windows for the following purposes:
1. to store data in a zero-height frame
2. to enable different parts of the pop-up to refresh at different rates
3. to enable scrolling in part of the pop-up
15.3. If you use frames in a pop-up window you MUST title each frame to facilitate frame identification and navigation (using the title attribute in the frame tag) - see WAI guideline at w3c.org/HTML Techniques for Web Content accessibility Guidelines/Frame names for implementation details.
15.4. The reasons for outlawing frames on pages are problems of accessibility, bookmarking, search engines, and increases in the complexity of the mental model of the page. As many of these problems do not apply to pop-ups, we consider that the benefits of allowing frames in pop-ups outweigh the few problems.
16. Pop-ups
16.1. bbc.co.uk sites MAY occasionally require a pop-up window to present content or a feature, such as:
1. Consoles such as broadband, radio player, News AV
2. Online quizzes and votes
3. Interactive promotions or games (e.g. developed in Flash /Shockwave).
16.2. The BBC definition of a pop-up is: "any browser window which is opened via JavaScript as a JavaScript-modified window". These windows MAY not have a toolbar (including back button) or address line.
16.3. You are advised to use pop-up windows with caution, because they present usability, accessibility, and navigation issues to users; and also because viewers might have configured their browsers to block pop-up advertising.
16.4. The use of pop-ups SHOULD be kept to a minimum
16.5. Pop-ups MUST never open unannounced
16.6. Pop-ups MUST only open when a user has clicked a hypertext link.
16.7 Use of pop-ups
16.7.1. Labeling and launching pop-ups
16.7.1.1. You MUST clearly label links which launch pop-ups so that our audience know they launch a pop-up.
16.7.1.2. Defensive coding techniques MUST be employed in HTML so that users are able to access pop-up window content, irrespective of whether or not their web browser is JavaScript-enabled.
16.7.1.3. Pop-up content MUST open in a new window (using a target attribute) when JavaScript is disabled, or a link back to the calling page MUST be provided.
16.7.1.4. You MUST give the pop-up focus when it launches, in the code which launches the pop-up (not in an onload in the pop-up).
16.7.1.5. Our audience MUST NOT be presented with multiple pop-up windows from a single click.
16.7.2. Size of pop-up windows
16.7.2.1. Pop-up windows SHOULD be adequately sized to avoid unnecessary scrolling.
16.7.2.2. Pop-up windows SHOULD NOT have an initial size of more than 600 x 440 pixels.
16.7.2.3. Pop-up windows with an initial size above 600 x 440 MUST NOT disable scrollbars.
16.7.2.4. Pop-up windows MUST NOT have an initial size of more than 720 x 540 pixels.
16.7.2.5. These dimensions are calculated as 90% of the minimum supported screen resolution for BBC sites.
16.7.2.6. Pop-up windows MUST be resizable to accommodate users with poor vision that need to enlarge their font sizes.
16.7.3. Required elements (incl. branding) of a pop-up window
16.7.3.1. Pop-up windows MUST contain the BBC logo (see BBC Logo Guidelines [ internal BBC doc - gain access via your Technical Account Manager])
16.7.3.2. They MUST contain the privacy and terms of use links (which SHOULD display in a new browser window, when clicked).
16.7.3.3. Pop-up windows or consoles which do not have the main content at the top of the pop-up (i.e. include navigation) MUST include a "skip to controls/main content/etc." invisible-gif shortcut to aid screenreader users.
16.8 Identifying whether a pop-up SHOULD be indexed by search agents
16.8.1 You SHOULD identify whether or not your pop-up is able to be indexed by web search agents. This is an editorial decision.
16.8.2 You MUST NOT allow pop-ups to be searched unless they are "standalone" and do not require instructions for use, from the page they are normally opened from (e.g. this content requires the Flash plug-in).
16.8.3 If your pop-up is searchable, you MUST include a "Go back to associated bbc.co.uk page" (or similar) link outside the viewable area of the pop-up
16.8.3.1 You MUST test the presentation of the content in a normal browser window (where you would be able to see that link).
17. Plug-ins / Flash
17.1 The BBC has standards relating to plug-in content, these are listed in the Multimedia Plug-in Content Standards.
18. Script functionality (JavaScript, CGI, mod_perl)
18.1 Reuse of common BBC scripts
18.1.1. Wherever possible, use the common BBC scripts that are provided for common tasks such as rollovers, plug-in detection etc. A list of locations where you MAY find these scripts is available at BBC Site Tools [ internal BBC doc - gain access via your Technical Account Manager] and the BBC CGI Toolbox [ internal BBC doc - gain access via your Technical Account Manager].
18.2 How to choose between implementing as client-side JavaScript or server-side CGI
18.2.1. You SHOULD use JavaScript with a CGI/server-side backup method for those who have turned JavaScript off in their browser or don't have a browser that supports the JavaScript version required. This will lower the processor load on bbc.co.uk servers.
18.3 Use/re-use of server-side cgi/mod_perl applications
18.3.1. If you are going to be making use/reuse of a server-side application as part of your site:
18.3.1.1. You MUST consider the scalability of that application for the intended/expected audience of your site (see Application Development Standards ).
18.3.1.2. You MUST inform the manager/author of the application you are reusing, so they are aware of your site's dependency on that application.
18.4 Capturing Personal Information
For applications that process personal data you MUST adhere to the requirements of the Technical Implementation of DPA.
19. XSSI (eXtended Server-Side Includes)
19.1. XSSI (eXtended Server Side Includes) are used extensively on bbc.co.uk for dynamic content manipulation rather than client-side scripting such as for time-dependent HTML/content changes. This is because, as a server-side function, we can be assured that the content will be delivered as intended, regardless of the client technology.
19.2. XSSI are also used within the BBC standard Page Template System (Barley) to configure and respond to settings for page layout.
19.3. See XSSI Standards for more information.
20. Page titles and metadata
20.1. Metadata significantly improves search results and ensures that users are able to find material that is relevant to their requirements. This results in increased traffic and higher levels of user satisfaction.
20.2. Conversely, the omission, inconsistent or inappropriate application of metadata prevents users finding relevant content and results in reduced traffic and user dissatisfaction.
20.3. All BBC website pages MUST include metadata according to the BBC Search Metadata Standards.
20.4. Note that if you are using Barley, you MUST supply the metadata indicated by the Barley template.
21. File and directory names
21.1. All file and directory names (include file extensions) MUST be in lowercase and SHOULD NOT be overly long.
21.2. Non-alphanumeric characters (except underscores, which MAY be used to separate words) MUST NOT be used in filenames (because these don't work on live web servers).
21.3. Underscores MUST NOT be used in tld directory names (those top-level directory names which are used to market bbc.co.uk sites - these are advertised on ceefax, which can not display underscores) and SHOULD NOT be used in other directory names.
21.4. Files MUST obey the File Extensions Standards.
21.5. Top Level Directory names MUST follow the URL Requirements standard.
22. Download Size / Page weight
22.1. bbc.co.uk is one of the most popular websites in the UK, generating significant levels of traffic, especially at peak times. It is therefore particularly important that all pages are designed to be as server/client efficient as possible.
22.2. The total weight of all code and called assets within a page SHOULD be as small as possible to minimise download time.
22.3. Any files over 500k MUST be served from downloads.bbc.co.uk, unless it is real or windows media. For serving of real and windows media files see the Audio Video standards.
22.4. For more information, see the Download Standards.
23. Enabling user feedback & customised feedback pages
23.1. As part of the BBC's service to its audiences, bbc.co.uk MUST provide facilities for those users to ask questions and provide feedback to the sites' producers.
23.2. Customised feedback pages MUST be made for each site with a top level directory (or redirect). Where this includes personal information, see section 18.5.
24. 404s and other errors
24.1. You MUST NOT cause 404 errors to appear on bbc.co.uk.
24.2. You SHOULD create your site's own (local, site-specific) 404 error pages where editorially justified.
24.3. Customised error pages MUST have a minimal Download Size and SHOULD provide additional local help to the standard error page for bbc.co.uk.
24.4. You MUST NOT link to www0.bbc.co.uk, or any single BBC server in any link.
25. Environment Variables
25.1. You MUST NOT rely on the accuracy of referrer information, as this is often removed or spoofed.
25.2. You MUST NOT use user agent detection, as this is not reliable. In Javascript you MAY use functionality detection [e.g. if(document.images)] to recognise what a browser is capable of.
26. Google Maps
26.1. If you wish to use Google Maps on your site, you MUST contact the Editor, Standards and Guidelines for advice on how you should do this.
27. Triggers for updates to this standard
27.1 tables standards get agreed
27.2 accessiblity group updates standards to inform on title attributes
27.3 This document SHOULD be updated when/if a standard validator (such as iF&L's RoboWebbie see Adam Guy) becomes available
28. Appendices
Appendix 1: Doctypes
The reasoning behind the use of these DTDs is in part legacy, and also to stop browsers rendering pages in strict mode.
Legacy issues
The Barley template currently uses the HTML 4.01 DTD, and the News CPS the 4.0 DTD. There are issues with both DTDs, but until such point as a better solution (solving the problems with strict rendering and moving to an XHTML DTD) is found, then as long as the areas use their DTDs consistently they MAY as well stay that way.
Browser rendering
Some modern browsers have two rendering modes. Quirk mode renders an HTML document like older browsers used to do it, e.g. Netscape 4, Internet Explorer 4 and 5. Standard mode renders a page according to W3C recommendations. Depending on the DTD present in the HTML document, the browser will switch into either quirk mode or standard mode. If there is no document type declaration present, the browser will switch into quirk mode. Both of the acceptable bbc.co.uk doctypes do the same thing - force the browser to render (in Mozilla) in quirks mode.
Appendix 2: Acceptable Validation Errors
Acceptable validation errors list:
Errors caused by forms and XHTML unary tags ( />) (which explains a lot of £document type does not allow element META/LINK here errors in the <head>)
topmargin, leftmargin, marginheight, marginwidth (in the body tag) [this is acceptable because it is needed to synchronise background images with foreground content on pages]
More than one style sheet or script in the <head>
This list SHOULD be reviewed whenever the Browser Support Standard and Barley templates are updated.
Appendix 3: XHTML compliance reasoning
Reasoning behind "All code MUST be XHTML compliant":
Pros:
- helps to make the document understandable/transformable using XSLT
- allows HTML coders to prepare for XML (and XHTML, in future)
- consistency on a page is necessary for us to validate pages with a DTD
- if our pages had an XHTML DTD, browsers could display the pages faster
Cons:
- page no longer validates to any HTML DTD
- adds to pageweight (download size - 2 chars on unary tags)
- problems with character sets, XSL (Saxon parser)
- we' re not habitually using XSLT over HTML docs
- requires hand-coding (Dreamweaver etc. doesn't do unary tags in XHTML format - need to turn off Dreamweaver default settings)
Appendix 4: Approved sites with Barley exemption
These sites MAY comply with the bbc.co.uk page appearance standards without using the BBC Standard (Barley) page templates:
- http://www.bbc.co.uk/news/
- http://www.bbc.co.uk/sport/
- http://www.bbc.co.uk/jobs/
- any World Service, 'international facing*' sites and DNA-based sites
*Includes the international toolbar.
Appendix 5 : Approved editorial reasons for alternative font faces
sites that are writing content in languages other than English MAY use fonts other than those declared to support the language.
cbbc, cbeebies and schools sites MAY use "Century Gothic" font in banner areas.
29. Document history
| Date | Version | Change | Author |
|---|---|---|---|
| 11/04/2008 | v1.4 | Added note that this standard has been superseded by the XHTML Integrity Standard. Added sections 3.3.1. about sIFR usage and 26.0 about Google maps usage. | Victoria Jolliffe |
| 15/06/2006 | v1.3 | Removed Courier as an approved font and made other (approved) fonts mandatory, as recommended by Accessibility WG and approved by Technical Forum (section 9.1.2). Also approved by Design Forum on 28/06/2006. | Tred Magill |
| 12/06/2006 | v1.2 | Revised section 18.4 in line with Technical Forum agreement (26/04/2006) to reference Technical Implementation of DPA requirements. | Tred Magill |
| 06/02/2006 | v1.1 | Extensive edits by BBC HTML Integrity Group | Nick Holmes |
| 18/11/2005 | v1.08 | Removed reference to floating divs (last sentence of introduction to Section 16). | Tred Magill |
| 16/03/2005 | v1.07 | Updates required by Tech Forum on 14/03/2005 (incl. from Matt Blakemore) | Jonathan Hassell |
| 08/03/2005 | v1.06 | Brief updates to Section 18 on personal info (to mirror the App Dev Guidelines) in yellow | Jonathan Hassell |
| 07/03/2005 | v1.05 | Updates to section 6 to link to new Barley and Page Layout docs (in yellow ) and bring in barley summary for public consumption from old Ch4 of Web Dev Guidelines | Jonathan Hassell |
| 03/12/2004 | v1.04 | Alterations required for approval by Tech Forum on 03/12/2004 | Jonathan Hassell |
| 03/12/2004 | v1.03 | Slight corrections from NickH | Jonathan Hassell |
| 05/10/2004 | v1.02 | Update from NickH re error messages in JavaScript | Jonathan Hassell |
| 17/09/2004 | v1.01 | Minor updates (for accessibility, integration with rest of Web Dev Guidelines, and requested by Standards Exec) | Jonathan Hassell |
| 22/06/2004 | v1.00 | Standard renumbered as 1.00 on approval by Standards Exec. | Jonathan Hassell |
| 14/06/2004 | v0.42 | Amendments required by Tech Forum on 14/06/2004 for approval (also introduced bookmarks for internal reference in doc) | Jonathan Hassell |
| 07/06/2004 | v0.41 | Small amount of post-meeting tidying | Jonathan Hassell |
| 04/06/2004 | v0.40 | Edits performed during Working Group meeting | NM HTML Integrity WG |
| 19/05/2004 | v0.39 | Edits performed during Working Group meeting | NM HTML Integrity WG |
| 14/05/2004 | v0.38 | Added in more on font usage | Jonathan Hassell |
| 11/05/2004 | v0.37 | Added in "skip to main content" requirement for all pages/pop-ups | Jonathan Hassell |
| 30/04/2004 | v0.36 | Added in question re how people SHOULD number their headings | Jonathan Hassell |
| 29/04/2004 | v0.35 | After comments from Technical Forum on 28/04/2004 | Jonathan Hassell |
| 20/04/2004 | v0.34 | Bit of a tidy-up: moved FTP section into Web Dev Guidelines (Ch5) | Jonathan Hassell |
| 15/04/2004 | v0.33 | Edits performed during Working Group meeting | NM HTML Integrity WG |
| 13/04/2004 | v0.32 | Removed XSSI stuff into separate document, replaced with a link to that document | Jonathan Hassell |
| 10/03/2004 | v0.30 | Edits performed during Working Group meeting | NM HTML Integrity WG |
| 09/03/2004 | v0.29 | Added use/reuse of applications section, as requested by Application Development Working Group | Jonathan Hassell |
| 20/02/2004 | v0.28 | Edits performed during Working Group meeting | Jonathan Hassell |
| 20/02/2004 | v0.27 | Info from JH's research | Jonathan Hassell |
| 03/02/2004 | v0.26 | Removed table info into specific doc | Jonathan Hassell |
| 06/01/2004 | v0.25 | Edits performed during Working Group meeting | NM HTML Integrity WG |
| 06/01/2004 | v0.24 | Tidy up by JH | Jonathan Hassell |
| 26/11/2003 | v0.23 | Put doc in correct template, integrated useful content from Chapter 4 of Web Dev Guidelines | Jonathan Hassell |
| 25/11/2003 | v0.22 | Annotations from 1st meeting of HTML Integrity Working Group | NM HTML Integrity WG (Jonathan Hassell) |
| 30/10/2003 | v0.21 | Annotations by Helen Pickford | Helen Pickford |
| 21/07/2003 | v0.2 | Took http://support.bbc.co.uk/standards/integrity and edited into one doc | Rebekah Ford, Nick Holmes |
Document editor: Editor, Standards & Guidelines. If you have any comments, questions or requests relating to this document, please contact the Editor, Standards & Guidelines.
Like all other Future Media Standards & Guidelines, this page is updated on a regular basis, through the process described on About Standards & Guidelines.
© MMIX