TextAreaExpander Class for MooTools

I’ve had to create a slew of forms over the last few months, and have become fond of textareas that auto-expand when they become filled. There are a number of MooTools scripts on the interwebs that can handle this task, but none of them suited me, and I generally like to roll my own code as a learning experience.

So, without further ado, I present a very simple MooTools Class: TextAreaExpander. It does exactly what is says: expand textareas. No more, no less.

Details

Options

Defaults are shown.

  • textarea_selector: none
    • Uses CSS selector syntax, such as “#myId” or “textarea.expand-o-rama”
  • padding_bottom: 0
    • Only accepts pixels, no percentages or ems
  • fx_transition: Fx.Transitions.Expo.easeOut
  • fx_duration: 350

Returns

Array of textarea elements

Requires

MooTools 1.2.4 core

Demos

Sample implementation using defaults (grabs ALL textareas on the page):


window.addEvent("domready", function (){
    new TextAreaExpander();								  
});

View ‘simple’ demo

 

Sample implementation specifying all available parameters:


window.addEvent("domready", function (){
    new TextAreaExpander({
        textarea_selector: "#demo",
        padding_bottom: 12,
        fx_transition: Fx.Transitions.Quad.easeInOut,
        fx_duration: 500
    });
});

View ‘options’ demo

Download

License

MIT-style license. Completely free. Enjoy.

Providing the same UI across browsers

As a web designer and e-learning course developer, I often grapple with the notion of making my products appear the same in every browser. I’m not opposed to the idea that you should make your work look (almost) identical in every browser. After all, you’re promoting a specific design aesthetic and the last thing you want is for a browser to dictate what you can and can’t do, especially browsers you don’t even like. (I’m looking at you, IE6.)

But it’s never as simple as we’d like. Internet Explorer has that crazy CSS box model. Older versions of Firefox and Safari don’t support border-radius or RGBa.  Mac browsers use completely different scrollbars and form elements than Windows and Linux browsers. For that matter, scrollbars and form elements in Windows 2000 look completely different than XP, Vista, and Windows 7.

This is one of the reasons Flash has become so popular — it allows designers to standardize their RIA‘s UI elements across browsers.

The latest salvo in the war for controlling your browser’s look and feel is Jilion’s SublimeVideo, an HTML5 video playback system that ensures your video has the same controller across browsers. It bypasses the browser’s built-in controller in favor of Jilion’s (very slick) custom controller. Jilion’s blog states (emphasis mine):

We aim at delivering a modern and simple video-embedding solution for web developers that provides the same user experience and uniform UI across browsers.

Jilion’s work comes from the same school of thought that led designers/developers to change the look and feel of other built-in browser components such as radio buttons and checkboxes. (Guilty!)

While looking at Jilion’s fine handiwork, I was struck by a thought: If a person uses a particular browser regularly, they will be accustomed to that browser’s native controls — whether it’s for video or drop-down menus in forms — and might be thrown off by the custom controls. Maybe it isn’t such a good idea to create a homogeneous video controller for all browsers.

After all, why does a Firefox user need to have the same experience as a Chrome user? Why does an Opera user need to have the same experience as an Internet Explorer or Safari user? These people have probably never seen what a webpage looks like in a different browser, anyway. What benefit do site visitors really receive from “a uniform UI across browsers”?

If you change the default controls to match the look and feel of something your visitor has never seen before, you run the risk of creating confusion, distrust, or alienation. Even worse, if the controls are poorly made or conceived — and many are — you might make your site less usable. A cardinal sin.

The more I think about it, the real beneficiaries of a uniform UI across browsers aren’t the site visitors, but rather the designers who demand artistic control and the clients who insist the product looks the same everywhere, without understanding that it’s okay (even expected) to have some differences.

Personally, I realized 100% uniformity is an unnecessary hardship when I began adopting HTML5 and CSS3 features into pipwerks.com last year. These new features are still not supported in all browsers, and essentially forced me to give up IE6 support. (pipwerks.com uses Andy Clarke’s handy Universal IE6 stylesheet for IE6.)

