homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

Is This Really Bad HTML?

 10:20 am on Jan 12, 2001 (gmt 0)

I recently found this web page about bad HTML [earth.com]. Here's a quote:

Don't split highlighting/formatting elements with structural markup. The only problem here is that it's simply invalid HTML and some browsers will terminate it for you, giving the end user the undesired result of loosing some of the markup that you, the author, intended.

Yes, it works on Netscape and MS Internet Explorer but that's because they are playing games with their parsing of the HTML.

Don't: <I>...<P>...</I>
Instead, terminate and restart the formatting element
Do: <I>...</I><P><I>...</I>

OK, what gives here? Is this really true? If so, I've never written a correct HTML page in my life! And no validator I've ever used has pointed out this kind of error.



 1:55 pm on Jan 12, 2001 (gmt 0)

yes. it is true. it is based on the logical hierarchical structure i.e arrangement of an html document.
<body><! higher block element -->
<div> <! outer block element -->
<p>inner block element<strong>hello</strong><span>
<font><i>inside of span, now close<small>all</small>
six in the opposite direction.</i></font></span>

The body tag applies to all of it, so close that after all of it. etc. do you see it? probably the w3.org has more info on this somewhere too. remember they are the standards that no one listens to. hehe.


 4:31 pm on Jan 12, 2001 (gmt 0)

mousemoves - you are correct in how to handle nested tags and it good that you pointed it out as it is the first lesson of HTML but I think tedster's issue is mildly different.

I think what they are getting at is that structural HTML (<p>, <blockquote> etc) is handled differently from formatting HTML (<font>, <i> etc). What they are saying is each set of structural tags defines a section of code and that section should be treated almost as seperate page with it's own set of tags. Stretching a formatting tag across multiple sections of HTML could cause it to break at the structural seperation depending on the browser.

I agree tedster, I've never written a correct page in my life either according to this but all the major browers can handle our 'bad' code so I don't worry about it.


 6:48 pm on Jan 12, 2001 (gmt 0)

If you are going to make your pages work in xml, it might be something to consider. XML is not nearly as lenient as HTML.



 6:54 pm on Jan 12, 2001 (gmt 0)

that's a better explanation. my illustrated tags meet the block-level element, inline element hierarchial structure of html as defined in the html specs at w3.org i am not referring to nested tags at all.


 4:27 am on Jan 13, 2001 (gmt 0)

Well, actually, HTML shouldn't really be compared to XML. Older versions of HTML are applications of SGML and the current version of HTML is an application of XML. So it'd be more accurate to compare XML to SGML.

SGML allows you more alternate ways of doing something (optional closing tags, implicit elements, etc) than XML, but most of the leniency is actually coming from the browser rather than the SGML spec.

I imagine there'll be lots of panic and relearning once automatic validation results become more common as a browser feature. iCab already displays a frowning face and offers a list of errors when dealing with invalid markup. A similar Mozilla feature is in the works as well. It'd be rather embarassing to have your users view your page and see a big "This page contains errors and may not be rendered as intended." warning.


 9:03 am on Jan 13, 2001 (gmt 0)

imho i think it will be so nice to think of the logical spec and be able to apply it. any spec! my code does meet the spec for html. it does separate structure from presentation and block-level/inline is an example. just in case someone out there thinks i'm a beginner, at many things yes, but not when it comes to html or style sheets, it is far too trivial. browser implementation of these specs is entireley not trivial and is no doubt the reason behind most of the problems. in my last post, i appreciated the fact that oilman explained in more general terms the global idea of structure and presentation, whereas i basically just wrote out an example, which was a stupid thing to do.

HTML specifies what each tag attribute means. XML uses 'tags' only to delimit pieces of data, and leaves the interpretation of the data completly to the application. source: w3.org

Grnidone compares the ability to work with html which is less strict then when working with xml. i.e if working with html, strict adherence to the spec is not required but it is required when working in xml otherwise the application reading the 'tags' will be lost.

here is a good article on XML by Scientific American for anyone whom is interested: [sciam.com...]


 9:33 am on Jan 13, 2001 (gmt 0)

If I understand the current situation correctly, one reason that good HTML may be rendered incorrectly at times by the major browsers is because they try to forgive bad code -- and that opens the door to bugs.


 10:07 am on Jan 13, 2001 (gmt 0)

i agree, Tedster.
here is the last paragraph from my above mentioned article which i think is interesting and applies to the discussion well.

Thus, for its users, the XML-powered Web will be faster, friendlier and a better place to do business. Web site designers, on the other hand, will find it more demanding. Battalions of programmers will be needed to exploit new XML languages to their fullest. And although the day of the self-trained Web hacker is not yet over, the species is endangered. Tomorrow's Web designers will need to be versed not just in the production of words and graphics but also in the construction of multilayered, interdependent systems of DTDs, data trees, hyperlink structures, metadata and stylesheets--a more robust infrastructure for the Web's second generation.


 10:15 am on Jan 13, 2001 (gmt 0)

That's a very illuminating article, mousemoves. Thanks.

I feel like I just got my homework assignment, and it's a two year term paper.


 10:39 am on Jan 13, 2001 (gmt 0)

