Slashdot Mirror

As others have posted: http://phil.ipal.org/tc.html

But that's 184KB and PNG would compress it as 24-bit at 13KB (per my testing in Photoshop).

Done.
http://phil.ipal.org/tc.html

GIF is all of that plus animated. Protip - GIF is not limited to an 8 bit palette, it's one 8 bit palette per block.
You can draw multiple blocks on top of each other with no delay, in effect creating a full color frame.

http://phil.ipal.org/tc.html

Despite what many people believe, GIFs aren't limited to 256 colors. Although you would have realized that if you'd actually read the story. It may be another 10 years before animated PNGs are universally supported.

Gif may be technically lossless, but only if you only want 256-colours. These days "lossless" means on 24-bit colour.

No 24 bit color gif you say?

Isn't the whole point of the format that it knocks back the color pallet to ~256 colors?

Actually, no. GIFs can contain multiple image blocks, each with its own palette. Ever seen a GIF with just under 16-bit color? Check this shit out.

It worked for me. The server certificate I got was valid (issued 2008-10-02, expires 2009-10-15, for "servicing.capitalone.com"). There could be many problems causing this.

http://skapare.ipal.org/servicing.capitalone.com.cert.general.png

One is that the actual server (of many servers they are running through load balancing port redirectors) you connected to doesn't have the right certificate (e.g. they didn't install the new one on all servers ... maybe new servers coming online and the update of renewed certificate crossed paths).

Another is that you really are subjected to a man-in-the-middle attack that passed everything through, actually updating your real account. In the mean time your username, password, and financial information, are all recorded (if you have a big enough balance now, you might not have it next week).

I put a copy of the video here for you for a while. Hurry up and get it before that server gets slashdotted.

GIF is not limited to 256 colors.

From http://phil.ipal.org/tc.html

The mistaken belief that GIF has a limit of 256 colors probably comes from the way GIF was first used when it came out. In the late 1980's, PC video cards generally supported no more than 256 colors. Image exchanges were becoming popular among BBS systems and the Internet and viewer programs were quickly produced. No one tried or needed to generate images with more than 256 colors since they could not be viewed on anything less than high priced graphics workstations.""

for one, don't think GIF is going anywhere. Limited to 256 colours, sure.

The GIFormat is not limited to 256 colors! Read this for more information and a demonstration. I guess I should fix the Wikipedia entry sometime as well.

While validation is generally good, sometimes you do have to hack to get things right. Sometimes it is the fault of the browser (heaven knows IE is a biggie there). Sometimes it is just deficiencies in the standards. I don't know which it is, but the author's own web site has some things gone wrong. It validates strict, but the result isn't good. If there's a way to get the results right, but that requires being non-compliant to do it, then so be it.

Here's how I get that site rendered in Firefox 1.5.0.3:

• 0 scrolls
• 1 scroll

1. The 7th top row menu link has spilled onto the next row. That's ugly. I wouldn't accept that as long as there is room to fit them on the row, and there is, even with the waste of space on the sides of the page.
2. And yes, there is visual space waste on each site. That's perhaps just the style, but I've seen too many webmasters do it because they don't know how to make things fit better.
3. The "Register A Domain" box has an input field leaking off to the right side. That's really ugly. That's not even acceptable.
4. The featured site box has text leaking out the bottom. I don't think that's style. I think he just didn't code the box very well.
5. The three boxes labeled "Web Designs", "Domains", and "Hosting" have a bit of ugliness on the bottom corners of those boxes. Intended presentation? I doubt it.

If I have to make a non-standard hack to get things to work, I will, whether that's a defective browser or just deficient standards.

While validation is generally good, sometimes you do have to hack to get things right. Sometimes it is the fault of the browser (heaven knows IE is a biggie there). Sometimes it is just deficiencies in the standards. I don't know which it is, but the author's own web site has some things gone wrong. It validates strict, but the result isn't good. If there's a way to get the results right, but that requires being non-compliant to do it, then so be it.

Here's how I get that site rendered in Firefox 1.5.0.3:

• 0 scrolls
• 1 scroll

