Slashdot Mirror

There is a list of defined character entities for HTML here: http://www.w3.org/TR/REC-html40/sgml/entities.html [w3.org] Unfortunately, Slashdot does not seem to accommodate them very well

The problem may also be with perl. Unicode support is not always as advertized. I've had to write code in c to remove some of the more exotic unicode characters that perl choked on.

This one.

There is a list of defined character entities for HTML here: http://www.w3.org/TR/REC-html40/sgml/entities.html Unfortunately, Slashdot does not seem to accommodate them very well. I tried μ for Greek mu, and that did not work at all.

And yes, source matters. That way, if there's any ambiguity in the spec, or question about how to implement something, I can look at what appears to be a compliant implementation and see how it's done.

There is no such W3C user agent either - Amaya is a less than compliant testbed, not a reference implementation. We are welcome to look at the source for Firefox and for WebKit, find out that they've implemented things differently,... and be none the wiser.

This being said, if you ever have to consult the code then there is a problem with the specification and an erratum needs to be issued. OSS is fraught with "consult the code" fallbacks to poor documentation which hamper reusability as people end up making assumptions beyond what might have been intended.

On top of all of this, Flash is patent-encumbered -- HTML itself is not.

What exactly does this mean? HTML may be encumbered by patents on certain proecesses, but W3C contributors have agreed on royalty-free licensing; anyone else might point out a feature in HTML they think is covered by one of their patents (e.g. BT). Similarly, Adobe has agreed to royalty-free licensing on anything they may have a patent for in the Flash spec.

In general, the W3C's policy is to possibly accept licensing on RAND terms.

Adobe doesn't seem to release everything (DRM in particular)

DRM's inherent broken-ness means its implementation cannot be released. Maybe if Flash dies providers will move to forcing you to download a DRM binary native plug-in, or at least try and fail to issue obfuscated Javascript (don't imagine for a moment that content providers will "oh well, never mind!" and remove DRM). Either way, the core Flash platform is open - the extensions which people interested in openness wouldn't want to use anyway are not.

It really does seem like this is the reason Gnash and others haven't caught up

I would say that it is lack of interest. There is one fairly good working implementation which works on the majority of desktops, and one slower implementation (Mac) which works on most of the rest. It is hard to monetise the development of an alternative Flash player, whereas it is easy to do so with web browsers via sponsored searches (everyone), proprietary extensions (esp. Microsoft) and (ultimately - esp. Apple) influencing the standard.

Many alternative Flash authoring tools exist and are used, so the spec is clearly readable.

Of course, we could also consider the fact that the Flash specs and Flash player are produced by exactly one company, while HTML is a collaborative process.

Agreed. It's just not nearly as "collaborative" right now as the W3C's adherents would have you believe.

With all valid criticism that exists against W3C standards' flaws, you can't seriously compare any of them with an inconsistent mess that is Flash.

Have you ever tried to browse the web using Amaya? I dare you to exclusively use Amaya as your browser for a 24 hour period.

Recently, Google announced Android 2.2, the next version of their Linux-based mobile operating system targeted at phones and PDAs, at Google I/O 2010. Developers praised the update, calling it and its features a welcome addition to the platform.

Android 2.2 will bring the phone operating system closer to parity with its competitors. With 2.2r4 out now and a projected final release date of Summer '10, Android 2.2 is coming fast.

But stepping back from all of the commotion, what exactly is Google offering with this update? What are these new features and who will benefit from them? There are plenty of questions about Android 2.2and here are the answers.

Five Alive

Probably the most important update for Android for its end-users is HTML5. This changes very little about the platform itself, but it shows that Google is investing in the technology. It also means that users will have a seamless Web experience.

These two things are important for the future success of Android as a viable mobile platform, though Google's implementation might prove problematic.

On live devices, users will have to install Android 2.2 in its entirety to gain HTML5 support. An entire operating system upgrade for a browser? Get real and update the browser on its owndon't make your users go through the trouble of updating and installing a fundamental update just for some HTML5 support, Google. If this is how you run your phone operating system, I'd hate to see what you expect of Chrome OS users.

