Dave Shea has decided to move away from implementing websites using xHTML and is using HTML 4.01. His main reason:
I made the switch more because of overall trends. Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about. For me, a guy who builds web sites and applications for clients that have to work in today’s browsers, XHTML2 is a non-issue. No browser support, no use to today’s web authors. End of story.
This is something I have not really thought about much over the last few years. I made the switch from HTML to xHTML and haven’t really looked back. Now, I am going to have to look into this. I don’t really see anything that xHTML offers over HTML 4.01. I do like the fact that xHTML is easier to parse using an XML parser, but this is a small point given libraries like Hpricot and Nokogiri.
What do others think? Is there any reason to use xHTML over HTML 4.01?
A width of 960 pixels has become the de facto standard for creating fixed-width web sites. Cameron Moll is asking if it is time to move beyond this width, and if so, what do we move to? I personally really like 960 as a width. It makes for easy to read lines of text and helps to ensure that they don’t get too long.
He proposes widths of 1020, 1040, and 1080. I am not sure the extra 60 to 120 pixels will really make that big of a difference.
With most computer monitors now displaying 1280 or larger horizontal resolutions, it is definitely something to think about.
I have been trying to set up a Capistrano script for deploying to a staging and production server. I found this very well written tutorial showing how to set up the various cap scripts to work with mod_rails (Passenger).
One note, Capistrano does not copy over the database.yml file. You need to put this in yourself. This tripped me up for a while since I was assuming that it would somehow magically take the database.yml.template file I had and turn it into a database.yml file that I would then have to configure. The Ruby magic doesn’t extend that far 
.
When using layouts in Rails, I strongly suggest keeping as much of the container elements in the layout and using content_for to create sections in which content can be placed.
I am working on a site right now that has used the YUI Grids to layout the site (something I highly recommend for anyone designing a site from scratch). Most of the site uses a two column layout. The application.html.erb file looks like this:
<body>
<div id="doc" class="yui-t6">
<div id="hd" role="banner">
<%= render_partial "shared/header" %>
</div>
<div id="bd" role="main">
<%= yield :content %>
</div>
<div id="ft" role="contentinfo">
<%= render_partial "shared/footer" %>
</div>
</div>
</body>
What is missing is the part that divides the page into your content area and your, in this case, right-hand side area. This part was placed in the rest of the view files. Not only does this mean that it is repeated everywhere and a huge pain to change, it also means that it is much harder for coders, who may not know YUI CSS Grids, to properly lay out pages. In the case of the app that I am modifying, it has also meant that parts of the CSS layout are strewn careless between regular pages and partials.
Instead, this is how the layout page should look:
<body>
<div id="doc" class="yui-t6">
<div id="hd" role="banner">
<%= render_partial "shared/header" %>
</div>
<div id="bd" role="main">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g">
<%= yield :content %>
</div>
</div>
</div>
<div class="yui-b">
<%= yield :side_content %>
</div>
</div>
<div id="ft" role="contentinfo">
<%= render_partial "shared/footer" %>
</div>
</div>
</body>
This keeps everything clean and makes for view pages that look like the following.
<% content_for :content do %>
put content here
<% end %>
<% content_for :side_content do %>
put side content here
<% end %>
I think that makes it much easier to see what is happening within view pages. It also keeps all the layout code in one place.
I have spent the last few days working with the CSS in an existing web application. It isn’t pretty. My biggest pet peeve with it is all the special cases that exist. If you find yourself doing a lot of the following you are in for a world of hurt when it comes time to redesign your site.
.homepage h3 {
some style
}
.about h3 {
}
div.box h3 {
}
My advice is to create a style guide and stick to it throughout the entire site. That way, when you use h3 you will know exactly what it is going to look like and it will stay consistent throughout the entire web site.
Another side benefit of doing this is your CSS file will be greatly reduced in size and will be understandable. This will also save on download times for those visiting your site.
I am not sure if anyone else has had this problem, but one thing I have never liked about using Yahoo! UI Grids library is that I could never get a background colour applied to <body> to fill the entire background. It would only go to the bottom of the #doc div. So if that happened to be half way up your browser window you were left with half a window of white.
I finally figured out how to solve this. Grids, or Reset, adds a background CSS attribute to the html element. To get rid of this, and have your background fill the entire browser simply use
html {
background: none;
}
I have been playing with adding tags to contacts in Highrise programatically. Unfortunately, 37Signals has not added this functionality to the API for Highrise so you have to hack it in. Based on a post on adding contacts, the following code will add a single tag to a contact.
require 'rubygems'
require 'net/http'
contact_id = 12345
connection = Net::HTTP.new("your_account.highrisehq.com")
req = Net::HTTP::Post.new("/parties/#{contact_id}/tags")
req["content-type"] = "application/xml"
req.basic_auth("your_api_token", 'X')
req.set_form_data({"name" => "new_or_existing_tag"}, ";")
response = connection.request(req)
puts response
This will return a bunch of JavaScript that you can ignore.
For comparison, here is the same code using HTTParty. A very nice, easy to use library for interacting with ReST services.
require 'rubygems'
require 'httparty'
class Tag
include HTTParty
base_uri "your_site.highrisehq.com"
basic_auth 'your_api_token', 'X'
def add_tag_to_contact(tag, contact_id)
self.class.post("/parties/#{contact_id}/tags", :query => { :name => tag })
end
end
puts Tag.new.add_tag_to_contact("tag_as_string", "1")
The goal of all this is to create a Highrise API wrapper that includes the ability to manipulate tags. Highrise is great, but the lack of Tags in the API really reduces what you can do with the tool since there is no facility for creating or manipulating lists.