The Rich Web Experience

Tea leaf [Flickr]

Aaron Gustafson — Sat, 28 Jan 2012 11:01:00 CST

The apparent results of meeting room boredom [Flickr]

Aaron Gustafson — Fri, 27 Jan 2012 11:21:00 CST

LinkedIn Etiquette

Howard Lewis Ship — Fri, 27 Jan 2012 10:07:08 CST

I've used LinkedIn for many years now, long before I joined Facebook ... I liked the concept of never losing contact information with business contacts and technologist. It just seemed like a good idea (though I do sometimes wonder if LinkedIn has any particular purpose).

I tend to only connect with people I've met in person, or at least talked to on the phone.

One thing that drives me crazy about LinkedIn is that you aren't forced to customize the message. As far as I'm concerned, the default message is like no message at all, and its a sign that you are just trolling for contacts. Just like you should always write a cover letter for a resume.

So the first rule of LinkedIn is: always customize the message. You chances of a connection go up significantly (at least with me) ... and with the default message, your chances drop down to near zero.

Tapestry Advantages

Howard Lewis Ship — Thu, 26 Jan 2012 12:26:50 CST

A summary of a discussion about the advantages of Tapestry over Struts:

Exceptional exception reporting
Significantly less code
Live class reloading
Sensible defaults, especially for SEO-friendly URLs
Great community
Flexibility and customizability

Interestingly, the quality of Tapestry's documentation was mentioned ... favorably! Between the revised home page, and Tapestry JumpStart (and Igor's coming book), I think we're headed in the right direction in terms of documentation going from a liability to an asset.

Getting Around Entering a SSL Passphrase when Restarting Apache

Mike Girouard — Thu, 26 Jan 2012 11:23:00 CST

Shame on me for not knowing this earlier.

sudo apachectl -k graceful

Reloads the Apache httpd gracefully by reloading configs only. This is hella useful if your server has SSL VHosts with passwords that you don’t know.

RedHat folks can do use service too:

sudo -i service httpd graceful

Github Ribbons in CSS

Terry Ryan — Wed, 25 Jan 2012 15:55:00 CST

Github has these cool ribbon images that you can use if you want to encourage forking your project on your site. They're great and I wanted to use them on a little project I am working on. However, one of my goals was not to use any images, but rather produce all display elements with CSS.

It was a little bit of trial and error but I got it working. Basically you do the following:

Create a link in a div with an id of "banner"
Force div#banner to be 149px x 149px.
Set overflow to "hidden"

This creates a square display area that won't show things that stretch out past the bounds of the box.

Create an A link
Tilt it using a CSS transform
Use relative positioning to pull the ribbon into place
Use CSS shadows to tweak the text and ribbon shadows
Finally I use a CSS gradient in the background of the ribbon to give it the bands that run along the edge.

Issues:

It's not a pixel perfect representation.
It doesn' work on IE before 9. It doesn't appear at all.

I'm not sure if I'm going to use this. I'll sound judgmental here, but the fact that it doesn't show up on IE less than 9 seems like a good thing. Do I want a developer on my project that isn't using the latest browser? Probably not.

Demo
See the live demo here.

Update

A couple people pointed out that there was a weird doubling of the letters on their browser (Chrome on Windows, and Safari on iPad.) Looks like it was caused by a slight text-shadow I had on the text. The text on the original banner has some anti-aliasing going on, and on some browsers, the text shadow helps it look a little smoother, but on others you get that doubling. So I've removed the text shadow. Display should be a little more consistent.

Tapestry 5.4: Focus on JavaScript

Howard Lewis Ship — Wed, 25 Jan 2012 09:46:00 CST

Tapestry 5.3.1 is out in the wild ... and if Tapestry is to stay relevant, Tapestry 5.4 is going to need to be something quite (r)evolutionary.

There was some confusion on the Tapestry developer mailing list in advance of this blog post; I'd alluded that it was coming, and some objected to such pronouncements coming out fully formed, without discussion. In reality, this is just a distillation of ideas, a starting point, and not a complete, finalized solution. If it's more detailed than some discussions of Tapestry's evolution in the past, that just means that the mailing list discussion and eventual implementation will be that much better informed.

