<a href="/foo/bar/">this is a block of selected text</a>

This is the normal behavior of TextMate which is fine, but I’d like some extra attributes in the anchor tag to give me options. When you ? (tab) out the cursor will be placed outside the end of the anchor bracket. What I’d like to do is give myself the freedom to edit the generated anchor URL, and edit or delete additional attributes. You could, of course just backspace into the anchor code and add these manually, but why? You have the power to customize your workflow with TextMate! To do this, let’s look at the Bundle Editor.Under the Hyperlink Helper context you will find many commands, one of which is Wrap Word / Selection as Link. Beneath the various commands in the list are Preference types, which will vary between Markdown, Textile, DokuWiki, and HTML. We’re going to customize the HTML preference. The default structure of the Ruby code which handles the HTML snippet looks like this:

{ shellVariables = (
  { name = 'TM_LINK_FORMAT';
    value = '<a href="<%= e_sn url %>"<%= " title="\${1:#{e_sn title}}"" if defined? title %>><%= e_sn input %></a>';
  },
  );
}

What basically happens here is that TextMate will evaluate any text snippet in the clipboard and fill out the URL area if possible. However, if nothing plausible is available then the default behavior is to insert some generic URL with a generic title. I’m going to change this behavior to add some niceties like an optional CSS class, title atrribute, and a nasty target attribute (yep, that’s probably taboo for some XHTML fascists but external jumpoff links are a fact of life. Maybe I’ll revisit a solution later). In addition, I’ll customize the snippet to give me tab triggers for each attribute and allow for editing or deletion of each. Inside the Bundle Editor, replace the value of TM_LINK_FORMAT with the following (note the difference):

{ shellVariables = (
  { name = 'TM_LINK_FORMAT';
    value = '<a href="<%= "${1:#{e_sn url}}" %>"${2: title="${3:< %= e_sn input %>}"}${4: target="${5:_blank/_parent/_self/_top/windowname}"}><%= e_sn input %></a>';
  },
  );
}

Please note that the second line of the value should actually be appended immediately to the end of the first line with no space but because <pre><code> doesn’t render very well here (my failures in CSS) I had to break it up.Okay what the heck does this do? Alright, I’ll get to the point. If you manage to customize the bundle correctly without errors, you will get something like this when you use Wrap Word / Selection as Link:

  <a href="http://some-site.com/" title="this is a block of selected text">target="_blank/_parent/_self/_top/windowname">this is a block of selected text</a>

The URL will be selected, which gives you the chance to edit the link (most internal links need editing anyway). If you hit (tab) then it will select the entire title attribute. You then can decide if you wish to delete it or keep it. Hitting (tab) will select the contents of the title attribute for editing, which defaults to the text contained in your initial selection. Using the (tab) key further will let you delete or edit the target attribute. Note that it gives you a list of valid options, which you will have to type yourself.I'm sure by studying the modification I made, you may also learn how to customize other snippets found within TextMate. If you think you royally screwed up, don't panic. Search the Finder for your ~/Library/Application Support/TextMate folder. Inside you will find Bundles, which will contain a file that corresponds to the Bundle you modified. If you trash the respective bundle file and relaunch TextMate, it will revert the Bundle back to its built-in defaults. Have fun! Share This

read more | digg story

Don’t get me wrong, these GUI apps are really good at their basic duty, which is to crank out HTML. However, beyond that they’re disastrous when it comes to JavaScript and CSS. One of my old websites utilized an image mouseover function that was added by Adobe GoLive. The basic Javascript function that was bolted on by the app was over 103 lines of code! A mouseover can be done with two lines of CSS!

GUI apps like Dreamweaver are fine for a web developer to do basic checking of bracket matching and layout preview. Even then, a lot of CSS layouts don’t preview correctly and you have to resort to using your web browser. Thus, the only real benefit of today’s GUI editors is:

• Layout preview
• Site template management

Beyond that, a non-techy web designer is better off using something like iWeb which is completely GUI driven and cranks out surprisingly valid XHTML. Once you get into serious development with a team, however, you really need to learn how to code and break down your design with CSS. Otherwise, you’re just making it difficult to interface with your programming peers.

GUI apps don’t take well at all with the point-and-click editing that most people do, and result in some insanely botched, if not laughingly valid code. Below are some hilarious examples of what these apps spew out.

Pretty silly:
10% discount in the bar. Excludes alcohol, tax and tip.

Nested font tags, something GUIs are notorious for:

<p><font face="Verdana, Arial, Helvetica"></font><font SIZE="4">
</font><font face="Verdana, Arial, Helvetica"></font><font SIZE="4">
A great place to see.</font></p>

The worst of all! Redundant, nested font tags, links to local Microsoft Windows paths (won’t even work on the Internet), inconsistent inline font style usage, spaces in URLs, AAAAAAUGH!

<p><font color="#FF0000">
<font color="#FF0000"><font color="a32f22" size="3">
Instructors</font><font color="#000099"><br /> </font>
</font></font><font color="#000000" size="1">
Our instructors are professionals. Members of the
<font color="005977" size="1">team</font>
 work well together.</font></p>

…AAAAAAAAAAAAAUUUUUUGGH!