How Twitter is Destroying the Web.

Where did things go so wrong?

Let me reassure you for a second: I have no problem with micro-blogging and I'm not afraid usage of URL shorteners (like bit.ly) - which have grown in prevalence because of the service - will lead to some dead URL graveyard. I take issue with something much bigger then that. The fact that because of Twitter's position as a relatively respected and highly visible technology company it has been able to bring web development practices back an entire decade, removing so many hard fought for gains.

Looking Back

Most web developers remember when using tables to layout a webpage was common practice. When it was encouraged as innovative instead of frowned upon. And at the time there seemed to be many good reasons for this:

• Tables act as a grid which elements are then placed upon. This works well with designing practices that originated way before the web - and are used heavily for print based publications.
• Tables are generally very easy for developers to wrap their heads around - after all it's just columns and rows all the way around.
• Tables make it easy to create layouts that respond to window size changes with variable column width.
• Tables tags are nice and short (tr, td).
• In the end tables became prevalent initially, because they reduced design and development time when creating a website.

What Changed?

The sites that used tables. And they changed often. Which quickly highlighted the biggest and most obvious problem with the table driven approach. When your site design changes (which any successful one will, and most will multiple times before ever even being released) you quickly find out that the savings you gained initially by putting your site in tables are quickly eroded. Seemingly simple visual changes often required massive changes throughout the entire HTML DOM structure. Which web developers then almost unanimously agreed is just what happens when you intermix structure with content.

Of course, this wasn't the only issue. Using tables makes it harder for HTML parsers and web indexers to determine what each web element is meant to represent, reducing interoperability and accessibility. The hate of tables became so unanimous among web developers it encouraged the creation of sites such as: http://shouldiusetablesforlayout.com/.

So a new paradigm was adopted and widely encouraged. One that respected the separation between content and visual layout. The Semantic Web. When following this approach developers would keep the semantic definition of their content in the HTML document with the design being cleanly separated into a CSS file. This had several advantages:

• It made it easy to make changes to the visual design of a page without ever having to touch the HTML.
• It made it easy for search engine indexers and accessibility tools to correctly parse the data (as without layout specific elements, it's meaning remained clear and concise)
• It encouraged developers to give logical CSS class names to the various sections of their page, making it easier for web scrapers to parse.
• In the end it took a little more work initially, but paid for itself many times over during the life-cycle of a website.

Things where looking up for the web as competent web developers everywhere had standardized on this approach and reduced the cost of inevitable changes. As a wonderful side-effect the usefulness of the HTML documents themselves where greatly improved - as they could very safely be used for more then just displaying to a web browser.

What Went Wrong?

Developers at Twitter realized developers everywhere were constantly creating the same styles (particularly for grid based layouts) over and over again. Certainly this wasn't optimal. So they did what several other companies before them had done and created a framework for foundational CSS with a grid-based layout system at its core. What made Twitter's framework unique is that competent developers took notice. Twitter's status as a hot technology start-up, along side Bootstrap's usage of another trending technology (less) gave developers confidence that bootstrap was not something to ignore. As such it's adoption become nothing short of astonishing.

There is, however, a major problem with Twitters Bootstrap framework. Along side its fancy widgets, responsive grid layout, and decent default styles - there is an unexpected feature: A return to all the problems that came with tables. A complete rejection of the agreed upon separation between semantic content and visual design. While it is very doubtful it was done intentionally, Twitter has done more harm to the goal of a semantic web then any other tech company in modern history.

What Do You Mean!?!!??

Bootstrap has given us back td colspan=2 as span class=span2. It's no better then the old table syntax and comes with all of its disadvantages. Want to change from an icon layout to a list layout? You have to change the markup. Want to change from a 2 col grid to a 4 col grid? Again, you must dig into your HTML document to make changes. So many competent web developers have somehow been fooled into thinking that Bootstrap is somehow different and have started using Bootstrap's structural classes instead of logical semantic names.

Sure you can use Less or Sass to inject the grid into semantic class names. Bootstrap's documentation however does not encourage this method of use, and instead repeatedly demonstrates classes intermixed with HTML. As such, this is the method that almost all developers use - and the one that any bootstrap based plugin will use as well. If Bootstrap was serious about maintainable web design it wouldn't expose these structurally named classes at all.

Courtesy of Twitter, we now have the table (the most infamous html element) back in wide spread use once again. Only it now has a new name: The Bootstrap Responsive Grid.