In posts and other conversations, I've alluded to my vision for Tapestry 5.4. As always, the point of Tapestry is to allow developers to code less, deliver more, and that has been the focus of Tapestry on the server side: everything drives that point: terseness of code and templates, live class reloading, and excellent feedback are critical factors there. Much of what went into Tapestry 5.3 strengthened those points ... enhancements to Tapestry's meta-programming capabilities, improvements to the IoC container, and reducing Tapestry's memory footprint in a number of ways. I have one client reporting a 30% reduction in memory utilization, and another reporting a 30 - 40% improvement in execution speed.

Interestingly, I think that for Tapestry to truly stay relevant, it needs to shift much, much, more of the emphasis to the client side. For some time, Tapestry has been walking a fine line with regards to the critical question of where does the application execute? Pre-Ajax, that was an easy question: the application runs on the server, with at most minor JavaScript tricks and validations on the client. As the use of Ajax has matured, and customer expectations for application behavior in the browser have expanded, it is no longer acceptable to say that Tapestry is page based, with limited Ajax enhancements. Increasingly, application flow and business logic need to execute in the browser, and the server-side's role is to orchestrate and facilitate the client-side application, as well as to act as a source and sink of data ultimately stored in a database.

As Tapestry's server-side has matured, the client side has not kept sufficient pace. Tapestry does include some excellent features, such as how it allows the server-side to drive client-side JavaScript in a modular and efficient way. However, that is increasingly insufficient ... and the tension caused by give-and-take between client-side and server-side logic has grown with each release.

Nowhere is this more evident than in how Tapestry addresses HTML forms. This has always been a tricky issue in Tapestry, because the dynamic rendering that can occur needs to be matched by dynamic form submission processing. In Tapestry, the approach is to serialize into the form instructions that will be used when the form is submitted (see the store() method of the FormSupport API). These instructions are used during the processing of the form submission request to re-configure the necessary components, and direct them to read their query parameters, perform validations, and push updated values back into server-side objects properties. If you've ever wondered what the t:formdata hidden input field inside every Tapestry forms is about ... well, now you know: it's a serialized stream of Java objects, GZipped and MIME encoded.

However, relative to many other things in Tapestry, this is a bit clumsy and limited. You start to notice this when you see the tepid response to questions on the mailing list such as "how to do cross-field validation?" Doing more complicated things, such as highly dynamic form layouts, or forms with even marginal relationships between fields, can be problematic (though still generally possible) ... but it requires a bit too much internal knowledge of Tapestry, and the in-browser results feel a bit kludgy, a bit clumsy. Tapestry starts to feel like it is getting in the way, and that's never acceptible.

Simply put, Tapestry's abstractions on forms and fields is both leaky and insufficient. Tapestry is trying to do too much, and simply can't keep up with modern, reasonable demands in terms of responsiveness and useability inside the client. We've become used to pages rebuilding and reformatting themselves even while we're typing. For Tapestry to understand how to process the form submission, it needs a model of what the form looks like on the client-side, and it simply doesn't have it. There isn't an effective way to do so without significantly restricting what is possible on the client side, or requiring much more data to be passed in requests, or stored server-side in the session.

The primary issue here is that overall form submission cycle, especially combined with Tapestry's need to serialize commands into the form (as the hidden t:formdata field). Once you add Ajax to this mix, where new fields and rules are created dynamically (on the server side) and installed into the client-side DOM ... well, it gets harder and harder to manage. Add in a few more complications (such as a mix of transient and persistent Hibernate entities, or dynamic creation of sub-entities and relationships) into a form, it can be a brain burner getting Tapestry to do the right thing when the form is submitted: you need to understand exactly how Tapestry processes that t:formdata information, and how to add your own callbacks into the callback stream to accomplish just exactly the right thing at just exactly the right time. Again, this is not the Tapestry way, where things are expected to just work.

