Elliotte Rusty Harold

author
+ Follow
since Feb 25, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Elliotte Rusty Harold

Get a better product manager?

Seriously, step 1 in good site design is to write a simple, linear page.

Step 2 is to apply CSS to make it look better.

But you always start with step 1, and then you always have a page that degrades gracefully in older browsers. The book spends a lot of time talking about how to design and style linear pages (though I didn't think of phrase it that way).

Besides backwards compatibility, linearity is crucial for both search engine optimization and accessibility. If your product manager doesn't believe that, don't tell them what you're doing. They won't know the difference.
I don't think any of the current commonly used tools are going away anytime soon (though I wish a few of them would).

The big trends I see on the horizon are on the backend, development side more than the frontend design side. I think a lot of sites are going to begin using native XML databases like eXist and Mark Logic to store their content instead of relational databases. Relational databases have just never been a very good fit for HTML.

I also expect we'll see more use of cloud computing with initiatives like Amazon EC2 and S3 and Google's AppEngine. Increasingly we won't think of a web site as associated with any one physical box. To a large extent, of course, that's already come to pass, but it's going to become even more true in the future.
Very true. Too many developers simply replace all the <i> tags with <em> and think they've done their job. Latin names are, in fact specifically discussed in the book in the section on "Replace <i> with <em>". I recommend using a span element with an appropriate class in this case. E.g.



Then you can define a CSS rule that italicizes all the species. However for quick and dirty work, you're better off using <i> here than <em>.
[ July 18, 2008: Message edited by: Elliotte Rusty Harold ]
JAHA? I'm not sure what that is. Did you mean Java? Either way, I do not discuss any hidden applet techniques.
Making a site resolution independent is usually easier than making a site resolution dependent. The key is to focus on the content and not the appearance. Strive for linearity and avoid complicated element placement. Never specify the width or height of anything (or if you must use percentages and relative units, not absolute units like pixels and centimeters). Finally, never design a mockup in Photoshop. It's a photo editor, not a page layout program.
REST is the third major theme of the book, along with XHTML and CSS, and is covered extensively in the chapter on web applications. I've published the intro section about REST on The Cafes.

To the extent possible, I tried to avoid working with specific frameworks, since there are so many. Instead I try to focus on general principles, like using GET for safe operations and POST for unsafe ones. However when I did feel the need for a specific example on the server side, I usually wrote it in either PHP or Java servlets (or both) since those are the most common and most understood systems out there. Also, they have the advantage of being fairly close to the wire, and not abstracting away too much like higher level frameworks and CMS's like WordPress or MediaWiki.
[ July 17, 2008: Message edited by: Elliotte Rusty Harold ]
Frameworks are the easiest systems to refactor because you only have to refactor the framework templates, not every single page. Once you've done that you can maintain well-formedness very easily.

The only real restriction here is that you want to use an open source framework so you can modify the underlying code. Ideally you also want to use one where the developers put some effort into producing better HTML themselves. For instance, SlashCode has improved quite a lot over the years, at least in terms of the HTML it generates. MediaWiki's done even better. Ultimate Bulletin Board, I'm sad to say, hasn't done so well. :-(
Quang,

I expect so. I learned enough while writing it, and I've been around a while too. Without knowing exactly what you already know it's hard to point to exactly what you'll learn; but I think the major new development is simply the techniques to upgrade old, legacy sites. These haven't been systematically analyzed before to my knowledge. I doubt this is the last word on the subject, but I hope it's a good start.
I have met web professionals who were worth several times their salt argue against closing elements and quoting attributes. Sometimes they've even been right.

You'll notice that a lot of the sections in the book include a caveat like this one from the section on quoting attributes:

This can add roughly two bytes per attribute value to the file size. If you�re Google and are counting every byte on your home page because you serve gigabytes per second, this may matter. This should not concern anybody else.



That should give you a big hint as to where some of these web professionals now work. :-)
Standards based approaches work much more reliably across browsers than non-standards based approaches. If you do need to support multiple browsers (and really you always do, even when you think you don't) the simplest approach is usually to develop in Firefox, validate, make it work in Internet Explorer, and validate again.
That question really deserves an entire book on its own, and that book has yet to be written. I didn�t have space or time to write a complete second book about test driven development of web sites and web applications, but perhaps this small excerpt will inspire someone else to do it. If not, maybe I�ll get to it one of these days. :-)


