Friday, August 20, 2010

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 {  }

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

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;

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

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.

Thursday, August 12, 2010

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

mind.location = unknown
I wonder what the value of the variable unknown is?


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()
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
No comment needed.

.ninja { color: black; }
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
No geek would ever intentionally rip the cord to their keyboard like that

Computers are Only Human
Apparently I didn't get that memo.

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

There's No Crying in Programming

Friday, August 6, 2010

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...

  © Blogger template 'Minimalist G' by 2008

Back to TOP