Designing Widgets
Designing widgets, especially viral widgets, may be an unfamiliar challenge for many designers. Unlike most HTML designs, widget designs must work well on a number of different web sites. Even worse, the content of the posts within the widget may be unknown. Following are some general guidelines for designing widgets and implementing them in HTML and CSS.
Dealing With Host Pages
Viral widgets will be placed on a huge number of web pages that you don’t know anything about and have absolutely no control over. The pages will use HTML4, XHTML Transitional or XHTML Strict or maybe even HTML5. They might have a DOCTYPE that puts the browser into standards mode or they might leave the browser in quirks mode. They might use CSS to redefine the appearance of basic HTML elements. They will place your widget in odd places on their page.
Because host pages are so unpredictable, dealing with them can be the biggest challenge in designing and coding a widget. You must try to predict what could go wrong with the widget and try to code defensively to avoid problems. The following guidelines will help you on your way.
Avoid complex designs if possible, particularly designs using floats. It can be very difficult to make these layouts work in the face of quirks/standards mode changes and varying CSS rules from the host page. Instead, consider using table-based layouts. Yes, it’s so last century and all the cool designers are using floats, but tables are very predictable across all browsers and in nearly all circumstances.
Some pages, notably Blogger sidebars, use CSS ID selectors that will override CSS class selectors. Therefore you should wrap your entire widget in an element with a carefully chosen ID, and base all your selectors on that ID. For instance, #NewsCo_Photo_Widget_${BuzzId} .title_${BuzzId}. Note that the ${BuzzId} token is used in both the ID and the class name. This protects against overlapping styles from styles on the host page as well similar widgets that may be on the page. This one change may save you enormous amounts of testing and rework time.
Define any CSS styles you use, even those that you use implicitly. For instance it’s good practice to define text-align:left, even though that’s the default, because some blog sidebars may have a different default alignment. Other commonly overlooked styles are color, background-color, font-family and font-size.
Remember that you don’t know whether your widget will be placed on the page. It may be in the center or up against the left or right side of the page. It may also be inside an <IFRAME> just large enough to contain it, as is the case with iGoogle. Therefore it is not wise to create flyouts to show article details or ads.
The amount of horizontal space available to you will vary as well, from 170px in a Typepad sidebar up to as much 800px in the center well of a page. This means you must be careful about using large images. If an image can be made that will work in any size you can make it the background image on an element. That way the browser will show as much as possible while still fitting into the available space. Just remember to make sure the image will make sense in all sizes.
Dealing with Content
If you are using content from feeds that you don’t control consider what might be in the posts. Sometimes posts contain large images, long words or URLs that won’t wrap properly, or other odd HTML Frequently your best bet is to use the stripHTML modifier to remove all HTML from the post Description.
Posts may also have very long descriptions. Some posts descriptions run to several pages of text. So it’s a good idea to use the excerpt modifier to ensure posts don’t go on for too long.
If you are counting on photo or video content in your widget remember that posts do not always have media attached. Even in feeds that nearly always have media there may sometime be a post without media, so be sure to use {if} statements to ensure that the media is available.
Javascript
Writing Javascript code for widgets will be the topic of another article. But remember that your Javascript code is loaded into the global context along with all the other Javascript on that page. Therefore you must be careful about naming your functions and variables because they might conflict with other functions on the page.
The simple solution is to use very uncommon names. A more advanced solution is to use a closure or custom class.