Slashdot Mirror

To be fair, MozHacks included a link to a non-Javascript method after the article. To learn how to implement HTML5, webcoders should read the HTML5 spec anyway, not some semiofficial blog by someone at Mozilla that may not even be an HTML5 expert.

TRWTF is
* that video fallback is broken in Firefox and
* Mozilla's dismissive handling of the issue:
#487398 <object>-element within <video>-element is not ignored is about fallback content being played even when the surrounding <video> has loaded. In other words, when you wrap an OGG object into an OGG video, the object starts playing in the background and you hear its sound. Mozilla inexplicably marked this RESOLVED INVALID after Anne commented that the HTML5 spec is a bit loose on what is required at that point. Not rendering fallback content when the wrapper can be rendered isn't strictly enforced by the spec, more likely by oversight than choice. It only says

User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browser informing them of how to access the video contents. (HTML5 spec draft)

So apparently "should not show" can be interpreted as "but may play the audio if they feel like it", and if something can be interpreted as conformant with a loose reading of a spec that makes it "not a bug" for Mozilla.

I will still use the standard method of scriptless fallback chains, because I value accessibility and I respect people's choice to disable javascript. Please do HTML5 a favor and bug Mozilla about acknowledging a bug as a bug and debugging it.

You can read the specification here. The spec provides for and browser vendors are implement the autoplay attribute.

And draw with <canvas>.

Flash Player comes with the equivalent of a library for tweening Bezier curves over time. And the Flash editor (3 figures USD) comes with an editor for objects made of Bezier curves. The HTML 5 draft's canvas element currently has neither, to the best of my knowledge.

"Separate from the Wikimedia grant we also just started funding work to port Theora to some DSPs, so that we will be able to do off-CPU decode/yuv2rbg/scale on some devices."

Does Theora even have a hardware accelerated codec? With the rise of netbooks, green computing, and the Ion Netbook solution it is pretty obvious that hardware assisted video decoding is where the market is headed. So even if Theora gets "good enough" (which reading TFA may be awhile yet) if Theora doesn't come up with a good hardware assisted decoder and quick I'm guessing it will be a non starter.

The in development 1.1 "Thusnelda" encoder is squarely in "good enough" territory now. Mozilla is funding codec improvements and hardware acceleration work on Theora. From one of Mike Shaver's posts to the whatwg mailing list:

That's indeed a big part of what we've been funding, and the results
have been great already. I'd like to demonstate them to you, because
I suspect that you'd be a better-armed advocate within Google for
unencumbered video if you could see what it's really capable of now.
(Separate from the Wikimedia grant we also just started funding work
to port Theora to some DSPs, so that we will be able to do off-CPU
decode/yuv2rbg/scale on some devices.)

My mistake then. I claim that Chris DiBona is being deliberately misleading then. Here's the relevant quote from a posting he wrote:

Google makes the FFmpeg libraries available as part of Chromium under the LGPL 2.1, with no patent license attached.

You're misinterpreting the LGPL. The language quoted by /. above says

if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.

Now, imagine it this way:

Let A be some 3d party software covered by patents that is unrelated to FFMpeg. Let B be Chrome. Let C be FFMpeg. Google got a patent for A. The patent is unrelated to FFMpeg.

The LGPL says that if you cannot distribute C without patent royalties, then you cannot distribute C at all.

People are making one of two mistakes regarding this issue. They're either assuming that the patent Google has cover C (this is thanks to Slashdot's shitty summary that makes it sound like this, but Google points out quite clearly this is not the case) or they think the LGPL says that if any patent restricts the distribution of A contained in B, then you distribute C if it is contained in B. This is a poor interpretation of the above-quoted LGPL clause.

The last link I provided (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020035.html) explains better than I the stance Google has taken. I think this stance is correct.

Disclaimer: I am merely a law school graduate. I have not taken the bar yet. I am not a lawyer. I am not your lawyer. This is not legal advice.

You're misinterpreting the LGPL. The language quoted by /. above says

if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.

Now, imagine it this way:

Let A be some 3d party software covered by patents that is unrelated to FFMpeg. Let B be Chrome. Let C be FFMpeg. Google got a patent for A. The patent is unrelated to FFMpeg.

The LGPL says that if you cannot distribute C without patent royalties, then you cannot distribute C at all.

