I'm a front end web developer living in San Francisco. I have been coding HTML since I was 15. I strive to be the best I can at what I do. I believe in clean and simple design as well as code. This is where I represent myself on the web. I am always looking to form relationships with other amazing people, part time or full time. contact me!
HTML 5 is the next major iteration of HTML, and I know I’m excited about it. I recently added some new HTML 5 markup into dinnermint. It was a very quick and simple change, which I believe will help clear up some of the <div> soup.
The New Tags
There are some new tags in the HTML 5 specification, that I believe will lead to more semantic code. And what I mean by that is the code says what it does. You’re no longer left wondering what those <div> tags are for, when you see a tag like <header> you know what it is for.
The Layout
There are lost of tags I could have used, like aside, audio, video. I plan on playing around with those later, but for now I set up a basic layout consisting of a header, nav, article, footer like so.
These elements behave like typical block level elements. But are more semantic, if you aren’t sure of the benefits of this check out this post I wrote on CSS class names. If you are thinking about setting up your site, you can at least use header, footer, nav. If you do setup your site, there are a few things you should know.
DOCTYPE One of my favorite new features of HTML 5. Now you don’t have to remember a long DOCTYPE when starting a page, just use <!DOCTYPE HTML> and that’s it!
HTML 4 Browsers Sigh, unfortunately not all browsers are on the same page, what you’ll need to do so these elements will be rendered like plain old block elements is below.
Add this to your stylesheet, this just reminds the browsers how to display these tags.
Add this to the Beginning of the <body> tag. This is important for IE browsers, all it is doing is creating an element in the dom for each of the html 5 tags so it doesn’t ignore them. It’s important you place this script before any html 5 tags are used, at the top of the page.
<!--[if IE]>
<script type="text/javascript">
(function(){if(!/*@cc_on!@*/0)return;
var e = "abbr,article,aside,audio,bb,canvas,datagrid,datalist,details,dialog,eventsource," +
"figure,footer,header,hgroup,mark,menu,meter,nav,output,progress,section,time,video";.
split(','),i=e.length;while(i--){document.createElement(e[i])}})()
</script>
<![endif]-->
This is a ui element I created which takes inspiration from facebook’s excellent growing textarea. Or at least I believe facebook was one of the first to create this.
How it works is when text is typed into the textarea and it becomes longer than the textarea height, then the textarea will grow. I’m keeping this plugin in a github repository, fork it, clone it My Javascript Git Repository.
Demo
The key to making something like this work, is you need to create div element that copies the text from the textarea to the div. The div naturally will grow when it has more text in it. When it does, you get the height of the div element and apply it to the textarea.
Here’s how you would init the growing text box.
$("textarea").growing();
I’ve also added some options you can pass in, growning({maxHeight:300,minHeight:40,buffer:20}) the max and min height are pretty self explainitory. The buffer is the space below the text in the textarea, if you want an extra line below the currently typing line.
The Code
Currently I’m adding a class to the div called faketextarea so I can style it the same as the textarea. This is important becuase if one element has more padding than the other, then the heights will be messed up. and this plugin won’t work exactly right.
Recently I have had the privilege to work with a few excellent small agile teams. With each team, they have their own process, which works best for them. And there’s nothing wrong with that, a team should work in it’s most effective way. But I came across a team recently that had a workflow that really impressed me. To put it simply it’s described as an extremely cool Git workflow.
I can’t take credit for coming up with this workflow, but I’m gonna do my best to re-describe it here so it can be shared. The basis for this post comes from reinh.com’s posts A git workflow for Agile Teams and Hack && Ship. Also this workflow pulls alot from Josh Susser’s post on the story branch pattern.
Let’s start by summarizing Josh’s post. In his post he describes a 7 step process that begins with Pivotal Tracker. The idea being you locate a story on pivotal tracker, like a bug, or feature, or chore. Then you update your working master by pulling from the origin, and create a whole branch just for that bug. Once you’ve fixed the bug, commited it to your branch, you then merge your branch with the master and push it all back up to the origin. Then just remove the old branch and you’re done.
That’s the basic workflow, but there is alot of automation that can be done. The first is the creation of the branch. This isn’t terribly long command ‘git checkout -b’ but I went ahead and created a shell alias ‘gcb’.
alias gcb='git checkout -b'
So now when creating my branch for working on my bug I just type
gcb fix_ie_bug_Story123456
After creating my branch I would work on it normally doing ‘git commits’ when needed. Then when I’m ready comes the cool part. Hack & Ship. Hack is what it’s called when you pull the lastest code from the origin and merge it with your branch. It’s a good idea to do this often, just to keep everything up to date. To not have to type and remember the few commands for accomplishing this, I use a shell script.
hack.sh
#!/bin/sh -x
# hack: Merge the latest changes from the master branch into your current branch
ref=$(git symbolic-ref HEAD 2> /dev/null) || exit 0
CURRENT="${ref#refs/heads/}"
git checkout master
git pull origin master
git checkout ${CURRENT}
git rebase master
So during my coding, I can at anytime just type the command hack. And my branch is updated!
Once I’ve finished my bug and I’m ready to send it back to the origin I do one more ‘hack’, make sure it’s all updated. And then I ship. This will checkout the master merge my branch with it, and then push it to the origin. Once again I use a shell script for this.
Now I’m done with my bug, and there’s a script for that ‘dwf’. This will move me back to the master, and delete my old branch.
dwf.sh
#!/bin/sh -x
# dwf, aka "Done With Feature" script: deletes current branch and puts you back on master
ref=$(git symbolic-ref HEAD 2> /dev/null) || exit 0
CURRENT="${ref#refs/heads/}"
git checkout master
git branch -d ${CURRENT}
And we’re ready to repeat the whole process on a new bug/feature/chore.
With the rise of web standards we have seen the rise of the semantic web. This applies to the HTML elements selected as well as the class names chosen for the HTML. When choosing semantic elements and class names you want to pick a name considering the function or meaning of the element as it is on your page, not the position or style of the element.
The Meaning
What exactly am I talking about “meaning” or “function”? This means that when picking a name you want to pick one regardless of where it is, only what it contains or what you’re using it for.
example: Imagine we have some markup that represents a search result
THE BAD WAY
<div class="search-result">
<div class="search-result-large-header"><a href="">My Search Result</a></div>
<div class="search-result-gray-description">This is the best search result</div>
<div class="bottom-search-result-info"><a href="">1 comment</a> <a href="">12 views</a></div>
</div>
There is a lot of things wrong with this. To name a few, there are too many unnecessary DIV’s; The class names have style and position specific properties; Since this is a search result, multiples of these makes me want to pass out.
THE SEMANTIC WAY
<div class="search-result">
<h3><a href="">My Search Result</a></h3>
<p>This is the best search result</p>
<div class="meta"><a href="">1 comment</a> <a href="">12 views</a></div>
</div>
using the semantic way, I don’t need as many divs and when I do use a div I try to pick a name that describes what I’m putting in the tag. I’m calling it “meta” because that info is the meta data for that search result. It has nothing to do with the bottom, and it doesn’t need “search-result” in the name because it is a child of search-result anyways.
I also selected h3 and p elements because an h3 refers to a heading, which the title of the search result is certainly a heading, and p, because this is a paragraph of text which describes the search result.
You may ask, “What’s the big deal? It’s all gonna render the same in the browser anyways?” The benefits for semantic code translate into faster development time, javascript traversal becomes easier and it makes me happy. :)
Some more bad names that I have witnessed: .padding5px, .topBorderGreen, .redErrorText. What happens if you want a padding of 4px, or suddenly the border becomes blue, or if the error text becomes yellow. Then you’ll need to go back through all your html and re-name classes. May I suggest names like .content, .important, or .error.
This is just a quick share, but while developing my site, I realized I don’t want visitors to click on a link and be taken away from my site. The proper way to do this is to add the target=”_blank” to all your external links like so.
But I’m way too busy to remember to do that for every link I add to my blog. I mean I try to but what happens when I forget. So I wrote a small jQuery snippet to get my back.
