|
|
Posted by robert maas, see http://tinyurl.com/uh3t on 02/16/07 01:43
> From: John Hosking <J...@DELETE.Hosking.name.INVALID>
> >>>That's not very useful at all when the error is reported several
> >>>thousand lines after where the actual error happened.
> >>Not very useful, but useful. Knowing whether there is an error or
> >>not is more information than not knowing whether there are errors
> >>or not.
> "Several thousand lines after where the actual error happened" would
> indeed be a pain. But from what I saw in your OP and subsequent posts,
> that wasn't the actual case. In fact, all the action occurred within
> Line 1353.
OK, the "several thousand" was a slight exaggeration. I should have
said "more than one thousand".
I don't know what you mean by "the action". The error message cited
only line 1353, but in fact the error was caused by a mistake
somewhere previously in the file which entered a mode not supported
by any Web browser (and flagged at *that* location by the *other*
validator), and that place where the actual error happened *could*
have been anywhere in the first 1352 lines of the file and would
still have resulted in that exact same validation error noted on
1353. So the anti-diagnostic merely told me that somewhere in the
first 1353 lines of the file I had made some mistake that finally
caused an actual syntax error on line 1353.
The GNU C compiler has the decency to tell me, when it sees gross
syntax garbage immediately after the close of a multi-line string,
that although the error was noted at this point the start of the
string was way up on such-and-such line so the actual error might
really be here. That indeed happened a couple times in producing
the test programs I've been discussing in another thread. The 'n'
key on my keyboard has been very flaky lately, and sometimes when I
type a string whose last logical character is the two-character
notation \n the n is missed, and I don't happen to see it while
typing, so the \ doesn't make a newline, it quotes the closing
quote mark *within* the string, allowing the string to continue
several more lines of the program until finally there's another
string literal, and the start of that literal *ends* the multi-line
string, and the innerds of that string literal are parsed as if c
syntax, immediately causing a gross syntax diagnostic. But the
helpful advice from GNU c compiler that the string started way back
there gives me an immediate clue (because in c I *never* write
multi-line string literals, I always use \n within strings instead,
at least I try to when my keyboard cooperates). I wish the
validator would likewise note something like this:
You started a NET 20 lines earlier:
<p />In the descriptions of the built-in functions which take keyword arguments,
^
which finally terminated here on line 1353:
<br /><em>(reduce #'/ nums :end 9)</em>
^
which might be responsible for the validation error which occurred
almost immediately next in your file:
<br /><em>(reduce #'/ nums :end 9)</em>
^
whatever...
> http://www.w3.org/TR/html401/struct/text.html#h-9.3.2
Start tag: required, End tag: forbidden
It doesn't say anything about empty tag. Allowed or forbidden??
9.3.4 Preformatted text: The PRE element
it doesn't say how to suppress the blank line at the end of each PRE element.
Also this entire section doesn't say which doctype it's applicable to.
For example, is it applicable to "transitional" or not?
Actually it looks like you have provided no links to HTML/XHTML
transitional at all.
> XHTML: <br/> and <hr/> or <hr></hr>
> http://www.w3.org/TR/xhtml1/#h-4.6
CORRECT: terminated empty elements
<br/><hr/>
INCORRECT: unterminated empty elements
<br><hr>
I originally tried <br/> (no space between br and /), but the
browser barfed on it, so I tried inserting the blank, and then it
worked fine. By the way, here are the homework assignments for that
"Web Design" class where I learned how to do "transitional" Web
pages: <http://www.rawbw.com/~rem/CIS89a/>
Those pages are littered with <br /> all over the place, and the
instructor who looked at all the pages (both source and as
displayed) never made one complaint about any of those empty-br
elements. By the way, she never mentionned the validation service,
and in fact those class assignments fail validation, so obviously
she didn't run the validator on our class assignments or she would
have noticed our grossly invalid HTML/XHTML transitional code, so
more and more I suspect the instructor was totally incompetant, was
just faking her way through teaching her first class in America
after miagrating from India.
> XHTML Appendix C: <br /> and <hr />
> http://www.w3.org/TR/xhtml1/#C_2
Include a space before the trailing / and > of empty elements, e.g.
<br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the
minimized tag syntax for empty elements, e.g. <br />, as the
alternative syntax <br></br> allowed by XML gives uncertain results in
many existing user agents.
Well, per that, I was doing exactly the right thing!!
Why are you all complaining???
C.3. Element Minimization and Empty Element Content
Given an empty instance of an element whose content model is not EMPTY
(for example, an empty title or paragraph) do not use the minimized
form (e.g. use <p> </p> and not <p />).
Hmm, I've started doing <p></p> instead, i.e. no space between the
opening and closing paragraph delimiters. Is that wrong??
> it *is* a start-tag *itself*, but it enables a null end tag.
Ah, thanks for clearing up my confusion on the jargon usage.
> I don't think he used any characters which the VT100 would mangle, ...
So why does he throw in the red herring of specifying his MIME
charaset as that special Windows thing I never heard of before his
post?? (I wouldn't have noticed it except that particular header
field was spread over about five physical lines, causing the most
important part of the header way down at the bottom to overflow to
the next screen so I had to go to extra work to copy&paste it in
with the rest of the header that was near the top of the first
screen. When I went back to see what was taking up so fucking much
space, I found that charset red herring.)
> If this is exactly what she said (i.e., that's *all* she said
> about it, dogmatically), then she left out some important info.
Well her heavy Indian accent made it hard to understand her, and
it's *possible* she in fact does not know American English sentence
structure well enough to even formulate the correct sequence of
words to express what she had in mind. Or, given that she wasn't
even aware of the validator, or the extra header needed so it
wouldn't have to *guess* the charset we're using, she might just
have been incompetant at the topic she was "teaching".
> Transitional is for legacy documents not yet cleaned up to
> validate as strict.
She wanted all our *new* documents to be transitional, so they'd
still "work" in existing Web browsers, yet they'd already work in
future XML-based Web browsers. It had nothing to do with any legacy
documents. If you look at the class assignments (URL earlier
above), one very early assignment was to make a template which
would then be copied as the starting point for all future
assignments which would all be brand-new from-scratch (well
from-template) pages. Please take a look at that template and tell
me if there's anything wrong with using it for brand-new documents.
> I don't know when you had your course,
Like I said earlier in this thread (but it's easy to overlook): 2.5
years ago. The exact dates are given in the headers of each
homework assignment.
> but there *was* a time when specifying a transitional doctype was
> good advice (or at least, widely recommended; Jukka or BTS or
> somebody will have the details).
When was that?
By the way, slightly related topic: The next semester after that,
one of my instructors gave me his old laptop, and sometime later I
decided to try my hand at JavaScript on it, got my first demo
working, uploaded it to my Web site, and tried it from the public
library, and it did't work. Turns out JavaScript has suffered an
incompatible change, such that it's impossible to write a script
that performs certain stuff and works in both the old version (on
my laptop) and the new version (elsewhere). If you're curious:
<http://groups.google.com/group/comp.lang.javascript/msg/ecf27d895294dd1a>
= Message-ID: <REM-2005jun15-002@Yahoo.Com>
> For *new* pages, or pages you are actively maintaining, go with HTML
> 4.01 strict, unless you have a bona fide reason to use XHTML.
http://groups.google.com/group/alt.support.diet/msg/7570305b77c13cc7
= Message-ID: <260820030806550860%cma@sympatico.ca>
I try to please everyone and I end up carrying a donkey on my back.
I give up. There's no way to write Web pages that are acceptable.
> > - Never use an opening tag without the matching close tag.
> > As you point out, neither br nor hr is compatible with those two
> > rules.
> Sure they are. You're letting yourself get confused.
Well if you think you can find a way to use a br or hr without
violating one of these rules:
Start tag: required, End tag: forbidden
INCORRECT: unterminated empty elements <br><hr>
Feel free to tell how to use BR or HR in HTML/XHTML transitional documents.
Navigation:
[Reply to this message]
|