Black Belt Coder

Douglas Crockford posted on his blog a list of 10 suggestions for the future of HTML. They are amazingly simple to understand and fixes some pretty annoying rules that probably made sense in design, but not so much in practice.

Some of the highlights.

• No more framesets, frames, or iframes. The security properties of these were problematic. Instead we’ll have modules.
• The default CSS content needs to be standardized. See for example http://developer.yahoo.com/yui/reset/. The browsers should have more commonality in their default styling.
• Custom HTML tags have always been allowed in HTML. In HTML 5 they become first class. CSS can be used to style custom tags.

It all comes together when read them all together, and I agree with most points. In fact, after close scrutiny the only one I don’t totally agree with is the single programming language per page argument. As Crockford is pretty adamant that ECMAScript 4 should become a separate language, only allowing one language which would be ECMAScript 3 on one page would doom 4 to banishment.

We had an opportunity to optimize our TabBar navigation component and I thought it would be a great chance to do some abstraction.

Below is the HTML the TabBar generated.


<td>

<img
border=”0“
src=”http://server/graphics/tabs/MyTabs/nav_default_cap_right.jpg“/>
</td>

I realize my HTML code example isn’t very pretty, I’ll have to go looking for a good plugin soon.

Some of the things bad about this.

• Table cells just for a graphic.
• Graphics inline with the HTML (so style is not seperated by a stylesheet)
• Javascript is embedded in the HTML so its not late bound.
• style=”cursor:pointer” on the Anchor.
• We would prefer not to use Tables at all for this control, its a list of links, so we should be using UL, LI, and A.

In our refactor we resolved the majority of these issues, with the exception being the last bullet on a table being used. The complexity of switching it to a UL was a bit more work then we could get time for in our sprint, so it gets pushed to another day.

Lets start with the roundedness of the tabs.

Hastily blown up to show them as they were only 1 pixel wide.

Because they are not fixed width, we needed the middle body of the tab to grow based on the size of the text, and then we would append the two edge images at their appropriate positions.

To do this we need 3 elements, basically a background holder for each image.


<td>
<a href=”#”>
<h3>
<span>
Home
</span>
</h3>
</a>
</td>


Yak all you want about the different tags you should use inside an anchor tag, it doesn’t matter for a technical standpoint. (Semantically I’m sure someone will have a firm reason which direction to take).

From here, you need some different css styles to apply our effects.


.TabBar {
margin:0;
clear:both;
background-color: #FFF;
}
.TabBar TD {
vertical-align: middle;
padding-left: 2px;
}
.TabBar a {
color:black;
text-decoration:none;
display:block;
background:url(tab_bg.jpg) repeat-x;
height:25px;
line-height:25px;
cursor:pointer;
}
.TabBar a H3{
display:block;
margin:0;
padding:0;
background:no-repeat url(tab_left.jpg);
vertical-align:middle;
white-space:nowrap;
}
.TabBar a span{
display:block;
padding:0 14px;
background:no-repeat url(tab_right.jpg) top right;
font-family:arial,sans-serif;
color:#333333;
vertical-align:middle;
font-size:13px;
font-weight:normal;
white-space:nowrap;
}

So our TD is wrapped in a table with class of TabBar and our styles are applied.

This should produce a tab that looks like this.

Now to give a mouse over effect, we just need to use the A:hover pseudo class to change the background of the three elements.


.TabBar a:hover{
background-image:url(hover_bg.jpg);
}
.TabBar a:hover H3{
background:no-repeat url(hover_left.jpg);
}
.TabBar a:hover span{
background:no-repeat url(hover_right.jpg) top right;
}


So when you mouse over the element, the CSS parser applies a whole new set of classes to the elements underneath, yet it also keeps the previous classes intact as well. Here is what the tab looks like on mouse over after the resulting CSS is added to the page.

No longer are we constrained to the formatting of everyone else’s horribly formatted code!

Discover the coolness of JS Beautifier

This takes poorly formatted JS and adds indentations and line breaks.

Now if someone could make a nice easy one for HTML/XML I would be set.