And there's also the fact that HTML5 is not novel. Every other industry player has already been including HTML5 support; Apple has long been a proponent of this, including HTML5 support in the developmental Webkit as well Safari since 2007. You're welcome to the party, Google, but don't announce it like you're the one throwing it. You can make catchup, but it's still catchup.

Flash Forward

Oh, Flash. Google and Adobe are performing a very calculated industry sixty-nine because both Apple and Google want the mobile-cum-portable market and Adobe wants the video portion of both.

Apple is pushing the open HTML5 standard; Adobe is pissed at Apple. Google, with the old the-enemy-of-my-enemy-is-my-friend tactic, sees an opportunity and hooks up with Adobe. Sadly, revenge sex only seems clever at first.

The reality is that HTML5, being open and supported by hundreds of companies and standard bodies, will win in the end. Google and Adobe will look like assholes having lapped at such a bloated, poorly-coded, closed video platform that everyone else will zoom past using their browsers sans crashy plugin.

Who wins in the end? The entire industry, sharing in the HTML5 platform, and users, whose browsers don't crash or chew up excess cycles and memory. Sadly, though, not Android users, who are unwitting Adobe consumers.

Hotspotting et al

Android will also support hotspotting, or wifi sharing funneled into its 3G or 4G network, of up to eight other devices. I'm not sure if you've done any serious work on 3G yet, but it's slow.

The prospect of using one 3G account to support other Internet-hungry devices is like expecting a pygmy to carry weightlifters: backbreaking at best and otherwise i

RunRev CEO:

> It makes perfect sense to have a high quality, rapid application
> development system available for the iPhone and iPad.

We already have that with Xcode. It's the same rapid application development system that a physicist used in 1990 to create the World Wide Web. A non-programmer was able to create the fucking Web with these tools.

Yes, and one of those web co-creators did it inspired by the Hypercard ancestor of RunRev while the other is a RunRev user today. If it's good enough for them...

How will be the HTML5 standards organised

The HTML standard just says "play video here" just like the image tag just says "show picture here"

That's just not true - try here and here. While W3C doesn't mandate certain formats, they give everyone specs for some. Besides, all generally useful image compression formats are freely available to anyone without any restrictions (as "freely" as it can be with any software these days).

None of the above is true with video.

How will be the HTML5 standards organised

The HTML standard just says "play video here" just like the image tag just says "show picture here"

That's just not true - try here and here. While W3C doesn't mandate certain formats, they give everyone specs for some. Besides, all generally useful image compression formats are freely available to anyone without any restrictions (as "freely" as it can be with any software these days).

None of the above is true with video.

http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing first paragraph.

Moreover, you haven't demonstrated it to be false -- it may be difficult to implement. HTML5 evidently is not.

It is not necessary to prove any random assertion false in order for it to not be true. As you've said, there's more interest in implementing W3C specs than Adobe specs. Still, HTML5 has 0 complete implementations, and Flash has 1.

but that doesn't tell me whether or not they're allowed to read the specs yet

Oh dear; I was hoping that you'd take the hint and look it up. Effective May 1, 2008, Adobe removed the entire licensing agreement from the SWF and FLV/F4V specifications. These licensing restrictions had meant that no one could build software that would "play" SWF content.

[existence of non-Adobe incomplete Flash implementations] Citation needed.

You are lazy. I'll give you three which take about 15 seconds to find on the web, and you can do the job of finding three more (hint: I could find 5 with a cursory search, and the 6th is fairly obscure; I'd already heard of 5). The most well-known incomplete implementation is gnash. Scaleform is a commercial implementation with hardware acceleration. Swfdec is a fairly amateur implementation which has been mostly abandoned.

It actually looks like they just care about DRM, and would use HTML5 if it had the appropriate features.

It looks like good-enough DRM on a platform which actually exists and is successfully in production is one of the things they care about, yes.

