On the tails of the exciting release of YUI 3.1, I wanted to build a little mini web-app to show some of the powerful new features. I built Photos Around You, an app which determines your Geolocation and finds photos geo-tagged around this location. Building this app took ~200 lines of YUI 3.1 JavaScript that I had to write; and this is how its put together:
Archive for the 'Code' Category
Tab Views (i.e. tabbed-content) are ubiquitous on the web.

Tabbed content is everywhere on the web
These interface elements are super simple to implement these days, so it seemed useful to show how a simple Tab View could be created using YUI 3.
The HTML Markup
The markup is a navigation list linking to content sections in the content area; simple and semantic. Some CSS classes are added to help with the layout, styling and JavaScript hooks.
<div class="tabview">
<ul class="tabview-tabs">
<li class="tabview-active"><a href="#content1">Tab 1</a></li>
<li><a href="#content2">Tab 2</a></li>
<li><a href="#content3">Tab 3</a></li>
</ul>
<div class="tabview-content">
<div id="content1"><p>Content for Tab 1</p></div>
<div id="content2" class="tabview-hidden"><p>Content for Tab 2</p></div>
<div id="content3" class="tabview-hidden"><p>Content for Tab 3. bla bla bla…</p></div>
</div>
</div>
The JavaScript Using YUI 3
Using the Y.Node Class made adding the behavior a breeze.
When a tab is clicked:
- I add the
tabview-activeCSS class to it and remove the class for all other tabs. - I then find the corresponding content section and remove the
tabview-hiddenCSS class from it and make sure all the other content sections are hidden.
YUI().use('node', function(Y){
Y.all('.tabview').each(function(){
this.delegate('click', toggleTabs, '.tabview-tabs a');
});
function toggleTabs (e) {
var tabview = e.container,
tabs = tabview.all('.tabview-tabs li'),
contents = tabview.all('.tabview-content > *'),
tab = e.currentTarget.get('parentNode');
contents.addClass('tabview-hidden')
.item(tabs.removeClass('tabview-active').indexOf(tab.addClass('tabview-active')))
.removeClass('tabview-hidden');
e.preventDefault();
}
});
Working Example
I’ve been using RGBA color values, border-radius, and box-shadow CSS3 features all over in my current projects. Since Internet Explorer (6, 7, & 8) does not support any CSS3 features I wanted to find some suitable fallbacks. RGBA color values are the most important (of the three CSS3 features I’m using) to find an IE-alternative; without one, IE will inherit the last non-RGBA color value (which maybe no color value, i.e. transparent).
A great article, Working With RGBA Colour, recently appeared on the collaborative web development blog: 24 Ways. The ‘Supporting All Browsers’ section of the article fell short of describing a robust way to “support” IE without punishing the other browsers.
Falling back to a PNG
In cases where you’re using transparency on a
background-color(although not on borders or text) it’s possible to fall back to using a PNG with alpha channel to get the same effect. This is less flexible than using CSS as you’ll need to create a new PNG for each level of transparency required, but it can be a useful solution.Using the same principal as before, we can specify the background in a style that all browsers will understand, and then overwrite it in a way that browsers without RGBA support will ignore.
h1 { background: transparent url(black50.png); background: rgba(0, 0, 0, 0.5) none; }Drew McLellan, 24 Ways: Working With RGBA Colour
I had a feeling, as did Martin Klepsch, that this code would result in downloading black50.png in browsers which wouldn’t even use/need it (i.e. non-IE browsers). Running tests and investigating alternate fallback techniques for RGBA color values in IE shined some light on this issue. Continue reading ‘RGBA — IE Fallback’
While wandering-around the Internet looking for examples of overlays in web application interfaces I thought of a challenge: create a working Facebook–styled overlay. I’m in the process of creating an application-wide design for overlays and needed some inspiration. Facebook uses overlays extensively and they have a distinct style [that others imitate, maybe even me :-) ]; I set-out to re-create this style.
Not wanting to mess around — I whipped up a working example of Facebook-styled overlays using only YUI 3 and CSS 3; things are nice and easy to do when you use the latest technologies.
The code is short enough I’ll just lay it all down here:
The JavaScript — YUI 3 is doing all the heavy lifting
YUI().use('overlay', 'dd-constrain', function(Y){
var fbOverlay = new Y.Overlay({
contentBox : '#fbOverlay',
width : '540px',
height : '300px',
visible : false
}).render();
// make overlay draggable
new Y.DD.Drag({
node : fbOverlay.get('boundingBox'),
handles : ['.yui-widget-hd']
}).plug(Y.Plugin.DDConstrained, { constrain2view : true });
// show overlay
Y.get('#show-fbOverlay').on('click', function(e){
if ( ! fbOverlay.get('visible') ) {
fbOverlay.align(this, [Y.WidgetPositionExt.TL, Y.WidgetPositionExt.TR]);
fbOverlay.show();
}
});
// hide overlay
Y.get('#hide-fbOverlay').on('click', function(e){
fbOverlay.hide();
});
});
Oh, and if you didn’t notice these Facebook–styled overlays are drag-able; Facebook doesn’t do that…
The CSS [3] — This is all me… and Facebook’s colors
#fbOverlay { display: none; }
.yui-widget #fbOverlay {
display: block;
background: rgba(0, 0, 0, 0.5);
border-radius: 6px;
-moz-border-radius: 6px;
-webkit-border-radius: 6px;
padding: 10px;
}
#fbOverlay .yui-widget-hd {
border: #3B5998 1px solid;
background: #6D84B4;
color: #fff;
padding: 0 10px;
cursor: move;
}
#fbOverlay .yui-widget-bd {
background: #fff;
border: #555 1px solid;
border-top: none;
border-bottom : none;
padding: 0 10px;
}
#fbOverlay .yui-widget-ft {
border: #555 1px solid;
border-top: none;
background: #f2f2f2;
}
#fbOverlay .yui-widget-ft > div {
border-top: #ccc 1px solid;
padding: 5px 10px;
text-align: right;
}
If you View Source you’ll see the contents of the overlay are in the (X)HTML; I’m making sure the hide these overlay–contents until the YUI Overlay Class instance grabs them up.
Not much to it; the only CSS 3 stuff is in the second rule, background: rgba(0, 0, 0, 0.5); giving the background some transparency and border-radius: 6px; to round-them-corners. Funny thing, these two style declarations save so much time and effort; look the source for Facebook’s overlay and you’ll see a nasty-mess of tables.
If you missed the link to the working version of the code above: here it is again.
JavaScript developers know the DOM API sucks: very verbose, and hairy across browsers. Some JavaScript library developers have chosen an innerHTML— approach for dynamically writing markup (DHTML). I’d argue this is just as crazy as trying to use the native DOM API.
Some [including me] are fed up with either alternative and decide to create a new API for writing markup in JavaScript:
Jeethu: “One of the sweetest parts of Mochikit IMO has been Mochikit.DOM. This is something which I’ve always missed with YUI. innerHTML is fast, but icky and it feels a little inelegant. So, I ended up writing something like Mochikit.DOM for YUI while writing Tagz. Thought it might be useful to others as well. So, here’s the mercurial repo with the code.”
Jeethu has something here; but I’m not psyched about the API design. The simple example on his blog post lacks clarity; the nested tree structure feels overly complicated. When creating a document in (X)HTML, nesting makes sense, you’re authoring the document as a whole thing. When programatically outputting (X)HTML, there isn’t a clear vision of the document as a whole. I prefer to keep with the semantics of programming when generating markup by writing meaningful statements.
At Oddnut Software, my small company (just two of us), we’re thinking about this issue with a broader vision: a unified API for writing XHTML on the server (Java) and on the client (JavaScript). We plan to open-source our project once it’s ready; we’re working out some of the final features.
For quite some time I’ve had a desire to fetch screenshots of webpages in thumbnail form. My last round of development in the area involved a somewhat overly complex solution using Amazon’s AWS Alexa Site Thumbnail service. I chose to integrate with the AWS Alexa Thumbnail service over other services because it just returned an image, no extra crap (Snap’s thumbnails are grotesque) and no ads. Although the service wasn’t free, it only cost a few pennies to use.
The other requirement I have is to retrieve the thumbnails in JavaScript. This lead to the creation my Ajax Alexa Thumbnails project. The AWS Alexa Thumbnail service required a client to interact via a XML web service (similar to the other AWS services), this means signing the request with your AWS credentials; something I wasn’t going to do in JavaScript. The project became too complex for the task; it involved making an Ajax request to a local PHP file which dealt with sending the request to and receiving the response from Amazon. Crazy I know, which is why I’m deprecating the Ajax Alexa Thumbnails project along with the deprecation of the AWS Alexa Thumbnail service in favor of my new solution [below] using Page Glimpse. Continue reading ‘Webpage Thumbnails — Screenshots via Page Glimpse in JavaScript’
I’m working on the rich UI of a small web application which has a problem I need to solve: the data from the server which the UI is presenting could change at any time. The first iteration of the UI has a refresh button. Clicking this button sends an Ajax request to a resource on the server which responds with a JSON data structure, and the UI is updated with any changes in the new data. My business partner doesn’t like the refresh button; he questions why it’s there and states how annoying it is to press the button all the time. His suggestion is the rich UI should smartly poll the server for changes to the data, and update the UI automatically.
Intrigued by his idea, we continued our discussion leading to a definition for what it means to smartly poll a server’s resource:
- Use conditional GET requests
- Retain the most recent Etag and Last-Modified date of the polled resource
- Disable polling when the browser window is inactive
Implementing a smart polling process in our application’s rich UI gives us some desired benefits:
- Removal of the refresh button
- Automatic updating of the UI when the resource on the server has changed
- Less repainting of the page since the DOM is touched only when the data has changed
- Changes to the UI only happen when the window is active (the user sees them) as polling is paused while the user is doing something else
Creating a reusable component to achieve a smart polling process feels like the correct approach as I foresee a need to use this functionality in future projects as well. Continue reading ‘Smart Polling’
Great news for YUI3: Matt Sweeney, a YUI Developer, has integrated the Sizzle JavaScript Selector Library in a branch of the YUI3 code-base on GitHub. There has been interest from the community about this integration for quite some time. I personally was hoping for Sizzle adoption into YUI3; this now appears to be the case.
Using the Selector utility in YUI2 I would find myself hitting bugs and roadblocks where my expectations weren’t matching the outcomes. I’ve felt since first using the selector engine in YUI that it didn’t compare in speed, robustness, or completeness to jQuery’s. With the Sizzle project, there’s a narrow focus and distinct vision: To make the best damn selector engine. Since a selector engine is an essential component to any modern JavaScript library, why not make one really good one for all libraries to use? That’s the route the Sizzle project has taken.
Once Sweeney’s branch is merged into the YUI3 Master Head, I’ll be doing a git pull and give it some exercise.
Bazaar is my prefered and default version control system. While searching for a replacement to Subversion it was clear that a distributed VCS was the way to go. This lead me to comparing Git, Mercurial, and Bazaar; ultimately choosing Bazaar for having a company backing it, great documentation, and easy transition from Subversion.
I tend to think that open source code I write falls into two categories: full projects, and everything else (examples, snippets, module). When the code I’m writing is turning into something I plan to release as an open source project, then I’ll release it on Google Code. For small chunks of code, especially code to supplement a post here, I’ve been releasing it to the files directory here.
Bazaar is built to work over standard protocols including HTTP; making it perfect to enhance a browsable directory on my server as a public ready-only Bazaar repository. This is precisely what I did with the /files directory; each sub-directory in /files is a bzr branch.
Feel free to bzr branch any branchs in my http://925html.com/files/ repository.
$ mkdir 925html
$ cd 925html/
$ bzr branch http://925html.com/files/branch_name
There’s been some changes with the Yahoo! User Interface library (YUI) project to make it more open. Contributing to YUI in the past was an odd burdenson process as the public-facing YUI project on SourceForge was essentially a proxy to an internal project at Yahoo!.
Over the past month many changes have come to the YUI project that are more than just code:
- The YUI project now consists of several [main] components:
- YUI 2 and YUI 3 Source Code Now on GitHub
- Also YUICompressor and YUIDoc project components, making the entire YUI source code on GitHub
- YUI has a new home [page] http://YUILibrary.com
- The site is not hosted at Yahoo!, but rather on SliceHost
- The YUI bug repository has been migrated from Source Forge to YUILibrary.com
- Out with the old YDN YUI tech forum, in with the new YUILibrary.com Forums
- YUI is now present on Twitter, FriendFeed, and Facebook

