Except "Please switch to browser X version Y", "Install plugin from vendor Z", "Enable anoying feature U", "Disable extension V", and so on. And if you replace flaky browsers with custom software or applets, you're back at square one.
1) Software provider has an 'incentive' to ensure the product is bug free or that the bugs get fixed quickly.
I'd say there's even stronger incentive not to fix any bugs. Service must have 100% uptime and any change, any fix, any upgrade is a risk it will all go down, corrupt databases, etc. Downtime and rollbacks may potentially harm customers more than a few bugs.
AOL makes it difficult to distinguish between their US and non-US network blocks. Workarounds for AOL's lameness aren't free: http://www.maxmind.com/app/geoip_country
How about using existing resources better instead? Why a website having a million visitors should send copy of the same thing million times across the globe?
Problem, for the most part, could be solved by developing a new delivery mechanism that's not endpoint-oriented, but resource-oriented (you don't care where you get your data from as long as you can be sure you're getting latest, unaltered copy of data you asked for).
Opera protects against it by asking each time a new unapproved URI scheme is used. It's not perfect, because it requires user to think, and approved apps may be exploitable as well, but at least it narrows attack surface and gives some warning.
It might be further improved to distinguish between clicked links and automatically triggered opens (like pop-up blocker does).
I have both Minis and the new one seems to have faster and more capable graphics. GMA950 supports CoreImage, which GeForce couldn't handle. In 1920x1600 full-screen CoverFlow was annoyingly slow. With GMA950 it's smooth(ish). Expose feels much snappier, too.
HTML and CSS have to work together and build off each other.
No, CSS is almost completly independent from HTML (you can take any DOM tree, any element names and style them using CSS). Theoretically HTML is styling-language-agnostic as well (<style type=text/javascript> used to work in Netscape).
painstakingly cumbersome absolute-sized and positioned divisions
Again, don't confuse what IE can't do with what CSS can't do. As far as CSS is concerned, you don't have to use positioning for grid layout - there is display:table-cell which makes any element behave like <td> . Tables for layout and hacks are neccessity because IE doesn't support CSS2, not because CSS2 doesn't support table-like layout.
Whether CSS sucks or not, it's not HTML's role to fix it. HTML defines structure and semantics of a document, and it's up to styling language to present them in a useful way.
Are you aware that HTML and CSS are different specs? Although CSS isn't perfect for layout, there is baisc automatic columnar layout (with text reflow) in CSS3 and table-like display in CSS2 (spec writers have written their part, now you should complain to Microsoft).
You could say that all tags are just standarized names for divs and spans, but you have to put name somewhere and there's no benefit in prepending everything with '<div class="'. There actually were some predefined class names in an earlier draft, but that didn't fly (for various, IMHO disputable, reasons - see public-html group archives).
CSS selector input[name=date] works now in all major browsers, including IE (since v.7 though).
HTML doesn't require you to stuff table cells with anything. In CSS you can control their presentation with empty-cells:show. Don't confuse specification with IE's lack of support for it.
HTML 5 includes new form controls for dates, time, urls, emails, with declarative validation. There are repetition templates (you could call it looping). It works already natively in Opera and there are free JS libraries for other browsers.
By the time there are browsers that supports this properly AND most people are using them I'll be retired.
One of the goals of HTML 5 is to make spec compatible with the web, not the other way round. Parsing model is reverse-engineered IE's behavior and so are some of the "new" features like WYSIWYG editor. Where possible, useful de-facto standards were documented and standarized as HTML 5. Most other features (like new form elements) degrade gracefully and can be fully implemented in current browsers using JavaScript.
Granted, IE and Firefox in text/html mode will choke on <article> tag, so don't quit your day job yet:)
Well at this point it's important to note one of the things that HTML 5 is not: XML.
This would be correct if you used <blink> instead of <b>;)
HTML 5 gives you choice of serialisations and you can either use HTML or XML. It doesn't affect semantics. As a perk, HTML 5 as HTML allows some stray slashes and xmlns attributes, so with little fiddling you can have one document that's compatible with both at the same time (so you can work around Firefox's inability to parse block elements in new tags and IE's inability to do anything with XHTML 5).
position:relative triggers hasLayout mode for given element, which appears to be a complete, different rendering (sub)engine in IE.
In CSS spec table elements are exception from all HTML/CSS layouting rules and IE they're even more of an exceptional-exception judging by the fact that display:table is not supported and display on table elements can only change visibility, not layout.
and on top of that <input> has been source of embarassment for IE already. <input type> alone used to instantly kill IE.
This is what happens when you implement stuff by adding hack on top of a hack (CSS on top of "magic" HTML elements) instead of refactoring old crap and using proper approach (all display handled by CSS only).
Project Honeypot's http:BL isn't handling dynamic IPs in any special way, so you have to be careful about these (combine with SORBS DUL and take into account age/threat that http:BL reports).
What on earth is the point in recommending a solution that doesn't work in IE?
GP suggested that CSS doesn't have easy way to lay out simple columns, while in fact CSS does. It's just that IE doesn't have proper CSS support, but no amount of new features in CSS spec will fix IE.
to enable server side processing of my CSS files, I have to give them a different file extension.
No. Any decent server can be configured to do that transparently (see mod_rewrite for example). You might have to worry about supporting HTTP cache validators though.
HTML 5 revived <embed>, <iframe> and added <video> precisely because <object> has failed. It turned out to be too difficult to implement interoperably -- you have one element, that might be an image, a page, a video, an applet or any plugin content, but you can never be sure what it is, because it's dependent on a remote resource and can even change dynamically. It must have DOM API for all of possible content types. It sometimes has intrinsic dimensions, sometimes it hasn't. And on top of it all, Eolas has been given patent for its most obvious implementation.
HTML 5 has fully documented parsing, including error handling. So you have unambiguousness of XML (handling of every possible input is covered by the spec) with fail-safety of real-world HTML (because users prefer browsers that don't show Yellow Screen of Death, ever).
What CSS needs is a way of defining columns, or a way of gluing DIVs together to it's easier to stack them side by side without running into all the problems you get if you float them.
You mean like display:table-cell that's part of CSS since 1996, and works reliably in every browser except IE?
It also REALLY REALLY needs variables.
For constants use server-side processing (color:%foo% is trivial to implement). For really variable-variables you have DHTML and W3C DOM2 Style.
Browser developers can't stop supporting HTML tagsoup, even worst presentational tags and quirks, because there is so much of it on the web (it is the web).
All tags, even those stupid ones, need to be documented to be implemented interoperably. Presentational tags are needed for WYSIWYG editors (they suck, but they won't die anytime soon, and blindly replacing <b> with <strong> or <font> with <span style> won't make document any more semantic).
Ping attribute protects privacy. Marketers currently track clicks with HTTP redirects and you can't disable that. You could disable ping attribute.
HTML 5 served as XML is exactly the same thing as XHTML/1 was to HTML 4. Nothing has changed here.
XML and table-based layouts are orthogonal.
Although Chris Wilson is chair of HTML5 WG, most of the work has been done by other developers lead by Ian Hickson (formely Opera, now Google employee).
Do your apps work in Internet Explorer? If they do, then you haven't used a single feature of XHTML, that's not available in HTML.
In fact most pages on the web that are supposed to be XHTML, aren't even interpreted as XHTML by XHTML-capable browsers (because nothing except MIME type triggers XHTML support, DOCTYPE is absolutely irrelevant).
I hate to give ammo to Opera haters but this is it, I am saying this public. That is a Opera bug which exists since first 9.x versions and lives up to date despite numerous kind of bug reports even posted to their forums.
You should be aware that Opera is working on a new "Kestrel" branch, so fixing it in soon-to-be-dead 9.0 branch would be waste of their time.
Unfortunately you'll probably have to hold on until they release next major version (which with complete CSS3 selectors, text-shadow and native QT4 and OS X UIs seems worth the wait).
(BTW: pretty much the same story is with Firefox 1-2 vs Firefox 3)
My stuff is writen to XHTML 1.0 Strict standards. If it doesn't work on the iPhone, it's not my problem.
Your grasp of W3C's standards seems very limited then. W3C has been pushing accessibilityacross devices for years. It's nothing new that there are "hoverless" devices, even CSS spec says it excplicitly:
Some conforming user agents supporting interactive media may not be able to support this [:hover] pseudo-class (e.g., a pen device).
Link spam is very easy to filter-out, because spammers have to use links and unobfuscated keywords, otherwise spam won't benefit them. And there are additional methods which can be used like observing odd "browsing" patterns, poor quality of HTTP/HTML implementations. Good'ol blacklists work too.
There are services that successfully implement content-filtering, like Akismet and (mine!) Sblam, which has accuracy over 99.85%. If you take into account "false positives" CAPTCHA causes by blocking disabled users or just discouraging posting, content-based filtering may be more effective than any "bulletproof" CAPTCHA.
Slashdot Mirror
Except "Please switch to browser X version Y", "Install plugin from vendor Z", "Enable anoying feature U", "Disable extension V", and so on. And if you replace flaky browsers with custom software or applets, you're back at square one.
I'd say there's even stronger incentive not to fix any bugs. Service must have 100% uptime and any change, any fix, any upgrade is a risk it will all go down, corrupt databases, etc.
Downtime and rollbacks may potentially harm customers more than a few bugs.
AOL makes it difficult to distinguish between their US and non-US network blocks. Workarounds for AOL's lameness aren't free:
http://www.maxmind.com/app/geoip_country
How about using existing resources better instead? Why a website having a million visitors should send copy of the same thing million times across the globe?
Problem, for the most part, could be solved by developing a new delivery mechanism that's not endpoint-oriented, but resource-oriented (you don't care where you get your data from as long as you can be sure you're getting latest, unaltered copy of data you asked for).
It might be further improved to distinguish between clicked links and automatically triggered opens (like pop-up blocker does).
I have both Minis and the new one seems to have faster and more capable graphics. GMA950 supports CoreImage, which GeForce couldn't handle. In 1920x1600 full-screen CoverFlow was annoyingly slow. With GMA950 it's smooth(ish). Expose feels much snappier, too.
No, CSS is almost completly independent from HTML (you can take any DOM tree, any element names and style them using CSS). Theoretically HTML is styling-language-agnostic as well (<style type=text/javascript> used to work in Netscape).
Again, don't confuse what IE can't do with what CSS can't do. As far as CSS is concerned, you don't have to use positioning for grid layout - there is display:table-cell which makes any element behave like <td> . Tables for layout and hacks are neccessity because IE doesn't support CSS2, not because CSS2 doesn't support table-like layout.
Whether CSS sucks or not, it's not HTML's role to fix it. HTML defines structure and semantics of a document, and it's up to styling language to present them in a useful way.
Are you aware that HTML and CSS are different specs? Although CSS isn't perfect for layout, there is baisc automatic columnar layout (with text reflow) in CSS3 and table-like display in CSS2 (spec writers have written their part, now you should complain to Microsoft).
You could say that all tags are just standarized names for divs and spans, but you have to put name somewhere and there's no benefit in prepending everything with '<div class="'. There actually were some predefined class names in an earlier draft, but that didn't fly (for various, IMHO disputable, reasons - see public-html group archives).
CSS selector input[name=date] works now in all major browsers, including IE (since v.7 though).
HTML doesn't require you to stuff table cells with anything. In CSS you can control their presentation with empty-cells:show. Don't confuse specification with IE's lack of support for it.
HTML 5 includes new form controls for dates, time, urls, emails, with declarative validation. There are repetition templates (you could call it looping). It works already natively in Opera and there are free JS libraries for other browsers.
One of the goals of HTML 5 is to make spec compatible with the web, not the other way round. Parsing model is reverse-engineered IE's behavior and so are some of the "new" features like WYSIWYG editor. Where possible, useful de-facto standards were documented and standarized as HTML 5. Most other features (like new form elements) degrade gracefully and can be fully implemented in current browsers using JavaScript.
Granted, IE and Firefox in text/html mode will choke on <article> tag, so don't quit your day job yet :)
It's there, based on contentEditable/designMode (so it's IE-compatible).
This would be correct if you used <blink> instead of <b> ;)
HTML 5 gives you choice of serialisations and you can either use HTML or XML. It doesn't affect semantics. As a perk, HTML 5 as HTML allows some stray slashes and xmlns attributes, so with little fiddling you can have one document that's compatible with both at the same time (so you can work around Firefox's inability to parse block elements in new tags and IE's inability to do anything with XHTML 5).
This is what happens when you implement stuff by adding hack on top of a hack (CSS on top of "magic" HTML elements) instead of refactoring old crap and using proper approach (all display handled by CSS only).
Project Honeypot's http:BL isn't handling dynamic IPs in any special way, so you have to be careful about these (combine with SORBS DUL and take into account age/threat that http:BL reports).
GP suggested that CSS doesn't have easy way to lay out simple columns, while in fact CSS does. It's just that IE doesn't have proper CSS support, but no amount of new features in CSS spec will fix IE.
No. Any decent server can be configured to do that transparently (see mod_rewrite for example). You might have to worry about supporting HTTP cache validators though.
HTML 5 revived <embed>, <iframe> and added <video> precisely because <object> has failed. It turned out to be too difficult to implement interoperably -- you have one element, that might be an image, a page, a video, an applet or any plugin content, but you can never be sure what it is, because it's dependent on a remote resource and can even change dynamically. It must have DOM API for all of possible content types. It sometimes has intrinsic dimensions, sometimes it hasn't. And on top of it all, Eolas has been given patent for its most obvious implementation.
HTML 5 has fully documented parsing, including error handling. So you have unambiguousness of XML (handling of every possible input is covered by the spec) with fail-safety of real-world HTML (because users prefer browsers that don't show Yellow Screen of Death, ever).
You mean like display:table-cell that's part of CSS since 1996, and works reliably in every browser except IE?
For constants use server-side processing (color:%foo% is trivial to implement). For really variable-variables you have DHTML and W3C DOM2 Style.
Browser developers can't stop supporting HTML tagsoup, even worst presentational tags and quirks, because there is so much of it on the web (it is the web).
All tags, even those stupid ones, need to be documented to be implemented interoperably. Presentational tags are needed for WYSIWYG editors (they suck, but they won't die anytime soon, and blindly replacing <b> with <strong> or <font> with <span style> won't make document any more semantic).
Ping attribute protects privacy. Marketers currently track clicks with HTTP redirects and you can't disable that. You could disable ping attribute.
HTML 5 served as XML is exactly the same thing as XHTML/1 was to HTML 4. Nothing has changed here.
XML and table-based layouts are orthogonal.
Although Chris Wilson is chair of HTML5 WG, most of the work has been done by other developers lead by Ian Hickson (formely Opera, now Google employee).
Do your apps work in Internet Explorer? If they do, then you haven't used a single feature of XHTML, that's not available in HTML.
In fact most pages on the web that are supposed to be XHTML, aren't even interpreted as XHTML by XHTML-capable browsers (because nothing except MIME type triggers XHTML support, DOCTYPE is absolutely irrelevant).
HTML 5 is in part designed by reverse-engineering IE. Most new HTML 5 features can be emulated in IE6 using JavaScript.
You should be aware that Opera is working on a new "Kestrel" branch, so fixing it in soon-to-be-dead 9.0 branch would be waste of their time.
Unfortunately you'll probably have to hold on until they release next major version (which with complete CSS3 selectors, text-shadow and native QT4 and OS X UIs seems worth the wait).
(BTW: pretty much the same story is with Firefox 1-2 vs Firefox 3)
fix and uh, there's more of it
Your grasp of W3C's standards seems very limited then. W3C has been pushing accessibility across devices for years. It's nothing new that there are "hoverless" devices, even CSS spec says it excplicitly:
Link spam is very easy to filter-out, because spammers have to use links and unobfuscated keywords, otherwise spam won't benefit them. And there are additional methods which can be used like observing odd "browsing" patterns, poor quality of HTTP/HTML implementations. Good'ol blacklists work too.
There are services that successfully implement content-filtering, like Akismet and (mine!) Sblam, which has accuracy over 99.85%.
If you take into account "false positives" CAPTCHA causes by blocking disabled users or just discouraging posting, content-based filtering may be more effective than any "bulletproof" CAPTCHA.