Blog Comments

I usually always try to respond to comments to my blog, but lately, we've had some disconnects with comments being sent in email, so I thought I would respond to a few recent comments. If I've missed your comment, please forgive me and feel free to send me mail using the Contact link in my blog.

Comment from Jason:

"Do you guys purposely markup your pages to render incorrectly in every browser other than IE?

Jason, I'm not sure if you're talking about the FrontPage dev portal on MSDN or my blog, but I assure you that it isn't intentional. Both the blog tool and MSDN have their own ways of marking up HTML, which are very different from each other and which I haven't yet quite figured out.

I just tried both MSDN and my blog in Firefox, and the blog looked fine, but sure 'nuf MSDN looked pretty bad. Unfortunately, I can't do much about this, so please don't dis our content because IMHO we have some pretty great content.

Comment from orcmid:

"Please screen the most-active newsgroup discussions before you feature them. After reading the thread about multiple body tags, I am very wary of ever asking a question that one of those MVPs might want to tell me is stupid.

"No one ever did bother to ask what DAWG found valuable about being able to have multiple body tags (regardless of the fact that FrontPage is not designed to allow it), assuming that there was an alternative solution without checking with him what he really wanted to do. The resulting incivility was unpleasant to watch."

First, newsgroup posts are included using a Web component. I'm not sure exactly how this is determined, but I believe it is based on how many responses there are to a post, so I have no direct control over which posts get "featured."

Second, no one should ever be treated rudely in any of the newsgroups. The newsgroups are moderated by MVPs and other users who volunteer time to respond to customers. Although we have no control over what general users say, we do have some control over how MVPs treat customers.  I'll forward your comment to the MVP lead, who I'm sure will follow up appropriately with the MVPs. If you ever see any user being abused, called names, or generally treated like an idiot in any of the newsgroups, feel free to contact me, and I'll follow up with the MVP lead.

Finally, I wanted to address DAWG's issue about using multiple BODY elements in the same document. The HTML schema doesn't allow for multiple BODY elements, so it's not surprising that FrontPage doesn't support it. However, I can think of a couple reasons why someone might want to use multiple BODY elements.

In documentation, there is something called single-sourcing. It allows people to create one file that can be used in multiple places. For example, you might have some files that you want included in a book as well as in a compiled help file. If this is what DAWG wanted to do, his best choice would be XML.

Old-timers often associate XML with literal data, as you might find in a database, but XML has many more uses, and single-sourcing is one of them. XML allows you to create a custom schema that you can use to markup content.

With XML, you can markup the content in a file and specify where different portions of the content get published. As in the case I cited earlier, say you have help files that you want published to a compiled help file as well as in a book.  Another case where you might want to do single sourcing is where some content gets published to a Web site, some content is included in a marketing flyer, and some content is compiled into a brochure. These are only a few instances where XML is the ideal markup language, and I have no doubt that many of you can think of many more possible scenarios where a single file might be published in multiple formats.

Although XTHML is similar to XML in the sense that the XHTML schema generally encourages that the formatting be kept separate from the HTML, it isn't XML. It's really just an HTML schema that enforces certain style restrictions. True XML uses a custom schema that contains custom markup tags. You use XSLTs to "transform" the appearance of the content in XML files, but XSLTs do more than just change the appearance of the text, for example making some text bold and other text underlined.

XSLT allows you to convert an XML file from one format, or XML schema, to another. For example, you can use an XSLT to compile XML files into a Word document, or you can use XSLT, to convert files into HTML format. You can even use XSLT to convert from one XML schema to another XML schema.

The second reason that I can think of is for browser compatibility.  For example, perhaps DAWG wanted to put in multiple BODY elements with the idea that only the BODY element for the client browser would be visible. This seems to me to be the least likely of the two reasons that I can think of.

Ideally, all Web pages should be cross-browser compliant (MSDN pages not withstanding!), but in the case where you need to develop different HTML pages for different browsers (or connection speeds), you could have a script that determines the browser on load and serves up the correct page for that browser. I'm sure there are several scripts available on the Internet, in fact, I believe FrontPage 2003 includes a behavior for just this purpose, but I'll provide a simple script in a future post for those who are interested in knowing how to do this.

Thanks, everyone, for your comments. As I said, as much as possible I like to respond to comments and usually do so in email when an email address is provided. Keep the comments coming!

Until next time, happy surfing!