I’m talking of course about Brian Wilson’s Index DOT Html and Index DOT Css sites. I have been using these sites over the past 8+ or so years as one of my primary resources when it comes to Web Development. They document the majority of the HTML and CSS elements and properties, how they work and what browsers support them (and to what degree) – complete with browser specific tips and notes.

The sites may not be up to date with Firefox 3 and Internet Explorer 7 or 8, but the information they provide is still very relevant and still very useful. They’re always my first stop when I need to look up a particular HTML element or CSS property, and to be honest I don’t know where I would turn if they weren’t around for me to use. I suppose I owe Brian Wilson an enormous thank you for all his hard work and dedication to the sites, and I’m pretty sure that there are many others out there who owe the same as well.

Brian, thank you for two of the most useful resources available on the Internet over the past decade or so.

After doing some initial debugging, it seemed that my responseText was coming back blank – but Firebug clearly showed that Firefox was getting the full DOM document back from the AJAX POST call, so I knew something was up with how the response was being handled by AJAX. Now, I use jQuery for the majority of my JavaScript code, so I was a bit surprised to find out that there was an AJAX problem since I figured that a bug like this would have likely at least already been reported. After a lot of searching on Google however, I only turned up one result that was quite similar to my problem which had no resolution. So it looked like I would have to solve this one entirely on my own.

I did more debugging, and out of pure luck I ended up noticing that the readyState on my XHR object was set to 0, which means that apparently an AJAX call hadn’t even been made yet. I found this rather odd to see a readyState of 0 since clearly an AJAX call had been made (and returned with success). I thought about the situation a bit and figured that perhaps I should move my debugging call (I was using console.log()) up the chain a bit so I did it as the first call from my AJAX completion callback function. After doing that I noticed that it was now correctly showing a readyState of 4. This meant that somewhere down the line, something was happening to my XHR object causing the readyState to be reset… and possibly resetting my entire XHR object!

Sure enough, I was indeed correct! The problem was that I was trying to directly access my XHR object from within a jQuery animation callback which obviously uses timers. Now, here is where I speculate because the problem only happens in Firefox, but I’m guessing that the XHR object was somehow being reset or altered after some time… very likely an internal browser cache system that was purging my XHR object. My solution was to simply copy the responseText to a variable before entering in to any timer based jQuery calls (essentially, I assigned the responseText to a variable as the first call from my completion callback function). Then, from within my jQuery animation callback I simply referred to the variable I created which had a copy of the responseText. No more random blank responseTexts!

Well, I’ve since run in to a situation that using float: left wasn’t working for me (try centering a set of divs that have float: left – it’s a pain!), so I had to find some kind of way to use inline-block.  Thankfully, Internet Explorer 8 and Firefox 3 support inline-block now, but we still have to deal with those hard-headed users that take forever (or never) to upgrade their browsers.  To accomodate Internet Explorer 7 and Firefox 2 we have to use some CSS hacks (what else is new!); thankfully they’re not that bad (but it still invalidates your CSS… bummer).

First, you must make sure that you do not throw the browser in to quirks mode, otherwise it won’t work just right.  This means specifying a proper DOCTYPE on your document (and if you’re using XHTML, don’t include the <?xml … ?> tag at the top).  Once you have that out of the way, it’s just a little bit of CSS to add to the element(s) you want to display as inline-block:


display: -moz-inline-box;
display: inline-block;
zoom: 1;
*display: inline;
vertical-align: top;


The first line sets a special Firefox property that we need for Firefox 2. The second line obviously sets the display to inline-block (and Firefox 2 will ignore this setting since it doesn’t understand inline-block). The third sets an IE-only property called zoom to a default 1 (no zoom) which triggers a switch in Internet Explorer 7 to enable hasLayout which allows the divs (which are block elements by default) to inherit inline display features. The fourth line re-sets the display to inline for Internet Explorer 7 to get the final effect we’re looking for. The last line fixes part of the word spacing problem we’re about to mention below.

As mentioned, there’s still one small problem which you may notice – inline items get word spacing applied to them because they’re now inline elements. That means that any space between your div tags will show up in your layout (even newlines!).  If you’re trying to get your div blocks to sit side by side without any spacing, you’re probably pulling your hair out because of this spacing.  There’s two fixes for it – the first is to simply get rid of it, though this usually means killing any readability in your back-end programming (if any is used) and mushing all your HTML code together in to one long line which sucks too.  The second way to fix it is with a bit more CSS around the container in which all these divs are in:


word-spacing: -1em;


That line of CSS sets the word-spacing to -1em, which is like doing a backspace of 1 character to get rid of the blank space caused by any white space or newlines between your divs. The vertical-align: top CSS we already added to the individual divs gets rid of the spacing between the divs above and below, but it doesn’t fix the spacing to the left or right. By adding a negative word-spacing, we get rid of the spacing on either side of our divs which gets rid of the last of our problems.

There you have it – a cross-browser inline-block CSS solution, and even a fix for any erroneous spaces in your HTML markup that you probably won’t want either. I haven’t tested these fixes in Internet Explorer 6 for a few reasons; I refuse to code for Internet Explorer 6 any more since the browser is so old and Internet Explorer 8 is now officially released so users really should upgrade.