1. The 7th top row menu link has spilled onto the next row. That's ugly. I wouldn't accept that as long as there is room to fit them on the row, and there is, even with the waste of space on the sides of the page.
2. And yes, there is visual space waste on each site. That's perhaps just the style, but I've seen too many webmasters do it because they don't know how to make things fit better.
3. The "Register A Domain" box has an input field leaking off to the right side. That's really ugly. That's not even acceptable.
4. The featured site box has text leaking out the bottom. I don't think that's style. I think he just didn't code the box very well.
5. The three boxes labeled "Web Designs", "Domains", and "Hosting" have a bit of ugliness on the bottom corners of those boxes. Intended presentation? I doubt it.

If I have to make a non-standard hack to get things to work, I will, whether that's a defective browser or just deficient standards.

The kids would easily beat me unless we play on my old video game.

Actually that's not exactly correct, GIF can support more than 256 colors, it's just that using the fomat to do so requires a bit of 'finess'. That and the fact that for the longest time most programs didn't support creating >256 color images (why bother when most computers couldn't display them).
  If your currious about it, or want evidence the try these two links: http://phil.ipal.org/tc.html and http://en.wikipedia.org/wiki/GIF
    If you want to be pedantic about it ANY digitized image is lossy in the manner you speak of (though at about 21bits or so most of us can't tell with just our eyes), nature's bpp AND resolution is much higher than scanners and thus even at the bit-depth of high end scanners and digital cameras some data is lost. At some point (several usually) between the original light bouncing around and the stored image file you WILL lose data. Lossless generally means the data put into the compressor can be exactly reproduced by the compressor.

Mycroft

OK, I found my link.

First, I was wrong, it's not per line, it's per image block.

http://phil.ipal.org/tc.html is a site demonstrating a 15-bit color GIF. The way it was done was by separating it into blocks that held 256 colors each.

That's not quite true:

http://phil.ipal.org/tc.html

At 184KB, it's far inferior to PNG, and it's not compatible with a lot of applications, but the assertion that GIF is limited to 256 colors is simply untrue.

CSS does NOT always degrade gracefully with HTML ... depending on how well the web developers handle it. If absolutely NO HTML presentation is specified at all, then the site does degrade. Whether that can be called graceful or not is a matter of opinion.

But once a site starts using even the slightest bit of presentation specification in HTML, then things get bad very quickly. For example if a background color is specified in a table cell, it might be in conflict with the default color used for say hyperlinks by the browser. So if the background color is specified, so must every affected font color.

Here is an example of a site, and how it looks in an older browser, where the developers claim they are using "web standards" to make a site, and it degrades horribly. Actually, I would call this site absolute crap. When I communicated with them about it, they simply claimed that it "meets federal accessibility standards". Technically, they are not actually doing web standards correctly. But the point is, there are too many webmasters who are idiots and can never get it right, so I have my doubts about promoting this concept.

I read your post as having a different parent. I'm sorry.

No problem.

But I went ahead and loaded up your page with the same setup as the others just to see what it looks like. The JPEG is here. It looks rather weighted to the left side to me. Lots of unused real estate on the right.

You can specify a much smaller percentage. OK, add a minimum pixel size to that, too. But the key is to allow the browser to expand it if it needs it. If a single word needs more space, it's better to expand the box instead of letting the text spill, as seen here (note the words "Subscribe?", "Askslashdot", and "Developers" in the left menu).

Certain when web designs think inside the box (that they learned back in graphical arts school when the medium was 8.5x11 inch company catalogs), they too often do use pixel measurements and don't allow elements to float in size (as they are supposed to on the web). I tried pushing the limits on your page [link, jpeg, gif]. The left menu didn't expand even when I resized to full screen. But at least the text wrapped around correctly, which did not happen on the ALA/Slashdot [link, jpeg, gif] example (in that case, the text spilled out of the box and overlapped). There is a problem with text overlapping vertically, but I think that is a browser bug (Firebird 0.7).

Certain when web designs think inside the box (that they learned back in graphical arts school when the medium was 8.5x11 inch company catalogs), they too often do use pixel measurements and don't allow elements to float in size (as they are supposed to on the web). I tried pushing the limits on your page [link, jpeg, gif]. The left menu didn't expand even when I resized to full screen. But at least the text wrapped around correctly, which did not happen on the ALA/Slashdot [link, jpeg, gif] example (in that case, the text spilled out of the box and overlapped). There is a problem with text overlapping vertically, but I think that is a browser bug (Firebird 0.7).

Certain when web designs think inside the box (that they learned back in graphical arts school when the medium was 8.5x11 inch company catalogs), they too often do use pixel measurements and don't allow elements to float in size (as they are supposed to on the web). I tried pushing the limits on your page [link, jpeg, gif]. The left menu didn't expand even when I resized to full screen. But at least the text wrapped around correctly, which did not happen on the ALA/Slashdot [link, jpeg, gif] example (in that case, the text spilled out of the box and overlapped). There is a problem with text overlapping vertically, but I think that is a browser bug (Firebird 0.7).

Certain when web designs think inside the box (that they learned back in graphical arts school when the medium was 8.5x11 inch company catalogs), they too often do use pixel measurements and don't allow elements to float in size (as they are supposed to on the web). I tried pushing the limits on your page [link, jpeg, gif]. The left menu didn't expand even when I resized to full screen. But at least the text wrapped around correctly, which did not happen on the ALA/Slashdot [link, jpeg, gif] example (in that case, the text spilled out of the box and overlapped). There is a problem with text overlapping vertically, but I think that is a browser bug (Firebird 0.7).

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.

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.

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.

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.

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.

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.

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.

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.

What kind of error checking do you think is needed? I'm sure there is much we could agree on, but maybe there is some we don't. One of the things I want to be sure of is that the system comes up despite errors. Applications should know how to deal with failures in services, for example a mail server that came up OK after the DNS server failed to come up should either sit there and do nothing, or even take itself back down, because of the lack of DNS. I have SSH configured to come up regardless of any other service, and be functional even without DNS. I want the system to come up if at all possible, so I can SSH in, instead of have to drive to the office to grab the console.

But I do check for errors to make sure messages are meaningful. The individual service scripts are still pretty much like those of SYSV; they just have a different location and naming strategy. But I'll let you look for yourself. Here is a copy of the scripts I put up for public access about a year ago. My current running copies have been updated a little bit since then, but not majorly so. If there is interest I could make a new set for general access.

This is a myth. Admittedly, it is a myth with some partial truth, but it is nevertheless a myth.

The images at http://phil.ipal.org/tc.html demonstrate how a GIF file can contain more than 256 colors. Ironically, mozilla's libpr0n is broken on multi-block GIF files, so mozilla does not display the true-color GIF correctly.

The mistaken belief that GIF has a limit of 256 colors probably comes from the way GIF was first used when it came out. In the late 1980's, PC video cards generally supported no more than 256 colors. Image exchanges were becoming popular among BBS systems and the Internet and viewer programs were quickly produced. No one tried or needed to generate images with more than 256 colors since they could not be viewed on anything less than high priced graphics workstations. Programs that converted images to GIF worked up a number of methods to reduce the number of colors to 256 or fewer. Some actually did a very good job. GIF files were constructed with just a single image block, even though the GIF standard placed no limit on the number of blocks. Since there was no use for more than 256 colors, there was no use for more than one image block. This practice became effectively ingrained into the computer culture and eventually everyone "knew" that GIF supported no more than 256 colors. The fact is, the programs that generated GIF files supported no more than one image block, and thus didn't have a means to deal with more than 256 colors. The top image shows that a GIF file really can have more than 256 colors.

this info and more (including full color GIF) from here.

How accurately are the colors displayed in the top GIF on this page?

Actually, GIF can render photo-quality images. It can do 24-bit color. It does it by means of blocks. That feature has been in there all along. It just didn't get well adopted because at the time it came out, the best video cards were no more than 256 colors. So it just came to be that all GIF images were done in a single block. To see how a GIF can in fact have well more than 256 colors, see here. It's just not efficient at it.

In order to make the web site do on an older browser such as Netscape 3 all that could be done on Netscape 3, then color information must be coded in the HTML part. Web sites should not be designed for Mozilla or IE. They should be designed to work in general, and it should come out reasonably well on all browsers still in general use ... if it is your intention to do so. You have the choice and right not to. But don't claim that you are making your site compatible with Netscape 3 if you exclude Netscape 3 users from the color information Netscape 3 is certainly capable of correctly handling. Information can be in the color, too. And some sites are even worse. They do put HTML color info in, different than the CSS color, and (possibly intentionally) the HTML color is the same as the text color (or maybe 1 value step off) making it impossible to read the information. One example of this is in the menu on the left of http://www.state.tx.us/. The text color is #5a61a9 while the background color is #5b61a9. The link text color is set with this HTML:

<body vlink="#B17070" link="#5B61A9" marginwidth="0" marginheight="0" leftmargin="0" topmargin="0">

<table bgcolor="#5A61A9" width="172" cellspacing="0" cellpadding="2" border="0">

BTW, when I contacted officials at the state office dealing with these issues, two months ago, their response was "we're working on it". BS! Just edit the HTML and change the color code.

In order to make the web site do on an older browser such as Netscape 3 all that could be done on Netscape 3, then color information must be coded in the HTML part. Web sites should not be designed for Mozilla or IE. They should be designed to work in general, and it should come out reasonably well on all browsers still in general use ... if it is your intention to do so. You have the choice and right not to. But don't claim that you are making your site compatible with Netscape 3 if you exclude Netscape 3 users from the color information Netscape 3 is certainly capable of correctly handling. Information can be in the color, too. And some sites are even worse. They do put HTML color info in, different than the CSS color, and (possibly intentionally) the HTML color is the same as the text color (or maybe 1 value step off) making it impossible to read the information. One example of this is in the menu on the left of http://www.state.tx.us/. The text color is #5a61a9 while the background color is #5b61a9. The link text color is set with this HTML:

<body vlink="#B17070" link="#5B61A9" marginwidth="0" marginheight="0" leftmargin="0" topmargin="0">

<table bgcolor="#5A61A9" width="172" cellspacing="0" cellpadding="2" border="0">

BTW, when I contacted officials at the state office dealing with these issues, two months ago, their response was "we're working on it". BS! Just edit the HTML and change the color code.

The whole "web standards" debate is stupid, and most especially one sided sites like Zeldman's webstandards.org. All that Zeldman and his cronies are doing is try to push new standards ahead of sane development, probably just so that he won't have to deal with standards like HTML. He has a point, though, as the older standards are lame and the newer standards are better. But he lacks the ability to understand that browser development and deployment will always lag behind, and why. The sad thing is that his kind of suckered lots of web developers into believing that all they have to do is blame the user for having an old browser and all will become better because all users will upgrade. Truth is, that's not always possible or feasible.

A tour of web sites using the Zeldman style with an older browser will generally work, as he does not advocate breaking them. But what you do get is less than what that browser is capable of. For example, browsers have for ages supported setting a background color or even a background image in HTML. Zeldmanistas refuse to set the background color, or in some cases, intentionally set it to something different than what is set in CSS. So while the site looks fine with CSS, without CSS you get maybe stark gray, or worse, black with black text over it. So what's actually going on here is not a case of these developers adhering to web standards, but rather, they are picking and choosing the standards they want to use, such as by not making use of HTML completely and correctly. So why should he any right to expect that others will choose to use newer standards like CSS or XML or whatever.

There is also a very good reason to make a web site that works with older browsers. Many groups are now operating in lower income urban areas carrying out programs to get older computers donated to them from businesses that are doing the upgrading. Because of the economy, the number of businesses doing upgrades has dropped off and most donations are rather old. What this means is that most of the people receiving these computers are getting something in the late 486 or early Pentium range, and at best a copy of Windows 95, which is usually all (other than BSD or Linux, which hasn't made it to these programs that I've seen yet ... something for us to get more involved in I suppose) that these old machines with slow CPU, small memory, and limited hard drive capacity can handle. So they end up with usually an old Netscape version 3 browser (Java and Javascript are hopelessly broken, and CSS is non-existant). Newer browsers overwhelm the machine, if they even fit at all.

This "economic accessibility" isn't yet addressed by law, and may never be. Private business does not have to cater to them. So the banks and other financial institutions listed with specific browser requirements aren't in violation. And besides, we're talking about people who can't afford a computer and have to use limited time community access ISPs just to get online (if the phone and electric bill are paid up). I'm sure the financial institutions have no interest in extending them credit.

While businesses probably should have a free choice in what, and who, they support, governments OTOH should not. People should have a right to expect their government internet based services to be accessible to all, not just those who can afford a bigger faster computer that can handle the latest obese and overloaded software. And since it is possible to make web sites that not only work well with new standards, but also work well (as well as those standards allow) with older standards that the smaller browsers support, governments should be required to do this in all citizen-facing web sites. In other words, if it can be made to work in a minimal set of standards, it must be made to work that well when that's what's available. Then if it works even better in newer standards in ways that the older standards could never do, that's fine, too.

What I think might be a better approach to this would be to support the development of a not-so-obese web browser, as well as programs to get systems like Linux deployed onto more of the computers being donated to the economically disadvantaged (aside: why are politically correct words so long?).

I have P3 800, so shouldn't it be even faster for me? You'd think. Maybe it's just the rapidity of my vision. Even on this P3 800 I can see a difference in the speed between NS 3 doing rendering and NS 4. It's just that on my previous Celeron 333 the NS 4 speed was not tolerable, so I used NS 3. I remember doing some timing tests way back then between NS 3 and NS 4 on some complex HTML tables, and NS 4 was 22.7 times slower than NS 3 at rendering them (the page was made sufficiently complex that it took NS 3 a total of 3 seconds to render, while NS 4 took 68 seconds. That was just quantifying what I was actually seeing visually on much less complex pages.

NS 4 is still slow at rendering multi-block GIFs. NS 3 did them nearly instantly. Maybe this is because NS 4 has too much per-block startup overhead. Or maybe it is because NS 4 mistakenly thinks a multi-block GIF is an animated GIF and artificially inserts a delay. Download this image [184,565 bytes] to disk first, so you aren't seeing any network delay, then test some browsers on it referencing the local file and see how quickly it renders (BTW, certain older builds of Moz and Konq won't even render it at all). You'll need to do this on X running in 24 bit or more per pixel, with a video card that can do that (what can't these days).

