Underlined text[u] (Not in html.1)
These char codes are case sensitive:
& is '&' = 38 decimal
£ is '£' or '£' = decimal 163 in ISO-Latin-1 (char # less the 8th bit)
French: èéêîôàÀ etc. [è ... Agrave icirc eacute ...]
German: ü Ä ö Ö Ü ä ë [ü Ä ....]
Fixed space ' ' is ' ' = decimal 160 (space char plus the 8th bit)
Fixed space ' ' is ' ' = non breaking space) 8194, 8195 are HTML fat (n and m-) spaces.
145 146 147 148 168 ¨
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144
149 (or •) 150 151 152 153 154 155 156 157 158 159
Dashes: — — (151 works but is technically illegal in HTML: 150 151 8211 – 8212 —)
Quotes: 145-148 illegal. 8216 ‘ 8217 ’ 8220 “ 8221 ”
HTML symbols extra HTML 4 symbols
Arrows and other symbols: [→ rArr larr uarr darr harr crarr, etc.]
→ ⇒ ← ↑ ↓ ↔ ⇔ ↵ ≡ ≠ ≈ ≅ ∞ √
<CENTER><P><B><STRIKE><BLINK><FONT COLOR="#EB0F11"><FONT SIZE=+3>THIS</FONT></FONT></BLINK></STRIKE></B></P></CENTER>
color="#000000" black color="#FFFFFF" white
color="#FF0000" red 7F0000 FF8080
color="#00FF00" green 007F00 80FF80
color="#0000FF" blue 00007F 8080FF
color="#FFFF00" yellow 7F7F00 FFFF80
color="#FF00FF" mauve 7F007F FF80FF
color="#00FFFF" turquoise 007F7F 80FFFF
color="#3A6EA5" royal (UoG) blue
[Plain] This is meant to be a considerable block of text, reaching over several lines and so displaying the wrap issues. I just hope that this is long enough for the windows I'll usually be using.[ADDRESS] This is meant to be a considerable block of text, reaching over several lines and so displaying the wrap issues. I just hope that this is long enough for the windows I'll usually be using.
[BLOCKQUOTE] This is meant to be a considerable block of text, reaching over several lines and so displaying the wrap issues. I just hope that this is long enough for the windows I'll usually be using.
[PRE] This is meant to be a considerable block of text, reaching over several lines and so displaying the wrap issues. I just hope that this is long enough for the windows I'll usually be using.
An email link. Commas optional between addresses. [A href="mailto:steve steve@dcs"]
A basic link [A href="std/howtoref.html"]
A popup link [A href="default.html#0" target="new"]
[A name="atarget"][/A] A target to which other links can jump within a document.
< A .. > links need not just be URLs
HREF is a url: link as a link: std/howtoref.html
Button as a link:
A basic picture link [IMG SRC="button1.GIF"] This text
acts as a label, but just follows it.
[IMG SRC="button1.GIF" WIDTH="35" HEIGHT="35" BORDER="0" ALT="*"]
Correct usage: width etc. lets browsers lay out the page correctly before fetching the image; ALT gives a text alternative for when images are disabled.
[A HREF="SteveDraper.GIF" target="new"] [IMG ALT="Link" SRC="button2.GIF" WIDTH=21 HEIGHT=21 BORDER=2][/A]
Image as a link (button), with border.
To get a picture centered on the page, embed in a table that is centred < TABLE align="center">< TR>< TD> < IMG SRC=maped.gif width=391 height=688 > < /TABLE>< /TR>< /TD>
To see how to get text flow-round an IMG or indeed other object, see demot.html.
< Acronyms: incomplete note on a new tags for acronyms This CSS: This NSS:
menus, lists, headers, tables
See 'DOCcss' for explanations. Value here is usually -1em, but can be 0.
You can also start with any number, and have various styles of number:
||this is cell 2, row1|
|this is cell 1,
|this is cell 2,
See also ~/bin/wtable.
And demot.html for using tables to get figure captions.
Forms seem to have basic facilities you might want to use, not necessarily for forms, for:
Thus you can consider mixing them with the other standard mechanisms:
Forms have items; any item (displayed or not) that has both a name and a value, will have that encoded and sent as: url?name=val1&name2=val2&name3=val3+word3b.... Buttons (type "submit") will also have their value sent iff they have both name and value defined. (Their value is the button label, so you may see buttons with value but no name.)
Cookies are an alternative. Now part of the HTTP protocol: server specs them by putting in a "Set-Cookie: " line/field in the HEAD of a response. They may also be set by Java within a page sent to the user. A browser will send it back as part of any GET request if the URL matches (of cookie against the request the browser is making). Cookies have expiry dates (if none, then deleted when browser is quitted). Their content are mainly name=value pairs. See the Wiki entry. Main use: maintaining state, preventing repetitive logins, shopping baskets etc. But also used for logging users' access to a site across time. If cookies are visible to browser-java, then theft of cookies from other servers becomes possible.
< embed> reads in (#include) another file; meant for plugins.
< EMBED SRC="../graphics/sounds/1812over.mid" HEIGHT=60 WIDTH=144>
< EMBED SRC="q.pdf">
< IFRAME> like EMBED, used for video insert into page body. See demot.html.
The first method will work for all URLs within server's domain, not just for real pages or page names within user-author's control. The rest of the methods only work for redirecting from pages within the user-author's control.
Though this might be fixable by adding line to page inside < HEAD> < BASE href="http://www.psy.gla.ac.uk/~steve/dir/tmp/"> to spec. the new location file root. So: a) move main copy of file to new place; b) add BASE to spec this file root; c) edit internal URLs or move dependent files (IMGs etc.) with it. d) link to it from old file location (and others).
This uses a refresh command with zero delay (or put in 1 or 5 seconds).
It does depend on the browser implementing this non-essential facility, but
most do (e.g. netscape 3). It commands the browser to pretend it received an
extra header line in the HTTP exchange. Shouldn't there be a "redirect" http
command/ header line?
[Won't work for IMG fetched files.]
[Won't work for IMG fetched files.]