Fixin's

You spill out all of your creative talent on a new Web page and after a while you just cannot stand not knowing any more. And so, with just a hint of trepidation, you hit your [F12] key to show the results in a real browser on the real Internet... and it looks awful. What do you do, at that point?

This is a question I seem to get the most. Well, this or some variation of it. How do you fix things? Okay, I took the training. I read the Google links. I looked it up in the book. Then I put down my best first effort and gave it a shot and came up short. Now what?

Validate your page first, of course. But suppose it’s not a syntax error you are hunting, but some weakness in your understanding of, say, Cascading StyleSheets?

When I was learning to fly, I had a Hell of a time learning to land, which is one of the skills you really want to become good at. I had a wonderfully patient flight instructor, though and he gave me the key: Try, as much as is possible, to always do the same things, and do them at the same time. I used to take off at 90 miles per hour the first time, and 110 miles per hour the next. Sometimes, I would climb to eight hundred feet before turning, other times, I would climb up to twelve hundred feet. Sometimes, I would turn toward the runway when I was a quarter mile from the end and other times, I would find myself half a mile away. And when I would turn onto my final approach, sometimes I would fly at 85 miles per hour and other times at 75 miles per hour. Sometimes I’d have the engine at idle and other times I’d be turning 1500rpm.

Every landing was different for me, because every landing was different. I never did the same thing the same way twice in a row, so who is surprised that each landing was a new adventure? Once I learned to always take off at 90mph and to always climb out at the same speed and always make my first turn at the same altitude and always reduce my speed abeam the same location on the runway, and so on, everything came together for me. You reduce your workload and get everything done early so you can more easily manage the fewer variables that have changed since the last time. You end up on Final approach with more or less the same “picture” out the window every time because you’re always more or less at the same place with the same airplane as you had last time. You’re not suddenly having to slow down, or account for a changing cross wind. And if you do have to account for those changes, those are the only changes you have to deal with.

Manage your variables is the lesson. Don’t change seven things and then check your pages, change one thing and check your pages. Work it out in your mind… what is it, specifically, you expect to see? And what are the differences between what you expect and what you get? Change one thing and you can immediately see the results of that change. But if you change nine things you may have a more difficult time seeing the effects of an individual adjustment. This is especially true when you are dealing with margins and paddings in CSS.

I am a big fan of putting a box around it, whatever “it” is that you’re working on, to help you to see what is actually happening on a page. Quite often there is a big difference between what you expect, what you think is happening and what is actually going on. You want to adjust the space between “this” and “that”? Draw a box around either element and then start making adjustments—just remember the border itself needs to be accounted for in that space. If you don’t declare a border, there won’t be one, of course. But if you do declare even a one-pixel border around an element, you will be placing two pixels in either the horizontal or vertical space you are working in. Remember that.

Work slowly, deliberately. Make a change, anticipate what it will do, and then check the results. Once you have the effect you wanted to achieve, or are happy with an accidental discovery, then move on to make other changes. And keep learning. Eventually, you will find that what you expect to see and what you actually get are more and more often the same. Then maybe you can back off a notch or two and only check every two or three changes. But if you’re surprised again, go back to the last time you weren’t and do the single-change thing again, stepping through the process until it all works.

I'm on the Beach

Well, at least I'm on vacation. Check back next week, please.

Adobe Dreamweaver CS5?

It came up last week, during training. “When will the next version of Dreamweaver arrive, and what kinds of differences can we expect?”

It seems like only yesterday since the upgrade from CS3 to CS4, but the big wheel keeps on turning. As I tell people in my Introductory class, “The people who brought you Dreamweaver CS4 still have jobs!” There will be another new version of Dreamweaver one day, probably (but by no means guaranteed to be) named “CS5”. A new version, however it’s named, may be with us as soon as the summer of 2010.

Remember, Dreamweavers so far have been called Dreamweaver, -2, -3, -4, -5 and then Dreamweaver MX2000 and Dreamweaver MX2004, then Dreamweaver 8, -CS3 and -CS4. So, really, it’s anyone’s guess.

What kinds of changes can we expect? The developers at Macromedia and Adobe both spent some major coin pumping up the support of Web standards and Cascading Stylesheets, since the MX releases. Every version has been better than the previous one, in that regard. It is now easier to twiddle with CSS, and the twiddling results in much better markup.

The user interface has been cleaned-up a bunch. Remember we lost a whole menu in the move from CS3 to CS4 (“Text”). I would expect a few improvements here, again. I would expect a little more modernization. Dreamweaver CS4 no longer includes the Netscape Navigator “Resize Fix” JavaScript code. I expect one day soon some cub developer will be tasked with shining-up the Snippets section, improving the default dates in the drop-down menu options and maybe adding a few new ones--it’s been a good long while we saw anything happening, here.

