Posted by admin on Jan 12, 2009 in
browsers So the bug I was working on today had to do with the error messages. In Firefox 2 & 3, and IE7, they show up great! Nice yellow background, red text, red border. Nothing fancy, but it definitely sticks out. IE6 gives me the fancy red text, but no background and no border. So off I go on the hunt to figure out why, oh why IE6 has cursed me so.
During my stalking of the interwebs, I came across the adobe forum and someone who had problems with their disc showing up on their <li> elements. Okay says I, how can I use this to my advantage? I read through the comments and the IE6 background bug strikes me like a brick in the forehead. Of course! I’ve solved THAT one before.
So the simple problem boils down to this code:
<span id=”errorMessage”>
<ul class=”errorMessage”>
<li>Some Error Message Goes Here</li>
</ul>
</span>
At first glance, there’s nothing really wrong here. The span has a display:block on it, so it should be great right? Yeah, not so much. Since IE doesn’t expect that a span would ever be used as a block, an explicit width must be set (the background bug solution). So my CSS now looks like this:
span#errorMessage {
display: block;
width: 590px;
}
Now just to be retentive, I’ve also set the <ul> and <li> elements:
ul.errorMessage {
/* added to correct IE6 error styling */
display: block !important;
display: inline;
}
ul.errorMessage {
display: auto !important;
display: block;
}
So now, my IE6 has some specific settings and my FF and IE browsers completely ignore it, thus solving the problem.
Hope this helps!
Other references to this and similar IE bugs:
Missing Backgrounds Bug
The IE7 CSS Hack | iBloom Studios
IE7 Repaint Bug
Tags: browser bug, ie6
Posted by weatherangel on Dec 9, 2008 in
browsers In an article by Ed Eliot, he talks about why Automatic versioning of CSS, JavaScript and Images is a good thing.
When including CSS and JavaScript resources in your pages you should version file paths and update these version numbers every time the files change. This is necessary as a visitor’s browsers may, depending on settings, continue to cache files even after a change. This can result in a mismatch between your HTML and these external resources which may cause rendering or functionality problems. One will likely encounter similar caching issues with images.
Tags: cache, SEO
Posted by admin on Dec 9, 2008 in
browsers It goes hand in hand with unobtrusive javascript, and really is just another name for the same thing. Here are some quotes from some decent articles on the subject:
from Dan’s Web Tips by Daniel Tobias
“Graceful Degradation” is an important principle in Web design. It means that, when you put in features designed to take advantage of the latest and greatest features of newer browsers, you should do it in a way that older browsers, and browsers letting users disable particular features, can “step down” to a method that still allows access to the basic content of the site, though perhaps not as snazzy in appearance.
from Augmentative authoring
- a different look at “graceful degradation” in Web authoring
The phrase “graceful degradation” is often used to describe the idea that a Web page that uses special technologies for presentation enhancements, animation, interactivity, etc., should “degrade” to a simpler, yet fully functional page in circumstancies where the technologies are not applicable. This document takes a somewhat different view: instead of considering how to provide “fallbacks” for various advanced constructs, we consider how to create first a robust document that works always, then augment it by providing optional alternatives to the simple constructs. We’ll discuss the different techniques that are needed for different enhancements.
We currently have a lot of old legacy javascript menus which contain all of the links to the various places on our sites. In our latest efforts, dubbed T2, we have introduced Spry and YUI libraries which use non-obtrusive javascript to manage the menus, sliding panels, collapsible panels and popups. In the article JS Menus – Good or Evil? the author highlights a few good reasons to get rid of those old javascript only menus and replace them with the new-fangled way of doing things in the Web 2.0 world, like Suckerfish. This article was written sometime in 2003, so it is quite old (as is the Suckerfish reference), however you will find after looking at the Suckerfish article that the SpryMenu we are using is actually uses this exact unobtrusive theory.
Tags: accessability, css, graceful degredation, javascript
Posted by admin on Dec 9, 2008 in
browsers In my google search for why inline javascript is evil, I was able to come across some interesting information that was relevant and some that was not so relevant. The relevant part was this article on Separating Behavior and Structure. The article was written by the author of quirksmode.com, which happens to be a site I often frequent to find out why IE6 is so evil to me. The short answer is usually that there was a bug that I didn’t know about, but the author explains nicely, or has a reference to the explanation and off I go to solve the problem. Definitely a site for the tool box!
The article went into javascript leaking memory at one point, and I had to digress to figure out what that was all about. At work, I use a lot of Spry and YUI, and frankly don’t want to kill people’s browsers because I did something stupid, or didn’t clean up after myself. These two articles go into how DHTML leaks like a seive and how the IE6 bug fix to correct memory leaks was greatly exaggerated. In short, if you tie the DOM to javascript, untie it before you leave. This is something that I am no generally doing today, and must fix in my code, preferably on the library side. I would have thought the libraries would be set up to handle this automatically, but it appears not so much from what I’ve read so far.
The irrelevant information found, while on quirksmode.org, also happens to help me with other subjects that I’ve been reading up on and working with. There was an article showing the new CSS compatibility changes, adding the Google Chrome browser to the mix, as well as an article on iPhone events. The iPhone events article was information I have pretty much figured out by having an iPhone myself, but it is a good read anyway just to solidify my findings, or bring to mind things that I may not have been paying much attention to. Through QA, we have found that the Google Chrome browser acts just like the Safari browser, which we were already watching out for. This is good news to me, one less browser that I really have to *worry* about.
I will continue to link back to articles that solve my probems, or at least give relevant details both for my and your reading and educating pleasure.
Tags: inline, javascript