I’ve come to grips with the notion that my site’s design won’t look the same in Opera 9 or IE7/8 because those browsers don’t support border-radius. My design is simple enough that the general impression is preserved across browsers, but people who use certain browsers will see a slightly less refined product. This is a-ok with me.

It should also be noted that growth in the mobile market appears to be shifting perceptions about consistency between browsers, too. Most major sites have a “mobile edition” which will look quite different than the standard website, and is most likely geared to look great on an iPhone and so-so in all other mobile devices.

Changes to pipwerks.com, part 2

In case you hadn’t heard, pipwerks.com was hacked last week. The entire database was erased. Bastages. Luckily, I had a recent backup.

While going through the pains of a new WordPress install (with new plugins, extra security, and imported posts/comments), I decided “why not throw a new layout in the mix, too?” I mean, if I’m going to make changes, I may as well do them all in one shot, eh?

I had been working on an HTML 5-based layout for some time, but had been reluctant to publish it because of HTML 5’s newness and uncertainty; where do I use ‘section’ versus ‘article’, etc.? Do I really want to let WordPress continue to abuse <ol> and <ul>, or does it make more sense to use <dl> in some cases?

The outcome of the argument is what you see today. I didn’t want to fight WordPress too much (esp. the plugins), so there are still a bunch of legacy <div>, <ul> and <ol> elements hanging around. I’m sure I’ve neglected a number of things, but for the most part I’m satisfied.

Here is a short list of fun stuff i implemented in this theme:

  • <dl> for comments (<dt> for author, <dd> for comment body). I feel this is more appropriate as it maintains a relationship between the comment author and the comment body. It also allows for interesting styling (though it makes threaded comments more difficult).
  • <nav> for page header
  • <section> to demarcate where the sidebars go, “related posts” lists, etc.
  • <article> to contain the post itself
  • <footer> to hold footer-ish stuff (though the definition of footer in HTML 5 is still a work in progress)
  • Widgets for sidebars and the footer, which make editing the template SO much easier!
  • Myriad Pro as the body font. Yes, many people won’t have it, and they’ll see Arial instead. But many of my readers probably have Adobe products, which include Myriad. So there you go. No @font-face required! 😛
  • Malarkey‘s Universal IE 6 CSS for the laggards who still use IE 6. No offense — we still have IE 6 at the office, too — but I simply am not interested in bending over backwards to support IE 6 anymore. Kthxbai, IE 6!
  • Alpha transparency in images to allow overlays (such as the cartoon head). Easy in every browser except IE 6 (see above)
  • CSS-based rounded corners in browsers that support them (Safari and Firefox at the moment)
  • The comments styling uses a CSS trick to create the triangle that gives the impression of a cartoon ‘talk’ bubble
  • Icons for external links via CSS3
  • Meyer’s CSS Reset
  • Gravatars
  • Sociable links
  • Related Posts displayed for each post
  • …and more!

I must say I really enjoyed working on this theme, though it took me way too long to get to this point. Please have a look around and let me know how you like the site (or, heaven forbid, you find any problems/errors). And of course, a big thank you to everyone who contributed to the CSS and plugins that I’m using! Your hard work makes my life easier and I appreciate it.

Fixed-width layouts

While working on a recent web project at work, I wondered if I should go for a fixed-width layout or stick with my preference for fluid layouts. Fixed-width layouts are certainly easier to manage, but they just feel so… rigid. With the boom in larger monitors, I also wondered if fluid sites start presenting a problem due to being too wide. I decided to check around the web to see what others are doing.

The search

In my (very quick and unscientific) research, I visited 150 popular sites, including news sites, shopping sites, software company sites, and the personal sites of well-regarded web designers and developers. I purposely avoided blogs that use canned themes.

When visiting the site, I determined the page’s width by reducing the browser window’s width until the horizontal scrollbar appeared. In some cases, I didn’t use the front page of the site, as these are sometimes standalone pages that use a completely different layout than the site’s actual content.

The results

Of the 150 sites I visited, only thirteen used fluid layouts — a whopping 8.6%.

A number of those thirteen sites weren’t completely fluid, as they either break at smaller sizes or have fixed-width sidebars, but I included them in the list since they aren’t using a fixed-width wrapper.

I was genuinely surprised about the number of fixed-width sites; a sizable chunk of these sites belong to (or were designed by) well-known web design gurus. I had assumed a number of them would use some sort of min-width/max-width CSS trickery, but I was wrong — only a very few sites (less than 3.5%) used this approach.

I was also surprised to see that the vast majority of the fixed-width sites were between 900 and 1000 pixels wide, a size that was unthinkable a mere 5 years ago.

Observations

  • Most of the fixed-width sites fell between 900 and 1000 pixels wide, and were usually centered in the browser
  • 20 sites were 800 pixels wide or less
  • 14 sites were between 800 and 900 pixels wide
  • 100 sites were between 900 and 1050 pixels wide
  • 3 sites were over 1050 pixels wide
  • the widest site was time.com at over 1100 pixels, although the layout uses a fixed-width wrapper wider than the content itself (the content was closer to 1000 pixels).

Sites visited

I picked sites somewhat randomly, using a combination of Alexa.com rankings, sites I frequent, sites my co-workers like to visit (hello, www.bebe.com), sites belonging to famous companies (McDonalds, Target, etc.) and sites belonging to well-known web designers and developers. I know I left out a number of good sites, but this was a very quick-and-dirty project.

Fluid layouts

  1. allinthehead.com (Drew McClellan)
  2. clearleft.com
  3. craigslist.org
  4. danwebb.net
  5. dean.edwards.name
  6. drupal.org (partially broken due to floating elements overlaying other elements)
  7. gmail.com
  8. htmldog.com (Patrick Griffiths)
  9. joeclark.org
  10. meyerweb.com (Eric Meyer)
  11. molly.com (Molly Holzschlag)
  12. people.opera.com/howcome (HÃ¥kon Wium Lie)
  13. wikipedia.org

Fixed-width layouts

  1. 24ways.org
  2. 37signals.com
  3. 456bereastreet.com (Roger Johansson)
  4. about.com
  5. adactio.com (Jeremy Keith)
  6. adobe.com
  7. alexa.com
  8. alistapart.com
  9. amazon.com
  10. americanexpress.com
  11. andybudd.com
  12. anthropologie.com
  13. aol.com
  14. apartmenttherapy.com
  15. apple.com
  16. authenticjobs.com
  17. bankofamerica.com
  18. barackobama.com
  19. barnesandnoble.com
  20. bbc.co.uk
  21. bebe.com
  22. bestbuy.com
  23. blogger.com
  24. borders.com
  25. boxofchocolates.ca (Derek Featherstone)
  26. burgerking.com
  27. cameronmoll.com
  28. cartoonnetwork.com
  29. cbs.com
  30. chase.com
  31. clagnut.com (Richard Rutter)
  32. cnet.com
  33. cnn.com
  34. comcast.com
  35. comcast.net
  36. crateandbarrel.com
  37. danbenjamin.com
  38. dean.edwards.name
  39. dell.com
  40. deviantart.com
  41. dictionary.com
  42. digg.com
  43. directv.com
  44. dojotoolkit.com
  45. dustindiaz.com
  46. ebay.com
  47. espn.com (MLB page)
  48. facebook.com
  49. fastcompany.com
  50. fedex.com
  51. flickr.com
  52. fox.com
  53. friendster.com
  54. gamespot.com
  55. go.com
  56. guardian.co.uk
  57. guitarhero.com
  58. happycog.com
  59. haveamint.com
  60. hicksdesign.co.uk
  61. home.live.com
  62. hulu.com
  63. iht.com
  64. ikea.com
  65. imdb.org
  66. jasonsantamaria.com
  67. jeffcroft.com
  68. jetblue.com
  69. jquery.com
  70. kaiserpermanente.com
  71. latimes.com
  72. linkedin.com
  73. livejournal.com
  74. m-w.com
  75. macys.com
  76. markboulton.com
  77. mcdonalds.com
  78. mediatemple.net
  79. mezzoblue.com (Dave Shea)
  80. microsoft.com
  81. mootools.net
  82. mozilla.com
  83. msn.com
  84. myspace.com
  85. nbc.com
  86. neopets.com
  87. netflix.com
  88. newegg.com
  89. nfl.com
  90. ning.com
  91. nintendo.com
  92. npr.org
  93. nytimes.com
  94. opera.com
  95. oreilly.com
  96. paypal.com
  97. pbs.org
  98. quirksmode.com (Peter-Paul Koch)
  99. reuters.com
  100. rockband.com
  101. rollingstone.com
  102. secondlife.com
  103. sfgate.com
  104. shauninman.com
  105. si.com (MLB page)
  106. simonwillison.net
  107. simplebits.com (Dan Cederholm)
  108. sitepoint.com
  109. skype.com
  110. snook.ca (Jonathan Snook)
  111. sony.com
  112. stuffandnonsense.co.uk (Andy Clarke)
  113. target.com
  114. techcrunch.com
  115. theonion.com
  116. time.com
  117. tivo.com
  118. twitter.com
  119. typepad.com
  120. ups.com
  121. urbanoutfitters.com
  122. usaa.com
  123. usps.com
  124. veerle.duoh.com (Veerle Pieters)
  125. virgin.com
  126. wait-til-i.com (Christian Heilmann)
  127. wamu.com
  128. washingtonpost.com
  129. weather.com
  130. wellsfargo.com
  131. whitehouse.gov
  132. williamssonoma.com
  133. wordpress.com
  134. yahoo.com
  135. yelp.com
  136. youtube.com
  137. zeldman.com (Jeffrey Zeldman)