Further, there is some doubt about even the desirability of the overall model. In many cases, it makes sense to batch together a series of changes to individual properties ... but in many more, it is just as desirable for individual changes to filter back to the server (and the database) as the user navigates. Form-submit-and-re-render is a green screen style of user interaction. Direct interaction is the expectation now, and that's something Tapestry should embrace.

What's the solution, then? Well, it's still very much a moving target. The goal is to make creating client-side JavaScript libraries easier, to make it easier to integrate with libraries such as jQuery (and its vast library of extensions), make things simpler and more efficient on the client side, and not sacrifice the features that make Tapestry fun and productive in the first place.

Overall Vision

The overall vision breaks down into a number of steps:

Reduce or remove outside dependencies
Modularize JavaScript
Change page initializations to use modules
Embrace client-side controller logic

Of course, all of these steps depend on the others, so there isn't a good order to discuss them.

Reducing and removing outside dependencies

Tapestry's client-side strength has always been lots of "out of the box" functionality: client-side validation, Zones and other Ajax-oriented behaviors, and a well-integrated system for performing page-level initializations.

However, this strength is also a weakness, since that out of the box behavior is too tightly tied to the Prototype and Scriptaculous libraries ... reasonable choices in 2006, but out-of-step with the industry today. Not just in terms of the momentum behind jQuery, but also in terms of very different approaches, such as Sencha/ExtJS and others.

It was a conscious decision in 2006 to not attempt to create an abstraction layer before I understood all the abstractions. I've had the intermediate time to embrace those abstractions. Now the big problem is momentum and backwards compatibility.

Be removing unnecessary behaviors, such as animations, we can reduce Tapestry's client-side needs. Tapestry needs to be able to attach event handlers to elements. It needs to be able to easily locate elements via unique ids, or via CSS selectors. It needs to be able to run Ajax requests and handle the responses, including dynamic updates to elements.

All of these things are reasonable to abstract, and by making it even easier to execute JavaScript as part of a page render or page update (something already present in Tapestry 5.3), currently built-in features (such as animations) can be delegated to the application, which is likely a better choice in any case.

Modularizing JavaScript

Tapestry has always been careful about avoiding client-side namespace polution. Through release 5.2, most of Tapestry's JavaScript was encapulated in the Tapestry object. In Tapestry 5.3, a second object, T5 was introduced with the intention that it gradually replace the original Tapestry object (but this post represents a change in direction).

However, that's not enough. Too often, users have created in-line JavaScript, or JavaScript libraries that defined "bare" variables and functions (that are ultimately added to the browser's window object). This causes problems, including collisions between components (that provide competing definitions of objects and functions), or behavior that varies depending on whether the JavaScript was added to the page as part of a full-page render, or via an Ajax partial page render.

The right approach is to encourage and embrace some form of JavaScript module architecture, where there are no explicit global variables or functions, and that all JavaScript is evaluated inside a function, allowing for private variables and functions.

Currently, I'm thinking in terms of RequireJS as the way to organize the JavaScript. Tapestry would faciliate organizing its own code into modules, as well as application-specific (or even page-specific) JavaScript modules. This would mean that de-referencing the T5 object would no longer occur (outside of some kind of temporary compatibility mode).

For example, clicking a button inside some container element might, under 5.3, publish an event using Tapestry's client-side publish/subscribe system. In the following example, the click events bubble up from the buttons (with the button CSS class name) to a container element, and are then published under the topic name button-clicked.

Consider this an abbreviated example, as it doesn't explain where the element variable is defined or initialized; the important part is the interaction with Tapestry's client-side library: the reference to the T5.pubsub.publish function.

Under 5.4, using the RequireJS require function, this might be coded instead as:

Here, the t5/pubsub module will be loaded by RequireJS and passed as a parameter into the function, which is automatically executed. So, this supports JavaScript modularization, and leverages RequireJS's ability to load modules on-the-fly, as needed.