Now that we are becoming QA anal, testing is a huge concern moving forward on all development. In regards to UI testing is just annoying to address. Lets take a feature we all know and love, and see how you would go about getting it tested and implemented.

How about this drop down menu from Google.  How would you write a unit test that verifies that this menu will function correctly? The key things are, how do we get an environment where we can validate code events and underpinnings?
What we are going to do is create an HTML page with just the markup for the control. Then when we include our Javascript which we can then write tests that verify that it interacts with that HTML properly. We won’t end up with JSUnit tests on google.com, we won’t even have anything to do with google.com, which as an internal google developer you wouldn’t anyway. You want to make sure that your menu bar fires off its drop down correctly.

Here we’ve made just the basics of our prototype page. Nothing special except our javascript library and our CSS reset file.

Here is the our page with the prototype code now on it. Depending on what level of development googleMenu.js is at, this may actually be a functional prototype. You should be able to open up this file and show people what the code will look like in a very isolated fashion. If this is step 1 of a new feature then you should see the evolution of your feature in the browser as you implement the code for it.

Lets say the component already exists, we are just wiring up a test to validate a bug fix. At the end you have this code.

The body of my test is commented out because well, none of this exists, its air-code.

Now we have a JSUnit test page that has a duel function as a stand alone prototype page.

At the AJAX experience I had a conversation with Geoffrey McGill, one of the developers working on a JS Date library that lets you do some really sweet things. Its been in development ever since the conference, but today I noticed it was released, and I’m quite jelous that it has a much cooler website then I do.

Check it out, http://www.datejs.com

In development lately, I’ve been including the CSS Reset stylesheet from Yahoo as just a basic setup of my page. It super simple as you can just link to the one on their development site.

<link rel=“stylesheet” type=“text/css” href=“http://yui.yahooapis.com/2.3.1/build/reset/reset-min.css”>

The idea being that you shouldn’t need to write excess CSS just to eliminate different browser defaults. The browser defaults have a purpose sure, but they just aren’t needed anymore in todays day and age of CSS.

Another option to consider is Tripoli which tries to make the defaults even a bit elegant, though I haven’t used it yet so I can’t vouch for it.

So not to get on Bill’s case or anything, but why are people out there neglecting to put the location of the companies when they are advertising positions?

Such as these Netflix jobs

Or his friend Sean Kane for getlisted.com here

Or say my money management site Mint.com

I may be missing it, but I just cannot find where these companies are located and was just curious. Yet it seems like a pretty important factor into whether a person would be interested in taking your job.

Anyway, now that I’ve mentioned it hopefully the trend of neglecting the location of your home office on your website will be abandoned.

With the book from 37 signals!

Getting Real: The book by 37signals

I’m not to far into it yet, or I’d have more to say.

While reading some stuff of Bill Scott’s I found this wonderful post about a talk from the guy who wrote the aforementioned book.

He again re-iterates that you want to limit un-necessary communication, and even goes to say that meetings are evil and should be avoided.

We use JSUnit at work, and I hate its assert methods.

assertEquals(comment, val1, val2);

YUK, the comment first? Coming from a C# background, this is about as ugly as you could imagine. So for eProject I wrote this simple class to get back to the norm.

var Assert = {
“AreEqual”    : function(val1, val2, comment) { assertEquals(comment, val1, val2) },
“AreNotEqual” : function(val1, val2, comment) { assertNotEquals(comment, val1, val2) },
“Fail”        : function(comment) { fail(comment); },
“IsTrue”      : function(val1, comment) { assertTrue(comment, val1); },
“IsFalse”     : function(val1, comment) { assertFalse(comment, val1); },
“IsNull”      : function(val1, comment) { assertNull(comment, val1); },
“IsNotNull”   : function(val1, comment) { assertNotNull(comment, val1); },
“IsNaN”       : function(val1, comment) { assertNaN(comment, val1); },
“IsNotNaN”    : function(val1, comment) { assertNotNaN(comment, val1); },
“IsUndefined” : function(val1, comment) { assertUndefined(comment, val1); },
“IsNotUndefined”: function(val1, comment) { assertNotUndefined(comment, val1); }
};

If you hate it too, then by all means, feel the love of the Assert class.