April 5th is the second annual CSS Naked Day. The idea behind it is to strip all the CSS from your site/blog to show the standards based content underneath. It's to promote web standards and help developers remember that it's important to code things using proper semantic markup to create a valid foundation for your site. What does your site look like naked?
To know more about why styles are disabled on this website visit the Annual CSS Naked Day website for more information.
I just spent the last several days troubleshooting this bug and since I couldn't find any information anywhere on the web for this obscure problem, I'm posting it here.
For a new site I'm building I have randomly loading promo buttons which are created in Flash. Since they're random and will appear on multiple pages, they need to be transparent. Nothing out of the ordinary, but when I put the page together I noticed a very peculiar error...
ONLY in Firefox 1.5 on a PC (2.0 was fine, Mac was fine) and ONLY when the swf had it's wmode property set to transparent, the swf would load but then be inoperable. No rollover animation or button click events would fire. It just sat there doing nothing on the page.
I tried everything to make it work... multiple embed methods, different flash publishing settings, etc. Nothing seemed to help until a colleague steered me, oddly enough, toward the CSS for my page.
My Flash promos where in a floated div tag for the left column of my page. The container element for the page columns contained a few styles, one of which was "overflow: auto;". This was being used to help clear the floats. A simple switch to "overflow: hidden;" magically solved the problem.
I’m still not 100% as to why this problem occurred. I was careful with my widths and paddings to make sure there weren’t any actual overflow problems but for some reason older versions of Firefox were just not happy with it. So there it is… if anyone else ever encounters this very odd random bug, check the CSS overflow property for the solution.
Recently I was asked to help on a project which involved a lot of Flash work. During one of the meetings someone suggested that we absolutely position a small Flash file over top of a larger background Flash file. Since none of us had actually done that before, I was given the task of figuring out if this would work in all of major browsers.
After a couple hours of testing I concluded that it will indeed work. In order to do so, the background Flash file MUST be transparent (accomplished by setting wmode="transparent"). Once that's done you can layer whatever you like over top of it including a 2nd transparent Flash file, a solid-color Flash file, or any kind of HTML content.
Browsers tested were:
IE 5.2 (Mac)
IE 5.5
IE 6
IE 7
Firefox 1.5
Firefox 2
Safari 1.3
Safari 2
Camino
Opera 9
Netscape 7
Netscape 8
As each year goes by the amount of browser/platform combinations continues to grow and grow. One of the main challenges we face as developers is trying to build sites that look great in all of the new browsers but don't look like a catastrophe in the older ones. What's the cutoff point though? Which browsers do you support and which do you not care about?
I don't really think there's a definitive answer to that question. I'd say that it largely depends on the site you're building and it's demographic. Code Scene, for example, is targeted primarily at web developers so I don't care if it doesn't work in Netscape 6. If you're a developer and your browser of choice is Netscape 6, then you have more problems than Code Scene can solve. On the other hand, if my target audience involved public schools and libraries which may have outdated machines I'd want to make sure that the site was accessible in older browsers.
"Accessible" should be the key word here. You'll go broke and/or crazy trying to get your site to look pixel-perfect in every browser. You should concentrate on making it perfect in the ones that count and making sure that at least the content is accessible (although not 100% pretty) in the others. You can do this with a wide variety of tricks such as using @import to include your CSS files. Modern browsers will render them. Netscape 4 will ignore it completely and render an accessible non-styled text version of the site.
Again, while the answer to the "What browsers should I test in?" question is different for each client, there is no question that some browsers are more important than others so this is my opinion on which should be prioritized when building a new site.
I've based this on browser data from TheCounter, W3Counter, Browser News, Market Share, and the analytics reports of a few sites I've built. If you're re-building an existing site, the analytics reports are a great way of seeing what browsers people are using.
Without further adieu, here are my recommendations for which browsers to prioritize.
Priority 1 - Your site MUST work flawlessly in these browsers since they account for the majority of Internet traffic.
Internet Explorer 6
Internet Explorer 7
Mozilla Firefox 2.0
Mozilla Firefox 1.x
Priority 2 – These browsers are somewhat older and/or less popular but your site should look good and work properly in them. (If you expect large amounts of traffic from Mac or Linux users then you may want to move Safari and Konquerer to Priority 1)
Internet Explorer 5.5
Netscape 7+
Safari 1.2+
Camino 1+
Opera 9+
Mozilla 1.x
Konquerer 3.4+
Priority 3 – These browsers are outdated and not widely used at all. Steps should be taken to make sure the site is accessible and/or downgrades to a text-only version in these browsers.
Netscape 6
Mac Internet Explorer 5.2
OmniWeb
Netscape 4.x
Internet Explorer 4.x
Lynx
Again, these are just general recommendations. Always keep your audience in mind when making the final decision. If you have agree/disagree, leave a comment below.
What does your website look like in Safari 1.3? How about the Firefox 2.0b1 beta? The Konqueror browser on a Linux box? You really have no idea do you?
Most developers test their pages on the one or two browsers they have installed on their machine but rarely in any others and usually never in any older legacy browsers. This isn't necessarily a sign of laziness. It's just really time consuming and expensive to setup a dozen test machines with different browser configurations. That's where BrowserCam comes in.
BrowserCam is an online service which has all of these platform/browser combinations setup for you. With a BrowCam account you can test how your sites render on the widest range of possible clients and make sure everything is perfect before launch. See BrowserCam's complete list of browsers.
There are two main features available through BrowserCam.
To demo, I've used my account to take screenshots of how Code Scene looks in a wide range of browsers.
Linux Konqueror 3.4.0-5
Mac Camino 1.0
Mac IE 5.2
Mac Safari 1.2
Mac Safari 1.3
Mac Safari 2.0
PC AOL 9.0
PC IE 4
PC IE5
PC IE5.5
PC IE6
PC IE7RC1
PC Firefox 1.5
PC Firefox 2.0b1
PC Mozilla 1.6
PC Mozilla 1.7
PC Netscape 4.78
PC Netscape 6.2
PC Netscape 7.2
PC Opera 8.5
PC Opera 9
As you can see, Code Scene looks great in most of the newer browsers while failing miserably in some of the older ones. So what browsers should you really care about? Stay tuned for my next post on that.
For now... if you're a developer and need to QA how your site looks in different browsers, BrowserCam is the cheapest and easiest way to make that happen.
This is quick and simple tip but I know a bunch of people who weren't aware of it so I felt it warranted a post. We all know that CSS classes are a great way of applying a specific style or position to an element. However not a lot of people know that you can apply more than one class to an element. I've seen many people have styles like this:
.indent { padding-left: 25px; }
.highlight { background-color: #ffff00; }
.highlightindent { background-color: #ffff00; padding-left: 25px; }
While there isn't anything wrong with that third style, it isn't neccessary. You can apply both the indent style and the highlight style to the same element, just separate them with a space, like this:
<p class="highlight indent">This text is highlighted and indented</p>
1 element. 2 classes. That's all there is to it. If you have a quick tip you'd like to see on Code Scene, send it to jay@codescene.com
A few days ago I posted a "critical thinking exercise" which was designed to help you learn the type of things you should be looking for when you do a code review.
As promised here are the answers:
One of the biggest challenges in this field is often finding the time to do a proper QA process on projects before they launch. Tight deadlines and last-minute changes often eradicate much of the time that should be allocated to QA.
So if you're launching a new website, and you only have a handful of minutes to do QA, you need to make sure that you know exactly what to look for. To that end, I recently developed a simple critical thinking exercise for my development team to help them learn the types of things that they should be looking for when they do a code review.
This is a basic HTML page that I've created and riddled with bugs, errors, and other things that are not best practices for the industry. There are some things that are simply coding errors like malformed tags. Other things, while they may be technically correct, will impact things like SEO and 508-compliance so they should be corrected.
Look through this HTML file and see how many problems you can find. I'll post the answers in a few days.
As Dave Shea from mezzoblue points out, IE7 Beta 2 is available and while there still may be some minor tweaks and bug fixes before the final release, the new rendering engine is finalized. The good news is that Microsoft has put a lot of work into properly implementing CSS and adhering to web standards. The bad news is that the hacks and tricks you used to make your site work in IE6 may now break it in IE7. Code Scene itself has a few quirks that I'll need to iron out in order to make the site look pretty in IE7.
One of the most noticeable differences is in the way CSS floats are rendered. The "easy clearing method" I've grown so fond of is no longer a viable option for clearing floated elements. Anne van Kesteren's method of "super simple clearing floats" seems to do the trick though.
Do yourself a favor and download the beta now and test all your sites. Make whatever adjustments you need to make now, before the final version is released and you get the angry phone calls from the client.
It seems like about everyone I know has asked me questions this week related to best practices for building HTML emails and newsletters. It can be a tricky business so I've decided to assemble a few basic rules to follow that should help. In no particular order:
Avoid CSS
It hurts me to say that since I preach CSS as gospel in any other situation but support for it just isn't all that stellar in email clients right now. Write your code in HTML 4.0 and try to minimize or eliminate the use of CSS.
A good idea is to use inline styles such as:
<p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size: 11px;">Remember to keep checking <a href="http://www.codescene.com" target="_blank"><font color="#2168C4">Code Scene</font></a> for the latest info.</font></p>
Newer clients will read the style property to set the font size while older ones will fall back on the HTML size attribute of the font tag. Everybody wins!
Hand-coding is also a good idea since WYSIWYG editors sometimes don't do the best job of writing clean code.
JavaScript
None. Ever. Forget it. I don't even know why people still ask about this.
Base Tag
While this works for most email clients, certain ones have trouble processing it so don't rely on it. Store all your images on a server and make absolute links to them.
I.e. <img src="http://www.mysite.com/images/whatever.jpg">
Background Images
For newsletters that require a background image or color, the 'background' and 'bgcolor' attributes of the BODY tag must NOT be used since most web-base email clients will not properly display them. Same goes for adding CSS to the body tag. What did I tell you about CSS anyways? The solution is to encapsulate everything in a container table or div tag and apply your background colors and images there.
Validated HTML
Malformed HTML code, non-standard characters, such as missing end tags or non-quoted attributes can cause display problems, especially with web-based email clients like Hotmail. To ensure that your code is valid, use the W3C Markup Validation Service at http://validator.w3.org/ to check your code for errors before sending it.
Testing
Whenever possible, test your HTML email in as many different clients as possible before sending it out. It's easy and free to sign up for all of the major web-mail clients so you have no excuse.
Use Image ALT tags
This should go without saying. If images are slow to download or turned off, the ALT tag will give a description of what the image was meant to convey.
No rich media
Many email clients still have problems with flash, video, or form components. It's much better to host those elements on your website and use the email to direct users to them.
One of the great things about building your websites using web standards is that the content is completely separated from the design. Since the design is controlled entirely through CSS it becomes simple to change. Add a style sheet switcher to your site and you can even let your users control the design. Click the colored buttons below (or on the right nav) for a demonstration.
Now why exactly would you want to give your users control over how your site looks? For CodeScene, I've done it simply because I think it's a cool trick that illustrates the separation of content and presentation. A far more practical use however, would have been to create styles with varying levels of font sizes and contrast. This would add to your site's accessibly by allowing the user to choose the style sheet that is most comfortable for him/her to read. Since CSS also controls not only the colors but the layout, you could use a style sheet switcher to control that aspect as well to perhaps show/hide a navigation bar. Use your imagination.
For those interested in the code behind it, it's a relatively simple javascript library that turns alternate style sheets on and off, and then sets a cookie to remember which one was selected. It was written by Paul Sowden and can be found in the article Alternative Style: Working With Alternate Style Sheets on the infamous A List Apart.
Select a style:
