Tumblr

Moved to tumblr: http://urlencode.tumblr.com/

Restoring Browser Functions to Clickable DIVs Without Javascript

Occasionally the situation comes up in web development where you have a highly styled tag such as
<div> or <li> that you want to make clickable.  This often happens when you have a list of items in which you want to make the entire item clickble instead of just the title for example.  The standard fare for doing so is to set { cursor: pointer; } with CSS then to bind the .click event to the tag (in jQuery as so)....

$('#myDivTag').click(function() {
    // your code here
});

Don't get me wrong -- this does work.  However, in doing this what you loose is the standard functionality that most viewers are used to; things like middle clicking to open in a new tab, right-click to copy URL address, and so on.  There is also the lag between when the page renders visibly to the user but the javascript hasn't downloaded and $(document).ready hasn't yet fired.  In this case the tag will not be clickable but the mouse cursor will indicate that it should be.

I've been dealing with this more so lately and there are a couple of ways to solve this problem.

The first is to wrap the <div> (or li or whatever else) tag in an anchor tag <a> and set that anchor tag to { display: block; }.

<style type="text/css">
   #myDivWrapper { display: block; }
   #myDiv {  }
</style>

<a id="myDivWrapper">
    <div id="myDiv">
       ... content ...
    </div>
</a>

By wrapping the div tag in an anchor you've restored the default functionality viewers are used to with a clickable item.  This works in most browsers but for the most part things like <div> and <li> are not allowed inside of an anchor tag per HTML language specifications.  In a sense in doing something like this you are rolling the dice that the next version of IE9 strict mode won't render when it hits this.

It also feels kind of  weird, because all of the styling that was on #myDiv, things like height, width, float, etc., now need to be applied to the anchor tag instead.  And no one likes wrappers. They just clutter things up.

The 2nd way to solve this problem which I've started using lately is to have an absolutely positioned anchor overlay the area of the div.  Consider the following...

<style type="text/css">
    #myDiv { position: relative; }
    a.clickable-overlay {
        position: absolute;
        top: 0;
        left: 0;
        height: 100%;
        width: 100%;
        z-index: 1;
        display: block;
        background-color: transparent;
    }
</style>

<div id="myDiv">
    ... content ...
    <a class="clickable-overlay" href="#wherever"></a>
</div>

