An application (IE) that hasn't been updated for a long time, and which is present on 95% of all computers, is bound to contain more security problems than one with an active developer community (Firefox).
I disagree. Whenever you make changes to something, you run the risk of introducing a security hole. Security holes don't simply develop of their own accord in old code.
If the only development Microsoft is doing on Internet Explorer is patching security holes, then it is getting more and more secure. If Firefox developers are adding feature after feature, security holes are bound to be introduced at some point.
Stable, mature code is generally more secure than code that is under active development. That is one of the very few things that Internet Explorer has on its side.
I've read Nielsen's book about usability & web design and I can assure you that it's only a common sense compilation.
I own it too, and I agree. However, I still think that it's a worthwhile read.
The trouble is, when people learn how to design websites, they inevitably copy everyone else. Including everyone else's mistakes. Not only that, but they make a few of their own.
The ones that go on to be professionals inevitably get caught up in doing the actual work and don't think about how to improve their practices enough. So the mistakes get ingrained and replicated across hundreds of designs.
Nielsen's book is good because he has a knack for showing people their designs from a user's perspective. It challenges those ingrained bad habits and gives you ideas on how to approach the field from a better angle.
If you read the book expecting some revolutionary new techniques for web design, then you will be disappointed. But if you read the book expecting a refreshing new perspective and a starting point for improving your work, then it's a damn good read.
Saving each one to html, then removing the clutter (headers for the rest of his site, etc) was a pain.
You can hide stuff when it is printed out using print stylesheets. No need to resort to PDFs. Just use the media="print" attribute when linking to a stylesheet, and it will be applied when documents are printed out.
not quite everything nielsen says is right in every situation but everything the w3c suggests is a suggest worth the weight of my toshiba laptop (a hefty 7 pounds) in gold.
Nobody is right all the time, not Mr Neilsen, not the W3C, not anybody. For instance, one of the "perfect" suggestions from the W3C that you refer us to:
If using several choices in a font-family property (in order to let the system choose the best available font out of a list), you can use the font-size-adjust property to force a specific aspect value.
Firstly, you cannot force anything with CSS. CSS provides suggestions, nothing more. But more importantly, no browser has ever implemented font-size-adjust! The W3C have even taken it out of CSS 2.1 because no browser vendor bothered with it. That statement will never be correct.
Safari implements quite a few things which Mozilla doesn't (for example, text-shadow)
As it became apparent that CSS 2 was never going to be fully implemented, the W3C decided to specify a subset of CSS that would more closely represent browser behaviour (in a similar way to HTML 3.2). This will soon be CSS 2.1.
Amongst other things, the text-shadow property has been removed from CSS because not enough browsers implemented it. So, whilst text-shadow is part of CSS 2, it is not part of CSS 2.1.
I don't know of anything which Mozilla implements which Safari doesn't.
Its box model is so completely borked (width includes padding & content, which is in explicit violation of the spec)
Internet Explorer 6 only gets the box model wrong if you kick it into "quirks mode".
I've often found that sites I develop primarily using Safari tend to translate to Gecko painlessly, yet require much more tweaking to get right in IE.
Ditto, except I use Gecko as my reference rendering, and that usually translates almost seamlessly to KHTML and Opera, with large amounts of messing about to get a decent rendering in Internet Explorer.
Moz/Firefox, Opera, and IE 6 are all far more CSS compliant than Safari.
You are completely and utterly wrong in claiming that any version of Internet Explorer has better CSS support than Safari.
Internet Explorer doesn't support CSS tables, a whole section of the CSS 2 specification - Safari does.
Internet Explorer doesn't support half the selectors described in the CSS specification - Safari supports all of them.
Internet Explorer doesn't support generated content - Safari does.
Internet Explorer doesn't support the:hover pseudo-class on anything but <a> elements - Safari implements it properly.
That's not even counting the bizarre bugs that cause entire sections of the page to disappear in Internet Explorer, and then reappear when you switch to another window and back again. Google for the "guillotine" or "peekaboo" CSS bugs, for example.
why on earth is Apple using a standard which isn't finalized yet. CSS3 is nowhere close to being done.
That's wrong too. "CSS 3" is a group of specifications. Over half a dozen are at "Candidate Recommendation" stage, which means that the W3C recommend that they be implemented. A few more are at "last call" stage, which is the stage before Candidate Recommendation, and only major showstoppers can make major changes to the specifications at that stage. In other words, large parts of CSS 3 are stable and ready to be implemented. It's not just Apple that are doing this, Mozilla are as well.
I can't address your DHTML complaint as you were far too vague. Can you come up with specific examples?
It appears that Acacia just had to get enough companies (Disney and Virgin Radio, among others) to pay licensing fees before they could afford a legal adventure against the big guys.
Since when are Disney and Virgin not considered big companies?
As I'm a web developer, I'm more concerned with the changes to Internet Explorer. Previous versions ignored a mandatory part of the HTTP specification (RFC 2616). Basically, it ignored the Content-Type header in various situations.
This update changes the HTTP handling to follow the specification. Ever been to a website with Mozilla, Opera or Konqueror and it shows you the source code? That's because the web developers only tested in Internet Explorer, which isn't affected by certain misconfigurations due to it not following the RFC rules properly.
Once this change goes through, these types of errors will show up in Internet Explorer as well. Which means Internet Explorer is less compatible with previous versions of itself, but more compatible with everything else. That's a step forward in my opinion.
PS: It's also a reason to make sure your website works in browsers that follow the specifications, not just Internet Explorer, even if you only intend Internet Explorer users to be able to visit your website.
It's sensitive to mouse-over... it displays the type of search in the status bar to remind you if the icon is not informative.
That's what the title attribute is for - to provide supplementary information. In most browsers, you can hover the mouse over an element and its title attribute will pop up in a tooltip.
In general, it's much better to rely on browsers' abilities to make use of information provided by your HTML than to try and code a replacement in Javascript. Three reasons stand out in this particular instance:
It works when Javascript is not available
It works when people switch off window.status changes in Javascript
It matches the usual user interface of hovering over something and a little help appearing, e.g. as used in toolbars (big difference in usability)
And if you roll over the form, the "Google" search area steals the input focus so you can just start typing
You have to move your hand away from the keyboard? Use the accesskey attribute to assign a shortcut to that form field.
Hitting enter launches a input-box specific function that crafts an appropriate GET request using the text in the box, and "submits" it using the enclosing form.
What's wrong with just using a normal form? They normally work this way.
The RSS 2.0 specification is frozen and no new development is allowed under the RSS name. The specification states that any new development must happen in namespaces or in new specifications with new names. Funnily enough, when people actually do that (with Atom, and with "funky" feeds), they are still criticised for it by the people who wrote that part of the spec.
the only way I can think of to do a image roll over with css would be using the background property, and I dont think that can be applied to a non-block tag.
Even if it didn't, there's no restriction in CSS about whether properties can be applied to block or inline "tags" (you mean "element types", not "tags") - you are almost certainly thinking of whether the element is block or inline display - and you can change an element's display type with the CSS display property. So if you want block display links, you could use:
Just because a page uses Javascript, it doesn't mean that it depends upon Javascript to be rendered correctly. You mention Slashdot uses Javascript, but if you switch Javascript off, you will find that it renders just fine. This is the way Javascript is supposed to be applied. Perhaps you should learn a little more about it before calling somebody else lame.
If fancy features such as Javascript, cookies, session ID's, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site.
To accomodate non-javascript visitors, you have the javascript set an extra parameter or something so the server side knows the server-side form validation shouldn't be required, and can skip.
What? An attacker could just send the exact same parameter to bypass your validation then!
The usual way for somebody to implement a secure validation is to always validate on the server, and include a Javascript onsubmit handler for the <form> element. This handler returns true if it finds that the data is valid (thus allowing form submission), and false otherwise (preventing form submission).
Right... so it's time to turn to Struts and JSPs for validation every form on our site.
You mean you don't already? You allow clients to submit whatever data they want and you don't bother checking it? That's not healthy.
Server-side validation is even easier than client-side validation as long as you've got more than five minutes experience with a server-side scripting language.
Why don't the "responsible" PC magazines who complain about all these security issues push Firefox?
Because the second you go from reporting security holes to advocating one product over another, you are vulnerable to being labelled biased.
If the article is a review of what browsers are available, then sure, you have the freedom of putting your opinion across. But that doesn't mean that you have the leeway to push one product over another every time the topic comes up.
Web site design today needs to eliminate JavaScript, as more people turn it off.
You're wrong. Javascript doesn't need to be avoided, it needs to be used sensibly. When it's used in the right way, it can improve the usability of a website.
Just because a website uses Javascript, it doesn't mean that it locks out those who have switched it off. The key is to educate the clueless Javascript abusers that do things like <a href="javascript:... or <a href="#" onclick... so that they don't lock people out.
Slashdot Mirror
I disagree. Whenever you make changes to something, you run the risk of introducing a security hole. Security holes don't simply develop of their own accord in old code.
If the only development Microsoft is doing on Internet Explorer is patching security holes, then it is getting more and more secure. If Firefox developers are adding feature after feature, security holes are bound to be introduced at some point.
Stable, mature code is generally more secure than code that is under active development. That is one of the very few things that Internet Explorer has on its side.
I own it too, and I agree. However, I still think that it's a worthwhile read.
The trouble is, when people learn how to design websites, they inevitably copy everyone else. Including everyone else's mistakes. Not only that, but they make a few of their own.
The ones that go on to be professionals inevitably get caught up in doing the actual work and don't think about how to improve their practices enough. So the mistakes get ingrained and replicated across hundreds of designs.
Nielsen's book is good because he has a knack for showing people their designs from a user's perspective. It challenges those ingrained bad habits and gives you ideas on how to approach the field from a better angle.
If you read the book expecting some revolutionary new techniques for web design, then you will be disappointed. But if you read the book expecting a refreshing new perspective and a starting point for improving your work, then it's a damn good read.
You can hide stuff when it is printed out using print stylesheets. No need to resort to PDFs. Just use the media="print" attribute when linking to a stylesheet, and it will be applied when documents are printed out.
Nobody is right all the time, not Mr Neilsen, not the W3C, not anybody. For instance, one of the "perfect" suggestions from the W3C that you refer us to:
Firstly, you cannot force anything with CSS. CSS provides suggestions, nothing more. But more importantly, no browser has ever implemented font-size-adjust! The W3C have even taken it out of CSS 2.1 because no browser vendor bothered with it. That statement will never be correct.
Ah, ignore me. I read "Konfabulator" as "Dashboard". It's still surprising that Konfabulator doesn't use WebCore for its Javascript support though.
That's very surprising, considering Safari and WebCore use the Javascript engine from the KDE project. Do you have a reference for the Mozilla link?
As it became apparent that CSS 2 was never going to be fully implemented, the W3C decided to specify a subset of CSS that would more closely represent browser behaviour (in a similar way to HTML 3.2). This will soon be CSS 2.1.
Amongst other things, the text-shadow property has been removed from CSS because not enough browsers implemented it. So, whilst text-shadow is part of CSS 2, it is not part of CSS 2.1.
Off the top of my head, table border collapsing.
Internet Explorer 6 only gets the box model wrong if you kick it into "quirks mode".
Ditto, except I use Gecko as my reference rendering, and that usually translates almost seamlessly to KHTML and Opera, with large amounts of messing about to get a decent rendering in Internet Explorer.
You are completely and utterly wrong in claiming that any version of Internet Explorer has better CSS support than Safari.
That's not even counting the bizarre bugs that cause entire sections of the page to disappear in Internet Explorer, and then reappear when you switch to another window and back again. Google for the "guillotine" or "peekaboo" CSS bugs, for example.
That's wrong too. "CSS 3" is a group of specifications. Over half a dozen are at "Candidate Recommendation" stage, which means that the W3C recommend that they be implemented. A few more are at "last call" stage, which is the stage before Candidate Recommendation, and only major showstoppers can make major changes to the specifications at that stage. In other words, large parts of CSS 3 are stable and ready to be implemented. It's not just Apple that are doing this, Mozilla are as well.
I can't address your DHTML complaint as you were far too vague. Can you come up with specific examples?
Since when are Disney and Virgin not considered big companies?
DARPA is the primary sponsor of ReiserFS 4. There's this other little thing called "the Internet" as well...
As I'm a web developer, I'm more concerned with the changes to Internet Explorer. Previous versions ignored a mandatory part of the HTTP specification (RFC 2616). Basically, it ignored the Content-Type header in various situations.
This update changes the HTTP handling to follow the specification. Ever been to a website with Mozilla, Opera or Konqueror and it shows you the source code? That's because the web developers only tested in Internet Explorer, which isn't affected by certain misconfigurations due to it not following the RFC rules properly.
Once this change goes through, these types of errors will show up in Internet Explorer as well. Which means Internet Explorer is less compatible with previous versions of itself, but more compatible with everything else. That's a step forward in my opinion.
PS: It's also a reason to make sure your website works in browsers that follow the specifications, not just Internet Explorer, even if you only intend Internet Explorer users to be able to visit your website.
It's quite simple to tell how many people view your webpage
Please enlighten us.
Ditto. I invited somebody this morning and they accepted without any problem.
That's what the title attribute is for - to provide supplementary information. In most browsers, you can hover the mouse over an element and its title attribute will pop up in a tooltip.
In general, it's much better to rely on browsers' abilities to make use of information provided by your HTML than to try and code a replacement in Javascript. Three reasons stand out in this particular instance:
You have to move your hand away from the keyboard? Use the accesskey attribute to assign a shortcut to that form field.
What's wrong with just using a normal form? They normally work this way.
The RSS 2.0 specification is frozen and no new development is allowed under the RSS name. The specification states that any new development must happen in namespaces or in new specifications with new names. Funnily enough, when people actually do that (with Atom, and with "funky" feeds), they are still criticised for it by the people who wrote that part of the spec.
The background property applies to all elements.
Even if it didn't, there's no restriction in CSS about whether properties can be applied to block or inline "tags" (you mean "element types", not "tags") - you are almost certainly thinking of whether the element is block or inline display - and you can change an element's display type with the CSS display property. So if you want block display links, you could use:
Just because a page uses Javascript, it doesn't mean that it depends upon Javascript to be rendered correctly. You mention Slashdot uses Javascript, but if you switch Javascript off, you will find that it renders just fine. This is the way Javascript is supposed to be applied. Perhaps you should learn a little more about it before calling somebody else lame.
I have.
Directly from Google Information for Webmasters:
What? An attacker could just send the exact same parameter to bypass your validation then!
The usual way for somebody to implement a secure validation is to always validate on the server, and include a Javascript onsubmit handler for the <form> element. This handler returns true if it finds that the data is valid (thus allowing form submission), and false otherwise (preventing form submission).
You can do rollovers in CSS using a number of different techniques (you just style a:hover).
You mean you don't already? You allow clients to submit whatever data they want and you don't bother checking it? That's not healthy.
Server-side validation is even easier than client-side validation as long as you've got more than five minutes experience with a server-side scripting language.
Because the second you go from reporting security holes to advocating one product over another, you are vulnerable to being labelled biased.
If the article is a review of what browsers are available, then sure, you have the freedom of putting your opinion across. But that doesn't mean that you have the leeway to push one product over another every time the topic comes up.
You're wrong. Javascript doesn't need to be avoided, it needs to be used sensibly. When it's used in the right way, it can improve the usability of a website.
Just because a website uses Javascript, it doesn't mean that it locks out those who have switched it off. The key is to educate the clueless Javascript abusers that do things like <a href="javascript:... or <a href="#" onclick... so that they don't lock people out.