40,000 GML Tags, by Theo Watson and F.A.T. Lab

GML, or Graffiti Markup Language, is an open file format designed to store graffiti motion data.  It’s been used in projects like the EyeWriter, Graffiti Analysis, DustTag, and Laser Tag, all of which have been uploading GML tags to000000book.com, a site/database where graffiti writers are encouraged to share tags and computer programmers are invited to create new visualizations based on the resulting data.  The project aims to bring together two seemingly disparate communities that share an interest hacking systems, whether through code or in the city.

Currently, there are over 40,000 tags in the #000000book database.  For the F.A.T. GOLD exhibition currently on display at Eyebeam, artist Theo Watson redrew these tags back into physical space.  The cascading display showcases tags in chronological order, from the very first ones drawn by Tempt1, to the most recent captured by a variety of GML-powered apps.


Changing YARD's Markup Format to Markdown or Textile.

YARD is amazing. It makes it fun to document code. And it is well known that documenting your code not only makes your code better but it makes you a better programmer.

The saying goes, you don’t really know something until you’ve tried to teach it. Trying to “teach” others (and future you) about your methods through documentation is a great exercise.

Configuring the Markup for YARD

By default, YARD uses RDoc as the default markup language. This is to help the transition of RDoc projects over to YARD. But for new project, I prefer Markdown (GitHub uses a derivative of this) or even Textile (used in 37signals' apps). 

It was difficult to find any documentation on this so I thought I would post a quick entry here for people doing a search.

  1. Create a .yardopts file in your project’s root directory.
  2. In .yardopts put in:
  3. Make sure you have the ‘redcarpet’ gem installed. I would add this to your gemfile under the development and testing groups: 
  4. Run your server and it will automatically append options in the .yardopts file.
Other YARD Options

Again, it took a little while to figure out how to find all the options I could pass into the .yardopts file so here is the command for that: 

yardoc --help

If you’re using Github Flavoured Markdown (GFM), which is the default when you are using RedCarpet as the Markup provider and Markdown as the Markup language, you wil notice that hard-line breaks are not respected. This is done by Loren Segal because when text editors typically have a word wrap set at 80 or 100 “columns” so when you’re writing long paragraphs in your documentation, you naturally use hard-breaks and this would cause the resulting documentation to look a little off. I’ve been using
when I really want a hard break.



How to add a reblog link to your Tumblr posts

Here is a gift from me to you. This is awesome. You know I’ve seen this on a limited number of blogs so I decided to do a little searching for this and voila! I found this theme tag on forum post linked from Tumblr. I made a little example above to share in context.

This also irritates me, because Tumblr is so piss poor to providing a complete documentation for their theme tags. They just recently cleaned it up a bit, but I could see if there was some guy new to coding for Tumblr looked at that library, they would be a little irked at the lack of description and examples a lot of the tags have.

Just sayin’. Please hire someone dedicated to properly maintaining the docs.

Zen Coding is an editor plugin for high-speed HTML, XML, XSL (or any other structured code format) coding and editing. The core of this plugin is a powerful abbreviation engine which allows you to expand expressions—similar to CSS selectors—into HTML code. For example:


…can be expanded into:

<div >
        <div class="logo"></div>
        <ul >
                <li><a href=""></a></li>
                <li><a href=""></a></li>
                <li><a href=""></a></li>
                <li><a href=""></a></li>
                <li><a href=""></a></li>
I feel stupidly accomplished (=

On my theme, the line height is, short-sightedly, too small so on titles that exceed one line the background color of the second line covers up the text on the first line.

SOOOOO, I went to “Customize” and under the “Theme” tab found the class they assigned to the title for each post, “ttl” and added the following rule within the “Advanced” tab under “custom CSS”:

.ttl {
line-height: 1.6;

that’s it. Not much, but I was able to read the alien markup of the tumblr theme syntax to understand it. I’m actually learning this stuff as it turns out.

Next step, make my own theme!!


Envisioning future forms

Here we go again. Advanced websites need advanced forms.

I mean… let’s talk about digital products in the Web 2.0 era. You want to be successful on a crowded market, so you need to stand up with a winning product. You decide to pay a digital products design firm that, if good enough, will come to you with a rocking design.

You then call your developer just to hear the usual, painful AAARGH!
… yes, he discovered your custom forms in prototypes.

Here we go, coding custom JS widgets, masking your ugly radiobutton behind sexy glittering icons, creating colorful image-based dropdowns and so on.
What’s wrong with this? Well, the form itself!

I mean… we’re making web since 90s and we’re still stuck with the concept of form element! HTML5 brought us sliders, date-pickers and such, but these still are form elements. They have a shape (different ones on different browsers, by the way) and are thought for a specific function and user-interaction. They have already been designed!
So what’s the point in hiring a design firm if the most important part of a modern website (namely interaction with user) has already been designed?

They always re-design them, indeed!
Try to make Drupal modules understand that you need something less ugly. Try with Symfony or Zend form components or CodeIgniter helpers…

I think it’s time for HTML to move from an element-based mindset to a behavior-based one. What if divs could be filled with text and sent via a click on an img?
What if I could check some spans and include them into a collection of values to be sent as an array to underlying application on the server, (say) sliding another image to the right?
What if I could add selected, submittable, editable, and such states to every visual element on a page? And if I could add behaviors to them that mimic what we know about form-based interactions? And what about defining more behaviors and states so they can be processed by JS callbacks?

Yes I know, we could already do all of this with JS, but:

  • Tell PS guys in design firm to code all of that in templates they send you…
  • Interaction design does not belong to JS domain, but should be inherent to elements themselves, so you could get clues on interaction logic reading the markup.
  • This would create a semantics for user-interaction. Form elements provide some but it’s an aged concept, missing events, behaviors and giving no clue about consequences of user actions.
  • Customizing forms it’s a loadshit of work! :P Every time!

Mmmh… Giving a second thought I realize this on-the-fly rant could be inspiring for a JS based stub of the concept.

Would anyone be interested in such a thing?

UPDATE: it seems I was not so out of track with this blurb. I obviously didn’t find the time to move a finger in this direction, but Google did. The concept described is exactly the base behind AngularJS.
Enjoy this revolutionary approach. Thanks again, BigG.

On Muse and Markup

After Monday’s headlines on Adobe Muse, I decided to check out the free beta for myself. For those of you who may not know, Muse is a new tool from Adobe to “design and publish HTML websites without writing code.” The interface will be quite familiar to those of you who have used Flash, Fireworks, Indesign, etc.

So let me make sure I got this right:

design and publish HTML websites without writing code

Herein lies the problem with WYSIWYG editors of all shapes and sizes. The rendered web page is just the tip of the iceberg. Without a rudimentary understanding of the way the code works, it’s harder to grasp the how, when and why of the rendered HTML document.

Yes it’s true that many print design principles are easily, and quite effectively, applied to web design, but the differences lie in their respective implementations. There’s no scenario in which a newspaper column would need to respond to a change in the size of the paper itself. Print design is static. Web design is not…

There’s a reason that fantastically talented individuals, like Harry Williams of CSS Wizardry, spend time writing on the intricacies of clean and semantic HTML:

markup is important

Cleaner markup means faster load times and a readable document for humans outside the confines of the browser window. I’m not saying a write perfect HTML, not by a longshot, but I’m damn sure it looks better than this:

<ul class="MenuBar widget_invisible colelem" ><!-- row -->
 <li class="MenuItemContainer grpelem" ><!-- vertical box -->
  <div class="pointer_cursor MenuItem MenuItemWithSubMenu MuseMenuActive colelem" ><!-- horizontal box -->
   <a class="block" href="index.html"></a>
   <div class="MenuItemLabel NoWrap grpelem" ><!-- content -->
    <p >Home</p>
    <div class="wrap"></div>
   <div class="wrap"></div>
 <li class="MenuItemContainer grpelem" ><!-- vertical box -->
  <div class="pointer_cursor MenuItem MenuItemWithSubMenu colelem" ><!-- horizontal box -->
   <a class="block" href="portfolio.html"></a>
   <div class="MenuItemLabel NoWrap grpelem" ><!-- content -->
    <p >Portfolio</p>
    <div class="wrap"></div>
   <div class="wrap"></div>
 <li class="MenuItemContainer grpelem" ><!-- vertical box -->
  <div class="pointer_cursor MenuItem MenuItemWithSubMenu colelem" ><!-- horizontal box -->
   <a class="block" href="contact.html"></a>
   <div class="MenuItemLabel NoWrap grpelem" ><!-- content -->
    <p >Contact</p>
    <div class="wrap"></div>
   <div class="wrap"></div>
 <li class="MenuItemContainer grpelem" ><!-- vertical box -->
  <div class="pointer_cursor MenuItem MenuItemWithSubMenu colelem" ><!-- horizontal box -->
   <a class="block" href="blog.html"></a>
   <div class="MenuItemLabel NoWrap grpelem" ><!-- content -->
    <p >Blog</p>
    <div class="wrap"></div>
   <div class="wrap"></div>
 <li class="wrap"></li>

That’s Muse output of a simple, 4-item navigation menu. Sure it works… but I can accomplish the same thing with a fraction of the code:

<ul class="MenuBar">
  <li><a href="#home">Home</a></li>
  <li><a href="#portfolio">Portfolio</a></li>
  <li><a href="#contact">Contact</a></li>
  <li><a href="#blog">Blog</a></li>

It took Muse 43 lines to do 6 lines of work. I think the result speaks for itself. If your objective is a professional HTML websites, you will not reach it without writing markup. No matter how simple the site.

Desktop programs don’t make good websites, us web folk make good websites.

7 Lovely Things About HTML5 Markup

HTML5 — the latest generation of the Web’s markup language — has been creating quite a stir over the last couple of years, as more and more browsers implement the latest and greatest HTML5 features. HTML5 really hit the mainstream in 2010, in part driven by Steve Jobs’ open letter, Thoughts on Flash.

HTML5 is quite a broad term, encompassing everything from the revised markup specification through to new API features such as audio, video, canvas and geolocation.

In this article I’m going to focus on the markup language itself, and look at seven reasons why I love HTML5’s markup more than HTML4’s. We’ll look at:

  • Doctypes
  • data- attributes
  • Some new and improved elements and attributes
  • More flexible linking
  • Simpler markup, and
  • Enhancements to web forms.

Ready to upgrade your markup? Let’s go!

A doctype you can actually remember


Let’s start with one of the more noticeable improvements to any HTML5 document. At last, we have a doctype declaration that’s easy to remember, and easy to write!

An HTML4 doctype:


The HTML5 doctype:

<!doctype html>

No contest really!

Author-defined attributes


In previous versions of HTML, you could only use the element attributes defined in the language, such as type, src, href, and so on. Now, in HTML5, you can also create your own attributes! The only requirement for an author-defined attribute is that it begins with the prefix “data-”.

For example:

123456789<img id="img1" src="eiffelTower.jpg" alt="Eiffel Tower"  data-country="fr"  data-imageType="thumb"  data-fullURL="/photos/large/eiffelTower.jpg"> <img id="img2" src="coliseum.jpg" alt="Coliseum"  data-country="it"  data-imageType="thumb"  data-fullURL="/photos/large/coliseum.jpg">

data- attributes have no direct effect on the appearance or behaviour of elements. Their main purpose is to let you associate arbitrary data with an element.

You can access the values of data- attributes using the DOM methods such as element.getAttribute(), just like regular attributes. You can also access all the data- attributes in an element using the new dataset DOM property, like this:

// Displays "/photos/large/eiffelTower.jpg":
alert( document.getElementById('img1').dataset.fullurl );

Currently only some WebKit browsers support the dataset property; however, Morten Barklund has created a nice jQuery plugin that adds dataset support to all browsers.

New semantic elements


HTML5 gives you lots of new semantic elements that you can use to add more meaning and structure to your markup. This lets you avoid the plague of divitis by replacing non-semantic div and span elements with more meaningful element types.

Some of my favourite HTML5 semantic elements are:

  • header and footer for page and article headers and footers respectively
  • article for encapsulating an article or blog post
  • nav for representing the site navigation
  • figure and figcaption for including figures and figure captions
  • time for representing dates and times

For example, here’s how you might mark up a blog post page:

<!doctype html><html lang="en"><head>  <title>New WonderWidget Released</title></head><body>   <nav>    <ul>      <li><a href="/">Home</a></li>      <li><a href="/archive/">Archive</a></li>      <li><a href="/about/">About</a></li>    </ul>  </nav>   <article>     <header>      <h1>New WonderWidget Released</h1>      <p><time pubdate datetime="2011-07-11"></time></p>    </header>     <p>Curabitur tortor. Pellentesque nibh. Aenean quam.    In scelerisque sem at dolor. Maecenas mattis. Sed    convallis tristique sem. Proin ut ligula vel nunc    egestas porttitor.</p>     <figure>      <img src="eiffelTower.jpg" alt="Eiffel Tower">      <figcaption>The Eiffel Tower, earlier today</figcaption>    </figure>     <footer>      <p>Posted by: Matt Doyle</p>      <p><a href="comments/">Comments</a></p>   </footer>       </article> </body></html>

Internet Explorer 8 and earlier don’t understand these new element types, which means that you can’t style them with CSS or access them in the DOM via JavaScript. To work around this, check out Remy Sharp’s HTML5 Shiv script.

Handy new attributes


HTML5 also introduces some useful new element attributes to the language. Not all browsers currently support all of these attributes, but browser support is improving all the time.

Here are some good ones:

Another nice thing about HTML5 is that it resurrects the target attribute, which lets you target iframes, open links in new windows, and so on. This attribute was deprecated in HTML4 Strict, but with HTML5 the W3C has had a change of heart and reinstated it.

Being able to wrap a link around almost anything


In older versions of HTML, a (anchor) elements were defined as inline elements and, as such, could only contain other inline elements, such as text, images and span elements. This made it difficult to wrap a link around a block-level element, such as a div containing multiple elements. You had to resort to wrapping links around the individual inline elements inside the div, or adding a JavaScript click handler to the div.

Now, in HTML5, links can contain flow content, which is an HTML5 term roughly equivalent to HTML4’s “block-level”. This means that you can happily include divs, headings, tables, and lots more inside a link. For example:

<a href="mypage.html">  <div>    <h2>Linked div</h2>    <p>Here's an entire linked div containing an h2 heading,    a paragraph, and an image!</p>    <img src="eiffelTower.jpg" alt="Eiffel Tower">  </div></a>

The only caveat is that the content inside the link must not itself be interactive — this rules out other a elements, as well as buttons, iframes, select menus, and so on.

Simplified markup


One of my favourite things about HTML5 markup is that many commonly-used snippets are now simpler and quicker to write. For example:

<!-- HTML4 --><meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <!-- HTML5 --><meta charset="utf-8">

<!-- HTML4 -->
<script type="text/javascript"> ... </script> <!-- HTML5 --><script> ... </script>
<!-- HTML4 -->
<style type="text/css"> ... </style> <!-- HTML5 --><style> ... </style>


Enhanced forms


HTML5 adds some new attributes to forms. These let you create semantically-rich form fields, and they also help to cut down on the amount of JavaScript needed for things like validation and autofocus.

My personal favourites are:

  • New, more meaningful input types: email, url, tel, number, range, date, datetime, search, and more. These serve 2 main purposes:

    1. Browsers can automatically validate the fields to make sure they contain the correct type of values. No JavaScript validation needed!
    2. Some browsers, such as Mobile Safari, can display context-aware keyboards based on the field type. For example, if the user is entering a telephone number into an <input type="tel"> field then the browser displays a telephone keypad.
  • The autofocus attribute that automatically focuses a form field of your choosing when the form first loads.
  • The placeholder attribute that lets you display placeholder text inside a field to guide the user.
  • The required attribute for making form fields required. As with the input types, this triggers automatic browser validation — the user can’t submit the form until they’ve filled in all required fields.

While HTML5 has some widely-publicised headline features such as native video, the canvas element and the geolocation API, there are also many improvements to the markup language itself that are worth a look. In this article you’ve touched on 7 things that make HTML5 markup more powerful — and nicer to write — than HTML4:

  • A much simpler doctype that’s easy to remember and type
  • data- attributes for adding arbitrary data to page elements
  • New semantically-rich elements like header, footer, article, nav, figure, figcaption and time
  • Useful new attributes such as contenteditable, spellcheck, reversed, draggable and dropzone
  • Links can now be wrapped around flow content (block-level elements)
  • Simpler markup for things like character sets, script blocks and style blocks
  • Additional form input types and attributes that add more meaning to form fields and enable auto-focusing fields, placeholders, and browser-native form validation
Metadata Monday: Microdata and Schema.org

Don’t we all need another standard or schema for web page markup? Fear not, the folks at Google, Bing and Yahoo! have collaborated on Schema.org - “to improve the web by creating a structured data markup schema supported by major search engines. On-page markup helps search engines understand the information on web pages and provide richer search results. A shared markup vocabulary makes easier for webmasters to decide on a markup schema and get the maximum benefit for their efforts.

Schema.org provides a collection of shared vocabularies webmasters can use to mark up their pages in ways that can be understood by the major search engines: Google, Microsoft, and Yahoo!

You use the schema.org vocabulary, along with the microdata format, to add information to your HTML content. While the long term goal is to support a wider range of formats, the initial focus is on Microdata. This guide will help get you up to speed with microdata and schema.org, so that you can start adding markup to your web pages.”

To me, this schema, based on RDF, is akin in simplicity to Dublin Core and a boon to those wishing to ensure their content is understood by those sometimes obtuse search engines.

iA Writer

iA Writer is magnificent! I downloaded it from the App Store yesterday and haven’t looked back. It’s such a compelling application, that I feel very motivated to start writing a book, it brings back the typewriter-esqué feel - the amount of focus you have on your content. I’m actually using iAW right now, to type this post - that’s since I’ve changed Tumblr to use Markdown. Oh didn’t I mention that? iA Writer is a Markdown editor. Markdown was created by John Gruber and has been exploding around the internet ever since; it’s that popular, Tumblr supports it ;)

I think the reason I find it so awesome is partly down to how I love minimalism and things being simple. Both of which, iAW does absolutely 110% better than anything else near it’s playing field.

iA Writer isn’t free, but it’s not expensive. For $9.99, it’s totally worth it. I’d actually pay the original amount of $17.99 because it’s so damn amazing.

One of the best modes (I think) is ⌘ + D which puts iAW in a kind of, further distraction free mode than OSX Lion has just recently introduced. It focuses the current active sentence, fading out anything before or after it. It makes it even more easier to see where you’re at in your piece of work.

Another feature that I really like is the Automatic Markdown parsing, which formats your text to the expected Markdown output as you type. This allows you to continue reading your work, without having to parse through consciously if it’s a list, bold, emphasis etc etc. Apart from text formatting, iAW also displays lists, numbered and bulleted and block quotes!

Unfortunately however, iAW doesn’t support code blocks - which is a great shame to me, since I write a lot of code samples for work projects in Markdown formats, also for GitHub and StackOverFlow. I’ve suggested it via Twitter, so we’ll see what happens in the near future ;)

Images and links are also not supported, however this doesn’t bother me so much as I feel that it would ruin the minimalistic feel that iAW has throughout.

I’d post some images, however I’d rather direct you towards their website and get on with buying it! Go forth!


Habt ihr schon mal einen von diesen ach so tollen neuen Google-Plus-Eins-Button-Dingern irgendwo eingebaut? Nein? Fast schon schade.

So ein Teil ist ja im Endeffekt nur so ein schmaler iFrame, in dem halt diese kleine Grafik mit der Zahl daneben lebt. Aber das wäre ja mal viel zu einfach, das dann auch so stumpf einbauen zu lassen. Als Google muss da ja prompt mal wieder alles neu erfinden und mindestens zehn Regeln brechen, damit das auch jedem Spaß macht, der so ein Stück Kode mal einbauen darf.

Fängt damit an, wie man dem Gerät seine Sprachpräferenz mitzuteilen hat. Das geht so:

<script type="text/javascript" src="https://apis.google.com/js/plusone.js">{lang: 'de'}</script>

Hübsch, oder? Und natürlich vollkommen gegen HTML5, wo nämlich so ein Script-Tag mit src nur noch Kommentare enthalten darf. Supergeil.

Ich mein, wozu muss ich diesem Dingen überhaupt sagen, was für ne Sprache ich da sehen will? Im Normalfall steht da “+1” und ne Zahl. Zahlen waren, das letzte mal als ich nachgesehen hab, noch international anerkannt. Aber gut, mir ja egal. Wenn ich da nix reinschreibe, ist es halt englisch.

Weiter geht’s. Weil nur einmal diese schöne HTML5-Spezifikation zu verletzten ist ja nicht genug. der Button selber sieht nämlich so aus: <g:plusone></g:plusone>. Ohne Namespace, ohne Inhalt, nicht selbstschließend. Jeder, der schon mal “XML” gelesen hat (also spätestens jetzt wirklich jeder) sollte sich spontan übergeben. Ich mein, wer kommt denn auf so einen Scheißdreck? Die Gestalt, die das da verbrochen hat, sitzt doch gerade garantiert mit seinem Trollface-T-Shirt irgendwo in Mountain View und schlürft genüsslich seinen Kaffee; weil er weiß, dass jetzt schon wieder einer ihm ein paar Minuten des Tages geopfert hat. Vielleicht hat seine Ex-Freundin auch einfach den HTML5-Validator gebaut.

Jedenfalls. Herzlichen Glückwunsch, Google. Dafür geht’s ein paar Plätze nach oben, auf meiner Hass-Liste.