People are making one of two mistakes regarding this issue. They're either assuming that the patent Google has cover C (this is thanks to Slashdot's shitty summary that makes it sound like this, but Google points out quite clearly this is not the case) or they think the LGPL says that if any patent restricts the distribution of A contained in B, then you distribute C if it is contained in B. This is a poor interpretation of the above-quoted LGPL clause.

The last link I provided (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020035.html) explains better than I the stance Google has taken. I think this stance is correct.

Disclaimer: I am merely a law school graduate. I have not taken the bar yet. I am not a lawyer. I am not your lawyer. This is not legal advice.

Seems you're right. The confusion is my own. The thread didn't start with the email you linked to, it started here:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019994.html

When I read it a few days ago, I understood it as "loading native codecs" rather than loading a binary library of FFMPEG. After that I paid little heed to the thread as these A\V codec discussions get a bit heated. :-/

Oddly, I have Chrome 2.0.172.30, but no FFMPEG license in sight. Oddly, the license for the V8 assembler is listed as Copyright (c) 1994-2006 Sun Microsystems Inc. WTF?

Yes, I saw what you wrote and may I quote your trollish behaviour?

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020215.html

I question the relevance to HTML5 of someone from a completely
proprietary software company closely questioning a direct competitor
on their conformance to the GPL.

Yea, you're not a troll at all.

Nope, you've got it wrong. Chrome includes ffmpeg.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020035.html

You can read multi-page version if that what you was saying about.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html

try reading the spec: http://www.whatwg.org/specs/web-apps/current-work/#video

If open video means a widget that site owners have no control over, like Quicktime video embedding, then commercial site operators aren't going to be too keen on it.

HTML 5 Video states that a page can ask the user agent to show a built-in control widget (by providing a controls attribute) or hide it and provide its own widget that controls the video player through its DOM (by omitting the controls attribute).

By your logic, web standards should be changed to match the behavior of Microsoft IE.

Yep. HTML5 blesses and standardizes a lot of the compatibility workarounds everyone is already using.

By your logic, web standards should be changed to match the behavior of Microsoft IE.

Yep. HTML5 blesses and standardizes a lot of the compatibility workarounds everyone is already using.

No idea whether Safari on the iPhone already supports the video tag, but it sure is open, cross-platform and simple.

This is hinted at in the HTML5 spec. Vladimir Vukicevic has already created a 3D Firefox Add-on that extends <canvas> with an OpenGL ES context; and others are working on a javascript library that aims to make make Canvas 3D development easier.

yes, a db that is under a quarter of a MB. It is vastly superior (with regards to interoperability, speed, flexibility, and scaling) to the poorly documented, brain-damaged Mork history format they where using, and it much more powerful and useful than flat html file that was used for bookmarks.