Creating simple ungraded quiz questions with feedback using HTML and JavaScript

Clive Shepherd recently wrote about “inductive learning.” He said:

In my post last week, Whatever happened to inductive learning?, I complained how difficult it was with current rapid development tools to write more conversational inductive questions in which you as author are able to comment on each selection that the user makes.

He explained that he wasn’t looking for graded answers, just a method for providing custom feedback for each clicked answer. He then provided some examples he created in Captivate and Articulate Presenter.

When I read his post, the first thing I thought was how dead-simple it is to create that kind of interaction in HTML and JavaScript. Flash-based products are not (as of this writing, anyway) really built for doing this kind of work, so why bother?

I think the biggest argument for trying to shoehorn this kind of interaction into a Flash-based system is the graphical user interface (GUI)… the avoidance of working directly with code. The Flash-based systems have nice GUIs, while the HTML-based systems are generally outdated and clunky.

Well, for those who don’t like working with code, I feel for ya; I honestly understand where you’re coming from. But, you sometimes need to go outside of your comfort zone to achieve your goals.

For those who are willing to give it a shot, I present to you a simple HTML and JavaScript template for inductive learning-style questions (ungraded, customized feedback for each answer selected).

This is a simple demo, but because it’s built in HTML with CSS and JavaScript, it’s completely customizable and can be restyled and/or re-purposed for a variety of question types. JavaScripters can even add SCORM calls if desired! I’ve used this approach successfully at work, though my version at work uses MooTools effects to give the interactions a much smoother, Flash-like feel.

Enjoy! Please let me know if you find these examples helpful, or if you have other ideas for this kind of question style.

HTML 5: The strong element

I just saw something interesting I thought I’d pass along. In the new HTML 5 proposal, the strong element is being modified to represent “importance rather than strong emphasis.”

The WHATWG gives the following example:


<strong>Warning.</strong> This dungeon is dangerous. 
<strong>Avoid the ducks.</strong> Take any gold you find. 
<strong><strong>Do not take any of the diamonds</strong>, 
they are explosive and <strong>will destroy anything within 
ten meters.</strong></strong> You have been warned.

The b element is supposed to represent “a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened.”

