We were in Tel Aviv on business and for our first night we decided to walk north along the Tel Aviv Promenade along the Mediterranean Sea to find a restaurant somewhere in the Tel Aviv Port area.
Tips:
We were in Tel Aviv on business and for our first night we decided to walk north along the Tel Aviv Promenade along the Mediterranean Sea to find a restaurant somewhere in the Tel Aviv Port area.
Tips:
Background on why I was Updating to jQuery 1.9: For a number of reasons, I needed to update my website to a newer version of jQuery, jQuery 1.9. My site, designed in 2010 was started on v1.4 and had last been updated to 1.7 in 2011. I knew I had several out-of-date methods and expected to some debugging and troubleshooting. Well, in the end, it took me 6 hours spread over two days. It wasn’t really that bad, but since I don’t upgrade jQuery everyday, I had a little re-learning to go through.
For starters, I knew that v1.9 had deprecated many of its old methods. In fact, I learned from the upgrade web page, , that v1.9 comes with a special migration plug-in. I was pleased to see this and used this to address most all of my updating challenages.
For example, $.browser() method was deprecated. The migrate script reported this to me in the Chrome console, as follows:
Chrome console:
With a little digging, I was able to find that I was using an old version of blockUI. When I changed to the new version the warning message went away.
I also got the following warning messages related to type changing and the change to the andSelf() method:
Chrome console:
Again, it took a lot of digging, but I was able to isolate the problem to my tmpl.js script. I was using a really old version. I think with a little more skill on my part, I would better be able to use stack backtraces or some other Chrome tool to find these quicker, but this problem was hard for me to find.
Since I was also using an old version of jQuery-UI, I stumbled upon a couple of breakages triggered by curCSS:
Chrome console:
For some reason, also, the dialog() method wouldn’t display text in the “OK” button and it would always popup at 0.0 (upper left), so I upgraded to jQuery-ui v1.9.2.
One last thing for Updating to jQuery 1.9. I had to change all of my .live() events to .on(). The migration guide clearly covered this.
Here’s an example from my website:
//$('#journal input').live('keydown', function(evt) { $(document).on('keydown','#journal input', function(evt) {
This was easy to do; I had to do it in 6 different place, and it worked the first time.
Updating to jQuery 1.9 was a little more painful than I would like, but feels good to get caught up.
Ok, now that I’ve converted to jQuery v1.9, I can try out some of the new things.
As part of updating my website to HTML5 boilerplate 4.2, I am finally converting my CSS to use normalize.css.
My original index.html
file used the following
<head> ... <link rel="stylesheet" href="css/smoothness/jquery-ui-1.8.16.custom.css"> <link rel="stylesheet" href="css/style.css"> <link rel="stylesheet" href="css/screen.css"> ... </head>
where style.css
borrowed heavily from a prior version of H5BP and most of my custom styles were in screen.css
. To me, all of this worked, but I was delighted to follow H5BP’s lead and refactor my CSS to use normalize.css
.
My new index.html
file looks like this:
<head> ... <link rel="stylesheet" href="css/smoothness/jquery-ui-1.8.16.custom.css"> <link rel="stylesheet" href="css/normalize.css"> <link rel="stylesheet" href="css/main.css"> ... </head>
where normalize.css
is version v1.1.1 taken from the H5BP github repository. The main.css
is the H5BP file with my custom CSS inserted at the designated spot (“Author’s custom styles” section).
So I didn’t trust that this work work very well. I have always been kludgy and I mostly hack together my CSS; I am happy to align with a framework like H5BP, but I wasn’t optimistic that this would be easy.
So, I took an intermediate step to Add Normalize to my HTML5 CSS by creating a temporary file called indexnormalize.html
. In Chrome, I setup two tabs, one with my index.html
and the other with my indexnormalize.html
and I did side by side comparisons, liberally using the “Inspect Element” developer tool built into Chrome.
After about an hour, I was done. It wasn’t that bad. Here’s a summary of the tweaks that I had to make to my CSS:
Background color. My web page has a black background. I have been setting it using the body tag, and I should have been using the html tag. The comments in normalize explain why this is better and there’s a whole series of blog postings explaining why my prior design was clueless (at best). Reference: Understanding the HTML versus BODY Element in CSS
/* Part of file main.css */ /* old: */ body { ... background-color: black; } --- /* new: */ body { ... } html { background: black; }
Drop down menu padding. The way my drop down menus were defined, the normalize.css
margin and padding mucked things up. Rather than redesigning my menus, I added some CSS to compensate.
In normalize.css
the following tripped me up:
/* Part of file normalize.css */ ul { margin: 1em 0; } ul { padding: 0 0 0 40px; }
To fix this, in my custom css I added:
/* Part of file main.css */ #page-bar { padding: 0 0 0 0px; margin: 0 0; }
Nav tag. My menus use the nav tag and so does normalize.css
. I had to also fix the margin and padding there, too
/* Part of file main.css */ nav ul { margin: 0; padding: 0; }
Printing styles. Also, I had to go into a different section of main.css
to edit in my print styles. In the section titled “Print Styles” I put the following at the very end:
/* Part of file main.css */ ... tbody, tr, img { page-break-inside: avoid; } tbody { border: 1px solid #999; } #head, #foot { display: none; } }