I did notice a problem with RoboForm’s Firefox XPI toolbar plugin however, in that when you had a “minimalistic” window open (such as view source, or a JavaScript popup that had no toolbars specified), it would still attach the RoboForm toolbar to it at the bottom, usually hiding any horizontal scroll bar the window had. Now it’s not such a big deal to just click the little close box on the toolbar so I could use the scrollbar, but it is still very annoying since I tend to use the “view source” feature quite a bit. I also know that this is very much a bug in their program or adapter because I have other toolbars in Firefox which do not exhibit this same behaviour.

So I figured I’d be nice and bug-report the problem for them to ensure they were aware of it. I was somewhat surprised however with how their support staff (William, or so he decided to call himself since his Indian name is probably not “customer friendly” or something) has decided to handle it.

You wrote (2007/02/07 08:05 pm EST)
Hi,

With the RoboForm toolbar set to be attached at the top of my browser toolbars, whenever I “view source” in Firefox (and it creates a new minimalistic window), the RoboForm toolbar gets attached at the bottom of this new window, and seems to overlay the horizontal scrollbar (if present). I have also noticed the same behaviour when you get a popup window in Firefox.

I am running Windows XP SP2 with all the latest patches, under a normal user account with RoboForm2Go 6.8.4 running from a U3 usb key. My version of Firefox is “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1″.

I can send a screenshot if required – just let me know (I’m not sending one now in case that causes your systems any issues). I had checked your online FAQ but did not notice this issue mentioned anywhere so I am not sure if it’s known or not.

If there’s a fix (or if you’d like me to try a beta/patch), please let me know as I “view source” quite often and have to close the roboform toolbar all the time to use the scrollbar!

Thanks,

Eli.

John replied (2007/02/13 06:36 am EST)
This is already known bug. We are working on solution.

William replied (2007/02/18 02:06 pm EST)
Now we added option to RoboForm -> Options -> General: Attach to Firefox if Adapter is not installed.

Uncheck it and RoboForm will not attach to Firefox if its XPI is not installed.

You wrote (2007/03/26 06:45 pm EST)
Hi,

I am unfortunately still having problems with the RoboForm toolbar attaching itself to windows that it shouldn’t. I have upgraded to 6.9.1 (and also upgraded the FireFox adapter to 6.9.1) and I have unchecked the option to install the toolbar when the adapter is not present.

It seems to work sometimes that the toolbar isn’t displayed *if* my browser (Firefox) was already open before I launch RoboForm2Go. However, if I close my browser windows, then re-launch FireFox and “view source”, the toolbar is attached at the bottom overtop of the horizontal scrollbar.

Let me know if you require any additional information.

Eli.

William replied (2007/03/27 12:04 am EST)
you should uninstall XPI Adapter and never install it again.

only roboform can install adapter now — not you.

XPI Adapter from now on will only create problems.

You wrote (2007/03/27 02:56 am EST)
Hi William,

Ok, I have removed the Firefox XPI adapter now and it appears that the RoboForm toolbar is always attached at the bottom of my browser window, never at the top where the options are set to have it displayed. Viewing the page source also displays the toolbar.

I also enabled the checkbox for displaying the toolbar even if the XPI adapter was not installed (since I had to so the toolbar would display).

Eli.

William replied (2007/03/27 12:55 pm EST)
after you uninstall XPI adapter, you should reinstall RoboForm and check “Install Adapter” box in RF installer.

then it installs the new style Adapter that should do everything well.

you can also do it from RoboForm -> Options -> Adapter.
make sure you see only one new style (not XPI) adapter there.

You wrote (2007/03/27 04:52 pm EST)
Hi,

The RoboForm2Go installer does not have an “Install Adapter” checkbox, and the “Install Adapter” and “Uninstall All Adapters” buttons in RoboForm -> Options -> Adapter are both grayed out (under both Administrator and my normal user accounts) and I cannot click them (tried with Firefox open and also not open).

Eli.

William replied (2007/03/27 10:06 pm EST)
roboform2go can attach to Firefox only at the bottom.

upper toolbar is available only with RoboForm Fixed (installed on computer).

You wrote (2007/03/28 03:00 am EST)
Hi William,

Having RoboForm2Go only able to attach at the bottom of my browser window despite the options clearly stating it’s supposed to be attaching at the top would indicate a bug of some sort. Having to purchase/install the full version of RoboForm just so that I can have my RoboForm toolbar *not* attach on windows where the other XPI toolbars don’t attach is clearly not a fix I am willing to accept.

I would at this time like to request you escalate this ticket to your manager or to someone in the software development department of your company, as it is clear there is a bug (other Firefox XPI plugins do not have this problem, only RoboForm) in your product and I am attempting at helping you resolve this bug, however all your solutions provided to me at this time in trying to help me work around it have failed.

Eli.

William replied (2007/03/28 02:47 pm EST)
we removed this from Firefox page and it does not state this anywhere now.

now RF attaches at the top only if this is Fixed RoboForm.

RoboForm2Go attaches at the bottom for Firefox.

You wrote (2007/03/28 02:59 pm EST)
Hi William,

Please escalate this ticket to your manager. You do not seem to understand how to aid me in resolving this issue and I am starting to find your replies extremely unhelpful.

The option to attach at the top is right in the options for RoboForm2Go. I don’t care what your website says, it’s clearly stated and selectable as an option within the program.

It’s safe to say that at this point I’m extremely frustrated with trying to deal with William and his feeble attempt at grasping what the hell I’m trying to tell him. Hopefully I’m able to get the attention of someone a bit more in tune with customer support and actually get somewhere with this – like helping them fix the bug perhaps!