Flare, WebHelp, and Internet Explorer 8

[LeoPaoletti]

I have a series of question and comments regarding Flare, WebHelp, and Internet Explorer 8. I was hoping to find something from MadCap but have come up empty so far.

Does MadCap Flare support Microsoft Internet Explorer 8? For example, if I had a new computer system running Vista and IE8 (never had to upgrade from IE7), would Flare work properly? Is IE8 officially supported?

I believe the Flare Preview window uses IE as the display engine (regardless of the browser you have set as a default). Will it continue to work properly with IE8? Is it possible to change which browser the Preview window uses?

We have been using MapCap Flare to create a WebHelp output. We had been reviewing the output exclusively in Microsoft Internet Explorer 7. We have now tested against the following other browsers:
-Microsoft Internet Explorer 8 (non-compatibility mode)
-Firefox 3 (Windows)
-Google Chrome (Windows)
-Opera (Windows)

We have noticed that IE7 and the Flare preview window treat our bullets and procedure steps differently than other browsers. In IE7 we have set these styles to be left aligned. However, all the other browsers indent these styles. I suspect the other browsers are “properly” rendering the HTML/CSS since IE7 is not standards compliant.
We use the default bullets and lists included in Flare. However, we have modified the indentation.

How we can make the bullets/procedure steps look the same across browsers? Does this require some sort of CSS hack? This will become a bigger issue for us as more of our users upgrade to IE8 from IE7.

I have a bug logged with MadCap about this but I’m not certain if it will get fixed.

We have also noted other differences from IE7 to IE8 with WebHelp output:
With IE8, terms in the glossary are underlined, and change to

• not underlined when you hover/click. In IE7 they were always not.
  The dialog box that gives errors/messages when entering a Comment (Feedback) now (with IE8) has a title bar of “Message From Web Page” where it used to say “Windows Internet Explorer” in IE7.
  
  Thanks,
  Leo

[RamonS]

IE8 came out after Flare 4.2 was released, so I am sure the official statement is "no". I just tried the Flare WebHelp here: http://www.madcapsoftware.com/support/w ... efault.htm and other than that IE8 is horribly slow I had no issues. I don't have Flare on this box and cannot tell if the preview still works, but you are right, it does use IE and no, you cannot change it (smells like feature request).
You will never be able to make XHTML content look exactly the same across browsers. I even question the effort in doing that since most browsers all for local overrides of server side CSS, which would destroy all your hard work. I agree, it is not common practice to do so.

What you really should do is to make it so that the output follows W3C standard. IMHO crafting pages for display in browser ABC is just bad practice and the core issue why we, the web users, are in such a mess (mainly caused by the ignorance of web standards by Microsoft). Especially now with IE8, which can be run in two modes: crappy IE7 mode or less crappy IE8 mode (some call that mode to be even standard compliant, but it depends on who you ask and which test was used). So even if you target IE only then the question is, which types and modes?
So what you are saying is that IE8 shows the bullets the way FF, Opera, and Chrome do, but it is different than how IE7 does it? I'd forget about IE7. There really is no compelling reason to not replace the two year old IE7 with IE8. There may be some hardships over the next few months, but by the time you make things look nice in IE7 as well as in all other browsers the need for this solution is no longer present. That depends though on your audience, some places / industries are upgrade-phobic and still use IE6 (maybe because some ignorant developer crafted a web app that only works with IE6).

[LeoPaoletti]

Ramon,
Thanks very much for the advice. I'm still hoping to see an official statement from Madcap regarding support for IE8. The sooner the better - i'm not sure when the Microsoft Windows updater will start pushing out IE8.

Does anyone have some CSS code that can make the HTML rendering in IE7 look like it does in IE8, Firefox, Safari, and Chrome? Any advice would be appreciated.

Thanks,
Leo

[doc_guy]

Like "RamonS" said, MadCap will officially support the latest IE browser the next time that MC releases a version of Flare/Blaze. You can bet it will happen before Microsoft starts rolling out forced upgrades to IE8. MadCap doesn't make many "official statements", so I wouldn't hold your breath. It is much more common for a version to just be released without much fanfare leading up to it.

There are ways you can tell your CSS to display things differently depending on the browser. One way is to put some type of javascript code in the head of your document to check the browser, and then display the link to the CSS file based on the user's browser.

Another way is to add code to your css file that "breaks" some browsers, so they can't read the rest of the css code for that declaration. You can read more about these on the web. I'm not going to get into a lot of detail, because I, like "RamonS" think that for the most part you're wasting your time. But you can search out CSS browser hacks if you really need to do this.

When my supervisor asks why the help system renders slightly differently in different browsers, I say, "that's the way IE mangles CSS. It works <like this...> in other browsers." End of story. I've got way to much to do to spend a bunch of effort trying to overcome Microsoft's inability to follow the rules everybody else plays by.

[LeoPaoletti]

Paul,
Thanks for the advice. Very helpful.

My problem is that our application only runs in IE7 and IE8. That means the help runs in IE7 and IE8. I'd really like to have help look good in both browsers.

Kind regards,
Leo

[RamonS]

I may repeat myself, but code to W3C standards and you did your task. The W3C standards only define which tags are to be understood and how they are supposed to be interpreted, they do not explicitly specify how things have to look like. That means any browser will display the same code slightly different and still be fully W3C standard compatible.
I recommend you try to make the output look good in all the browsers, but forget about making it look identically. I think that is futile. But why does the application only run in IE 7 or 8? It should be working fine in any browser if it was done right.