In fairness, the real utility of the database will be enabling client-side storage for web apps that utilize HTML 5 features (since the client-side storage stuff is mandated by HTML 5 -- this is the same API that Palm's new phone is going to use). In addition to basic key-value pair storage, there will be fully realized structured/relational data storage.

yes, a db that is under a quarter of a MB. It is vastly superior (with regards to interoperability, speed, flexibility, and scaling) to the poorly documented, brain-damaged Mork history format they where using, and it much more powerful and useful than flat html file that was used for bookmarks.

In fairness, the real utility of the database will be enabling client-side storage for web apps that utilize HTML 5 features (since the client-side storage stuff is mandated by HTML 5 -- this is the same API that Palm's new phone is going to use). In addition to basic key-value pair storage, there will be fully realized structured/relational data storage.

Implementing cooperative multithreading in a browser just throws up all kinds of red flags.

I can't go into too much detail about this particular implementation, but I agree with what you're saying. Cooperative multitasking is not a scalable solution in web browsers. In fact, sorting is one of those issues generally best left to the database. The circumstances of this particular situation required that the code be written in this fashion, even though it would not have been my first choice.

The takeaway from this should not be that the technology was improperly implemented, but rather that there are situations under which significant processing is being pushed to the browser today. Thus future browsers must consider supporting such heavy processing, especially as web applications grow in complexity and sophistication. Today we have a choice on this issue. What of tomorrow when the browser pulls large quantities of data for offline use? Without access to the server during these periods, the client must operate self-sufficiently.

True multi-threading is a very real part of upcoming browsers. It's already in Google Gears and will show up in browsers as the Web Workers specification is finalized. So we're covered for the direction the market is going with web apps. :-)

It has been discussed recently on HTML5 WG.

Browsers' UI for HTTP authentication so far is absolutely awful, and there's no standard mechanism for logging out.

Although HTTP Digest authentication does offer slighly better security than cookies, HTTP authentication is helpless against any MITM attacks.

There have been proposals to give HTML forms front-end for HTTP authentication, but they haven't gone anywhere, since there is little to gain (same UI as cookie-based auth, negligible security improvement) and backwards compatibility is poor.

Google has announced its Google native client, which enables x86 native code to be run securely inside a browser.

Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it. An instruction set that was finally starting to loosen its grip as the industry worked toward more abstract solutions.

With Java applets already dead and buried

And with good reason!!! Plugin engines do not provide a very smooth browsing experience. You must wait for them to download and activate before you can start using the widget. Meanwhile, Javascript is designed for execution as the page is loading.

The heavyweight JVM was probably the worst offender, but look at Flash for another example of an engine that most developers would rather eliminate. While it was hip to create entire websites out of Flash for a while, the platform was very user-unfriendly and almost died out. Thanks to infighting over video standards however, Flash was able to hold on as a video delivery platform and even gained a margin of success as a web-gaming platform. (About the only area where Java Applets really shined back when they were popular.)

My personal opinion* is that this is a step in the wrong direction. Javascript engines are getting good. Damn good. I'd like to see more R&D poured into these engines and the underlying technologies rather than reinventing ActiveX and Java. If researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it. But I don't run a browser to become a part of a compute farm. I run a browser to access web information and applications. Very little of which is compute-intensive enough to require a new execution engine over a more advanced set of APIs.

* ...and 50 cents won't buy you a cup of coffee anymore, so take it for what it's worth.

** As an aside, C/C++ is an incredibly complex build environment. Why anyone would want to continue subjecting developers to the angst of compiler differences, makefiles, configure scripts, and other irritants is beyond me. As is typical with such platforms, I can't even get the examples running on my machine. The run.py script dies with an "Invalid Argument" on line 42 and the nacl-gcc compiler fails with syntax errors a-plenty. I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?

If you read the link or any of the numerous pages about web worker threads, you'd understand.

Might I suggest open standards so anyone who cares can implement their own?

You mean like this one? Yes, good idea. ;)

What API? Tags do not have APIs, and the <object> can be extended with "params"s

If you think about it, you answered your own question. The API to a plug-in that renders an <object> element is the interpretation of its <param> elements. But each video playback plug-in needs a different set of <param> elements to define a particular behavior. The <video> element specifies the behavior more strongly than <object> and <param> ever did.

This "video" tag looks a lot like an old Netscape HTML "extension" to me.

If it's in the HTML 5 draft, can it really be called an extension?

Enter: HTML 5.

5. If you're worried about this, just wait until you guys see the Storage APIs in HTML5. You're going to freak.

Firefox follows cookie policies for DOM Storage as well. Whatever preferences you set for cookies, it will be applied to DOM storage as well.

1. Flash supports local shared objects, not "cookies". Cookies are submitted back to the server. Shared Objects are bits of storage available to movies from a particular domain. They must explicitly submit the information back to cause an information leak.

2. Using shared objects to save browsing history is dumb. If you wanted to do evil Flash tracking, use a unique id that you can look up on the server side.

3. You can delete and/or restrict the contents from inside a Flash movie. Use the right-click menu in Flash to access settings and set the storage level to 0 bytes. That will wipe everything out. It will also force Flash to prompt you every time it wishes to save something to disk.

4. This was added in Flash 6, which was released back in 2002. Since then, it has been used by a variety of Flash applications. Many of which you probably use every day. From saving your progress in your favorite Flash game to remembering the volume settings in that Youtube video, Local Shared Objects have been shown to be a valuable feature.

5. If you're worried about this, just wait until you guys see the Storage APIs in HTML5. You're going to freak.

A bit more information...

1 - Flash can store, by default, 100 kb of any datatype in the SharedObject class. They could easily emulate a browser cookie cache. This is effective because 99% of people don't even have a clue the cookies are there, and no adware-sniffing program I've seen yet even looks at sharedobject data. This is a VERY effective way of sneaking a cookie (and/or other data) into a permanent spot on a user's machine.

2 - There is no point here: The sharedobject interface can easily store a cookie, and even if it didn't, it could probably safely store or backup more information based on the ignorance of the average user.

