Slashdot Mirror
Web Designer's Reference
The reasons are clear and compelling: The World Wide Web Consortium, which promulgates Web design standards, has decreed HTML as obsolete. Newer, more compliant browsers, will in time not support the older tags and code; the new standards facilitate much better use by the disabled of screen readers and non-graphic browsers. Not least, the newer code makes writing and revising code easier and more efficient, as well as more capable.
These are certainly good reasons for Web designers to move to the new code. Nevertheless, surveys show that most Web pages are not compliant and that thousands of designers continue to use deprecated code. I confess that I am one of them -- after a number of years learning and getting used to HTML, the need to learn new and more code is onerous. The inertia of habit is a factor, I'm sure.
For those Web designers like me, Mr. Grannell's book is a welcome addition to the literature because it systematically deals with the topics under discussion. In its coverage of XHTML, CSS, Javascript, and complementary coding (like PHP), it provides a nice framework guiding "old dogs" like me into standards-compliant code. Not only does it provide some historical perspectives on these codes, it compares the old with the new in regard to all of the important elements of Web design.
The author is an experienced Web designer and operates a design and writing agency. He also writes articles for a number of computer magazines.
Grannell's goals are to teach cutting-edge, efficient coding, and how to master standards-compliant XHTML 1.0 and CSS 2.1. There are a dozen chapters. He breaks down the elements of Web design into modular components so that one can focus on each element separately, like page structure, content structure, layout, navigation, text control, user feedback, and multimedia. Relevant technologies are explained in context of producing a typical Website.
If one finally decides to move forward, as many suggest, this is a very good volume by which to get your start. For new designers, this is a nice primer to learn what is expected, in an overall sense, of good, advanced Web design.
This is a well-produced book with clear writing, comprehensive approach, dozens of practical examples, and downloadable files with the code examples used in the book. The author writes in a logical sequence much like an engineer would. It is a heavy textbook-like read, only lightly sprinkled with style and personality. It should appeal primarily to novice designers, but has enough advanced information to satisfy an experienced designer who is looking for that fresh start.
And in fact, the structure of the book facilitates the "fresh-start" idea. It starts with a Web design overview, giving an experienced user's tips on what software to use to write code, what browsers to design for, how to build pages from the very top to the bottom. (XHTML, unlike HTML, requires a preliminary document-type definition (DTD) to validate. Only after the introductory section does the first HTML tag appear.)
Like others writing in this area, Grannell firmly advocates designing for standards compliance, usability, accessibility, and last and least, visual design. Marketing Department people may choke on that priority list, but there is no inherent conflict between function and aesthetics; Grannell simply does not spend a lot of time on the aesthetics.
The middle chapters concentrate on modular construction of pages -- the XHTML introduction, the structural elements like text blocks and images, the logical structure of the links and navigation flow, and finally, the stylizing with CSS. Comparisons between pages styled with HTML vs. CSS compellingly demonstrate the benefits and advantages of CSS. There will be no going back once you've decided to upgrade your technical approach.
Basic CSS concepts are explained and illustrated with code samples and screenshots. Grannell describes how to use CSS for text control, navigation, and layouts. There is a broad section on frames and another on forms and interactive components.
The last chapter covers testing and tweaking including how to create a 7-item browser test suite. Strategies overcoming browser quirks are discussed throughout the book. There is detailed technical information, especially in regard to the XHTML introductory section of the page, which I have not seen elsewhere.
There are three welcome reference appendices at the end covering XHTML tags and attributes, Web color coding, and a very comprehensive entities chart noting currencies, European characters, math symbols and more.
Much of this material is covered elsewhere in the growing set of publications about standards-compliant code. This book has the virtue of having a useful overall perspective on Web design and acts as a framework for new designers and converting designers to renew and upgrade their technical approaches.
You can purchase Web Designers' Reference: An Integrated Approach to Web Design with XHTML and CSS from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
That's a long title. It's upwards of five words. We need to stop this trend before we get crap that's fourteen words and requires a pamplet hanging off the spine of the book to print in full. New Books:Old Books Diet Cherry Vanilla Lime Dr. Pepper:Dr. Pepper
Bring back the BLINK tag!
-- jimmycarter
Haha, a web design book being reviewed on Slashdot. Oh, the ironing is delicious.
This begs the question: "Whose implementation does this book emphasize/teach?"
... to launch my CSS3 compliant site.
I setup my cron to push the site live in 2007.
For ANY web designer who has at least some experience with html/css, this is the single most difficult aspect of web design. That is, getting the page to work in all the popular browsers takes the most time and really has no logic to it. What I would like to see is a book that skips all the fluff that we've seen before and goes straight to browser bugs. If they can be avoided in the first pass at making a web site it makes perfecting the final presentation all that much easier.
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
Newer, more compliant browsers, will in time not support the older tags and code;
Yeah that's a great idea. Lets just stop supporting a simple markup and make it impossible to view all the legacy HTML in existence. While we're at it let's force everyone to change to a newer, more complicated standard, even if they have no need for it.
Now I'm all for using CSS and XHTML, but that is because it makes things easier to maintain for me. Calling for browsers to stop supporting HTML, however, is taking it about three steps too far.
So if that is the case, then why the heck doesn't more people do it? I mean, if we assume that people learn to code webpages from books, why do they buy the old shitty books and code their pages with godawful font-tags and something that closely resembles MS-Word-HTML?
With that said, XHTML and CSS is love.
If the developers of Netscape Navigator had this fanatical devotion to the W3C that seems to be popular lately, we wouldn't have tables, scripts, or any kind of styles (neither nor CSS). None of that was in the standard (HTML 2.0) at the time.
I don't understand why designers and technologians keep preaching XHTML. It's at best a kludge. Until you start serving XHTML documents with the correct mimetype (application/xhtml+xml I believe) XHTML provides no benefits over plain old HTML (provided you stick to the spec). Until then, User Agents will continue to accept whatever crap you throw at them, and since you're not using real XML you won't see any errors (except for the rendering).
I coordially invite someone to give me one reason why XHTML (in its current form, served as text/html or text/xml) is better than HTML 4.0 strict? Is closing my link and meta tags really that life-changing?
I need to take a screenshot for future use of this perfect example of both ignorance and apathy.
You obviously have no experience with CSS. In comparison with more modern markup, coding and styling plain old HTML is like making spaghetti _one_ noodle at a time.
Macromedia, Adobe and gang have to push things forward to keep getting us to buy product right. Is HTML now "designed obsolescence"?
& page=1 [csszengarden.com] (Click "select a design to see the style changes). But again I see that as new candy that doesn't really solve problems that neither I nor my viewers are having. [/rant]
No
Jakob Nielson and the gang have pushed us to really boring text based browsing that is a chore to read, and not worth a casual flipping. Why should *I* care if my website is Modem/text based browsing compliant? Sure if I had a research website I can see the point, but my website is a video hosting portal http://videos.streetfire.net/ [streetfire.net] so I doubt the 40,000 folks coming to my site every day care about text based browsing or low-bandwidth options, since the end media is video.
FWIW though I chose 3.0 HTML because it's easier to integrate the 13 ASCX objects into my single ASPX page than if I kept styling separate with XHTML.
Now that if course is just me and maybe I'm bothered by people saying my site is obsolete. I admit there are a lot of neat things you can do with XHTML http://www.csszengarden.com/?cssfile=/152/152.css
PS I used the BR tag too, because I still think the P tag is lame.
-Adam HTML guy since 1994.
Super quick whizzbang explanation:
<b> and <i> are visual tags: they make text look bold or italicised without altering the meaning of the sentence they are in. <strong> and <em> are logical tags: <strong> provides emphasis in web page readers, as well as looking bold, for example. <em> does the same, but renders differently in text browsers. There are other italic tags such as <cite> that are used for citing references, for example.
This page says it better than I do.
Guy asked me for a quarter for a cup of coffee. So I bit him.
Grannell firmly advocates designing for standards compliance, usability, accessibility, and last and least, visual design.
If people keep using HTML, browers will continue to support it. Designing for standards compliance is great, but a crappy website that loads on any standards compiant browser is a lot less useful than a beautiful, usable website that loads on the major brosers like Firefox, IE, Opera and Safari.
Ever heard someone complain about an ugly website that's hard to navigate? we've all done it.
Ever heard anyone complain that standard HTML didn't look the same on all broswers? Not too often I bet.
And standards compliance is great, but with 1) IE having a 90% market share, and 2) IE not being standards compliant, doesn't that mean that most internet users aren't using a standards compliant browser?
And why is that? So people can screen scrap easier because you're content is xml parsable?
I lived by those rules not long ago; tableless design, css driven, no client side javascript events in the html (but put there by an initialization function), classnames never revealing structure information, separating structure classes with lay-out classes in different css, xhtml 1.1, etc.
Where did it get me? Not sure but sticking to all those rules sure costed me much more time then needed. And what for, because browers require that a page validates in a few years? Forget it, not in a decade, not in two.
Advice, stick to clean html that makes sense, think of your customers, think of your bandwith and don't let that w3c run your web development.
Although I haven't read the book this review is about. I recently purchased another book titled Web Standards Solutions: The Markup and Style Handbook by Dan Cederholm and found it very good for beginner's to XHTML and CSS. Even my wife, who's never dabbled in web design before is enjoying it. Also, quite a few of the chapter's in Dan Cederholm's book appear on his website if you want to get a feel for his writing style.
Just a comment as someone who is a "content manager" ie the poor person who has to put the words onto the web designers pages.
Using a database to feed a web site makes things so much easier. Global updates, automatic sorting and reusable elements in other parts of the web. Just because something does not make sense to a coder does not meant it is useless to mere mortals.
>>> all the complicated PHP scripts and ASP pages serving as frontends to database of choice, to serve up what's essentially static information.
Interesting... I thought that, right up until the time that I tried authoring and maintaining a medium-size site (back in the .com days) and earned myself a rude awakening.
In my experience (YMMV) it is far, far easier to create an infrastructure capable of doing everything you want and to serve content dynamically within that infrastructure, than it is to edit more than a very few pages by hand. Now there is a good argument for serving static (cached) versions of dynamically created files where this is possible, and a lot of sites do just that.
Whoever told you that Firefox was "100% compliant" was selling something.
Firefox whiffs some CSS2.1 rules among other things.
there's more than one way to do me.
XHTML 1.0 became a W3C Recommendation on 26 January 2000, meaning it has been around almost as long now as HTML was when it came out! (Well, at least, almost as long as HTML had been in popular use when XHTML came out).
The only excuse for not using XHTML today is laziness and ineducation on the part of designers and those educating them. The same reasons most web sites don't validate as proper HTML. Sadly, "just good enough" is the rule of the day.
Having said that, using PHP and other dynamic mechanisms to "code around" browser bugs, by implanting "patched" tags or using alternative mechanisms where something is seriously broken, is definitely the most practical solution.
You can use Apache SSI's to detect the browser and then #include the appropriate page, but that is extremely expensive on maintenance. It is much more practical to embed markers wherever you might need to deviate from the "correct" HTML and simply use a script to search & replace.
For those pages that genuinely do have dynamic content, you can have a background engine generate static pages every so often, which you then serve, avoiding a continuous rebuild. However, you run the risk of race conditions, where you try to serve a page that is part-way through a rebuild. The result will be the display of a broken page, which is definitely a Bad Idea.
Really, the "correct" design is to use a mix of approaches. Use static methods for static content, use dynamic methods for dynamic content, use pre-built pages where downloads are more frequent than updates. Hammers are great for nails, but you wouldn't use them in place of a saw or a screwdriver.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
database backed webpages are a trap and a bottleneck. Notice that Slashdot generates static pages from comments. Databases are not a limitless resource and notice how many webpages get sucked into the "No more connections" trap when you visit them from Slashdot.
Now people will argue that a server is not scalable either, but you can always have 5000 servers serving up that same static data. You really can't expect 5000 servers to access a single database and expect the database to survive.
Databases are needed for some webpages, but don't throw them in as a simple shortcut.
Many things are wrong with current HTML. Well, ok, not CURRENT HTML (4.01) but everything before that.
Since XHTML is just a reformulation of HTML 4.01 into XML, and XHTML 1.1 is just a modularization of XHTML, technically nothhing is wrong with HTML as it exists today. But what about how it exiists tomorrow?
XHTML allows for the easy expansion of the language. Right now, DOCTYPES are the only way to define what version of HTML you're using, which makes it an all or nothing proposition. What if you want to use HTML + SUPERCOOLHTML-Extended? XHTML 1.1 allows you to basically define your own syntax, and more importantly allow the standards body to do so easily).
This way you only have to use as much of the standard as you want to, and if there are two competing standards you can actually choose which one (or ones) to use in a way that the browsers can understand.
Now, i'll grant you that for the typical "my cat fluffy" site, they don't give a rip. HTML 4.01 is just fine. But did you know that HTML 4.01 strict doesn't have font tags? It doesn't have the target attribute on links. It doesn't have a lot of stuff you're used to that are going away.
It's best to get used to XHTML now, HTML won't be improved, but XHTML will.
If you need web hosting, you could do worse than here
I did a page layout on eBay for an older retired friend who makes wooden toys. I used the normal .css file and div tags -- it looked like crap and was unusable. I had to go back to the drawing board and use tables! (Tables, nested in tables to get the same layout)
Most of the internet might be ready for bleeding edge stuff, but don't toss away your plain 'ole vanilla flavored HTML just yet.
Newt-dog
My Doctor prescribed daily nasal saline irrigation, hehe
That said:
Garbage. The amount of code necessary to support basic HTML is so tiny amidst the vast beasts major broswers have become that there's no reason to dispense with it. And why use anything else when straight, primative HTML is still the most effective tool for conveying simple information?Crow T. Trollbot
What I like to do:
.htaccess mod_rewrite rules to make the pages look static (blah.php?pageID=24&whatever=1 becomes blah-24-1.html)
On local development server:
- Create database to store data
- Create scripts to make the pages
- Create
Then I use wget to save a static version of the website, then upload the static version to my webserver. Some advantages:
- Less resources needed on server
- HTML template easily changed if required
- Extremely fast script development time, since there are no security checks required
- More secure than PHP scripts on a server could ever be
Obviously this method won't work for websites that require user input (like polls), but I think not having to worry about the security of live scripts is awesome.
There are plenty of other reasons.
Like 90% of the pages out there don't need it.
99.99% of mine don't. All I need is my trusty hammer and screwdriver, and you're trying to insist I use a fully automatic, 50 calibre nailgun and a 3HP power drill with screwdriver attachment.
Uhm, with some caching it doesn't matter. Cached content feeding from a database is fine IMO...
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Are you forgetting the NS4/IE incompatibilities and proprietary tags that plague the web to this day?
The fact is, when W3C came along, the web was seriously broken. Those of us that are so outspoken on standards are generally those that have been on the web long enough to remember how broken it was when non-standard HTML ruled the day.
Just curious, after reading the fine article, then doing a little research and reading a couple chapters of the w3c documents I wonder that anyone would change to xhtml for the sake of canonical righteousness.
Seems to me there are reasons to do xhtml... I DO like the idea of well formed objects, especially things like web pages... at least if it's well formed you've eliminated one source of nasty little bugs creeping into sites, especially sites creating pages dynamically.
But, for sites already rolled out and wrung out in public forums this seems prissy. And problematic. Consider:
I've done an informal look-around, and found some popular and quite famous (hmmmm, a particular site comes to mind...
So, academically maybe a good direction to consider, but the predictions of html going away to be supplanted by xhtml is premature, and I predict something that in our internet lifetimes will never happen.
Personally I think HTML is beautifully simple. My own site uses vanilla grade HTML,a little JavaScript and some basic CSS. That is sufficient. I'm not running an online storefront or something. I have shown extremely computer illiterate people to write their own HTML pages - and one is running 4 busineses from his own website now for 7 years, with no more handholding from me.
All this PHP, ASP, Today's 3-letter buzzword is mostly HYPE, so "web developers" can stay aloof and whine for more $$ every budget cycle. We need faster, bigger servers to cough up all this bloat, newer browsers to sift through all this crap and spew it up to the user's screen in some useable form. Many of these pages render badly, wrong, or not at all. Countless ones refuse to print or print so f*-ed up it makes the information they offer completely useless.
I don't know about you but I know, er used to know, quite a few people who have have some sort of handicap or disability, I have a big one myself, and using "vanilla grade HTML,a little JavaScript and some basic CSS" without a lot of spagetti code just doesn't work. Now I'm not saying all these acronyms make things neccessarily easier and more usable but used properly they can.
Falcon FalconShould there be a Law?
XHTML is a good idea but have you noticed how verbose and complicated it's gotten?
d ">
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dt
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
versus:
<html lang="en-US">
<head>
The US Army: promoting democracy through unquestioned obedience
Now people will argue that a server is not scalable either, but you can always have 5000 servers serving up that same static data. You really can't expect 5000 servers to access a single database and expect the database to survive.
Of course other people may argue that the solution would be to take those 5000 servers and divide them up: run a database service across a few hundred of them, have a few thousand web servers that do the real request processing and then let the rest of the machines be web-facing machines that cache the results for a few seconds to decrease load on the real webservers.
UK Webhosting http://xeriom.net
Yeah, it's impossible to add extra database servers.
:)
It's also unlikely that one could find a database server that can cache the results of identical queries when the data hasn't changed, significantly speeding up access to nearly-static data.
It's downright insane to consider using proper cache-control headers and a caching proxy in front of a web server farm.
It's sure too bad that these solutions can't be solved by merely hiring a competent sysadmin who's willing to relocate, 'cause that's be far too convenient.
It'd probably be easier to teach everyone in the company good HTML.
First of all, this is not a troll. I read the review and thought about buying the book, so i surfed at +4 trying to find more reviews of the book, or even better, comments like "wait, this book is better, bla bla". But I only found trolls about why XHTML or XML or HTML4.01 or whatever is the *best* solution, and some useless posts about why PHP is better than ASP. Then i surfed at -1, and read all the freaking comments! And I CANT FIND ANYTHING RELATED TO THE REVIEW!!! All the wasted time.. all the offtopic flamebait etc etc I had to read. So, can SOMEONE please write a useful comment? Is this book actually good? Are there better books out there for teaching good XHTML+CSS2 to someone that has some experience on html?
Try using some HTML formating progams like HTMLTidy. They really reduced the work for me when I had to do a job similar to yours.
Binny V A
I don't see what XHTML offers me that HTML4+CSS doesn't. I've been "separating code from content" from the day I could dismiss the font tag, I don't see what XHTML offers to a non-programmer (I don't think using markup==programming and I know I'm not good at anything that requires more thinking than that...).
I think, therefore I am...I think.
"For years practitioners used the Web and its language, HTML, as a free format and layout platform for forms and documents (often as paint for software applications)."
You can use a drinking-well as a urinal, but that doesn't make it a good idea. And it certainly doesn't mean you'll get anything worth having out of it later.
The fact that HTML (and browsers) allowed such horrible, buggy, quirky markup has done more to retard content aggregation and the further development of the web than practically any other force in computing.
Sure, in the early days it made sense to keep the barrier to entry low, to get people on-board. It fuelled the growth of the web, and allowed any idiot with five minutes and Frontpage to put up a page announcing to the world what a L33T h4xx0R they were in bright clashing colours on an unreadable patterned background.
This is akin to offering people a blank sheet of paper instead of a form with distinct questions and answer-boxes - useful, because they can write whatever they want and don't have to think about it, but much, much harder to do anything with later.
There's a reason we have paper forms, and a reason all non-trivial data is stored in some form of database[1] - unstructured information is useless. It only becomes useful when it's structured - when it stops being just information and becomes data
Why is XML/RSS/ATOM more tightly-structured than HTML? Why can't we straight aggregate HTML instead of having to invent a new file format? Because HTML is now fundamentally broken for automatic syntactic parsing of data.
"Then along comes the W3C to proclaim to those practicing this craft: "HTML is not a format and layout language"."
It isn't. Or, at least, wasn't intended to be - HTML was originally envisioned by Tim Berners-Lee as a semantic markup language - it's only later development and the commercialisation of the web that lead to it being almost exclusively presentational. A new effort (the Semantic Web) is now being made on this front - old, broken, misused HTML is being retired in favour of semantic XHTML, CSS for presentation, javascript/ECMAScript for interactive behaviour and XML for interoperability/data representation. All open languages and standards, you'll note.
"They then proceed to break all the existing code that's out there in the name of that proclamation."
What's broken? Show me a mainstream browser that doesn't passably support all the way back to HTML 1.0. Sure, it entails some extra work for the browser manufacturers, but I find it hard to feel bad for them, since they (with lax enforcement of HTML grammar, proprietary extensions and the like) contributed so hugely to the mess in the first place.
"It may be coincidence that the W3C is filled with representatives of companies who make billions of dollars selling what are essentially formatting and layout platforms for forms and documents... "
Oh please - this is the worst tinfoil hat argument I've ever heard. Oooh, oooh, the companies who benefit from breaking interoperability, introducing proprietary extensions and generally grabbing the fast buck are pushing more interoperability, stricter standardisation and long-term game-plans that drastically improve the entire architecture of the net. Sorry - not following you on that one.
If it was really an industry cartel dictating the future of the web for their own ends, XHTML would have been replaced with an unreadable binary format, with unlimited proprietary vendor- and platform-specific extensions. It would be incredibly difficult to learn, rather than basically identical to HTML but ever-so-slightly stricter. They certainly wouldn't be publishing and pushing the standards for free - they'd be charging for them, attaching licence conditions to them. And they wouldn't be providing on-line validators for free - you'd be expected
Everything in moderation, including moderation itself
A good analogy is mathml. For decades most scientists use latex to type the text, then somebody came up with the idea that the formulae must be searchable and presented in a form that computer must understand. Why? What useful purpose would it serve? How I as a user can benefit from it? How many readers of the online journals are going to search for a particular fragment of the formula in the online paper?