Slashdot won't accept the post I wrote in reply to yours. So I put it on my web server here where there is no "Lameness Filter" to get in the way. To reply to that, come back here (if you can).

Maybe some day they will make the Lameness Filter explain what it thinks is lame so we know what to fix.

If the user configured his browser to use a specific proxy, then I would agree with you regarding RFC2068. The client in essence is delegating DNS responsibility to the proxy server. However, what is happening here is called transparent proxy. There is no DNS delegation taking place. And RFC2068 requires that semantic transparency be preserved (although it does not seem to differentiate types of proxies). It says:

In this case the origin server would have delivered a web page (I actually tried it and it works fine for me), and so the proxy has the responsibility to deliver the same thing. In that, it seems, it failed.

It has always been that way. Want control your own root? You can do that right now.

You're right. I've been doing it for years. It's just a matter of knowing you can. Knowledge can be a powerful thing ... and dangerous to those who would try to control us. But consider why 99% are "sheep". Many don't even know you can (not that they'd ever get it right). Many are afraid to (it really does work). Many just don't know where to get the info (My zone file is from ORSC).

But with DNS, we can trade root zone files. Here's mine.

I'm currently looking around for a Linux driver that can make a special RAMDISK out of whatever RAM exists beyond the point specified in mem= in the kernel parameters (append in LILO). If I can't find one, I may consider writing one.

As for your reference to a huge initrd, why not try out my cdinit loader that is part of my BICK [Bootable ISO Construction Kit] project. It comes to life via a smaller than usual initrd (having only /dev/console and cdinit named as /sbin/init). It expects to be booted from a CDROM, so it looks around for that CDROM and loads a tar file from it into tmpfs. I originally used ramfs instead of tmpfs when I started writing it. If you're going to run from RAM, either of those might work out better than RAMdisk. Given enough RAM and a patch to the kernel to tweak some limits, you could load 600+MB (even more if uncompression is implemented) from the CD into RAM and run a rather substantial system (at the cost of several minutes load up time, depending on CDROM speed). Or hack cdinit to use other data sources, like the network. You're not stuck with using initrd.

Another mirror is here, at least for a while. You can also get the tarball [1058816 bytes gzipped to 893547 bytes] here if you want to jumpstart your own mirror.

Another mirror is here, at least for a while. You can also get the tarball [1058816 bytes gzipped to 893547 bytes] here if you want to jumpstart your own mirror.

The max() and min() macros have been changed throughout the kernel to now use 3 arguments instead of 2. The new argument is the first, which is the type for the temporary variables used. This avoids problems with multiple references to data. Usually those get compiled out, but with variables of type volatile, they do not. But in since cases you don't want multiple fetches from volatile variables. The problem here is that the max() macro has one instance and the min() macro has two instances of being used inside the for() clause. Simply changing back to the 2 argument usage won't fix it because the macro is defined for 3. My patch just changes the 3 affected uses back to conventional C code.

I made a patch to fix that.

Due to an invalid assumption about putting baces inside macros (specifically, the max() and min() macros, which were changed in 2.4.9) which might be present inside the for() clause (which exists in 3 places in the kernel, 2 of which apply to NTFS code), the NTFS code isn't compiling. I made this patch to fix it.