The WHATWG gives the following example:

The <b>frobonitor</b> and <b>barbinator</b> components are fried.

To me, this is both exciting and confusing. Knowing we can nest the strong element opens up some new styling possibilities while keeping the markup valid and semantic. But using both the b and the strong elements, with different conditions for their usage, will ultimately be confusing for most people, including me.

Wonder how WYSIWYG editors will handle this.

Vertical centering — without using tables!

For many years, table-based web page layouts were the rule, not the exception. They were easy to build, they worked cross-browser, and WYSIWYG editors made it a breeze to create and edit tables. CSS-based layouts didn’t really grab hold until just a few years ago, thanks to the evangelism of people like Jeffrey Zeldman and Eric Meyer.

The benefits of CSS-based layouts are very well-documented, and include increased accessibility (for surfers who use assistive technology), ease of site updates (change an entire site’s look and feel with a single stylesheet), and improved search engine rankings (search engines are able to index your content more cleanly when it isn’t surrounded by table markup).

It’s getting easier and easier to avoid table-based layouts these days, and even WYSIWYG editors like Dreamweaver have shifted gears and started including CSS-based layout templates with their software. This is way cool.

But every now and then, a developer like myself will come up against something that was SOOOO easy with table-based layouts and winds up being a royal pain with CSS-based layouts. One of these “d’oh!” moments is when you try to vertically center an element on your web page. Umm… hang on, let me rephrase that: One of these “d’oh!” moments is when you try to vertically center an element on your web page when using Internet Explorer 6.

Firefox supports CSS standards better than Internet Explorer 6 (the dominant browser), and predictably, vertical centering in Firefox is a piece of cake!

This journal entry is devoted to explaining how to get vertical centering working in both Firefox and IE6.

First, an example page.

The ingredients

There are three keys to making this work:

  1. A set of nested DIVs (yes, I know some of you are anti-nested DIV, but hey the world keeps on spinning).
  2. CSS for standards-compliant browsers (Firefox et al)
  3. A separate chunk of CSS for our old friend IE6

Nested DIVs

The first requirement is nested DIVs. You may be thinking “what’s the point of avoiding tables if I still have bloated markup?” My response is that one small set of nested DIVs isn’t nearly as bloated as a table, and using DIVs still helps you keep your markup readable for accessibility purposes and search engines. It’s a good thing! DIVs are also much more flexible should you decide to change your layout later on.

Here’s the layout in all its glory:


<body>
<div id="outer">
  <div id="container">
    <div id="inner">
      <img src="http://pipwerks.com/images/posts/indicator_green.gif" alt="Please wait" width="32" height="32" /><br />
      Loading...<br/>
      Well, not really.<br/>
      But don't I look nice centered like this?
    </div>
  </div>
</div>
</body>

The ‘inner’ DIV is what will hold your content. The ‘outer’ and ‘container’ DIVs’ sole purpose in life is to get your content centered on the page! I’ll explain this in a moment.

The CSS

Let’s look at the CSS:


body {
}

* {
   margin: 0;
   padding: 0;
}

/* macs won't see this! */
html, body { 
   height:100%;
   width:100%;
}
/* END mac */

#outer {
   height:100%;
   width:100%;
   display:table;
   vertical-align:middle;
}

#container {
   display:table-cell;
   vertical-align:middle;
}

#inner {
   text-align: center;
   width: 50%;
   margin-left:auto;
   margin-right:auto;
}

We set all elements on the page to have a default padding and margin of 0. This avoids box-model issues. We also dealt with some Mac inconsistencies with the Mac hack.

As you can see from the CSS, the body and outer elements (outer, container) are set to be 100% wide and 100% tall. The outer element is told to behave like a table (display:table), and is vertically centered using the “vertical-align:middle” property.

By nesting the ‘container’ DIV inside the faux-table, we can make the container DIV behave like a table cell: “display:table-cell”. This DIV is also set to be vertically centered using the “vertical-align:middle” property.

That’s it for the vertical centering in CSS-compliant browsers!