Here's what's happening:  At the end of the <div> (or li or whatever) we're adding an anchor tag.  The parent div is set to { position: relative }, and the anchor tag to { position: absolute; }.  If you're not familiar with position absolute you're missing out.  The way it is designed to work is that any element positioned absolutely is done so in relation to it's parent (or any parent's parent) that is positioned either relatively or absolutely.  What this means is that in setting our <div> tag to position: relative the anchor tag with position absolute will be positioned relative to the div.  Top 0 and left 0 will be the top left of the div,  and height 100%, width 100% will cause the anchor to fill out the area of the div.

The result is that we are left with a transparent anchor tag that completely overlays the area of the div, providing the default clickable behavior users expect.  The last CSS trick to making this work is to set z-index to 1, forcing the browser to always render the anchor tag over whatever content is in the div.

The positives to this method are that 1. we restore the expected clickable behavior without javascript (meaning it also works as soon as that markup is rendered and not when $(document).ready is fired) and 2. we're using correct HTML syntax.

I should point out there is a downside to this method, in that because the anchor overlays the div, the contents of the div are no longer selectable or clickable.  Depending on your application this may be negligible.

Top 10 Programming T-Shirts That Don't Make Sense

mind.location = unknown
http://www.zazzle.com/javascript_mind_tshirt-235892961444457742
I wonder what the value of the variable unknown is?

import_soul
http://www.zazzle.com/import_soul_tshirt-235715645595867505

What is import_soul?  It's written as a keyword.  If it were a function it should be import_soul(), however the keywords for this shirt include "python" which makes me thinking they meant import soul.

Function Check_Drunk()

http://www.zazzle.com/function_check_drunk_tshirt-235954739548677347

Where do I begin with this one... drink is treated as a global variable but never declared globally.  Then there's the awesome conditional if "bra = true" which will always return true because a single = is assignment not evaluation.  Lastly, none of the functions are ever called, they're just declarations of.

Programmers Cool Club

http://www.zazzle.com/cool_programmers_club_tshirt-235068746346060145

No comment needed.

.ninja { color: black; }

http://www.zazzle.com/css_ninja_style_class_tshirt-235091799113607617

This one's amusing and almost worth getting, but the behavior of visibility: hidden; is such that it keeps screen space allocated for the element and simply does not render it.  I personally believe a true ninja would { display: none; }.

Geek Power

http://www.zazzle.com/geek_power_tshirt-235232870665206831

No geek would ever intentionally rip the cord to their keyboard like that

Computers are Only Human

http://www.zazzle.com/computers_are_only_human_tshirt-235670270460766159

Apparently I didn't get that memo.

SELECT TOP 25

http://www.zazzle.com/the_best_sql_query_ever_tshirt-235031072069340726

Aside from using the vendor-specific "TOP 25" (MS SQL), the comment at the bottom brings to light the poor execution of this SQL:  It should be sorted DESCENDING

Do You Speak Code

http://www.zazzle.com/do_you_speak_code_tshirt-235290525576102199

There's No Crying in Programming

http://www.zazzle.com/no_crying_in_programming_card-137314447034339159

Python Templating For the Web (Random Ideas)

Well it's past midnight and I'm musing about web templating in Python for Tornado or AppEngine.   The thing about most Python templating engines that I notice is...

• There's kind of an obsession with being agnostic about everything.  You can render JSON and XML and whatever else you want with our engine!  When is someone just going to make a really awesome templating engine for the web and not try to be everything to everyone?
  
• The value in a template engine to me is how easy it is to allow the template to include logic that's independent of the controller that's generating it.  For example, you might want a server-side ad manager on every page, but you don't necessarily want to put the code for that in every controller.  Solution?  Some engines call it modules, some call it template tags, but whatever the name there is some type of logic that's independent of the controller.  The problem is that most of these pieces of independent logic are needlessly complicated.  (side note: Django has gotten a bit better about this since I first used it two years ago).
  
• Maybe some better support for lazy-loaded values which are available for all templates... things like static URL, etc.

So it's late and I'm thinking, what if there was a template engine, and I mean one specifically for the web, which represented an HTML document more so as a Python class.  Every root element or element with an ID is a property of the document.  Tags can interact with each other... Maybe this is turning out to be too much of a DOM implementation in Python.  Maybe this is a bad idea.  Or maybe I should try coding up a prototype just to see what it's like.

But it's not quite a DOM.  The DOM is concerned with specific structure, where as we're only concerned with a loose abstract structure.  It doesn't matter of the area where scripts are printed too is in the or right above , what's important is that there is a scripts area which sub-modules can access.

Instead of {% extends "some_html_file.html %}, it could be {% extends templates.master %} where templates.master is a python module.


(15 minutes later)... you know it kind of sounds like I'm trying to re-invent ASP.NET WebForms...

Komodo Edit

I like Komodo Edit. It's simple but at the same time functional enough to be useful. It also does code completion, supports Python, and is cross-platform. (Side note: If only it supported Scala, then it would be like the **aaaaahhh** perfect editor).

I've had this idea kicking around for a while of starting a Komodo color themes/schemes website. The idea is simple. You create a theme, then share it on the site. Other people can download it or Vote/"Like" it. Most-liked themes bubble to the top. I'm thinking of a simple architecture using Google App Engine (python) + Tornado. We'll see.

In the mean time I sure did waste like 2 hours of what should have been productive programming time putting together a bunch of themes for Komodo Edit. Here are some previews of them...

"Heart Dry"

"Fancy Terminal"

 "Happy Day" (currently used)

 "Monokai"

"Phoenix"

"Transformers"

"Work Scheme"

Formatting Console Output in Scala

So it's midnight and I'm programming Scala (heh).  I'm actually starting to be able to write little scripts in Scala.  Here's a quick one that I put together, inspired by Chapter 3 of "Programming Scala" which reads a source code file and formats the file to the screen with line numbers.



I tried to be as functional as possible.  The "formatSourceLine" I felt was getting close to the concept, using recursion, immutable values, and always returning a value (avoiding the side effect of printing from within the function).

The actual output from this script is:

D:\Development\Scala>scala file.scala file.scala

    1 | import scala.io.Source
    2 |
    3 | if (args.length > 0) {
    4 |
    5 |     def formatSourcePrefix(line: Int, suffix: String, max: Int = 5):
    6 |         var prefix: String = ""
    7 |         for (i <- 1 to (max - line.toString.length))
    8 |             prefix += " "
    9 |         prefix + line.toString + suffix
   10 |     }
   11 |
   12 |     def formatSourceLine(lines: List[String], line: Int = 1, 
   13 |         val out = output + formatSourcePrefix(line, " | ")
   14 |         if (lines.length > 1)
   15 |             formatSourceLine(lines.tail, line + 1, out)
   16 |         else
   17 |             out
   18 |     }
   19 |
   20 |     // Read file from disk
   21 |     val lines = Source.fromPath(args(0)).getLines().toList
   22 |
   23 |     // Print results to screen
   24 |     println
   25 |     print(formatSourceLine(lines))
   26 |
   27 | }
   28 | else {
   29 |     // Print out proper syntax
   30 |     Console.err.println
   31 |     Console.err.println("scala file.scala [filename]")
   32 | }

The Difference a Space Can Make

How can you print the string value of a floating point value of 5 in Scala?

scala> 5.toString  // Wrong!
res16: java.lang.String = 5

scala> 5. toString
res17: java.lang.String = 5.0

In the first line scala counts the "." as syntax for "toString method of Integer 5".  The second line uses the "toString" method in infix notation, applying the toString method against the floating point value of 5.0.

Here's another example where a space can make a big difference in type:

scala> 4.+(1)
res20: Double = 5.0

scala> 4 .+(1)
res21: Int = 5