You know, the whole "This property works. But only for elements of this type. Or with this, this, or that property. Unless its parent has this property, or is of this type. Unless you're using %, in which case it doesn't work at all. Unless....". Holy jesus!
Yeah, that's really a pain in the neck, particularly for for designers, but again, it's a limitation brought about by the desire to make it easy to implement rendering engines. If you look at a lot of the things that match your description, you'll find that, say, you can't allow a certain property for a certain type of element because it would involve having the rendering engine jump through hoops to make it happen. Frequently the specification looks more complicated than it actually is because it is written in English and not pseudocode, and English sucks for describing processes.
There's a balance that has to be struck between making things simple for designers and making things simple for browser developers. In hindsight, I think CSS is weighted too far in favour of the browser developers, but when you consider the performance constraints of 1996 computers, some of the decisions start to make more sense. For example, if CSS selectors were more contextually aware, there's no way a browser would be able to evaluate them in a reasonable timeframe on pages the size of, say, Slashdot comment pages. And, of course, similar constraints are in place today with mobile platforms.
No, if you are thinking of the <div> element type as a replacement for the <table> element type, you're still doing it wrong. Moving to CSS isn't about replacing <table> with <div>, it's about using the most appropriate element type for the job. You only use <div> when there isn't anything more appropriate (there usually is).
The W3C's CSS validator has recently been changed to check against CSS 2.1 by default instead of CSS 2. The text-shadow property was removed from CSS 2.1 because virtually no browser developers bothered to implement it. The stylesheet is still a valid CSS 2 stylesheet, but you wouldn't know that because nobody's bothered to come up with a way of labelling stylesheets to denote what level of CSS they are meant to conform to.
With CSS, it is all about theory, without real world tests.
On the contrary, some of the most frequently complained about shortcomings of CSS are due to the desire to keep implementations simple, which is practically the opposite of being "all about theory". They purposefully left out things like a decent query mechanism because they considered it too hard for people to implement.
The only reason it got pushed as standard, is because the web evolved too fast for its own good, and no one realised what was happening before it was too late, to propose an alternative to CSS.
No, Netscape implemented an alternative (JSSSL) and submitted it to the W3C for standardisation. It was more powerful than CSS, and that's one of the reasons why CSS was a better choice.
I hate to praise IE but IE has a way to only load certains stylesheets for IE or even certain versions of IE. It'd be nice to see that built into the standard so it'd be easier to make minor tweaks for individual cases.
Delivering differentiated content to work around buggy user-agents is a function of the transport protocol, not something you want to replicate for each and every file format delivered over that protocol. It is built into the standard - the right standard for this, HTTP. I quote from RFC 2616:
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations.
Of course, it isn't reliable, but that's because of abuse from both web developers and browser developers. It's only in the face of this abuse that stupid workarounds in particular file formats is necessary.
Heck, I like to switch stylesheets based on window size even so why not make that possible also without resorting to Javascript
That's already possible with CSS 3 Media Queries, already implemented by Opera.
They've crippled inovation in favour of maintaining a monopoly for YEARS now.
The example most relevant to me is the web. They essentially conned Spyglass into licensing code for Internet Explorer royalty-free, then "cut off Netscape's air supply". Once Netscape was dead, they abandoned Internet Explorer for five years, during which time web developers the world over had to support their lousy bug-ridden code because everybody used it, because it shipped with Windows.
I'm a web developer. The abandoned, buggy Internet Explorer with major market share has cost me time and money. If it wasn't for Microsoft, I'd have more money in my pocket. I'd have had more long weekends. I've have gone home earlier more often instead of working overtime to figure out the latest Internet Explorer foible. I'd have been able to do better things with less code instead of having one arm tied behind my back. And even now they are developing Internet Explorer again, it will still be years before this changes. That's why I hate Microsoft.
The "PHP Way" has always been to give the user sufficient power to shoot himself in the foot. The benefit is that the language itself is not slowed down by "features" which exists only to keep stupid programmers from hurting themselves.
On the contrary, the "PHP Way" has always been to give defaults where the user is likely to shoot himself in the foot, and when it inevitably happens, blame him for not changing the defaults (despite it breaking third-party applications). And the "benefit" you describe not only doesn't exist, it's the exact opposite of the truth - take "magic quotes" for example, where the language is slowed down by "features which exist only to keep stupid programmers from hurting themselves", and still manages to cause security headaches.
Having seen the update to the story by Zeev, I have to disagree. There is a grey area between bugs in PHP and bugs in PHP applications, and this is one of the major problems of PHP - a design that, when used correctly isn't insecure, but also a design that makes it much more likely that it's used incorrectly. This is a problem caused by PHP itself, but the symptoms manifest themselves as problems with PHP applications, making it easy to pass the buck.
he sounds pretty disgruntled with how his efforts towards security were received
I'm not surprised. If you read the article, you come across this gem:
Suraski expressed his regret at Esser's resignation from the security team and hoped that Esser might come to his senses and return. He also hoped that Esser would not turn against the PHP project. The "Month of PHP security bugs" proposed by Esser for 2007 would harm the project.
That's right, the PHP team think that dedicating a month to finding security holes in PHP is "harming the project".
Stefan has a bit of a reputation for being "abrasive". But in my opinion, it is because he's got decent (not unreasonable, but decent) quality standards, and isn't afraid to hold other people to them. In a normal project, that wouldn't be so bad, but given the prevailing attitudes of the PHP project, it's understandable that he blows up frequently enough to have a reputation.
With Firefox and Opera, one is able to open a link in a new tab by middle clicking on it. But unfortunately, many AJAX-enabled Web apps disallow such functionality, for whatever reason.
It's not Ajax per se that disallows it. The problem is that a lot of developers use <a href="#" onclick="..."> and don't provide an actual URI to open.
GMail is a major culprit.
Yes, it is, and I've said as much in the past. It's actually even worse than the average clueless developer, because it doesn't even use <a> for links - it uses <span> and click handlers to provide really, really crappy emulated links. Of course, doing so immediately throws the normal link handling your web browser provides out the window, including (but not limited to) opening them in new tabs or windows.
Basically every AJAX site I've tried has interfered some way with traditional ways of browsing. I don't know if it's an inherent limitation with AJAX
It's not. It's usually either developer ignorance or developer apathy - they either don't know how to do it or they don't care.
Does EMCA standardize anything other than MS apps?
ECMA have ratified a few standards relating to JavaScript - for instance, ECMA 262 defines the language that JavaScript, JScript, ActionScript and QtScript are implementations of, and the E4X extension that allows XML literals is also an ECMA standard.
I'm not sure what you are getting at. Yes, they are deprecated, but that doesn't mean that they aren't part of the specification or that they cannot be used in a conformant document. Deprecated essentially means that they are going away in the next version - and <font> did exactly that, it's not present in XHTML 1.1. This doesn't change my point that the use of <font> is irrelevant to the question of standards compliance.
You can however understand that a commercial company where time is money and money is matter of survival in a market developing with a furious pace would be disappointed at the speed at which W3C works.
Don't make me laugh. Microsoft still haven't come anywhere close to finishing their CSS 2 implementation, the specification for which was published over eight years ago. The same goes for other specifications - for example, they've only just finished PNG, and that specification was published over a decade ago. You simply can't call the W3C too slow for Microsoft when it's Microsoft that can't keep up with the W3C.
Standards-based design is not just about browser compatibility. It's also about separating style from content.
There's a strong correlation between people who adhere to the W3C's specifications and people who separate content from presentation, but that doesn't mean that they are the same thing. <font> and <table> are in the HTML 4 and XHTML 1.0 specifications.
Conflating the two leads to people claiming stupid things, like that they are writing "standard" code because they use CSS, when in fact their code is non-standard and full of hacks.
I know over the past few years "web standards" has become a popular buzzword, but there's a difference between best practices and conformance to particular specifications. Just because it's a good thing, it doesn't mean the specifications require it, and jujst because it's in the specifications, it doesn't mean it's a good thing.
There was a bit in there about a way of handling GPL violators who want to be able to redistribute again. According to Stallman, this is because when you redistribute without following the terms of the GPL, you lose any further right you have to distribute it, even if you comply with the GPL later on. In the article, he says he's not sure where the idea originated, but I suspect it's somewhere in the KDE camp, as this is where the idea that you need "forgiveness" from the copyright holder was first seen. The "cure" proposal would be a way of granting that forgiveness automatically.
On the other hand, I have to think that if someone makes a recording that can continue to sell for 50+ years, that person deserves some sort of financial reward for it.
50 years-worth of royalties isn't enough of a financial reward?
Brits here should check out the petition for private copying on 10 Downing Street's website. It's essentially asking that the government do what the think tank suggested.
First and foremost, copyrights and patents are not property, so don't refer to them as such. But it also leads to confusion like this article.
Come on, no matter how much of a Linux fan you are, you have to admit that there's at least a chance that Linux does indeed infringe on Microsoft's patents.
Okay, it's patents we're talking about, right? Patents are published - that's the whole point of them. They aren't secret.
only Microsoft has access to most of its source code
So what? Their source code is of no use when determining patent infringement, only copyright infringement. So is it copyright infringement we are talking about then?
After all, before IBM handed over some 500 patents to the open source community, it's pretty clear that Linux was infringing some of them. Given that, why is it so hard to believe that the same isn't going on with Microsoft?"
Patent and copyright violation are two totally different things. Copyright violation would involve somebody with access to Microsoft's source code copying it into Linux - a highly unethical and stupid thing to do. I don't think Linux kernel contributors are likely to be highly unethical and stupid. Patent infringement, on the other hand, can be unintentional - but in this case, his remarks about it being impossible to verify don't apply.
This is a case where the term "IP" as a blanket reference to very different rights is confusing the issue. His arguments don't apply to either because he thinks they are the same thing.
Remote File Inclusion. It's a pretty poor term for this type of attack, because it's not the act of inclusion that causes the problem, it's the act of requesting the file in the first place.
Read it again, he's not arguing against multiple accounts. He's saying that if you can log in as a new user when the screen is locked, then you don't need to have an explicit "log off" button, you can just lock the screen.
This is the same company that abused the DMCA to shut down competition, remember? So they reinstated a few accounts after screwing up. Big deal. They're still barratry bullies.
Any scammer out there can get a nearly free hosting plan and upload whatever content they want.
Yes, but that's not a problem because they aren't on a domain where you have a saved password. The problem here is that random people can upload content to, say, myspace.com, and if you have a password for myspace.com, your browser will automatically fill their form in. When an attacker uploads something to attacker.example.com, you aren't going to care because you don't have a saved password for attacker.example.com.
Slashdot Mirror
<word><letter type="capital">W</letter><letter>h</letter><lette
<space/>
<word><letter>d</letter><letter>o</letter></word>
<space/>
<word><letter>y</letter><letter>o</letter><letter
<space/>
<word><letter>s</letter><letter>a</letter><letter
<space/>
<word><letter>t</letter><letter>h</letter><letter
<punctuation>?</punctuation>
</sentence>
Yeah, that's really a pain in the neck, particularly for for designers, but again, it's a limitation brought about by the desire to make it easy to implement rendering engines. If you look at a lot of the things that match your description, you'll find that, say, you can't allow a certain property for a certain type of element because it would involve having the rendering engine jump through hoops to make it happen. Frequently the specification looks more complicated than it actually is because it is written in English and not pseudocode, and English sucks for describing processes.
There's a balance that has to be struck between making things simple for designers and making things simple for browser developers. In hindsight, I think CSS is weighted too far in favour of the browser developers, but when you consider the performance constraints of 1996 computers, some of the decisions start to make more sense. For example, if CSS selectors were more contextually aware, there's no way a browser would be able to evaluate them in a reasonable timeframe on pages the size of, say, Slashdot comment pages. And, of course, similar constraints are in place today with mobile platforms.
No, if you are thinking of the <div> element type as a replacement for the <table> element type, you're still doing it wrong. Moving to CSS isn't about replacing <table> with <div>, it's about using the most appropriate element type for the job. You only use <div> when there isn't anything more appropriate (there usually is).
The W3C's CSS validator has recently been changed to check against CSS 2.1 by default instead of CSS 2. The text-shadow property was removed from CSS 2.1 because virtually no browser developers bothered to implement it. The stylesheet is still a valid CSS 2 stylesheet, but you wouldn't know that because nobody's bothered to come up with a way of labelling stylesheets to denote what level of CSS they are meant to conform to.
On the contrary, some of the most frequently complained about shortcomings of CSS are due to the desire to keep implementations simple, which is practically the opposite of being "all about theory". They purposefully left out things like a decent query mechanism because they considered it too hard for people to implement.
No, Netscape implemented an alternative (JSSSL) and submitted it to the W3C for standardisation. It was more powerful than CSS, and that's one of the reasons why CSS was a better choice.
Delivering differentiated content to work around buggy user-agents is a function of the transport protocol, not something you want to replicate for each and every file format delivered over that protocol. It is built into the standard - the right standard for this, HTTP. I quote from RFC 2616:
Of course, it isn't reliable, but that's because of abuse from both web developers and browser developers. It's only in the face of this abuse that stupid workarounds in particular file formats is necessary.
That's already possible with CSS 3 Media Queries, already implemented by Opera.
The example most relevant to me is the web. They essentially conned Spyglass into licensing code for Internet Explorer royalty-free, then "cut off Netscape's air supply". Once Netscape was dead, they abandoned Internet Explorer for five years, during which time web developers the world over had to support their lousy bug-ridden code because everybody used it, because it shipped with Windows.
I'm a web developer. The abandoned, buggy Internet Explorer with major market share has cost me time and money. If it wasn't for Microsoft, I'd have more money in my pocket. I'd have had more long weekends. I've have gone home earlier more often instead of working overtime to figure out the latest Internet Explorer foible. I'd have been able to do better things with less code instead of having one arm tied behind my back. And even now they are developing Internet Explorer again, it will still be years before this changes. That's why I hate Microsoft.
On the contrary, the "PHP Way" has always been to give defaults where the user is likely to shoot himself in the foot, and when it inevitably happens, blame him for not changing the defaults (despite it breaking third-party applications). And the "benefit" you describe not only doesn't exist, it's the exact opposite of the truth - take "magic quotes" for example, where the language is slowed down by "features which exist only to keep stupid programmers from hurting themselves", and still manages to cause security headaches.
Having seen the update to the story by Zeev, I have to disagree. There is a grey area between bugs in PHP and bugs in PHP applications, and this is one of the major problems of PHP - a design that, when used correctly isn't insecure, but also a design that makes it much more likely that it's used incorrectly. This is a problem caused by PHP itself, but the symptoms manifest themselves as problems with PHP applications, making it easy to pass the buck.
I'm not surprised. If you read the article, you come across this gem:
That's right, the PHP team think that dedicating a month to finding security holes in PHP is "harming the project".
Stefan has a bit of a reputation for being "abrasive". But in my opinion, it is because he's got decent (not unreasonable, but decent) quality standards, and isn't afraid to hold other people to them. In a normal project, that wouldn't be so bad, but given the prevailing attitudes of the PHP project, it's understandable that he blows up frequently enough to have a reputation.
It's not Ajax per se that disallows it. The problem is that a lot of developers use <a href="#" onclick="..."> and don't provide an actual URI to open.
Yes, it is, and I've said as much in the past. It's actually even worse than the average clueless developer, because it doesn't even use <a> for links - it uses <span> and click handlers to provide really, really crappy emulated links. Of course, doing so immediately throws the normal link handling your web browser provides out the window, including (but not limited to) opening them in new tabs or windows.
It's not. It's usually either developer ignorance or developer apathy - they either don't know how to do it or they don't care.
ECMA have ratified a few standards relating to JavaScript - for instance, ECMA 262 defines the language that JavaScript, JScript, ActionScript and QtScript are implementations of, and the E4X extension that allows XML literals is also an ECMA standard.
I'm not sure what you are getting at. Yes, they are deprecated, but that doesn't mean that they aren't part of the specification or that they cannot be used in a conformant document. Deprecated essentially means that they are going away in the next version - and <font> did exactly that, it's not present in XHTML 1.1. This doesn't change my point that the use of <font> is irrelevant to the question of standards compliance.
Don't make me laugh. Microsoft still haven't come anywhere close to finishing their CSS 2 implementation, the specification for which was published over eight years ago. The same goes for other specifications - for example, they've only just finished PNG, and that specification was published over a decade ago. You simply can't call the W3C too slow for Microsoft when it's Microsoft that can't keep up with the W3C.
There's a strong correlation between people who adhere to the W3C's specifications and people who separate content from presentation, but that doesn't mean that they are the same thing. <font> and <table> are in the HTML 4 and XHTML 1.0 specifications.
Conflating the two leads to people claiming stupid things, like that they are writing "standard" code because they use CSS, when in fact their code is non-standard and full of hacks.
I know over the past few years "web standards" has become a popular buzzword, but there's a difference between best practices and conformance to particular specifications. Just because it's a good thing, it doesn't mean the specifications require it, and jujst because it's in the specifications, it doesn't mean it's a good thing.
Americans are wasting a billion gallons of fuel per year by being so fat.
Lose some weight. It's good for you and it's good for the environment.
There was a bit in there about a way of handling GPL violators who want to be able to redistribute again. According to Stallman, this is because when you redistribute without following the terms of the GPL, you lose any further right you have to distribute it, even if you comply with the GPL later on. In the article, he says he's not sure where the idea originated, but I suspect it's somewhere in the KDE camp, as this is where the idea that you need "forgiveness" from the copyright holder was first seen. The "cure" proposal would be a way of granting that forgiveness automatically.
50 years-worth of royalties isn't enough of a financial reward?
Brits here should check out the petition for private copying on 10 Downing Street's website. It's essentially asking that the government do what the think tank suggested.
First and foremost, copyrights and patents are not property, so don't refer to them as such. But it also leads to confusion like this article.
Okay, it's patents we're talking about, right? Patents are published - that's the whole point of them. They aren't secret.
So what? Their source code is of no use when determining patent infringement, only copyright infringement. So is it copyright infringement we are talking about then?
Patent and copyright violation are two totally different things. Copyright violation would involve somebody with access to Microsoft's source code copying it into Linux - a highly unethical and stupid thing to do. I don't think Linux kernel contributors are likely to be highly unethical and stupid. Patent infringement, on the other hand, can be unintentional - but in this case, his remarks about it being impossible to verify don't apply.
This is a case where the term "IP" as a blanket reference to very different rights is confusing the issue. His arguments don't apply to either because he thinks they are the same thing.
I think it's also worth pointing out Stallman's criticism of the term "Intellectual Property".
Slashdot had an article about this a couple of months ago.
Read his comment again:
He's talking about companies that sell software to people running Vista Home.
Remote File Inclusion. It's a pretty poor term for this type of attack, because it's not the act of inclusion that causes the problem, it's the act of requesting the file in the first place.
Read it again, he's not arguing against multiple accounts. He's saying that if you can log in as a new user when the screen is locked, then you don't need to have an explicit "log off" button, you can just lock the screen.
This is the same company that abused the DMCA to shut down competition, remember? So they reinstated a few accounts after screwing up. Big deal. They're still barratry bullies.
Yes, but that's not a problem because they aren't on a domain where you have a saved password. The problem here is that random people can upload content to, say, myspace.com, and if you have a password for myspace.com, your browser will automatically fill their form in. When an attacker uploads something to attacker.example.com, you aren't going to care because you don't have a saved password for attacker.example.com.