I develop extensively for both IE and Mozilla/Firebird and standards-compliant pages work just fine in both.
Then you can't be doing anything in the least bit complex with HTML or CSS. Try <object>. Try virtually any CSS 2 selectors. Try about half the CSS 2 specification for that matter. Try alpha channels with PNG (and no, having to resort to javascript or proprietary filters doesn't count).
So they compared the source code of an open-source project with what ? the disassembled code of a closed-source project ? how would they know if the source code of the latter has better quality than the former's, since by definition, you can't get the source code of the latter ?
If you have the cash, you can get source to a lot of things. That doesn't mean it's open-source though, just "with-source". Check out the open-source definition.
The comparable defect rate indicates that open-source software starts out as raw as proprietary software, but Reasoning said that ultimately open-source software has the potential to exceed proprietary software.
For some value of "starting out" and "open source software", I think everybody can agree with this. The average open-source project starts out as a lone coder with a pet project - it stands to reason it will improve significantly when other coders (with varying experience in various areas) jump on board. That's not even addressing the fact that it's "survival of the fittest" - poor-quality open-source projects simply get dropped for higher-quality ones.
As an example, the average English-speaking coder, no matter how experienced, could write a killer text editor, but be completely oblivious to i18n issues or Unicode - this changes when, say, a German patches it to be more friendly to him. Maturity counts.
But Apache isn't in that boat - it's considered to be mature. Which version were they studying? "A newer version" could be the latest 2.0 or 1.3 release. The 2.0 release still isn't benefitting as much as it could from the bazaar model - most people are still on the 1.3 tree.
Without using shift, the browser will still used cached images. Therein lies the difference.
Not quite. It still issues the request for each image, it just does a "conditional GET", which means it asks "send me the image if it's been updated." Usually the server can respond with 304 Not Modified, which means it doesn't have to transmit the image again (so you get the impression that it's just blindly using the cache because there is no download time). If the image has been updated though, it will simply respond with a 200 and the updated image.
I hate getting old data because the browser is caching.
If that is happening to you with Mozilla, there is probably one of the following things going on:
There is a transparent proxy sitting between you and the website that is screwing things up (talk to your ISP, it's probably their fault).
The website has either completely ignored caching, set things up wrongly, or prefers things the way they are.
HTTP has some very specific headers that deal with caching. If the server tells clients "must-revalidate", then you should always get the correct content. If the people who are responsible for the websites you are talking about do not do this, then talk to them. Unless the servers tell clients that the information is updated, you can't blame the clients for showing you cached data. It's the way HTTP works.
I can't, but that proves how silly this is. The server uses a file extention to MIME mapping file
Err, no. That is one mechanism, and probably the most convenient from your perspective, but it is by no means the only mechanism.
The client uses a MIME to file extention mapping file. Why bother?
Because there are no file extensions in URLs. A period is just a period. Who cares what mechanism you use - unless you are assuming that everybody uses the same mechanism as you, which is just plain wrong.
Your.htaccess file is never going to know about all 10,000 existing file extensions.
Why should my.htaccess file need to know 10,000 file extensions? Most sites only serve a dozen or so, most of them are covered by the default Apache setup, and the others you wouldn't like to be part of your web browser.
Until we get decent meta-data into our filesystems, forget aobut MIME.
You are confusing filesystem hierarchies with URLs - in many cases there may be a one-to-one mapping, but this certainly isn't a reliable assumption.
As an example, please let me know what you think the mime type for.content files is. Over here, it varies between at least three different mime-types, and in many cases, there isn't a file involved at all.
Just a simple thing such as aligning text & images in the center of a div means that I need to resort to tables since isn't allowed, and there is no horizontal-align (only text-align which "SHOULD" apply to text only, but some browsers seems to know better (ie, worse)).
The text-align property applies to inline elements, including inline replaced elements such as images. That is all you need, and pretty much all browsers that support CSS understand this.
Internet Explorer has problems relating to horizontal alignment of block display elements, but this is a separate issue.
I have to say this is fucking stupid. Every other version of HTML was distingished by the !DOCTYPE -- what makes XHTML 1.1 so special that one has to reconfigure MIME types for it?
Alternately, what makes XHTML 1.0 so special that it is allowed to be sent as text/html? After all, there are situations where XHTML treated as tag soup means something different to the HTML equivelant.
$10 says you guys will be having this same conversation 2 years from now.
But of course we will. There won't be a new version of Internet Explorer out within two years, so we'll be stuck with text/html for at least that long.
Well, technically it isn't breaking the spec, just bending it really far.
No, it is actually breaking the spec. You (and Mark) are referring to an unofficial Note produced by a member of the W3C. A quote from that document:
This document is a Note made available by the World Wide Web Consortium (W3C) for your information. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
I am referring to RFC 2854. This RFC provides the list of document types that may be sent as text/html. It includes XHTML 1.0, but not any other type of XHTML. In particular, even some forms of XHTML 1.0 are unsuitable for being labelled as text/html.
Question: What's the problem XHTML is supposed to solve? Answer: the fact that too much web content only works correctly on a particular browser. (And often at a particular resolution!) XHTML does this by re-introducing the strict content-presentation separation that is an essential feature of markup languages, but which HTML basically ignores.
This is untrue. XHTML 1.0 (the only XHTML viable to the public web) is a direct translation from the SGML-based HTML 4.01. As such, it comes in three flavours:
XHTML 1.0 Transitional (includes the cruft that you claim is not in XHTML)
XHTML 1.0 Strict (The XHTML you describe)
XHTML 1.0 Frameset (ick)
Later XHTML specifications build on XHTML Strict, but you can't use any of them with Internet Explorer without violating RFC 2854.
Mozilla's support would be OK, but it suffers from the same overly nitpicky irritation as it does with HTML+CSS: it stubbornly refuses to acknowledge that a file could possibly be XML or whatever unless the MIME type is correct.
Stubborn? It's a required part of the HTTP specification. Every browser other than Internet Explorer gets this right.
Given that even fewer servers, particularly those run by ISPs for their personal subscribers rather than run by companies for themselves, get the MIME type right for X* than they do for HTML+CSS, Moz is out of the race as a serious contender no matter how good its standards support may be.
Granted, there are a few wonky servers out there, but they aren't anywhere near as widespread as you make out. If the server you are on is serving your files incorrectly, and you cannot fix this yourself, then complain. You are getting a substandard service.
I agree that standards are important, but they are only a means to an end.
If Mozilla and other browsers do the exact opposite of what the public specifications require, and instead blindly copy Internet Explorer, then they have essentially given control of that specification to Microsoft. How can this be a good thing?
To avoid developing for IE6's new quirks and to keep my documents compliant by having the !DOCTYPE declaration in there, I add the ?xml... declaration to the top of my files to kick IE back in to its 5.5ish quirky existance.
There are problems with including the XML declaration/PIs in documents that you later serve as text/html, outlined in Appendix C of the XHTML 1.0 Recommendation. For instance, Pocket IE renders them as content.
The only mime-type you should serve XHTML 1.1 as is application/xhtml+xml. If you serve it as text/html, you are violating the spec. The only type of XHTML you are allowed to serve as text/html is XHTML 1.0 that follows Appendix C of the XHTML 1.0 Recommendation.
Also, when you serve it as text/html, the only thing browsers see is tag soup - they don't treat it as XHTML, just run-of-the-mill HTML that doesn't quite match HTML 4.01.
Based on SCO's response, claiming that no patent or copyright issues are involved, then Linux and Linux users are safe from any action by SCO EVEN IF SCO WINS AGAINST IBM.
Yes and no. It's clear that SCO cannot persue claims against Linux users. However, it sounds as though they think they have an exclusive contract with Novell. As such, Novell can claim damages. Yes, they are sounding friendly to Linux at the moment, but I would imagine that any exclusive contract would include the requirement that Novell undertake lawsuits to protect that arrangement - so Novell may be faced with a "sue Linux users or be sued for breach of contract" deal.
The point I was responding to was that we have no business saying that Revolution copyright holders have made enough money. I'm specifically pointing out that copyright is essentially a public matter. I'm not addressing the larger issue of whether hundreds of millions is enough profit for a movie, or how much time is appropriate for a movie to remain locked up (or even whether time is an adequate measurement).
I'm pretty sure I wouldn't want someone else who has nothing to do with my work determining when I've made enough money from it and telling me I'm "whining" if somebody steals it.
Absolutely. But in the case of copyright infringements against the copyright holders of the Matrix, this is not a valid argument.
The sole reason that they have special reproduction rights over Reloaded is because they are working for us, the public.
The entire point of copyright is to reward people who create original works. We reward them by allowing them sole reproduction rights over their works for a limited time. Then the works pass into the public domain, which they would have done instantly without copyright law.
The idea is that we are rewarding them for something we will eventually possess collectively. Creators are essentially working for the public. So I wouldn't say that we, the public, have nothing to do with their work.
Of course, this system is breaking down as our (the public's) property gets dragged further and further out of reach by extensions to copyright periods, copyright holders are attempting to extert more control than simple copyrights, and people are infringing on those copyrights more and more.
Slashdot Mirror
No. SMIL is like an XML-based Flash, developed by the W3C.
Then you can't be doing anything in the least bit complex with HTML or CSS. Try <object>. Try virtually any CSS 2 selectors. Try about half the CSS 2 specification for that matter. Try alpha channels with PNG (and no, having to resort to javascript or proprietary filters doesn't count).
If you have the cash, you can get source to a lot of things. That doesn't mean it's open-source though, just "with-source". Check out the open-source definition.
For some value of "starting out" and "open source software", I think everybody can agree with this. The average open-source project starts out as a lone coder with a pet project - it stands to reason it will improve significantly when other coders (with varying experience in various areas) jump on board. That's not even addressing the fact that it's "survival of the fittest" - poor-quality open-source projects simply get dropped for higher-quality ones.
As an example, the average English-speaking coder, no matter how experienced, could write a killer text editor, but be completely oblivious to i18n issues or Unicode - this changes when, say, a German patches it to be more friendly to him. Maturity counts.
But Apache isn't in that boat - it's considered to be mature. Which version were they studying? "A newer version" could be the latest 2.0 or 1.3 release. The 2.0 release still isn't benefitting as much as it could from the bazaar model - most people are still on the 1.3 tree.
Not quite. It still issues the request for each image, it just does a "conditional GET", which means it asks "send me the image if it's been updated." Usually the server can respond with 304 Not Modified, which means it doesn't have to transmit the image again (so you get the impression that it's just blindly using the cache because there is no download time). If the image has been updated though, it will simply respond with a 200 and the updated image.
If that is happening to you with Mozilla, there is probably one of the following things going on:
HTTP has some very specific headers that deal with caching. If the server tells clients "must-revalidate", then you should always get the correct content. If the people who are responsible for the websites you are talking about do not do this, then talk to them. Unless the servers tell clients that the information is updated, you can't blame the clients for showing you cached data. It's the way HTTP works.
Err, no. That is one mechanism, and probably the most convenient from your perspective, but it is by no means the only mechanism.
Because there are no file extensions in URLs. A period is just a period. Who cares what mechanism you use - unless you are assuming that everybody uses the same mechanism as you, which is just plain wrong.
Why should my .htaccess file need to know 10,000 file extensions? Most sites only serve a dozen or so, most of them are covered by the default Apache setup, and the others you wouldn't like to be part of your web browser.
You are confusing filesystem hierarchies with URLs - in many cases there may be a one-to-one mapping, but this certainly isn't a reliable assumption.
As an example, please let me know what you think the mime type for .content files is. Over here, it varies between at least three different mime-types, and in many cases, there isn't a file involved at all.
The text-align property applies to inline elements, including inline replaced elements such as images. That is all you need, and pretty much all browsers that support CSS understand this.
Internet Explorer has problems relating to horizontal alignment of block display elements, but this is a separate issue.
Alternately, what makes XHTML 1.0 so special that it is allowed to be sent as text/html? After all, there are situations where XHTML treated as tag soup means something different to the HTML equivelant.
But of course we will. There won't be a new version of Internet Explorer out within two years, so we'll be stuck with text/html for at least that long.
No, it is actually breaking the spec. You (and Mark) are referring to an unofficial Note produced by a member of the W3C. A quote from that document:
I am referring to RFC 2854. This RFC provides the list of document types that may be sent as text/html. It includes XHTML 1.0, but not any other type of XHTML. In particular, even some forms of XHTML 1.0 are unsuitable for being labelled as text/html.
What? XHTML served as text/html validates just fine.
This is untrue. XHTML 1.0 (the only XHTML viable to the public web) is a direct translation from the SGML-based HTML 4.01. As such, it comes in three flavours:
Later XHTML specifications build on XHTML Strict, but you can't use any of them with Internet Explorer without violating RFC 2854.
Stubborn? It's a required part of the HTTP specification. Every browser other than Internet Explorer gets this right.
Granted, there are a few wonky servers out there, but they aren't anywhere near as widespread as you make out. If the server you are on is serving your files incorrectly, and you cannot fix this yourself, then complain. You are getting a substandard service.
If Mozilla and other browsers do the exact opposite of what the public specifications require, and instead blindly copy Internet Explorer, then they have essentially given control of that specification to Microsoft. How can this be a good thing?
Try this one.
There are problems with including the XML declaration/PIs in documents that you later serve as text/html, outlined in Appendix C of the XHTML 1.0 Recommendation. For instance, Pocket IE renders them as content.
The only mime-type you should serve XHTML 1.1 as is application/xhtml+xml. If you serve it as text/html, you are violating the spec. The only type of XHTML you are allowed to serve as text/html is XHTML 1.0 that follows Appendix C of the XHTML 1.0 Recommendation.
Also, when you serve it as text/html, the only thing browsers see is tag soup - they don't treat it as XHTML, just run-of-the-mill HTML that doesn't quite match HTML 4.01.
I seem to remember that Slackware had a subscription option, I don't know if they still do. Ahh yes, here it is.
There are legitimate criticisms of PHP, but these aren't them.
PDF preserves layout. This is useless when an ebook has to be read on devices ranging from handhelds to 21" monitors.
You are right though, leveraging existing work is always good. What's wrong with DocBook?
Don't forget:
It's certainly not the first.
It doesn't matter if Linus wrote the code himself and had never heard of SCO. A patent covers independent implementations.
Even if he got hit with a multi-million dollar lawsuit, Linus could just pack up and go home. Software patents aren't legal in Europe.
Yes and no. It's clear that SCO cannot persue claims against Linux users. However, it sounds as though they think they have an exclusive contract with Novell. As such, Novell can claim damages. Yes, they are sounding friendly to Linux at the moment, but I would imagine that any exclusive contract would include the requirement that Novell undertake lawsuits to protect that arrangement - so Novell may be faced with a "sue Linux users or be sued for breach of contract" deal.
The point I was responding to was that we have no business saying that Revolution copyright holders have made enough money. I'm specifically pointing out that copyright is essentially a public matter. I'm not addressing the larger issue of whether hundreds of millions is enough profit for a movie, or how much time is appropriate for a movie to remain locked up (or even whether time is an adequate measurement).
Absolutely. But in the case of copyright infringements against the copyright holders of the Matrix, this is not a valid argument.
The sole reason that they have special reproduction rights over Reloaded is because they are working for us, the public.
The entire point of copyright is to reward people who create original works. We reward them by allowing them sole reproduction rights over their works for a limited time. Then the works pass into the public domain, which they would have done instantly without copyright law.
The idea is that we are rewarding them for something we will eventually possess collectively. Creators are essentially working for the public. So I wouldn't say that we, the public, have nothing to do with their work.
Of course, this system is breaking down as our (the public's) property gets dragged further and further out of reach by extensions to copyright periods, copyright holders are attempting to extert more control than simple copyrights, and people are infringing on those copyrights more and more.