3 - This is true. You can delete sharedobjects as long as you have a move clip visible you can click on. However, many sites have hidden flash elements that cannot be seen or clicked on. These sites can set data.

4 - Sure they are useful, but the can and are misued. Best to be informed. Fortunately, you can find the storedobject data in "C:\Documents and Settings\\Application Data\Macromedia\Flash Player\#SharedObjects". Each site that stores data is found in a subdirectory bearing that site's name. You can pick and choose which sharedobjects to keep.

5 - Indeed.

1. Flash supports local shared objects, not "cookies". Cookies are submitted back to the server. Shared Objects are bits of storage available to movies from a particular domain. They must explicitly submit the information back to cause an information leak.

2. Using shared objects to save browsing history is dumb. If you wanted to do evil Flash tracking, use a unique id that you can look up on the server side.

3. You can delete and/or restrict the contents from inside a Flash movie. Use the right-click menu in Flash to access settings and set the storage level to 0 bytes. That will wipe everything out. It will also force Flash to prompt you every time it wishes to save something to disk.

4. This was added in Flash 6, which was released back in 2002. Since then, it has been used by a variety of Flash applications. Many of which you probably use every day. From saving your progress in your favorite Flash game to remembering the volume settings in that Youtube video, Local Shared Objects have been shown to be a valuable feature.

5. If you're worried about this, just wait until you guys see the Storage APIs in HTML5. You're going to freak.

In its most primitive form, it basically involves taking an iframe, figuring out where the link part/form part is, and then tricking the user into clicking it.

This seems very clunky and hacky, but I suspect that the speakers at the OWASP talk have gotten this technique to work well enough so that it is both transparent and highly effective. Can you think of a website that needs you to click, say, a play button in order to view content? That click may be hijacked through an invisible iframe to execute an action on another website.

The good folks at Google recently raised this topic on the WHATWG mailing list, you can read more about it here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html

The zdnet article is pretty vague, but I think it refers to the problem detailed in this message from Michal Zalewski:

"A malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as 'delete all items', 'click to add Bob as a friend', etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it."

Disabling JavaScript won't prevent the attack. It will break some mitigations, though!

They did get the memo. It was dated 1997. After that, they got the other memo. You know, the one that said thanks to modern standards we can make complex applications in the browser now? Didn't you get the memo?

Perhaps it is time the browser can 'render' video natively as well, with standard codecs.

Take a look at the HTM5 video tag, which is already supported in Safari and coming to Firefox.

What 'standards' to support, and are supportable, is the catch.

Right. The state of various codecs is pretty sad right now.

That is: Apple is likely to just support whatever QuickTime does, but QuickTime will only include formats that Apple has licensed. They haven't had their lawyers look over the open formats (Theora, Vorbis, Dirac) to make sure that there's no risk of some submarine patent -- of some company just waiting for one of these formats to get popular, so they can start trolling.

On the other hand, Firefox really can't afford to license anything, so they'll probably only support open formats. Hopefully, they'll make it easy to plug things in, and on Medibuntu, I hope to see proper x264 support.

But the net result is, with the video tag as is, you're still going to be forcing people to install some sort of plugin, unless Apple does something really surprising.

I got the impression that Ogg Theora was removed as the default codec because certain parties were arguing for the inclusion of DRM in the HTML 5 standard. Was that an incorrect assumption?

http://www.whatwg.org/specs/web-apps/current-work/#video0

My point was exactly that pushing for a standard which does not exist would be similar to the non-standard tags pushed through in the period when NS4.7 & IE4 where the main browsers.

From the above link:

"we need a codec that is known to not require per-unit or per-distributor licensing"

No problem.

"compatible with the open source development model, that is of sufficient quality as to be usable,"

Quality is disputable, of course. But what other open sourced alternative is there at the moment?

"and that is not an additional submarine patent risk for large companies."

This is not a problem, as far as I understand matters. Ogg Theora allows everyone to use the patented methods used, right? No other format I know of does. It would be lovely if there were "open" alternatives.

Sadly, some of the MPEG video patent holders have big voices in the W3C and demanded that there be no baseline. (What a shock: they don't want to have have a more level compatibility playing field because they don't want to have to compete on quality and price).

