Nettuts.com is one of my new favorite web development blogs. One of their recent posts is pretty cool, especially for those new to web development.
For some unknown reason, a significant amount of people still use Internet Explorer 6 as their browser of choice. Since that’s the case, web developers such as myself have to continue to test our websites in IE6 to make sure they work as desired. The majority of the problems in IE6 caused by CSS can be resolved by using a Global Reset Stylesheet and by building in valid, clean code. However, problems still remain, such as IE6′s inability to support alpha-channel transparency for PNG image files.
There are a number of options for getting PNG transparency to work in IE6:
SuperSleight (http://24ways.org/2007/supersleight-transparent-png-in-ie6) – I’ve also used this before but it’s a bit awkward and clunky since it uses a proprietary filter called AlphaImageLoader. It might be worth looking into if you’re looking for something that has been updated more recently than 2004, but it still does not support the background-repeat property, which is the only reason I would not use the initial pngfix.js.
IE PNG Fix (http://www.twinhelix.com/css/iepngfix/) – This one uses CSS behaviors, which is a custom Microsoft extension to CSS. It apparently also uses the AlphaImageLoader filter that SuperSleight uses. Most importantly, the IEPNGFix v2.0 Alpha version found on the test site apparently now supports the background-repeat property. If that’s the case, then I have found a new PNG fix! I haven’t used it yet but once I do, I’ll update the blog with my observations.
Until Microsoft requires users to update their browsers from IE6, we will always be presented with the problem of PNG transparency. Hopefully, the options above will help!
Here’s a sweet keyword research tool from Wordtracker. Plug in a keyword for a list of the most frequently searched questions containing your keyword.
Ever since I upgraded to Dreamweaver 8, I’ve been annoyed by the _notes folders that are automatically created in each directory of the site. Of course, they are hidden in the Dreamweaver file view but they are visible in Windows Explorer if you are not hiding hidden file types. I often find myself having to delete these folders whenever I package up website files to send to other developers or designers. This link below provides a solution so that Dreamweaver 8 never creates the _notes folders and dwsync.xml files in the first place.
“Macromedia Dreamweaver 8 creates an _notes folder, even when you have the preference turned off in the Design Notes category of the Site Definition dialog box. Dreamweaver also creates a dwsync.xml file inside the _notes folder. When you run Clean Up in the Design Notes category of the Site Definition, Dreamweaver does not delete the dwsync.xml file or the _notes folder. (Ref. 196185)
Dreamweaver 8 keeps file synchronization information in the dwsync.xml file which is located in the _notes folder. Although the dwsync.xml file resides in the _notes folder, it is not a Design Note. The Clean Up design notes command only cleans up MNO files.
If you don’t use Dreamweaver’s Synchronize feature, you can disable the “Maintain synchronization information” option from the Remote Info category of the advanced view of the Site Definition dialog box. This will delete all of the existing dwsync.xml files and stop the creation of future dwsync.xml files and _notes folders.
Note: Disabling the “Maintain Synchronize Information” option will prevent you from using Dreamweaver’s Synchronize functionality.”
The majority of the websites I develop for clients have contact forms on them for a variety of reasons. First, it’s more convenient for users to fill out a form within their browser window as opposed to requiring them to open up their email software to write an email from scratch. Second, it’s the primary method of measuring generated leads/conversions, and clients can require exactly the information they need to qualify leads. Third, by using a contact form, clients won’t have to publish an email address on the site for spam bots to harvest. However, contact forms are definitely vulnerable to being flooded with spam and that’s why I am writing this post on how to prevent exactly that. I use a variety of methods which tend to prevent 99% of automated spam submissions:
Step 2. Validate The Referrer – If you are using a separate file to process the form, make sure to validate that the form is being submitted from the page with the contact form. This will prevent bots and spammers to automatically access the processing file to spam it. However, the referrer can easily be spoofed and often is, so this method alone is certainly not bulletproof.
Step 3. Hide Fields with CSS – Most bots and spammers will automatically fill out every form field that is on the page. One way to stop them is to insert a blank field in the form but hide with CSS “display: none;”. Add some code to your form processing file to check to ensure that the hidden field remains empty; if it’s not, it’s most likely filled out by a spammer and thus should not be processed.
Follow those 3 steps and you’ll be much better protected against contact form spam. There are definitely additional measures you can use such as more complicated JS validation, CAPTCHAs, and asking simple questions that only humans can answer (1+2=?, what color is a cardinal?, etc.), but I’ll write more about those in another post.