Safely rendering user-supplied HTML in the browser is harder than it seems, and Web Access avoids the security concerns by forcing the download.  This separates any scripts that run in the page from the Web Access context, so that cross-site scripting attacks are not possible.

Essentially, there are two approaches that an application can take to support this functionality.  It can sanitize the HTML that it renders to remove potentially malicious code (this is what e.g. Hotmail does to render HTML mail) or it can serve the content from a separate domain (like gmail's use of googleusercontent.com) so that the potentially malicious code that the page contains is sand-boxed from the application itself.  The first approach puts us in the position of not faithfully rendering user content, and doing so in such a way that breaks many of the intended use cases (because the rendered pages would not be interactive).  The second approach is way beyond what we could expect people to configure.

If you have reason to trust this content (e.g. you have processes in place to keep malicious code out) then this is a safe thing to do.  Since Web Access needs to support the general case, we don't plan to allow this.