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

Discussion in 'HTML' started by robert maas, see http://tinyurl.com/uh3t, Feb 12, 2007.

  1. 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?
     
    robert maas, see http://tinyurl.com/uh3t, Feb 12, 2007
    #1
    1. Advertising

  2. robert maas, see http://tinyurl.com/uh3t wrote:
    > 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;

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Feb 12, 2007
    #2
    1. Advertising

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

    Andy Dingley Guest

    On 12 Feb, 19:53, (robert maas, see http://
    tinyurl.com/uh3t) wrote:
    > 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.
     
    Andy Dingley, Feb 12, 2007
    #3
  4. robert maas, see http://tinyurl.com/uh3t

    Rik Guest

    On Mon, 12 Feb 2007 20:53:18 +0100, robert maas, see
    http://tinyurl.com/uh3t <> wrote:

    > 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 Wasmus
     
    Rik, Feb 12, 2007
    #4
  5. robert maas, see http://tinyurl.com/uh3t

    Rik Guest

    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 Wasmus
     
    Rik, Feb 12, 2007
    #5
  6. robert maas, see http://tinyurl.com/uh3t

    Rik Guest

    On Mon, 12 Feb 2007 21:26:17 +0100, Rik <> wrote:

    > 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 :p

    --
    Rik Wasmus
     
    Rik, Feb 12, 2007
    #6
  7. 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
    <br/> just as <br>> without looking for a matching "/").

    > 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 ">".

    --
    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Feb 13, 2007
    #7
  8. robert maas, see http://tinyurl.com/uh3t

    Andy Dingley Guest

    On 13 Feb, 06:31, "Jukka K. Korpela" <> wrote:

    > > actually exposed a real flaw in the validator.

    >
    > 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.

    > > Your code is bogus, although probably not actually invalid.

    >
    > 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).


    > > 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.


    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.
     
    Andy Dingley, Feb 13, 2007
    #8
  9. 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? :)

    >>> 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.

    >
    > 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".)


    --
    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Feb 13, 2007
    #9
  10. > From: "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.

    > 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, Feb 14, 2007
    #10
  11. > From: "Jukka K. Korpela" <>
    > 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??

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

    > 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??
     
    robert maas, see http://tinyurl.com/uh3t, Feb 14, 2007
    #11
  12. On 2007-02-14, robert maas, see http://tinyurl.com/uh3t wrote:
    >> From: "Jukka K. Korpela" <>

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


    <br>

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

    >> <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.


    > by itself is >.


    --
    Chris F.A. Johnson <http://cfaj.freeshell.org>
    ===================================================================
    Author:
    Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
     
    Chris F.A. Johnson, Feb 14, 2007
    #12
  13. robert maas, see http://tinyurl.com/uh3t wrote:

    > 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>


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Feb 14, 2007
    #13
  14. > From: "Jukka K. Korpela" <>
    > 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 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.


    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???
     
    robert maas, see http://tinyurl.com/uh3t, Feb 14, 2007
    #14
  15. Scripsit robert maas, see http://tinyurl.com/uh3t:

    >> 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.


    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,
    namely constructs like <a href=/foo>, where the formal error is quite
    different from what really went wrong.)

    >> Checking is not a substitute for learning and understanding.

    >
    > 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.

    >> 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.


    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
    content and must not have an explicit end tag. Therefore, </br> is always an
    error.

    > 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.

    --
    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Feb 14, 2007
    #15
  16. robert maas, see http://tinyurl.com/uh3t

    Andy Dingley Guest

    On 14 Feb, 04:35, (robert maas, see http://
    tinyurl.com/uh3t) wrote:

    > 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
    few cases when <pre> might well be appropriate, but for nealy all HTML
    coding purposes it isn't.

    > 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 />
     
    Andy Dingley, Feb 14, 2007
    #16
  17. > From: "Chris F.A. Johnson" <>
    > 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.

    > > by itself is >.


    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, Feb 14, 2007
    #17
  18. > From: "Jonathan N. Little" <>
    > <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.
     
    robert maas, see http://tinyurl.com/uh3t, Feb 14, 2007
    #18
  19. robert maas, see http://tinyurl.com/uh3t wrote:
    >> From: "Chris F.A. Johnson" <>
    >> 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


    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>

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Feb 14, 2007
    #19
  20. robert maas, see http://tinyurl.com/uh3t wrote:
    >> From: "Jonathan N. Little" <>
    >> <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.


    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

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Feb 14, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Saunders
    Replies:
    1
    Views:
    682
    John Saunders
    Nov 18, 2003
  2. Morten Snedker

    html validation fails

    Morten Snedker, Nov 27, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    362
    Morten Snedker
    Nov 28, 2006
  3. Mike Barnard
    Replies:
    5
    Views:
    409
    Beauregard T. Shagnasty
    Feb 26, 2008
  4. Replies:
    2
    Views:
    300
    Grant Wagner
    Dec 23, 2004
  5. dayo
    Replies:
    11
    Views:
    349
    Ilya Zakharevich
    Dec 16, 2005
Loading...

Share This Page