diff --git a/updating_the_website.html b/updating_the_website.html
index 15209ab..1ee97f5 100755
--- a/updating_the_website.html
+++ b/updating_the_website.html
@@ -1,101 +1,111 @@
-
+
-
-
-
-
-
-
+
+
+ Updating The Boost Website
+
- Updating The Boost Website
-
+
+
+ Making Updates to the Boost Website Content
- Making Updates to the Boost Website Content
+ Any boost developer can update the Boost website content between
+ releases.
- Any boost developer can update the Boost website content between
- releases.
+
+ - We strongly recommend the use of HTML Tidy when editing HTML and XHTML
+ files intented for the website. Using
tidy helps in
+ preventing errors in the HTML, in keeping a clear revision history, and
+ in conforming to Web standards to help make the website readable by the
+ majority of people. The Boost web pages currently have a variety of
+ different types of HTML and XHTML content. Each needs to be dealt with
+ differently by tidy. Most pages are regular HTML 3.x/4.x,
+ for these use a tidy invocation of:
+
+tidy --tidy-mark no -i -wrap 78 -m some_page.html
+
Other pages are using the more recent XHTML 1.0 and XHTML 1.0 Strict
+standards. Most notably this include the home
+page. Some additional options are needed to make tidy
+enforce the XHTML standard:
+
+tidy --tidy-mark no -i -wrap 78 -m -asxhtml some_page.html
+
That command is also useful if one is converting from HTML to XHTML. To
+have tidy check for the XHTML 1.0 Strict format use:
+
+tidy --tidy-mark no -i -wrap 78 -m -asxhtml --doctype strict some_page.html
+
If you have a choice as to what format to use, prefer the XHTML 1.0
+Strict format as that opens the content to the widest audience.
+
-
- - If the change you are making is intended to be part of a
- release, you should first make the change in our CVS repository,
- so it doesn't get lost or overwritten by the next person that
- updates the page between releases. Of course if you don't check
- in (say because the change is not supposed to be in the next
- release), and someone else changes the page after you, the
- change may be lost. This procedure does not account for that
- case; you'll have to use your head and figure out what to
- do.
+ - If the change you are making is intended to be part of a release, you
+ should first make the change in our CVS repository, so it doesn't get
+ lost or overwritten by the next person that updates the page between
+ releases. Of course if you don't check in (say because the change is not
+ supposed to be in the next release), and someone else changes the page
+ after you, the change may be lost. This procedure does not account for
+ that case; you'll have to use your head and figure out what to do.
- -
- You will upload the file(s) by
scp'ing to the
- appropriate subdirectory of
- shell.sf.net:/home/groups/b/bo/boost/htdocs/. For
- example, to update the page you are reading, I would issue
-
+
- You will upload the file(s) by
scp'ing to the
+ appropriate subdirectory of
+ shell.sf.net:/home/groups/b/bo/boost/htdocs/. For example,
+ to update the page you are reading, I would issue
+
scp updating_the_website.html david_abrahams@shell.sf.net:/home/groups/b/bo/boost/htdocs/more/
-
+
- -
- It is crucial to ensure that you set group write permission on
- every file you upload. If you don't do that, nobody else will be able
- to change it, which is particularly deadly at release time. If you
- are on Unix or Cygwin, you may be able to do that with a
- chmod command before uploading the file. The absolutely
- failsafe thing to do is to ssh into shell.sf.net
- and do the chmod there. The files also need to have general
- read permission, and any directories should have general execute
- permission and the "set user or group ID on execution" (s) bit should
- also be set. If you're not touching any directories, you can do it
- all with one command, e.g.
-
-ssh david_abrahams@shell.sf.net "chmod a+r,g+rw /home/groups/b/bo/boost/htdocs/more/updating_the_website.html"
+
- It is crucial to ensure that you set group write permission on
+ every file you upload. If you don't do that, nobody else will be able to
+ change it, which is particularly deadly at release time. If you are on
+ Unix or Cygwin, you may be able to do that with a chmod command
+ before uploading the file. The absolutely failsafe thing to do is to
+ ssh into shell.sf.net and do the chmod there.
+ The files also need to have general read permission, and any
+ directories should have general execute permission and the "set user or
+ group ID on execution" (s) bit should also be set. If you're not
+ touching any directories, you can do it all with one command, e.g.
+
+ssh david_abrahams@shell.sf.net "chmod a+r,g+rw /home/groups/b/bo/boost/htdocs/more/updating_the_website.html"
-
+
+
+
- Revised
- $Date$
-
+ Revised $Date$
+
- © Copyright David Abrahams 2005
+ © Copyright David Abrahams 2005
- Use, modification, and distribution are subject to the Boost
- Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at www.boost.org/LICENSE_1_0.txt)
-
-
-
+ © Copyright Rene Rivera 2005
+
+ Distributed under the Boost Software License, Version 1.0. (See
+ accompanying file LICENSE_1_0.txt or copy
+ at www.boost.org/LICENSE_1_0.txt)
+
-
-
-
-
-
