Notes on How to set up and maintain Web pages
Where to put your Web pages
On your Linux account put them
in a directory called public_html:
gedit index.html &
gedit file.html &
to make the files:
Other web hosting in DCU
File and Directory permissions / protections
The hierarchy of directories above the files
needs to be executable by "others". See
Notes on directory protections
chmod o+x .
chmod o+x public_html
On DCU this is done by default when you make directories.
All files need to be readable by "others". See
Notes on file protections
chmod o+r public_html/index.html
chmod o+r public_html/file.html
chmod o+r public_html/image.jpg
On DCU this is done by default when you make files.
- Raw HTML in a text editor
- Raw HTML in an assisted text editor
WYSIWYG Web editors
- Web content management system
- Great for organisation where many users enter data.
Users don't write HTML at all.
- Web templates
- use the skill of graphic/CSS designers who make sites look good / portable.
- CSS frameworks -
aimed at developers who will still access the code.
- Web application frameworks
Summary: Incredible number of tools and frameworks.
Some aimed at ordinary user who wants to avoid ever seeing code.
Others aimed at developers who want support
but still want to retain full control.
Things to consider:
- If tool generates very complex HTML then it makes it hard to make any small changes by hand.
Have to use the tool.
- Scaling up. Some tools are ok for editing a 5 page site
but not for editing a 5,000 page site.
- Consider how difficult it would be to
"replace X with Y"
in 5,000 pages.
Or move Images to a different directory and fix the links to them in 5,000 pages.
Do you have to edit 5,000 pages directly or can you script the changes?
- Note WYSIWYG editors may be misleading on the Web
because the Web is not WYSIWYG.
Your users are looking at your pages on mobiles,
old systems, tiny screens, wide screens,
with custom colours, fonts not installed,
ad blockers on
and windows resized.
WYSIWYG editors may delude you into thinking that what you are looking at
is how the page will look to the user.
<title> My web page </title>
<h1> My web page </h1>
<p> I am a very interesting person
and here are my poems. </p>
<p> Here is a link to my favourite artist,
<a href="http://www.daniel-site.com/"> Daniel O'Donnell</a>.
I hope to marry him some day. </p>
Browsers are forgiving:
- Case of tags doesn't matter.
Blank space and new lines are all compressed.
You can probably leave out the <html> tags,
and also the closing
- all browsers can display partial downloads.
starts a new paragraph no matter what,
so you can leave out the
- We could say "HTML is forgiving",
but it's more accurate to say that browsers are forgiving.
The HTML spec can say what it likes
- the browsers will still forgive errors.
- See discussion of this under
See HTML Reference.
- Open source model:
Source is interpreted on client side.
"View .. Source"
on other people's pages
to get ideas.
- Multiple files model:
HTML file embeds JPEG file. Two separate files.
- This can make it awkward to email someone a page with multiple supporting files.
(bundles all files into one file).
Some HTML tags.
- Plain text
- Just link to it, and browser should display it automatically.
- If problems, maybe change extension to .txt, or just scrap extension.
- pdf, doc, ppt, xls, ps, rtf
- Can all your users view this? On all platforms?
- How to read other formats
HTML plus images (browse-and-move-on)
HTML plus images is the most portable format,
readable on anything.
Your users are not just on PCs
but on netbooks, tablets, smartphones,
on old machines and old software and slow phone lines.
Why make them unable to read your work unless there is a good reason.
pdf, doc, ppt, xls, ps, rtf
(and in general anything that requires plug-ins and separate applications)
may break the clean Web model of browse-and-move-on.
- Searching for and searching in:
If it is in HTML,
the content can be picked up in search engines
(whereas content of ps, doc, pdf, etc. may be less accessible).
Content on a page can be easily searched in HTML.
- Linking in and out:
If it is in HTML,
people can link to it,
can link to sub-sections within it,
and those sections in turn can link back out
to the Web.
- You can link to sections in PDF. See example:
And PDF can link back out.
- LaTeX documents which can link out.
And you can link in.
- Don't need them online to browse them:
- Can browse offline work direct from disk:
- (this is also useful when server is down)
- Under Windows, use various tools
to make UNIX look like a drive, and browse:
- Or even edit them completely elsewhere, e.g. on laptop, and upload later:
- file:///C:/path/My Documents/My Web pages/index.html
To be able to browse the site in different ways like above,
we need to use relative links
- <a href="subdir/file.html">
- <img src="../picture.gif">
rather than absolute links:
- <a href="/~USER/subdir/file.html">
- <a href="http://computing.dcu.ie/~USER/subdir/file.html">
- <img src="/picture.gif">
- <img src="http://computing.dcu.ie/picture.gif">
so that the link will work whether we are browsing in "http mode"
or "file mode"
To include this image:
1. Absolute http address
2. Absolute http address, dropping server
3. Absolute file address
4. Relative address
1. and 2. work for http:// mode only
3. works for file:// mode only
4. works for both http:// and file:// mode
Though 4. assumes we know what level the linking page is in the hierarchy.
We might not know. e.g. Header included on all pages in all levels. Header must use absolute addressing.
Say your website is on UNIX server:
- Edit them directly off public_html in UNIX.
- Edit them in other dir in UNIX.
Periodically copy them into public_html.
- Edit them in Windows. Upload to UNIX. Maybe make UNIX account look like a drive: