Radiant Core: HTML/CSS

Another site launches

Wed, 09 Jan 2008 12:00:00 GMT

We were very excited to see that our friends (and clients) at Wildeboer Dellelce LLP launched their new site this week. It's a very different looking site for a very different law firm, and has features such as live-filtering lawyer and transaction listings (with obligatory vcard downloads), customised JavaScript market update on the homepage, and plenty of RSS feeds.

I'm especially pleased because I headed up the design and build - call it a little parental pride!

The project includes some interesting technical elements - all AJAX is built using the YUI toolkit; we've added some handlers in place to combat Internet Explorer's difficulties with displaying layers over HTML elements such as drop-downs; and there are a number of interesting cross-links between content areas that combine for great exploration.

HTML5 and CSS3

Sun, 21 Oct 2007 11:18:00 GMT

We currently write websites to the XHTML 1.0 Strict specs, which was published by the W3C in 2002 and extends the HTML 4.0 specs, which were published in 1997-1999. Although it may not feel like it when you pay attention to sites like TechCrunch, the pace of change in the technologies which underly the web is actually remarkably slow. It would be fair to say, from a purely HTML-focused perspective, that there have been no major innovations in nearly ten years (if you don't count XHTML as anything more than a natural evolution of HTML). Even the Cascading Style Sheets 2.0 spec (CSS2) that we use to format and display websites is nearly ten years old, having been published in May 1998.

So, almost needless to say, we're getting really excited about the emerging drafts of the HTML5 and CSS3 specs. This may seem somewhat abstract to some of you, particularly if you don't do what we do, but it means your websites are 'about' to gain some great new functionality which will solve a number of the problems we bump into on a regular basis. Some things we're really looking forward to:

CSS3 Fonts: The technology to embed fonts in a web page was first specified a long time ago (so long ago that there's a webmonkey tutorial!), but support from the browser makers never materialized and it died in the water (for a complete history, I refer you to our esteemed colleague, Joe Clark: Simon Daniels: Web font embedding rides again!). This is a very complicated issue given that the web exists in virtually every language on the planet (does your favourite font include a full set of Kanji characters?), and that fonts have licenses (just like other software) and many of those licenses prohibit things like embedding them in web pages. CSS3 brings it back to life with the @font-face at-rule, which means that we will finally be able to use something other than Verdana, Trebuchet, Georgia, and Arial.
CSS3 Multiple Columns: Clients who are used to working with print layouts are often surprised to discover that there's no way to automatically layout HTML content in multiple columns. Sure, we can count out the total number of elements in a list, divide by two, then output the first half, end the column manually, and finally output the second half, but that's about as tedious as it sounds. The Multi-Column Module in CSS3 makes it about as simple as specifying:
```
column-count: 2
```
and Bob's your multi-column uncle.
HTML5 Client Side Storage: Of less import from a visual perspective, Client Side Storage gives web applications the ability to store data locally in the browser, which effectively makes the app accessible offline (e.g.: if you had a website which allowed people to store recipes and share them, client side storage would make those recipes available even when Tom's laptop wasn't connected to the Internet and he was in his kitchen making Duck à L'Orange). This is fundamentally similar to Google Gears, but would mean that your site's visitors wouldn't need to install anything in their browser to make use of the technology. Congrats to Dave Hyatt and the WebKit team, who have announced preliminary support in the latest nightly builds.

Keep in mind that we're a good five years away from actually being able to make use of these fun new features, since they'll have to get built into the next release of the major browsers, and then those will take some time to eventually replace the current versions in popular enough numbers to make the new stuff widely available. As always, we'll do our best to keep covering the new specifications for your ongoing edification, as well as to start producing some fun samples for you to play with once some browsers with HTML5 and CSS3 support become a little more stable and easy to download.

exPhone (New) Home

Thu, 05 Jul 2007 22:46:00 GMT

Are you one of the lucky 700,000 new iPhone owners? Wondering what to do with that clunky old BlackBerry or Nokia that you used to love but now can't even look at without stroking your new toy happily? Enter exPhone, a site dedicated to helping you find ways to responsibly reuse or recycle your old cellphone. Launched by our good friends at Citizen Agency, with the help of We Know HTML, the site is chock full of great info about how to donate or recycle old cellphones, as well as important things like reminding you to erase them first. Or you could save yourself the trouble and just send us your iPhone. We'll take good care of it. Promise.

Fixing an IE 7 bug in mm_menu.js navigation

Fri, 16 Feb 2007 13:15:00 GMT

We're proud (even stubborn) hand-coders, so we don't often get the opportunity to delve into the JavaScript libraries deployed by using applications such as Dreamweaver.

Recently, however, we were contacted with an IE7 bug: a navigation system that was using the mm_menu.js library appeared to be only showing the first word of each option.

At 800 lines of dense JavaScript, this was not going to be fun to debug. Fortune, however, smiled upon us in the form of an invidual named Hiroto, who posted the following on the Cre8asite Forums:

function writeMenus(container) {
    .... some code here ....
    menu.menuItemHeight = menu.menuItemHeight || defaultHeight;
    var itemProps = ''; <= CHANGE THIS LINE TO => var itemProps = 'white-space:nowrap;';
    if( menu.fontFamily != '' ) itemProps += 'font-family:' + menu.fontFmaily+';';
     .... some code here ....
}

You should find this spot around line 163 of mm_menu.js. The change worked a charm. Thanks Hiroto!

Keyword Placement

Mon, 06 Nov 2006 10:00:00 GMT

David Dougherty has a great post at One Degree on developing your keyword strategy, (part two). David provides an extensive process for choosing your keywords, phrases and deciding how to structure your pages most effectively.

It's not only important what you say on your web page but it's also very important where you place content within the page. Specifically, where you place it within the HTML code. Search engines such as Google place value on content within a web page based on whether it occurs at the top of a page or farther down. Additionally, the HTML tag that the keyword is within may influence the way in which it ranks the words contained within it.

For instance, placing content within the "title" tag gives it the highest ranking of all-content within your page from the search engine's perspective. Following that, placing content in an "h1" tag will garner a much higher value than if it were placed within a styled "p" tag or "div" tag. Google naturally assumes that content marked as a header is more important than content marked as a paragraph and subsequently content within a title tag is more important than anything within a header tag. Beyond important tags such as titles and headers Google basically ranks content at the top of the page source higher than content that is lower within the page. It has been suggested anecdotally that Google places further emphasis "strong" tags.

It's also worth noting that search engines can change the way in which they analyse pages at any time. At one time it was quite useful to make use of the "meta" tags to provide hidden keywords that would help search engines optimize for page content. Unfortunately the spam community abused the feature by aggressively populating meta tags with misleading information to generate traffic. The merit of that approach is best left for another discussion but the result is that few search engines utilize the meta tag making is effectively useless.

Strong keyword strategies combined with a program to generate inbound links are your first lines of attack. But implementing these simple placement guidelines will help you get the most mileage out of your keywords.

Having High Standards

Thu, 27 Jul 2006 10:00:00 GMT

Here at Radiant Core we take our W3C standards seriously. Our projects are delivered to clients with clean, validated markup that we consider the mark of a properly done website. Sometimes that means a little extra work, and often an equal amount of frustration dealing with rendering issues across various web browsers.

The guys over at Icon Factory have recently undertaken the the job of cleaning up the markup on their own site and have documented the adventure in true Icon Factory style.

5 Tips for protecting your site against XSS

Tue, 18 Jul 2006 11:00:00 GMT

While some still debate the risks associated with cross-site scripting (XSS) attacks, after the high exposure attacks against MySpace and Hotmail the pendulum has definitly swung in the direction of treating XSS as seriously as other more common injection type attacks. Either way, as with most things involving security on the web, it never hurts to err on the side of caution. The trick with XSS is that since the problem isn't specific to a particular technology, it can be tricky to know if you are vulnerable. Here are five common XSS injection techniques to check for any time you accept user input on your site.

Your forms accept unnecessary HTML tags: This one should be obvious, but if a form on your site lets a user insert a tag in a comments form, you've got a potential problem. Unless there is a very good reason for it, it's usually not advisable to let users send HTML entities through a form.
Failing to validate properties in anchor tags: It's often convenient or necessary to allow users to insert HTML in their input. If your site allows this, it is highly advisable to validate the properties passed along with the HTML. A common exploit is to hide script source inside of URLs. Depending on the user's browser, Community Creators, Secure Your Code!", in-line CSS styling provides another opportunity. Niklas spends far more time on the subject than I can here including suggestions for cleaning input.
Ignoring and tags: While Javascript is the most common tool for implementing an XSS attack, you should also be careful that users can't link to external objects that have their own scripting languages. For example, Flash could be used to display an element on a page, or even open new browser windows. Since ad tags are not directly dangerous, many developers overlook them when filtering user input.

For more information on XSS vulnerabilities, I highly recommend reading HTML Code Injection and Cross-site scripting which provides detailed information on detecting and filtering user input to protect your site from attack.