File: syntax_error.html

package info (click to toggle)
netrik 1.16.1-2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, sid, stretch
  • size: 3,272 kB
  • ctags: 729
  • sloc: ansic: 6,657; sh: 994; makefile: 114
file content (164 lines) | stat: -rw-r--r-- 5,957 bytes parent folder | download
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
153
154
155
156
157
158
159
160
161
162
163
164
<html>
<head>
<title>Syntax error handling</title>
</head>
<body>

<h1 align="center">Syntax error handling<br />>=======================&lt;</h1>

<p>
[This file explains how netrik handles syntax errors in HTML pages, why it does
so, and what to do about that. See index.txt or
<a href="index.html">index.html</a> for an overview of available
netrik documentation.]
</p>

<p>
or:
</p>

<h2>Why does netrik always complain about HTML syntax errors??</h2>

<p>
or:
</p>

<h3>No matter what site I load, (almost) always I get error messages. That can't be OK?!</h3>

<p>
Well, it *is* OK... The problem is: Actually almost all sites *are* more or
less broken.
</p>

<p>
Other browsers simply ignore the errors, hoping that the effect will resemble
more or less what the author intended -- and nobody ever knows, but for some
little blemish maybe, where no one cares about. (If Netscape wasn't so tolerant
about syntax errors in the first place, we wouldn't have that problem today :-(
) However, the browser can only "guess" what the author intended, and that
doesn't always work out; such errors can cause the page to be layouted
completely wrong, including missing text parts etc. That's why netrik warns
about them, so the user at least knows what the matter is, and also gets the
chance to tell the page author about the problem. (s.b.)
</p>

<p>
Note that XHTML even *requires* a browser to abort on syntax errors -- sadly,
XHTML is not very popular. (Yet?...)
</p>

<p>
Of course, it might also happen that netrik sees an error where there is none
-- but this is rather rare, and would indicate a bug in netrik. Of course, if
you encounter such a situation, don't hesitate to send a bug report. ($
<a href="mailto:netrik-general@lists.sf.net">netrik-general@lists.sf.net</a>$
)
</p>

<h2>Can't I turn that off?</h2>

<p>
Well, actually, you can: There are the two options "--broken-html" and
"--ignore-broken". "--ignore-broken" will prevent netrik complaining about
*any* syntax errors, while "--broken-html" only turns off warnings about common
errors which in most cases can be guessed correctly and nicely worked around.
(But not always!)
</p>

<p>
Presently, "--broken-html" is the default, so less critical erros won't cause
netrik to stop and wait for keypress. (The error messages are still displayed,
but they just scroll through in this mode.) This is because the current
interface makes the warnings quite obtrusive; we will change the default again
when a better UI will allow displaying the messages in a less disturbing
manner.
</p>

<p>
However, please avoid usage of these options if possible. While "--broken-html"
probably can't be helped for now, it seems generally a bad idea to use
"--ignore-broken".
</p>

<p>
Still, please take the (little) trouble to tell the page author about the
problem.
</p>

<h2>Reporting a problem</h2>

<p>
Normally you will find an e-mail address of the right contact at the bottom of
the page, or on some "contact" page. Most authors will be greatful for the
information, and will gladly fix the problem -- once and for all.
</p>

<p>
You can improve your chances by telling exactly what the problem is. To find
out, you can load the page again, but using the "--debug" option. While parsing
the page, netrik will dump the source in this mode. When an error is
encountered, the last charactacter printed before the error message is the
offending one. Note however that in some cases the real reason for the problem
may be somewhere before.
</p>

<p>
If the output is too big, you may either use the --dump option and pipe the
output through some pager (but note that the debug output is written to stderr,
so you'll need to redirect it: "netrik --debug --dump &lt;url> 2>&amp;1 |less -R" or
something the like), or you can use the "--fussy-html" option, causing netrik
to abort after the first error is detected.
</p>

<p>
Alternatively, you can use the W3Cs (WWW Consortium) HTML validating service.
(<a href="http://validator.w3.org">http://validator.w3.org</a>)
This will create a report with all problems nicely listed -- very helpful for
the page author.
</p>

<h2>A note on comments</h2>

<p>
Netrik implements full SGML comment parsing. The problem is that the comment
syntax in SGML is fairly complicated; most authors do not know it, and thus do
not know that putting a "--" string inside a comment normally generates errors.
In most cases these are quite obvious; netrik will print an error message, and
use a workaround which will work in most cases, but not always -- just like for
other typical errors.
</p>

<p>
However, there are some constructs which *are* valid SGML -- but do not make
what the author probably intended. "&lt;!------>" is a typical example: It is
valid, but the comment doesn't terminate; everything behind it will also be
treated as part of the comment! As it is not an error, netrik can't print an
error message or apply a workaround; instead, just a warning is printed.
</p>

<p>
Often such an unterminated comment will generate other errors later, because it
interferes with other comments or because it stretches to the end of the file;
in such a case, the warning may help finding the problem. In other cases
however, no error is generated at all -- the warning is the only cue that
something went wrong.
</p>

<h2>Warnings in general</h2>

<p>
Other similar situations are thinkable. That's why netrik also prints warnings
on things that are strictly speaking valid hatml, but explicitly discouraged
in the HTML standard -- while some browsers will handle them correctly, others
might do otherwise; or sometimes a really correct behaviour even produces
results different from what the author intended and sees in popular browsers.
</p>

<p>
Warnings will normally (in --valid-html or --broken-html mode) only scroll
through, but without pausing with an additional message after parsing is
finished. To see all warnings, use --clean-html .
</p>

</body>
</html>