Notice the difference between the two examples; in the first example, coding as a module was optional (but recommended), since the necessary publish() function was accessible either way. In the 5.4 example, coding using JavaScript modules is virtually required: the anonymous function passed to require() is effectively a module, but its only through the use of require() (or RequireJS's define()) that the publish() function can be accessed.

This is both the carrot and the stick; the carrot is how easy it is to declare dependencies and have them passed in to your function-as-a-module. The stick is that (eventually) the only way to access those dependencies is by providing a module and declaring dependencies.

Change page initializations to use modules

Tapestry has a reasonably sophisticated system for allowing components to describe their JavaScript requirements as they render, in the form of the JavaScriptSupport environmental (an environmental is a kind of per-thread/per-request service object). Methods on JavaScriptSupport allow a component to request that a JavaScript library be imported in the page (though this is most commonly accomplished using the Import annotation), and to request the initialization functions get executed.

Part of Tapestry's Ajax support is that in an Ajax request, the JavaScriptSupport methods can still be invoked, but a completely different implementation is responsible for integrating those requests into the overall reply (which in an Ajax request is a JSON object, rather than a simple stream of HTML).

Here's an example component from the TapX library:

The @Import annotation directs that a stack (a set of related JavaScript libraries, defined elsewhere) be imported into the page; alternately, the component could import any number of specific JavaScript files, located either in the web application context folder, or on the classpath.

Inside the afterRender() method, the code constructs a JSONObject of data needed on the client side to perform the operation. The call to addInitializerCall references a function by name: this function must be added to the T5.Initializers namespace object. Notice the naming: tapxExpando: a prefix to identify the library, and to prevent collisions with any other application or library that also added its own functions to the T5.initializers object.

The JavaScript library includes the function that will be invoked:

Under 5.4, this would largely be the same except:

There will be a specific Java package for each library (or the application) to store library modules.
The JavaScriptSupport environmental will have new methods to reference a function, inside a module, to invoke.
Stacks will consist not just of individual libraries, but also modules, following the naming and packaging convention.

Embrace client-side controller logic

The changes discussed so far only smooth out a few rough edges; they still position Tapestry code, running on the server, as driving the entire show.

As alluded to earlier; for any sophisticated user interface, the challenge is to coordinate the client-side user interface (in terms of form fields, DOM elements, and query parameters) with the server-side components; this is encoded into the hidden t:formdata field. However, it is my opinion that for any dynamic form, Tapestry is or near the end of the road for this approach.

Instead, it's time to embrace client-logic, written in JavaScript, in the browser. Specifically, break away from HTML forms, and embrace a more dynamic structure, one where "submitting" a form always works through an Ajax update ... and what is sent is not a simple set of query parameters and values, but a JSON representation of what was updated, changed, or created.

My specific vision is to integrate Backbone.js (or something quite similar), to move this logic solidly to the client side. This is a fundamental change: one where the client-side is free to change and reconfigure the UI in any way it likes, and is ultimately responsible for packaging up the completed data and sending it to the server.

When you are used to the BeanEditForm component, this might feel like a step backwards, as you end up responsible for writing a bit more code (in JavaScript) to implement the user interface, input validations, and relationships between fields. However, as fun as BeanEditForm is, the declarative approach to validation on the client and the server has proven to be limited and limiting, especially in the face of cross-field relationships. We could attempt to extend the declarative nature, introducing rules or even scripting languages to establish the relationships ... or we could move in a situation that puts the developer back in the driver's seat.

Further, there are some that will be concerned that this is a violation of the DRY pricipal; however I subscribe to different philosophy that client-side and server-side validation are fundamentally different in any case; this is discussed in an excellent blog post by Ian Bickling.

Certainly there will be components and services to assist with this process, in term of extracting data into JSON format, and converting JSON data into a set of updates to the server-side objects. There's also a number of security concerns that necessitate careful validation of what comes up from the client in the Ajax request. Further, there will be new bundled libraries to make it easier to build these dynamic user interfaces.

Conclusion

In this vision of Tapestry's future, the server-side framework starts to shift from the focus of all behavior to the facilitator: it paints the broad stokes on the server, but the key interactions end up working exclusively on the client.

I'm sure this view will be controversial: after all, on the surface, what the community really wants is just "jQuery instead of Prototype". However, all of the factors described in the above sections are, I feel, critical to keeping Tapestry relevant by embracing the client-side in the way that the client-side demands.

I think this change in focus is a big deal; I think it is also necessary for Tapestry to stay relevant in the medium to long term. I've heard from many individual developers (not necessarily Tapestry users) that what they really want is "just jQuery and a restful API"; I think Tapestry can be that restful API, but by leveraging many of Tapestry's other strengths, it can be a lot more. Building something right on the metal feels empowering ... until you hit all the infrastructure that Tapestry provides, including best-of-class exception reporting, on-the-fly JavaScript aggregation and minimization, and (of course) live class reloading during development. java

I'm eager to bring Tapestry to the forfront of web application development ... and to deliver it fast! Monitor the Tapestry developer mailing list to see how this all plays out.

More shovels

Tim Kadlec — Wed, 25 Jan 2012 09:39:00 CST

There is no shortage of information floating around today. There are a multitude of books, magazines, newspapers, blog posts, articles, videos and podcasts just clamoring for our attention. It’s an incredible thing, this wealth of information we have at our fingertips. Never before has so much knowledge been so easily accessible.

We’ve responded by creating a lot of tools that help us collect this information. We can easily store quotes, snippets or even full articles in any one of a hundred different sites and services. We can save links to the videos and recordings that moved us on some level. RSS feeds make it incredibly easy to consume massive quantities of online articles and blog posts. Tools like the incredible Ifttt help make our many online services interact with each other, further easing the process of collecting information.

But what happens to that information after it has been carefully tagged and stored away? The more new information we collect, the more old information gets buried. That post we read that sparked an idea, that quote that stirred something deep within—lost and buried. Forgotten amongst the piles of all the other information we’ve collected.

Certainly this is nothing new—the issue has merely been amplified. Technology, though, is supposed to work for us. It’s supposed to help us solve issues we’ve had in the past. Why not push our tools to not merely collect, but to remind us what is already there?

We need more services like the Kindle Daily Review and Timehop. Kindle’s Daily Review delivers “flash-cards” of a book you’ve read in the past. It displays notes and highlights that you made. It’s fantastic! I love seeing a passage from a book that I had forgotten all about, but that still sparks something within me. Timehop is similar—it lets you know what you posted on Twitter, Facebook, Foursquare or Instagram a year ago. I’ve only been using that service for a short time, but already I’ve found several articles and conversations that I had forgotten about.

Why is this important? Because serendipity is a stimulant. In his book, “Marshall McLuhan: You Know Nothing of My Work”, Douglas Coupland had this to say about Marshall McLuhan, one of the most prescient minds of the last century: “For Marshall, the fun of ideas lay in crashing them together to see what emerged from the collision.” When you rub two stones together, you can make a spark that starts a fire. Put two seemingly unrelated ideas next to each other and the effect is the same.

Searching, for the most part, eliminates those kinds of serendipitous discoveries. It’s a more or less direct path to the very specific type of information we are looking for. A service like the Kindle Daily Review, a service that provides automated nostalgia—that’s the kind of tool that encourages the mixing of ideas, the friction that causes the spark.

We have enough piles. What we need are more shovels.

Boston Cream Pie [Flickr]

Aaron Gustafson — Tue, 24 Jan 2012 20:29:00 CST

Aaron Gustafson posted a photo:

Batch Update All Your Vendor Repositories

Mike Girouard — Tue, 24 Jan 2012 20:18:00 CST

I’ve got just shy of 100 vendor repositories that I pull from for my side projects and client work. Updating them all has become quite a bother so I wrote this little guy to save me some time.

It’s certainly not perfect, and sometimes falls over, but this does the trick. This handles both Git and SVN repositories, but I’m sure with a few extra lines you can make it work for whatever SCM you prefer to use.

Tapestry 5.4: Focus on JavaScript

Howard Lewis Ship — Tue, 24 Jan 2012 19:24:33 CST

Tapestry 5.3.1 is out in the wild ... and if Tapestry is to stay relevant, Tapestry 5.4 is going to need to be something quite (r)evolutionary.

There was some confusion on the Tapestry developer mailing list in advance of this blog post; I'd alluded that it was coming, and some objected to such pronouncements coming out fully formed, without discussion. In reality, this is just a distillation of ideas, a starting point, and not a complete, finalized solution. If it's more detailed than some discussions of Tapestry's evolution in the past, that just means that the mailing list discussion and eventual implementation will be that much better informed.

In posts and other conversations, I've alluded to my vision for Tapestry 5.4. As always, the point of Tapestry is to allow developers to code less, deliver more, and that has been the focus of Tapestry on the server side: everything drives that point: terseness of code and templates, live r2eloading, and excellent feedback are critical factors there. Much of what went into Tapestry 5.3 strengthened those points ... enhancements to Tapestry's meta-programming capabilities, improvements to the IoC container, and reducing Tapestry's memory footprint in a number of ways. I have one client reporting a 30% reduction in memory utilization, and another reporting a 30 - 40% improvement in execution speed.

Overall Vision

The overall vision breaks down into a number of steps:

Reduce or remove outside dependencies
Modularize JavaScript
Change page initializations to use modules
Embrace client-side controller logic

Of course, all of these steps depend on the others, so there isn't a good order to discuss them.

Reducing and removing outside dependencies

Modularizing JavaScript

Under 5.4, using the RequireJS require function, this might be coded instead as:

Change page initializations to use modules

Here's an example component from the TapX library:

The JavaScript library includes the function that will be invoked:

Under 5.4, this would largely be the same except:

There will be a specific Java package for each library (or the application) to store library modules.
The JavaScriptSupport environmental will have new methods to reference a function, inside a module, to invoke.
Stacks will consist not just of individual libraries, but also modules, following the naming and packaging convention.

Embrace client-side controller logic

The changes discussed so far only smooth out a few rough edges; they still position Tapestry code, running on the server, as driving the entire show.

Conclusion

I'm eager to bring Tapestry to the forfront of web application development ... and to deliver it fast! Monitor the Tapestry developer mailing list to see how this all plays out.

@globalmoxie on the furry blanket [Flickr]

Aaron Gustafson — Tue, 24 Jan 2012 13:39:00 CST

Aaron Gustafson posted a photo:

Review: Gradle Class with Luke Daley

Howard Lewis Ship — Tue, 24 Jan 2012 12:32:18 CST

Last week, Luke Daly arrived in Portland to teach a three day Gradle class; the folks at Gradleware were nice enough let me audit the class (so it only cost me a couple of thousand dollars of lost billing revenue to attend). My goals for the class was to gain a deeper understanding of how Gradle works, so that I could write more efficient builds, diagnose problems, and write my own plugins. The class scored very high on all of those counts!

Much of the first day was spent on basics, including a very useful introduction to the Groovy programming language (which is the basis of the Gradle DSL). Even though I have used Groovy pretty extensively for testing purposes over the last couple of years, there were features I've glossed over in the past that turned out to be very useful.

The class is taught largely bottom up: from the basics of declaring tasks, then actions on tasks, and gradually working up towards defining tasks inputs and outputs. Compiling Java came pretty late, which seems curious since that's the primary job of Gradle, but this makes sense from a bottom-up approach as SourceSets can then be described correctly.

The class alternates between lecture and discussion, and short focused labs. At the end of the third day, we worked on tuning up our own builds, passing the video projector cable around ... we had a good time making the Tapestry build more efficient and readable, as well as adding new features to it.

I'm feeling very good about my Gradle skills after attending the course; I've already been able to make further improvements to the Tapestry build subsequently, and I have plans for more involving things going forward.

The return on investment for this class is a bit tricky; Gradle simply does so much straight out of the box, and even without a strong understanding of its structure, you can kind of get it to do what you want just by guesswork and Googling. If you've been using Gradle for a while, I give this a cautious recommendation: getting back the three days of invested time may take a while to pay off. On the other hand, if you are currently dependent on Ant or Maven ... sign up for the next class and get yourself switched over, today!

Now rotating: Baristas Fashionistas Mother Teresas by The Nim Nims [Flickr]

Aaron Gustafson — Mon, 23 Jan 2012 21:54:00 CST

Aaron Gustafson posted a photo:

80s’ [Flickr]

Aaron Gustafson — Mon, 23 Jan 2012 17:43:00 CST

Aaron Gustafson posted a photo:

Speaking in Philly this Week

Terry Ryan — Mon, 23 Jan 2012 12:57:00 CST

I'll be speaking in my hometown this week. I'll be presenting at the Philadelphia Area New Media Association (PANMA) meeting for January.

Topics:

jQuery Mobile
PhoneGap
Typekit
Edge
CSS Shaders

Description:

Adobe and HTML5

In the past few months, there has been a number of new tools and new services from Adobe for HTML5. Some of these tools, like PhoneGap Build and jQuery contributions are aimed at developers and some, such as Edge, are more focused on designers. Adobe Evangelist Terry Ryan will give an overview and demos of these and other tools.

The meeting is on Thursday, January 26th at 6:00PM. It will be at the Huntsman Building at 38th and Walnut on Penn's Campus.

Venn Diagram entirely in CSS

Terry Ryan — Mon, 23 Jan 2012 11:56:00 CST

A friend of mine alerted me this weekend to just how much I have a weird fascination with Venn diagrams. I decided to roll with it. So yeah, I have an irrational love of Venn diagrams. But that begs the question, can I make a Venn diagram with just CSS?

I found a couple of examples out there:

But I felt like they had a bit too much fluff in the HTML markup. Not that there is anything technically wrong with their implementations. I prefer complexity in my CSS and not in my HTML. It's probably just a subjective thing, but I do.

So how do you do it?

First you create 3 divs. 1 for each Venn circle, and 1 for the overlap section. Each div contains a p with content in it.

Then you go to style each of the circles. Give them matching heights and widths, and a border radius of half of the height. This creates the circle. Then give each one an opacity below 1. This will ensure that when they overlap they will form a new color.

I then created two rules based on the nth child css selector to color each of the circles. I also padded to ensure that there would be a space to write in the overlap section.

Finally I styled the overlap section using relative positioning and pulled it back towards the center.

The real trick is to watch the pixel counts because a couple are directly related.

To create a circle:

width must equal height
border radius must equal 50% of width.

To overlap circles:

Circle 2 must have negative x left margin
(Or Circle 1 must have negative x right margin)
Each circle must have x padding-left or x padding-right to ensure its text doesn't spill over borders

It looks like the example works across modern browsers, including IE 9, but not previous versions.

Columbus Circle grid [Flickr]

Aaron Gustafson — Wed, 18 Jan 2012 17:33:00 CST

Aaron Gustafson posted a photo:

Lost [Flickr]

Aaron Gustafson — Wed, 18 Jan 2012 13:01:00 CST

Aaron Gustafson posted a photo:

Explore the Future [Flickr]

Aaron Gustafson — Wed, 18 Jan 2012 07:59:00 CST

Aaron Gustafson posted a photo:

Glowing red [Flickr]

Aaron Gustafson — Tue, 17 Jan 2012 21:32:00 CST

Aaron Gustafson posted a photo:

Sparkly [Flickr]

Aaron Gustafson — Tue, 17 Jan 2012 15:09:00 CST

Aaron Gustafson posted a photo:

One heckuva chandelier [Flickr]

Aaron Gustafson — Tue, 17 Jan 2012 15:02:00 CST

Aaron Gustafson posted a photo:

Speaking at Webvisions Next Week in NYC

Terry Ryan — Fri, 13 Jan 2012 15:57:00 CST

I was originally scheduled to help out my colleague Kevin Hoyt as a TA. Turns out that there was a slight scheduling SNAFU and I'm taking a full slot. My topic:

The Future of HTML5 Motion Design

HTML5 and CSS3 are hot, driven by an explosion of new, Internet connected devices. While they offer many new features that should allow you to do the types of things that you previously did in Flash, actually making it happen is really hard. Until now.

If you weren't sure, I'll be talking about Adobe Edge, our HTML5 animation tool. It's currently in beta, and looking pretty cool.

So if you're in NYC, and want to get some dirt on where Adobe is going with HTML animation or just to get close to some of the foremost experts on the web, you really got to check out Webvisions.