In this case, the ‘inner’ DIV’s CSS is purely for horizontal centering. I set the width to 50% simply because I wanted a narrow DIV, and I centered the DIV horizontally using margin-left: auto and margin-right: auto.

Remember, the code up to this point is for standards-compliant browsers, not IE6.

Dealing with our friend, Internet Explorer 6

Now, you may be thinking that writing different CSS specifically for IE harkens back to the bad old days of browser sniffers and alternate web sites, and you would be correct. However, the alternate CSS is very easy to manage, and doesn’t require a browser sniffer! Thanks to Microsoft’s implementation of conditional comments in IE, we can simply insert a chunk of alternate CSS code into a conditional comment… whatever is inside the comment will be safely ignored by any non-IE browser. Here’s an example:


<!--[if IE ]>
   <style type="text/css">
      body {
         color: #ff0000;
      }
   </style>
<![endif]-->

You can read more about conditional comments at Peter-Paul Koch’s website.

On our vertical centering example, I used the following CSS code in a conditional comment:


#container {
   height: 1px; /* required for IE to properly center vertically */
   position:relative;
   top:50%
}

#inner {
   position:relative;
   top:-50%;
}

Internet Explorer doesn’t support the “display: table”, “display: table-cell” and “vertical-align: middle” properties. To get around this, we have told IE to use relative positioning to move the ‘container’ DIV 50% down from the top of its parent DIV (‘outer’), and to move the ‘inner’ DIV negative 50% from the top its parent DIV (‘container’).

Normally these two values would simply offset each other and cause the ‘inner’ DIV’s content to be displayed at the top of the screen. However, through the magical glitches of IE, by setting the ‘container’ DIV’s height attribute, the DIV suddenly jumps down to the middle of the page, right where we want it to be! I have no idea why, but hey, it works. Here’s the proof.

Important: the height must be set BEFORE the top percentage is declared.

Externalizing the CSS

It’s always a good idea to set up your CSS in external CSS files. This helps keep your web page clean, enables you to re-use your code on other pages, and much more. The CSS contained in the conditional code can also be placed in an external stylesheet. Here’s how I set up my page:


<link href="centering.css" rel="stylesheet" type="text/css" />

<!--[if IE ]>
   <link href="centering-IE.css" rel="stylesheet" type="text/css" />
<![endif]-->

The CSS is exactly the same, but cut and pasted into two external files: centering.css and centering-IE.css.

Now my page is looking clean as a whistle, and I can reuse my code by linking my other pages to my ‘centering’ css files!

Cool, can you do that with a Flash SWF, too?

Yes, you can! Here’s an example.

The code for the Flash example is exactly the same as the first example, except for content: I replaced the contents of the ‘inner’ DIV with some dummy text, and I embedded a Flash SWF using Geoff Stearn’s SWFObject method (the best embedding method I’ve used by far!). No CSS was altered except for the body and font colors.

And there you have it… a nice, (relatively) simple way to vertically center DIVs using CSS and NO tables.

Updates

Thanks to some sharp-eyed readers, here are a few corrections and/or additions:

Update: Here is an example of a Flash SWF embedded with a transparent background. The CSS has been altered slightly: an HTML background image has been specified, and the inner DIV has been set to the exact pixel size of the Flash SWF; this properly centers the SWF and causes scrollbars to appear when a minimum width or height has been reached. Tested successfully in IE6, FF2 and Safari 3 (beta), all Windows XP.

Update 9/03/2007: For IE7, if specifying the height of the inner div, you must also specify the height of the container div in the IE-specific CSS file. For example:

In standard CSS:


#inner {
   text-align: center;
   width: 550px;
   height: 400px;
   margin-left:auto;
   margin-right:auto;
}

In IE7’s CSS:


#container {
   /* required for IE to properly center vertically,
      must match #inner height */
   height: 400px;
   position:relative;
   top:50%
}

Unfortunately, in IE7 this also produces scrollbars (IE7 thinks the page content is larger than it actually is). I plan to do some more research into this when I have the time.