What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state?
Zero. Follow the proceedings of the HTML Working Group and see for yourself. You can criticize Microsoft's involvement on various grounds, but nothing they've done has the effect of slowing down progress much. The Working Group is proceeding on a timetable toward Last Call set by the three co-chairs, only one of whom is employed by Microsoft (the other two are Apple and IBM). Microsoft has no more say in the W3C than any other member, and all four of its competitors in the browser market participate more actively in the HTMLWG (and WHATWG) than it does. They wouldn't let it get away with anything even if it tried, which it hasn't.
Standards work always appears slow. With vendor-specific stuff, they don't design it until right before they intend to implement it, and you don't hear about it until the implementation is done. So it sounds like it appears out of thin air. With standards, the design is usually done long before all browsers have the resources allocated to implement it, so it looks like it's taking much longer: you can see the design from day one, and there's a big gap between design and full implementation. Malice has nothing to do with it.
If they can't write specs in less than several years, why not divide html 5 into its core components and concentrate the work on one piece at a time?
Because the spec is written. Go read it yourself. The editor cut back on adding new features a few years ago when it was clear that his feature-writing was outstripping implementers' ability to implement the features. He routinely replies to requests for significant new features by saying he's waiting for browsers to implement what's in the spec now before he adds more. The editing right now is almost all just that, editing – hammering out minor flaws that people discover and report. (There are some exceptions, like WebSRT.)
In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.
What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big company's votes (so the neat technology they'd patented was "optional" or left out entirely) and the couple of small businesses or individuals who'd already got products running using the draft spec were ignored.
The W3C has a Patent Policy requiring that all its specifications be implementable royalty-free, so this is not an issue. No spec can be covered by any known patents at all unless those are irrevocably licensed royalty-free. I've heard this kind of bickering can suck up time at less enlightened standards organizations, though, which believe in unreasonable stuff like RAND (= let everyone on the standards committee rake in money by making sure some patent of theirs is required).
Your job is to write code, not to design a Sculpture to be admired throughout the ages. Designs are fluid, so is the code that implements them.
That's all very well, but when browsers change widely-used APIs, they break sites. Then users complain loudly and refuse to upgrade, because the old version works better than the new one for them if they use those sites. So all the browser implementers except Microsoft refuse to change behavior in ways that will break sites more than absolutely necessary, and Microsoft only pulls off such behavior changes because of its compatibility modes. Which means that once the APIs are widely used, they don't change, period. Browsers will not break content.
There have been tons of minor changes like that, sure. HTML5 initially mandated PUT and DELETE be supported on HTML5 forms, which HTML4 didn't allow, but implementers are not likely to spend time on it without clear advantages that accrue to the average user or web author. You can still do PUT and DELETE from HTML via XMLHttpRequest, in clients that support script (the overwhelming majority), so it's not like it's a huge loss.
._. The original plan of WhatWG was to stabilize in 2022 . Yes. 12 years from now. But the devil is in the details and I am not 100% up to date on the W3C details. I get the feeling that the W3C is trying to be the Debian of standardization organizations though. Slow and stable.
The WHATWG never planned to stabilize in 2022. Ian Hickson, the editor of HTML5, predicted that it would take until 2022 to reach the equivalent of W3C Recommendation status: where every single feature has at least two independent implementations, plus a full test suite (which would require hundreds of thousands if not millions of tests for such a large spec). The spec becomes basically stable at the Candidate Recommendation stage, which Ian originally predicted to be 2012 (and that looks to be plausible so far). You can read more about this in the WHATWG FAQ.
First off, Canvas is fucking redundant and never should have been created in the first place. SVG has existed since 2001. Canvas is a crappy JavaScript-only version of Canvas with half the features stripped out. There's no reason to use canvas in the first place - just use SVG. Most browsers support it and even if they don't there's good plugin support. And it's an actual released standard.
SVG is a declarative vector graphics format, while canvas is an immediate-mode 2D graphics API for JavaScript. Using SVG for a dynamic web application is kind of ridiculous – something as simple as ctx.fillRect(x, y, w, h) to draw a rectangle would require several lines of DOM methods.
HTML5 video is completely fucking useless, because:
1. You can't stream video. (No, not a file, I mean live video.)
You can stream live video just fine, if the format and browser supports it. I've heard reports of people getting this to work just fine with Ogg. This isn't the big use-case anyway, though.
2. You can't full screen HTML 5 video. (The spec forbids this as a security flaw.)
You can full-screen HTML5 video in Firefox 3.6 and later (IIRC) via the context menu. There's no standard JavaScript API to full-screen the video yet, because no one has worked out the security implications in enough detail yet: you'd have to design it carefully so that malicious scripts can't take over the screen (maybe just by copying what Flash does). WebKit has an experimental API in that regard. Plus, you can always just make the <video> tag fill the screen and let the user hit F11 if they want – YouTube does this, and it works pretty well (although it's not ideal).
3. There is no standard format, leaving you to encode an unknown number of versions. Hell, even if you stick with just H.264, you still need to encode to multiple profiles if you want to support everything.
HTML5 video is not yet usable as the only video format anyway, since you have to support IE
4. You can't seek in videos in anything remotely near a reliable manner. You know how you can link to a certain time in a Youtube video? Not possible in HTML5.
It's perfectly possible. YouTube has some JavaScript that will automatically seek the Flash video based on the fragment, and they could do exactly the same for HTML5 video. Seeking is as simple as setting video.currentTime. YouTube already uses this attribute to make its custom seek bar work.
5. You can't switch to lower/higher-bandwidth versions while the video is playing.
Of course you can. Just record currentTime, change the src, and then set the new currentTime. This is all trivial from JavaScript, much easier for a typical web developer than trying to communicate with Flash.
The HTML5 spec as is stands today is useless. The features it does offer above HTML4 already exist and are handled better via existing specs or plugins. Pretty much anything that isn't canvas or video isn't implemented anywhere, making the features entirely useless instead of done better elsewhere.
HTML5 is a vast spec that includes a huge number of improvements and refinements. The HTML5 parsing algorithm, for instance, will make a lot of weird websites work exactly the same across browsers when formerly they all behaved a bit differently – it's enabled by default in Firefox 4, and experimentally available for WebKit. This and many other clarifications are giving each new browser release more opportunity to be consistent with other browsers.
Canvas, video, and audio are not yet as reliable, widely available, or full-featured as their plugin-based equivalents, but they're suitable at least as fallbacks where the plugins aren't available (iOS, sometimes Linux). SVG and MathML embe
>To replicate, cut and paste this into your URL bar:
>data:text/html,
>Then type one or two letters in the password field (not more) and try to submit.
Chrome 6.0.472.63 works
Opera 10.62-6438 fails
Firefox 3.6.10 fails
(All on Linux x86-64
You're not getting what's I was testing. Opera prints the password in cleartext when you do what I described, no other browser does. Firefox 4 nightlies print an unhelpful error message (unhelpful because I provided no title attribute on the input element, for brevity, otherwise it would be helpful), and everything else just submits the form, but nothing else prints the password.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5.
I quite deliberately said that Firefox 4 will be the first good implementation of HTML5 form enhancements. I wrote HTML5 form support for MediaWiki, but disabled it – partly because of an inexcusably bad WebKit bug, but also because Opera's support is just cruddy. The UI is terrible – red-bordered boxes that only appear when you try to submit the form, not when you actually do the invalid input.
And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext, so <input type=password pattern=....> to require passwords of at least four characters is a non-starter. I reported the bug to Opera around the time 10.00 was beta, and it's still not fixed in 10.60. To replicate, cut and paste this into your URL bar:
Why does it have to be implemented before it can become a finalized specification?
Because before it's implemented, it's just some words on a web page, and no one has actually tried it. Implementers inevitably spot parts that are vague, or too complicated or expensive or slow to implement, only when they actually try to implement it. Also, implementing it will mean it gets the regular security and UI review that all new browser features get, which will result in more feedback. And finally, you get almost no feedback from regular authors or users until it's shipping in at least beta versions of browsers. This is why no W3C spec can be declared finished without two interoperable implementations.
Another way of looking at it is that you could try speccing everything first, then implementing it. But it means that you miss a lot of things and wind up putting out a bad standard. Instead, web standards are usually developed in tandem with implementations, and are open to change as long as it's feasible if new information comes to light. They're only really set in stone when so much content depends on particular behavior that browsers can't change it without breaking websites – barring that, they can always be improved. Even Recommendations aren't final in practice, because they can be superseded by later versions. HTML 4.01 is a recommendation, but HTML5 contradicts it in many places, and takes precedence.
It's probably the "need" for paper and in-vivo meetings.
If you didn't need them, standards would fly instead of committee members.
HTML5 uses no in-person meetings. The HTML Working Group charter at the W3C even says "This group primarily conducts its technical work on a Public mailing list". Everything is done through a combination of the mailing list and Bugzilla, with some IRC discussion thrown in on the side. There are teleconferences, but nothing important is done there, and the editor doesn't attend them – the decision policy requires that all requests for changes be made through Bugzilla and other web interfaces. There's also no paper involved anywhere.
Really, almost nothing at the W3C is in-person. People contribute from all over the world, both W3C members and non-members. In-person meetings are impractical. This is particularly true for HTML5 – the WHATWG version of the spec is really managed exactly like an open-source project with a benevolent dictator, not at all like a conventional spec.
The reason specs progress slowly is because it takes lots of programmer-hours to implement them correctly. Most of HTML5 is fully specced and just awaiting implementation. Programming is expensive work.
When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.
This is why the WHATWG – the body that originally developed HTML5, and which still develops a version in parallel to the W3C – abandoned the idea of rating the stability of the spec as a whole. The WHATWG spec version (which is edited by the same person as the W3C spec, contains everything the W3C spec does plus more, and has useful JavaScript annotations like a feedback form) is perpetually labeled "Draft Standard", and per-section annotations in the margins tell you the implementation status of each feature.
The W3C Process, on the other hand, requires everything to proceed through the Candidate Recommendation stage, where it gets feature-frozen, and therefore becomes rapidly obsolete. It's quite backwards, but doesn't seem likely to change soon. So for sanity's sake, you can just ignore the W3C and follow the WHATWG instead.
(I really doubt that Philippe Le Hegaret actually said anything like what he was quoted as saying in TFA, though. It doesn't match what I've heard from him or the W3C before – no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback. It sounds more like an anti-HTML5 smear piece. Paul Krill has apparently written other anti-HTML5 articles.)
But the real question is why does it take so long to come up with these standards? HTML5 started by WHATWG back in 2004. CSS3 has been around since 2005. Just get them finalized already. Don't whinge about browsers not fully supporting the standards if you don't give them a fixed document to work towards.
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
So it's mostly a matter of limited programming time, nothing mysterious.
Which is why I added the caveat. In reality, you don't really have to restart the system even on a fatal flaw. Init isn't terribly insecure with the old version if the exploit was a vulnerability in sockets for instance; whereas if there was a socket bug in libc and you were running Apache, sure as hell you want to reload Apache with the fresh version.
Your average sysadmin (or even your above-average sysadmin) is going to be pretty hard-pressed to figure out which services a given library vulnerability "really" affects. Without really understanding the code, it's hard to say. The only safe thing is to restart everything.
Libc is easy. Install the update while the app is running. The old version of the library stays alive in ram as long as processes still have handles to it which is no big whoop unless its an exploit that you really must clean up immediately.
If application X uses libc, the next time its started it'll get the new version of the library and happily co-exist with the old one, nay?
Sure. You just have to restart everything using libc, like for instance:
Notice how it's deleted, so presumably init is using an old libc version that was upgraded. Hope it doesn't contain vulnerabilities! If you can't tolerate rebooting your system, you probably can't tolerate restarting every single process, either. And if you can leave unpatched libc running in all these daemons, why not an unpatched kernel too?
All that said, it would be nice if distros could apply patches live automatically for the benefit of regular users, who ignore the "please reboot" message (or even just take hours to notice it). At least it will reduce vulnerabilities. But this can't fairly be billed as a way to avoid rebooting altogether, which is how it's often presented: "No More Need To Reboot". Wrong.
Hardware failure and hardware upgrade can be handled by VMWare FT assuming your app fits into 1 vCPU (this will probably be relaxed in the future but I have heard nothing about even experimental support for vSMP yet).
Okay, this is a legitimate point. If you use clustering or something, then you might be immune to most hardware failures. Even if you use regular hardware, if you have enough hardware redundancy you're only subject to CPU/RAM/motherboard failure, and most of that's hot-swappable for upgrades with the right OS. Not perfect, but say planned downtime once per five or ten years for an OS upgrade, probably acceptable. It's possible.
But it's much more common these days to just design systems you can reboot nodes without downtime, so I don't see hot-patching allowing "No More Need To Reboot" except in a very small minority of setups. Better to think of it as a tool to increase security by letting you deploy patches faster.
The difference between mainframes and regular PCs is that one mainframe's role is taken on by many PCs. With proper setup, you should have redundancy between the PCs, so you can reboot them one at a time without affecting service.
This is often impossible considering the workload. This is why you see 32 core servers with many gigabytes of ram.
I run a 16-core server with 16 GB of RAM. I'm going to deploy a second one soon with automatic failover to eliminate downtime for routine administration. It's perfectly possible for the vast majority of services. I'll grant that there will always be exceptions, probably for the most part custom-written applications that weren't designed for redundancy.
You can't do that if you only have only one mainframe.
Yes you can, and that's the whole point.
You can't reboot one mainframe at a time without affecting service, if you only have one mainframe. Rebooting it's going to leave you with no running servers, and it's hard to provide service then.:) Instead, you're forced to design the system so you never have to reboot it, which is much harder.
When your kernel needs an update, you use ksplice. If libc needs an update, you hot-patch libc in the same way. "But there's no way to do that!", you say? Actually, there is--it's just proprietary. The place I work at has implemented userspace hotpatching on linux for several architectures.
And for hardware failures? Or critical service restarts? Or a bug causing an OS crash? Put it this way: you can either try to minimize the downtime of each server, or make it so that the downtime of one server doesn't affect service. The former is much more complicated and error-prone, and is still going to fail sometimes, so you need the latter regardless if you're really aiming for reliability. And the latter makes the former unnecessary.
Well let's be honest here, the risk/gain isn't exactly working out for stable enterprise uses.
Exactly backwards.
This feature replicates what mainframes have been doing for years. Specifically because businesses want zero downtime, if possible.
The difference between mainframes and regular PCs is that one mainframe's role is taken on by many PCs. With proper setup, you should have redundancy between the PCs, so you can reboot them one at a time without affecting service. You can't do that if you only have only one mainframe. Even with two, you can only do it if you can afford to double your load. So this might be needed for mainframes, but not for PCs.
Okay, so even suppose this is perfectly reliable. Let's say I'm running a high-availability server and can't stand any downtime. Now when my kernel needs an update, I don't have to reboot, great!
So what about when, say, libc needs an update? As long as programs are still using it, they'll be using the outdated version. Am I supposed to restart all programs using libc? That will cause downtime just like a reboot (although maybe a bit less).
Or what about when I need a hardware upgrade? Or there's a hardware failure? Or what happens when that critical application requiring 100% uptime needs a security fix? What am I supposed to do then?
There's no way to avoid outages completely for any given machine. PC OSes aren't meant for that. Any high-availability service needs to be able to tolerate the failure of any one machine. So why not just reboot it when you get a critical update to the kernel or major system library? That way you know that the machine reboots properly, too.
My suspicion is that this is mainly meant to lure in Linux users who want the "please reboot your computer" messages to go away. But those messages are misleading. If you Ksplice and never reboot, your libraries will remain outdated indefinitely – it's not secure. Distros would do better to ask for reboots only on security updates, and to do so for libraries and running applications (if they can't be easily restarted) as well as kernel updates.
That means there's libre-free software and a service provided by a non-distro company which is, for selected distros, gratis-free. For now.
I like your Latin-based distinction of "free" better than the free-as-in-beer v.s. free-as-in-speech method.
I'll have to remember it for the next time I give a speech on OSS at the Roman senate.
I'm not sure if you're referring to US history, but the "protection" that unions got only came later. The original unions only had the threat to walk off as "protection".
I said that. In those cases, I don't object to unions much or at all. However, that's not the status quo today, contrary to what you implied. Unions today are protected by the government far beyond what free trade would give them.
Why should corporations exist with "legal protection" if unions should not? What do you think patents are? What do you think copyrights are? What do you think contract law is all about? You live in some Cato Foundation fantasy world where you honestly believe you could survive for 2 days without "legal protection". You probably also believe that your "success" and "wealth" exist only due to your hard work and talent and the government only holds you back, right?
I'm not a laissez-faire capitalist, nor a libertarian. I'm in favor of government regulation to help the poor and achieve other social goals. I also agree that unions were important historically in improving the standard of living in America, if only because of the lack of other options. However, I don't think most unions are good for society at large today, and I think government protection of unions should end.
I'm not about to get into an argument about why I think all this, particularly not on Slashdot. I only posted to object to your implication that collective bargaining as we know it today is the result of a free market. It's the regulations prohibiting the employer from firing union members that require them to negotiate. Otherwise most unions would be destroyed pretty quickly.
What you want is a return to the days when all the power is in the hands of the employers. It sounds like you're some free-market religious fanatic or something, and I'm not sure why I even took the time to respond. When you can find a single case in human history when a "free market" existed and made anything better for anyone, then you can be taken seriously.
You were the one who first mentioned free markets, not me. You were trying to paint today's teachers' unions as the product of a free market (or at least that's how I read "Should they not be allowed to negotiate their best pay package? Don't you trust free markets?" in your post). I never said I supported totally free markets, and I don't.
Hate to play devil's advocate here, but cartels are not (usually) legally protected, and legally the board of a company can hire whatever CEO they want. Unions, however, are legally protected entities. It would be a bit nuts to fire all the teachers and hire new people, but the law is there because some employers would do it if they could.
It's not nuts at all: it's the only way to break a union. It's how Reagan destroyed the air traffic controller union, for example. I also recall reading years ago that when a Canadian Wal-Mart's employees tried to unionize, Wal-Mart couldn't fire or otherwise penalize them under local law, so instead they simply shut down that store.
I'd go so far as to say that firing people is the standard response to a strike, where it's legal. The employer is hurt, but the union members are hurt far more – so the next batch knows to never try that again. If firing people for job actions were legal (they're deliberately not doing their job . ..), most unions probably wouldn't exist.
By the way, don't you believe teachers should have the right to collectively bargain? Should they not be allowed to negotiate their best pay package? Don't you trust free markets?
Sure I do. In a free market, an employer would be able to fire anyone immediately as soon as they so much as joined a union, let alone took any job action. But doing that is generally illegal, and that's the sole reason most unions can exist today. If a union can exist without legal protection (as was often the case in the 1800s and early 1900s), I'm not necessarily against it.
Slashdot Mirror
What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state?
Zero. Follow the proceedings of the HTML Working Group and see for yourself. You can criticize Microsoft's involvement on various grounds, but nothing they've done has the effect of slowing down progress much. The Working Group is proceeding on a timetable toward Last Call set by the three co-chairs, only one of whom is employed by Microsoft (the other two are Apple and IBM). Microsoft has no more say in the W3C than any other member, and all four of its competitors in the browser market participate more actively in the HTMLWG (and WHATWG) than it does. They wouldn't let it get away with anything even if it tried, which it hasn't.
Standards work always appears slow. With vendor-specific stuff, they don't design it until right before they intend to implement it, and you don't hear about it until the implementation is done. So it sounds like it appears out of thin air. With standards, the design is usually done long before all browsers have the resources allocated to implement it, so it looks like it's taking much longer: you can see the design from day one, and there's a big gap between design and full implementation. Malice has nothing to do with it.
If they can't write specs in less than several years, why not divide html 5 into its core components and concentrate the work on one piece at a time?
Because the spec is written. Go read it yourself. The editor cut back on adding new features a few years ago when it was clear that his feature-writing was outstripping implementers' ability to implement the features. He routinely replies to requests for significant new features by saying he's waiting for browsers to implement what's in the spec now before he adds more. The editing right now is almost all just that, editing – hammering out minor flaws that people discover and report. (There are some exceptions, like WebSRT.)
In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.
What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big company's votes (so the neat technology they'd patented was "optional" or left out entirely) and the couple of small businesses or individuals who'd already got products running using the draft spec were ignored.
The W3C has a Patent Policy requiring that all its specifications be implementable royalty-free, so this is not an issue. No spec can be covered by any known patents at all unless those are irrevocably licensed royalty-free. I've heard this kind of bickering can suck up time at less enlightened standards organizations, though, which believe in unreasonable stuff like RAND (= let everyone on the standards committee rake in money by making sure some patent of theirs is required).
Your job is to write code, not to design a Sculpture to be admired throughout the ages. Designs are fluid, so is the code that implements them.
That's all very well, but when browsers change widely-used APIs, they break sites. Then users complain loudly and refuse to upgrade, because the old version works better than the new one for them if they use those sites. So all the browser implementers except Microsoft refuse to change behavior in ways that will break sites more than absolutely necessary, and Microsoft only pulls off such behavior changes because of its compatibility modes. Which means that once the APIs are widely used, they don't change, period. Browsers will not break content.
The spec hasn't changed all that much since then (although it has changed)
It seems that recently there has been a change on the set of methods that are supported by an HTML5 form, where PUT and DELETE are no longer supported.
Big Mistake.
There have been tons of minor changes like that, sure. HTML5 initially mandated PUT and DELETE be supported on HTML5 forms, which HTML4 didn't allow, but implementers are not likely to spend time on it without clear advantages that accrue to the average user or web author. You can still do PUT and DELETE from HTML via XMLHttpRequest, in clients that support script (the overwhelming majority), so it's not like it's a huge loss.
._. The original plan of WhatWG was to stabilize in 2022 . Yes. 12 years from now. But the devil is in the details and I am not 100% up to date on the W3C details. I get the feeling that the W3C is trying to be the Debian of standardization organizations though. Slow and stable.
The WHATWG never planned to stabilize in 2022. Ian Hickson, the editor of HTML5, predicted that it would take until 2022 to reach the equivalent of W3C Recommendation status: where every single feature has at least two independent implementations, plus a full test suite (which would require hundreds of thousands if not millions of tests for such a large spec). The spec becomes basically stable at the Candidate Recommendation stage, which Ian originally predicted to be 2012 (and that looks to be plausible so far). You can read more about this in the WHATWG FAQ.
First off, Canvas is fucking redundant and never should have been created in the first place. SVG has existed since 2001. Canvas is a crappy JavaScript-only version of Canvas with half the features stripped out. There's no reason to use canvas in the first place - just use SVG. Most browsers support it and even if they don't there's good plugin support. And it's an actual released standard.
SVG is a declarative vector graphics format, while canvas is an immediate-mode 2D graphics API for JavaScript. Using SVG for a dynamic web application is kind of ridiculous – something as simple as ctx.fillRect(x, y, w, h) to draw a rectangle would require several lines of DOM methods.
HTML5 video is completely fucking useless, because:
1. You can't stream video. (No, not a file, I mean live video.)
You can stream live video just fine, if the format and browser supports it. I've heard reports of people getting this to work just fine with Ogg. This isn't the big use-case anyway, though.
2. You can't full screen HTML 5 video. (The spec forbids this as a security flaw.)
You can full-screen HTML5 video in Firefox 3.6 and later (IIRC) via the context menu. There's no standard JavaScript API to full-screen the video yet, because no one has worked out the security implications in enough detail yet: you'd have to design it carefully so that malicious scripts can't take over the screen (maybe just by copying what Flash does). WebKit has an experimental API in that regard. Plus, you can always just make the <video> tag fill the screen and let the user hit F11 if they want – YouTube does this, and it works pretty well (although it's not ideal).
3. There is no standard format, leaving you to encode an unknown number of versions. Hell, even if you stick with just H.264, you still need to encode to multiple profiles if you want to support everything.
HTML5 video is not yet usable as the only video format anyway, since you have to support IE
4. You can't seek in videos in anything remotely near a reliable manner. You know how you can link to a certain time in a Youtube video? Not possible in HTML5.
It's perfectly possible. YouTube has some JavaScript that will automatically seek the Flash video based on the fragment, and they could do exactly the same for HTML5 video. Seeking is as simple as setting video.currentTime. YouTube already uses this attribute to make its custom seek bar work.
5. You can't switch to lower/higher-bandwidth versions while the video is playing.
Of course you can. Just record currentTime, change the src, and then set the new currentTime. This is all trivial from JavaScript, much easier for a typical web developer than trying to communicate with Flash.
The HTML5 spec as is stands today is useless. The features it does offer above HTML4 already exist and are handled better via existing specs or plugins. Pretty much anything that isn't canvas or video isn't implemented anywhere, making the features entirely useless instead of done better elsewhere.
HTML5 is a vast spec that includes a huge number of improvements and refinements. The HTML5 parsing algorithm, for instance, will make a lot of weird websites work exactly the same across browsers when formerly they all behaved a bit differently – it's enabled by default in Firefox 4, and experimentally available for WebKit. This and many other clarifications are giving each new browser release more opportunity to be consistent with other browsers.
Canvas, video, and audio are not yet as reliable, widely available, or full-featured as their plugin-based equivalents, but they're suitable at least as fallbacks where the plugins aren't available (iOS, sometimes Linux). SVG and MathML embe
>To replicate, cut and paste this into your URL bar: >data:text/html, >Then type one or two letters in the password field (not more) and try to submit.
Chrome 6.0.472.63 works Opera 10.62-6438 fails Firefox 3.6.10 fails
(All on Linux x86-64
You're not getting what's I was testing. Opera prints the password in cleartext when you do what I described, no other browser does. Firefox 4 nightlies print an unhelpful error message (unhelpful because I provided no title attribute on the input element, for brevity, otherwise it would be helpful), and everything else just submits the form, but nothing else prints the password.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5.
I quite deliberately said that Firefox 4 will be the first good implementation of HTML5 form enhancements. I wrote HTML5 form support for MediaWiki, but disabled it – partly because of an inexcusably bad WebKit bug, but also because Opera's support is just cruddy. The UI is terrible – red-bordered boxes that only appear when you try to submit the form, not when you actually do the invalid input.
And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext, so <input type=password pattern=....> to require passwords of at least four characters is a non-starter. I reported the bug to Opera around the time 10.00 was beta, and it's still not fixed in 10.60. To replicate, cut and paste this into your URL bar:
data:text/html,<form><input name=foo type=password pattern=...><input type=submit></form>
Then type one or two letters in the password field (not more) and try to submit. So, Opera's great and all, but its implementation of this stinks.
Why does it have to be implemented before it can become a finalized specification?
Because before it's implemented, it's just some words on a web page, and no one has actually tried it. Implementers inevitably spot parts that are vague, or too complicated or expensive or slow to implement, only when they actually try to implement it. Also, implementing it will mean it gets the regular security and UI review that all new browser features get, which will result in more feedback. And finally, you get almost no feedback from regular authors or users until it's shipping in at least beta versions of browsers. This is why no W3C spec can be declared finished without two interoperable implementations.
Another way of looking at it is that you could try speccing everything first, then implementing it. But it means that you miss a lot of things and wind up putting out a bad standard. Instead, web standards are usually developed in tandem with implementations, and are open to change as long as it's feasible if new information comes to light. They're only really set in stone when so much content depends on particular behavior that browsers can't change it without breaking websites – barring that, they can always be improved. Even Recommendations aren't final in practice, because they can be superseded by later versions. HTML 4.01 is a recommendation, but HTML5 contradicts it in many places, and takes precedence.
It's probably the "need" for paper and in-vivo meetings.
If you didn't need them, standards would fly instead of committee members.
HTML5 uses no in-person meetings. The HTML Working Group charter at the W3C even says "This group primarily conducts its technical work on a Public mailing list". Everything is done through a combination of the mailing list and Bugzilla, with some IRC discussion thrown in on the side. There are teleconferences, but nothing important is done there, and the editor doesn't attend them – the decision policy requires that all requests for changes be made through Bugzilla and other web interfaces. There's also no paper involved anywhere.
Really, almost nothing at the W3C is in-person. People contribute from all over the world, both W3C members and non-members. In-person meetings are impractical. This is particularly true for HTML5 – the WHATWG version of the spec is really managed exactly like an open-source project with a benevolent dictator, not at all like a conventional spec.
The reason specs progress slowly is because it takes lots of programmer-hours to implement them correctly. Most of HTML5 is fully specced and just awaiting implementation. Programming is expensive work.
When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.
This is why the WHATWG – the body that originally developed HTML5, and which still develops a version in parallel to the W3C – abandoned the idea of rating the stability of the spec as a whole. The WHATWG spec version (which is edited by the same person as the W3C spec, contains everything the W3C spec does plus more, and has useful JavaScript annotations like a feedback form) is perpetually labeled "Draft Standard", and per-section annotations in the margins tell you the implementation status of each feature.
The W3C Process, on the other hand, requires everything to proceed through the Candidate Recommendation stage, where it gets feature-frozen, and therefore becomes rapidly obsolete. It's quite backwards, but doesn't seem likely to change soon. So for sanity's sake, you can just ignore the W3C and follow the WHATWG instead.
(I really doubt that Philippe Le Hegaret actually said anything like what he was quoted as saying in TFA, though. It doesn't match what I've heard from him or the W3C before – no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback. It sounds more like an anti-HTML5 smear piece. Paul Krill has apparently written other anti-HTML5 articles.)
But the real question is why does it take so long to come up with these standards? HTML5 started by WHATWG back in 2004. CSS3 has been around since 2005. Just get them finalized already. Don't whinge about browsers not fully supporting the standards if you don't give them a fixed document to work towards.
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
So it's mostly a matter of limited programming time, nothing mysterious.
"Hope it doesn't contain vulnerabilities!"
Which is why I added the caveat. In reality, you don't really have to restart the system even on a fatal flaw. Init isn't terribly insecure with the old version if the exploit was a vulnerability in sockets for instance; whereas if there was a socket bug in libc and you were running Apache, sure as hell you want to reload Apache with the fresh version.
Your average sysadmin (or even your above-average sysadmin) is going to be pretty hard-pressed to figure out which services a given library vulnerability "really" affects. Without really understanding the code, it's hard to say. The only safe thing is to restart everything.
Libc is easy. Install the update while the app is running. The old version of the library stays alive in ram as long as processes still have handles to it which is no big whoop unless its an exploit that you really must clean up immediately. If application X uses libc, the next time its started it'll get the new version of the library and happily co-exist with the old one, nay?
Sure. You just have to restart everything using libc, like for instance:
$ sudo lsof -c init 2>/dev/null | grep libc /lib/tls/i686/cmov/libc-2.11.1.so
init 1 root DEL REG 251,0 269825
Notice how it's deleted, so presumably init is using an old libc version that was upgraded. Hope it doesn't contain vulnerabilities! If you can't tolerate rebooting your system, you probably can't tolerate restarting every single process, either. And if you can leave unpatched libc running in all these daemons, why not an unpatched kernel too?
All that said, it would be nice if distros could apply patches live automatically for the benefit of regular users, who ignore the "please reboot" message (or even just take hours to notice it). At least it will reduce vulnerabilities. But this can't fairly be billed as a way to avoid rebooting altogether, which is how it's often presented: "No More Need To Reboot". Wrong.
Hardware failure and hardware upgrade can be handled by VMWare FT assuming your app fits into 1 vCPU (this will probably be relaxed in the future but I have heard nothing about even experimental support for vSMP yet).
Okay, this is a legitimate point. If you use clustering or something, then you might be immune to most hardware failures. Even if you use regular hardware, if you have enough hardware redundancy you're only subject to CPU/RAM/motherboard failure, and most of that's hot-swappable for upgrades with the right OS. Not perfect, but say planned downtime once per five or ten years for an OS upgrade, probably acceptable. It's possible.
But it's much more common these days to just design systems you can reboot nodes without downtime, so I don't see hot-patching allowing "No More Need To Reboot" except in a very small minority of setups. Better to think of it as a tool to increase security by letting you deploy patches faster.
The difference between mainframes and regular PCs is that one mainframe's role is taken on by many PCs. With proper setup, you should have redundancy between the PCs, so you can reboot them one at a time without affecting service.
This is often impossible considering the workload. This is why you see 32 core servers with many gigabytes of ram.
I run a 16-core server with 16 GB of RAM. I'm going to deploy a second one soon with automatic failover to eliminate downtime for routine administration. It's perfectly possible for the vast majority of services. I'll grant that there will always be exceptions, probably for the most part custom-written applications that weren't designed for redundancy.
You can't do that if you only have only one mainframe.
Yes you can, and that's the whole point.
You can't reboot one mainframe at a time without affecting service, if you only have one mainframe. Rebooting it's going to leave you with no running servers, and it's hard to provide service then. :) Instead, you're forced to design the system so you never have to reboot it, which is much harder.
When your kernel needs an update, you use ksplice. If libc needs an update, you hot-patch libc in the same way. "But there's no way to do that!", you say? Actually, there is--it's just proprietary. The place I work at has implemented userspace hotpatching on linux for several architectures.
And for hardware failures? Or critical service restarts? Or a bug causing an OS crash? Put it this way: you can either try to minimize the downtime of each server, or make it so that the downtime of one server doesn't affect service. The former is much more complicated and error-prone, and is still going to fail sometimes, so you need the latter regardless if you're really aiming for reliability. And the latter makes the former unnecessary.
Well let's be honest here, the risk/gain isn't exactly working out for stable enterprise uses.
Exactly backwards.
This feature replicates what mainframes have been doing for years. Specifically because businesses want zero downtime, if possible.
The difference between mainframes and regular PCs is that one mainframe's role is taken on by many PCs. With proper setup, you should have redundancy between the PCs, so you can reboot them one at a time without affecting service. You can't do that if you only have only one mainframe. Even with two, you can only do it if you can afford to double your load. So this might be needed for mainframes, but not for PCs.
Okay, so even suppose this is perfectly reliable. Let's say I'm running a high-availability server and can't stand any downtime. Now when my kernel needs an update, I don't have to reboot, great!
So what about when, say, libc needs an update? As long as programs are still using it, they'll be using the outdated version. Am I supposed to restart all programs using libc? That will cause downtime just like a reboot (although maybe a bit less).
Or what about when I need a hardware upgrade? Or there's a hardware failure? Or what happens when that critical application requiring 100% uptime needs a security fix? What am I supposed to do then?
There's no way to avoid outages completely for any given machine. PC OSes aren't meant for that. Any high-availability service needs to be able to tolerate the failure of any one machine. So why not just reboot it when you get a critical update to the kernel or major system library? That way you know that the machine reboots properly, too.
My suspicion is that this is mainly meant to lure in Linux users who want the "please reboot your computer" messages to go away. But those messages are misleading. If you Ksplice and never reboot, your libraries will remain outdated indefinitely – it's not secure. Distros would do better to ask for reboots only on security updates, and to do so for libraries and running applications (if they can't be easily restarted) as well as kernel updates.
That means there's libre-free software and a service provided by a non-distro company which is, for selected distros, gratis-free. For now.
I like your Latin-based distinction of "free" better than the free-as-in-beer v.s. free-as-in-speech method. I'll have to remember it for the next time I give a speech on OSS at the Roman senate.
Libre is French. The Latin equivalent is liber.
I'm not sure if you're referring to US history, but the "protection" that unions got only came later. The original unions only had the threat to walk off as "protection".
I said that. In those cases, I don't object to unions much or at all. However, that's not the status quo today, contrary to what you implied. Unions today are protected by the government far beyond what free trade would give them.
Why should corporations exist with "legal protection" if unions should not? What do you think patents are? What do you think copyrights are? What do you think contract law is all about? You live in some Cato Foundation fantasy world where you honestly believe you could survive for 2 days without "legal protection". You probably also believe that your "success" and "wealth" exist only due to your hard work and talent and the government only holds you back, right?
I'm not a laissez-faire capitalist, nor a libertarian. I'm in favor of government regulation to help the poor and achieve other social goals. I also agree that unions were important historically in improving the standard of living in America, if only because of the lack of other options. However, I don't think most unions are good for society at large today, and I think government protection of unions should end.
I'm not about to get into an argument about why I think all this, particularly not on Slashdot. I only posted to object to your implication that collective bargaining as we know it today is the result of a free market. It's the regulations prohibiting the employer from firing union members that require them to negotiate. Otherwise most unions would be destroyed pretty quickly.
What you want is a return to the days when all the power is in the hands of the employers. It sounds like you're some free-market religious fanatic or something, and I'm not sure why I even took the time to respond. When you can find a single case in human history when a "free market" existed and made anything better for anyone, then you can be taken seriously.
You were the one who first mentioned free markets, not me. You were trying to paint today's teachers' unions as the product of a free market (or at least that's how I read "Should they not be allowed to negotiate their best pay package? Don't you trust free markets?" in your post). I never said I supported totally free markets, and I don't.
Hate to play devil's advocate here, but cartels are not (usually) legally protected, and legally the board of a company can hire whatever CEO they want. Unions, however, are legally protected entities. It would be a bit nuts to fire all the teachers and hire new people, but the law is there because some employers would do it if they could.
It's not nuts at all: it's the only way to break a union. It's how Reagan destroyed the air traffic controller union, for example. I also recall reading years ago that when a Canadian Wal-Mart's employees tried to unionize, Wal-Mart couldn't fire or otherwise penalize them under local law, so instead they simply shut down that store.
I'd go so far as to say that firing people is the standard response to a strike, where it's legal. The employer is hurt, but the union members are hurt far more – so the next batch knows to never try that again. If firing people for job actions were legal (they're deliberately not doing their job . . .), most unions probably wouldn't exist.
By the way, don't you believe teachers should have the right to collectively bargain? Should they not be allowed to negotiate their best pay package? Don't you trust free markets?
Sure I do. In a free market, an employer would be able to fire anyone immediately as soon as they so much as joined a union, let alone took any job action. But doing that is generally illegal, and that's the sole reason most unions can exist today. If a union can exist without legal protection (as was often the case in the 1800s and early 1900s), I'm not necessarily against it.
You can retest several times if you plan ahead.
But then all your grades get sent to the school, right?