[KevinDAmery]

I recommend you try to make the output look good in all the browsers, but forget about making it look identically. I think that is futile. But why does the application only run in IE 7 or 8? It should be working fine in any browser if it was done right.

Now now. It's not the tech writer's fault if the developers decided to use ActiveX....

[Andrew]

I think that is futile. But why does the application only run in IE 7 or 8? It should be working fine in any browser if it was done right.

This is good advice.

The rest of it, about coding to web standards, is nice in theory, but your customers don't care about web standards. They care about useable documentation. If the browser they choose to use does not render your help correctly, you can either tell them to change browsers, or you can fix it so that it will be okay in their browser. Which is appropriate depends entirely on the situation.

[RamonS]

I recommend you try to make the output look good in all the browsers, but forget about making it look identically. I think that is futile. But why does the application only run in IE 7 or 8? It should be working fine in any browser if it was done right.

Now now. It's not the tech writer's fault if the developers decided to use ActiveX....

I questioned why the application only works in IE. And yes, I squarely blame developer arrogance for that.

[RamonS]

I think that is futile. But why does the application only run in IE 7 or 8? It should be working fine in any browser if it was done right.

This is good advice.

The rest of it, about coding to web standards, is nice in theory, but your customers don't care about web standards. They care about useable documentation. If the browser they choose to use does not render your help correctly, you can either tell them to change browsers, or you can fix it so that it will be okay in their browser. Which is appropriate depends entirely on the situation.

The only means of no longer having to deal with incompatibilities that cause a "doesn't work" situation is to finally adhere to the only standards for XHTML out there. Constantly coding to a single vendor spec that is contrary to international standards got us all into this mess. So your advice is to continue doing what was proven over and over again as bad practice and not working? Especially now that IE8 comes along and defaults to a mode that is widely incompatible to IE7. I know that there is the "break the browser to fix my page" button, but I am surprised that people don't complain about that idiocy, but constantly resist to finally use the one and only common 'real' standard.
There is a reason why all vehicles are supposed to drive on the same side. What you and Microsoft (more so in the past) propose is about the same as having everyone drive on one side except for trucks and buses. What kind of recommendation is that? And no, neither that nor the IE only approach work in practice.

[Andrew]

I'm saying that if you ignore business (and human) realities, you lose customers. Thus, I believe that saying everyone should tell customers what browser to use (and that applies equally to limiting customers to IE, etc.) is foolish as any kind of blanket rule.

[doc_guy]

My company only "supports" IE 7. The application is complicated enough that we don't support other browsers. Does our application run on other browsers? Yes. In fact, most of the development staff uses Firefox for internal use. However, we have government clients that only have IE installed, so we have to support their browsers. And our QA department doesn't have the resources to test every function of the software across multiple browsers, in addition to testing the application on several different supported database types. For every browser/version you add to the "supported" matrix, the QA work goes up exponentially.

We don't care if our clients use Firefox, Opera, Safari, or whatever to use our application. But if they call Support because something doesn't look right or whatever, if they aren't using Internet Explorer, then we tell them to try it in IE to see if they get the same error.

In a perfect world it would be nice to be able to support all browsers. But in a realistic world, the government pays a large portion of our bills (i.e. salaries), and since they won't install Firefox on their systems, we will support IE. And since in these economic times we don't have QA support to test multiple browsers, we release with only one supported browser.

It's kind of lame, but it is how we have to do business.

[beelia]

I don't worry about IE8 because not many people are using it yet, and our early adopter customers can't expect to have webapps customized to it. [I'm taking full advantage of that wiggle room.]

However, my entire company standardizes on IE7, and it frustrates me that I can't fix the skin to look as good as it does in FF.

In particular, the bars around the topic pane are black, thick and ugly. I've tried changing every conceivable skin style without result. Anyone got a clue to share?

TIA

Bee

[RamonS]

I wouldn't count on that, IE8 includes a IE7 "compatibility" mode that breaks the browser in so far as that broken IE-only pages are rendered as intended. There really is nothing lost to switch to IE8....not much gained either.

[Andrew]

I wouldn't count on that, IE8 includes a IE7 "compatibility" mode that breaks the browser in so far as that broken IE-only pages are rendered as intended. There really is nothing lost to switch to IE8....not much gained either.

Er, what are you talking about? IE8 renders in standards mode by default, a mode which passes the Acid2 test. The broken page mode is something the user has to consciously invoke.

[RamonS]

IE8 does not render the Acid2 test consistently. Go to the test page, then switch to compatibility mode, then switch back => IE8 "standards" mode fails the Acid2 test, it also scores only around 20 points for the Acid3 test. I know that the Acid tests are not without criticism either, but compared to non-IE browsers who start at least with a 70 point score IE has a long way to go. You can set IE8 to use compatibility mode by using specially crafted meta tags, besides that, based on Microsoft's documentation intranet pages are rendered in compatibility mode, mainly to make the standards-incompatible SharePoint to work right. So it should be quite easy to make IE8 to use IE7 mode (which some claim isn't real IE7 behaviour). See here: http://blogs.msdn.com/ie/archive/2008/0 ... -view.aspx