“Mark of the…” What?

If you use MadCap Flare, Adobe RoboHelp, and probably any other HAT (help authoring tool), you may have noticed the intriguingly-named Mark of the Web option in the output settings. Mark of the Beast jokes aside, what is this?

If you use IE 7 or 8 (and some earlier service packs), you know that after you generate a browser-based output like WebHelp and then try to view it, the output doesn’t display. Instead, the browser opens with a yellow bar that reads “To help protect your security…” just above the display area. To view the output, you must click on the blocked content bar, click the Allow Blocked Content… option, and finally click Yes to the security warning message. Only then does the output display.

The blocked content… feature has nothing to do with help authoring per se. It’s a security feature in IE that has the side effect of blocking the display of HTML and XHTML files, which the help topics are, when you run them from your local PC. Where help authoring is concerned, it’s harmless but mildly irritating. Selecting the Mark of the Web feature, often referred to as MOTW, lets you deal with that irritation by turning off the blocked content bar and displaying your output immediately.

According to MSDN…

“The Mark of the Web (MOTW) is a feature of Windows Internet Explorer that enhances security by enabling Internet Explorer to force webpages to run in the security zone of the location the page was saved from—as long as that security zone is more restrictive than the Local Machine zone—instead of the Local Machine zone. When you are developing webpages, the MOTW enables you to test your HTML documents in the security zone where you intend the pages to run. Adding the MOTW to your webpages also enables you to fully test their compatibility with users' security settings.” (http://msdn.microsoft.com/en-us/library/ms537628(v=vs.85).aspx)

So why not turn on MOTW all the time? The blocked content bar only appears when you view your output or HTML/XHTML files on your local PC. It does not appear when you view your output or HTML/XHTML files on a network drive or server. So if users will view your output on a network drive or server, there’s no reason to use MOTW. If users will view your output locally, on the C drive, for example, you might use MOTW. But be aware that MOTW also causes two odd problems in help authoring:

• If you created links in your topics and turn MOTW on, those links don’t work when you preview topics in your HAT. Confusingly, however, they do work in the output. So there’s the risk of wasting time trying to figure out why the links don’t work except when they do.

• If you created links in your topics to external files like PDFs and turn MOTW on, the external links don’t work in the preview or output. They look fine… they just don’t work. So, again, there’s the risk of wasting time trying to figure out why regular links do work but external links don’t. It’s a problem whose solution – turn off MOTW – is simple but totally unintuitive.

The upshot… You might want to turn MOTW on during development to avoid having to click through the blocked content bar each time you review the interim output. Just be aware of the authoring problems and be sure to turn MOTW off when you generate your final output.

Thanks to Jerry in San Jose and the crew is Brisbane for motivating me to finally write this. :-)