Otherwise, your rant here makes no sense in light of the native iPhone client they have planned.

Is that an HTML5-based iPhone client? If not, what's your point?

For example, contrary to your claim, HTML5 does seem mostly implemented by the browsers I'm using. What's missing?

You really are lazy.

I never said that you claimed SVG supports local SQL storage

You're making arguments in response to the strawman argument that "SVG is a suitable replacement for HTML5". I was arguing for SVG in the context of canvas, it was obvious that I was arguing for SVG in the context of canvas, and you were being deliberately obtuse because it felt good to you to so boldly tear down an argument which hadn't been made.

To fake it on top of SVG (or HTML), you'd have to create separate elements behind the element that's moving, and be careful to disable all events on those so they can't be interacted with, and remove them when you're done

If only you could group elements in SVG. If only there were a generic way to add filters in SVG, and that could be used, say, to produce motion blur. The problem with SVG is that you have to read the spec instead of canvas where everyone can be lazy and reimplement his own way.

You can abuse anything, so the fact that a tool can be abused is no reason to avoid it. (I doubt I'd like an entire website in Canvas much better than an entire website in Flash.)

The whole point here being that canvas and most of its HTML5 friends are no better in principle than Flash, and (currently) are worse in practice.

I'm done with this thread. I appreciate that you're at least responding, but your lack of effort at researching most basic points is too frustrating. Thanks.

I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag

You're mistaken. HTML5 permits scripts "Where phrasing content is expected", and phrasing content is the stuff that goes in regular old paragraphs and so forth. HTML 4.01 (thus also XHTML 1.0) also says scripts "may appear any number of times in the HEAD or BODY of an HTML document."

In fact, it's a good idea to put scripts in the body if possible, ideally at the end of the page. That way they won't block page rendering. "Put Scripts at the Bottom" is Rule 6 of High Performance Web Sites, an O'Reilly book that's worth reading if you're interested in the subject.

You mean PUT and DELETE, which came in HTTP 1.1, significantly after HTTP 1.0 had defined all the methods as GET, HEAD and POST. These deal with the HTTP's resource model, which only deals with the URL notion of thing, not page-level interactivity which is what I think the OP was talking about.

Still, I do like HTTP 1.1 and one thing I like about REST is that it builds on what appear to me to be fundamental assertions about the HTTP model. You're not fighting the model, you're working with it. Still, I do wonder about how we got where we are today. Things are much harder than they need to be. Many of the things that help initially wind up hurting in the long run, and staying current is a constant battle.

You mean PUT and DELETE, which came in HTTP 1.1, significantly after HTTP 1.0 had defined all the methods as GET, HEAD and POST. These deal with the HTTP's resource model, which only deals with the URL notion of thing, not page-level interactivity which is what I think the OP was talking about.

Still, I do like HTTP 1.1 and one thing I like about REST is that it builds on what appear to me to be fundamental assertions about the HTTP model. You're not fighting the model, you're working with it. Still, I do wonder about how we got where we are today. Things are much harder than they need to be. Many of the things that help initially wind up hurting in the long run, and staying current is a constant battle.

Spurious, semantic definitions for ontological terms isn't something the web supports... Yet.

I agree, a link to something like this or or this all of which came from a quick google and give some basic info on mpeg 7 and mention some content ID tech would be helpful as a real source of *something* on this new standard (that I just heard of today)! Damn it editors, do your jobs!

What I think we need (please point out if someone's taken a good stab at this!) is some similar standard for describing a profile that has good use of public key encryption [...]

It's called FOAF+SSL :)

But Facebook allows you to have a list of friends, which you can use to grant granular access control to information.

A decentralized, RESTful solution exists as FOAF+SSL.

What would be awesome is if popular social sites like Facebook would generate a FOAF file/Web ID for their users automatically. Then users of those sites would also be part of the open social graph (you know, the World Wide Web) and they would still look at the ads on facebook when they update their statuses or whatever you do on facebook. Win-win.

Yours is the best post in this entire discussion.

The basic methods of communication need to be unencumbered (libre==free). This is a point that corporations will not understand, but it's surprising how much anti-freedom sentiment there is on Slashdot.

The predominant mode of communication in every era has been free (or, where it hasn't been, people have militated against that).

Quill - free to use, no royalties.
Movable type - you don't have to pay anything to use the letters of the Latin alphabet
Digital text (HTML) - you don't have to pay royalties to Tim Berners-Lee

So why should digital video be different? Pay to view, pay to create. It's not the price, it's the principal.

And if this is going to be a government-mandated standard, the government would be justified in taking the patent under eminent domain, compensating MPEG-LA, and allowing free use of the codec.

Open PDF-creating software is just finally getting started really it seems

Not sure what you mean here. I've been using Ghostscript for 14 years now. It has never had a problem generating PDF for me. You did say open, so I should note that the GPL version came out 7 years ago.

It may be because most programs for creating SVG graphics are using the .svg format instead of PDF

Hmm, I never thought about using SVG to replace PDF. I suppose you could. I'm not sure how well SVG implements paper-space.

They have different purposes. SVG was designed to produce vector graphics for the WWW. PDF was designed to produce a digital print job. PDF does make use of vector graphics. However, it was meant as an end-deliverable. That is why the ability to edit PDF is so limited.

It's still a complete mystery why HTML web standards stopped at "dynamic and moving text" instead of continuing onto "dynamic and moving verticies and lines"

That isn't much of a mystery. HTML stands for Hyper-TEXT markup language. The World Wide Web Consortium did create a web-standard to handle "dynamic and moving verticies and lines". They called it Scalable Vector Graphics

The video tag works very much like the img tag and thus can support multiple codecs.

That's the problem. video is a lot like good ol' object, which already determines video type based on the server or the MIME type in attribute type , and has the same wrong-MIME-related problems. From there (assuming the right MIME), the browser can just use a default player (as Chrome, Firefox, and even IE are sometimes smart enough to do). If said player can't figure out the exact codecs, then some combination of (a) the player isn't smart enough (really, exact-codec-hunting should be the player's job), (b) the video's some old, busted, or old and busted format, and (c) the video is not a video and no amount of "dieflashdie" will save its ass or the user's.

Other than some issues of how default object players would do the whole controls and poster thing, I remain unconvinced that video is not redundant or even bad. With the failed one-format effort, I keep blinking and thinking "Meet the new HTML" and so forth. *sighs* just hoped that we'd all drop img and any other format-specific object tags now that Acid2 checks some object images and stuff. Rant over, do continue.

While you may have to pay licensing costs to use any version of H.264, as I said, you are free to implement your own version (there is an open source version called x264).

Yes, and the licencing is the problem. Due to its licencing, H.264 is incompatible with the design goals of the web. See the W3C's patent policy:

http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing

Until H.264 can meet the W3C's licencing requirements for web standards, it will remain a poor technology choice for the web.

Apple's website used to have a page endorsing the W3C's patent policy at http://www.apple.com/about/w3c/. However, it appears to have been either moved or removed. Fortunately, it has been archived:

http://web.archive.org/web/20050407171053/www.apple.com/about/w3c/

I encourage Apple to stay true to that expressed commitment and support open, royalty-free media formats to contribute to building an open web.

With all this html5 love, where is the webcam broadcasting support?
What will all the live streaming sites do allow you to send your HD or almost HD UVC webcam out to the world?
http://dev.w3.org/html5/html-device/

There's no markup for hypertext in HTTP either.

The original pre-RFC HTTP states that a response is an HTML message.

After many years[1] there finally seems to be some signs of progress being made on features that will help websites make things safer for their users:

http://www.infoq.com/news/2010/01/HTML-5-Sandbox-IFrame
http://people.mozilla.org/~bsterne/content-security-policy/

[1] I actually tried to get people to do something about a similar problem 8 years ago:

http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html

For years the browser and W3 have been focusing on adding "gas pedals", and their idea of brakes was "just make sure none of the hundreds of gas pedals we created are pressed", which is a bit trickier in the real world.

If they had added working "brake pedals" back then, stuff like the MySpace worm might not have happened. And ads and other 3rd party content might be more easily secured.

declarative ... http://www.w3.org/TR/html5/forms.html

If referring to HTTP, referer is correct: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36

Apple has licensed those patents for free to anyone implementing the canvas tag as defined in the HTML5 standard.

Not quite. They've disclosed them, that's all. They only have to make a legally binding decision on whether to license them once HTML5 reaches Recommendation status. Ian Hickson, the editor, predicts that will be in 2022 or so. You can read the W3C Patent Policy yourself, and the list of disclosed patents. (Note "disclosed", not "licensed".)

Apple has licensed those patents for free to anyone implementing the canvas tag as defined in the HTML5 standard.

Not quite. They've disclosed them, that's all. They only have to make a legally binding decision on whether to license them once HTML5 reaches Recommendation status. Ian Hickson, the editor, predicts that will be in 2022 or so. You can read the W3C Patent Policy yourself, and the list of disclosed patents. (Note "disclosed", not "licensed".)

Check out http://dev.w3.org/html5/spec/Overview.html#the-article-element.

Canvas is not needed. You can create dynamic, animated graphics using the existing SVG standard.

But can you let the user do this creating? How would one write a photo editor or pixel art editor with SVG and no <canvas>? And how well does SVG handle sprite graphics in the style of 8-bit or 16-bit consoles?

And yes, html5 brings back the integration of style and content.

It was still there in transitional XHTML 1.

Html5 spec does not specify a single DOM structure

What exactly do you mean by this? If the HTML5 standard cites the DOM Events spec, then it supports addEventListener and the like. Microsoft made a specific choice not to support DOM Events, a W3C Recommendation published in 2000, and therefore not support HTML5.

but compared to the competing and now defunct standard xhtml2?

Which web browser ever supported XHTML 2 without using XSLT to turn it into XHTML 1? Heck, IE was even late to support XHTML 1.

O RLY?

http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fie.microsoft.com%2Ftestdrive%2FPerformance%2F01FlyingImages%2FDefault.html

Please, show me the standard a PERL CGI script adheres to

Gee, I dunno, maybe this one?

Flash pre-dates touchscreen devices [but] HTML5 does not, and most HTML5 content is going to be developed with touch-screen device capabilities in mind.

I don't follow. The onmouseover attribute was in HTML 4, which became a W3C Recommendation a decade ago.

http://dev.w3.org/2009/dap/contacts/

Unfortunately, your belief is wrong.

In fact, this is completely available via whatever language the DOM is implemented in. That's the entire point of the API.

A lot of the strong dislike about Microsoft products comes from these strategic decisions to lock in users, move them along to the next product, and prevent uptake of competing technologies. There's a lot here on /. about the persistent security issues that Windows suffers as Microsoft persists in choosing features and ease of use over security.

This whole issue persists and is so hot precisely because knowledgable people in the industry know that achieving compatibility and higher security is absolutely possible because it's done by other platforms like Open Office and BSD. It would never occur to me to claim that Office can't be made compatible, that Windows can't approach Unix in levels of security. Obviously that is possible because anything one program can do, another program can do. But then we read the Comes documents and the Halloween documents and see that these things are not only seen as "not worthwhile," but anathema to the Microsoft monopoly. They are deliberately avoided as a matter of policy - and that's what fuels the frustration - that Microsoft deliberately denies us this great boon because they see it as not in their best interest to do so, and then they field proxies who claim the things themselves are not even possible. That's rubbish.

Now in TFA it appears that some PFY on the Explorer team stumbled across w3.org and they're investigating what parts of this "web standards" nonsense might be worth embracing and extending. That's cool in a way, but most of us just assume that Microsoft will only keep the Explorer team alive (again!) long enough to reverse their market share losses and retain "ownership" of the web in the minds of common users. It's assumed that as soon as they've rebuilt their share they'll extend the standards in non-compliant ways to prevent compatibility by other browers - perhaps defending that turf with patents and patent licensing. This is what that whole HTML5 H264 vs Ogg Theora thing is about. Then once they've got their share built up again and the threat is extinguished, off to the slag heap once more with the Explorer team until their monopoly is threatened by innovation again, as their users languish in an abyss of incompatibilities and insecurities (again!). This is the song that never ends.

To come out in front of God and Everybody and say that compatibility and security are not possible is an outright lie, and I'm going to call out that lie ever time I see it. Maybe I could be nicer about it, but we've seen this nonsense for so long now that somebody who would claim to know something worth sharing should be mindful of it.

I must admit I'm not terribly familiar with the problem, but consider XAdES (XML Advanced Electronic Signatures) wikipedia) as requirement of signing your documents, because it seems a reasonably well backed standard if ETSI standardized it since 2002 and the EU encourages it for intergovernmental correspondence. It also seems future-proof if it has the signing algorithm as a parameter instead of predefined.
Also, the upcoming ODF 1.2 supports it (see ODF spec part 3 chapter 4).

No offense to you or your lady, but you should teach her safer browsing habits.

Blame the user. That's nice. Maybe you guys could just deliver this "Trusted Computing" platform Bill discovered in 2002.

FYI, if you don't use Windows you can click on the Internet with reckless abandon. We call it "browsing". It doesn't require reading every URL before you click it, worrying about whether your computer will become useless with each click. You should try it - it's fun. Since you're a Windows user, let me recommend to you the quite capable Knoppix.

This "safe browsing" you recommend is neither safe nor browsing. Hand-translating each URL beforehand, researching the domain name and ASN of the host IP, avoiding links to video, PDF documents or unusual image or audio formats before clicking the link isn't the process that was being described when Tim Berners-Lee invented the web client "WorldWideWeb" on NeXT. Even taking all that trouble isn't safe. Even a perfectly normal and accepted top-100 site can carry flash banner ads sold to the advertising syndicate by affiliates who sold those ads of unknown provenance to anonymous strangers. Since flash itself is a top-3 vector, and the link could go to literally anything, it's entirely possible to hose a windows box with a plain flash ad. And then there are the popovers, unders, and whatnot. To a Windows user who's read Microsoft guidance, browsing the Internet must seem like hugging a porcupine.

Mac users and Linux users don't have that problem, mostly because they don't take their Infosec guidance from a company so obviously ignorant of the topic.

With all the idiots fighting over the usual crap no one mentioned that it doesn't seem to support the canvas element. Microsoft has specifically tried to get the canvas element removed from the HTML5 spec. (as per here). And I know why Microsoft doesn't want the canvas element in there: because it's a direct threat to Silverlight.

The canvas API is no longer in the HTML5 spec anyway. The editor, Ian Hickson, has been in favor of a single monolithic specification, but other HTMLWG members have argued for various parts to be broken out into separate specs for a long time. In January, the HTMLWG overruled the editor and decided to split microdata into a separate spec. At the same time, in anticipation of further WG decisions in the same vein, the editor split the canvas 2D API into a separate spec too, which recently became a Working Draft.

This doesn't actually change the status of the canvas element: it's still part of a W3C Working Draft. They can implement it or not, just as much as if it was in the main HTML5 spec. Personally, I'm guessing they'll most likely implement it in a later IE9 release, but time will tell.

With all the idiots fighting over the usual crap no one mentioned that it doesn't seem to support the canvas element. Microsoft has specifically tried to get the canvas element removed from the HTML5 spec. (as per here). And I know why Microsoft doesn't want the canvas element in there: because it's a direct threat to Silverlight.

The canvas API is no longer in the HTML5 spec anyway. The editor, Ian Hickson, has been in favor of a single monolithic specification, but other HTMLWG members have argued for various parts to be broken out into separate specs for a long time. In January, the HTMLWG overruled the editor and decided to split microdata into a separate spec. At the same time, in anticipation of further WG decisions in the same vein, the editor split the canvas 2D API into a separate spec too, which recently became a Working Draft.

This doesn't actually change the status of the canvas element: it's still part of a W3C Working Draft. They can implement it or not, just as much as if it was in the main HTML5 spec. Personally, I'm guessing they'll most likely implement it in a later IE9 release, but time will tell.

It's the foundation of the fucking web!

The fee is capped now because the MPEG LA wants a monopoly for video on the web, and when they do, they can charge even more. It's extremely shortsighted to use H.264. It's incompatible with an open web: http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing

I wonder why using H.264 is such a big fuss in Opera and Firefox.

Because Opera and Firefox support an open web, which H.264 is 100% incompatible with: http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing

So apart from the "philosofic" approach

Yeah, who cares about open standards? Let's use Microsoft Markup Language (which only works in IE) for websites! You are also forgetting that when H.264 gets a monopoly, the MPEG LA can turn up the prices as much as they want and make shitloads of money.

H.264 is a closed and proprietary codec, and incompatible with the web: http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing

H.264 could never be part of any open web standard: http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing

Yes, instead of specifying the video in the 'src' attribute of the 'video' tag, you include one or more 'source' elements as children of 'video': http://dev.w3.org/html5/spec/Overview.html#the-source-element

It's of course H.264 but for different reasons - Windows 7 has build-in support for H.264, and Theora kind of lost the war already.

No, it isn't "of course" H.264. The author of the Technologizer article doesn't have a good understanding of the situation. From the article:

"The HTML5 situation remains murky: Video needs to be compressed using a particular codec, and Safari and Chrome support H.264 while Firefox and Opera use the open-source Ogg Theora standard. (That’s why YouTube’s experimental HTML5 version works only in the Apple and Google browsers–YouTube opted for H.264, not Theora.) Microsoft representatives told me that IE9 will be part of the H.264 camp."

Chrome supports both H.264 and Ogg Theora out of the box. Safari uses the QuickTime framework to play back video and so by extension it supports Ogg Theora if the XiphQT QuickTime components are installed. It seems unlikely to me that IE9 wouldn't use the DirectShow framework to play back video. If that's the case, then IE9 will also support Ogg Theora if the DirectShow filters are installed.

When it comes to HTML5 video today, Theora is the only video codec that can reach all four major browsers. I'd speculate that will continue to be the case with IE9.

If (perhaps when) Google releases VP8 as an open, royalty free codec there will be more royalty free options available. Ultimately, only royalty free formats are worth pursuing for the web. As you say, both Flash and H.264 are closed are proprietary and thus diametrically opposed to the open web.

What good is a standard embedded video tag if there is no standard coded with which to play with it?

What good is a standard embedded image tag if there is no standard coded with which to play with it? Notice that HTML's definition of the <img> element doesn't require support for any specific image format.

Well - maybe it's not a direct equivalent, but yes, HTML5 has the potential to keep such persistent cookies, as large as or larger than flash now uses.

http://completosec.wordpress.com/2010/02/07/html-5-persistent-offline-storage-as-a-risk-management-challenge/

Read the actual spec. It has an entire section on privacy. One quote:

If users attempt to protect their privacy by clearing cookies without also clearing data stored in the local storage area, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in all persistent storage features simultaneously.

The spec has to have a rock-solid security model required for implementors, and a good security test suite must be freely available. Without these, the database will turn out to be a major hack vector. With a great security model, we only have to worry about bugs. As it stands, the spec covers security very lightly.

The spec has these sections that mean people are at least thinking about security. I hope there are actual security experts involved:

• 4. Privacy
• 5. Authorization - especially:
• 5.3 Implementation risks
  "Thus, strictly following the origin model described in this specification is important for user security."

If you want this thing to succeed, you have an interest in the security model.