What's wrong with this HTML (fails validation) ?

[robert maas, see http://tinyurl.com/uh3t]

The URL for my Web page is:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/CookTop.html>
The validation site is:
<http://validator.w3.org/>
When I ask it to validate my Web page, it gives me this error:
1. Error Line 1353 column 14: end tag for "EM" omitted, but its
declaration does not permit this.
<em>(reduce #'/ nums :end 9)</em><br />
+ You forgot to close a tag, or
+ you used something inside this tag that was not allowed, and
the validator is complaining that the tag should be closed
before such content can be allowed.
The next message, "start tag was here" points to the particular
instance of the tag in question); the positional indicator points
to where the validator expected you to close the tag.
✉
2. Info Line 1353 column 0: start tag was here.
<em>(reduce #'/ nums :end 9)</em><br />
3. Error Line 1353 column 32: end tag for element "EM" which is not
open.
<em>(reduce #'/ nums :end 9)</em><br />
The Validator found an end tag for the above element, but that
element is not currently open. This is often caused by a leftover
end tag from an element that was removed during editing, or by an
implicitly closed element (if you have an error related to an
element being used where it is not allowed, this is almost
certainly the case). In the latter case this error will disappear
as soon as you fix the original problem.

The / it's complaining about is in the middle of ordinary text, not
within any tag, so why is it even looking there to find anything
wrong? There's an opening EM tag at the start of the line, and a
matching closing tag near the end, with no tags of any kind
between. I see nothing wrong. What am I overlooking?

 

[Jonathan N. Little]

The URL for my Web page is:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/CookTop.html>
The validation site is:
<http://validator.w3.org/>
When I ask it to validate my Web page, it gives me this error:
1. Error Line 1353 column 14: end tag for "EM" omitted, but its
declaration does not permit this.

<snip>

Don't now about that but one error is on line 53
.... and auto-repeated units (loops)<</a>/li>
^

And you have diagrams with '<' & '>' your need to encode entities for
especially in *X*HTML

&lt; &gt;

 

[Andy Dingley]

The URL for my Web page is:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/CookTop.html>

1. Error Line 1353 column 14: end tag for "EM" omitted, but its
declaration does not permit this.
<em>(reduce #'/ nums :end 9)</em><br />

Congratulations! You might be one of the very few people to ever post
about validation problems here and to have actually exposed a real
flaw in the validator.

Your code is bogus, although probably not actually invalid. It's
littered with <p /> <br /> and <hr /> tags.

* This is HTML, not XHTML, so <br /> is wrong - just use <br>

* Your <p> elements aren't empty, so the empty tag <p /> is wrong.

* You appear to have confused <p> "paragraph wrapper element" with a
notion of it as "paragraph spacer tag". Replace [...] <p /> [...]
with <p>[...]</p> <p>[...]</p>

The try re-validating it.

It seems that the validator recently changed behaviours and started
accepting <br /> as valid HTML, when it used to reject it outright. I
haven't looked at the details, but there's a recent thread on it. This
is _strictly_ true, but horribly misleading to authors.

I neither know nor care whether this will cause the problem with <em>
that you're actually reporting. It's just not worth chasing these odd
ones until you've fixed the obvious stuff. One characteristic of
validators like this is that they usually report an error long after
the condition that really caused it.

 

[Rik]

The URL for my Web page is:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/CookTop.html>
The validation site is:
<http://validator.w3.org/>
When I ask it to validate my Web page, it gives me this error:
1. Error Line 1353 column 14: end tag for "EM" omitted, but its
declaration does not permit this.
<em>(reduce #'/ nums :end 9)</em><br />
+ You forgot to close a tag, or
+ you used something inside this tag that was not allowed, and
the validator is complaining that the tag should be closed
before such content can be allowed.
The next message, "start tag was here" points to the particular
instance of the tag in question); the positional indicator points
to where the validator expected you to close the tag.
✉
2. Info Line 1353 column 0: start tag was here.
<em>(reduce #'/ nums :end 9)</em><br />
3. Error Line 1353 column 32: end tag for element "EM" which is not
open.
<em>(reduce #'/ nums :end 9)</em><br />
The Validator found an end tag for the above element, but that
element is not currently open. This is often caused by a leftover
end tag from an element that was removed during editing, or by an
implicitly closed element (if you have an error related to an
element being used where it is not allowed, this is almost
certainly the case). In the latter case this error will disappear
as soon as you fix the original problem.

The / it's complaining about is in the middle of ordinary text, not
within any tag, so why is it even looking there to find anything
wrong? There's an opening EM tag at the start of the line, and a
matching closing tag near the end, with no tags of any kind
between. I see nothing wrong. What am I overlooking?

<p /> does not mean what you think it means.... A simple seach/replace
with <p> makes it valid.

Someone just recently pointed that out on a newsgroup, that in SGML
there's a shorttag feature of some kind, so that <h1/This is a header/ is
possible.

So:
<p /> Some text and then some and a / and then some more.
Is actually:
<p>> Some text and then some and a </p> and then some more.

I'm not aware of a browsers that renders it that way, but there's your
answer.

 

[Rik]

And to bring it back to it's bare minimum (see
<http://www.positioniseverything.net/articles/mys-bug.html>, it's as true
for any script as for CSS):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3c.org/TR/html4/loose.dtd">
<html>
<head>
<title>"CookBook" toplevel</title>
</head>
<body>
<p /> Now we start another tag <em> which will be implicitly closed be the
following slash / Yes, the one we just had, as it closes the paragraph. So
this closing tag</em> doesn't close anything anymore, and will result in
yet another error.
</body>
</html>

 

[Rik]

And to bring it back to it's bare minimum (see
<http://www.positioniseverything.net/articles/mys-bug.html>, it's as
true for any script

and/or markup

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

Congratulations! You might be one of the very few people to ever post
about validation problems here and to have actually exposed a real
flaw in the validator.

Actually, no. He was however one of the few people who post about validation
problems and provide sufficient information, namely a URL.

Your code is bogus, although probably not actually invalid.

It is actually invalid; see Rik's answers, or check
http://www.cs.tut.fi/~jkorpela/html/empty.html
(which discusses a more common problem, limited to XHTML-like syntax for
empty elements, where the issue is different - since a validator knows that
an HTML element like <br> has EMPTY declared content, it effectively treats

It's littered with <p /> <br /> and <hr /> tags.

Yes, that's the practical markup problem, and easy to fix.

* Your <p> elements aren't empty, so the empty tag <p /> is wrong.

<p /> would be wrong even for an empty paragraph. By HTML rules, "<p /"
starts shorthand markup that will cause a matching "/" to be looked for. By
XML rules, "<p />" is a self-closing element, but the use of that syntax is
disallowed in XHTML that pretends to be compatible with "HTML user agents",
by the infamous Appendix C.

It seems that the validator recently changed behaviours and started
accepting <br /> as valid HTML, when it used to reject it outright.

Nope. I don't think there's any change. <br /> is formally valid HTML, it
just _means_ <br>>. It causes no error message. <hr /> might, in Strict HTML
4.01 in a context where only block-level elements are allowed, as directly
inside <body>, but that would be an error due to the ">".

 

[Andy Dingley]

Actually, no.

I would regard this as a flaw in the validator, in that it indicates
that simplistic pure DTD-based validation isn't adequate for an entry-
level HTML validator for use by inexperienced authors.

The OP has thrown their bogus code at the validator and they've
receieved an error message that's basically useless. This isn't a good
situation. Although three experienced HTML authors quickly spotted
the real problem, they did this by eyeballing the code, not owing to
any help from the validator.

It is actually invalid; see Rik's answers, or checkhttp://www.cs.tut.fi/~jkorpela/html/empty.html

Of course it's invalid in this case, the validator told us as much. I
was writing of the broader case where the mere use of <br /> or <p />
alone isn't always enough to make it invalid (after all, this page
managed 1300 lines before actually breaking).

Nope. I don't think there's any change.

But if my fallible memory serves, this did used to be flagged as an
error? (the nit-picking valid interpretation notwithstanding) It
seems a backward step to have changed this. I suspect that it was done
to reduce "false positives"(sic) on Appendix C XHTML with <br />, but
that's far from a good thing to permit under a HTML doctype.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

I would regard this as a flaw in the validator, in that it indicates
that simplistic pure DTD-based validation isn't adequate for an entry-
level HTML validator for use by inexperienced authors.

The very meaning of "validation" in HTML context is "simplistic pure
DTD-based validation". If you want something else, give it some other name,
instead of confusing things by blaming a validator for being a validator.

Of course validation is of limited usefulness and can actually cause
problems instead of solving them. But that's a different issue.

The only reasonable reasons for recommending validators to Joe Wannabe
Webauthor is that they detect and report _some_ errors and the other
available HTML checkers confuse even more e.g. by issuing completely wrong
error messages and foolish warnings that reflect just their author's taste
and misconceptions.

The OP has thrown their bogus code at the validator and they've
receieved an error message that's basically useless.

The useful thing is that the validator reports the existence of an error.
The rest is more difficult, but as usual, we might expect people to check
back their HTML textbooks and tutorials when they encounter error messages.
Checking is not a substitute for learning and understanding.

Of course it's invalid in this case, the validator told us as much. I
was writing of the broader case

Here we go. "Invalid" and "valid" are well-defined words in the HTML
context. Leave it at that. You're not the guy drops here once a year to
advertize a phoney "validator", are you?

But if my fallible memory serves, this did used to be flagged as an
error?

Hardly. It would be an error to flag a valid document as erroneous.

You might confuse the W3C validator with the WDG validator
http://www.htmlhelp.com/tools/validator/
which gives (and has given for years) a useful warning, even though this is
strictly speaking outside the scope of a validator:

<br />
^Warning: net-enabling start-tag; possibly missing required quotes
around an attribute value

(It would be more understandable with "net" spelled as "NET" and with the
addition "or attempt to use XHTML syntax".)

 

[robert maas, see http://tinyurl.com/uh3t]

Don't now about that but one error is on line 53
... and auto-repeated units (loops)<</a>/li>

Ah, thanks! The validation site totally failed to notice that! I
searched for all instances of <<, found that and another <</a>
later too, and found the several COUT << stuff in C++ examples and
changed them to use &lt; (I thought I had all those but I guess I
missed that one line with about six of those). I also looked for >>
just in case, but didn't find any at all in the whole file.

Checking validation again after just those fixes ... nope, didn't
help. Still got the same error at line 1353 as before.

And you have diagrams with '<' & '>' your need to encode entities
for especially in *X*HTML

I'm going to do one complete pass through the file searching for *all*
references to any of those three characters, which will take quite
a while, starting at 19:17 looking for & ... done at 19:19, not
a single mistake found, you must be halucinating, looking for all
instances of < next ... found this bogus syntax:
<li><a href="#deci">Decisions (branches) and auto-repeated units (loops)</a>/li>
Why did the validator miss that?? Fixing it now.
Found this bogus line:
Anything I haven't yet included might ... cited there.<br>
Should read, fixing it now:
Anything I haven't yet included might ... cited there.<br />
That's the sort of thing that could cause the symptom, so I'm re-validating
before finishing this scan, at 19:24 ... didn't help, back to scan...
I'm suspicious of this:
enter two numbers, with a space between them, such as
<pre>42 69</pre>on a single
line of input? Lisp will read the 42, and print it out on a new line.
So I'm going to spread it all out just to be safe:
enter two numbers, with a space between them, such as
<pre>
42 69
</pre>
on a single
line of input? Lisp will read the 42, and print it out on a new line.
Resuming the scan at 19:20 only 17% through the file... this is
taking too awfully long! At 19:34 I'm only 39% through the file.
I'm going to jump to the place where the problem occurs and search
backwards from there ... I don't see anything wrong for several screens.
I don't think this is the problem. I'm going to abort this scan and
read the rest of the ideas in the thread.

But thanks for that one correction, which helped me find another
just like it, even if that didn't fix validation.

 

[robert maas, see http://tinyurl.com/uh3t]

It is actually invalid; see Rik's answers, or check
http://www.cs.tut.fi/~jkorpela/html/empty.html
(which discusses a more common problem, limited to XHTML-like
syntax for empty elements, where the issue is different - since a
validator knows that an HTML element like <br> has EMPTY declared
content, it effectively treats <br/> just as <br>> without looking
for a matching "/").

Shit! I took a class at De Anza College (in Cupertino, CA), where
the instructor emphased strongly that we must **stop** writing our
Web pages in old HTML that is incompatible with XML, instead
absolutely *must* write all Web pages in HTML->XHTML transitional,
where we absolutely must not use any <tag> without the matching
</tag>, not even <br> or <p>, but we *are* allowed to liberally use
<tag/> or <tag /> when we don't enclose anything. She was fucking
wrong, I now learn! Thanks a lot!!

Because there's a possible problem with <p /> leading into the
place where the validator "found" a problem, that according to the
"Web Design" instructor doesn't have anything wrong with it, I
laborously changed all the paragraphs leading into that part of the
file to have <p>...</p>, and to avoid all use of the br element
whatsoever, using <pre>...</pre> instead whenever I want one or
more single lines with no rearranging of line breaks.

Now it passes validation! Thanks! (I think so. I haven't yet looked
at the document to see whether it looks all trashed now. Gonna take
my first look at my PLASTIC FACIAL SURGERY / FACE TRANSPLANT now
... yuk!! Now instead of flowing paragraphs with unbroken lines in
the middle, the pre element causes a blank line after each section,
and also the p element causes a blank line *before* the paragraph
but not after. Does anybody know a way to avoid that blank line
after a pre section, and before a paragraph?? I've been needing
that information for years, but this seems to be my first chance to
ask the real experts!!)

I want it to look like this:
The meaning of that is that arg1 arg2 thru argz are each required, but
then any combination of the keywords may be used, each a pair of the
keyword itself and the corresponding value. For example, here's a
description of a function's calling conventions in that notation:
(make-hash-table &key :test :size :rehash-size :rehash-threshold)
***No blank line here***
where there are no required arguments, only keyword arguments, so all
of the following forms of call are syntactically valid:
(make-hash-table)
(make-hash-table :test 'equal)
(make-hash-table :size 300)
(make-hash-table :size 300 :rehash-size 1.8)
(make-hash-table :test 'equal :size 300)
(make-hash-table :size 300 :test 'equal)

Here's another function's calling conventions:
(reduce function sequence &key :from-end :start :end :initial-value)
***No blank line here***
and several syntactically-valid call forms:

How do I get that effect in SGML/HTML->XHTML/XML transitional??

Yes, that's the practical markup problem, and easy to fix.

How do I fix that without introducing extra blank line where not wanted?

<br /> is formally valid HTML, it just _means_ <br>>.

That's meaningless. Any < or > by itself is unbalanced brockets,
which is complete garbage in SGML/XML.

So anyway, I'm going to make a pass through my entire document,
even though it passes validation, to flush all instances of <br />,
and do something else instead. Starting pass at 20:28 PST ...
OK, I did just the very first of them:
Anything I haven't yet included might be found
<a href="http://merd.sourceforge.net/pixel/language-study/syntax-across-languages.html">here</a>
in much terser form but still perhaps useful if you then use Google to find
the documentation for the keyword cited there.<br></br>
Also, the original perl cookbook sourcecode and partial translations to
several other languages can be found
<a href="http://pleac.sourceforge.net/">here</a>,
but I noticed some mistakes in my casual browsing of the CommonLisp section,

And just that one fix makes it fail validation already!! How do I
force a line break, **without** a blank line, in the middle of a
paragraph, in transitional XHTML??

 

[Chris F.A. Johnson]

....
How do I fix that without introducing extra blank line where not wanted?

<br>

 

[Jonathan N. Little]

I want it to look like this:
The meaning of that is that arg1 arg2 thru argz are each required, but
then any combination of the keywords may be used, each a pair of the
keyword itself and the corresponding value. For example, here's a
description of a function's calling conventions in that notation:
(make-hash-table &key :test :size :rehash-size :rehash-threshold)
***No blank line here***
where there are no required arguments, only keyword arguments, so all
of the following forms of call are syntactically valid:

How about with some styling? CODE element is default inline but if you
wish your code example displayed otherwise when within a paragraph then:

<style type="text/css">
P CODE { display: block; }
....


<p>
Paragraph text above code...
<code>Your code snipped </code>
continuation paragraph text below ...
</p>

 

[robert maas, see http://tinyurl.com/uh3t]

Of course validation is of limited usefulness and can actually cause
problems instead of solving them. But that's a different issue.

You're on the opposite side of the debate from the several people
who harass me that I don't know how to write Web pages (I'm an
idiot) because one or another of my Web pages fails validation.

The useful thing is that the validator reports the existence of an
error.

That's not very useful at all when the error is reported several
thousand lines after where the actual error happened.

It should report the error *exactly* where it happened, to be of
reasonable use to authors. In this case it failed to do that.

Checking is not a substitute for learning and understanding.

Are you claiming that you've never made even one mistake in your
entire life? So a utility that checks for mistakes in your work is
totally worthless? No matter how much a human being learns and
understands, a human being occasionally makes yet another mistake.
I guess you're super-human and that never happens to you. Your
snobbish attitude (if one ever make even one mistake then that
person is an idiot who needs to learn more, rather than a human who
makes mistakes) is beginning to piss me off.

The classic idea that a person needs to learn everything that is
known by mankind before he's competant to get his first job stopped
being reasonable a few centuries ago. Nowadays, especially with the
Web available, the best approach is to learn the basic idea of a
discipline, then give it a try, and rely on error-checkers to point
out fine points that are urgent to learn next. There's probably not
one person alive today, not even you, who knows *everything* about
even one (1) field of study.

Interlude: My history of HTML: Circa 1994 was the first time my ISP
provided any Web browser that I could use on my VT100 dialup shell
account, namely lynx. So I started teaching myself HTML, then
converted my MaasInfo (toplevel meta-index to the InterNet) to HTML
format. Also I made some other new Web pages. But lacking direct
InterNet access I couldn't do anything dealing with images or
stylesheets, only plain vanilla HTML text. In mid-1998 I got an ad
for a free trial of AT&T WorldNet, so I gave it a try. It was
utterly horrible! It took 20 minutes just to download the default
homepage that AT&T forced me to always start with, and once that
was downloaded it took 5 minutes every time I clicked on the scroll
bar to move to the next screen among the already-downloaded Web
page. I tried downloading a NASA image of Mars, but after a hour of
downloading it had gotten only about one inch of the image at the
top of the screen downloaded. If, after waiting for the 20-minute
download of the AT&T home page, I the immediately entered the URL
of one of my own text-only Web pages, it wasn't horribly slow, but
I had to be careful *never* to click on any link to anything that
might have images and take another 20 minutes to download. Of
course I cancelled the service before the free month was finished,
but AT&T insisted on billing me for the second month, and refused
to totally retract the charges, and I refused to pay even the
reduced amount, so they cut off my long distance service, which has
remained cut off to this day. Anyway, I've been text-only at home
ever since.

Then in late 2000 I discovered my new ISP allowed users to set up
CGI, so in early 2001 I taught myself CGI and wrote a demo
application. Then 2.5 years ago I took a class at De Anza College
called "Web Design", which I thought would teach me the artistic
layout of Web pages. Nope, all it taught me were the technicalities
of CSS and embedded images and XHTML transitional (and it got the
latter fucking wrong, as I learned just today in this thread),
although I did get a hint a few months that XHTML transitional
might be all bunk, but today was the clincher. So during the 2
months of that class was the only time I ever had developmental
access to CSS and images etc. (At the public library I can view
other people's pretty Web pages, but they don't provide TELNET
access so there's no way I can connect to my shell account to edit
a Web page and then switch over to Mozilla to view my changes.)

End of interlude, back to thread.

It would be an error to flag a valid document as erroneous.

On the other had, "transitional" means something that bridges the
gap between two slightly different systems, so if it flagged
something that was valid in SGML/HTML but not valid in XHTML/XML or
vice versa that would be very helpful.

My conclusion at this point is that there is *no* way to force a
line break in the middle of a paragraph without actually forcing a
full paragraph break which implies a **BLANK*LINE** between
paragraphs. If anybody knows a way, please tell.

You might confuse the W3C validator with the WDG validator
http://www.htmlhelp.com/tools/validator/
which gives (and has given for years) a useful warning, even
though this is strictly speaking outside the scope of a validator:

Aha, I tried that, and quickly got:

* Line 26, character 4:
<p />
^
Warning: net-enabling start-tag; possibly missing required quotes
around an attribute value
Will somebody please tell me what "net-enabled" means here??
In any case, it clearly shows me I shouldn't be doing that.

I clicked on the link for the p element:
The P element defines a paragraph. The closing tag for P is optional,
but its use prevents common browser bugs with style sheets. ...
What does "optional" mean??? The "Web Design" instructor emphasized
that every opening tag requires a matching (and properly nested)
closing tag. Only empty tags can stand alone.

* Line 81, character 55:
... keyword cited there.<br></br>
^
Error: end tag for element BR which is not open; try removing the
end tag or check for improper nesting of elements
It looks open to me, per XML/XHTML standards!! Clearly I'll have to
totally avoid the br element in my Web pages.

I clicked on the link for the br element:
The BR element forces a break in the current line of text. BR can be
useful in formatting addresses within the ADDRESS element, but it is
often misused to break lines of text in a paragraph or table cell when
it looks "nice" to the author.

OK, that's the clincher. Despite the fact just about everyone on
the net generates the br element to force line break in paragraphs
or other flowing text (implicit paragraphs), it's wrong!!!

* Line 86, character 45:
... t trust this as accurate.<br />
^
Warning: net-enabling start-tag; possibly missing required quotes
around an attribute value
What does "net-enabling" mean???

<br />&nbsp;<hr />
^
Warning: net-enabling start-tag; possibly missing required quotes
around an attribute value
How the **** do I get a horizontal rule any more???
Omitting these will **RUIN** my Web page design!!

<http://www.rawbw.com/~rem/HelloPlus/CookBook/CookTop.html>
The file now passes both validators, at the cost of looking like trash!!!
How to fix it???

 

[Jukka K. Korpela]

Scripsit robert maas, see http://tinyurl.com/uh3t:

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.

Of course error messages should be compact, informative, to the point, and
related to the very construct that is in error. But error diagnostics is
difficult. It takes time and effort to create a good diagnostic system, and
it requires a good understanding of both the language rules and the ways
people typically break them. (In my wild youth, I wrote major parts of a
Pascal compiler, including error processing, and I still remember it was
rather difficult to be correct and helpful at the same time.)

In the case on "<p />" (by the formal SGML-based rules of classic HTML), the
formal error is where it was reported to be. "<p /a long string/" is
formally valid. You must not report an error when there is none. What you
could conceivably issue is a _warning_ on pragmatic grounds, and that's what
the WDG validator does. (If I remember correctly, the warning was added
according to my suggestion and was actually related to a different issue,

Are you claiming that you've never made even one mistake in your
entire life?

My modesty prevents me from doing so.

Seriously, I don't see why you imply such a claim in my statement.

So a utility that checks for mistakes in your work is
totally worthless?

On the contrary. A utility that reports mistakes (even on a "There is an
error" basis, though naturally I prefer more exact reports) is often
essential, but it is not a _substitute_ for learning and understanding.
Rather, an incentive and tool for them.

Compare this with spelling checkers. When I wrote serious texts to be
published in print media, I almost always use Microsoft Word with all
possible spelling and grammar checks enabled, even when I write rather
technical texts with lots of special terms that will be flagged by the
checks. But I do not blindly make the changes that the checkers suggest.
Rather, I treat them just as input to my own checking and judgement. I
occasionally even decide to use expressions flagged as "poor style", but
consciously and after due consideration. And if Word flags an entire
sentence in a manner that effectively says "hey, this went over my head, the
sentence is too complicated", I'm grateful for the information and don't
require it to tell _where_ its analysis broke. Rather, I read the sentence
carefully and then usually reformulate it, typically breaking it to two
sentences.

I guess you're super-human

I'm not particularly interested in arguing with you, but I sense some
arrogance in your statements where you seem to accuse me of arrogance.

Your snobbish attitude

Of course I'm a snob, but the parenthetic statement is all yours:

(if one ever make even one mistake then that
person is an idiot who needs to learn more, rather than a human who
makes mistakes)

Idiots, by definition, cannot learn much. All human people should learn more
every day to the extent they can. Reports about mistakes can be taken as
suggestions about possible needs for learning, or you might get crazy and
babble and drool _like_ an idiot. I have much sympathy for idiots, but not
that much for people who just act like idiots.

Interlude:

Excuse me while I yawn.

On the other had, "transitional" means something that bridges the
gap between two slightly different systems, so if it flagged
something that was valid in SGML/HTML but not valid in XHTML/XML or
vice versa that would be very helpful.

Both "Transitional" and "Strict" are strictly defined formal syntaxes. If
"it" refers to a validator, then you are asking for a validator to do
something else than act as a validator. And maybe it _is_ useful to add
heuristic pragmatic warnings to validators, but the statement "It would be
an error to flag a valid document as erroneous". A program purported to be a
validator could be _more_ than a validator, but it should not be _less_.

My conclusion at this point is that there is *no* way to force a
line break in the middle of a paragraph without actually forcing a
full paragraph break which implies a **BLANK*LINE** between
paragraphs. If anybody knows a way, please tell.

What? I think this was already discussed, and I have no idea how you think
it is related to the formal aspects being discussed.

A paragraph break implies a blank line only by default rendering rules of
(typical) visual browsers. These days, you can easily use CSS to set the
relevant properties (margin-top and margin-bottom for applicable elements)
to zero, with the usual CSS caveats of course.

Moreover, you can use <br> (or <br /> if you use XHTML for some odd reason)
for a simple line break. Or you could use display: block in CSS, as someone
suggested in this discussion, I think.

Warning: net-enabling start-tag; possibly missing required
quotes around an attribute value
Will somebody please tell me what "net-enabled" means here??

In this context, "net" (better written as "NET") means "null end tag". When
you have "<p /", you have a NET-enabling start tag, i.e. a start tag that
makes the next "/" act as the end tag for the element that was opened. It's
a nice idea in SGML, but it was never implemented in HTML browsers, even
though it was formally part of HTML up to and including HTML 4.01.

I clicked on the link for the p element:
The P element defines a paragraph. The closing tag for P is
optional, but its use prevents common browser bugs with style
sheets. ...
What does "optional" mean???

It means something that may be used, upon your decision. That is, the word
has the same meaning as in ordinary English.

The "Web Design" instructor emphasized
that every opening tag requires a matching (and properly nested)
closing tag. Only empty tags can stand alone.

That was simply teaching XHTML. It's not that serious as such - one of the
books I've co-authored teaches XHTML in a fairly systematic way and even
carries "XHTML" in its name, though it also explains the real scope of
applicability of XHTML. It does no harm to follow such rules, as long as you
are careful with empty elements and don't mix classic HTML and XHTML and
expect validators to grok it. But it may prevent people from understanding
that in classic HTML, many end tags _are_ optional (omissible) and routinely
omitted without casualties.

* Line 81, character 55:
.. keyword cited there.<br></br>
^
Error: end tag for element BR which is not open; try removing
the end tag or check for improper nesting of elements
It looks open to me, per XML/XHTML standards!!

Well, did you _declare_ that you use XHTML? I don't think so. If your
document type declaration declares an HTML 4.01 doctype, then SGML rules
apply. By SGML rules and by the declaration for the br element (with EMPTY
declared content), <br> is "self-closing", i.e. the element always has empty

Clearly I'll have to
totally avoid the br element in my Web pages.

So _that_ is how you jumped into a conclusion earlier.

<br />&nbsp;<hr />
^
Warning: net-enabling start-tag; possibly missing required
quotes around an attribute value
How the **** do I get a horizontal rule any more???

By using <hr>. Alternatively, by setting a top or bottom border for an
element. There are other techniques like images and background images too,
if you want to create a decorative rule.

 

[Andy Dingley]

I took a class at De Anza College (in Cupertino, CA),

I don't believe that anyone has ever posted a "college class" to these
newgroups where the teaching was anything _other_ than obsolete and
clueless. Most web tutorials are bad and wrong, but colleges seem to
be right at the bottom of the barrel.

the instructor emphased strongly that we must **stop** writing our
Web pages in old HTML that is incompatible with XML,

In fairness to your instructor, there are several things they could
reasonably have said here (and even more they meant) and many of them
are quite reasonable advice.

Yes, it's a good idea to author HTML as "XMl style", but only up to a
point.

SGML has an awful lot of features for clever minimisations. Many of
them (although not all) are also available under HTML. If you're a
parser, or if you're Jukka, then you can use the features. For the
rest of us, the long-winded simplicity of XML-style, where consistency
is valued higher than terseness, leads to more accurate hand-coding.

So close your elements with an end tag. Keep your tagname case
consistently lower-case. Quote your attributes. Don't minimize an
attribute like "selected". However _don't_ use the XML form of the
empty element ( <br /> ) and certainly don't ever use this for an
element like <p> that isn't defined in the DTD as being empty. The
first is a minor error, but <p /> is a major error.

This is quite possibly what your tutor actually said. Unless you
already understand a fair bit about what a DTD is, you can't see the
difference.

we *are* allowed to liberally use <tag/> or <tag /> when we don't enclose anything.

Don't think about "whether it encloses anything" (current document-
based XML behaviour), think instead about whether the DTD forbids it
from ever enclosing anything (i.e. it's declared as EMPTY by SGML's
DTD-based behaviour)

avoid all use of the br element whatsoever, using <pre>...</pre> instead whenever I want one or
more single lines with no rearranging of line breaks.

That's ridiculous. <br> is an inline line-break within a paragraph. If
that's what you mean, then use it. Your code examples are one of the

the pre element causes a blank line after each section,

It does no such thing, nor does <p>. It causes the content to be
rendered as a block within a box, and CSS might say that there's some
margin space after this. That's a lot different from there being "a
blank line afterwards". There is no line, there's only space after the
line before.

Does anybody know a way to avoid that blank line
after a pre section, and before a paragraph??

Learn some trivial CSS, in particular the use of vertical margins.
Avoid padding at first. Learn about "collapsing margins". http://
brainjar.com might be a good starter.

That's meaningless. Any < or > by itself is unbalanced brockets,

Wasn't "unbalanced brockets" the guy with the steam loco in Chigley?

And just that one fix makes it fail validation already!! How do I
force a line break, **without** a blank line, in the middle of a
paragraph, in transitional XHTML??

<br />

 

[robert maas, see http://tinyurl.com/uh3t]

Or use a new <p> with padding-top and margin-top set to 0.

Let me see if I can find the documentation for that ...
<http://www.w3.org/TR/CSS21/box.html>
shows only how to do it in CSS, not directly in the element, so
that's useless for me because not all browsers support CSS, in
particular the only browser available to me for testing over VT100
dialup (lynx) into unix shell doesn't support CSS.
<http://www.thescripts.com/forum/thread154512.html>
also refers to CSS, but at least it shows doing something directly
in the individual element, so let me give it a try ... No, it
doesn't work. Here's the HTML source:

Anything I haven't yet included might be found
<a href="http://merd.sourceforge.net/pixel/language-study/syntax-across-languages.html">here</a>
in much terser form but still perhaps useful if you then use Google to find
the documentation for the keyword cited there.
<p style="margin-top: 0; padding-top: 0"></p>
<em>**(I don't want a blank line here, just a forced newline.)**</em>
Also, the original perl cookbook sourcecode and partial translations to
several other languages can be found
<a href="http://pleac.sourceforge.net/">here</a>,
...

And here's how it appears on-screen.

Anything I haven't yet included might be found here in much terser
form but still perhaps useful if you then use Google to find the
documentation for the keyword cited there.

**(I don't want a blank line here, just a forced newline.)** Also, the
original perl cookbook sourcecode and partial translations to several
other languages can be found here, ...

So what do I need to do there to get rid of that blank line?

Also is there any way to prevent the blank line after the pre element here?

... So suppose you
enter two numbers, with a space between them, such as</p>
<pre>
42 69
</pre>
**(I do *not* want a blank line here!!)**
on a single line of input?
Lisp will read the 42, and print it out on a new line.

That's disgusting. I've tried to purge my documents of all
accidental use of that crock, using &gt; whenever I want that
character to *appear* in the display of the WebPage.

 

[robert maas, see http://tinyurl.com/uh3t]

<style type="text/css">
P CODE { display: block; }
...
<p>
Paragraph text above code...
<code>Your code snipped </code>
continuation paragraph text below ...
</p>

OK, I tried that, but it doesn't work. Here's the URL, and how it
appears:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/JonathanNLittle.html>
Paragraph text above code... Your code snipped continuation paragraph
text below ...

If I implemented your suggestion incorrectly, please explain.

 

[Jonathan N. Little]

Let me see if I can find the documentation for that ...
<http://www.w3.org/TR/CSS21/box.html>
shows only how to do it in CSS, not directly in the element, so
that's useless for me because not all browsers support CSS, in
particular the only browser available to me for testing over VT100

Anything in recent history, Yeah 10-year old browser will have trouble
but who is using one? I should you how to get what you wish, if the code
is a one-liner then semantically you should use the CODE element. To
style the inline CODE element on its own line then:
<!-- CSS -->
<style type="text/css">
P CODE { display: block; }
....

<!-- HTML -->
<p>
Paragraph text above code...
<code>Your code snipped </code>
continuation paragraph text below ...
</p>

Now if you have multi-line code you could use the PRE element and you
can give it the class "code". Now unfortunately IE does not support
"sibling selectors" so for IE you will need classes for the P above and
below the code snippets to remove the margins

<!-- CSS -->
<style type="text/css">
/* remove spacing on code PRE blocks */
PRE.code { margin: 0; padding: 0; }

/* for para before */
P.beforeCode { margin-bottom: 0; color: blue; }

/* for para after */
P.afterCode { margin-top: 0; color: red; }
...

<!-- HTML -->

<p class="beforeCode">
The para before your code block ...
</p>
<pre class="code">
Your code sample ...
</pre>

<p class="afterCode">
The para after your code block ...
</p>


<snip>

 

[Jonathan N. Little]

OK, I tried that, but it doesn't work. Here's the URL, and how it
appears:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/JonathanNLittle.html>
Paragraph text above code... Your code snipped continuation paragraph
text below ...

If I implemented your suggestion incorrectly, please explain.

Works in IE 5.01 + and Opera 7. Firefox2.0.0.1 and SeaMonkey, old
Mozilla 1.7.12 and the oldest Konqueror I have running 2.0! And it
almost works in NN4.7 on Linux!

I don't have any Macs but I am sure it will work in Safari