The Mobile Web is not getting any smaller, and I would not be surprised to see more support for that in the next version. Maybe a simpler, easier way to approximate your latest page in two or three handheld devices.

Dreamweaver’s Design View now runs on the same WebKit engine behind popular browsers like Firefox and Chrome. It would be nice if we could get some kind of a real-world way to view our pages, independent of platform. Suppose I work on a Macintosh. Why should I have to boot up even a virtual Windows machine to check a Web page? Why couldn’t Dreamweaver provide me with some kind of Windows Internet Explorer emulation as part of the program?

One feature I have always disliked, that is probably unlikely to change, is the way you cannot move your cursor up a line in the column one of Text View. Click on a line of text in your markup and right-arrow to the end of the line. One more right-arrow gets you to the very beginning of the next line. Now, up-arrow to get back into the line you just left, and Dreamweaver thoughtfully moves you over about five or six characters into the line. Left-arrow as many times as you need to get back to that first column and up-arrow again and you will once again be in column four or five or six. Whatever it is, it’s annoying to me.

One area where Macromedia and Adobe have always fallen short is in the support and training and even the marketing of features and benefits in the Creative Suite. Can you tell me what “Spry” is and does and how it works and why we should care? Sprinkled throughout the Dreamweaver interface are little references to Spry, but you have to really want to learn what it is and does to get any value or benefit out of it.

What would you like to see, in the next version of Dreamweaver?

I'm on vacation, next week. Keep the lid on it!

Run Google Chrome in Internet Explorer?

Through the magic of browser augmentation, you can now run a good WebKit browser from within your copy of Microsoft Internet Explorer.

Some notes for those of you scoring this one at home:

• Internet Explorer is far and away the internet’s most used Web browser.


• Internet Explorer 6 was born in August of 2001, and last updated in April of 2008.


• For many years, IE6’s share was something around ninety percent of the market.


• Internet Explorer 6 does not understand HTML5 tagging.


• Internet Explorer 6 features old-style (slow) JavaScript performance.


• The Web community has been asking for a better browser since long before IE6 showed up, and many responded by drifting away to Firefox, Safari and the Google Chrome browsers.


• Some IT departments thought it was cute to tie Web applications not to the underlying standard technologies of the Web, the HTML, the CSS and the JavaScript, but to the underlying technologies of Internet Explorer, including ActiveX, despite the security risks involved.

That’s pretty much it, for Internet Explorer and especially Internet Explorer 6. Comes now the Google Chrome plug-in, which shines up IE in ways that Microsoft couldn’t, or wouldn’t, for all of those years.

Google Chrome Frame is an open-sourced Google plug-in featuring one-click installation that brings Internet Explorer up to par with other WebKit browsers. You can use it with IE6 if you have to, IE7 if you’re still using that, or IE8, and take advantage of JavaScript improvement approaching ten times better JavaScript performance, plus new support for HTML5. All of your old IE applications still work, because you are still using IE.

This comes to you from your friends at Google, remember. Not your... developers, at Microsoft. Take a deep breath, here, kids. Chrome now runs inside Internet Explorer. Just imagine if you could get Honda or Toyota quality and performance in a new Pontia—uh, Satur—uh, Buick. To all outward appearances, you’re a Good American, buying a Good American Car. But now it runs forever and doesn’t fall apart on you and doesn’t depreciate as fast. This is going to be an interesting ride, folks. Google does not destroy anything about IE6, IE7 or IE8. It does not change the browser in ways that it identifies as Google Chrome on server logs. It adds functionality to IE, just like any other plug-in.

Web developers cannot afford to ignore Internet Explorer, it’s just too big. But this new plug-in allows authors to include a single line of markup in their pages that flips the rendering of a page from Internet Explorer’s “Trident” engine to the increasingly-popular WebKit engine. Suddenly, HTML5 works, and JavaScript works much faster.

Now, quite often in life when you mix manufacturers, authors, artists, if you will, you run into troubles. The whole car is English but the engine is now Metric. That doesn’t seem to be the case in Google Chrome Frame. Internet Explorer now runs the ACID-3 test and scores… 100 out of 100. It’s amazing.

Now Microsoft, predictably, doesn’t think much of this idea. They remind people that now, you have two lines of vulnerability online, the bag of IE problems and the bag of Chome’s troubles, too. That’s certainly valid, but I suspect that Google is going to be doing whatever it can to shine up Chrome Frame.