1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>hsc - Features - Syntax Definition</TITLE>
<LINK REV="owns" TITLE="Thomas Aglassinger" HREF="mailto:agi@giga.or.at">
<LINK REL="Next" HREF="exec.html">
<LINK REL="Copyright" HREF="../copy.html">
<LINK REL="Previous" HREF="if.html">
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
</HEAD>
<BODY>
<A HREF="../index.html"><IMG SRC="../image/main.gif" ALT="Contents" ALIGN="middle" WIDTH="70" HEIGHT="16"></A>
<IMG SRC="../image/noindex.gif" ALT="-----" ALIGN="middle" WIDTH="70" HEIGHT="16">
<A HREF="../copy.html"><IMG SRC="../image/copy.gif" ALT="Copyright" ALIGN="middle" WIDTH="70" HEIGHT="16"></A>
<A HREF="../index.html"><IMG SRC="../image/back.gif" ALT="Up" ALIGN="middle" WIDTH="70" HEIGHT="16"></A>
<A HREF="if.html"><IMG SRC="../image/prev.gif" ALT="Previous" ALIGN="middle" WIDTH="70" HEIGHT="16"></A>
<A HREF="exec.html"><IMG SRC="../image/next.gif" ALT="Next" ALIGN="middle" WIDTH="70" HEIGHT="16"></A>
<HR>
<H1>Syntax Definition</H1>
<P>Everything <KBD>hsc</KBD> knows about html, it retrieves from a
file named <I>hsc.prefs</I> at startup. This file contains
information about all tags, entities and icon entites.
Additionally, some <A HREF="spcattr.html">special
attributes</A> are set up there also.</P>
<P>The main advantage of this concept is that it's rather
easy to add new syntax elements. For this task, the hsc tags
<A HREF="prefs.html#deftag"><CODE><$deftag></CODE></A>, <A HREF="prefs.html#defent"><CODE><$defent></CODE></A> and <A HREF="prefs.html#deficon"><CODE><$deficon></CODE></A> can be used.</P>
<H2><A NAME="default">Default Preferences</A></H2>
<P>It is a serious problem about html that no one can give you competent
answer on the question ``Now which tags are part of html?''. On the
one hand, there is w3c, which you meanwhile can ignore, on the other
hand, there are the developers of popular browsers, which implement
whatever they just like.</P>
<P>The <I>hsc.prefs</I> coming with this distribution should support most
elements needed for everyday use. This includes full html-2.0-support,
tables, client-side image-maps and several elements only used by
special browsers.</P>
<P>However, they are currently rather outdated and could need a major
rework. This should come with one of the next releases.</P>
<H2><A NAME="search">Searching For The Preferences</A></H2>
If you do not explicitely specify certain preferences by means of the
CLI-option <A HREF="../options.html#prjfile"><KBD>PREFSFILE</KBD></A>, <KBD>hsc</KBD> will look at several places when
trying to open <I>hsc.prefs</I>:
<UL>
<LI>the current directory
<LI>the directory specified in the environment variable <A HREF="../envvar.html#hscpath"><VAR>HSCPATH</VAR></A>
<LI>the directory <CODE>PROGDIR:</CODE>, which is automatically
assigned to the same directory where the <KBD>hsc</KBD> binary resides
when <KBD>hsc</KBD> is invoked
</UL>
<P>If it is unable to find <I>hsc.prefs</I> anywhere, it will abort with
an error message.</P>
<P>If you want to find out where <KBD>hsc</KBD> has read <I>hsc.prefs</I> from,
you can use <KBD><A HREF="../options.html#status">STATUS=VERBOSE</A></KBD>
when invoking <KBD>hsc</KBD>. This will display the preferences used.</P>
<H2><A NAME="tags">Special Tags To Modify Syntax Definition</A></H2>
All the tags below should be used within <I>hsc.prefs</I> only.
<H3><A NAME="defent">Define an entity</A></H3>
<P>This tag defines
a new entity. The (required) attribute <CODE>NAME</CODE> declares the
name of the entity, <CODE>RPLC</CODE> the character that should be
replaced by this entity if found in the hsc-source and <CODE>NUM</CODE>
is the numeric representation of this entity.</P>
<STRONG>Example:</STRONG> <CODE><$defent NAME="uuml" RPLC="ü" NUM="252"></CODE>
<H3><A NAME="deficon">Define icon-entity</A></H3>
<P>This tag defines
a new icon-entity. The only (required) attribute is <CODE>NAME</CODE>
which declares the name of the icon.</P>
<STRONG>Example:</STRONG> <CODE><$deficon NAME="mail"></CODE>
<H3><A NAME="deftag">Define a tag</A></H3>
<P>This tag defines
a new tag, and is used quite similar to <A HREF="../macro/macros.html"><CODE><$macro></CODE></A>, exept that a
tag-definition requires no macro-text and end-tag to be followed.</P>
<STRONG>Example:</STRONG> <CODE><$deftag IMG SRC:uri/x/z/r ALT:string ALIGN:enum("top|bottom|middle") ISMAP:bool WIDTH:string HEIGHT:string></CODE>
<P>To fully understand the above line, you might also want to read the sections
about <A HREF="../macro/attrib.html">attributes</A>
and <A HREF="../macro/flag.html">options</A> for tags and macros.</P>
<P>For those, who are not smart enough or simply to lazy, here are some
simple examples, which should also work somehow, though some features of
<KBD>hsc</KBD> might not work:</P>
<PRE>
<$deftag BODY /CLOSE BGCOLOR:string>
<$deftag IMG SRC:uri ALT:string ALIGN:string ISMAP:bool>
</PRE>
<H2>Why It Can Not Read DTDs</H2>
DTD is short for Document Type Definition. One of the early concept of
html was that the first line of a document should contain a line that
tells which DTD has been used to create this document. This could look
like
<PRE><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"></PRE>
<P>Browsers should read that line, obtain the DTD and parse the source
according to it. The problem about DTDs: they are written in sgml. And
the problem about sgml: It's awful. It's unreadable. It's a pure
brain-wanking concept born by some wireheads probably never seriously
thinking about using it themselves. Even when there is free code
available to sgml-parse text.</P>
<P>As a result, only less browsers did support this. As it was rather
easy to write a browser spiting on the sgml-trash, but simply parsing
the code ``tag-by-tag'', developers decided to spend more time on
making their product more user-friendly than computer-friendly (which
really can understand).</P>
<P>These browsers became even more popular when they supported tags
certain people liked, but were not part of DTDs. As DTDs were
published by w3c, and w3c did not like those tags, they did not made
it into DTDs for a long time or even not at all (which I really can
understand, too).</P>
<P>This did work for a certain degree until html-2.0. Several people
(at least most of the serious w3-authoring people) did prefer to
conform to w3c than use the funky-crazy-cool tags of some special
browsers, and the funky-crazy-cool people did not care about DTDs or
html-validators anyway.</P>
<P>However, after html-2.0, w3c fucked up. They proposed the infamous
html-3.0 standard, which was never officially released, and tried to
ignore things most browsers did already have implemented (which not
all of them were useless crap, I daresay.). After more than a year
without any remarkable news from w3c, they finally canceled html-3.0,
and instead came out with the pathetic html-0.32.</P>
<P>Nevertheless, many people were very happy about html-0.32, as it
finally was a statement after that many things became clear. It became
clear that you should not expect anything useful from w3c anymore. It
became clear that the browser developers rule. It became clear that no
one is going to provide useful DTDs in future, as browser developers
are too lazy and incompetent to do so. It became clear that anarchy
has broken out for html-specifications.</P>
So, as a conclusion, reasons not to use DTDs but an own format are:
<UL>
<LI>It's more readable, and users can change it easier, even without reading three books about sgml and analysing
20 example sources.
<LI>It has been easier for me to implement, even without reading three books about sgml and analysing
20 example sources.
<LI>One does not depend on w3c. (Sad, that this is a reason.)
<LI>The format for <I>hsc.prefs</I> contains some information, which makes
is possible to for example evaluate image-sizes or strip tags with
absolute URIs. This is realised with special attribute modifiers
which have no equivalent in DTDs.
</UL>
<P>Quite unexpected, with html-4.0 this has changed for some extent,
as the DTDs are quite readable and well documented. Although it will
take them more than this to get back the trust they abused in the
recent years, at least it is a little signal suggesting there are some
small pieces of brain intact somewhere in this consortium.</P>
<H2>Problems</H2>
<P>There is also a disadvantage of this concept: reading <I>hsc.prefs</I>
every time on startup needs an awful lot of time. Usually, processing
your main data takes shorter than reading the preferences. You can
reduce this time, if you create your own <I>hsc.prefs</I> with all tags and
entities you don't need removed. But I recommend to avoid this because
you might have to edit your preferences again with the next update of
<KBD>hsc</KBD>, if any new features have been added.</P>
</BODY></HTML>
|
