Now, I'm using XP, and it's easy to see how 10 years of development have consistently innovated-not in a direction I'd like, and not in a safe or secure manner, but it's innovation.
Incremental improvements inspired by others is not innovation. What great new features have Microsoft ever introduced to the world? It has to be more than a couple to claim the status of "consistently innovating".
What has Linux got but 10 years of incremental patches?
Things like ReiserFS? Major sections of the kernel have been completely rewritten since 1.0. The scheduler, the module loading system, the/dev handling (static/dev to devfs to udev), the network subsystem. Anybody even remotely familiar with the kernel wouldn't make the claim you are making.
I feel the "if it's open source, it's perfect" ideology
That's a straw man argument. People don't claim that open source automatically makes something perfect.
is the reason Windows is still the desktop OS of choice.
Desktop OS of choice for some people. It's certainly not the desktop OS choice for me.
Linux fanatics need to be able to step back and look objectively at Linux's many flaws
Zealots of any kind aren't objective. But people who use and develop Linux at home or work are not automatically zealots as you seem to be implying.
The help text was just an example. What about the technique that presents a single page as a series of tabs, or the related technique of presenting a long form as a series of pages? Search engines should certainly take that text into consideration.
It's certainly possible, but as Google's own website is not valid, I doubt it's part of Google's strategy.
The main thing to remember is that the Googlebot is like a web browser you cannot test in. You have no idea what parts of HTML it supports, and what bugs it can work around. You know the old problem with Netscape 4.x, where, if you leave off a closing </table> tag, it doesn't see any of the table? Who knows how many of those types of errors Google has problems with?
The bottom line is that if you want some arbitrary user-agent to understand your website (in this case Google), then you really don't have any option but to write valid HTML. If you don't, you are gambling, plain and simple.
Or even better, just use an intelligent html parser that can work out if text would be hidden and ignore it if it is.
There are legitimate reasons for hiding text. For example, putting help text into a page, and only showing it when the user clicks a help button (far more friendly than popups).
I haven't seen in either GNOME or KDE something like 'right button click' -> 'share this folder' option
It needs to be enabled by the administrator, but right-click on a folder, go to Properties, and there's a Local Net Sharing tab there (KDE 3.2, dunno about previous versions as I don't use that feature).
Photographs are not protected by copyright unless noted. If copyrighted, permission should be obtained from the copyright owner prior to use. If not copyrighted, photographs may be reproduced and distributed without further permission from NASA. If a recognizable person appears in a photograph, use for commercial purposes may infringe a right of privacy or publicity and permission should be obtained from the recognizable person.
Scrollbars are easy to recognize no matter what color they are.
As far as I can tell, the overwhelming majority of people who try and change scrollbar colours do so to make them blend in with the colour scheme used on their website. This usually makes them far less obvious.
They are always in exactly the same place
No they aren't. Scrollbars can appear in frames, iframes, <object> elements, textarea fields and elements with overflow: scroll set. It's very easy to miss them in a large number of cases, even if you are an experienced surfer.
In any case, anybody who dislikes this misfeature should vote for the bug.
You need to deviate from spec. to get Internet Explorer to even attempt to render it. If you serve it as application/xhtml+xml as per spec., Internet Explorer simply prompts you to save the file rather than rendering it.
I did mean to write "[IES is remarkably standards-compliant in comparison to earlier versions of IE".
That I can agree with a bit more, it does manage to get a bit more of CSS 2 right. The majority of the things I mention are still just as big of an issue in Internet Explorer 6 as in previous versions though.
it is now possible to write compliant web documents that validate and appear virtually the same in ie6, mozilla and opera.
Absolutely, yet you can't simply write to the standards and forget about it. You need to write to the standards, avoiding all the bits of the standards that Internet Explorer ignores, and then find hacks to work around the issues where Internet Explorer tries to get it right and fails miserably.
at least some of the specific issues you describe are problems in other browsers too. (e.g. http1.1 preservation of request method in a 302 response is a problem in mozilla too, as is robust css2 support)
302 responses, as described by RFC 2616, are effectively dead since so many web applications rely on its traditional behaviour. That is why it was obsoleted and replaced with 303 and 307 responses. I was mostly thinking of things like disregard for the Content-Type header. I would describe Gecko/Mozilla as having robust CSS 2 support for quite some time. It could be improved upon, but it's miles ahead of anything Internet Explorer can handle.
So I still contend it is completely false to say that IE6 makes no *attempt* to comply with web standards.
I agree with that, but I'd also say that once it was clear that Microsoft had won the browser war, they completely gave up on Internet Explorer development. It had served its purpose.
It manages to get CSS 1, a specification over seven years old mostly right. However, it ignores or screws up vast swathes of CSS 2, a specification that will soon be six years old. It doesn't even attempt to handle the four year-old XHTML 1.0. It doesn't understand most selectors. It doesn't understand any of the CSS table model. It violates a number of mandatory sections of the five year-old HTTP 1.1 specification. It can't render PNG images correctly, despite the fact that Microsoft promised support in Internet Explorer 4 and the fact that it's been around for over eight years. It can't even decide between "quirks mode" and "standards compliant mode" reliably, as it throws an eppy when faced with the XML prologue in XHTML documents.
Don't even try to argue that Internet Explorer is in any way a decent browser when it comes to supporting standards.
code that works on Mozilla is probably going to work on IE
That's not true. There's gigantic amounts of CSS 2 that works in Mozilla, Opera and KHTML, but not in Internet Explorer. The most prominent areas are the selectors and tables.
The only place where Internet Explorer usually gets things "right" is where it actually does the wrong thing, but what a newbie developer expects.
For instance, text-align: center shouldn't centre block-level elements, just text. Internet Explorer gets that wrong, but to a newbie it looks like it "works" in Internet Explorer, but not in anything else.
Another example is the CSS content-type. If you claim that your stylesheets aren't CSS, but rather text documents, Internet Explorer ignores you (in contravention of the HTTP 1.1 RFC) and treats them as stylesheets.
Having said that, I completely agree that Gecko should be used as the reference rendering when developing. There's no point developing against Internet Explorer and then finding out you've not been following spec. You just have to be aware of what things are just plain broken in Internet Explorer before you waste time using them.
What are you aiming for - compliance with the W3C specifications, or separation of content and presentation?
You can use all those nasty <font> elements and still adhere to the specifications. Use HTML 4.01 Transitional or XHTML 1.0 Transitional (following Appendix C).
The benefits of adherance to public standards means increased compatibility with present and future browsers, and reduced business risk.
Separation of content and presentation is slightly more risky, due to buggy browsers, particularly Internet Explorer. If you are going to do this, make sure you have somebody familiar with CSS first that knows the limitations of the various browsers.
You may want to do it in two stages - first separating out the minor styling, such as fonts and colours, and then getting rid of the table layouts when you've laid the groundwork.
Older browsers like Netscape 4.x will almost certainly cause you major problems. The normal technique these days is to hide stylesheets from them using their bugs against them. That way, they get the plain, unstyled HTML page (which should still be functional if you are doing things right).
Newer browsers have something called "doctype switching". Make sure you trigger standards-compliant mode so that they are at least trying to do the right thing.
Don't rush headlong into CSS if you've not spent much time with it before. There are plenty of things you can do to screw up a page (e.g. pt or px-sized fonts) that aren't immediately obvious to the newcomer.
Luckily, the things I'm working on are fairly new, so we'd need a pretty strong reason not to use the relevent specifications and separate content from presentation.
I think it means that if you sue somebody alleging that, say, Apache, infringes upon a patent, you lose your license for Apache.
If this is true, doesn't this mean that it's not Free Software and non-compliant with the Debian requirements? It seems to be placing a restriction on use rather than redistribution, and is therefore EULA-like.
The data: URL scheme RFC was published in August 1998. However, to my knowledge, the only implementation was first created six months ago (the Opera web browser).
I find it always funny that KDE supporters always list re-use of existing libraries as a big minus point of Gnome
That's a straw-man argument. KDE supporters don't "always list re-use [...] as a big minus point."
In Gnome the supporting libraries are almost never Gnome dependent they often use already existing libraries or help to modify them too their needs, without Gnome-ifying them.
The same is true of KDE.
Which makes the KDE supporters scream that Gnome is taking everything over.
I think you may be listening to trolls, not KDE supporters.
This isn't true, but Gnome by using the above philosophy, doesn't alienate itself from other Linux/*nix projects in stark contrast too KDE.
Can you give an example of how KDE alienates itself from other projects? I don't see that happening at all, in fact KDE developers have put a lot of effort into increasing compatibility between KDE and GNOME in particular.
Gnome is not only about building a great desktop, it is about building modular desktop technology that can be used and reused by more projects then Gnome only, which make Gnome more cooperative too other projects then KDE.
No, that's the job of Freedesktop.org, which both GNOME and KDE developers participate in.
I find the KDE community extremely vicious against everything not KDE
I don't. I find a lot of people who criticise KDE, and compare it against GNOME without becoming familiar with KDE first, leading to a highly biased point of view.
PNG hasn't caught on because Internet Explorer has yet to properly support it.
PNG is as functional as non-animated GIF in Internet Explorer 5+, the problems are with a non-binary alpha value (totally opaque works, totally transparent works, nothing else does).
The gamma support is the only area where it fails against the GIF format for static images. Gamma correction is built into the PNG format, whereas GIF took the approach of "don't worry about it". Differing gamma correction means that you often get mismatched colours between PNGs and neighbouring coloured areas. In practice, you can solve this for everything but older versions of Safari and Opera by configuring your graphics editor to remove all gamma information.
Yes, you cited one standard. Congratulations. Unfortunately for you there are thousands more.
It was an example to illustrate a point. If you really need others, fine:
SMTP: Exchange, Sendmail, Qmail, Postfix.
FTP: IIS, proftpd, wu-ftpd.
DNS: BIND, djbdns, whatever Microsoft offers.
IRC: Probably too many to mention...
All examples of open standards that have implementations that are resistant to each others' worms.
DES is a special case because the cryptographic algorithm itself is what can be attacked, not the actual implementation. It's rare that a security hole is found within a standard. It's common to find them in implementations.
You could use the same argument against "standards."
No you couldn't. IIS and Apache both implement the HTTP standard, but only one of them was vulnerable to Code Red et al.
Avoiding a monoculture doesn't mean making everything as different as possible. It means that one implementation of a standard shouldn't monopolise the marketplace. If anything, open standards promote this, as you are free to use differing implementations rather than the single implementation that can handle a particular proprietary format or protocol.
I have an earlier edition of this book, and I was massively underwhelmed. It was as if somebody printed out the online manual and prefixed it with a few average tutorial chapters. The actual useful content of the book to a beginner was approximately a quarter of the overall page count.
I can't say whether or not this edition has improved the situation, but if the publisher was willing to churn out such a low-quality book before, I don't have high hopes for this new edition, especially as it seems to be aimed at cashing in on the release of the new PHP5.
Incremental improvements inspired by others is not innovation. What great new features have Microsoft ever introduced to the world? It has to be more than a couple to claim the status of "consistently innovating".
Things like ReiserFS? Major sections of the kernel have been completely rewritten since 1.0. The scheduler, the module loading system, the /dev handling (static /dev to devfs to udev), the network subsystem. Anybody even remotely familiar with the kernel wouldn't make the claim you are making.
That's a straw man argument. People don't claim that open source automatically makes something perfect.
Desktop OS of choice for some people. It's certainly not the desktop OS choice for me.
Zealots of any kind aren't objective. But people who use and develop Linux at home or work are not automatically zealots as you seem to be implying.
It's very strange that you can't back this claim up, especially as Stallman and the FSF have made money by selling GNU software.
In fact, you can order GNU software directly from the FSF right now.
In fact, why not read what the FSF have to say on the matter straight from their own website:
The help text was just an example. What about the technique that presents a single page as a series of tabs, or the related technique of presenting a long form as a series of pages? Search engines should certainly take that text into consideration.
It's nice to see that storage companies are throwing away the ridiculous notion of mebibytes and gibibytes and using far more sensible units.
It's certainly possible, but as Google's own website is not valid, I doubt it's part of Google's strategy.
The main thing to remember is that the Googlebot is like a web browser you cannot test in. You have no idea what parts of HTML it supports, and what bugs it can work around. You know the old problem with Netscape 4.x, where, if you leave off a closing </table> tag, it doesn't see any of the table? Who knows how many of those types of errors Google has problems with?
The bottom line is that if you want some arbitrary user-agent to understand your website (in this case Google), then you really don't have any option but to write valid HTML. If you don't, you are gambling, plain and simple.
There are legitimate reasons for hiding text. For example, putting help text into a page, and only showing it when the user clicks a help button (far more friendly than popups).
That's complete rubbish. GNU even maintain a list of licenses that qualify as Free Software licenses but are GPL-incompatible.
Then how do you explain the fact that Stallman condones the use of the LGPL for glibc and a BSD-style license for Ogg Vorbis?
It needs to be enabled by the administrator, but right-click on a folder, go to Properties, and there's a Local Net Sharing tab there (KDE 3.2, dunno about previous versions as I don't use that feature).
It seems to be pretty clear to me:
As far as I can tell, the overwhelming majority of people who try and change scrollbar colours do so to make them blend in with the colour scheme used on their website. This usually makes them far less obvious.
No they aren't. Scrollbars can appear in frames, iframes, <object> elements, textarea fields and elements with overflow: scroll set. It's very easy to miss them in a large number of cases, even if you are an experienced surfer.
In any case, anybody who dislikes this misfeature should vote for the bug.
You need to deviate from spec. to get Internet Explorer to even attempt to render it. If you serve it as application/xhtml+xml as per spec., Internet Explorer simply prompts you to save the file rather than rendering it.
That I can agree with a bit more, it does manage to get a bit more of CSS 2 right. The majority of the things I mention are still just as big of an issue in Internet Explorer 6 as in previous versions though.
Absolutely, yet you can't simply write to the standards and forget about it. You need to write to the standards, avoiding all the bits of the standards that Internet Explorer ignores, and then find hacks to work around the issues where Internet Explorer tries to get it right and fails miserably.
302 responses, as described by RFC 2616, are effectively dead since so many web applications rely on its traditional behaviour. That is why it was obsoleted and replaced with 303 and 307 responses. I was mostly thinking of things like disregard for the Content-Type header. I would describe Gecko/Mozilla as having robust CSS 2 support for quite some time. It could be improved upon, but it's miles ahead of anything Internet Explorer can handle.
I agree with that, but I'd also say that once it was clear that Microsoft had won the browser war, they completely gave up on Internet Explorer development. It had served its purpose.
IE6 is remarkably web-standards-compliant
Bullshit.
It manages to get CSS 1, a specification over seven years old mostly right. However, it ignores or screws up vast swathes of CSS 2, a specification that will soon be six years old. It doesn't even attempt to handle the four year-old XHTML 1.0. It doesn't understand most selectors. It doesn't understand any of the CSS table model. It violates a number of mandatory sections of the five year-old HTTP 1.1 specification. It can't render PNG images correctly, despite the fact that Microsoft promised support in Internet Explorer 4 and the fact that it's been around for over eight years. It can't even decide between "quirks mode" and "standards compliant mode" reliably, as it throws an eppy when faced with the XML prologue in XHTML documents.
Don't even try to argue that Internet Explorer is in any way a decent browser when it comes to supporting standards.
Yep, I have to echo everybody else and recommend JC. Very clueful tech support, very reliable, and very cheap for what you actually get.
I didn't know you had to win awards to be infamous. Anyway, here you go:
That's not true. There's gigantic amounts of CSS 2 that works in Mozilla, Opera and KHTML, but not in Internet Explorer. The most prominent areas are the selectors and tables.
The only place where Internet Explorer usually gets things "right" is where it actually does the wrong thing, but what a newbie developer expects.
For instance, text-align: center shouldn't centre block-level elements, just text. Internet Explorer gets that wrong, but to a newbie it looks like it "works" in Internet Explorer, but not in anything else.
Another example is the CSS content-type. If you claim that your stylesheets aren't CSS, but rather text documents, Internet Explorer ignores you (in contravention of the HTTP 1.1 RFC) and treats them as stylesheets.
Having said that, I completely agree that Gecko should be used as the reference rendering when developing. There's no point developing against Internet Explorer and then finding out you've not been following spec. You just have to be aware of what things are just plain broken in Internet Explorer before you waste time using them.
What are you aiming for - compliance with the W3C specifications, or separation of content and presentation?
You can use all those nasty <font> elements and still adhere to the specifications. Use HTML 4.01 Transitional or XHTML 1.0 Transitional (following Appendix C).
The benefits of adherance to public standards means increased compatibility with present and future browsers, and reduced business risk.
Separation of content and presentation is slightly more risky, due to buggy browsers, particularly Internet Explorer. If you are going to do this, make sure you have somebody familiar with CSS first that knows the limitations of the various browsers.
You may want to do it in two stages - first separating out the minor styling, such as fonts and colours, and then getting rid of the table layouts when you've laid the groundwork.
Older browsers like Netscape 4.x will almost certainly cause you major problems. The normal technique these days is to hide stylesheets from them using their bugs against them. That way, they get the plain, unstyled HTML page (which should still be functional if you are doing things right).
Newer browsers have something called "doctype switching". Make sure you trigger standards-compliant mode so that they are at least trying to do the right thing.
Don't rush headlong into CSS if you've not spent much time with it before. There are plenty of things you can do to screw up a page (e.g. pt or px-sized fonts) that aren't immediately obvious to the newcomer.
Luckily, the things I'm working on are fairly new, so we'd need a pretty strong reason not to use the relevent specifications and separate content from presentation.
Yes, I've just confirmed that it works in Firebird. Cheers for the info.
I think it means that if you sue somebody alleging that, say, Apache, infringes upon a patent, you lose your license for Apache.
If this is true, doesn't this mean that it's not Free Software and non-compliant with the Debian requirements? It seems to be placing a restriction on use rather than redistribution, and is therefore EULA-like.
Does there need to be an implementation? XHTML has supported this since it was first published (Jan 2000, not including public drafts).
Specifically, you embed the binary data using the data: URL scheme, so, for example, you would write:
The data: URL scheme RFC was published in August 1998. However, to my knowledge, the only implementation was first created six months ago (the Opera web browser).
That's a straw-man argument. KDE supporters don't "always list re-use [...] as a big minus point."
The same is true of KDE.
I think you may be listening to trolls, not KDE supporters.
Can you give an example of how KDE alienates itself from other projects? I don't see that happening at all, in fact KDE developers have put a lot of effort into increasing compatibility between KDE and GNOME in particular.
No, that's the job of Freedesktop.org, which both GNOME and KDE developers participate in.
I don't. I find a lot of people who criticise KDE, and compare it against GNOME without becoming familiar with KDE first, leading to a highly biased point of view.
PNG is as functional as non-animated GIF in Internet Explorer 5+, the problems are with a non-binary alpha value (totally opaque works, totally transparent works, nothing else does).
The gamma support is the only area where it fails against the GIF format for static images. Gamma correction is built into the PNG format, whereas GIF took the approach of "don't worry about it". Differing gamma correction means that you often get mismatched colours between PNGs and neighbouring coloured areas. In practice, you can solve this for everything but older versions of Safari and Opera by configuring your graphics editor to remove all gamma information.
For more information, read The Sad Story of PNG Gamma "Correction".
It was an example to illustrate a point. If you really need others, fine:
All examples of open standards that have implementations that are resistant to each others' worms.
DES is a special case because the cryptographic algorithm itself is what can be attacked, not the actual implementation. It's rare that a security hole is found within a standard. It's common to find them in implementations.
No you couldn't. IIS and Apache both implement the HTTP standard, but only one of them was vulnerable to Code Red et al.
Avoiding a monoculture doesn't mean making everything as different as possible. It means that one implementation of a standard shouldn't monopolise the marketplace. If anything, open standards promote this, as you are free to use differing implementations rather than the single implementation that can handle a particular proprietary format or protocol.
I have an earlier edition of this book, and I was massively underwhelmed. It was as if somebody printed out the online manual and prefixed it with a few average tutorial chapters. The actual useful content of the book to a beginner was approximately a quarter of the overall page count.
I can't say whether or not this edition has improved the situation, but if the publisher was willing to churn out such a low-quality book before, I don't have high hopes for this new edition, especially as it seems to be aimed at cashing in on the release of the new PHP5.