As a Perl coder, and a Dreamweaver/vim double-teamer, I must correct your assertion. The primary reason I use Dreamweaver is that it doesn't add crap to your HTML; the "RoundTrip HTML" bits in the ads for the product aren't just marketing hype.

It _will_ do some farily legit clean-up, upper-casing tags and the like, but it won't plug in stupid tags, or cram just one more javascript function, unless you tell it to. And you can, from one option screen, turn off everything, leaving your code 100% pristine. This is nigh-impossible in FrontPage, from what I hear (I won't go near THAT app with a 50-foot pole.)

It even offers an option like the HTML Tidy program to clean up Word and FrontPage HTML. For those wanting rapid dev on the HTML side, concentrating on writing Perl code, Dreamweaver works very well.

----Asim, known to some as Woodrow.

Dreamweaver (and most WYSIWYG HTML tools) add so much cruft and overhead to pages it is beyond a joke.

Wow, I thought Dreamweaver was good about this. Certainly it is much better than Frontpage.

But anyway, as long as the browser can display it, I don't care how unacceptable it is to an HTML expert like you...

but tell me something: do you want your HTML split across a bunch of components so that you can no longer edit an HTML document? How would you deal with something like that?

But anyway, as long as the browser can display it, I don't care how unacceptable it is to an HTML expert like you...

Arghh! This is the kind of attitude that made the web the mess it it today. This is why XHTML is such a good thing.

What do you mean by "the browser"? You site will (hopefully) be visited by large numbers of people using many different browsers. The kind of HTML generated by most so-called "wysiwyg" (a meaningless term on the web, btw) editors will probably break on most of them. Front Page is, for obvious reasons, the worst culprit.

Hand crafted HTML that adhers to the W3C standards will degenerate gracefully in less capable browsers.

Remember, the most important visitors to your site are probably the search engine web crawlers. They don't use the latest version of Internet Explorer.

Whoever first made the decision that Mosaic would "do its best" with invalid HTML should be made to personally clean up every invalid HTML page out there on the web.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you don't talk about Perl club."

While any HTML that displays in any browser can be considered 'good', it's typically better to try to aim for HTML that is small and efficient. Notably in the days of the first WYSIWYG HTML editors, the editor would fill the resulting HTML with excess FONT, BR, nbsp entities, and other bastardizations of HTML; some found that nice small, text-and-minimal-graphics pages to balloon to 250-400% of their original size when saved by the HTML editor than as opposed to the hand-written stuff. Today's HTML editors are much better in that regard, but some still use tags that are being depreciated as we speak, such as FONT. In addition, they still place a lot of emphasis on pixel-perfect placement using fixed-width tables (this is a major HTML designer no-no; if you want pixel-perfect, use PDF). It's much better to make use of CSS and styles to format a document, and while I know the editors are capable of that today, I don't necessarily see a lot of designers using that. But the end result of a good CSS design is that your resulting pages will be smaller and more efficient (meaning less time for your end user to download), and it's much easier to change one aspect of an entire site by changing one line in a site-wide style sheet than to edit each document (static or template HTML) to fix it.

And there's actually good reason to split HTML up in some points; it's the usual trick of setting up common elements on pages that can be used by something like SSI or a dynamic template generator. That said, these elements *ought* to be valid HTML or SGML; all open tags are closed before the EOF of the snippet, unlike the example that was at the top of this thread. This way, if using SSI, for example, and there was a problem including this snippet, the layout of the rest of the page would not be drastically affected because it's not waiting for a tag to be open, or a tag previously open to be closed.

(Please note that I'm not trying to put a grudge down on princepawn; just that one that's followed the world of HTML from the start, I just needed to point out certain aspects from his parent node).

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

As for Dreamweaver... I completely disagree. I started writing HTML eight years ago, and have since tried an assortment of WYSIWYG HTML tools. Dreamweaver is the only one I would even consider using (and do). The level of cleanliness (at least, for the simple to medium-complexity stuff I do) is comparable to that of my own, hand-tuned code. To be sure, it does take some, minor effort of setting it up properly in the first place, and diligence in alt tags and similar Good Code, but those are mostly all things that I'd have to do in vi either. Did I mention that you can directly edit the HTML in DW and it will not second-guess you?

About the worst I'll give you is that it uses <p> and </p> tags, and probably has more whitespace/indentation than I use on my own. For the sake of clarity, I think I can stand that.

Of course, I personally find it really hard to beat the Dreamweaver-Fireworks integration. Vector-based graphics are yummy, and 'Export slices to Dreamweaver,' is totally killer. Sadly, lately it's been more about the pretty pictures than the content. Been bizzy.

About the worst I'll give you is that it uses <p> and </p> tags,

Actually, if you look at the latest XHTML standard, you need the </p> tag to terminate each paragraph, assuming you want you HTML to be compliant.