thread posting flow: this post belongs before tedster's last post.
i guess i should say i agree and ultimately the core problem is with html and the desire to use it for more than it was intended to be used. designers don't follow the spec always and neither do the browsers. designers sometimes do odd hacks to implement solutions to problems when no spec solution is implemented by the browsers. i.e style sheets. what a nightmare, but what an easy logical spec.
other designers may not follow the spec because they don't have to and sometimes get in trouble because of it. certainly the block-level/inline element spec should be followed. but to this day we can't follow the separation of structure and presentation perfectly because the browsers don't follow the spec perfectly for style sheets.

it's all such a mess and results in a ridiculous waste of time. but i guess that's progress.


 10:50 am on Jan 13, 2001 (gmt 0)

i'm not sure exactly what you mean Tedster, but ya, i have lots of homework when it comes to xml, also. if this is what you mean.

i can always count on webmaster world to help me find stuff to study. :)


 11:14 am on Jan 13, 2001 (gmt 0)

Its been worrying us for a while that we have used single <P> instead of <P>..</P> for 6 years. A while ago the new HTMl spec made the latter the only valid HTML i think. Our pages work in the 4 major browsers but we are worried about future problems.

Has anyone converted their old <P> only pages to <P>..</P>

Having thought around search and replace strings, we have come to the conclusion there is no automated way to do this but has to be done manually (an enormous job)

Question is.. has anybody found a way to automatically change these tags?


 11:22 am on Jan 13, 2001 (gmt 0)

gosh, i would say you can't. how would the program know where it should place the end tag?


 11:50 am on Jan 13, 2001 (gmt 0)

actually, i just checked and the html4.01 spec states the end tag for the paragragh element is optional.

it is on the following page:

i'm looking at the xhtml1.0 spec right now to see what it says about this.


 12:21 pm on Jan 13, 2001 (gmt 0)

here it is for xhtml1.0, in this case the paragraph element must have a closed end tag, and all html tags are suppose to written in lowercase, plus some other stuff.
the following link describes things really well.


 1:33 pm on Jan 13, 2001 (gmt 0)


read this, it may help fix your automation problem.
it is about converting your doc into xhtml using a program called html tidy.

i just checked it out more. nope, it doesn't help the end paragraph tag problem, but at least it does some stuff and may be helpful to someone.


 2:16 pm on Jan 13, 2001 (gmt 0)

thanks mousemoves for all the attention and help. I'm following it all up now.


 12:02 am on Jan 14, 2001 (gmt 0)

>Well, actually, HTML shouldn't really be compared to XML. Older versions of HTML are applications of SGML and the current version of HTML is an application of XML. So it'd be more accurate to compare XML to SGML.

My point was not to compare HTML to XML at all. My point was that if you are going to ever program XML, you may as well get into the good habit of nesting your tags correctly.



 5:53 am on Jan 14, 2001 (gmt 0)

The W3C provides a small utility called "HTMLtidy" that can clean things up for you. It makes sure your elements are closed properly, etc. As I recall, it also converts SGML-based HTML to XML-based HTML in valid XHTML 1.0 form, but it's been a while since I looked at that utility. Unfortunately, I don't have an URL handy for it, I just remember that it was on the W3C's site.

Anyway, HTML itself is no more or less lenient than the markup system it's based on. If it's XML-based, you have to play by XML rules. If it's SGML-based, you have to play by SGML rules. If it's being run through an ad-hoc Mosaic-style parser, you have to guess the rules by trial and error. I look forward to the day when 98% or more of users have a browser with XHTML 1.0 or higher support so that I can just write XML and trust it to be parsed correctly. Too bad that'll be a while.


 11:48 am on Jan 14, 2001 (gmt 0)

Tidy is here [w3.org]


 2:50 pm on Jan 14, 2001 (gmt 0)

1st Page HTML editor also has a "convert to XML" as part of the program. This is a free program which looks similar to homesite, but looks to be much more powerful. You can find it here [eversoft.com]


 12:40 am on Jan 15, 2001 (gmt 0)

Holy cow! That place is located just down the street from where I live!

But I can't find the software you speak of...have I missed something?


 3:18 am on Jan 15, 2001 (gmt 0)

the url is evrsoft.com not eversoft (small typo on elijfes' link) however it is easy to find using Search Engines!

There seems to be some controversy on the program however with comments on the downlaod.com site that there may be viruses in the code and that the installation program over-writes some windows files.

Scared me so much i didnt download it!


 3:44 am on Jan 15, 2001 (gmt 0)


I got a copy that was already on a CD. Can't say that multiple virus scans have turned up anything. Program seems to run fine, but..... caveat emptor or what's the word for freeware acquirer beware?


 3:46 am on Jan 15, 2001 (gmt 0)

I've used it for quite some time and never had any problems at all. Pretty sweet little program.


 2:59 pm on Jan 15, 2001 (gmt 0)

I just came upon a nifty little article about HTML 4.0 in Netscape and Explorer [webreference.com] that addresses many curiosities of SGML, HTML, and XML.

Theoretically accurate, but also full of excellent practical advice for our theoretically inaccurate present moment.

Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved