Thanks to Duncan Stephen’s blog post about dummy images, I was inspired to add a new feature.All of the customisation options have got us excited, but I can think of a few more features that would improve it even further.The ability to set a width and an aspect ratio, for those times when you know you need a 16:9 image but just can’t be bothered to get the calculator out.What a great idea! It took me an hour or two to thoroughly test the new feature to my satisfaction and push it live. I’ve also updated the documentation and source code for anyone who wants to take a look to see how it’s done.You can use aspect ratios with the width like so:http://dummyimage.com/640×4:3or with the heighthttp://dummyimage.com/16:9×1080I enjoy adding new features that make a designer/developers life a bit easier. If you have something that you would like to see dummyimage.com do, let me know!Dummyimage.com Can Calculate Ratios Now by Russell Heimlich

As 2010 is wrapping up, I decided to take some time to chronicle the history of one of my biggest web development milestones of the year.In December of 2006, I started my first real job out of college as a frontend developer at USNews.com. My first big project was to turn a new site design from a collection of Photoshop documents into functioning HTML and CSS code. I had to slice up dummy images to put into the layouts. As the redesign process wore on, sizes of elements changed ever so slightly meaning I needed to make new images with each iteration. I had wished there was a way to conjure up these placeholder images on the fly. I ended up tucking that idea away in the back of mind.For whatever reason I decided to purchase the domain dummyimage.com on the 20th of July, 2007. I can’t remember if I had some early prototype version working by then but I had made up my mind that I was going to do something with this idea. Like most tinkering web devs, I have a stable of domains for other ideas sitting around until one day when I can get around to them. Dummyimage.com was not like those other ideas.Fast forward to August 11th, 2007, when I attended my first Bar Camp in Washington DC. I had mentioned my dummy image idea to Jason Garber and Jeremy Carbaugh in passing. They said it was a cool idea and should be pretty easy to do.From then on, I was determined to figure out how to make my idea work. Aside from toying around in WordPress (which resulted in this blog you’re reading now) I had zero experience with PHP. I was quite comfortable with JavaScript however and found PHP easy to pickup. On August 26th, 2007, I had launched my first version of dummyimage.com.The first release was as simple as could be. The only thing you could change were the dimensions of the images. Everything was a gray background with the size of the image in centered black Arial text. I released the source code via a no-frills zip archive for anyone to take it and do what they wanted. I didn’t even bother with a design for the site itself thinking only a handful of people would even see it.Around December of 2009 I began toying with some new capabilities for dummyimage.com. The biggest request I got was for the ability to change the colors of the background and text. I didn’t really see the point so I sat around on the new changes. Then on January 25th, 2010. My friend Charlie Park (whom I met at the first DC Bar Camp in 2007) tweeted out a link mentioning dummyimage.com My site made its way through the developer community like wildfire thanks to HackerNews, and Twitter. Suddenly I felt the need to get working on new features and a redesign for dummyimage.com based on the feedback that was pouring in.On March 10th, 2010, (Chuck Norris’ Birthday & International Day of Awesomeness) I launched version 2 of dummyimage.com.This added color options, the ability to customize the text displayed on the image, and a simple form on the homepage to make generating custom dummy images easier. I switched the typeface from Arial to a completely free and open font called M+. I also released the source code under the liberal MIT license based on feedback I had gotten.I wanted the new dummyimage.com look to be a little rebellious. Most sites are centered align in relation to the browser. I deliberately made the dummyimage.com homepage align to the right. You can really notice this the larger your monitor’s resolution is. One person even sent me an e-mail providing a CSS tweak to make it center align. He thought I had made a mistake.Since other people were doing other things with the dummyimage idea like making plugins for text editors and different platforms, I decided to curate those and link to them from dummyimage.com I was happy to see my idea taking hold with the community, even spreading to non-english areas of the web. I guess the simplicity of my little project transcends language barriers.Dummyimage.com gets about 10,000 unique visits to it’s one and only page. It’s single largest day of traffic was January 26th, 2010, with 15,766 unique visits. Of course most of the traffic comes from people embedding images into their pages. I get about 5.8 million requests (pageviews essentially) for a total of 11.4 gigabytes of bandwidth in a typical month. I have gigs and gigs of server logs to analyze if I really wanted specifics but I leave dummyimage.com’s server stats open for anyone to take a look at.With the redesign I aimed to make a little extra change by placing 3 ad units to the left. They probably bring in a couple dollars a month via Amazon.com referrals. I don’t really pay attention to that stuff.So all in all I’m happy with where dummyimage.com has come and it makes for a great milestone in 2010. Hopefully in 2011 I can manage to launch even bigger projects I have in mind.The History Of Dummyimage.com by Russell Heimlich

JavaScript is a fun language. It lets you build almost anything you can imagine. For some reason, I thought it would be fun to build a simulator for the card game War. I started hacking away on the idea in my spare time. It was also a good excuse to learn object-oriented JavaScript to make my card game simulator flexible and modular. After a few weekends I had something that worked (screenshot below). Unfortunately after that life got busy and my war simulator just sat there collecting virtual dust for more than a year.

Fast forward to July 29th when the 10K Apart contest is launched challenging developers to build compelling apps that are 10 kilobytes or less. This would be a fun way to refine my stale war game simulator as well as test my JavaScript coding-foo to squeeze it all in to 10 kilobytes. Pure HTML Cards One of my first challenges was re-doing the cards. Initially I constructed a single-image sprite containing all of the cards. JavaScript would manipulate the class of a div which would determine how to position the image for the proper card to be displayed. This method led me to discover something Internet Explorer actually gets right with CSS and the other browsers fall short. This image of all of the cards weighed in at 36KB alone. Ouch! My solution was to use unicode characters for the different suites and letters and numbers for the card values. Child elements of the card held the symbols and I positioned them absolutely within the card element. The final touch was to rotate one of the child elements 180 degrees using the transform CSS property so it would display upside down just like a real card. My image-less approach was just a fraction of the size of using images for cards. But something was still missing.

Playing cards have decorative designs in the middle. It would be too complicated to completely replicate these designs so I came up with the idea to use a Twitter avatar as a background. Thanks to the awesome service provided by http://tweetimag.es/ their RESTful api let me grab any public Twitter users avatar by constructing a simple URL. Browsers provide an easy way to  add new CSS rules to a stylesheet via JavaScript so I could dynamically change the background image of a card based on which Twitter names the user provided. This is where the idea for making my War game simulator revolve around Twitter users was born. Viral Sharing A bigger advantage to hooking into Twitter is it makes each game more personal for the player. Pitting two people in a card game battle makes the experience more meaningful then a bunch of plain, virtual playing cards flipping back and forth for a couple hundred of turns. This also has the potential for a viral aspect to my app since I already have atleast two Twitter names that would be interested in the results. In order to share a game I needed to create a way to read in the number of players, their twitter name, and their deck at the start of the game. Using a simple string of characters that represented this data attached to the end of the URL allowed me to do this. All of the values in the deck could be stored as a number or letter since I had unique first letters.

Card Encoded Equivalent

0, 1, 2 … 10 0, 1, 2 … 10

Jack j

Queen q

King k

Ace a

Hearts h

Diamonds d

Spades s

Clubs c

Therefore, the Ace of Spades could be represented as ‘as’, the 10 of Diamonds would be ’10d’ and so on. A full game looks like this: p1-kingkool68:adqhkc2d5d10s3h3d5hjs8dqc9c8h2s9d6c7c9skd10d8c7s7d2c4s|p2-naudebynature:jc6d10cjdkh5c4h6sqdks2has6h4d7h4cac10h9hah3s8s5s3cjhqs A Heap of Data

One of my favorite parts of developing this app was creating a way for keeping track of all the different data that results from a single game. For each war I store the turn it occurred on as well as keep track of which player won the war. After each turn I store a copy of the players deck for further analysis after the game concludes. I originally wanted to include a line graph showing the number of cards a player had in their deck as the game progressed. Building that feature was pretty simple thanks to the Google Charts API but in the end it had to be cut in order to get below the 10KB limit. Squeezing Down the Bits

I was a little ambitious with the functionality that when I was ready to start compressing my code down I was shocked to see my idea bloated to 33KB. That’s more than 3 times the maximum size. A serious slimming down was in order. Pre-populat lists of Twitter users that would make for interesting battles: cut. Charting capabilities mentioned earlier: gone. A brief blurb explaining the game and who I was: removed. Title tags: discarded. Every little bit I could trim down would help. After all this I was down to about 17KB and along way to go to get under 10KB. Dean Edwards took JavaScript compression to another level with his /packer/ tool. He came up with away to reduce the size of JavaScript by removing white space, stripping comments, and replacing variables with shorter, less-coherent replacements. CleanCSS.com does pretty much the same thing but for CSS. Such optimizations include replacing font-weight:bold; with font-weight:700; color:#ff0000; with color:red; and so forth. These packing tricks helped get me to 13KB but I was running out of ways to optimize further. My next plan was to modify my HTML. IDs like ‘prepare-for-war’ became a single letter, <strong> elements were replaced with deprecated <b> tags, and the closing </body> and </html> tags were axed since they had no affect on my page. Sidenote: Google chops off the closing </body> and </html> tags which for a site that serves up that volume of pages results in a savings of a couple million dollars in bandwidth bills every year.</end sidenote> At this point I was so close to coming under 10KB but yet so far. It was time for one more drastic technique. I noticed how well the JavaScript /packer/ tool worked so I decided to combine my HTML and CSS into a single line and use JavaScript to write it out to the page as it was loading. This way I could combine it with my main JavaScript code for the most efficient compression possible. After 3 hours of toiling in vain, I reached the point where my app was under the magic limit. Ten kilobytes is equal to 10,240 bytes. My code weighed in at 10,236 bytes; a mere 4 bytes to spare! Lessons Learned Even after spending hours tediously compressing and optimizing my code, I still had a lot of fun. My biggest challenge wasn’t squeezing everything down, or getting it all to work just right. Rather my biggest challenge was myself and when to determine it was finished. After each piece of functionality I coded I wound up thinking of two more things to make it even better. Once it was submitted to the contest gallery, my app got some luke-warm attention but I’m used to that now. Personal projects I toil over never get the amount of attention I always think they will. I’m anxious to see who wins the 10K Apart contest and whether my War app gets any mention at all from the judges. But in the end that doesn’t matter. What matters is I got my idea out of my head and into a working state where people could actually try it out, no matter how trivial of an idea it is. And that is what makes the web such a great platform for an individual like myself. The Trials And Tribulations Of 10KB by Russell Heimlich

It sure would be nice if the blip.tv player had an easy way to change which video is playing in a playlist using their JavaScript API. But they don’t, so I had to roll my own to make the two play together nicely. Here is the end result (Note there are some line breaks I put in here for visual formatting, it might not work): var player; var currentPlaylistItem; var currentState; function getUpdate(type, arg1, arg2) { switch(type) { case "state": currentState = arg1; break; case "item": currentPlaylistItem = arg1; var episode = player.getCurrentItem(); document.title = episode.title; break; } }

var flashvars = { 'file': 'http://blip.tv/play/ha0CjMVEh_8o', 'enablejs': 'true', 'javascriptid': 'blip_player', 'autostart': 'false' };

var params = { 'allowscriptaccess': 'always', 'allowfullscreen': 'true', 'expressinstall': '/millennials/flash/expressInstall.swf' };

var attributes = { 'id': 'blip_player', 'name': 'blip_player' }; swfobject.embedSWF('http://blip.tv/play/ha0CjMVEh_8o', 'blip_player', '770', '470', '8.0', false, flashvars, params, attributes, swfCallBack);

function swfCallBack() { player = document.getElementById('blip_player'); $('#agenda h3 a, #agenda a.blip_tv').click(function(){ var playlistItemNum = $(this).attr('href').split('#')[1]; changePlaylist(Number(playlistItemNum)); $.scrollTo('.video .player', 800); return false; }); }

function changePlaylist(num) { var direction = 'prev'; var diff = currentPlaylistItem - num; if (diff < 0) { direction = 'next'; diff = Math.abs(diff); } for(i=0; i < diff; i++) { player.sendEvent(direction); } if (currentState == 0) { player.sendEvent('play'); } }

There are three requirements to getting started as outlined in the blip.tv wiki:

The player must be embeded with the enablejs=true Flash variable set The player must be embeded with allowScriptAccess=always object/embed parameter set A JavaScript function must exist named getUpdate()

The first part of my script sets up three global variables that we’ll use.

player will reference the object/embed element by an ID. It is how we send commands to the show player. currentPlaylistItem is the number of the video selected (or position) in the playlist. currentState is either 2 (playing), 1 (loading), or 0 (stopped) depending on the current state of the player.

The getUpdate() function listens to the blip.tv player for changes like when the player is stopped or a video is changed in the playlist. The type argument is a string which we can send through a switch statement to determine what we need to do. If the state of player has changed then we update our currentState variable with the value of arg1 (which will be a number between 0 and 2). If the event is an item change, we will update the currentPlaylistItem variable to reflect that. As an added bonus we get the title of the current playing video and change the title of the webpage to reflect this. This has zero SEO value and is really only a convenience to our audience.  Now that we know what is going on, lets get to the fun stuff. Three variables (which are really Objects) are created for swfobject so we can easily embed the video player dynamically into the page. The ‘blip_player’ paramter is the ID of the player that we’ll be referencing shortly. The swfCallBack() function is called once the blip.tv player has loaded. There we set our player variable to reference the element of the blip.tv player. I used a line of jQuery to set the onClick() events of a group of links that will change the playlist when they are clicked. In the HTML the links contain direct links to each blip.tv video and an anchor with a number after it. This number is the playlist position of the specific video. jQuery makes it a snap to extract just that number from the URL which we store in the playlistItemNum variable. The playlistItemNum variable is passed along to a function called changePlaylist() which does all of the heavy lifting. Since the blip.tv show player doesn’t have a direct way of going to a specific video in a playlist, we have to hit the next or previous button on the player programmatically. The direction is set to ‘prev’ initially.  diff is calculated by subtracting the number passed to the function from the position of the currently playing video, currentPlaylistItem. If diff is a negative number than we need to switch the direction variable to ‘next’ and get rid of the negative number by calling the absolute value method ( Math.abs() ). Now we simply send the player a command to go to the next or previous video as many times as we need to get to the desired video via a loop. Finally, if the player is stopped, we send the video player a command to start playing the video. As an added nicety, we gently scroll the viewer up the page to the top of the video player so they’re not left wondering why nothing happened. The jQuery scrollTo plugin makes this a breeze to do. There is one caveat for the changePlaylist() function to work: the playlist needs to be visible on the blip.tv show player. This is simply an option you set on the player configuration screen on blip.tv. Without it showing, we can’t get which video is playing and the whole thing falls apart. That wraps up how to roll your own playlist changing function as well as shed some light on how you might control other things about the blip.tv show player using JavaScript. You can see this in action on the Pew Research Center Millennial Conference video page. If you have any questions leave them in the comments or get in contact. a

Ever since the surge of interest in my pet project dummyimage.com I’ve been meaning to add some new features. Today is the International Day of Awesomeness (which coincides with Chuck Norris’ birthday) and I couldn’t think of a better time to unveil DummyImage.com’s new functionality to the public.

Here is a run down of the changes: Specify Custom Colors You can choose the background and foreground colors of the dummy image right in the url using a 6,3,2, or even 1 character hexcode. Don’t worry if you forget to do this as dummy image will default to gray and black. Add Your Own Text A lot of people wanted to be able to add their own text to a dummy image to better communicate what it is representing. Now using the &text= parameter you can. A Better Typeface Arial be damned! Font geeks cringed at my basic choice of a font. Some seemed worried about my distribution of the most popular font on Earth. Now both camps can be happy as I’m now using the completely free and open M+ Font. I also changed the X in the middle of the images to a multiplication sign × as pointed out by Erinah and Dave Cortright. Standard Image Sizes Dummyimage.com is a useful prototyping tool and a lot of prototypes and wireframes have ad positions. Instead of memorizing dimensions you can now bring up ad sizes by their industry-standard name like largerectangle, skyscraper, and fullbanner. You can even customize the colors, text, and formats of theses sizes as well. Pick Your Format Before you could add any image format extension to the url but my script would still generate a GIF image everytime. Now you can generate proper PNG, JPG, and GIF images and drag them into another app trouble free.

And with these new features I figured it was time to give the site a proper, though still simple, design. Rather than bury how these features work in long, boring text I made a little tool that shows you everything you need to know with minimal fuss. Not a fan of change? Don’t worry, you can still use Dummyimage.com to generate place holder images exactly the same way you have always been doing it. So thank you to everyone who has e-mailed me, tweeted me, left a comment on a post somewhere or otherwise provided feedback on dummyimage.com. I’m glad so many people found it as useful as I think it is. Keep the ideas and dummyimage variations coming. I’m sure this thing could be better. a

Way back in August of 2007 I built a simple PHP tool that generates place-holder images at different size by simply changing the URL. The idea came to me when I was working on a redesign for USNews.com. I hated opening up Photoshop, creating a new document,  filling the background layer, and exporting for web just to make a simple placeholder image. That is why I made dummyimage.com. I figured it would be useful to other people which is why I also released the complete source code, documented and including instructions for setting it up on your own server. But like most new things, few gave it any notice.

The other day my friend Charlie Park (founder of Pear Budget) found it when doing some in-browser wire-framing and sent out a tweet to all of his followers. But he didn’t stop there. Charlie also posted it to Hacker News, a simple news aggregator aimed at geeks. It was obvious that my little tool was resonating with other developers with the tagline “Lorem ipsom for images.” In 24 hours, the Hacker News story got 161 votes with 77 comments, 513 people bookmarked it on del.icio.us, and 337 tweets. What really struck me was how dummyimage.com was crossing the language barrier. I saw tweets mentioning in Spanish, Japanese, Russian, German, Dutch, even Latvian. I’m glad my idea was simple enough that foreign speakers could easily pick it up without any translation help.

All of this sudden attention also produced helpful feedback and new feature ideas. I started working on an update this past December for a few additions I wanted to see but this recent surge of interest has lit a fire under my butt to continue developing. As is the nature of opensource software, people don’t have to wait for me; they can adapt the code to their own needs. Here are some iterations that have already been made:

Fakeimage (Ruby) Placeholder_image (Ruby) Lorem ipsom for Images (JavaScript/jQuery)

And somewhere down the line I would like to give it an attractive homepage. Hooray for side projects! a

ThemeForest.net is an online marketplace for developers to sell themes, templates, and other web development related goodies. A lot of the files are for the backend making it next to impossible for someone to copy them without breaking into your server. But ThemeForest offers JavaScripts for sale and even offers a live preview. By the very nature of the web, a front end technology like JavaScript requires the source code to be downloaded to your computer before it can run. This means anyone with a little know-how can easily bypass the need to buy the script and piece it together themselves. For example, take this JavaScript calendar widget which has 0 sales as of this writing. All you have to do is go to the live preview and remove the frame by clicking the link in the top left corner. From there it’s just a matter of viewing the source (Choose View->Source in Internet Explorer, View->Page Source in Firefox) and copying the necessary JavaScript and CSS files. Here’s everything you need for this calendar widget:

http://s3.envato.com/files/199652/css/calendar.css http://s3.envato.com/files/199652/css/setup.css http://s3.envato.com/files/199652/css/text.css http://s3.envato.com/files/199652/js/resources.js http://s3.envato.com/files/199652/js/config.js http://s3.envato.com/files/199652/js/calendar.js

Now before you get all upitty about the ethics behind this, you should know that this script is freely available from the author’s own site, which was based on an open source project from around 2006 according to comments in the CSS files. Granted ThemeForest isn’t targeted at professional developers like me so someone might be more than happy to plunk down $8 to download everything in one nice, neat package. But if I were selling scripts on ThemeForest, with the expectation of a profit, I would be pissed that ThemeForest didn’t take more precaution to protect my source code. At the least they could obfuscate the live preview code using a tool like /packer/. At any rate this demonstrates why it’s so hard to sell JavaScripts by themselves due to the very nature of how they work in an open web. a

I picked up JavaScript by accident before jQuery, Prototype or any of the other smitten tools that make web developers lives easier. The web was just coming back to life in early 2005 from the dot-com bomb. I was enrolled in the Digital Media Production program at the Art Institute of Philadelphia; a degree encompassing video, web, and multimedia all rolled up into one. Back then almost everything about building websites fell under the term ’scripting.’ ‘Scripting 1′ was really an introduction to HTML with a little bit of CSS thrown in. I managed to test out of this class with an example site I put together for a friend a week earlier. Logically, Scripting 2 would seem to be more advanced HTML and CSS techniques, but my thinking was wrong. My school deemed ‘Scripting 2′ as a JavaScript class.

My only experience with JavaScript before ‘Scripting 2′ was the auto-generated cruft from Dreamweaver MX used in rollovers and jumpmenus. I had no idea what it did or how it worked; I only knew not to muck with it or things would break. I also spent most of my Dreamweaver time in design view, not code view. The required reading for the class was Beginning JavaScript by Paul Wilton. It was still a leading book at the time even though it was 5 years old. That’s how stagnant web development was compared to the blistering pace of progress made today. Some of the more advanced topics included dynamic HTML (DHTML) on Internet Explorer 4.0 and Netscape Navigator 4.x. Yea it was that old, but a lot of the basics still hold true even today.

I read that book cover to cover to get a handle of JavaScript and help me complete my projects consisting of things like temperature converters and form validation. After 11 weeks it finally began to make sense. I began thinking about solving problems with it which led me to my personal project Deviant Bordermaker. The simple tool calculated image sizes for specific ratios given an image. It was developed long before Adobe Air as an offline app that people would download and run locally. Ecstatic couldn’t even begin to describe the feeling of bringing an idea to life and overcoming the barriers of learning a new technology. I knew from that day on that JavaScript would be a part of my career. Fast forward nearly 2 years later when I land my first job at USNews & World Report. My very first task was to develop a quiz-building tool. Since I knew zilch about server-side programming languages, like PHP, I built the app using JavaScript. The final output was the HTML necessary for the quiz to run that a producer could simply copy and paste into the right place. Thinking back on it, the JavaScript was probably overly complex but I certainly learned a lot and continued to push the boundaries of my JavaScript chops. From there I slowly learned the Prototype JavaScript framework, which was the defacto library at the time. At first I didn’t feel like it was making anything easier as I was struggling to grasp the object oriented model of doing things in Prototype. This hard work paid off as learning jQuery was a breeze; it’s pretty much the same thing but with different names for things. JavaScript has come a long way since 2005. The language continues to be pushed into new areas thanks to AJAX, web applications, and a rekindled browser war. Learning JavaScript will go a long way in learning other things like PHP and should definitely be a foundation skill for most any frontend developer. How did you come across JavaScript? a

Every web developer is looking forward to the new HTML spec, HTML 5. The new spec will birth 20 new elements to add more underlying semantic meaning to content. The new elements came out of popular IDs and Class attributes for common situations in web design: <nav> is just like <div id=”nav”>. But these new elements are just a stop gap.

I wish the web community could move beyond pigeon-holing ourselves with specific elements. Why can’t we make our own elements to better describe our content? If I had my way <div>s would be ancient history and any element not already defined in the HTML spec would be treated by browsers like a <div>. There are many benefits to opening up the element nomenclature like this. 1) It will be much easier to describe content. No longer will we need to shoehorn our content into quasi-relevant elements. Did you know the <address> tag is to define the contact information for the author or owner of a document and not to hold a plain street address? 2) No more div-itis. Web developers will no longer have to wade through a dozen </div> tags. <div> tags are the least-semantic structural elements in a web designers toolbox; it literally means ‘division’ of a page and is used to mark off different sections within a document. Things can get pretty messy when using too many <div>s however as it is hard to tell where they end. Take a look at this code example:

<div id="container"> <div id="article"> ... <div id="chart"> ... </div> </div> </div>

Look how much better this markup looks from both a readability and maintainability perspective:

<container> <article> ... <chart> ... </chart> </article> </container>

A benefit to free-form elements is the semantic closing tags making it clear where each element begins and ends. 3) Microformats might actually work. The movement to create semantic markup using loosely agreed upon Classes slowly died off due to the extra bloat it introduced to the underlying code. With the ability to create your own tags, Microformats could flourish and we can begin to set-up our own best practices for describing content. 4) Faster JavaScript. Not many browsers support the JavaScript method getElementsByClassName but every browser supports getElementsByTagName. Because of this many libraries have had to write their own implementations which are many times slower than native methods. Faster DOM traversal = faster JavaScript! What will it take to make this a reality? Boogers We’re already going to have issues with older browsers supporting brand new elements with HTML 5. We might as well go all the way and make sure every browser can support whatever element we can come up with. After all we only have one shot to get HTML right for this generation according to John Allsopp. Many browsers already support free-form elements both with CSS and JavaScript. To really flesh this out I created the Booger Test and below are my findings.

Firefox 3+ supports the <booger> tag as if it were a native element but has to be explicitly set to display:block. Firefox 2 has no problem with CSS unless there children elements in which case the <booger> tag collapses. Weird! All versions of Internet Explorer don’t know what to do with the <booger> tag but they do function normally when using a JavaScript shiv Safari and Chrome have no problems. Every browser I tested passed the JavaScript portions (getElementsByTagName(”booger”)) of the booger test with flying colors!

So as you can see, we are really close to being able to use our own elements. HTML 5 is already going in this direction but it would be a real shame if everyone got hung up on what frivolous new element names we should all agree to use instead of coming up with new functionality to move the capabilities of the web forward. a

Firebug is the web developer equivalent of a hammer to a carpenter. In other words without this valuable tool hundreds of thousands would not be able to do their job and make the web what it is today. So even small changes to the interface are going to ruffle some feathers. I spent a good half day trying to figure out why my precious Firebug wasn’t behaving like its usual self. For one thing, it wasn’t showing JavaScript errors in the status bar icon like it usually does. It also displayed a message saying “Reload to activate window console” whenever I would bring it up. This makes debugging impossible if I have to keep refreshing the page everytime. It turns out the Firebug developers made a teeny, tiny tweak to the interface. The screenshot on top is the newer Firebug, version 1.4. The bottom half of the screenshot is from an earlier version. See the difference?

