You think the FSF actually "determined" something?
Well, yes. A lot of lawyers contribute to the FSF's position on these things, and they have professional opinions on what they believe the correct reading of the law is. So does the SFLC, which agrees with the FSF here. This position might differ from a court's opinion: that remains to be seen.
It is much more likely that they are grasping at straws trying to come up with anything that supports their position, because their idea of a derivative work has no trace in statutory or case law, at least in the United States.
Are you a lawyer, or can you cite any statements by lawyers to this effect? If not, why should anyone take your word over that of the lawyers employed by the FSF and SFLC?
In fact the case law runs in the _opposite_ direction, holding (for example) that technical interfaces are not protectable by copyright (cf. Baystate v. Bentley Stems (1997)).
Which is a district court case, thus not binding precedent anywhere. The arguments presented to it were likely different from the ones that would be presented in a GPL case, too.
But most important, it doesn't really cover the same issue. At stake there was the similarity of two programs that were meant to read the same data format. The court concluded that there was no copyright infringement, because any similarity (including the use of identical data structures) was a necessary result of the fact that they had to accomplish the same function, so it was permitted under the merger doctrine.
A plugin is something totally different. A plugin's sole purpose is to incorporate into the larger work; it has no function without it. Yes, given that it's a plugin, it has no choice but to use the larger program's APIs. But (the argument goes) the mere fact that it's a plugin, that it's designed to do nothing but be combined with the larger work, makes it derivative. The fact that the programs call functions from one another is not the violation in itself, it's just the evidence that they're tightly coupled and so form a single work when combined.
And if they are not grasping at straws, how is it that the FSF website has no trace of a legal argument on the subject?
I don't know. Why don't you ask them? I've sent an e-mail to licensing@fsf.org, and I'll let you know what the response is. I'm speculating here, but maybe they don't want to present their arguments publicly lest their enemies have time to pick them apart and prepare good counter-arguments. When it comes to court, the FSF et al. will certainly volunteer to help the GPL side, and at that point they can present novel arguments that the other side won't be prepared for. Lawyers tend to be secretive about everything, as far as I've seen.
Whatever the case may be, and however biased or optimistic or secretive the FSF is, I'll still take the opinions of lawyers over those of non-lawyers any day. And it's not just the FSF's lawyers, by the way – as this very article's summary says, the lawyers that Matt Mullenweg contacted agreed. He spoke with the SFLC, and he published their response. Excerpt:
The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.
Clearly, putting it on multiple computers does constitute propagating, but as it is done by the IT person, only that IT person would retain the right to distribute further copies. Offering it for internal download, again, clearly qualifies. Why? Because without permission to copy something, making additional copies for additional machines would be a copyright violation.
The GPL is actually remarkably clear on this point; making something available to the general public is not required for the license to kick in, and internal distribution does count. The concern over internal distribution is legitimate, at least under GPLv3. Don't like that? Pick software with a better license next time, like GPL version 2.
I'll just pile on and give a more relevant quote from the GPL FAQ than the people who have already debunked you (source):
Is making and using multiple copies within one organization or company “distribution”?
No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.
However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.
A derivative work must be _substantially similar_ to a pre-existing work to be considered derivative.
A lot of copyright lawyers worked on the FSF's determination of what's a derivative work in software. Have any lawyers supported your opposite conclusion? If not, why do you think you know more than copyright lawyers about how to apply the case law on derivative works to software?
They didn't have any of those things in 2005 - the time period I was referring to in my post.
Just as you said here - (1) they gave source code dumps, (2) they didn't accept any patches, (3) their source code was filled with platform-specific code, (4) they didn't offer any bug repository even to core KHTML devs, (5) they asked KHTML devs to sign NDAs to see source code they added, etc.
Apple forked WebKit in 2002, and at that point it was as you describe. June 7, 2005 is the date when they created a webkit.opendarwin.org website for WebKit; opened the entire CVS repository with the full history of the project to public checkout; invited publicly-submitted patches (and they committed some of those on the very same day); opened a public bug tracker; and created public mailing lists and IRC channels. See Dave Hyatt's blog post. The first person to get commit access to WebKit who wasn't an Apple employee was Anders Carlsson, in August 2005.
So basically, no. WebKit became a full-fledged open-source project in 2005.
Your post highlights a key difference between written and spoken words -- we tend to contract words ("have a" to "hav.uh")
That's not a contraction, is it? The words are just pronounced one after the other, with have stressed and a unstressed. A contraction is when some sounds are actually omitted, like it's for it is.
As every IT manager knows, the amount of time it takes to produce some code is directly proportional to the number of people working on it!
They should employ 100,000 coders, that way exploits will get fixed minutes after they're found!
In that case, you can do even better: employ only 1/100,000 of a coder, and exploits will be fixed in nanoseconds! (Or wait, did you mean inversely proportional?)
While I of course applaud the aims of this particular legislation, I think Senator Sessions may not like the consequences of starting an international game of "we won't recognize your court judgments because of your 'abusive legal system.'" The US legal systems for IP and class action recovery are the poster-children for 'abusive', and at a time when so much of the US economy depends on IP lawsuits (to say nothing of some no-doubt imminent class action suits against a certain British oil company), being the first to start ignoring foreign court judgments on principle might prove ill-advised.
I'm pretty sure that everyone has been freely ignoring foreign court judgments since anyone first came up with the idea of a "court" sometime in prehistoric times. Foreign court rulings are not generally enforceable against someone outside the country, unless a specific agreement exists. Usually agreements do exist, at least between developed nations, but they tend to be very limited when it comes to civil cases, AFAIK.
IP and class action suits are entirely different, because there you're often talking about suing a multinational corporation. Likewise BP. As soon as they have assets in the country, the court can enforce its orders without asking permission from another country. Otherwise, you're out of luck. When the MPAA tried sending DMCA takedown notices to The Pirate Bay, they were indeed told to go jump off a cliff, IIRC. The suit had to be filed in the local nation's court to actually get an enforceable judgment.
... this won't help cases like Spamhaus being sued by spammers in the US for defamation and tortious interference.
You mean the case where they didn't bother defending themselves, ignored the default judgment at no harm to themselves, and eventually won anyway because some lawyers appealed for them pro bono? At very little eventual cost to themselves, while the spammer went broke suing them? What help did they need there, exactly?
It's because they legally had to - they forked KHTML which was under LGPL. Now webkit is also under LGPL.
They could easily have 1) only given source dumps instead of public SVN checkout, 2) not accepted patches or bug reports from the public, and 3) structured all their big additions/rewrites as a separate library so as not to be infected by the LGPL, dropping LGPL code as it gets rewritten, and thereby eventually getting rid of LGPL code entirely.
Instead, they have public SVN checkout, they have a public Bugzilla that they actually use, you can submit patches, you can get commit access, all their additions are LGPL. They did not legally have to do any of this. But they did, and it's awesome of them and we should give them credit for it. (Despite the fact that they may be completely evil in other respects.)
No, that's "thinking of US instead of thinking of ME". Too many people thinking of ME is why things like IE6, that are just plain bad for the public as a whole, are still so prevalent.
Please try to start thinking about US instead of ME ME ME.
You can't. Because if you do, then your business fails, your website goes down, and your principled stand no longer has any impact. It's natural selection, survival of the fittest. Businesses aren't self-interested because businessmen are nasty people: it's because if you aren't self-interested, your business fails. Period. Nice guys finish last, like it or not. Businesses can only tenably act against their self-interest if their competitors also do, which requires active coordination, which is impossible with so many websites out there and anyway is vulnerable to renege.
So, sorry, but grandparent is right. Your philosophy does not work in the real world, and cannot, as long as there's competition. The only way to do it is to ban all competition, like by being the government. And that's not such a great idea for website development, now, is it?
I'm willing to bet my life that less than 2% of sites have only 30% of users using IE. None of mine have IE at less than 50%.. even ones aimed at people in the creative industry where Mac usage is disproportionately large.
One of my websites has Firefox 48.18%, IE 29.34%, Chrome 13.11%, Opera 5.47%, Safari 3.28% according to Google Analytics. Firefox was a clear majority before Chrome showed up. It's a gaming site, so it attracts almost exclusively young techy types. W3Schools probably gets lots of visitors from corporate sites with only IE installed, and while your creative types might use Macs a lot more, they're also less likely to change the default browser when they do use Windows.
I think you're underestimating variability among site audiences here. Most sites are pretty specialized, and audiences can have drastically different browser usage patterns. I think more than 20 of the top thousand sites will have under 30% IE usage share. 2% is extremely small. mozilla.com, apple.com, and thepiratebay.org are three Alexa top 100 websites that are likely candidates. If I'm right on two of those three, or there are some I missed, you're already wrong for the top hundred sites. And variability will go way up as you get to less mainstream sites, so only looking at the top hundred is generous to your hypothesis.
Still, I agree that at least 90% of reasonably large sites probably see IE at 30% or more. 98% I wouldn't bet on, nor anything for smaller sites.
Granted, IE6 is broken, but not in the way most developers seem to think, or want to claim. It had bugs, and when it was designed, the W3C had not clarified how the box model was supposed to work, and IE6's assumptions were were wrong.
I agree that people drastically underestimate how good a browser IE6 was. It got 95% market share because it was the best browser at the time, period. However, this specific statement of yours is wrong, as far as I know. CSS2 clearly specified the box model and the meaning of the "width" property in 1998. IE6 was released on August 2001, IE5.5 in July 2000, IE5 in March 1999.
Thus IE6 must have still been in the design phase by the time that the box model was officially clarified, and its team must have decided that this bug wasn't worth delaying the browser release over. I don't begrudge them that decision, because I don't know what reasoning went into it. As I recall a Mozilla developer once saying when denying the blocking flag on a bug, "Release management is the art of deciding who to tick off." Software can't ship with all desired features, or even close to it.
I think it's fair to say overall that the thing we should be hating Microsoft for is not releasing IE6, but for taking five years to release IE7. If they had released incremental updates every two years after IE6, we would not be in nearly as terrible a situation as we're in today. IE7 is bad but way better than IE6, IE8 is actually tolerable in objective terms, and IE9 is looking to actually be almost competitive in standards support.
Except, all circumstances are cases where the patient is unable to communicate if they can pay. There is a powerful incentive to lie, and the cost (in time) to verify would easily be prohibitive in an emergency. To prevent hospitals from requiring payment-up-front, the government had to step in. What other solution could there be?
Hmm. I suppose so. You might be able to prove that you can pay, by presenting your insurance card or such, but you can't prove that you can't pay, because there's no way to demonstrate that you didn't leave your insurance card at home, don't have a rich uncle who will cover it, etc. Good point.
And that's just from a "protecting the market from a market failure" conservative argument. I think most people want to live in a society with the humanitarian rational as well.
Yes, certainly (me included).
Except there are people who know they should go to a doctor, but have to wait until it is an emergency. That doesn't help anyone. There's no risk being avoided, just an inability to pay.
Hmm, I see. So you're saying that once the poor already have emergency medical coverage that's paid for by other people, it makes sense to give them some types of other coverage so they can avoid more expensive emergency treatment. This does make sense in the cases where the prevention is likely to be less expensive than the emergency treatment, so it's a good (non-humanitarian) argument for at least very limited public funding of medicine for the poor. But it still only covers a small subset of medical care, surely not things like routine checkups.
Okay, I think we pretty much agree at this point. I have to commend you for carrying on an intelligent and productive discussion on Slashdot to its conclusion. Too bad it doesn't happen more often (on Slashdot, or in life generally).
I tend to think it would be impossible to force hospitals to assess someone's ability to pay before emergency treatment. After all, do I have insurance? Am I a millionaire? Of course I'll tell you I'll pay if I'm conscious, and of course they can foreclose on my double-wide when I don't afterwards. Sometimes, maybe, they can run a credit check, but see, I forgot my social, and I'm screaming in pain and about to pass out.
Therefore, we make hospitals provide emergency services, then try to get paid.
This rationale only applies to cases where the patient is unable to communicate about whether they can cover the treatment. My impression (could easily be wrong) is that the law typically requires hospitals to provide emergency treatment even to people who they know can't pay. This is justifiable on humanitarian grounds, if you're not a hardcore economic conservative/libertarian, but it's not at all the same rationale as automobile liability insurance.
You may have misunderstood what I meant by "a stitch in time". While I certainly think vaccines should be forced down everyone's throat for free, I was actually talking about the "one stitch" that prevents "nine". That is, not pervasive education, although probably screening. If you have your finger mangled, but have to wait for it to get ganggreen, that doesn't help you and makes it more expensive to fix. If you have pneumonia, and wait for it to do serious damage to your lungs.
This is only true once you know you have a serious problem, though. Generally people will go for treatment regardless once they hit that point, and don't need to be encouraged. (No?) If they don't, it's probably because they hope it will get better without treatment. In that case, you have to trade off the costs of putting off necessary treatment against the costs of receiving unnecessary treatment (because maybe it really isn't needed).
In medicine as in other things, people are biased to think that caution and long-term planning are always good ideas, and that incaution and short-term planning are only pragmatic compromises. In a lot of cases, though, caution and long-term planning can cause more long-term cost than the opposite, because they result in more wasted resources. If you only go to the doctor when you know you have to, you put yourself at more risk of lasting harm, but less risk of wasting money. (Kind of like opting out of insurance.) Whether this is a good idea depends on the exact level of harm and money we're talking about.
So yeah, sometimes going to the doctor early can save everyone money, but sometimes it can lose money. Sometimes it can save you, but sometimes it can kill you – preventive medical techniques are not without risk, and even entering a hospital puts you at non-negligible risk of routine infection. So it depends.
That is actually one of the most significant problems with HTML5. It provides no way for the video to maximize to full screen and is actually even against such functionality with JavaScript (page could maximize the window automatically and so on).
This will be done. See this whatwg thread, or this one. WebKit has a non-standard experimental implementation, and it's likely we'll see progress on standardization and deployment in the next year or so. For now, you can usually view videos full-screen by right-clicking and choosing the fullscreen option, or by opening in a new tab and hitting F11. This is one of six concerns that John Harding of YouTube told the WHATWG was important for YouTube to use HTML5 video more, and all the implementers are aware it needs to be fixed at some point.
This kind of function should be under the control of the browser. Not something called from within the Javascript on some random page.
Otherwise the day when a "goFullScreen()" method is made available on canvases and video object, is the day when you have über-annoying ads (or shock sites) that completely hijack the whole screen.
You mean like window.open(), which has allowed web pages to open new windows from JavaScript for more than a decade? Except, right, browsers all integrated popup blockers, so it can only be called when you click a button. Works fine. Flash does pretty much the same thing for full-screen, and HTML5 will too when (not if) that's added to the language.
(You know as some of the flash ads already do. Have you recently tried surfing with your AdBlock+ deactivated ?)
Flash ads can't full-screen until you click on them, and when they do there's a pop-up that tells you to hit escape to leave full-screen mode. So, no, they don't do this. They can take over the page, of course, but not the whole screen (i.e., they leave the browser UI alone).
Actually, surprisingly many authors use XHTML even today, and most HTML5 demos I've seen are written in well-formed XHTML in practice.
Really? Which authors use well-formed XML reliably, and which HTML5 demos are well-formed XML? The only major site I know of that serves well-formed pages reliably is Wikipedia. Remember that with XML, you don't get points for effort: if some minority of your pages are not well-formed, they fail to display.
The problem with XHTML2 didn't have anything to do with the fact that it was XML-only. The problem was that they threw out most existing HTML elements, and changed semantics for many that remained, so it wasn't backwards-compatible even with XHTML1.
I wasn't only talking about XHTML2. In 2004, Mozilla and Opera proposed that work begin in the W3C on incremental improvements to HTML independent of the path that the W3C was already pursuing. This path included XHTML2, but also XForms and other things (XML-based across the board). The W3C rejected their proposal, and that's how the WHATWG was formed. You can read a summary from the perspective of the browser implementers.
This wasn't only about XML, you're right, it was also about all-around impracticality. But XML was a big part of the picture. I can say with pretty good certainty that browser vendors would have refused to restrict new features only to XML even if that's all that was on the table. After all, implementers wrote HTML5, and had the choice to limit it to XML, but didn't. It's too brittle and hard to write correctly. One mistake and your page goes up in flames, and some of the mistakes you can make are very subtle.
Someone pointed out that on Unix, if you have a weird filename (non-printable characters) and try to visit a file:/// URL in some versions of Firefox, you get a well-formedness error. So even Mozilla can't get well-formedness right all the time. It's really hard to catch that kind of thing; XML is just too strict and too complicated. Errors about nesting are even worse, because they can't even be detected when you emit things unless you use an XML parser to build your output instead of string functions.
The thing discussed here is different - retain backwards compatibility on DOM level. This means that 1) any XHTML1 website just works, and 2) any HTML4 website can be automatically translated to XHTML1 - on the fly, if needed - and also just work.
So then you'd have to have a reliable HTML parser anyway, and you're saying it should be deployed on the server side instead of the client? What sense does that make? There are millions of servers, but at most five major clients. Implementing the parser in the client is much more reasonable, and much easier to implement. (Which is why that's what's actually done.)
The only reason to have HTML mode alongside XML in HTML5 that I see is to allow people with HTML4 websites to start using new HTML5 features without going XHTML. I do wonder how much this is an issue in practice, though, as the group of people most interested in HTML5 seem to be the same folks who proudly put "validated by W3C" stickers on their websites, and who moved it all to XHTML ages ago, anyway.
Actually, HTML5 advocates mostly get into violent arguments with XHTML advocates.;) In practice, though, it would be a major problem. HTML5 is not only meant for standards advocates, it's meant for everyone. Plenty of Google properties use HTML5 features, but basically nothing they output is well-formed. Five or ten years from now, Joe Q. Author is expected to be slapping down video tags just like img tags, and almost no authors use well-formed XML.
You wouldn't expect liability insurance to go down, but you would expect comprehensive, since it covers the cost of an uninsured driver colliding with you.
All else being equal, yes. It might have been masked by rate increases due to other things like inflation, though. Usually the price of goods and services goes up steadily over time, so a moderate cost saving might be reflected in a longer period until the next price increase, rather than an actual price decrease.
Emergency medical treatment is provided (ambulances sent, ER admissions) absent any method of payment. Therefore the cost for the people who cannot pay their bills gets spread out to those who can. Therefore, some amount of insurance is just as justifiable for healthcare.
Well, it's not quite the same, since conceivably you could also just not require emergency rooms to treat patients without payment. But if you're going to require that they be treated, then yes, the same rationale applies to limited mandatory health insurance as applies to mandatory liability insurance.
Or people who feel that it is cheaper (the stitch in time method) that allowing poor people to wait until they need to go to the hospital.
The one place multiple columns in an electronic medium makes sense is where you can fit everything on a single page by doing so, and in order to be readable that means knowing the size of the screen your readers will be using - if you can't guarantee that, just use a single column. Pretty much everyone is used to scrolling down as they read, it is quite easy and seamless.
Actually, there's at least one more case: where the user isn't reading sequentially at all. Wikipedia often uses multiple columns for footnotes, and that works excellently. They take up less vertical space, and it's no harder to read (since you're only reading one footnote at a time anyway, and probably not reading any at all).
HTML5 is different in that it adds a lot of new features. If it also mandated that anyone using them (and, in general, "DOCTYPE html") must serve well-formed XML, the uptake would be much quicker.
No, it wouldn't. Authors would not want to use XML, just as they do now. Browser implementers are not willing to work on features that authors don't want to use, so they'd just implement all the features without the XML requirements.
Actually, this is pretty much exactly what happened. The W3C tried to do new features only in XML. The browser implementers got sick of it and started work on HTML5 outside the W3C, ignoring the W3C standards. (Correctly, in my view, because XHTML2 et al. were bad ideas in practice, but some people still dispute that.) Eventually the W3C accepted HTML5 because the alternative was being completely ignored.
So, the W3C tried it. Didn't work. Browsers aren't going to try it, because they compete, so they're forced to cater to actual users and authors, and almost none of them want to use XML if given the choice.
What insurance is good for is one thing and one thing only: To handle things between minor fender benders up to totaling a car and/or covering relatively minor injuries to others or major ones to yourself. Anything past that and you're screwed. Anything less than that, and you're better off simply paying out of your own pocket because of how much higher your premiums will be.
Assuming you can actually afford to pay out of your own pocket. Not everyone can afford to pay ten thousand dollars all at once for damaging someone's fancy car. If you can afford to pay close to your insurer's maximum payout out-of-pocket, then insurance isn't worthwhile, no.
In case you don't know this yet, insurance is a scam. It sounds nice in theory, but it's legalized gambling with a twist--you're betting money on something bad happening instead of something good.
The difference is key. In gambling, you accept a known loss for the chance of a very large gain. In insurance, you accept a known loss to avoid the chance of a very large loss. What's the difference? Money has decreasing marginal utility. Every dollar you earn is worth less than the last. This is especially evident at the high end: ten billion dollars isn't appreciably more useful than a billion dollars, certainly not ten times as useful.
So say you bet one dollar for a one-in-a-million chance to win a million dollars. Your expected monetary gain is zero, but your expected utility gain is negative. A million dollars is less than a million times as useful as one dollar, so you're losing out. The fact that your odds will be less than one-in-a-million just amplifies your loss; even if it were even you'd still be losing.
On the other hand, say you have a one-in-a-million chance of losing a million dollars. If you can pay a dollar to avoid that, it's almost certainly worth it. The utility loss from losing a million dollars is much more than a million times the utility loss of using one dollar. So in this case, it would be a good deal if you were paying exactly on the odds as here. Whether it's a good deal in real life depends on how much extra the insurance company charges: it might or might not be a good deal.
Just like in a casino, in which the house always comes out ahead, the insurance companies will always come out ahead, too.
Yes, they'll always come out ahead, but that doesn't mean you don't also come out ahead. It's perfectly possible for both parties in a transaction to gain utility from it. In the case of a casino, they come out ahead, but more importantly you come out behind. This is not always true for insurance (although it can be, as with any good or service).
Add up all of the money you--and your employer, on your behalf--have paid over the years for insurance, and imagine how far that money would have gone had you paid it into, I dunno, a mutual fund or something instead of paying for actuaries and marble-halled buildings. You might actually be able to pay off a large liability claim if you had.
If we're talking about you, or a small employer, then sure, all those insurance premiums would be enough to pay for a large liability claim. That does defeat the purpose of insurance – as long as you only got the claim after you had been stockpiling money for long enough. That's the flaw. So how to get around it? Well, you could pool together with a bunch of other people, so the pot is big enough from the start that it's unlikely to be depleted . . . hmm, why didn't anyone ever think of that?
If we're talking about a large employer, then they probably aren't paying for insurance at all. A company that owns 100,000 buildings across the world generally does not pay for fire insurance, for example. Why? Because they can just pay directly and skip the insurers, since the cost is no big dea
Just display all canvases as blank, and don't display their contents until the user lets them.
Then watch pages display all the text and images inside a canvas, so that if you turn off the canvas element, you turn off everything.
They can already do this with Flash, and in fact some do. It's not going to be any easier or more reliable to do this with canvas than Flash in the near future. Flash has had well over 95% market share at various points, and few sites did this despite that. Canvas doesn't change anything. Non-HTML sites are a pain in the neck and lose a lot of functionality that users expect.
In the end, anything evil that can be done with canvas can be done with Flash, since canvas provides a subset of Flash's functionality. Canvas is not going to cause any problems for users that did not already exist with Flash.
IE9, which should hit beta later this year, supports all HTML5 elements.
Not even close. No browser is even close. Large swathes of the HTML5 spec are totally unimplemented. If you restrict yourself solely to new elements and not other new features (I don't know why you would), no browser implements <progress>, <meter>, <details>, <menu>, and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.
Overall, IE9 is a huge step forward from IE8 and drastically closes the standards-compliance gap with other browsers, but it's still behind.
The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off. With canvas, the JavaScript used for the animated ads is run in the same context as the JavaScript used for essential page functionality. It's much harder to disable the intrusive ads without disabling the rest of the page.
No, it would be trivial. Just display all canvases as blank, and don't display their contents until the user lets them. You can treat canvas operations as no-ops, or have them execute but not draw the results to the screen until the user requests it.
This won't stop pages from using 100% CPU, but they can do that anyway. They usually don't, and I don't expect canvas to change that.
Is HTML 5 still structured like XHTML? I hope that it is, because one of the biggest pains in the HTML standard was the inconsistent syntax. I think a strength of strict XHTML was that it could be easily parsed by an XML parser, and if we are going back to the syntax of HTML 4 I think that's a step backwards.
It's not a step backwards, because we never actually had a web that could be parsed with an XML parser. If you want to parse the web, you need to be able to parse tag soup, because most authors will never get with the XML program. So HTML5 defines a horrifyingly complicated but well-defined non-XML "tag soup" markup. This is designed so that an HTML5 parser will actually parse web pages the same as browsers, thus as the author intended (or as close as possible). So just replace your XML parser with an HTML5 parser, and you can parse real-life web pages, not just the tiny minority of web pages that actually are well-formed XML (Wikipedia, and what else?).
Another major benefit of this is that browsers will all parse the same pages the same way. Previously, each one had its own idiosyncratic pile of hacks to address specific bug reports they received. Firefox 4 now uses an HTML5 parser, and WebKit is working on one, so eventually they should all parse everything interoperably.
Of course, you can still use XML if you want. HTML5 permits that too.
Slashdot Mirror
You think the FSF actually "determined" something?
Well, yes. A lot of lawyers contribute to the FSF's position on these things, and they have professional opinions on what they believe the correct reading of the law is. So does the SFLC, which agrees with the FSF here. This position might differ from a court's opinion: that remains to be seen.
It is much more likely that they are grasping at straws trying to come up with anything that supports their position, because their idea of a derivative work has no trace in statutory or case law, at least in the United States.
Are you a lawyer, or can you cite any statements by lawyers to this effect? If not, why should anyone take your word over that of the lawyers employed by the FSF and SFLC?
In fact the case law runs in the _opposite_ direction, holding (for example) that technical interfaces are not protectable by copyright (cf. Baystate v. Bentley Stems (1997)).
Which is a district court case, thus not binding precedent anywhere. The arguments presented to it were likely different from the ones that would be presented in a GPL case, too.
But most important, it doesn't really cover the same issue. At stake there was the similarity of two programs that were meant to read the same data format. The court concluded that there was no copyright infringement, because any similarity (including the use of identical data structures) was a necessary result of the fact that they had to accomplish the same function, so it was permitted under the merger doctrine.
A plugin is something totally different. A plugin's sole purpose is to incorporate into the larger work; it has no function without it. Yes, given that it's a plugin, it has no choice but to use the larger program's APIs. But (the argument goes) the mere fact that it's a plugin, that it's designed to do nothing but be combined with the larger work, makes it derivative. The fact that the programs call functions from one another is not the violation in itself, it's just the evidence that they're tightly coupled and so form a single work when combined.
And if they are not grasping at straws, how is it that the FSF website has no trace of a legal argument on the subject?
I don't know. Why don't you ask them? I've sent an e-mail to licensing@fsf.org, and I'll let you know what the response is. I'm speculating here, but maybe they don't want to present their arguments publicly lest their enemies have time to pick them apart and prepare good counter-arguments. When it comes to court, the FSF et al. will certainly volunteer to help the GPL side, and at that point they can present novel arguments that the other side won't be prepared for. Lawyers tend to be secretive about everything, as far as I've seen.
Whatever the case may be, and however biased or optimistic or secretive the FSF is, I'll still take the opinions of lawyers over those of non-lawyers any day. And it's not just the FSF's lawyers, by the way – as this very article's summary says, the lawyers that Matt Mullenweg contacted agreed. He spoke with the SFLC, and he published their response. Excerpt:
Clearly, putting it on multiple computers does constitute propagating, but as it is done by the IT person, only that IT person would retain the right to distribute further copies. Offering it for internal download, again, clearly qualifies. Why? Because without permission to copy something, making additional copies for additional machines would be a copyright violation.
The GPL is actually remarkably clear on this point; making something available to the general public is not required for the license to kick in, and internal distribution does count. The concern over internal distribution is legitimate, at least under GPLv3. Don't like that? Pick software with a better license next time, like GPL version 2.
I'll just pile on and give a more relevant quote from the GPL FAQ than the people who have already debunked you (source):
A derivative work must be _substantially similar_ to a pre-existing work to be considered derivative.
A lot of copyright lawyers worked on the FSF's determination of what's a derivative work in software. Have any lawyers supported your opposite conclusion? If not, why do you think you know more than copyright lawyers about how to apply the case law on derivative works to software?
They didn't have any of those things in 2005 - the time period I was referring to in my post.
Just as you said here - (1) they gave source code dumps, (2) they didn't accept any patches, (3) their source code was filled with platform-specific code, (4) they didn't offer any bug repository even to core KHTML devs, (5) they asked KHTML devs to sign NDAs to see source code they added, etc.
Apple forked WebKit in 2002, and at that point it was as you describe. June 7, 2005 is the date when they created a webkit.opendarwin.org website for WebKit; opened the entire CVS repository with the full history of the project to public checkout; invited publicly-submitted patches (and they committed some of those on the very same day); opened a public bug tracker; and created public mailing lists and IRC channels. See Dave Hyatt's blog post. The first person to get commit access to WebKit who wasn't an Apple employee was Anders Carlsson, in August 2005.
So basically, no. WebKit became a full-fledged open-source project in 2005.
Your post highlights a key difference between written and spoken words -- we tend to contract words ("have a" to "hav.uh")
That's not a contraction, is it? The words are just pronounced one after the other, with have stressed and a unstressed. A contraction is when some sounds are actually omitted, like it's for it is.
As every IT manager knows, the amount of time it takes to produce some code is directly proportional to the number of people working on it!
They should employ 100,000 coders, that way exploits will get fixed minutes after they're found!
In that case, you can do even better: employ only 1/100,000 of a coder, and exploits will be fixed in nanoseconds! (Or wait, did you mean inversely proportional?)
While I of course applaud the aims of this particular legislation, I think Senator Sessions may not like the consequences of starting an international game of "we won't recognize your court judgments because of your 'abusive legal system.'" The US legal systems for IP and class action recovery are the poster-children for 'abusive', and at a time when so much of the US economy depends on IP lawsuits (to say nothing of some no-doubt imminent class action suits against a certain British oil company), being the first to start ignoring foreign court judgments on principle might prove ill-advised.
I'm pretty sure that everyone has been freely ignoring foreign court judgments since anyone first came up with the idea of a "court" sometime in prehistoric times. Foreign court rulings are not generally enforceable against someone outside the country, unless a specific agreement exists. Usually agreements do exist, at least between developed nations, but they tend to be very limited when it comes to civil cases, AFAIK.
IP and class action suits are entirely different, because there you're often talking about suing a multinational corporation. Likewise BP. As soon as they have assets in the country, the court can enforce its orders without asking permission from another country. Otherwise, you're out of luck. When the MPAA tried sending DMCA takedown notices to The Pirate Bay, they were indeed told to go jump off a cliff, IIRC. The suit had to be filed in the local nation's court to actually get an enforceable judgment.
... this won't help cases like Spamhaus being sued by spammers in the US for defamation and tortious interference.
You mean the case where they didn't bother defending themselves, ignored the default judgment at no harm to themselves, and eventually won anyway because some lawyers appealed for them pro bono? At very little eventual cost to themselves, while the spammer went broke suing them? What help did they need there, exactly?
It's because they legally had to - they forked KHTML which was under LGPL. Now webkit is also under LGPL.
They could easily have 1) only given source dumps instead of public SVN checkout, 2) not accepted patches or bug reports from the public, and 3) structured all their big additions/rewrites as a separate library so as not to be infected by the LGPL, dropping LGPL code as it gets rewritten, and thereby eventually getting rid of LGPL code entirely.
Instead, they have public SVN checkout, they have a public Bugzilla that they actually use, you can submit patches, you can get commit access, all their additions are LGPL. They did not legally have to do any of this. But they did, and it's awesome of them and we should give them credit for it. (Despite the fact that they may be completely evil in other respects.)
No, that's "thinking of US instead of thinking of ME". Too many people thinking of ME is why things like IE6, that are just plain bad for the public as a whole, are still so prevalent.
Please try to start thinking about US instead of ME ME ME.
You can't. Because if you do, then your business fails, your website goes down, and your principled stand no longer has any impact. It's natural selection, survival of the fittest. Businesses aren't self-interested because businessmen are nasty people: it's because if you aren't self-interested, your business fails. Period. Nice guys finish last, like it or not. Businesses can only tenably act against their self-interest if their competitors also do, which requires active coordination, which is impossible with so many websites out there and anyway is vulnerable to renege.
So, sorry, but grandparent is right. Your philosophy does not work in the real world, and cannot, as long as there's competition. The only way to do it is to ban all competition, like by being the government. And that's not such a great idea for website development, now, is it?
I'm willing to bet my life that less than 2% of sites have only 30% of users using IE. None of mine have IE at less than 50%.. even ones aimed at people in the creative industry where Mac usage is disproportionately large.
One of my websites has Firefox 48.18%, IE 29.34%, Chrome 13.11%, Opera 5.47%, Safari 3.28% according to Google Analytics. Firefox was a clear majority before Chrome showed up. It's a gaming site, so it attracts almost exclusively young techy types. W3Schools probably gets lots of visitors from corporate sites with only IE installed, and while your creative types might use Macs a lot more, they're also less likely to change the default browser when they do use Windows.
I think you're underestimating variability among site audiences here. Most sites are pretty specialized, and audiences can have drastically different browser usage patterns. I think more than 20 of the top thousand sites will have under 30% IE usage share. 2% is extremely small. mozilla.com, apple.com, and thepiratebay.org are three Alexa top 100 websites that are likely candidates. If I'm right on two of those three, or there are some I missed, you're already wrong for the top hundred sites. And variability will go way up as you get to less mainstream sites, so only looking at the top hundred is generous to your hypothesis.
Still, I agree that at least 90% of reasonably large sites probably see IE at 30% or more. 98% I wouldn't bet on, nor anything for smaller sites.
Granted, IE6 is broken, but not in the way most developers seem to think, or want to claim. It had bugs, and when it was designed, the W3C had not clarified how the box model was supposed to work, and IE6's assumptions were were wrong.
I agree that people drastically underestimate how good a browser IE6 was. It got 95% market share because it was the best browser at the time, period. However, this specific statement of yours is wrong, as far as I know. CSS2 clearly specified the box model and the meaning of the "width" property in 1998. IE6 was released on August 2001, IE5.5 in July 2000, IE5 in March 1999.
Thus IE6 must have still been in the design phase by the time that the box model was officially clarified, and its team must have decided that this bug wasn't worth delaying the browser release over. I don't begrudge them that decision, because I don't know what reasoning went into it. As I recall a Mozilla developer once saying when denying the blocking flag on a bug, "Release management is the art of deciding who to tick off." Software can't ship with all desired features, or even close to it.
I think it's fair to say overall that the thing we should be hating Microsoft for is not releasing IE6, but for taking five years to release IE7. If they had released incremental updates every two years after IE6, we would not be in nearly as terrible a situation as we're in today. IE7 is bad but way better than IE6, IE8 is actually tolerable in objective terms, and IE9 is looking to actually be almost competitive in standards support.
Except, all circumstances are cases where the patient is unable to communicate if they can pay. There is a powerful incentive to lie, and the cost (in time) to verify would easily be prohibitive in an emergency. To prevent hospitals from requiring payment-up-front, the government had to step in. What other solution could there be?
Hmm. I suppose so. You might be able to prove that you can pay, by presenting your insurance card or such, but you can't prove that you can't pay, because there's no way to demonstrate that you didn't leave your insurance card at home, don't have a rich uncle who will cover it, etc. Good point.
And that's just from a "protecting the market from a market failure" conservative argument. I think most people want to live in a society with the humanitarian rational as well.
Yes, certainly (me included).
Except there are people who know they should go to a doctor, but have to wait until it is an emergency. That doesn't help anyone. There's no risk being avoided, just an inability to pay.
Hmm, I see. So you're saying that once the poor already have emergency medical coverage that's paid for by other people, it makes sense to give them some types of other coverage so they can avoid more expensive emergency treatment. This does make sense in the cases where the prevention is likely to be less expensive than the emergency treatment, so it's a good (non-humanitarian) argument for at least very limited public funding of medicine for the poor. But it still only covers a small subset of medical care, surely not things like routine checkups.
Okay, I think we pretty much agree at this point. I have to commend you for carrying on an intelligent and productive discussion on Slashdot to its conclusion. Too bad it doesn't happen more often (on Slashdot, or in life generally).
I tend to think it would be impossible to force hospitals to assess someone's ability to pay before emergency treatment. After all, do I have insurance? Am I a millionaire? Of course I'll tell you I'll pay if I'm conscious, and of course they can foreclose on my double-wide when I don't afterwards. Sometimes, maybe, they can run a credit check, but see, I forgot my social, and I'm screaming in pain and about to pass out.
Therefore, we make hospitals provide emergency services, then try to get paid.
This rationale only applies to cases where the patient is unable to communicate about whether they can cover the treatment. My impression (could easily be wrong) is that the law typically requires hospitals to provide emergency treatment even to people who they know can't pay. This is justifiable on humanitarian grounds, if you're not a hardcore economic conservative/libertarian, but it's not at all the same rationale as automobile liability insurance.
You may have misunderstood what I meant by "a stitch in time". While I certainly think vaccines should be forced down everyone's throat for free, I was actually talking about the "one stitch" that prevents "nine". That is, not pervasive education, although probably screening. If you have your finger mangled, but have to wait for it to get ganggreen, that doesn't help you and makes it more expensive to fix. If you have pneumonia, and wait for it to do serious damage to your lungs.
This is only true once you know you have a serious problem, though. Generally people will go for treatment regardless once they hit that point, and don't need to be encouraged. (No?) If they don't, it's probably because they hope it will get better without treatment. In that case, you have to trade off the costs of putting off necessary treatment against the costs of receiving unnecessary treatment (because maybe it really isn't needed).
In medicine as in other things, people are biased to think that caution and long-term planning are always good ideas, and that incaution and short-term planning are only pragmatic compromises. In a lot of cases, though, caution and long-term planning can cause more long-term cost than the opposite, because they result in more wasted resources. If you only go to the doctor when you know you have to, you put yourself at more risk of lasting harm, but less risk of wasting money. (Kind of like opting out of insurance.) Whether this is a good idea depends on the exact level of harm and money we're talking about.
So yeah, sometimes going to the doctor early can save everyone money, but sometimes it can lose money. Sometimes it can save you, but sometimes it can kill you – preventive medical techniques are not without risk, and even entering a hospital puts you at non-negligible risk of routine infection. So it depends.
That is actually one of the most significant problems with HTML5. It provides no way for the video to maximize to full screen and is actually even against such functionality with JavaScript (page could maximize the window automatically and so on).
This will be done. See this whatwg thread, or this one. WebKit has a non-standard experimental implementation, and it's likely we'll see progress on standardization and deployment in the next year or so. For now, you can usually view videos full-screen by right-clicking and choosing the fullscreen option, or by opening in a new tab and hitting F11. This is one of six concerns that John Harding of YouTube told the WHATWG was important for YouTube to use HTML5 video more, and all the implementers are aware it needs to be fixed at some point.
This kind of function should be under the control of the browser. Not something called from within the Javascript on some random page.
Otherwise the day when a "goFullScreen()" method is made available on canvases and video object, is the day when you have über-annoying ads (or shock sites) that completely hijack the whole screen.
You mean like window.open(), which has allowed web pages to open new windows from JavaScript for more than a decade? Except, right, browsers all integrated popup blockers, so it can only be called when you click a button. Works fine. Flash does pretty much the same thing for full-screen, and HTML5 will too when (not if) that's added to the language.
(You know as some of the flash ads already do. Have you recently tried surfing with your AdBlock+ deactivated ?)
Flash ads can't full-screen until you click on them, and when they do there's a pop-up that tells you to hit escape to leave full-screen mode. So, no, they don't do this. They can take over the page, of course, but not the whole screen (i.e., they leave the browser UI alone).
Actually, surprisingly many authors use XHTML even today, and most HTML5 demos I've seen are written in well-formed XHTML in practice.
Really? Which authors use well-formed XML reliably, and which HTML5 demos are well-formed XML? The only major site I know of that serves well-formed pages reliably is Wikipedia. Remember that with XML, you don't get points for effort: if some minority of your pages are not well-formed, they fail to display.
The problem with XHTML2 didn't have anything to do with the fact that it was XML-only. The problem was that they threw out most existing HTML elements, and changed semantics for many that remained, so it wasn't backwards-compatible even with XHTML1.
I wasn't only talking about XHTML2. In 2004, Mozilla and Opera proposed that work begin in the W3C on incremental improvements to HTML independent of the path that the W3C was already pursuing. This path included XHTML2, but also XForms and other things (XML-based across the board). The W3C rejected their proposal, and that's how the WHATWG was formed. You can read a summary from the perspective of the browser implementers.
This wasn't only about XML, you're right, it was also about all-around impracticality. But XML was a big part of the picture. I can say with pretty good certainty that browser vendors would have refused to restrict new features only to XML even if that's all that was on the table. After all, implementers wrote HTML5, and had the choice to limit it to XML, but didn't. It's too brittle and hard to write correctly. One mistake and your page goes up in flames, and some of the mistakes you can make are very subtle.
Someone pointed out that on Unix, if you have a weird filename (non-printable characters) and try to visit a file:/// URL in some versions of Firefox, you get a well-formedness error. So even Mozilla can't get well-formedness right all the time. It's really hard to catch that kind of thing; XML is just too strict and too complicated. Errors about nesting are even worse, because they can't even be detected when you emit things unless you use an XML parser to build your output instead of string functions.
The thing discussed here is different - retain backwards compatibility on DOM level. This means that 1) any XHTML1 website just works, and 2) any HTML4 website can be automatically translated to XHTML1 - on the fly, if needed - and also just work.
So then you'd have to have a reliable HTML parser anyway, and you're saying it should be deployed on the server side instead of the client? What sense does that make? There are millions of servers, but at most five major clients. Implementing the parser in the client is much more reasonable, and much easier to implement. (Which is why that's what's actually done.)
The only reason to have HTML mode alongside XML in HTML5 that I see is to allow people with HTML4 websites to start using new HTML5 features without going XHTML. I do wonder how much this is an issue in practice, though, as the group of people most interested in HTML5 seem to be the same folks who proudly put "validated by W3C" stickers on their websites, and who moved it all to XHTML ages ago, anyway.
Actually, HTML5 advocates mostly get into violent arguments with XHTML advocates. ;) In practice, though, it would be a major problem. HTML5 is not only meant for standards advocates, it's meant for everyone. Plenty of Google properties use HTML5 features, but basically nothing they output is well-formed. Five or ten years from now, Joe Q. Author is expected to be slapping down video tags just like img tags, and almost no authors use well-formed XML.
You wouldn't expect liability insurance to go down, but you would expect comprehensive, since it covers the cost of an uninsured driver colliding with you.
All else being equal, yes. It might have been masked by rate increases due to other things like inflation, though. Usually the price of goods and services goes up steadily over time, so a moderate cost saving might be reflected in a longer period until the next price increase, rather than an actual price decrease.
Emergency medical treatment is provided (ambulances sent, ER admissions) absent any method of payment. Therefore the cost for the people who cannot pay their bills gets spread out to those who can. Therefore, some amount of insurance is just as justifiable for healthcare.
Well, it's not quite the same, since conceivably you could also just not require emergency rooms to treat patients without payment. But if you're going to require that they be treated, then yes, the same rationale applies to limited mandatory health insurance as applies to mandatory liability insurance.
Or people who feel that it is cheaper (the stitch in time method) that allowing poor people to wait until they need to go to the hospital.
My understanding is that prevention often costs more than treatment, so I don't think this is obviously correct as a general rule. In some cases, doubtless.
The one place multiple columns in an electronic medium makes sense is where you can fit everything on a single page by doing so, and in order to be readable that means knowing the size of the screen your readers will be using - if you can't guarantee that, just use a single column. Pretty much everyone is used to scrolling down as they read, it is quite easy and seamless.
Actually, there's at least one more case: where the user isn't reading sequentially at all. Wikipedia often uses multiple columns for footnotes, and that works excellently. They take up less vertical space, and it's no harder to read (since you're only reading one footnote at a time anyway, and probably not reading any at all).
HTML5 is different in that it adds a lot of new features. If it also mandated that anyone using them (and, in general, "DOCTYPE html") must serve well-formed XML, the uptake would be much quicker.
No, it wouldn't. Authors would not want to use XML, just as they do now. Browser implementers are not willing to work on features that authors don't want to use, so they'd just implement all the features without the XML requirements.
Actually, this is pretty much exactly what happened. The W3C tried to do new features only in XML. The browser implementers got sick of it and started work on HTML5 outside the W3C, ignoring the W3C standards. (Correctly, in my view, because XHTML2 et al. were bad ideas in practice, but some people still dispute that.) Eventually the W3C accepted HTML5 because the alternative was being completely ignored.
So, the W3C tried it. Didn't work. Browsers aren't going to try it, because they compete, so they're forced to cater to actual users and authors, and almost none of them want to use XML if given the choice.
What insurance is good for is one thing and one thing only: To handle things between minor fender benders up to totaling a car and/or covering relatively minor injuries to others or major ones to yourself. Anything past that and you're screwed. Anything less than that, and you're better off simply paying out of your own pocket because of how much higher your premiums will be.
Assuming you can actually afford to pay out of your own pocket. Not everyone can afford to pay ten thousand dollars all at once for damaging someone's fancy car. If you can afford to pay close to your insurer's maximum payout out-of-pocket, then insurance isn't worthwhile, no.
In case you don't know this yet, insurance is a scam. It sounds nice in theory, but it's legalized gambling with a twist--you're betting money on something bad happening instead of something good.
The difference is key. In gambling, you accept a known loss for the chance of a very large gain. In insurance, you accept a known loss to avoid the chance of a very large loss. What's the difference? Money has decreasing marginal utility. Every dollar you earn is worth less than the last. This is especially evident at the high end: ten billion dollars isn't appreciably more useful than a billion dollars, certainly not ten times as useful.
So say you bet one dollar for a one-in-a-million chance to win a million dollars. Your expected monetary gain is zero, but your expected utility gain is negative. A million dollars is less than a million times as useful as one dollar, so you're losing out. The fact that your odds will be less than one-in-a-million just amplifies your loss; even if it were even you'd still be losing.
On the other hand, say you have a one-in-a-million chance of losing a million dollars. If you can pay a dollar to avoid that, it's almost certainly worth it. The utility loss from losing a million dollars is much more than a million times the utility loss of using one dollar. So in this case, it would be a good deal if you were paying exactly on the odds as here. Whether it's a good deal in real life depends on how much extra the insurance company charges: it might or might not be a good deal.
Just like in a casino, in which the house always comes out ahead, the insurance companies will always come out ahead, too.
Yes, they'll always come out ahead, but that doesn't mean you don't also come out ahead. It's perfectly possible for both parties in a transaction to gain utility from it. In the case of a casino, they come out ahead, but more importantly you come out behind. This is not always true for insurance (although it can be, as with any good or service).
Add up all of the money you--and your employer, on your behalf--have paid over the years for insurance, and imagine how far that money would have gone had you paid it into, I dunno, a mutual fund or something instead of paying for actuaries and marble-halled buildings. You might actually be able to pay off a large liability claim if you had.
If we're talking about you, or a small employer, then sure, all those insurance premiums would be enough to pay for a large liability claim. That does defeat the purpose of insurance – as long as you only got the claim after you had been stockpiling money for long enough. That's the flaw. So how to get around it? Well, you could pool together with a bunch of other people, so the pot is big enough from the start that it's unlikely to be depleted . . . hmm, why didn't anyone ever think of that?
If we're talking about a large employer, then they probably aren't paying for insurance at all. A company that owns 100,000 buildings across the world generally does not pay for fire insurance, for example. Why? Because they can just pay directly and skip the insurers, since the cost is no big dea
Just display all canvases as blank, and don't display their contents until the user lets them.
Then watch pages display all the text and images inside a canvas, so that if you turn off the canvas element, you turn off everything.
They can already do this with Flash, and in fact some do. It's not going to be any easier or more reliable to do this with canvas than Flash in the near future. Flash has had well over 95% market share at various points, and few sites did this despite that. Canvas doesn't change anything. Non-HTML sites are a pain in the neck and lose a lot of functionality that users expect.
In the end, anything evil that can be done with canvas can be done with Flash, since canvas provides a subset of Flash's functionality. Canvas is not going to cause any problems for users that did not already exist with Flash.
IE9, which should hit beta later this year, supports all HTML5 elements.
Not even close. No browser is even close. Large swathes of the HTML5 spec are totally unimplemented. If you restrict yourself solely to new elements and not other new features (I don't know why you would), no browser implements <progress>, <meter>, <details>, <menu>, and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.
Overall, IE9 is a huge step forward from IE8 and drastically closes the standards-compliance gap with other browsers, but it's still behind.
The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off. With canvas, the JavaScript used for the animated ads is run in the same context as the JavaScript used for essential page functionality. It's much harder to disable the intrusive ads without disabling the rest of the page.
No, it would be trivial. Just display all canvases as blank, and don't display their contents until the user lets them. You can treat canvas operations as no-ops, or have them execute but not draw the results to the screen until the user requests it.
This won't stop pages from using 100% CPU, but they can do that anyway. They usually don't, and I don't expect canvas to change that.
Is HTML 5 still structured like XHTML? I hope that it is, because one of the biggest pains in the HTML standard was the inconsistent syntax. I think a strength of strict XHTML was that it could be easily parsed by an XML parser, and if we are going back to the syntax of HTML 4 I think that's a step backwards.
It's not a step backwards, because we never actually had a web that could be parsed with an XML parser. If you want to parse the web, you need to be able to parse tag soup, because most authors will never get with the XML program. So HTML5 defines a horrifyingly complicated but well-defined non-XML "tag soup" markup. This is designed so that an HTML5 parser will actually parse web pages the same as browsers, thus as the author intended (or as close as possible). So just replace your XML parser with an HTML5 parser, and you can parse real-life web pages, not just the tiny minority of web pages that actually are well-formed XML (Wikipedia, and what else?).
Another major benefit of this is that browsers will all parse the same pages the same way. Previously, each one had its own idiosyncratic pile of hacks to address specific bug reports they received. Firefox 4 now uses an HTML5 parser, and WebKit is working on one, so eventually they should all parse everything interoperably.
Of course, you can still use XML if you want. HTML5 permits that too.