One thing I am a little worried about: with any book of this nature I can virtually guarantee that anyone who reads it will absolutely love some of the chapters and absolutely hate others. We certainly saw that in the review stages with early drafts of the manuscript. However, we also saw that the reviewers couldn't agree on which chapters they loved and which they hated. In fact, a chapter that one reviewer hated was usually another reviewer's favorite and vice versa.
The love / hate thing smells deliciously of controversy. What parts of the book do you expect (or have found to be) most controversial?
The one that's really jumped out is well-formedness. There are people who are well-formedness fanatics and who think that allowing malformed markup is insane, and there are people who despise it passionately. We had one tech reviewer quit over that, and though he was anonymous I'm pretty sure I know who it was. I suggested his name precisely because I knew he was going to vehemently disagree with everything I said, and pick as many holes in my arguments as possible.
Like all refactorings though, you should implement the well-formedness refactorings if they assist you and make your site better, and ignore them if they don't. However well-formedness is a prerequisite for a lot (though not all) of other things you might want to do, so I wouldn't throw it out without a very good reason. Such reasons do exist, but they're the exception, not the rule.
Elliotte Rusty Harold<br />Author of <a href="http://cafe.elharo.com/web/refactoring-html/" target="_blank" rel="nofollow">Refactoring HTML</a>
"Validity" would refer to whether or not it passes validation.
"Well-formedness" would refer more to semantic markup and proper markup. Like using tables for layout. It's valid, but it's not well-formed. Or using the blockquote, quote, and cite tags semantically. They're kind of a PITA to use, require a lot of weird styling sometimes, and don't add much visual semantic information (if any), so many developers leave them out and just use a paragraph or whatever. Again, this is valid, but not well-formed.
Originally posted by Paul Clapham: Technically that would be "validity" and not "well-formedness", no?
Yes, that's why I asked the question. I've never heard any web professional worth his salt religiously argue against properly closing tags or quoting of attributes, so I was wondering what controversy Elliotte has experienced in this regard.
(I've encountered plenty of page authors who don't use well-formed markup -- but no one who argues against well-formed markup.) [ July 16, 2008: Message edited by: Bear Bibeault ]
Originally posted by Kenneth Love: Like using tables for layout. It's valid, but it's not well-formed.
I do not believe that "well-formed" is the proper term for that. "Well-formedness" usually refers to whether the XML has proper and valid syntax.
I've never heard it used to describe adherence to best or accepted practices.
Joined: Jan 18, 2005
Wow. I always thought "well formed" meant a closing bracket for every tag, and proper sequence of the closing tags when nesting the different nodes. The following is the Wikipedia definition:
In web page design, and generally for all markup languages such as SGML, HTML, and XML, a well-formed element is one that is either:
* opened and subsequently closed, * an empty element, which in that case must be terminated, * properly nested so that it does not overlap.
For example, in HTML: <b>word</b> is a well-formed element, while <i><b>word</i> is not, since the bold element is not closed. In XHTML, empty elements (elements that inherently have no content) should be closed by putting a slash at the end of the opening tag, e.g. <img />, <br />, <hr />, etc. In HTML, there is no closing tag for such elements, and no slash is added to the opening tag.
Furthermore, if an element has any attributes, each attribute value must be properly quoted.
In a well-formed document,
* all elements are well-formed, and * a single element, known as the root element, contains all of the other elements in the document.
[ July 16, 2008: Message edited by: Charles McGuire ]
Elliotte Rusty Harold
Joined: Feb 25, 2004
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. :-)
Ah yes, I forgot about google. I remember at some point in my series of interviews with them discussing using the <img> tag to make simple and low-overhead Ajax calls.
Obviously, this is an engineering discipline and sometimes it's expedient and worth the trade-offs to break the rules. But only if you have a really good story to justify it. ("I'm lazy" isn't one of those good stories )
When the src attribute of the <img> is set, it hits the server with the URL, which can possess a query string just like any other URL. This is very low in overhead compared to an XMLHttpRequest-initiated request.
Of course it's not useful if the client needs anything in the response, but it's quick and dirty for triggering something to happen on the server when a response is unnecessary.
This is not a technique I've ever really used, or would even considering using unless it was critical to allowing a bazillion users to hit a server simultaneously. Our web app only gets simultaneously used by something on the order of a hundred thousand to two hundred thousand or so, and we haven't found a need to resort to such tricks.
Joined: Nov 03, 2006
Originally posted by Bear Bibeault: When the src attribute of the <img> is set, it hits the server with the URL, which can possess a query string just like any other URL. This is very low in overhead compared to an XMLHttpRequest-initiated request.
Ah, I get it - thanks.
In our current applications I can think of about 1001 things to improve before we might need to resort to those types of tricks