The ‘X’ used to hide the Firebug window in older versions has been replaced with an Off button. Unfortunately the Firebug developers changed the behavior as well. The Off button deactivates Firebug for that website which explains why JavaScript errors disabled in the status icon. The button that I have come to accustomed to for minimizing the Firebug panel is that circular down-ward arrow about 50 pixels away. This is a usability nightmare!

The hide Firebug functionality isn’t where the user expects it, especially for long-time users who have developed a muscle memory The Off button is ambiguous to what the action does (a better word would be deactivate, though that doesn’t quite fit) The Off buttons breaks away from the rest of the paradigm of the interface (icons are for actions like inspect, and pause while words are for different tabs) and the Off button is a much larger than the minimize button even though the minimize button is used far more frequently than the off button

I now have to focus in order to minimize Firebug taking mental energy away from my task. If I’m not paying attention I can turn-off Firebug for the site I’m working on and then I would have to reload the page to get it working again. These sound like little things but compounded one hundred times and it can drive you batty. So while the latest Firebug update is not technically broken, a poor interface decision sure makes it feel like a buggy mess. a

After reading through Smashing Magazine’s latest article, 50 New CSS Techniques For Your Next Web Design, I came across an article glossing over a technique for creating a triangle using pure CSS. A triangle using just CSS? That blew my mind! How is that even possible? After playing around with the sample CSS I started to get it. Using an empty HTML element and the border properties, you can make all kinds of shapes. Here is how it works. Note: As expected, Internet Explorer acts a bit wonky especially IE6. These experiments were done in Firefox 3.5 but you can see what they should look like in a screenshot I took. Per the box model, the border outlines the perimeter of an element. When an element has a width and height of 0px the border-width’s make up the dimensions of the element.The corners of borders meet at a 45° angle which is apparent with larger border widths and what makes pure CSS shapes possible. The final CSS to make a 200 pixel tall red triangle pointing up looks like this:

But let’s see how we got to this conclusion step by step starting with a basic square and borders. Each border will be given a different color so we can tell them apart.

.triangle { border-color: yellow blue red green; border-style: solid; border-width: 200px 200px 200px 200px; height: 0px; width: 0px; }

We won’t need the top border so we can set its width to 0px. This makes our triangle easy to measure without any extra space on top; a border-bottom value of 200px will result in a triangle that is 200px tall.

.triangle { border-color: yellow blue red green; border-style: solid; border-width: 0px 200px 200px 200px; height: 0px; width: 0px; }

To hide the two side triangles we set the border-color to transparent. If we set the border-left and border-right widths to 0px then the whole shape would collapse, leaving us with nothing. Since the top-border has been effectively deleted, we can set the border-top-color to transparent as well.

.triangle { border-color: transparent transparent red transparent; border-style: solid; border-width: 0px 200px 200px 200px; height: 0px; width: 0px; }

There you have it; a triangle using only a single, empty HTML element and some CSS. The same technique can be applied to the other three sides for different orientations. Where might this come in handy? A JavaScript toggle to indicate a container is visible comes to mind. And using a pure CSS triangle is a lot more convenient than coming up with new images for each variation. Try playing around with different widths to create different kinds of triangles. You can also get some funky effects by changing the border-style; dotted produces a neat effect on our regular bordered square.

.funkyShape { border-color: yellow blue red green; border-style: dotted; border-width: 200px 200px 200px 200px; height: 0px; width: 0px; }

I even managed to come up with the del.icio.us logo.

.delicious { border-color:#FFFFFF #3274D0 #D3D2D2 #000000; border-style:dashed; border-width:150px; height:0; width:0; }

And a heart shape.

.heart { border-color:red; border-style:dotted; border-width:0 150px 150px 0; height:0; margin-left:90px; margin-top:90px; width:0; }

I wasn’t the first one to explore CSS shapes, it turns out Tantek Çelik was playing around with these ideas way back in 2001. a Pure CSS Shapes: Triangles, Delicious Logo, and Hearts

Example of a CSS style guide. Great reference for when you write your own.