Talk about a coincidence... I clicked over to/. while I was waiting for my order at templatemonster.com to process. I was vaugly aware of the sites like this, but never really looked at the templates until yesterday. They offer full, very professional website templates
I just had a look at their code. Their website isn't even valid. They use proprietary element types and attributes, they miss off important accessibility hints like alt attributes, they include a number of mistakes in their CSS that only Internet Explorer ignoring the CSS specification would ever do anything with, and so on.
It might be acceptable for a beginner who is playing around with a website for a hobby, but I couldn't describe it as professional when they make so many beginner errors.
That's just it - it isn't. PHP has made significant improvements to their object model in the 4.x and 5.x versions for those people that choose to use it. Everybody who doesn't like object-oriented programming can simply carry on using their own style and it doesn't affect them at all.
If you want to separate business logic from presentation, which is almost manditory on a large site, you will want some sort of templating package.
Not really. It's perfectly acceptable to put business logic in included classes and simply use simple PHP embedded in the page to do nothing more than output the results of that business logic.
You will have to write your own.
You're kidding, right? That is flat-out wrong. There are loads of template engines freely available to everybody. Nobody has to write their own.
This is a common need, why shouldn't the core language address it?
It does. PHP is a template language itself. Furthermore, there are PEAR packages that add additional capabilities.
No it isn't. It's marking up text to describe the document structurally and semantically.
An HTML tag is merely the start of a structure, it isn't an instruction to a browser. Think "this is a paragraph", not "leave a vertical space"; think "this is a heading", not "increase the size of the text".
If they'd had to create fully valid HTML before the browser gave them the time of day, they'd probably have fallen at the first hurdle.
I don't think that's true at all, and you haven't even suggested why that might be the case.
What I think would happen is:
Beginner enters bad HTML.
Beginner loads it in the browser.
Beginner sees error.
Beginner looks at the tutorial.
Beginner thinks "oops, I missed a bit".
Beginner fixes their mistake.
Beginner loads it in the browser.
Beginner is pleased with the result.
It's easy to make a mistake in HTML. It's also easy to correct a mistake.
"But it's full of malformed crap!" you say. Frankly, who gives a shit?
Everybody who has to deal with it? How much time do you think Mozilla developers have wasted trying to be bug-for-bug compatible with Internet Explorer? Wouldn't you have preferred it if they could have spent their time on something productive like SVG instead?
The malformed crap raises the barrier to entry for browser developers. Think about the number one objection most people have to switching browsers - it doesn't handle the malformed crap in the same way as Internet Explorer.
The fact that browser authors have to create nasty code to handle this stuff is a tiny price to pay for something as fantastic as the World Wide Web.
You still haven't explained why malformed crap is necessary for the WWW to exist.
But, hey, if you want to make a web browser that treats everything fully strictly, go right ahead.
It won't work. That's my whole point. It won't work because of all the malformed crap.
If you want to make a new hypertext network where everything has to be 100% valid to work, go right ahead. No one's ever gonna use 'em, because the world doesn't work that way.
Ever heard of XML? If you try and put malformed crap through an XML parser, it throws a fatal error. It has to; it's in the XML 1.0 specification. Last time I checked, XML was quite popular.
It's not about a page with bad layout because of invalid CSS, it's about Mozilla's own big, ugly error message. Your visitor will not see anything but the error message.
C++ compilers are strict about syntax. Why don't I see you complaining about how users are confronted with compilation errors every time they try and run an application with a tiny error in? Because they don't. Why don't they? Because the developers are made aware of the error immediately and must fix it before they can release it to the public.
The same logic applies to the web. If browsers refused to render corrupt HTML documents, do you really think web developers would continue to publish broken websites?
TBL said the philosophy that allowed the web to grow was: be tolerant of input, strict on output.
Actually, that is Postel's Law, and web developers, CMSs and web development tools are overwhelmingly not strict on output, which is why the web is in such the mess it is.
And arguing that auto-correcting malformed HTML tags is security risk is laughable really.
Laughing is ignorant. Lax parsing is indeed a security risk.
For example, you can filter out all resources but those of text/* and image/* media types at an HTTP proxy. It won't matter, because you can label an executable as text/plain and Internet Explorer will ignore RFC 2616 and treat it as an executable.
If you are writing a web application, for user-submitted data, you have to filter out not only everything harmful, but everything that could possibly be interpreted as harmful. For instance - comments are safe enough, right? Nope. Internet Explorer lets you hide JScript in comments, and it will be executed.
Microsoft makes it easier for the user to get content.. Mozilla doesn't.. Microsoft is the better solution (for this particular case) because it gives the user what they desire.. not what *you* the rigid developer desires.
If it were that simple I would agree. But it isn't. If common web browsers interpreted HTML and CSS rigidly, users wouldn't see any errors because web developers simply wouldn't upload broken files in the first place.
Last time I checked, tar just stops processing when it encounters a broken tarball. The GIMP can't open corrupted image files. GCC doesn't guess at what you mean when you make syntax errors in your C source code. Why is it such a crime to have a web browser that works dependably too?
Dean Edwards has published some Javascript that emulates lots of things that are broken in Internet Explorer, and he called it "IE7". That is not what this news is about, although it is excellent work.
That's IE Shines on Broken Code. It was garbage that had no correct rendering. You can't really say that "IE does a very good job at figuring out what someone actually intended with the broken code and rendering it well" when you're talking about randomly generated data intended to crash the browser.
Slashdot has broken HTML, but it's not the broken HTML that causes the problem in Firefox, it's a Firefox bug. It's in Bugzilla, along with a valid HTML testcase that exhibits the same problem. Why do people keep insisting that it's caused by Slashdot?
IE does a very good job at figuring out what someone actually intended with the broken code and rendering it well.
No it doesn't. It's just that if it's broken in Internet Explorer, virtually every web developer will go back and fix it immediately. Thus the broken code on the WWW is strongly biased to the type of error that Internet Explorer happens to handle adequately. The same cannot be said for any other web browser, simply because Internet Explorer has overwhelming market share.
Does a car require a radio to move people from A to B? Nearly every new car today comes with one, made and/or selected by the car manufacturer.
Does a single car manufacturer control 90% of the car market? Are car owners the only market for radio manufacturers?
Your analogy simply doesn't hold up. Microsoft are in trouble because they can use their desktop OS monopoly to bludgeon the media player market into submission, just like they did with the web browser market. No car manufacturer has a monopoly on cars, and radio manufacturers can sell to people who don't own cars.
You install windows and want to download firefox from the internet. Now give me one good way that doesn't request user to have 5 years of experience with dos, ftp or similar utility to do that?
You're forgetting a step. They need to connect to the Internet before they start surfing. They need an account with an ISP. What usually comes with an ISP's signup package? That's right, a web browser.
This is why it was such a blow for Netscape to skip version 5. At that point, they were still bundled on most ISP's signup CDs. That is effectively the only way they could have fought back against Internet Explorer being bundled with Windows - users won't use Internet Explorer if they get Netscape set to be the default when they sign up with their ISP.
But Netscape remained practically undeveloped for years, with ISPs having to support buggy Netscape 4. They all switched to bundling the latest version of Internet Explorer on their signup CDs, and the browser war was lost.
There isn't any reason for users to need a web browser built into their operating system. They could just as easily get a web browser from their ISP.
Verdana is a better font, but not for the web. The problem is that it has a higher aspect value than most other fonts. This means that at a smaller size it still remains legible where other fonts may not. It also means that at a normal size, it appears to be quite a bit larger than other fonts.
The problem is that web designers can't specify any particular font and assume that the web browser will honour that request. There are lots of different reasons why a different font may be substituted for the originally requested one.
This means that if a web designer specifies Verdana for small text, another font could be used in its place, resulting in unreadable text. If a web designer specifies Verdana for normal text, people will think that it's ugly because it's too big. There really aren't that many situations where Verdana is an appropriate choice for web designers.
None of this is to say that it isn't a nice font; I personally use it throughout most of KDE. But it's not a good choice for the Web Core Fonts collection.
Konqueror "cheats" in the "warm start" test. KDE automatically keeps an instance loaded after the first time you start Konqueror up. You can even configure it to preload an instance upon KDE startup (go to Control Panel | KDE Components | KDE Performance), although this isn't the default setting.
Konqueror's "cheats" in the "cold start" test as well - as you can see from the results, there are significant differences in startup time depending upon whether KDE or GNOME is used as the desktop (on account of the libraries already in memory, DCOP server, etc).
There is no need to "trick" browsers into sending any particular value for referer
You're looking at the little details but missing the big picture.
I know that the Referer header is optional. I also know that virtually everybody transmits an accurate Referer header.
If you deep link and the person you are deep linking to filters based on the Referer header, sure, there will be a few people who have switched off their Referer header that will see what you intended them to see. But most people won't.
This is why it is an effective way of stopping people from deep linking. They don't want to deep link if only 1% of their visitors will see it. They don't want to deep link if it means they have to tell their visitors to reconfigure their browsers.
It simply doesn't matter that the Referer header is untrustworthy. You are using it to deter other web developers from misappropriating your bandwidth, not as a means to stop every last page load from working.
it is optional and somewhat freeform
It is not freeform, as per RFC 2616, it is a relative or absolute URI.
I used a cgi to illustrate for convenience because it shows an easily understandable way in which arbitrary headers can be injected into a request
You used a CGI because that's the only reliable way of doing it. It's also pretty nonsensical because it's a waste of bandwidth, which is exactly what deep linkers want to avoid.
I'm certain there is some client scripting method to manipulate the headers of requests for embeded objects.
I'm unaware of anything like that. Even if something like that existed, it certainly isn't reliable, which means the deterrent will still be effective.
If you are so certain that you can manipulate HTTP headers for requests for resources on different domains, by all means, post the code.
Any dependancy on unverifiable information supplied by the client is dangerous and the level of actual protection it affords is trivial.
Current versions of firefox don't allow this, unlike the (annoyingly easy to mis-click) ActiveX install dialog in IE. [...]Sites not in the whitelist won't even get a dialog, instead a yellow bar at the top of the screen appears
That yellow bar was inspired by the way ActiveX installation works in Internet Explorer running on Windows XP with service pack 2 applied.
Um... because, why in the world should they waste their own resources (i.e. hosting the image on their machine, using their bandwidth) when they can plunder the resources of someone else?
Read the comment again. It's not a method to trick browsers into requesting the image with a particular Referer header. The method suggested uses double the bandwidth as simply hosting the image themselves - once when the CGI downloads from the original server, and once when the CGI serves the image to the visitor.
My point is not that wget can get around 'referer' header filters, but that the technique itself is a very weak protection.
No, it's very strong protection. You seem to think that this is some sort of anti-copying measure. It's a way of protecting server resources. Nobody's going to bother deep linking when 99% of their visitors are going to get broken images. They'll just copy it to their own server instead.
I bet it is only a matter of time before web board software comes up with a script for all signature images. The signature img tag is rewritten from www.whatever.tld/myimage.jpg to www.board.tld/img-sig.cgi?www.whatever.tld and a request that fakes up a referer header to make the request look like an internal link from www.whatever.tld sent instead by way of the cgi.
Why on earth would somebody do that instead of simply copying the image to their server?
On problem with this solution is that newer firewall software blocks referer headers.
That's no problem; if you re-read my comment, you'll see that I suggested only blocking requests with a Referer header that started with http that didn't match your website. Blank Referer headers and Referer headers that say "blocked by [xxx]" will not trigger this.
The typical solution to this is serving a complaint image to requests with the Referer header set to something starting with 'http' that don't correspond to your website. Five minutes on Google would have told you this (and provided ready-made recipes for Apache).
Slashdot Mirror
I just had a look at their code. Their website isn't even valid. They use proprietary element types and attributes, they miss off important accessibility hints like alt attributes, they include a number of mistakes in their CSS that only Internet Explorer ignoring the CSS specification would ever do anything with, and so on.
It might be acceptable for a beginner who is playing around with a website for a hobby, but I couldn't describe it as professional when they make so many beginner errors.
That's just it - it isn't. PHP has made significant improvements to their object model in the 4.x and 5.x versions for those people that choose to use it. Everybody who doesn't like object-oriented programming can simply carry on using their own style and it doesn't affect them at all.
Not really. It's perfectly acceptable to put business logic in included classes and simply use simple PHP embedded in the page to do nothing more than output the results of that business logic.
You're kidding, right? That is flat-out wrong. There are loads of template engines freely available to everybody. Nobody has to write their own.
It does. PHP is a template language itself. Furthermore, there are PEAR packages that add additional capabilities.
No it isn't. It's marking up text to describe the document structurally and semantically.
An HTML tag is merely the start of a structure, it isn't an instruction to a browser. Think "this is a paragraph", not "leave a vertical space"; think "this is a heading", not "increase the size of the text".
It would if browsers consistently threw errors for broken documents.
I don't think that's true at all, and you haven't even suggested why that might be the case.
What I think would happen is:
It's easy to make a mistake in HTML. It's also easy to correct a mistake.
Everybody who has to deal with it? How much time do you think Mozilla developers have wasted trying to be bug-for-bug compatible with Internet Explorer? Wouldn't you have preferred it if they could have spent their time on something productive like SVG instead?
The malformed crap raises the barrier to entry for browser developers. Think about the number one objection most people have to switching browsers - it doesn't handle the malformed crap in the same way as Internet Explorer.
You still haven't explained why malformed crap is necessary for the WWW to exist.
It won't work. That's my whole point. It won't work because of all the malformed crap.
Ever heard of XML? If you try and put malformed crap through an XML parser, it throws a fatal error. It has to; it's in the XML 1.0 specification. Last time I checked, XML was quite popular.
C++ compilers are strict about syntax. Why don't I see you complaining about how users are confronted with compilation errors every time they try and run an application with a tiny error in? Because they don't. Why don't they? Because the developers are made aware of the error immediately and must fix it before they can release it to the public.
The same logic applies to the web. If browsers refused to render corrupt HTML documents, do you really think web developers would continue to publish broken websites?
There is a big difference between failing gracefully and ballsing it up and pretending nothing's wrong.
Actually, that is Postel's Law, and web developers, CMSs and web development tools are overwhelmingly not strict on output, which is why the web is in such the mess it is.
Laughing is ignorant. Lax parsing is indeed a security risk.
For example, you can filter out all resources but those of text/* and image/* media types at an HTTP proxy. It won't matter, because you can label an executable as text/plain and Internet Explorer will ignore RFC 2616 and treat it as an executable.
If you are writing a web application, for user-submitted data, you have to filter out not only everything harmful, but everything that could possibly be interpreted as harmful. For instance - comments are safe enough, right? Nope. Internet Explorer lets you hide JScript in comments, and it will be executed.
If it were that simple I would agree. But it isn't. If common web browsers interpreted HTML and CSS rigidly, users wouldn't see any errors because web developers simply wouldn't upload broken files in the first place.
Last time I checked, tar just stops processing when it encounters a broken tarball. The GIMP can't open corrupted image files. GCC doesn't guess at what you mean when you make syntax errors in your C source code. Why is it such a crime to have a web browser that works dependably too?
Dean Edwards has published some Javascript that emulates lots of things that are broken in Internet Explorer, and he called it "IE7". That is not what this news is about, although it is excellent work.
That's IE Shines on Broken Code. It was garbage that had no correct rendering. You can't really say that "IE does a very good job at figuring out what someone actually intended with the broken code and rendering it well" when you're talking about randomly generated data intended to crash the browser.
Slashdot has broken HTML, but it's not the broken HTML that causes the problem in Firefox, it's a Firefox bug. It's in Bugzilla, along with a valid HTML testcase that exhibits the same problem. Why do people keep insisting that it's caused by Slashdot?
No it doesn't. It's just that if it's broken in Internet Explorer, virtually every web developer will go back and fix it immediately. Thus the broken code on the WWW is strongly biased to the type of error that Internet Explorer happens to handle adequately. The same cannot be said for any other web browser, simply because Internet Explorer has overwhelming market share.
Does a single car manufacturer control 90% of the car market? Are car owners the only market for radio manufacturers?
Your analogy simply doesn't hold up. Microsoft are in trouble because they can use their desktop OS monopoly to bludgeon the media player market into submission, just like they did with the web browser market. No car manufacturer has a monopoly on cars, and radio manufacturers can sell to people who don't own cars.
You're forgetting a step. They need to connect to the Internet before they start surfing. They need an account with an ISP. What usually comes with an ISP's signup package? That's right, a web browser.
This is why it was such a blow for Netscape to skip version 5. At that point, they were still bundled on most ISP's signup CDs. That is effectively the only way they could have fought back against Internet Explorer being bundled with Windows - users won't use Internet Explorer if they get Netscape set to be the default when they sign up with their ISP.
But Netscape remained practically undeveloped for years, with ISPs having to support buggy Netscape 4. They all switched to bundling the latest version of Internet Explorer on their signup CDs, and the browser war was lost.
There isn't any reason for users to need a web browser built into their operating system. They could just as easily get a web browser from their ISP.
Verdana is a better font, but not for the web. The problem is that it has a higher aspect value than most other fonts. This means that at a smaller size it still remains legible where other fonts may not. It also means that at a normal size, it appears to be quite a bit larger than other fonts.
The problem is that web designers can't specify any particular font and assume that the web browser will honour that request. There are lots of different reasons why a different font may be substituted for the originally requested one.
This means that if a web designer specifies Verdana for small text, another font could be used in its place, resulting in unreadable text. If a web designer specifies Verdana for normal text, people will think that it's ugly because it's too big. There really aren't that many situations where Verdana is an appropriate choice for web designers.
None of this is to say that it isn't a nice font; I personally use it throughout most of KDE. But it's not a good choice for the Web Core Fonts collection.
Opera has had first-hand experience with Microsoft breaking interoperability. At one point, Microsoft were deliberately serving broken CSS to Opera that would cause it to mess up the layout for that one particular browser.
Konqueror "cheats" in the "warm start" test. KDE automatically keeps an instance loaded after the first time you start Konqueror up. You can even configure it to preload an instance upon KDE startup (go to Control Panel | KDE Components | KDE Performance), although this isn't the default setting.
Konqueror's "cheats" in the "cold start" test as well - as you can see from the results, there are significant differences in startup time depending upon whether KDE or GNOME is used as the desktop (on account of the libraries already in memory, DCOP server, etc).
You're looking at the little details but missing the big picture.
I know that the Referer header is optional. I also know that virtually everybody transmits an accurate Referer header.
If you deep link and the person you are deep linking to filters based on the Referer header, sure, there will be a few people who have switched off their Referer header that will see what you intended them to see. But most people won't.
This is why it is an effective way of stopping people from deep linking. They don't want to deep link if only 1% of their visitors will see it. They don't want to deep link if it means they have to tell their visitors to reconfigure their browsers.
It simply doesn't matter that the Referer header is untrustworthy. You are using it to deter other web developers from misappropriating your bandwidth, not as a means to stop every last page load from working.
It is not freeform, as per RFC 2616, it is a relative or absolute URI.
You used a CGI because that's the only reliable way of doing it. It's also pretty nonsensical because it's a waste of bandwidth, which is exactly what deep linkers want to avoid.
I'm unaware of anything like that. Even if something like that existed, it certainly isn't reliable, which means the deterrent will still be effective.
If you are so certain that you can manipulate HTTP headers for requests for resources on different domains, by all means, post the code.
You've missed the point. Completely.
You could just as easily write a script that will save the images locally. This would work quicker and use half the bandwidth.
That yellow bar was inspired by the way ActiveX installation works in Internet Explorer running on Windows XP with service pack 2 applied.
Read the comment again. It's not a method to trick browsers into requesting the image with a particular Referer header. The method suggested uses double the bandwidth as simply hosting the image themselves - once when the CGI downloads from the original server, and once when the CGI serves the image to the visitor.
No, it's very strong protection. You seem to think that this is some sort of anti-copying measure. It's a way of protecting server resources. Nobody's going to bother deep linking when 99% of their visitors are going to get broken images. They'll just copy it to their own server instead.
Why on earth would somebody do that instead of simply copying the image to their server?
That's no problem; if you re-read my comment, you'll see that I suggested only blocking requests with a Referer header that started with http that didn't match your website. Blank Referer headers and Referer headers that say "blocked by [xxx]" will not trigger this.
The typical solution to this is serving a complaint image to requests with the Referer header set to something starting with 'http' that don't correspond to your website. Five minutes on Google would have told you this (and provided ready-made recipes for Apache).