The w3c check is not an acurate measure on how thruly accessible the pages are
I now this because I have friends who are blind and frecuently use screen reader applications
Yes and no. On the one hand, WCAG does have acknowledged shortcomings and it's certainly no guarantee. But aural browsers and screenreaders tend to be absolutely awful when it comes to supporting the markup that's intended to help them. They aren't designed to read accessible websites, they are designed to scrape as much meaning as they can out of inaccessible websites.
So from a practical perspective, yes, you need to test in individual assistive user-agents if you want your website to be as usable as possible by disabled people. But when the markup is fine according to the W3C and assistive user-agents get it wrong, it's usually because the developers of the assistive user-agents haven't even heard of the W3C.
I have to disagree with both of you. People block ads not because of risk, not because they take up too much bandwidth and processor power, but because they take up too much attention. People want to pay attention to the real content, not wade through fake distracting crap that wants to sell them something.
I don't know of any general-purpose libraries, but the latest version of Wordpress has a system like that that you could rip out.
Re:The problem with the alternatives to PHP
on
Pro PHP Security
·
· Score: 3, Insightful
Ignoring support by ISP's
That's the #1 issue by far. Even if all the competition were ten times better than PHP, if the average person can only find cheap PHP hosting, that's what they are going to use.
I'm not even aware of where I could find documentation on Python libraries to communicate with MySQL
Seriously? Go to python.org. Scroll down the page to where you see the "Using Python for... databases" link. Click it.
There's another point - Python modules come with help built into them, and Python comes with a help browser. And if you don't want to use that, just load the Python interpreter and run help(module). I don't think PHP has anything similar to that yet.
PHP allows you to inline your code into your documents
While separating content from presentation might be the point of CSS, it is not to create a hundred different versions of the same website for a hundred different visitors. That's simply one not-very-useful consequence.
You could do things like serve random style sheets to viewers so contents look different.
Yes, you could, but why on earth would you? Are you really telling me this is what you think CSS is for?
This makes it easy to make different styles for handhelds, cell phones, printouts, the blind, etc.
Yes, it does, but if that was what Dvorak was getting at, then he chose a remarkably obtuse way of saying so. Considering he writes for a living, I can't believe even Dvorak is that bad at expressing himself. I think it's far more likely that he simply doesn't understand CSS and he strung a few techie-sounding words together in a vague attempt to sound like he knew what he was talking about.
Browsers are lousy in terms of supporting the various specifications people have published that define useful things web developers want and need to do. This has numerous effects:
It slows down and frustrates web developers.
It raises the costs of web development.
It makes some things impossible.
All of these are pretty bad for web developers, but they have knock-on effects that end-users suffer from, but don't understand. For example, when was the last time you ran across a bug on a website? Did you ever consider that a web developer would have got around to fixing it before you had trouble with it if he hadn't been busy trying to work around a bug in Internet Explorer?
The Acid2 test is merely a collection of all kinds of ways in which browsers screw up support for particular specifications. The idea is that it contains lots of things that browsers get wrong which cause hassle for web developers, and that browser developers can use it as a check-list for bugs. It's also a gimmick to raise awareness for these bugs to put pressure on the browser developers to fix them.
The more browsers that pass the Acid2 test, the better support there is for web developers. The better support there is for web developers, the higher the quality of the work they put out. And you, as an end-user of that work, benefit. It's too many steps removed for you to see, but it's certainly not the meaningless statistic you think it is.
To use your analogy with CPUs, imagine if every CPU screwed up 10% of the time, and applications like word processors and mail clients had to have 30% more code written to work around the bugs in CPUs. Would you say that was a problem, and demand better quality CPUs, or would you say "Hey, not a problem, the application developers can work around it, right?" Because that's the analogous situation; the "processors" of the WWW are utterly broken, and a huge amount of effort is being wasted because they aren't getting fixed.
Contrary to your statement, opera does not have spell checking out of the box. It's available as a 3rd party add-on.
I know that's what the article says, but it's highly misleading. Opera hooks into the native spelling checker on each platform it runs on. On OS X, this is an official system service. On other platforms, it uses Aspell - which comes as standard in virtually every Linux distribution and installed on most UNIX systems. Windows doesn't provide a standard spelling checker, but Opera still uses Aspell if it's installed.
So "third-party add-on" is a long way from the truth. It's automatically available without any add-on necessary on most platforms, and it automatically recognises a common spelling-checker if it's installed on Windows. It's nothing like Firefox 1 and the Google extension at all.
Now if only they could fix Gecko's inability to render display: inline-block properly, it might become a halfway usable browser. Quite why it's taken so long is beyond me. It's was originally logged as a bug 7 years ago
Seven years ago, that was a proprietary Internet Explorer property. It's been added to the upcoming CSS 2.1, but that's still only a draft. It's not like it's been a missing part of CSS support for seven years, until recently it was totally non-standard, and technically it still is.
Firefox 2 doesn't pass Acid 2 because no work has been done on Gecko
Oh come on, don't be such an apologist. Are you seriously saying "It's unfair! They're only behind on that because they didn't work on it!" How is that unfair? They had just as much opportunity to fix things as Opera did, the difference is that they chose not to. That may or may not be a good decision to make, but you can't exactly call it "unfair", can you?
Firefox 3 (which will use Gecko 1.9) will pass the Acid 2 Test.
That doesn't matter, what's planned for Firefox 3 doesn't make Firefox 2 any better. When Firefox 3 is released, we can compare that with Opera 10 and Internet Explorer 8, which will both have moved forward too.
Standout features are Opera's built-in BitTorrent support, Firefox's spellchecker for forms, and IE's Quick Tabs view.
How can Firefox's spelling checker be a "standout feature" when Opera, Safari and Konqueror already have it built in? It's more of a "catch-up feature" than a "standout feature".
Re:Internet Connection Losing CSS data??? WTF???
on
Dvorak Rants on CSS
·
· Score: 5, Funny
It's when there's a hole in one of the tubes, all the CSS starts to leak out.
But no commercial clients will ever let their web crew turn away any possible customers
So do it for your non-commercial work. Don't turn them away, just disable all CSS and JavaScript and give them the plain HTML. Include a big notice at the top with conditional comments telling them that their browser is broken and that is why they are getting the retard-friendly version instead of the high quality version everybody else is getting, and provide links to other browsers.
Sure, you'll lose some users, but you'll save a lot of work and inspire a few people to switch. The trick is to make them feel like they are missing out on something other people are getting.
it appears he's basically experiencing some pain with his first exposure trying to format using a technology that he doesn't really understand.
Precisely. The first clue should be when he says:
CSS's real benefit was that the layout not only could be changed easily but also could become dynamic: The content is stored in a database and presented as necessary, with instant updates. With dynamic content, it's possible for 100 people to go to the same Web site and get 100 different versions.
What the hell is he talking about? Not only is that not CSS's "real benefit", I can't even figure out how he managed to get the idea that this is what CSS is all about. Did he take one look at the CSS Zen Garden and completely miss the point or something?
He can't even get basic facts and terminology right:
The first problem is the idea of "cascading." It means what it says: falling--as in falling apart. You set a parameter for a style element, and that setting falls to the next element unless you provide it with a different element definition.
Nope, wrong. That's inheritance. The cascade is when you resolve rules found in multiple stylesheets.
You don't "set parameters for style elements" at all. Style elements are instances of the <style> element type, and they are used to include parts of a stylesheet in an HTML or XHTML document. You don't set parameters for elements either. He could be talking about attributes, or perhaps properties, it's hard to tell when his terminology is so muddled.
Finally, this bit is hilarious:
Worse yet, nobody except the most techie insiders wants to talk about this mess.
That's right, he's been totally oblivious to CSS, and now, when he starts to learn a bit about it, he blames his ignorance on some sort of conspiracy! That's right, us "techie insiders" have been keeping the truth from you, muhahaha!
Writing the URIs is where all the pain is. I don't see any difference here this and hashing out any other protocol spec.
The difference as I see it is simply that the protocol is being specified at a higher level, which means that if you have the right libraries, it's just less work to implement.
It's those other problems -- the ones beyond their scope -- that remain unaddressed.
My perspective is that you don't stand a chance of solving the larger problems in a generic way until you solve the smaller problems they are dependent upon in a generic way. The web started out solving the addressability and file transfer problems and bashed out an ad-hoc markup language to tie it all together. Then we got XML to solve the markup syntax problem (yeah, SGML was there beforehand). Now we have RDF to specify relationships. They are all individual steps along the path. The key thing is that they are useful on their own merits apart from the Semantic Web, which lets them be used and refined right now, rather than needing to invent a whole Semantic Web all at once.
Some SemWeb advocates tell me that they've almost got this solved and pretty soon we won't have to do this any more -- they'll all be written automagically. This is the claim -- that this new notation, if we all used it correctly, will suddenly make the problem easy -- that smells like bullshit to me.
Me too. There's a long way to go and quite a few components missing before anybody can tie the whole lot together to solve the bigger problems generically, but each step along the way makes the manual work easier.
For example, if you are expecting an integer between 1 and 3, you still need to do input checking.
Only if you can't express that with a database constraint or if users can submit out-of-bounds data legitimately. If it's just somebody trying to cause trouble, you don't need to give them a friendly error message. For example, if the only form where they submit the data has a <select> with the values 1-3 for the options, legitimate users aren't going to submit anything else and attackers will just run up against the database constraint. There's no need to write application-level code to check the values.
The representation isn't the problem. The problem is agreeing what the the relationships mean.
That problem is not the problem that RDF addresses. It just gives you the tools so that you can concentrate on solving that problem instead of worrying about all the crap underneath. It's like XML doesn't address semantics, it just gives you tools so you can focus on semantics without worrying about parsing.
What does "#friend" mean? Does it mean the same thing to program X as it does to program Y? How can you tell?
To use the XML analogy again, the XML specification doesn't tell you what particular element types mean, because that's outside XML's scope. You read the specification for the XML document type, e.g. XHTML, to find out what an element type means.
who gets to decide what #friend means, and whether this is a global or local definition?
You're forgetting that #friend is just shorthand for a URI. It's not a literal string "friend". If Slashdot choose to expose their friend data with URIs like http://slashdot.org/rdf/#friend that doesn't have any bearing on the meaning of Friendster's data if they use URIs like http://friendster.com/rdf/#friend. They are two separate URIs with two separate meanings that the owners of the domain have chosen.
I know, the next thing you are wondering is how this is of value if everybody makes up their own URIs. Well the answer is, if they want interoperability, they don't just make up their own URIs. Just like people using XML get together, agree on concrete definitions and write specifications like XHTML, the same things happen with RDF vocabularies, people get together and decide what they think #friend should mean, write a specification like FOAF, and use the same URIs.
These are questions that I've never heard answered in any believable manner.
Ignore all the hype from PHBs, this isn't about computers magically understanding arbitrary documents. This is about expressing relationships in a standard way. Of course you need some way of agreeing on what relationships mean, which is why people write specifications. RDF doesn't solve that problem, it's outside RDF's scope. RDF is much smaller and more focused than you think, it's not magic.
Make sure you use strip_tags() on all incoming data that is headed for output on your page (to get rid of cross-site scripting).
Please don't do this, it's bloody annoying when half your input gets chucked away because you used a special character. I really don't see why that function ever existed, it's a total fuckup and completely unnecessary when things like htmlspecialchars() exist. Encode your user-supplied data properly, don't simply chuck bits of it away.
I thought if you just parse out the ' in user input you are immune. No?
No. For example, an attacker could use a backslash as the last character in a string, and it would escape the quote you provide to delimit the string.
Trying to roll your own escape function is insanity. Don't do it. Every database API in existence provides well-tested escaping functions. Use them.
With all my Web Apps I create a function called SafeChar, and have it replace the ' with '.
Sounds to me like your web applications are vulnerable to an XSS attack - if you really store quotes in this way, they'd fall apart once you escape them when you output them - as the & would be replaced with &. If your applications aren't breaking in this way, then you probably aren't escaping properly.
I am curious what language automatically checks your users input for any attempt at SQL Injection.
You're approaching it with the wrong mindset. A database API shouldn't check for SQL injection attempts, it should encode the input appropriately. Avoiding SQL injection attacks is just a subset of correct operation, as anybody with an Irish surname could tell you.
As for an example, well with Python's DB-API 2.0, you write code like this:
cursor.execute("select foo from bar where baz = %s;", (quux,))
It doesn't matter whether quux has apostrophes, it gets automatically escaped because the API is designed as an interface to input data, not an interface that accepts data that has been specially prepared and cannot be distinguished from data that hasn't been specially prepared.
Web programming is never presented in that light; it's always, "here's a quick little script that fetches twenty records from a database and displays them."
It's actually worse than that, not only is security not adequately discussed, in a huge number of cases, sample code is given that is totally insecure. Newbies are being taught to write insecure code by ignorant tutorial authors.
I'm not sure why, but there's something about web development that makes people with the tiniest amount of knowledge think that they are an expert that can teach others. I've lost track of the number of "OMG Learn PHP!" tutorials that provide code that only barely manages to operate.
I still don't think I truly understand how RDF is supposed to work...
I don't think anyone does.
RDF's core idea is simple. Give everything a URI. Express relationships as a set of three URIs, (subject, property, value). So you might have (#me, #friend, #bob) expressing the idea that Bob is a friend of mine. Or you might have (#photo, #contains, #me), expressing the idea that I'm in a photo.
RDF is little more than a mechanism for expressing relationships. It doesn't give software the ability to understand those relationships, you need to build that on top. RDF just helps you solve the relationship problem in a generic way. So, for example, even if you have (#me, #friend, #bob), that's still meaningless until you write software that knows the #friend, #spouse, #employer, #whatever URIs are relationships between people. For instance, you could build a social network like Friendster, only decentralised - and people have, with FOAF, because they've agreed that particular URIs express particular relationships.
Most all of us these days are writing webapps that spit out xml and have a CSS style sheet that makes that stuff pretty.
XML has no semantics whatsoever. None. It's a way of serialising and unserialising a tree of elements and attributes. It's markup languages that are built on top of XML that contain the semantics. Part of the Semantic Web is finding a good representation for the deeper semantics that are pervasive on the web. Think less about "This bit of text is a paragraph" and more about "This is the relationship X has with Y".
With that infrastructure, you can express all kinds of different things with minimal special-case knowledge from the software you are using. The same code can handle relationships expressing you tagging a Slashdot story as [troll] and relationships expressing your friend network on Friendster. The way you interact with that code will be different - so the UI stuff will be special-case, but underneath the superficial stuff, it can be handled more generically, which means you don't have to come up with a new XML document type every time you want to express a different set of semantics.
Tim Berners-Lee seems to stress the fact that the semantic Web is all about AI doing content classification for us.
I don't think I've seen him stress that in the sense that the users are dissassociated from the process. The Semantic Web is all about representing things like tags, microformats, etc, in a generic way.
For example, if comment moderation was defined in terms of a relationship between a person, a comment, and an opinion, that doesn't mean a computer would be moderating comments, it just means that the same mechanism could be applied across multiple websites, without having to build moderation into the websites themselves. You could mod Dvorak -1, Troll, and everybody who lists you in their FOAF file using a browser that supports it, would see that moderation.
Just because the focus is on making the software smarter, it doesn't mean that it's about replacing user opinions with computer opinions. In fact, the majority of Semantic Web stuff I've seen have been all about codifying user opinions to make them more accessible to computers, and thus, more easily exposable to the end-user in a useful way.
Slashdot Mirror
Yes and no. On the one hand, WCAG does have acknowledged shortcomings and it's certainly no guarantee. But aural browsers and screenreaders tend to be absolutely awful when it comes to supporting the markup that's intended to help them. They aren't designed to read accessible websites, they are designed to scrape as much meaning as they can out of inaccessible websites.
So from a practical perspective, yes, you need to test in individual assistive user-agents if you want your website to be as usable as possible by disabled people. But when the markup is fine according to the W3C and assistive user-agents get it wrong, it's usually because the developers of the assistive user-agents haven't even heard of the W3C.
Yeah, because letting people run around with guns really solved the USA's violent crime problem, didn't it?
I have to disagree with both of you. People block ads not because of risk, not because they take up too much bandwidth and processor power, but because they take up too much attention. People want to pay attention to the real content, not wade through fake distracting crap that wants to sell them something.
I don't know of any general-purpose libraries, but the latest version of Wordpress has a system like that that you could rip out.
That's the #1 issue by far. Even if all the competition were ten times better than PHP, if the average person can only find cheap PHP hosting, that's what they are going to use.
Seriously? Go to python.org. Scroll down the page to where you see the "Using Python for... databases" link. Click it.
There's another point - Python modules come with help built into them, and Python comes with a help browser. And if you don't want to use that, just load the Python interpreter and run help(module). I don't think PHP has anything similar to that yet.
So does mod_python.
W3C CSS test suites.
While separating content from presentation might be the point of CSS, it is not to create a hundred different versions of the same website for a hundred different visitors. That's simply one not-very-useful consequence.
Yes, you could, but why on earth would you? Are you really telling me this is what you think CSS is for?
Yes, it does, but if that was what Dvorak was getting at, then he chose a remarkably obtuse way of saying so. Considering he writes for a living, I can't believe even Dvorak is that bad at expressing himself. I think it's far more likely that he simply doesn't understand CSS and he strung a few techie-sounding words together in a vague attempt to sound like he knew what he was talking about.
Browsers are lousy in terms of supporting the various specifications people have published that define useful things web developers want and need to do. This has numerous effects:
All of these are pretty bad for web developers, but they have knock-on effects that end-users suffer from, but don't understand. For example, when was the last time you ran across a bug on a website? Did you ever consider that a web developer would have got around to fixing it before you had trouble with it if he hadn't been busy trying to work around a bug in Internet Explorer?
The Acid2 test is merely a collection of all kinds of ways in which browsers screw up support for particular specifications. The idea is that it contains lots of things that browsers get wrong which cause hassle for web developers, and that browser developers can use it as a check-list for bugs. It's also a gimmick to raise awareness for these bugs to put pressure on the browser developers to fix them.
The more browsers that pass the Acid2 test, the better support there is for web developers. The better support there is for web developers, the higher the quality of the work they put out. And you, as an end-user of that work, benefit. It's too many steps removed for you to see, but it's certainly not the meaningless statistic you think it is.
To use your analogy with CPUs, imagine if every CPU screwed up 10% of the time, and applications like word processors and mail clients had to have 30% more code written to work around the bugs in CPUs. Would you say that was a problem, and demand better quality CPUs, or would you say "Hey, not a problem, the application developers can work around it, right?" Because that's the analogous situation; the "processors" of the WWW are utterly broken, and a huge amount of effort is being wasted because they aren't getting fixed.
I know that's what the article says, but it's highly misleading. Opera hooks into the native spelling checker on each platform it runs on. On OS X, this is an official system service. On other platforms, it uses Aspell - which comes as standard in virtually every Linux distribution and installed on most UNIX systems. Windows doesn't provide a standard spelling checker, but Opera still uses Aspell if it's installed.
So "third-party add-on" is a long way from the truth. It's automatically available without any add-on necessary on most platforms, and it automatically recognises a common spelling-checker if it's installed on Windows. It's nothing like Firefox 1 and the Google extension at all.
Seven years ago, that was a proprietary Internet Explorer property. It's been added to the upcoming CSS 2.1, but that's still only a draft. It's not like it's been a missing part of CSS support for seven years, until recently it was totally non-standard, and technically it still is.
Oh come on, don't be such an apologist. Are you seriously saying "It's unfair! They're only behind on that because they didn't work on it!" How is that unfair? They had just as much opportunity to fix things as Opera did, the difference is that they chose not to. That may or may not be a good decision to make, but you can't exactly call it "unfair", can you?
That doesn't matter, what's planned for Firefox 3 doesn't make Firefox 2 any better. When Firefox 3 is released, we can compare that with Opera 10 and Internet Explorer 8, which will both have moved forward too.
How can Firefox's spelling checker be a "standout feature" when Opera, Safari and Konqueror already have it built in? It's more of a "catch-up feature" than a "standout feature".
It's when there's a hole in one of the tubes, all the CSS starts to leak out.
So do it for your non-commercial work. Don't turn them away, just disable all CSS and JavaScript and give them the plain HTML. Include a big notice at the top with conditional comments telling them that their browser is broken and that is why they are getting the retard-friendly version instead of the high quality version everybody else is getting, and provide links to other browsers.
Sure, you'll lose some users, but you'll save a lot of work and inspire a few people to switch. The trick is to make them feel like they are missing out on something other people are getting.
Precisely. The first clue should be when he says:
What the hell is he talking about? Not only is that not CSS's "real benefit", I can't even figure out how he managed to get the idea that this is what CSS is all about. Did he take one look at the CSS Zen Garden and completely miss the point or something?
He can't even get basic facts and terminology right:
Nope, wrong. That's inheritance. The cascade is when you resolve rules found in multiple stylesheets.
You don't "set parameters for style elements" at all. Style elements are instances of the <style> element type, and they are used to include parts of a stylesheet in an HTML or XHTML document. You don't set parameters for elements either. He could be talking about attributes, or perhaps properties, it's hard to tell when his terminology is so muddled.
Finally, this bit is hilarious:
That's right, he's been totally oblivious to CSS, and now, when he starts to learn a bit about it, he blames his ignorance on some sort of conspiracy! That's right, us "techie insiders" have been keeping the truth from you, muhahaha!
The difference as I see it is simply that the protocol is being specified at a higher level, which means that if you have the right libraries, it's just less work to implement.
My perspective is that you don't stand a chance of solving the larger problems in a generic way until you solve the smaller problems they are dependent upon in a generic way. The web started out solving the addressability and file transfer problems and bashed out an ad-hoc markup language to tie it all together. Then we got XML to solve the markup syntax problem (yeah, SGML was there beforehand). Now we have RDF to specify relationships. They are all individual steps along the path. The key thing is that they are useful on their own merits apart from the Semantic Web, which lets them be used and refined right now, rather than needing to invent a whole Semantic Web all at once.
Me too. There's a long way to go and quite a few components missing before anybody can tie the whole lot together to solve the bigger problems generically, but each step along the way makes the manual work easier.
Only if you can't express that with a database constraint or if users can submit out-of-bounds data legitimately. If it's just somebody trying to cause trouble, you don't need to give them a friendly error message. For example, if the only form where they submit the data has a <select> with the values 1-3 for the options, legitimate users aren't going to submit anything else and attackers will just run up against the database constraint. There's no need to write application-level code to check the values.
That problem is not the problem that RDF addresses. It just gives you the tools so that you can concentrate on solving that problem instead of worrying about all the crap underneath. It's like XML doesn't address semantics, it just gives you tools so you can focus on semantics without worrying about parsing.
You read the specification for the vocabulary you are working with. For example, here's the FOAF specification.
To use the XML analogy again, the XML specification doesn't tell you what particular element types mean, because that's outside XML's scope. You read the specification for the XML document type, e.g. XHTML, to find out what an element type means.
You're forgetting that #friend is just shorthand for a URI. It's not a literal string "friend". If Slashdot choose to expose their friend data with URIs like http://slashdot.org/rdf/#friend that doesn't have any bearing on the meaning of Friendster's data if they use URIs like http://friendster.com/rdf/#friend. They are two separate URIs with two separate meanings that the owners of the domain have chosen.
I know, the next thing you are wondering is how this is of value if everybody makes up their own URIs. Well the answer is, if they want interoperability, they don't just make up their own URIs. Just like people using XML get together, agree on concrete definitions and write specifications like XHTML, the same things happen with RDF vocabularies, people get together and decide what they think #friend should mean, write a specification like FOAF, and use the same URIs.
Ignore all the hype from PHBs, this isn't about computers magically understanding arbitrary documents. This is about expressing relationships in a standard way. Of course you need some way of agreeing on what relationships mean, which is why people write specifications. RDF doesn't solve that problem, it's outside RDF's scope. RDF is much smaller and more focused than you think, it's not magic.
Please don't do this, it's bloody annoying when half your input gets chucked away because you used a special character. I really don't see why that function ever existed, it's a total fuckup and completely unnecessary when things like htmlspecialchars() exist. Encode your user-supplied data properly, don't simply chuck bits of it away.
No. For example, an attacker could use a backslash as the last character in a string, and it would escape the quote you provide to delimit the string.
Trying to roll your own escape function is insanity. Don't do it. Every database API in existence provides well-tested escaping functions. Use them.
Sounds to me like your web applications are vulnerable to an XSS attack - if you really store quotes in this way, they'd fall apart once you escape them when you output them - as the & would be replaced with &. If your applications aren't breaking in this way, then you probably aren't escaping properly.
You're approaching it with the wrong mindset. A database API shouldn't check for SQL injection attempts, it should encode the input appropriately. Avoiding SQL injection attacks is just a subset of correct operation, as anybody with an Irish surname could tell you.
As for an example, well with Python's DB-API 2.0, you write code like this:
It doesn't matter whether quux has apostrophes, it gets automatically escaped because the API is designed as an interface to input data, not an interface that accepts data that has been specially prepared and cannot be distinguished from data that hasn't been specially prepared.
It's actually worse than that, not only is security not adequately discussed, in a huge number of cases, sample code is given that is totally insecure. Newbies are being taught to write insecure code by ignorant tutorial authors.
I'm not sure why, but there's something about web development that makes people with the tiniest amount of knowledge think that they are an expert that can teach others. I've lost track of the number of "OMG Learn PHP!" tutorials that provide code that only barely manages to operate.
RDF's core idea is simple. Give everything a URI. Express relationships as a set of three URIs, (subject, property, value). So you might have (#me, #friend, #bob) expressing the idea that Bob is a friend of mine. Or you might have (#photo, #contains, #me), expressing the idea that I'm in a photo.
RDF is little more than a mechanism for expressing relationships. It doesn't give software the ability to understand those relationships, you need to build that on top. RDF just helps you solve the relationship problem in a generic way. So, for example, even if you have (#me, #friend, #bob), that's still meaningless until you write software that knows the #friend, #spouse, #employer, #whatever URIs are relationships between people. For instance, you could build a social network like Friendster, only decentralised - and people have, with FOAF, because they've agreed that particular URIs express particular relationships.
XML has no semantics whatsoever. None. It's a way of serialising and unserialising a tree of elements and attributes. It's markup languages that are built on top of XML that contain the semantics. Part of the Semantic Web is finding a good representation for the deeper semantics that are pervasive on the web. Think less about "This bit of text is a paragraph" and more about "This is the relationship X has with Y".
With that infrastructure, you can express all kinds of different things with minimal special-case knowledge from the software you are using. The same code can handle relationships expressing you tagging a Slashdot story as [troll] and relationships expressing your friend network on Friendster. The way you interact with that code will be different - so the UI stuff will be special-case, but underneath the superficial stuff, it can be handled more generically, which means you don't have to come up with a new XML document type every time you want to express a different set of semantics.
I don't think I've seen him stress that in the sense that the users are dissassociated from the process. The Semantic Web is all about representing things like tags, microformats, etc, in a generic way.
For example, if comment moderation was defined in terms of a relationship between a person, a comment, and an opinion, that doesn't mean a computer would be moderating comments, it just means that the same mechanism could be applied across multiple websites, without having to build moderation into the websites themselves. You could mod Dvorak -1, Troll, and everybody who lists you in their FOAF file using a browser that supports it, would see that moderation.
Just because the focus is on making the software smarter, it doesn't mean that it's about replacing user opinions with computer opinions. In fact, the majority of Semantic Web stuff I've seen have been all about codifying user opinions to make them more accessible to computers, and thus, more easily exposable to the end-user in a useful way.