With CSS on, NS4 crashes about 5 times as often. It's hard to pin down where that is because I've seen it crash on pages w/o CSS after having visited some with. It probably is using some memory after free().
It may well be that the RBLs can't handle the load. I only described how the load would be larger by many orders of magnitude because of the fact that each mail server using an RBL is now seeing a much larger number of different connecting addresses during the cache lifetime of an RBL lookup answer. So yeah, there is a huge load, and perhaps they can't handle it. I don't know that there isn't additional DDoS load, but I can certainly see where the querying load would be scaled so much larger during these kinds of virus attacks.
It is my understanding that infected machines are also now open proxies for spammers, and maybe even spam proxies (e.g. connect, send message, then send IP and email address pairs to spam to).
Relying on things like Bayesian filters greatly increases my cost and load. I already block 99.5% of incoming spam attempts before accepting any data. And no, my mail servers cannot handle 1000x what they are getting now. They could perhaps go to 10x. I have 3 mail servers now. If the load doubles, I either lose my burst margin, or have to add more servers. No thanks. What I am doing now is extracting from my logs all addresses that have had mail rejected since 1 August 2003, and placing those addresses in a "permanent" local blacklist. I'll delete that only after the attack ends. That's my part to help reduce the load on them.
I know how CSS basically works. The problem is that without a CSS compliant browser (NS4 is not one), you lose the presentation. I don't want to lose that, yet I want to support such browsers (for now... that will eventually change). So that means my presentation has to be in HTML.
Also, the older NS3 (and probably IE3, but I don't have one of those around) is incredibly fast at rendering nested tables. On a 100 MHz Pentium, NS3 was faster than what NS4 does now on an 800 MHz Pentium-III.
NS4.7 is still broken in CSS. It causes many segfaults (perhaps specific to certain bad CSS code or CSS interpreted HTML). So CSS stays turned off.
In fixing those 12,000 pages, are you going to widen the range from that middle of the road approach? Or are you going to shift the center upwards and favor the rich (who have medical insurance) over the poor (who don't, and don't pay their hospital bills, either)?
The problem is, people with VoIP services want to be able to call any phone number. That means VoIP service providers are really gateways to the telco network. And that's where the tax comes in.
What we need is basic IP access with sufficient bandwith to all end users, static IP for everyone (need to move to IPv6), and then we can do VoIP on an end-to-end basis by "dialing" someone's hostname (with end user aliasing to make it easier to call friends). Then we won't need those gateways.
Greedy governments will still try to tax it. But if everything is hidden in end-to-end authenticated encryption... oh wait, they'll start taxing encryption.
No, you have it backwards. The correct analogy of my statement, in the application software arena, would be "If you want the largest possible user base for your application, then develop it for Windows, Mac, and Unix with X windoes (AIX, BSD, Linux, Solaris, etc)". It's the people who say to develop only for the majority that would justify making software for only Windows.
As for Lynx text colors, that itself can introduce accessibility problems. I happen to have a certain vision problem related to colors that doesn't allow me to see certain color combination boundaries (I can actually see all colors very distinctly, but the boundaries are a mess, much like chromatic aberration). To deal with it, I have changed the pallette of 16 colors to a special set of a few shades of a few colors. Some programs still revert the pallette back, and I can't use those programs. Others think they are using the original 16 colors, and they end up sometimes with still unusable parings. Leaving colors off entirely makes text fully readable to me.
It is sad that browser developers are lagging web designers. I do think it should be the other way around. They should have put CSS in NS3 and left out the bugs. But the software development field is still so horribly screwed up (which is why I stayed out of it and went to system and network administration).
Obviously, our standards of what "works just fine" means is not the same. I do know about the broken CSS support in NS4. Add to that it is buggy and can crash the browser process, too. So I leave it off.
Maybe game makers should not hold back just for you. It's their decision to determine what part of the market they want to go for. Typically I expect them to reach for the sky. But a state or federal government web site intended for all citizens must have an entirely different goal. And clearly they will end up having to carefully balance between browsers that can't work with new standards, and browsers that can't work without the new standards. And they must balance between having loads of detailed HTML, and slowing down the experience of people stuck on a 9600 baud modem (yes, they are still around). Such balancing acts are at best going to be changing from day to day or month to month. And what the site is for may affect what way the balance tips. A site for filing income tax forms needs to worry less about mobile access. A site giving up to the minute Homeland Security news needs to worry more about mobile access.
My code isn't problematic. It's bigger, but it works everywhere I have seen so far. I'm sure eventually some browser will stop supporting tables, or break that support in some way. That hasn't happened, yet.
You are definitely successful at making your site readable in CSS-turned-off NS4. That's a whole lot better than some others (who probably think they are doing things right, but clearly are not). Now, while it is readable, that's not the way I want my site to appear, at least for now.
One problem to watch out for in older browsers is making pages with forms. The forms elements will overrun tables if the tables are forced to sizes that don't fit the forms. Since your site doesn't use tables, it should be OK (the next text after a form element might be below it). That K10k site showed overruns of the form elements. But I didn't analyze why in that case. I'm worried that CSS boxes might have the same problem. When I do put form elements in table cells, I make sure the table cells are dynamic size so they fit. I avoid fixed size tables as much as possible because there are things to be rendered that might not fit in certain circumstances (such as users using huge fonts to deal with vision problems). Also, fixed size in terms of pixels shows up quite different in browsers in a 400x300 window than in browsers in a 2000x1600 window.
I'm glad you don't use JavaScrap in your web sites. I don't either.
On their slow computers, the older browser renders fine. It's the newer browsers with their many deeper layers of object abstracting in the code that run slower on the new browsers. I benchmarked NS4 as 22.5 times slower than NS3 at rendering nested tables. So NS3 can handle my table based pages back to very very slow CPUs. NS6 was more than 4 times slower than NS4. NS3 had a nice tight (although buggy) rendering engine.
Feel free to look at my site and tell me how you would do it. But I want it to generally look the same in my NS4 browser that has CSS disabled for integrity purposes. I'm going to be re-designing the whole site soon, to include customization, so any ideas you have would be nice. But if they include CSS, then I probably won't use that for at least another year or so.
CSS in NS4 is broken. Numerous elements of stylesheets are not handled as expected. Also, NS4 crashes frequently when accessing CSS pages. It is necessary to leave CSS disabled in NS4. So NS4 is equivalent to a browser with no CSS (because it has a broken CSS).
I'm less worried about making "quirk" pages render nice than I am about making standards compliant pages render nice. But the biggest problem remains that the browsers themselves are not shedding the fat, and that is part of why the progress forward to better standards is being slowed down.
I don't know what is in Firebird, either. But I did manage to make a quick look over some of the code, and I what I saw didn't seem to be necessary for a browser.
A List Apart is my example of a web page that looks like crap in some browsers that are still used today. He hasn't bent any rules in making that site. If we could have better browsers for everyone, then I'm sure his page would look fine everywhere, for everyone, and we can use it as a model for good design. And you can do that today, if your needs do not include making web pages work well for people stuck on older browsers.
Of course as more use of other methods of viewing take place, things do have to change. And Zeldman's information helps us prepare for that day. For some, that day is here now. For others, it is not.
Of course new standards are a whole lot better than HTML 3.2. But depending entirely on the new standards while you need to display well in older browsers that don't support them is the problem. And again, I say, the solution isn't going to be finding an answer to the debate about how to design pages... standards compliant is the way to go... the solution is to fix the browser problem... so that web page design can move forward for everyone.
One of Zeldman's own web sites doesn't even work right in NS4 at all. His personal standard is that anyone who uses a browser that makes him, the designer, have to work a little harder to support, isn't someone he wants in his audience, anyway. His reaction will simply be "upgrade" without considering any of the implications of that. I take a different approach. I put in some effort to make things work more universally. I've seen how Zeldman's own development comes out crappy in NS4. I don't want that for my sites.
You say "complex layouts" for browsers v4 and under. I take that to mean you consider using a few layers of tables to be "complex". OK, so be it. But how do you expect to get a decent site without that? Oh wait, you don't care about that. I know Zeldman doesn't, because he told me so.
Nested tables do get big, but not that big. And there's no way to do certain things in older browsers without them. If you think you can, I'm open to looking at what you have.
I have no trouble doing table-based layouts. Mine work fine and I can visualize just how they work, and what can and cannot be done with them.
I don't dismiss standards. They are good things. What I'm saying is that in certain cases, they can't be used at this time because those cases involve requirements that are incompatible with the current deployment of browsers that don't support the standards. The real problem is the browsers. If all browsers supported the standards correctly, we wouldn't be here debating this. But the fact is some don't, and some people still have to use them because the new browsers won't work in their situations. When either those situations change, or the programmers work on making leaner browsers (and operating system distribution configurations to run them), then we can have a case of virtually all browsers running will support the standards (hopefully correctly). But there will still be one problem: as soon as that comes to pass, there will be new standards, and the lower end of browsers then won't support those new ones.
What I mean by just barely complying with standards is that the browser developer is not to go adding anything else to make it work beyond what those standards specify. That includes adding no features, even if they are proposed for a new version of standards yet to come out. In other words, it needs to be the most minimalist browser that can still be compliant.
I don't believe browsers are bloated because of new standards. Instead, I think browsers are bloated because developers are always trying to one-up each other in adding in new features to make their browser become the one most people use. And for those who want such browsers, fine.
As for making standards compliant web pages that work in older browsers, sure, I've seen it done, too. I did it using a standard called HTML 3.2. I've also seen a site Zeldman set up, which he has claimed is a model for his development methods, that looks like crap in NS4. To me, that's not "working". It's certainly not compliant with my personal standards of good site. And the stories section doesn't even work to any extent at all, showing nothing but a blank gray page.
In regard to your statement...
But if your site IS about information, then you're shutting out FAR more of your potential audience by saying "It's going to look good in legacy browsers, dammit" than you are by saying "Legacy browsers get all of my content, but not my presentation."
... I have to disagree. Choosing between whether my site looks good or looks crappy in an older browser, while it looks the same in a newer browser, isn't going to shut anyone out, as long as my choice is in the "good" direction. I'll setting for making it look good for everyone.
One reason for this is because I do know that style and presentation is as useful in information as it is in other content goals. Things like having a gray background combined with images that were designed for a white background, just because the web designer wants to specify the background color in CSS and NOT specify it in HTML, create distractions. They bother me when reading a site. And I know I can do better by making the correct background color work everywhere.
As for Mozilla Firebird, that thing is still way too big. The programmers who write today's graphical applications have an obese mindset. And I was generous with the 2 MB requirement. It really should have been 1 MB. A source tree that is 220 MB (after uncompressed) and 1703675 lines is just way too big. There's got to be more in there than just complying with standards.
Then I guess I can't do a review of your web site. Sure, you have it easy with a one-browser audience. But if you wanted to make a site look good in a wide range of browsers, including older ones, then things like CSS cannot be depended on exclusively. But if you don't care if the site looks like crap in an older browser, then using CSS won't be a problem for you. It depends on what your goals are. Zeldman's ways don't work for everyone.
You say to pick one standard and use it? Well, I pick HTML 3.2. So there. Now why didn't I pick any version of CSS, or XHTML? Well, simply put, my goals are to make a site not only work, but work better than just barely working, in older browsers that are still in common use. And right now based on logged User Agent data, that looks like back to Netscape 3 and IE 4. And the goal of a state government, unlike a corporation, is to make things work for all citizens of the state, including poor ones that are given old hand-me-down computers (often donated by those corporations).
CSS certainly has many benefits for the designer. And as long as your target audience is using browsers that support CSS correctly, you should use it. And for many corporations and person web sites, that's fine. Where I think CSS still needs to be avoided is where the goals are so broad that users w/o CSS capable browsers still need to be accomodated. Where we will probably differ in opinion is just how good the site will need to be in say NS4. Some will accept default gray backgrounds, sloppy layout, and mangled color schemes, so long as the text is readable. My goals are higher than that, so the philosophy of doing nothing else but CSS cannot be used since it cannot achieve my goal.
I think you still misunderstand the older computer problem. That older computer can't run a new OS. It can't run a new browser. Or in cases where it can be squeezed in, it's too slow to be comfortable. Try Mozilla on a 25 MHz machine. The older browsers like NS4 and NS3 actually render tables faster. I actually stayed with NS3 for a while back when I was on 100 MHz because NS4 was just too damned slow at rendering tables (I benched NS3 as 22.5 times faster than NS4 on a deeply nested table).
I won't dispute that CSS would be faster than the corresponding same thing in raw HTML. But if you can't get a browser working that does CSS right, or at all, and won't die when it sees it (like NS4 does), then you're basically locked out and have to limit your browsing to what works. Some sites can be made to work in NS4 anyway, but look ugly in the process. Mine will look nice in NS4.
As for coding for different browsers, the only difference I have ever done is graphical vs. non-graphical (e.g. lynx). Look at linuxhomepage.com and see.
My goal, which may not be what the standards set as a goal, is to do the best that a given browser can do with a common set of code. What I end up seeing is stuff like no background color at all in some of these sites in Netscape 4. That's because the background color was put in the stylesheet and NOT put in the HTML. But if it were put in the HTML, then it would still work on both old and new browsers, and work better in the older ones compared to leaving it out.
CSS is the way of the future...
I'll agree with you on this. Now we need to debate whether CSS is the way of the present.
The reviewer cited a goal that was to make the web site work in as many browsers as possible. The goal statement isn't entirely clear. He needs to define what "work" means. If he's willing to give up looking as good as a given browser can look, in order to achieve standards compliance, and has a goal of merely making sure the text can be see, then his goal is not the same as mine. But I've seen people who do things with this total standards compliance goal and come up with totally a totally crappy site.
As for K10k, I do see a lot of layout on this page, but I can't tell if you've completed it or not. It looks like a nice design, but it lacks content. Here (and scrolled) is what it looks like to me in Netscape 4 (with CSS off, because it is unsafe to browser in NS4 with CSS on due to bugs). I certainly wouldn't call that usable (but like I say, I don't know if this is "under construction" or not... it looks like a half way done site). I included the scrolled down image of it so that I could also point out the fact that the form elements are out of bounds of what appears to be areas where maybe it isn't intended. I see many sites where the designer tries to fix things to a specific number of pixels, and this simply does not work on the web unless you can make those be images and control them exactly (which can be done for the submit button, but only in a limited way by changing font for the input fields and drop down menus).
What this K10k page does in NS 4 is certainly not what I want to let happen on any web page I design. This page does a lot better in NS 3 and 4, as well as IE 4, 5, and 6, and even Gecko, Konq, and Opera. I'm happy with it because I got what I wanted. Of course it is table driven, so NS 1 is out of luck and will have to use the Lynx version. But at least there is a link to that.
Netscape 4 is dead: don't worry about it beyond getting your sites to still be legible in it.
People who follow these standards have made web sites that are totally illegible in Netscape 4. I, OTOH, have made sites that not only display nicely in the new browsers, but also display equally nicely in older browsers back to Netscape 3, and are easy to maintain through the use of configuration settings using PHP. And that was doing without even checking the value of User-Agent at all.
I don't consider it to be acceptable to tell the end user that it is the fault of the browser when: 1: they cannot upgrade the browser for some (often legitimate) reason, and/or 2: I could make the page work just as well in their browser.
As for newer browsers: Netscape 6/7 is just too obese (and too much ad crap). Mozilla is also too obese and slow. Konq works reasonably well, but it refuses to run as separate processes while still segfaulting on occaision (which is why I like to put each browser instance in a separate process, to avoid losing everything from segfaults triggered by one site).
What we need is a lean browser that just barely complies with the standards, and does nothing more than that in its base version. It needs to have a small footprint (2 MB max) and leave out the damned JavaShit.
Since Netscape 3 doesn't support CSS at all, and Netscape 4 has a broken CSS, I wonder what it is you did to get your site to display correctly on those browsers (assume CSS is turned off on Netscape 4 so my process won't segfault and take down all my Slashdot windows). Can you put a test/demo page up somewhere? Or is the site totally secret until released (at least tell us when and where that will be).
Based on discussions I've had with Zeldman, I will not read his book at all. The site he demonstrated as adhering to standards (about a year ago or so) was total crap in the browser I use. His goals in web site design (minimize the work the designer has to do or make the transmission as small as possible), and my goals (make the web site not only work, but work well, in as many browsers as can support what I'm trying to do), simply are not the same. Therefore his methods are of no interest to me. If someone were to give me his book, I'd sell it on Ebay as "never opened".
Your site looks like crap in my older browser. Oh wait, you didn't tell me where your site is. OK, so I'm guessing. But most sites that do things like this have these problems. OTOH, your company's intended audience may not include people using older browsers. Your web site; your rules (just don't make rules in ignorance).
BTW, I was able to simplify my color and other themes without XHTML or CSS. I just used PHP and set some variables. It won't gain you the faster loading times that CSS will, but it can make maintenance easier.
However, not all browsers support XHTML and CSS. Older browsers, which people of limited means are stuck with because they don't have the computer capacity to support the obese new ones, don't support those. Sites intended by commercial businesses marketing to people with good economic means don't need to worry about accessibility to the economically disadvantaged, so they can go ahead and disregard them and use those standards. But if your goal is to maximize access to all, as the book reviewer's needs were, then you have to deal with the reality that the new standards are not supported, and attempts to use new standards on older browsers can often be worse than just using the old standards everywhere.
If you want the largest audience possible, then using the latest web standards, such as promoted by Zeldman, is not what you want to do. The reason for this is because not all web browsers in current use work with these standards. And there are many reasons people won't or can't upgrade those browsers.
There is a way to make web pages so that they can use standards, and still work on older browsers. However, you might not like the end result. What you get on the older browsers is a very poor presentation. For example, if you define the look of your page in cascading stylesheets, when viewed on a browser with no support for CSS, you get crap.
Boundary conditions are even worse. If the browser is a version that tries to support something, and does it wrong, you can get even worse that crap. It might not work at all.
Mixing standards can cause problems as well. Here is an example. Lots of designers seem to like blue backgrounds for the side rail menus. But lots of web browsers default to blue for hyperlink text. If you specify the color of the text in a stylesheet, but specify the background color of a table cell (or worse, the whole page), in HTML, then you can end up with a situation where some of what you specify is acted on, and some is not. You'd end up with blue text on a blue background, and therefore unreadable.
It would be great if everyone could upgrade to the latest browser. But if you are trying to reach the widest audience possible, you do have to consider that many in that audience will be using older computers which have smaller drive space, smaller RAM space, slower CPUs, and can only run older versions of operating systems and browser software. While Linux might well be a great replacement for old versions of Windows on those machines, you still have the problem if shaving a recent version of some Linux distribution down to fit, and getting a huge obese browser to run on a tiny, slow, machine.
Here is an example of a real web site done in a way that displays terrible on some browsers. You can see what it looks like in Netscape 4 in PNG, or JPEG, or true color GIF (works on Netscape 2 and later) formats. If you scan very close in the blue area on the left (this does not work with the JPEG image), you can see that the colors are #5a61a9 for the background, and #5b61a9 for the text (specified by their HTML in the body tag, so they intentionally did this). By radically exaggerating the red plane (e.g. everything #5a and below is made #00, and everything #5b and above is made #ff), you can see (PNG, JPEG) the text was really there. And you'd think that a state government would be concerned enough about making their site available to all audiences, including the economically disadvantaged who can just barely even get a computer and internet access. But no, they don't actually care (I talked to these people, and they really don't care). Here is another crappy web site. By comparison, this site and this site look fine in this older browser.
I'll agree that when a whole group of people get blocked because one person in their IP range spammed, there is a problem. But the responsibility for there being a problem that escalates to more of the network being blacklisted belongs to that network administration for not having corrected the original spam problem that persists. Despite being blocked, spamming takes up resources. By being blocked it is a little less, but it is not zero. The goal is to get that spammer off the network. When the other users of that network refuse to pressure the network operator to fix the problem (often due to FUD and blame from the network operator, and ignorance by most users), they are just making things worse, not better. There is an intent behind expanded blocking and in many cases, the goals (get the ISP to clean up its act) have been accomplished.
In cases where we are talking about Microsoft Windows servers, and Microsoft has released patches and/or service packs to fix problems, and/or configuration options exist to exclude problems, then if the system is under the care of an MCSE and it isn't fixed, I'd certainly blame the MCSE. But I suspect most of them are not under the care of an MCSE, and many under no care at all.
And some of them might be running Linux, including very old versions that are quite vulnerable and have probably been 0wn3d and r3-0wn3d for a long time.
Oh it's you again. You're still pissed off because your ISP harbors spammers and you think that you're not somehow supporting that by helping your ISP stay in business.
As to your statement about Bayesian filtering... there are many negative effects. First, it works on the basis of content. What makes mail be spam is not what the content is; it's that the senders are using bulk methods to send to people who didn't want it. I do get some mailings that I have optted in to, which if they were sent to people that don't want them, would be spam to them. Bayesian filtering doesn't work on the basis of what spam really is. Secondly, to even use Bayesian filtering, it becomes necessary to let the spam arrive, using up network and server resources as it comes in. Then the Bayesian filtering has to be run which uses up even more server resources. And finally, if it is considered spam and rejected, then a bounce message has to be queued (taking up disk space), and delivery of it has to be attempted (which for most because it is from real spammers, cannot be delivered, and takes space and delivery attempts for several days). So I will never use Bayesian filtering because it is simply all wrong.
Slashdot Mirror
With CSS on, NS4 crashes about 5 times as often. It's hard to pin down where that is because I've seen it crash on pages w/o CSS after having visited some with. It probably is using some memory after free().
It may well be that the RBLs can't handle the load. I only described how the load would be larger by many orders of magnitude because of the fact that each mail server using an RBL is now seeing a much larger number of different connecting addresses during the cache lifetime of an RBL lookup answer. So yeah, there is a huge load, and perhaps they can't handle it. I don't know that there isn't additional DDoS load, but I can certainly see where the querying load would be scaled so much larger during these kinds of virus attacks.
It is my understanding that infected machines are also now open proxies for spammers, and maybe even spam proxies (e.g. connect, send message, then send IP and email address pairs to spam to).
Relying on things like Bayesian filters greatly increases my cost and load. I already block 99.5% of incoming spam attempts before accepting any data. And no, my mail servers cannot handle 1000x what they are getting now. They could perhaps go to 10x. I have 3 mail servers now. If the load doubles, I either lose my burst margin, or have to add more servers. No thanks. What I am doing now is extracting from my logs all addresses that have had mail rejected since 1 August 2003, and placing those addresses in a "permanent" local blacklist. I'll delete that only after the attack ends. That's my part to help reduce the load on them.
I know how CSS basically works. The problem is that without a CSS compliant browser (NS4 is not one), you lose the presentation. I don't want to lose that, yet I want to support such browsers (for now ... that will eventually change). So that means my presentation has to be in HTML.
Also, the older NS3 (and probably IE3, but I don't have one of those around) is incredibly fast at rendering nested tables. On a 100 MHz Pentium, NS3 was faster than what NS4 does now on an 800 MHz Pentium-III.
NS4.7 is still broken in CSS. It causes many segfaults (perhaps specific to certain bad CSS code or CSS interpreted HTML). So CSS stays turned off.
In fixing those 12,000 pages, are you going to widen the range from that middle of the road approach? Or are you going to shift the center upwards and favor the rich (who have medical insurance) over the poor (who don't, and don't pay their hospital bills, either)?
The problem is, people with VoIP services want to be able to call any phone number. That means VoIP service providers are really gateways to the telco network. And that's where the tax comes in.
What we need is basic IP access with sufficient bandwith to all end users, static IP for everyone (need to move to IPv6), and then we can do VoIP on an end-to-end basis by "dialing" someone's hostname (with end user aliasing to make it easier to call friends). Then we won't need those gateways.
Greedy governments will still try to tax it. But if everything is hidden in end-to-end authenticated encryption ... oh wait, they'll start taxing encryption.
No, you have it backwards. The correct analogy of my statement, in the application software arena, would be "If you want the largest possible user base for your application, then develop it for Windows, Mac, and Unix with X windoes (AIX, BSD, Linux, Solaris, etc)". It's the people who say to develop only for the majority that would justify making software for only Windows.
As for Lynx text colors, that itself can introduce accessibility problems. I happen to have a certain vision problem related to colors that doesn't allow me to see certain color combination boundaries (I can actually see all colors very distinctly, but the boundaries are a mess, much like chromatic aberration). To deal with it, I have changed the pallette of 16 colors to a special set of a few shades of a few colors. Some programs still revert the pallette back, and I can't use those programs. Others think they are using the original 16 colors, and they end up sometimes with still unusable parings. Leaving colors off entirely makes text fully readable to me.
It is sad that browser developers are lagging web designers. I do think it should be the other way around. They should have put CSS in NS3 and left out the bugs. But the software development field is still so horribly screwed up (which is why I stayed out of it and went to system and network administration).
Obviously, our standards of what "works just fine" means is not the same. I do know about the broken CSS support in NS4. Add to that it is buggy and can crash the browser process, too. So I leave it off.
Maybe game makers should not hold back just for you. It's their decision to determine what part of the market they want to go for. Typically I expect them to reach for the sky. But a state or federal government web site intended for all citizens must have an entirely different goal. And clearly they will end up having to carefully balance between browsers that can't work with new standards, and browsers that can't work without the new standards. And they must balance between having loads of detailed HTML, and slowing down the experience of people stuck on a 9600 baud modem (yes, they are still around). Such balancing acts are at best going to be changing from day to day or month to month. And what the site is for may affect what way the balance tips. A site for filing income tax forms needs to worry less about mobile access. A site giving up to the minute Homeland Security news needs to worry more about mobile access.
My code isn't problematic. It's bigger, but it works everywhere I have seen so far. I'm sure eventually some browser will stop supporting tables, or break that support in some way. That hasn't happened, yet.
You are definitely successful at making your site readable in CSS-turned-off NS4. That's a whole lot better than some others (who probably think they are doing things right, but clearly are not). Now, while it is readable, that's not the way I want my site to appear, at least for now.
One problem to watch out for in older browsers is making pages with forms. The forms elements will overrun tables if the tables are forced to sizes that don't fit the forms. Since your site doesn't use tables, it should be OK (the next text after a form element might be below it). That K10k site showed overruns of the form elements. But I didn't analyze why in that case. I'm worried that CSS boxes might have the same problem. When I do put form elements in table cells, I make sure the table cells are dynamic size so they fit. I avoid fixed size tables as much as possible because there are things to be rendered that might not fit in certain circumstances (such as users using huge fonts to deal with vision problems). Also, fixed size in terms of pixels shows up quite different in browsers in a 400x300 window than in browsers in a 2000x1600 window.
I'm glad you don't use JavaScrap in your web sites. I don't either.
On their slow computers, the older browser renders fine. It's the newer browsers with their many deeper layers of object abstracting in the code that run slower on the new browsers. I benchmarked NS4 as 22.5 times slower than NS3 at rendering nested tables. So NS3 can handle my table based pages back to very very slow CPUs. NS6 was more than 4 times slower than NS4. NS3 had a nice tight (although buggy) rendering engine.
Feel free to look at my site and tell me how you would do it. But I want it to generally look the same in my NS4 browser that has CSS disabled for integrity purposes. I'm going to be re-designing the whole site soon, to include customization, so any ideas you have would be nice. But if they include CSS, then I probably won't use that for at least another year or so.
CSS in NS4 is broken. Numerous elements of stylesheets are not handled as expected. Also, NS4 crashes frequently when accessing CSS pages. It is necessary to leave CSS disabled in NS4. So NS4 is equivalent to a browser with no CSS (because it has a broken CSS).
I'm less worried about making "quirk" pages render nice than I am about making standards compliant pages render nice. But the biggest problem remains that the browsers themselves are not shedding the fat, and that is part of why the progress forward to better standards is being slowed down.
I don't know what is in Firebird, either. But I did manage to make a quick look over some of the code, and I what I saw didn't seem to be necessary for a browser.
A List Apart is my example of a web page that looks like crap in some browsers that are still used today. He hasn't bent any rules in making that site. If we could have better browsers for everyone, then I'm sure his page would look fine everywhere, for everyone, and we can use it as a model for good design. And you can do that today, if your needs do not include making web pages work well for people stuck on older browsers.
Of course as more use of other methods of viewing take place, things do have to change. And Zeldman's information helps us prepare for that day. For some, that day is here now. For others, it is not.
Of course new standards are a whole lot better than HTML 3.2. But depending entirely on the new standards while you need to display well in older browsers that don't support them is the problem. And again, I say, the solution isn't going to be finding an answer to the debate about how to design pages ... standards compliant is the way to go ... the solution is to fix the browser problem ... so that web page design can move forward for everyone.
One of Zeldman's own web sites doesn't even work right in NS4 at all. His personal standard is that anyone who uses a browser that makes him, the designer, have to work a little harder to support, isn't someone he wants in his audience, anyway. His reaction will simply be "upgrade" without considering any of the implications of that. I take a different approach. I put in some effort to make things work more universally. I've seen how Zeldman's own development comes out crappy in NS4. I don't want that for my sites.
You say "complex layouts" for browsers v4 and under. I take that to mean you consider using a few layers of tables to be "complex". OK, so be it. But how do you expect to get a decent site without that? Oh wait, you don't care about that. I know Zeldman doesn't, because he told me so.
Nested tables do get big, but not that big. And there's no way to do certain things in older browsers without them. If you think you can, I'm open to looking at what you have.
I have no trouble doing table-based layouts. Mine work fine and I can visualize just how they work, and what can and cannot be done with them.
I don't dismiss standards. They are good things. What I'm saying is that in certain cases, they can't be used at this time because those cases involve requirements that are incompatible with the current deployment of browsers that don't support the standards. The real problem is the browsers. If all browsers supported the standards correctly, we wouldn't be here debating this. But the fact is some don't, and some people still have to use them because the new browsers won't work in their situations. When either those situations change, or the programmers work on making leaner browsers (and operating system distribution configurations to run them), then we can have a case of virtually all browsers running will support the standards (hopefully correctly). But there will still be one problem: as soon as that comes to pass, there will be new standards, and the lower end of browsers then won't support those new ones.
What I mean by just barely complying with standards is that the browser developer is not to go adding anything else to make it work beyond what those standards specify. That includes adding no features, even if they are proposed for a new version of standards yet to come out. In other words, it needs to be the most minimalist browser that can still be compliant.
I don't believe browsers are bloated because of new standards. Instead, I think browsers are bloated because developers are always trying to one-up each other in adding in new features to make their browser become the one most people use. And for those who want such browsers, fine.
As for making standards compliant web pages that work in older browsers, sure, I've seen it done, too. I did it using a standard called HTML 3.2. I've also seen a site Zeldman set up, which he has claimed is a model for his development methods, that looks like crap in NS4. To me, that's not "working". It's certainly not compliant with my personal standards of good site. And the stories section doesn't even work to any extent at all, showing nothing but a blank gray page.
In regard to your statement ...
... I have to disagree. Choosing between whether my site looks good or looks crappy in an older browser, while it looks the same in a newer browser, isn't going to shut anyone out, as long as my choice is in the "good" direction. I'll setting for making it look good for everyone.
One reason for this is because I do know that style and presentation is as useful in information as it is in other content goals. Things like having a gray background combined with images that were designed for a white background, just because the web designer wants to specify the background color in CSS and NOT specify it in HTML, create distractions. They bother me when reading a site. And I know I can do better by making the correct background color work everywhere.
As for Mozilla Firebird, that thing is still way too big. The programmers who write today's graphical applications have an obese mindset. And I was generous with the 2 MB requirement. It really should have been 1 MB. A source tree that is 220 MB (after uncompressed) and 1703675 lines is just way too big. There's got to be more in there than just complying with standards.
Then I guess I can't do a review of your web site. Sure, you have it easy with a one-browser audience. But if you wanted to make a site look good in a wide range of browsers, including older ones, then things like CSS cannot be depended on exclusively. But if you don't care if the site looks like crap in an older browser, then using CSS won't be a problem for you. It depends on what your goals are. Zeldman's ways don't work for everyone.
You say to pick one standard and use it? Well, I pick HTML 3.2. So there. Now why didn't I pick any version of CSS, or XHTML? Well, simply put, my goals are to make a site not only work, but work better than just barely working, in older browsers that are still in common use. And right now based on logged User Agent data, that looks like back to Netscape 3 and IE 4. And the goal of a state government, unlike a corporation, is to make things work for all citizens of the state, including poor ones that are given old hand-me-down computers (often donated by those corporations).
CSS certainly has many benefits for the designer. And as long as your target audience is using browsers that support CSS correctly, you should use it. And for many corporations and person web sites, that's fine. Where I think CSS still needs to be avoided is where the goals are so broad that users w/o CSS capable browsers still need to be accomodated. Where we will probably differ in opinion is just how good the site will need to be in say NS4. Some will accept default gray backgrounds, sloppy layout, and mangled color schemes, so long as the text is readable. My goals are higher than that, so the philosophy of doing nothing else but CSS cannot be used since it cannot achieve my goal.
I think you still misunderstand the older computer problem. That older computer can't run a new OS. It can't run a new browser. Or in cases where it can be squeezed in, it's too slow to be comfortable. Try Mozilla on a 25 MHz machine. The older browsers like NS4 and NS3 actually render tables faster. I actually stayed with NS3 for a while back when I was on 100 MHz because NS4 was just too damned slow at rendering tables (I benched NS3 as 22.5 times faster than NS4 on a deeply nested table).
I won't dispute that CSS would be faster than the corresponding same thing in raw HTML. But if you can't get a browser working that does CSS right, or at all, and won't die when it sees it (like NS4 does), then you're basically locked out and have to limit your browsing to what works. Some sites can be made to work in NS4 anyway, but look ugly in the process. Mine will look nice in NS4.
As for coding for different browsers, the only difference I have ever done is graphical vs. non-graphical (e.g. lynx). Look at linuxhomepage.com and see.
My goal, which may not be what the standards set as a goal, is to do the best that a given browser can do with a common set of code. What I end up seeing is stuff like no background color at all in some of these sites in Netscape 4. That's because the background color was put in the stylesheet and NOT put in the HTML. But if it were put in the HTML, then it would still work on both old and new browsers, and work better in the older ones compared to leaving it out.
I'll agree with you on this. Now we need to debate whether CSS is the way of the present.
The reviewer cited a goal that was to make the web site work in as many browsers as possible. The goal statement isn't entirely clear. He needs to define what "work" means. If he's willing to give up looking as good as a given browser can look, in order to achieve standards compliance, and has a goal of merely making sure the text can be see, then his goal is not the same as mine. But I've seen people who do things with this total standards compliance goal and come up with totally a totally crappy site.
As for K10k, I do see a lot of layout on this page, but I can't tell if you've completed it or not. It looks like a nice design, but it lacks content. Here (and scrolled) is what it looks like to me in Netscape 4 (with CSS off, because it is unsafe to browser in NS4 with CSS on due to bugs). I certainly wouldn't call that usable (but like I say, I don't know if this is "under construction" or not ... it looks like a half way done site). I included the scrolled down image of it so that I could also point out the fact that the form elements are out of bounds of what appears to be areas where maybe it isn't intended. I see many sites where the designer tries to fix things to a specific number of pixels, and this simply does not work on the web unless you can make those be images and control them exactly (which can be done for the submit button, but only in a limited way by changing font for the input fields and drop down menus).
What this K10k page does in NS 4 is certainly not what I want to let happen on any web page I design. This page does a lot better in NS 3 and 4, as well as IE 4, 5, and 6, and even Gecko, Konq, and Opera. I'm happy with it because I got what I wanted. Of course it is table driven, so NS 1 is out of luck and will have to use the Lynx version. But at least there is a link to that.
People who follow these standards have made web sites that are totally illegible in Netscape 4. I, OTOH, have made sites that not only display nicely in the new browsers, but also display equally nicely in older browsers back to Netscape 3, and are easy to maintain through the use of configuration settings using PHP. And that was doing without even checking the value of User-Agent at all.
I don't consider it to be acceptable to tell the end user that it is the fault of the browser when: 1: they cannot upgrade the browser for some (often legitimate) reason, and/or 2: I could make the page work just as well in their browser.
As for newer browsers: Netscape 6/7 is just too obese (and too much ad crap). Mozilla is also too obese and slow. Konq works reasonably well, but it refuses to run as separate processes while still segfaulting on occaision (which is why I like to put each browser instance in a separate process, to avoid losing everything from segfaults triggered by one site).
What we need is a lean browser that just barely complies with the standards, and does nothing more than that in its base version. It needs to have a small footprint (2 MB max) and leave out the damned JavaShit.
Since Netscape 3 doesn't support CSS at all, and Netscape 4 has a broken CSS, I wonder what it is you did to get your site to display correctly on those browsers (assume CSS is turned off on Netscape 4 so my process won't segfault and take down all my Slashdot windows). Can you put a test/demo page up somewhere? Or is the site totally secret until released (at least tell us when and where that will be).
Based on discussions I've had with Zeldman, I will not read his book at all. The site he demonstrated as adhering to standards (about a year ago or so) was total crap in the browser I use. His goals in web site design (minimize the work the designer has to do or make the transmission as small as possible), and my goals (make the web site not only work, but work well, in as many browsers as can support what I'm trying to do), simply are not the same. Therefore his methods are of no interest to me. If someone were to give me his book, I'd sell it on Ebay as "never opened".
Your site looks like crap in my older browser. Oh wait, you didn't tell me where your site is. OK, so I'm guessing. But most sites that do things like this have these problems. OTOH, your company's intended audience may not include people using older browsers. Your web site; your rules (just don't make rules in ignorance).
BTW, I was able to simplify my color and other themes without XHTML or CSS. I just used PHP and set some variables. It won't gain you the faster loading times that CSS will, but it can make maintenance easier.
However, not all browsers support XHTML and CSS. Older browsers, which people of limited means are stuck with because they don't have the computer capacity to support the obese new ones, don't support those. Sites intended by commercial businesses marketing to people with good economic means don't need to worry about accessibility to the economically disadvantaged, so they can go ahead and disregard them and use those standards. But if your goal is to maximize access to all, as the book reviewer's needs were, then you have to deal with the reality that the new standards are not supported, and attempts to use new standards on older browsers can often be worse than just using the old standards everywhere.
If you want the largest audience possible, then using the latest web standards, such as promoted by Zeldman, is not what you want to do. The reason for this is because not all web browsers in current use work with these standards. And there are many reasons people won't or can't upgrade those browsers.
There is a way to make web pages so that they can use standards, and still work on older browsers. However, you might not like the end result. What you get on the older browsers is a very poor presentation. For example, if you define the look of your page in cascading stylesheets, when viewed on a browser with no support for CSS, you get crap.
Boundary conditions are even worse. If the browser is a version that tries to support something, and does it wrong, you can get even worse that crap. It might not work at all.
Mixing standards can cause problems as well. Here is an example. Lots of designers seem to like blue backgrounds for the side rail menus. But lots of web browsers default to blue for hyperlink text. If you specify the color of the text in a stylesheet, but specify the background color of a table cell (or worse, the whole page), in HTML, then you can end up with a situation where some of what you specify is acted on, and some is not. You'd end up with blue text on a blue background, and therefore unreadable.
It would be great if everyone could upgrade to the latest browser. But if you are trying to reach the widest audience possible, you do have to consider that many in that audience will be using older computers which have smaller drive space, smaller RAM space, slower CPUs, and can only run older versions of operating systems and browser software. While Linux might well be a great replacement for old versions of Windows on those machines, you still have the problem if shaving a recent version of some Linux distribution down to fit, and getting a huge obese browser to run on a tiny, slow, machine.
Here is an example of a real web site done in a way that displays terrible on some browsers. You can see what it looks like in Netscape 4 in PNG, or JPEG, or true color GIF (works on Netscape 2 and later) formats. If you scan very close in the blue area on the left (this does not work with the JPEG image), you can see that the colors are #5a61a9 for the background, and #5b61a9 for the text (specified by their HTML in the body tag, so they intentionally did this). By radically exaggerating the red plane (e.g. everything #5a and below is made #00, and everything #5b and above is made #ff), you can see (PNG, JPEG) the text was really there. And you'd think that a state government would be concerned enough about making their site available to all audiences, including the economically disadvantaged who can just barely even get a computer and internet access. But no, they don't actually care (I talked to these people, and they really don't care). Here is another crappy web site. By comparison, this site and this site look fine in this older browser.
I'll agree that when a whole group of people get blocked because one person in their IP range spammed, there is a problem. But the responsibility for there being a problem that escalates to more of the network being blacklisted belongs to that network administration for not having corrected the original spam problem that persists. Despite being blocked, spamming takes up resources. By being blocked it is a little less, but it is not zero. The goal is to get that spammer off the network. When the other users of that network refuse to pressure the network operator to fix the problem (often due to FUD and blame from the network operator, and ignorance by most users), they are just making things worse, not better. There is an intent behind expanded blocking and in many cases, the goals (get the ISP to clean up its act) have been accomplished.
In cases where we are talking about Microsoft Windows servers, and Microsoft has released patches and/or service packs to fix problems, and/or configuration options exist to exclude problems, then if the system is under the care of an MCSE and it isn't fixed, I'd certainly blame the MCSE. But I suspect most of them are not under the care of an MCSE, and many under no care at all.
And some of them might be running Linux, including very old versions that are quite vulnerable and have probably been 0wn3d and r3-0wn3d for a long time.
Oh it's you again. You're still pissed off because your ISP harbors spammers and you think that you're not somehow supporting that by helping your ISP stay in business.
As to your statement about Bayesian filtering ... there are many negative effects. First, it works on the basis of content. What makes mail be spam is not what the content is; it's that the senders are using bulk methods to send to people who didn't want it. I do get some mailings that I have optted in to, which if they were sent to people that don't want them, would be spam to them. Bayesian filtering doesn't work on the basis of what spam really is. Secondly, to even use Bayesian filtering, it becomes necessary to let the spam arrive, using up network and server resources as it comes in. Then the Bayesian filtering has to be run which uses up even more server resources. And finally, if it is considered spam and rejected, then a bounce message has to be queued (taking up disk space), and delivery of it has to be attempted (which for most because it is from real spammers, cannot be delivered, and takes space and delivery attempts for several days). So I will never use Bayesian filtering because it is simply all wrong.