If you were to read and understand the discussion rather than spewing bullshit you'd realise that everyone involved, Apple and Nokia included, want to arrive at a common baseline format for the HTML 5 specification. The industry-standard MPEG suite of codecs was considered unacceptable by representatives of Mozilla and Opera due to the licensing costs, while representatives from Apple, Nokia and Microsoft considered Ogg unacceptable due to the risk they would be opening themselves to by adopting these new codecs. Until a solution is found that addresses the concerns of both groups there is absolutely no point in including a baseline in the specification as at least one group would simply ignore the requirement.

What W3C specification exists for a Javascript drawing API?

HTML5. Which is itself a W3C dump of the ongoing work over at the WHATWG. Here's the specific W3C text on Canvas:

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies such as XBL.

When authors use the canvas element, they should also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element's fallback content.

In interactive visual media, if the canvas element is with script, the canvas element represents an embedded element with a dynamically created image.

In non-interactive, static, visual media, if the canvas element has been previously painted on (e.g. if the page was viewed in an interactive visual medium and is now being printed, or if some script that ran during the page layout process painted on the element), then the canvas element represents embedded content with the current image and size. Otherwise, the element represents its fallback content instead.

In non-visual media, and in visual media if the canvas element is without script, the canvas element represents its fallback content instead.

The work over at the WHATWG is a collaboration between Mozilla, Opera, and Apple. Microsoft was offered to contribute, but they declined. (Though a few Microsofties have been seen on the mailing lists as of late.)

That's quite a rant on programming for a Javascript form field validator.

The right answer to this problem was probably WebForms, which added support to HTML for basic form validation. WebForms provided for simple regular expressions in HTML forms like
this one for a credit card number:

<input type="text" pattern="[0-9]{16}" name="cc" />

If the field didn't match the pattern, the browser would tell the user, in a standardized way, probably at keystroke time. The browser would also do things like prevent alpha entries in a numeric field, something that IBM green screen terminals were doing in the 1970s. (You could even program a keypunch machine to do that.) It's kind of lame that HTML forms never had any built in input validation.

For some reason, the WebForms proposal made very slow progress and never caught on.

Quote: "For some reason, the WebForms proposal made very slow progress and never caught on."
Reason: Probably because it's reasonably easy to roll your own with a JavaScript function sending arguments to a validation function. There's an example at http://www.w3schools.com/jsref/jsref_onkeydown.asp that refuses numbers in text field. If you want to validate on the server side as well, you could write code to both validate the form results and generate the JavaScript validation function from the same rule set.

That's quite a rant on programming for a Javascript form field validator.

The right answer to this problem was probably WebForms, which added support to HTML for basic form validation. WebForms provided for simple regular expressions in HTML forms like this one for a credit card number:
<input type="text" pattern="[0-9]{16}" name="cc" />

If the field didn't match the pattern, the browser would tell the user, in a standardized way, probably at keystroke time. The browser would also do things like prevent alpha entries in a numeric field, something that IBM green screen terminals were doing in the 1970s. (You could even program a keypunch machine to do that.) It's kind of lame that HTML forms never had any built in input validation.

For some reason, the WebForms proposal made very slow progress and never caught on.

Just keep in mind, there's nothing stopping web developers from using straight HTML, CSS, JPG, PNG and GIF for basic animation.

The key word there is BASIC. Complex animations, applications, and games are where Flash excels. Web Browsers did not provide sufficient facilities until recently. And only then because the browser makers got fed up with the W3C's stance that HTML did not need to be updated, and ended up doing an end run around their process. In result, most web browsers (except IE, surprise, surprise) support APIs for complex animations. They are also adding support for long term storage, sophisticated networking, predictable parsing, and other features that will greatly aid web developers.

This minor coup has not gone unnoticed by the W3C. In order to maintain the coherency of their organization, they went ahead and accepted HTML 5 as a working draft. The specification is getting top priority and is being handled in an open manner that is most unlike the W3C's business as usual. In other words, a win for both browser and web app developers. :-)

You're probably thinking of XHTML 2.0, though img is still present there. HTML 5 came about when Apple, Mozilla, and Opera decided they didn't like where XHTML was going. They started the WHATWG, and made a draft of HTML 5. The W3C has since restarted development on HTML, and it looks like XHTML 2.0 may be dead before it's even started. HTML 5 can be formulated as XHTML anyway (XHTML 5), where we will finally dump the whole DOCTYPE pointlessness and make it clear that it's the internet media type and not the DOCTYPE that makes an XHTML document.