In theory, refactoring should not break anything that isn�t already broken. In practice, it isn�t always so reliable. To some extent, the catalog later in this book shows you what changes you can safely make. However, both people and tools do make mistakes; and it�s always possible that refactoring will introduce new bugs. Thus, the refactoring process really needs a good automated test suite. After every refactoring, you�d like to be able to press a button and see at a glance whether anything broke.

Although test-driven development has been a massive success among traditional programmers, it is not yet so common among web developers, especially those working on the front end. In fact, any automated testing of web sites is probably the exception rather than the rule, especially when it comes to HTML. It is time for that to change. It is time for web developers to start to write and run test suites and to use test-driven development.

The basic test-driven development approach is as follows:


1. Write a test for a feature.
2. Code the simplest thing that can possibly work.
3. Run all tests.
4. If tests passed, goto 1.
5. Else, goto 2.

For refactoring purposes, it is very important that this process be as automatic as possible. In particular:

  • The test suite should not require any complicated setup. Ideally, you should be able to run it with the click of a button. You don�t want developers to skip running tests because they�re too hard to run.
  • The tests should be fast enough that they can be run frequently; ideally, they should take 90 seconds or less to run. You don�t want developers to skip running tests because they take too long.
  • The result must be pass or fail, and it should be blindingly obvious which it is. If the result is fail, the failed tests should generate more output explaining what failed. However, passing tests should generate no output at all, except perhaps for a message such as �All tests passed�. In particular, you want to avoid the common problem in which one or two failing tests get lost in a sea of output from passing tests.


  • Writing tests for web applications is harder than writing tests for classic applications. Part of this is because the tools for web application testing aren�t as mature as the tools for traditional application testing. Part of this is because any test that involves looking at something and figuring out whether it looks right is hard for a computer. (It�s easy for a person, but the goal is to remove people from the loop.) Thus, you may not achieve the perfect coverage you can in a Java or .NET application. Nonetheless, some testing is better than none, and you can in fact test quite a lot.

    One thing you will discover is that refactoring your code to web standards such as XHTML is going to make testing a lot easier. Going forward, it is much easier to write tests for well-formed and valid XHTML pages than for malformed ones. This is because it is much easier to write code that consumes well-formed pages than malformed ones. It is much easier to see what the browser sees, because all browsers see the same thing in well-formed pages and different things in malformed ones. Thus, one benefit of refactoring is improving testability and making test-driven development possible in the first place. Indeed, with a lot of web sites that don�t already have tests, you may need to refactor them enough to make testing possible before moving forward.

    You can use many tools to test web pages, ranging from decent to horrible and free to very expensive. Some of these are designed for programmers, some for web developers, and some for business domain experts. They include:

  • HtmlUnit
  • JsUnit
  • HttpUnit
  • JWebUnit
  • FitNesse
  • Selenium


  • In practice, the rough edges on these tools make it very helpful to have an experienced agile programmer develop the first few tests and the test framework. Once you have an automated test suite in place, it is usually easier to add more tests yourself.



    The subject continues for quite a few pages in Chapter 2. That said, this could really use a book length treatment of its own.
    [ July 16, 2008: Message edited by: Elliotte Rusty Harold ]
    Yes, moving the presentation to CSS is a major focus of the book. It's not a CSS tutorial (there are plenty of other good ones) but it does cover some of the thornier problems in depth, including what I think is the best exposition yet of the Holy Grail (three column layout with liquid center).
    Yes, provided you already know HTML. It is definitely more an advanced best practices than a tutorial for first-time HTML jockies.
    The book talks about refactoring HTML, CSS, and more generally web sites and web applications. It really is refactoring HTML, not refactoring JavaScript. With respect to JavaScript, I focus more on when, where, and why to use or not use JavaScript. I didn't bother with porting well-known programming language refactorings such as "Inline Method" or "Extract Field" to JavaScript. The target audience is really people who design and build web sites for a living, not programmers as such. (Of course, many of us have jobs that blur those distinctions but I didn't want to assume everyone reading the book was an accomplished object oriented programmer.)
    The key to selling refactoring to creative or other groups is to address their pain points. Find out what they're having trouble with, and then choose those refactorings that will assist with that.

    Visual creative types do have one particular pathology you'll need to address. They tend to think their job is done as soon as everything looks exactly right in their browser, on their desktop, at their screen size. Thus they tend to create markup that works in only one very specific environment. If you can get away with it, change their computer daily so they never use the same browser, monitor, or operating system two days in a row. (This requires a really good network home directory.) Less radically, just require them to switch browsers regularly.