We all know the margin: auto trick for horizontal centering, but if you combine position: absolute, and set the top and bottom properties to 0, guess what? It’s worky for vertical centering as well!

Stephen Shaw’s article goes on to show that it works in most scenarios, including padding, offsets, and even responsive resizing.

I gave it a little run in CodePen, specifically wanting to see what happens when the absolute centering is inside of a container, and you move that container around. The results of my experimentation are here:

Sure enough, the vertical centering stays true to the CSS rules around position:absolute (If the containing element is relative or fixed, positioning — and in this, case centering — is relative to the bounds of the container). As you can see from the screenshot, in addition to the immovable, centered div (with a nested centered div inside of it), there are two fanciful elements, with all their fancy dragging abilities. Each draggable element has double nested, vertically centered divs inside.

In short, it works like a charm.

I did, however, make one modification for text, and that is to treat the div containing text with display:table.
The reason for this is so that we can vertically center multi-line and single-line text. If we employ the vertical centering CSS, like Stephen did, to a div with text, the text won’t ‘cheat up’ on multiple lines. The fix for this is pretty straightforward:

.txt{
text-align:center;
width:100%;
display:table;
}

[Update: the height is automatically calculated, so no reason to set it, unless you maybe want to look at compatibility/fallback — Thanks Stephen!] You’ll notice the height property is set to 2.4em. Setting the height to this value is a good approximation for the amount of height needed when you have a multi-line text div.

If you want to display a single line in the center, just add the following:

.single{
height:1em;
}

Feel free to play around with the CodePen example, and do make sure to check out Stephen Shaw’s article.
He did the heavy lifting here, I’m just propagating a great code snippet.

I’ll expand on this post with a specific example in a few days, but I wanted to get a shout out to Vladimir Kharlampidi for his new Swiper library.

It’s a Carousel, it’s an app-store slider, it’s Windows Metro, all in one slick, performant package. It’s new, it’s FREE, and it just works.

It even asks you to Touch it. How lascivious!

There are some bugs and missing API calls ( .index() and .currentSlide() need to be fixed, and you absolutely need to get to the baseSlides when params.loop = true — I’ll prob. submit the pull requests) so if you want to get programmatic you have to do a little bit of landscaping, but it’s competitive with any other HTML slider out there, works 100% with touch, and it’s fast.

I’ve been going over Javascript frameworks for the past couple of days. Everything from Processingjs and raphaeljs to Jquery and Mootools (a longer post on this later), and I hit something that just pretty much blew my mind.

Meteorjs (or just Meteor, if you want to get semantic) is a framework being built by a gifted, prolific group of scientists, which uses the binding and instant update techniques found in Handlebars, Nodejs, etc, but does it in a way that at first glance may actually qualify as magic. No, seriously.

I’ve been reading a lot lately (rather than posting, sorry kids) and Chris Coyier asked for people’s “Ah ha” moments with Javascript in a recent article.

Well, I had such just such a moment last night at about 3am, and even though it wasn’t for Javascript, Chris’ solicitation inspired me to share it.
Nope, it wasn’t for Javascript. It was for HTML. Specifically, it was for HTTP requests, and website development in general.

So, the old school website philosophy, which is tried and true, is pretty easy to grasp. A full web application is an “enterprise” level MVC design pattern:

You have your database and interface to that database (Model)

You have your web server, which processes requests, reads/writes from the database, and servers web pages (Controller)

You have your web pages, which submit information to the server in the form of POST or GET calls (View)

Simple, straightforward, and proven.

Well, with the introduction of AJAX methodologies almost a decade ago (has it really been that long??? Man, I’m getting old…) we now have a significant portion of the processing / logic being done on the web page itself.
This is a good thing! I’m definitely not saying it isn’t. I’m just punching your ticket on my thought train that led me to my “Aha!” moment…

…as I was saying, the “clean” MVC pattern has been enhanced now, making HTML/Javascript pages become applications in their own right, using MVVM or MVP or other design patterns (I promise, I’m coming up on the point here, just bear with me).

These new patterns utilize JSON, AJAX, and Websocket calls, to interact with online services. Meaning, the webpage itself is now the application, with its own controller/presenter/view model component, and Jquery/Javascript calls to get information from a service is now the model. There is no longer a need for the webpage to make GET/POST calls. In fact, the only thing the web server is needed for now is the downloading of the initial HTML for the web page, and serving up JS and CSS files.

And this is the “Aha!” moment:

HTML is now an application.

(The paradigm of ‘Site’ is dead)

Webpages aren’t webpages anymore. They’re applications. GET/POST should now be looked at as just-another-data-source for the Model of that application, and for “downloading” the application (FKA webpage).

That may not be an “Aha!” moment for anybody else, but the implications of it most definitely were for me:

You don’t need Site Maps anymore.
– What formerly was a separate webpage is now just another view / attribute of the webpage ‘application’.
– For e.g.: Preferences (it used to be a separate page. Now it’s a panel, just like it would be in a fully-installed app)

You can treat a webpage literally as you would a full application:
– It’s ‘downloaded’ and ‘installed’
– It has different modes / views (instead of separate pages)
– It stores information locally (instead of just using cookies)
– It consumes web services (instead of it being the View of a web service, ala POST/GET calls)
– It can live on its own, outside a browser (e.g. PhoneGap)

So there you have it- You can start treating HTML as an application. Not a pseudo-application. An actual application. The call to the web server is now the download+installation process, and nothing else.

I’m 100% sure I’m not the first person to think about it this way, but it was definitely a paradigm shift for me, and qualified in my mind as an “Aha!” moment.