browser based rich-text editing is a huge mess. [...] we need a standard desperately, and we needed it years ago.

See: HTML 5.

It will be implemented by all major browsers (yes this includes IE; with the help of a compatibility library, if necessary).

native support for video (in the form of the tag and a Free codec such as Ogg Theora). The latter is actually already written, but Mozilla isn't going live with it yet because of patent fears from certain large companies.

I thought that was because it just wasn't finished in time for Firefox 3.0, hence why they're implementing it in Firefox 3.1 instead. If Mozilla are worried about submarine patents, they've kept that very quiet. Apple have been quite vocal of their worries about submarine patents in Theora, while Nokia seem to have objected without knowing quite what it is they're objecting to, but Mozilla supported making it a part of the HTML 5 spec.

A game like Battlezone is actually well served by 2D vector drawing. All you have to do is do a quick rasterization of the vertexes (x2d = x3d/z3d, y2d = y3d/z3d), then pass the result to the 2D vector routines. Rendering engine done.

While I can't view the site right now, COMET support sounds like one of the more interesting feature requirements. The only thing that I don't get is (and maybe this is explained on the currently-slashdotted site), isn't this solved by Server-Sent DOM Events? That effectively provides a smooth and scalable form of COMET support. Of course, only Opera supports it at the moment, so maybe that's the problem...

This is a Javascript port of the Processing Visualization Language and a first step towards Javascript being a rival to Flash for online graphics content.

Last I checked, HTML 5's working doc says that forms aren't going to change over html4.

They are going to change. It's not yet decided exactly how they will change – the HTML WG has Web Forms 2 (an extension of HTML4's forms), and the Forms WG is working on some rough ideas for trying to fit XForms into HTML5, and there is a joint Task Force that is meant to be working things out between the groups but hasn't actually managed to achieve anything yet. (None of the major browser developers has indicated much interest in implementing XForms, whereas Opera has already released an implementation of WF2 and there is some ongoing work to implement parts in Firefox and Safari, so the momentum is currently in that direction.)

allow forms to validate without having to have [div]s that do nothing but hold hidden fields because [input] is a presentation tag and therefore must be within a text-carrying tag

Web Forms 2 says "input elements of type hidden may be placed anywhere (both in inline contexts and block contexts)", which sounds like it satisfies your concern (and has the advantage of working in all existing web browsers, unlike a new <state> element).

can we PLEASE have them back so that we can use them for tabular data (like item names, prices, descriptions, etc)?

<table> has never been deprecated, and HTML5 still permits it. (Tables used for layout are not allowed, although that's impossible for an automatic validator to detect). There are already CSS properties that can replace cellpadding ('padding') and cellspacing ('border-spacing').

would it really kill the documentation writers to say what something has been deprecated BY?

It seems spec writers usually think that kind of thing should be described in tutorials or other documents, not in the specification. The HTML5 spec is far harder to read than HTML4 (because it's far more detailed, to fix the differences between implementations caused by HTML4's vagueness), so it really needs that kind of user-oriented documentation. The differences document gives a brief mention of what should be used instead of some obsolete features, but it would be nice to have more detail and examples for people who want to move to HTML5.

I'm guessing this is Ian of WHATWG fame ;-)
http://forums.whatwg.org/index.php

alt="" is required in almost all cases, but there are indeed some specific cases where it can be omitted (basically for sites like flickr who have no idea what the images are).

See the part of the spec for more detail:

      http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded0.html#the-img

Most of HTML5 was actually done outside of the W3C.

However, to address your earlier point, one of the big things we're doing with HTML5 is we're going and specifying the bits that all the other specs avoided, like 'window', like 'setTimeout', like how to parse HTML in the face of errors, and so on, and saying exactly how they should work, based on how browsers do them now, so that we can get the browsers to converge on one interoperable set of behaviours.

I'm also working on the Acid tests, e.g. Acid2 and Acid3, to foster interoperability on the older specs. It's working pretty well so far.

http://ln.hixie.ch/
http://www.webstandards.org/action/acid3

So... HTML5 should actually help bring the browsers closer on the bits that weren't specified before, and the Acid tests are directly intended to do that with the bits that _were_ specified before. If you want to help out, please do -- see the links above for how to help with Acid3, and the links below for how to help with HTML5:

http://blog.whatwg.org/w3c-restarts-html-effort