Yes. I'm not sure why, I suspect a combination of some form of snobbery and the idea that a particular news segment can be thought of as covering the time period between the last article and the current one. When you publish news articles on a schedule, there's a reasonable expectation that you are covering a particular time period, but there's no similar expectation when you just read what people publish when they feel like it - you don't know whether they are covering what happened that day or just what happened to be on their mind that day.
that does not mean that any of their readers would choose "regularly scheduled news" over "the current news, whenever you want it, with searchable archives and the ability to comment on it and read the comments of others".
Oh now come on, that's just a silly argument. Just because you keep to a schedule it doesn't mean that you can't have feedback or searchable archives. You are creating a false dichotomy. Nielsen himself sent notification of this Alertbox out by newsletter, and yet we are discussing it just fine, and his searchable archives stretch back to 1995.
Yes, Firefox is truly becoming the 21st century EMACS. It's a decent OS, all it needs now is a good web browser;).
What really worries me is when the EMACS developers realise that they can replace their built-in web browser with Firefox and when the Firefox developers realise that they can replace their built-in text boxes with EMACS. The resulting bloat will collapse in on itself and the Earth will be sucked into the newly-formed black hole.
you click on a phone number in a web page and it calls it.
You still don't need to build the VOIP into the browser. Just a Greasemonkey script to convert plain-text telephone numbers into <a href="tel:..."> links and a handler to pass off tel: links to an external program just like mailto: links are handled.
Atom/RSS became popular long before browser support came about. I don't see why you are tying news feed ignorance to Internet Explorer's lack of support - any Internet Explorer user can sign up for a web-based aggregator today, without any special support. Users aren't hampered by Internet Explorer in this respect, it's their own ignorance, and probably at least partially because it doesn't do much for a lot of people. Not everyone's a geek.
Don't be so quick to write him off as clueless when you haven't actually read what he's saying. He's not talking about the speed at which information is published, he's talking about having it published on a regular schedule.
I don't really seen the point in publishing something at a set time or on a particular day, but some people think it's incredibly important. For these people, the fact that weblogs might publish it first isn't important, the fact that they are just publishing on the whim of the author as opposed to covering a particular period of time is important.
The W3C publishes their specs; Microsoft does not. If they did [emphasis mine], I'm sure the Mozilla folks would be more than happy to implement it. As it stands, they're forced to try and emulate some of IE's bugs and quirks in order to render poorly-written, IE-only pages correctly.
But as I pointed out earlier in the discussion, they generally haven't done this.
He said that if Microsoft published specifications for MS-HTML, MS-CSS, etc, Mozilla might do something about it. Microsoft leaves a lot of things undocumented, so pointing out that Mozilla hasn't been forthcoming with support for these things doesn't contradict what he said.
Historically, their attitude has been that they would support only the "official" (i.e., W3C and such) specs, and would not implement any concessions to IE compatibility.
This is not the case. Their main focus is obviously on standards, and if the standard way of doing something conflicts with the Microsoft way of doing something, they tend to pick the standard way. But Mozilla have implemented plenty of stuff in the name of compatibility with Internet Explorer. Off the top of my head, there's document.all, favicons, two quirks modes and XMLHttpRequest. I'm sure there's more.
For all the bitching some people have been doing in this discussion about MS not documenting anything, they've also been bitching about IE6 has been standing still for years. It's not like there's a moving target to emulate, and the main differences are well enough known that pro web developers use them on auto-pilot these days!
There's a difference between web developers being able to work around issues and browser developers being able to correctly emulate issues. Compare, for example Microsoft's documentation for hasLayout, and its reverse-engineered description. This one facet of rendering has huge implications on layout, yet it remained an undocumented mystery for five years and still hasn't been totally cracked. Or look at Hixie's description of the way Internet Explorer comes with a DOM tree that isn't actually a tree. Or look at Hyatt's description of the "residual style" problem.
Mozilla and other browser developers already spend plenty of time reverse-engineering Internet Explorer. Are you really criticising them for choosing to implement some standards stuff too rather than spending 100% of their time on reverse-engineering Internet Explorer's crazy behaviour?
Finally, some of our users resented the fact that news feeds are divorced from the context of the publisher's website. They preferred the serendipity that came from visiting a full-fledged website that offered additional content beyond the current headlines.
This makes no sense whatsoever. If you are reading a feed, the website is a click away. If you are reading an email newsletter, the website is a click away. In both cases you aren't reading the information on the website.
It only make sense once you substitute "some of our users" for "some publishers". Email newsletters don't really have a strong tradition of including the entire article in the notification email, but plenty of people complain if you only provide partial feeds as opposed to full-text feeds.
I've seen a lot of resentment from some publishers because they think that because the person is reading their article, that they should be able to dictate that they read it on the website. But I've never seen any users complain that Atom/RSS feeds aren't "serendipitous enough". That makes no sense.
He sneers at graphic design and pretty much anything beyond plaintext
Do you have a cite for anything even approaching this? I find Nielsen to be one of those people who is widely vilified for things he hasn't said and doesn't agree with. Having read plenty of Nielsen in the past, I strongly suspect you are completely misrepresenting him.
Nielsen says in this article that he prefers email newsletters to news feeds because "the email newsletter comes to you; it arrives in your in box, and becomes part of the one place you go to get information. That's the great strength." This is an interesting idea, but I don't think he realizes that it doesn't scale. Sure, a couple newsletters would work fine, but a few years back, I was subscribed to so many newsletters that I started filtering them into folders and essentially treating them just like feeds.
I was in exactly the same situation. My inbox stopped being about communicating with people and became a time-sink for keeping up to date with various things. So I went through a phase of unsubscribing from every mailing list, and once unsubscribed, I'd try and replace the information with an RSS feed. If I couldn't find one, I'd email them, tell them why I unsubscribed, and ask for a feed. Sometimes I was pleasantly surprised to find that they had one squirrelled away and not linked to on their site.
It sounds like I'm just shifting the burden elsewhere, or "hiding the mess", but it's amazing how much quicker things flow when you don't open your mail client in the morning to find dozens of things you need to sort through. And no, mail filters don't do the job for various reasons. As much as I hate to sound like a self-help book, it changes from your information controlling you to you controlling when and how you get that information.
I believe people interact with periodical articles in a fundamentally different way to normal email, and that email newsletters lead people into trying to handle both of them in the same way, resulting in chaos. Email newsletters might be the most effective way to reach your audience, as Nielsen says, but that doesn't mean that email newsletters are the most effective way for your audience to be notified of your articles. So leave your audience members who don't know any better reading your email newsletter, but make sure you give people the option of an Atom feed.
By coincidence, Nielsen's was one of the newsletters I unsubscribed from. He didn't provide a feed, and when I emailed him to ask if he had one, I was told that he'd get back to me because he was on holiday. He never did, so he has one less reader now.
I can accept that he believes that email newsletters are better than feeds, but I think it's uncharacteristic of him to not even allow the possibility of handling his Alertbox column in the way that fits into his readers' workflows best. It's not as if offering the option will harm usability for the people who don't want or understand Atom feeds.
It's an amalgamated mess of about half of CSS 2.1, some proprietary stuff, and a sprinkling of JavaScript expressions. It doesn't have a name, but Microsoft tend to refer to it as "CSS", despite being clearly different to CSS. cf. Embrace, extend & extinguish.
Unfortunately many of us work for employers that aren't interested in W3C purity. They want the page to work in IE and they don't want to pay for it to be thoroughly tested (or even tested to work at all!) in other browsers. Thus the evil empire wins.
Why? None of that means that you can't write valid code. Just because your code is valid, it doesn't mean it won't work in Internet Explorer or that you are obliged to test it in other browsers.
Validity just means that the documents you write are syntactically and structurally correct. While that has positive implications for cross-browser support, that doesn't mean validity and cross-browser support are the same thing.
That's a bit of an odd thing to say. Microsoft essentially pulled the rug out from under the Mac Internet Explorer developers. What would have been the rendering engine for v6.0 was instead used for Mac MSN, and it turned out to be a great engine with great standards support. Killing Mac Internet Explorer just meant that the people who stayed with Mac Internet Explorer stayed with the old and buggy version you despise instead of having up to date support for the standards.
Apparently they think they have a better way of doing CSS than the people who set the CSS standards.
Try again. Microsoft had employees on the CSS working group at the W3C, while at the same time they were busy coding the proprietary stuff instead. All the finished CSS specifications, right from the first one published in 1996, have an acknowledgements section listing, among others, Microsoft employees.
The fact is, if they thought they had a better way of doing things, they could easily have brought it up when CSS was being designed, because they are some of the people who made CSS in the first place.
There's plenty of CSS hacks that you can use to give rules to Internet Explorer without making your stylesheet invalid, and the Microsoft-approved way of doing it is to use conditional comments, which also solves the proprietary property problem.
Don't be so quick to discount the intrinsic problems invalid code causes. It's very easy to spot a single genuine mistake if it's the only error you get, but if it's hidden amongst dozens of "harmless" errors, it becomes much more difficult to spot. It also makes it much more difficult to run a validator over a number of websites periodically, because it means you have to pick through hundreds of errors to see if any of them matter instead of simply being notified when something becomes invalid. Invalid code can be a disadvantage even if browsers don't choke on it.
Just because it makes sense for Microsoft to include the ability to visit a website, it doesn't mean that they should make their browser a full-featured application.
You'd be just as able to download Firefox, Opera, Internet Explorer, etc if Windows just had an HTML user-agent with no CSS, no JavaScript, no favourites, no Atom/RSS support, no anti-phishing, no ActiveX, no nothing.
There's simply no need to include a full web browser application in Windows. A rudimentary downloading utility that can handle HTML is all that is necessary. If Microsoft had have done this, they would have been competing fairly and they wouldn't have been using their monopoly illegally against Netscape.
PS: Windows has shipped with an FTP client since Windows 95. Look for ftp.exe. That's in addition to the FTP support that is built into Internet Explorer.
There's virtually nothing that requires you to make sites invalid for them to work in Internet Explorer. Just because Internet Explorer doesn't support all of the specifications, it doesn't mean you can't use the subset that is implemented.
What are you doing that needs invalid code to work in Internet Explorer? I hear a lot of people claim this on places like Slashdot, but it's very rare I hear an actual web developer say it, and it's certainly not true in my experience.
Are IE "standards" not widely used because they are closed and opaque to developers, thereby locking any developer into using their tools? Does IE follow any standard?
There's five main factors at play here.
Internet Explorer includes interfaces that Microsoft just went ahead and implemented without any form of community input. These are usually documented on MSDN, so there's at least a chance of implementing them in other browsers if absolutely necessary. On the other hand, sometimes the MSDN documentation is lacking, so people have to reverse engineer some things.
Sometimes, it's not even a good idea to implement these things. The "Samy" worm was essentially caused by Internet Explorer's non-standard ability to sneak JavaScript into a page. The concept of "liberal in what you accept" has security implications on the WWW because you can't expect all the software you are interoperating with to know what kinds of liberties you are taking and compensate for them.
Internet Explorer doesn't have a document that completely specifies how their rendering engine is supposed to work. A mysterious property called "hasLayout" went undocumented for years, and a lot of the CSS bugs are tied into it. The way in which they construct a DOM tree-that-isn't-really-a-tree from mangled markup is frankly bizarre.
While Microsoft were busy implementing all this stuff without any community consensus and releasing it on the world as a fait accompli, they were simultaneously on the W3C working groups that were publishing the specifications that did have community consensus. So Microsoft deliberately chose not to do things the same way as everybody else.
Because they do things differently to everybody else, and because Internet Explorer has such overwhelming market share, everybody else has to go at least part of the way towards emulating Internet Explorer's proprietary behaviours. And because a lot of them are undocumented and poorly documented, it leaves other browsers playing catch-up in terms of support for all the broken websites out there.
You have to consider the long-term drawbacks of this. The more that browsers copy Internet Explorer proprietary behaviours, the more control they give to Microsoft. If browser developers spend their time inefficiently reverse-engineering Internet Explorer and marginalising the open specifications, everybody else will forever be playing catch-up to Microsoft, locked in a wait-for-next-version-of-Internet-Explorer -> copy -> wait-for-next-version -> copy cycle. It leaves everybody except Microsoft in the position of having second-class support for the MSWWW.
This is essentially the position OpenOffice is in with Office documents, except instead of your own documents being poorly readable by competing software, everybody else's documents are poorly readable by competing software.
HTML tables are a declaration that various pieces of information are related across multiple axes. CSS tables are a suggestion that various parts of the page should be laid out in a grid-like manner.
One is a method of describing semantics, one is a presentation scheme. You are right in believing that HTML tables are inappropriate for the display of non-tabular data, but the criticisms you list don't apply to CSS tables because they are a totally different thing. The word "table" is being used in two different senses here.
Try not to get hung up on the "tables are evil for layout" mantra. It doesn't apply to CSS tables, it never has, it was purely a criticism of HTML tables. Follow the link I provided, I'm not talking about HTML tables.
Do you worry that CSS is scaring off new Web writers
Why would it scare off new web writers? I can see a case for it scaring off newbie designers but CSS actually makes it easier to write for the web, because you don't have to worry about the design so much when you are writing. In fact, surely the immense popularity of weblogs is evidence that writing for the web is more popular than ever before? It certainly doesn't look like anybody is being scared off.
That page is a long-standing joke. Surely the way it's written tipped you off? It reads like an angry thirteen year-old was let on the computer without supervision. Try googling the web or Usenet for some of the rebuttals.
Is the difficulty of producing a layout that consists of three or more columns of equal height justification for adding some new feature to the specification to make this easier?
They added that feature to CSS over eight years ago. Nobody uses it because Internet Explorer hasn't caught up to 1998 yet. No, not even Internet Explorer 7.0 will handle display: table-cell. Maybe Internet Explorer 8.0 if we are lucky.
What would you like them to do - add a duplicate feature and hope Microsoft implements it this time?
Multiple backgrounds are coming in CSS3. Safari (and another browser I think) went ahead and implemented it ahead of time.
Yes, all KHTML-based browsers now support CSS 3 backgrounds.
And you'd actually be surprised at how well-supported CSS is across browsers (even IE6). Some people just make the mistake (among several others) of not declaring a specific doctype
Well no, CSS isn't well supported. You're making the mistake of forgetting about the entire sections of CSS that Internet Explorer doesn't implement, and which everybody tends to ignore for that reason. There's at least four large sections of the CSS 2 specification that simply don't exist for most developers because they aren't implemented in the browsers most people are using.
Yes, it's true, strict mode can solve a few problems with rendering, but that's insignificant compared to the amount of stuff that just isn't implemented in Internet Explorer.
As the number of browsers increases, my development time remains static. The lower boundary is defined by Internet Explorer and other browsers don't raise it significantly.
In my experience, the people who complain about the number of different browsers are the people who design for Internet Explorer first and fix things for browsers that attempt to follow the W3C specifications. The people who design for compliant browsers first and then fix things for Internet Explorer don't tend to worry about the number of different browsers, because they all tend to work pretty much alike, apart from Internet Explorer.
The problem is that there's no real, new, revolutionary development in browsers.
How would you characterise Opera's improvements as an aural user-agent, the way it works on handhelds, the lowering of the barrier to entry for extensions with user JavaScript, or its JavaScript compatibility patches for popular websites? As far as I'm aware, these problems haven't been tackled very successfully before (if at all), and Opera's work in their last few versions has made significant inroads.
Slashdot Mirror
Yes. I'm not sure why, I suspect a combination of some form of snobbery and the idea that a particular news segment can be thought of as covering the time period between the last article and the current one. When you publish news articles on a schedule, there's a reasonable expectation that you are covering a particular time period, but there's no similar expectation when you just read what people publish when they feel like it - you don't know whether they are covering what happened that day or just what happened to be on their mind that day.
Oh now come on, that's just a silly argument. Just because you keep to a schedule it doesn't mean that you can't have feedback or searchable archives. You are creating a false dichotomy. Nielsen himself sent notification of this Alertbox out by newsletter, and yet we are discussing it just fine, and his searchable archives stretch back to 1995.
Yes, Firefox is truly becoming the 21st century EMACS. It's a decent OS, all it needs now is a good web browser ;).
What really worries me is when the EMACS developers realise that they can replace their built-in web browser with Firefox and when the Firefox developers realise that they can replace their built-in text boxes with EMACS. The resulting bloat will collapse in on itself and the Earth will be sucked into the newly-formed black hole.
You laugh, but Opera for mobile phones already implements RFC 3966, which means you can click on a link in a web page to call somebody.
You still don't need to build the VOIP into the browser. Just a Greasemonkey script to convert plain-text telephone numbers into <a href="tel:..."> links and a handler to pass off tel: links to an external program just like mailto: links are handled.
Atom/RSS became popular long before browser support came about. I don't see why you are tying news feed ignorance to Internet Explorer's lack of support - any Internet Explorer user can sign up for a web-based aggregator today, without any special support. Users aren't hampered by Internet Explorer in this respect, it's their own ignorance, and probably at least partially because it doesn't do much for a lot of people. Not everyone's a geek.
Don't be so quick to write him off as clueless when you haven't actually read what he's saying. He's not talking about the speed at which information is published, he's talking about having it published on a regular schedule.
I don't really seen the point in publishing something at a set time or on a particular day, but some people think it's incredibly important. For these people, the fact that weblogs might publish it first isn't important, the fact that they are just publishing on the whim of the author as opposed to covering a particular period of time is important.
He said that if Microsoft published specifications for MS-HTML, MS-CSS, etc, Mozilla might do something about it. Microsoft leaves a lot of things undocumented, so pointing out that Mozilla hasn't been forthcoming with support for these things doesn't contradict what he said.
This is not the case. Their main focus is obviously on standards, and if the standard way of doing something conflicts with the Microsoft way of doing something, they tend to pick the standard way. But Mozilla have implemented plenty of stuff in the name of compatibility with Internet Explorer. Off the top of my head, there's document.all, favicons, two quirks modes and XMLHttpRequest. I'm sure there's more.
There's a difference between web developers being able to work around issues and browser developers being able to correctly emulate issues. Compare, for example Microsoft's documentation for hasLayout, and its reverse-engineered description. This one facet of rendering has huge implications on layout, yet it remained an undocumented mystery for five years and still hasn't been totally cracked. Or look at Hixie's description of the way Internet Explorer comes with a DOM tree that isn't actually a tree. Or look at Hyatt's description of the "residual style" problem.
Mozilla and other browser developers already spend plenty of time reverse-engineering Internet Explorer. Are you really criticising them for choosing to implement some standards stuff too rather than spending 100% of their time on reverse-engineering Internet Explorer's crazy behaviour?
He's gone into more detail in his latest Alertbox column. One thing that caught my eye:
This makes no sense whatsoever. If you are reading a feed, the website is a click away. If you are reading an email newsletter, the website is a click away. In both cases you aren't reading the information on the website.
It only make sense once you substitute "some of our users" for "some publishers". Email newsletters don't really have a strong tradition of including the entire article in the notification email, but plenty of people complain if you only provide partial feeds as opposed to full-text feeds.
I've seen a lot of resentment from some publishers because they think that because the person is reading their article, that they should be able to dictate that they read it on the website. But I've never seen any users complain that Atom/RSS feeds aren't "serendipitous enough". That makes no sense.
Do you have a cite for anything even approaching this? I find Nielsen to be one of those people who is widely vilified for things he hasn't said and doesn't agree with. Having read plenty of Nielsen in the past, I strongly suspect you are completely misrepresenting him.
I was in exactly the same situation. My inbox stopped being about communicating with people and became a time-sink for keeping up to date with various things. So I went through a phase of unsubscribing from every mailing list, and once unsubscribed, I'd try and replace the information with an RSS feed. If I couldn't find one, I'd email them, tell them why I unsubscribed, and ask for a feed. Sometimes I was pleasantly surprised to find that they had one squirrelled away and not linked to on their site.
It sounds like I'm just shifting the burden elsewhere, or "hiding the mess", but it's amazing how much quicker things flow when you don't open your mail client in the morning to find dozens of things you need to sort through. And no, mail filters don't do the job for various reasons. As much as I hate to sound like a self-help book, it changes from your information controlling you to you controlling when and how you get that information.
I believe people interact with periodical articles in a fundamentally different way to normal email, and that email newsletters lead people into trying to handle both of them in the same way, resulting in chaos. Email newsletters might be the most effective way to reach your audience, as Nielsen says, but that doesn't mean that email newsletters are the most effective way for your audience to be notified of your articles. So leave your audience members who don't know any better reading your email newsletter, but make sure you give people the option of an Atom feed.
By coincidence, Nielsen's was one of the newsletters I unsubscribed from. He didn't provide a feed, and when I emailed him to ask if he had one, I was told that he'd get back to me because he was on holiday. He never did, so he has one less reader now.
I can accept that he believes that email newsletters are better than feeds, but I think it's uncharacteristic of him to not even allow the possibility of handling his Alertbox column in the way that fits into his readers' workflows best. It's not as if offering the option will harm usability for the people who don't want or understand Atom feeds.
It's an amalgamated mess of about half of CSS 2.1, some proprietary stuff, and a sprinkling of JavaScript expressions. It doesn't have a name, but Microsoft tend to refer to it as "CSS", despite being clearly different to CSS. cf. Embrace, extend & extinguish.
Why? None of that means that you can't write valid code. Just because your code is valid, it doesn't mean it won't work in Internet Explorer or that you are obliged to test it in other browsers.
Validity just means that the documents you write are syntactically and structurally correct. While that has positive implications for cross-browser support, that doesn't mean validity and cross-browser support are the same thing.
That's a bit of an odd thing to say. Microsoft essentially pulled the rug out from under the Mac Internet Explorer developers. What would have been the rendering engine for v6.0 was instead used for Mac MSN, and it turned out to be a great engine with great standards support. Killing Mac Internet Explorer just meant that the people who stayed with Mac Internet Explorer stayed with the old and buggy version you despise instead of having up to date support for the standards.
Try again. Microsoft had employees on the CSS working group at the W3C, while at the same time they were busy coding the proprietary stuff instead. All the finished CSS specifications, right from the first one published in 1996, have an acknowledgements section listing, among others, Microsoft employees.
The fact is, if they thought they had a better way of doing things, they could easily have brought it up when CSS was being designed, because they are some of the people who made CSS in the first place.
There's plenty of CSS hacks that you can use to give rules to Internet Explorer without making your stylesheet invalid, and the Microsoft-approved way of doing it is to use conditional comments, which also solves the proprietary property problem.
Don't be so quick to discount the intrinsic problems invalid code causes. It's very easy to spot a single genuine mistake if it's the only error you get, but if it's hidden amongst dozens of "harmless" errors, it becomes much more difficult to spot. It also makes it much more difficult to run a validator over a number of websites periodically, because it means you have to pick through hundreds of errors to see if any of them matter instead of simply being notified when something becomes invalid. Invalid code can be a disadvantage even if browsers don't choke on it.
Just because it makes sense for Microsoft to include the ability to visit a website, it doesn't mean that they should make their browser a full-featured application.
You'd be just as able to download Firefox, Opera, Internet Explorer, etc if Windows just had an HTML user-agent with no CSS, no JavaScript, no favourites, no Atom/RSS support, no anti-phishing, no ActiveX, no nothing.
There's simply no need to include a full web browser application in Windows. A rudimentary downloading utility that can handle HTML is all that is necessary. If Microsoft had have done this, they would have been competing fairly and they wouldn't have been using their monopoly illegally against Netscape.
PS: Windows has shipped with an FTP client since Windows 95. Look for ftp.exe. That's in addition to the FTP support that is built into Internet Explorer.
There's virtually nothing that requires you to make sites invalid for them to work in Internet Explorer. Just because Internet Explorer doesn't support all of the specifications, it doesn't mean you can't use the subset that is implemented.
What are you doing that needs invalid code to work in Internet Explorer? I hear a lot of people claim this on places like Slashdot, but it's very rare I hear an actual web developer say it, and it's certainly not true in my experience.
There's five main factors at play here.
You have to consider the long-term drawbacks of this. The more that browsers copy Internet Explorer proprietary behaviours, the more control they give to Microsoft. If browser developers spend their time inefficiently reverse-engineering Internet Explorer and marginalising the open specifications, everybody else will forever be playing catch-up to Microsoft, locked in a wait-for-next-version-of-Internet-Explorer -> copy -> wait-for-next-version -> copy cycle. It leaves everybody except Microsoft in the position of having second-class support for the MSWWW.
This is essentially the position OpenOffice is in with Office documents, except instead of your own documents being poorly readable by competing software, everybody else's documents are poorly readable by competing software.
You've mixed up HTML tables and CSS tables.
HTML tables are a declaration that various pieces of information are related across multiple axes. CSS tables are a suggestion that various parts of the page should be laid out in a grid-like manner.
One is a method of describing semantics, one is a presentation scheme. You are right in believing that HTML tables are inappropriate for the display of non-tabular data, but the criticisms you list don't apply to CSS tables because they are a totally different thing. The word "table" is being used in two different senses here.
Try not to get hung up on the "tables are evil for layout" mantra. It doesn't apply to CSS tables, it never has, it was purely a criticism of HTML tables. Follow the link I provided, I'm not talking about HTML tables.
Why would it scare off new web writers? I can see a case for it scaring off newbie designers but CSS actually makes it easier to write for the web, because you don't have to worry about the design so much when you are writing. In fact, surely the immense popularity of weblogs is evidence that writing for the web is more popular than ever before? It certainly doesn't look like anybody is being scared off.
That page is a long-standing joke. Surely the way it's written tipped you off? It reads like an angry thirteen year-old was let on the computer without supervision. Try googling the web or Usenet for some of the rebuttals.
They added that feature to CSS over eight years ago. Nobody uses it because Internet Explorer hasn't caught up to 1998 yet. No, not even Internet Explorer 7.0 will handle display: table-cell. Maybe Internet Explorer 8.0 if we are lucky.
What would you like them to do - add a duplicate feature and hope Microsoft implements it this time?
Yes, all KHTML-based browsers now support CSS 3 backgrounds.
Well no, CSS isn't well supported. You're making the mistake of forgetting about the entire sections of CSS that Internet Explorer doesn't implement, and which everybody tends to ignore for that reason. There's at least four large sections of the CSS 2 specification that simply don't exist for most developers because they aren't implemented in the browsers most people are using.
Yes, it's true, strict mode can solve a few problems with rendering, but that's insignificant compared to the amount of stuff that just isn't implemented in Internet Explorer.
As the number of browsers increases, my development time remains static. The lower boundary is defined by Internet Explorer and other browsers don't raise it significantly.
In my experience, the people who complain about the number of different browsers are the people who design for Internet Explorer first and fix things for browsers that attempt to follow the W3C specifications. The people who design for compliant browsers first and then fix things for Internet Explorer don't tend to worry about the number of different browsers, because they all tend to work pretty much alike, apart from Internet Explorer.
How would you characterise Opera's improvements as an aural user-agent, the way it works on handhelds, the lowering of the barrier to entry for extensions with user JavaScript, or its JavaScript compatibility patches for popular websites? As far as I'm aware, these problems haven't been tackled very successfully before (if at all), and Opera's work in their last few versions has made significant inroads.