Centering a Div Tag with Physics, Instead of CSS

Summary: I combined a Javascript CSS parser and a Javascript physics engine to layout DOM elements with physics.

After reading yet another guide to layout with CSS, and yet another flame-war over CSS’s flaws, I just wanted to ditch CSS entirely. Tex has had a box and glue model, that has functioned well, for decades in print, but the tooling looks unusable for rendering webpage layouts requiring dynamic flexing and reflowing. So, why can’t I just connect two DOM nodes with a spring and have it flex as the the document resizes? (And, this is 2014. Where is my flying car?)

Using the real physical laws of motion, that people expect out of real world objects, actually makes some sense when you think of a document as in motion. CSS grids, using frameworks such as Twitter Bootstrap, have different layout configurations for ranges of different window sizes, based on CSS media queries. But, you can also see it as a page squeezing and stretching based on the user’s window size, with the DOM nodes connected by springs, colliding as the window is squeezed and stretching apart as the window is stretched. So, I built a Physics-based Page Layout system (Live demo).

Conceptual Springs

I am, currently, using a modified physics engine, originally built by by jonobr1, but there are numerous other engines to choose from. If I get the urge, I may swap it out for one that does continuous collision detection. This would help layouts squeeze correctly in response to other nodes, but would require a better abstraction around the current physics engine.

All the DOM nodes mentioned in a selector, or a declaration, are lazily assigned a particle group, containing one particle for each side (top, right, bottom, left) of a box. If the node is only mentioned inside a declaration, the particles are fixed in position, relative to the DOM node. This allows nodes to be used as anchors, without taking them out of the normal document flow. If the node is mentioned in a selector, the node is taken out of the document flow (absolute positioning) and given internal springs connecting each edge particle in a diamond pattern (top to right, right to bottom, bottom to left, left to top). This allows the particles, and thus the node, to flex in response to external springs. It would be interesting to conditionally disable those internal springs to provide partially-rigid boxes. But, that is not currently in the code base.

Originally, I kept the physics animation, of the springs flexing, as the system sought equilibrium. This behavior was fun to watch, but it resulted in terrible performance for document layout. So, now, it runs a fixed number of steps in time (500) without updating the DOM, and repeating as necessary to reach equilibrium. It might be nice to be able to conditionally re-enable the animation, as a way to assist debugging complex layouts, but that is not yet a priority.

After building this system, I think I now have a better understanding of the complexities around document layout. The current implementation is not much more than a proof-of-concept. To make it usable would require adding rigid connections, one-dimensional springs, minimum and maximum spring lengths, layers, cross-layer connections, shorthand declaration syntax, better performance, and more. So, for right now, it is just a neat proof-of-concept.

Hangout Fishbowl

Summary: I built an out-of-band invite tool, for Google’s Hangout On Air, based on the Fishbowl discussion format.

Around the beginning of January, I wandered into an online book club utilizing Google Hangouts On Air. The normal attendance was greater than the Google Hangout limit of ten people, so they turned on Hangouts On Air for the people who couldn’t get into the discussion. They allocated the nine available slots to first nine to join the Hangout. The rest were left to watch, and chat, amongst themselves, as the Hangout chat and viewer chat are separate. There was always shuffling to get into the Hangout, and a percentage of the group was always left out.

I realized, after some thought, there is a discussion format that allows total group participation and restricts the number of people speaking at any one time. The Fishbowl conversation format could be mapped onto a Hangout On Air. Every Open Spaces conference i’ve attended has featured a Fishbowl demonstration, but I had never found a use for it. Being optimized for Google+ integration, the Hangout invite system would not work smoothly for swapping in members of the audience dynamically. So, I built the Hangout Fishbowl. (The icon needs as much work as everything else.)

The application is built around two interfaces, a custom site for “viewers” and a Hangout extension for the Hangout On Air broadcaster. This allows a viewer to sign in, with Google+, to the custom site and be seen by the broadcaster, directly invited by the broadcaster, and request an invite to the active Hangout. It is designed to be realtime, so there are no emails, Google+ notifications, or privately shared posts. The broadcaster clicks a link, the viewer gets a popup, and the viewer joins the conversation.

Behind the scenes, the link between the viewer site and the Hangout extension is maintained by a simple Node.js, Socket.IO, and Redis backend.

Currently, the Hangout Fishbowl MVP is a failure. No groups are using it, and the friction involved with using it, on top of Google+ events and Hangouts, is still greater than manually adding people. Perhaps, in a few weeks, I will cycle back to it and iterate on the idea.

The Role of Web Browsers

I found an old blog post from a greggles. I don't know who he is, or what he does, but he has a good point. The web application inside the browser is ideal for simple applications, but starts to suffer with higher complexities. Now, you could argue, any number of client side frameworks(AIR, Silverlight 2, Gears, etc) would solve this problem, but it still raises a question on the role of web browsers as a whole.

History Lesson:
The web browser was designed as a document viewer for files on a remote server. Every browser and standard was built to support that. With time, people grew tired of bread and water. So, now we have a "rich" ecosystem of web applications hosted at every point on the globe.

Analysis:
If you generalize enough, the browser, as it stands today, is a platform for developers to write applications that are compatible with multiple OSes, have built in deployment, change management, and sandboxing,
and are ubiquitous. As a programmer, I know all the features listed are surmountable with existing programming techniques and focused effort.

My Question:
Should the web browser continue to take on this role as programming platform?

My Conclusion:
The logical path is to have the web browser evolve into a pure data format viewer component and run applications inside an isolated virtual machine. With an automated system for synchronizing code and data, all the points from above can be solved while allowing for the full use of libraries, tools, and languages available to system programmers.

Now I just have to figure out how to make it easy to use and build it for free.

[Edit] (2008.07.20) I just read the wikipedia entry for application virtualization expressing a better point. Oops. Next time I will think about researching something first.

3D Printing

I like the idea of 3D printers. You have a device that can repeatable produce low volume, highly customizable items. This won't change the Henry Ford assembly line approach. The assembly line is great at producing large quantities of exact copies.

So, it stands to reason the best initial application for 3D printing would be clothing. Clothing has very high variety (style, color, shape, size, etc), and thus low volume. (With the assumption that the current size system is a generalization to help mass production.)

Use Case:
You walk into a store full of samples, and find something you like. Step into the 3D scanner for measurements (already exists, and in limited use). The printer then prints a tailored shirt, shorts, etc.

The new "Old Navy" would maintain its standing by using different materials, machines, designs, and public image. Thus duplicating the current model.

The scanner would not be required for clothing production, you could save your last scan and provide it to the store.

It could also be applied to online shopping. You order a pattern and take it to be printed at a store's printer. Of course, you would suddenly get piracy and DRM problems just like other industries that cannot cope without exclusivity.