Slashdot Mirror

I'm not talking about 'web apps', I'm talking about mobile phone apps that do not require server access to function.

http://diveintohtml5.org/offline.html

* lets you access hardware (microphone, camera, gps, accelerometer)
> Not all of them, quite yet (geolocation yes, camera .. probably in the near future)
  > http://www.w3.org/TR/2010/WD-media-capture-api-20100928/ - Camera API - Google have said it will arrive in future Android versions
  > http://diveintohtml5.org/geolocation.html

* lets you manipulate a client-side database
  > http://diveintohtml5.org/storage.html - WebSQL

* lets you establish a socket connection to a server
  > websockets, ajax calls :)

I'm not talking about 'web apps', I'm talking about mobile phone apps that do not require server access to function.

http://diveintohtml5.org/offline.html

* lets you access hardware (microphone, camera, gps, accelerometer)
> Not all of them, quite yet (geolocation yes, camera .. probably in the near future)
  > http://www.w3.org/TR/2010/WD-media-capture-api-20100928/ - Camera API - Google have said it will arrive in future Android versions
  > http://diveintohtml5.org/geolocation.html

* lets you manipulate a client-side database
  > http://diveintohtml5.org/storage.html - WebSQL

* lets you establish a socket connection to a server
  > websockets, ajax calls :)

I'm not talking about 'web apps', I'm talking about mobile phone apps that do not require server access to function.

http://diveintohtml5.org/offline.html

* lets you access hardware (microphone, camera, gps, accelerometer)
> Not all of them, quite yet (geolocation yes, camera .. probably in the near future)
  > http://www.w3.org/TR/2010/WD-media-capture-api-20100928/ - Camera API - Google have said it will arrive in future Android versions
  > http://diveintohtml5.org/geolocation.html

* lets you manipulate a client-side database
  > http://diveintohtml5.org/storage.html - WebSQL

* lets you establish a socket connection to a server
  > websockets, ajax calls :)

Actually, HTML5* does solve most of the list of issues you mention.

Just have a look at this page:
http://diveintohtml5.org/forms.html

For certain environments, like public websites, you might want to add a javascript-file which does the same for old browsers, but this isn't a shortcoming of HTML/JS/CSS specifically.

I've never looked into this, but I'm pretty sure you can't use OpenGL on your old Atari either. As the OpenGL-specifications didn't exists when the Atari was created.

* HTML5 and other specifications which people all seem to lump together to call "HTML5"

Actually, HTML5 is kind of a revolt against the ideas of XHTML.

XHTML specifies if their is a single mistake on the XML you should stop rendering and only display a warning, this is not acceptable for (read: useful to) the user.

So maybe XML is technically better, but HTML is more useable in practise.

The reason we are now getting all these new specs the W3C is because W3C wanted XML-syntax for HTML and all these 'innovations' got delayed.

Have a look at the longer story:

http://diveintohtml5.org/past.html#timeline

And why HTML, XHTML, XML, MIME is such a clusterfuck ...

http://diveintohtml5.org/past.html

Will Web Workers mitigate the multithreading issue?

The GP did only say "effectively" so perhaps they were referring to the fact that they have been licensed royalty-free, as noted here:
http://diveintohtml5.org/video.html#vp8

Quoting the linked page, it says: "In 2010, Google acquired On2 and published the video codec specification and a sample encoder and decoder as open source. As part of this, Google also "opened" all the patents that On2 had filed on VP8, by licensing them royalty-free. (This is the best you can hope for with patents. You can't actually "release" them or nullify them once they've been issued. To make them open source-friendly, you license them royalty-free, and then anyone can use the technologies the patents cover without paying anything or negotiating patent licenses.)"

http://www.w3.org/TR/html5/offline.html
http://diveintohtml5.org/offline.html

There are plenty of bits of HTML5 that you can start using now. They might not do anything on one or more browsers, but they'll be appreciated by the people that do see them. I used some HTML5 for a website we launched recently, and we haven't had any reports of problems with things like <input type="search" placeholder="Search articles"> or <article>.

Here is a good place to start.

I did the same regarding CSS3. Columns and the :target attribute don't work in IE, but it's useful for people with better browsers. Those users also get slightly-interactive SVG charts, IE users just have bitmaps. Of course, if IE9/10/whatever supports :target, SVG, and so on, those users will start to see this stuff.

I posted this URL in another thread, but it is a great view of the whole video format "war" going on.

Even with chrome supporting h.264, in order to get maximum compatibility for video playback across all browsers(let's not leave out Android and Iphone), you still need to have the video in all 3 formats(below is copy/pasted from the site). Chrome isn't going "backwards" compared to where it stands now, unless you prefer having site visitors standardize on a set of browsers, in which case I can't argue with that:

      For maximum compatibility, here’s what your video workflow will look like:
            1. Make one version that uses WebM (VP8 + Vorbis).
            2. Make another version that uses H.264 baseline video and AAC “low complexity” audio in an MP4 container.
            3. Make another version that uses Theora video and Vorbis audio in an Ogg container.
            4. Link to all three video files from a single element, and fall back to a Flash-based video player.

http://www.diveintohtml5.org/video.html

Most people don't know that in order to support EVERY video format for HTML5, you still have to encode a video 3 different times. But this site has a great explanation on which browsers support what, this history of the video formats, and even describes the history of licensing HTML5(i.e. went from paying for encoders, players, AND transmitting to just paying for encoders to players).

http://www.diveintohtml5.org/video.html

A book (that I even reviewed on Slashdot) has a section on just this sort of thing you can read here. It tells you how to use HTML5 microdata to mark up reviews so that search engines and sites (like metacritic) can utilize your HTML to build indexes of reviews.

Slashdot's always been a little behind the curve but considering what their review form looks like, you'd think it'd be a trivial thing to have the end product wrap the review in microdata so they too are suddenly influencing metacritic and coming back a real review site in Google.

... read a similar book he's working on here.

Is there a good reason why these new Google toys don't work in Opera by default? Neither the background image option or that swirling ball trick from the other day worked in Opera until you set it in the options for Opera to mask itself as IE or Firefox - and now the same thing is true for this latest gimmick.

I don't know for sure (not a Google insider) but I would guess that they are using a wrapper script or something that has a hard coded list of support browser by browser. Whatever version of Opera you are using is probably incorrectly identified as not having these HTML5 feature(s) supported. Or perhaps it only gives you some of the functionality so they make the executive decision to just disable it entirely. I just finished reading HTML5 Up and Running by Mark Pilgrim of Google and he pushes heavily for the use of modernizr to check browser capabilities. I've never known Modernizr to be wrong though. Whatever the case, it appears Google is simply not promising their doodle will work in Opera ... could be that they made a checking script for the Pac-Man doodle and just kept carrying it over. Did Opera work for that?

Now that I think about it, this is a high traffic page so they probably wrote their own browser checking wrapper for graceful fallback instead of pushing all of a javascript library down to each client. They are probably using a broad brush to balance bandwidth with audience and you're one of the unfortunate victims.

However, unlike previous HTML specifications, HTML5 is attempting to define which formats are required to be supported by media tags.

No, it is not.

Is also a great resource. With less ads, things broken up by chapter, examples, how to detect if something is enabled, etc.

http://diveintohtml5.org/

Why are we using HTML5 and not XHTML 2?

XML abuses aside, XHTML is superior to HTML5.

Go read http://diveintohtml5.org/

Essentially, the argument is, make it easy for the users - the web programmers, not the browser programmers, and to allow the browsers to incrementally implement the standard, rather than an all or nothing that no one will do. . Telling the browser to error out when the html is not correct or supported is user UNfriendly. HTML5 provides a graceful way to handle it.

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.

They've enabled locations in HTML5. I was playing around with "Dive into HTML 5" and for fun clicked on the "Locate me". It was dead on. Even though I was going through a Proxy server (so I know they didn't find me through IP). Scroll to the bottom, it's "A complete live example"

Prey Project using it as the geo locator for theft recovery. I've had Orbicule's Undercover for a while, and they use Skyhook. Prey Project is 100% open source (all bash scripts more or less) and digging through they're using Google's location APIs to locate devices.

So basically Google now has a 'sky hook' type service that anyone can use for free. Not just that. Every single smart phone that doesn't have GPS built in, now has a 'near location' enabled. Meaning that google can provide location based results even without a GPS.

It's funny that people are so fixated over the video tag discussion that a lot of the other outstanding features of HTML5 are being overlooked. There's offline storage, javascript threads, and even in browser form validation. The awesome thing is that a bunch of these features are already implemented in various browsers. It's just a matter of including a simple javascript sniffer to determine if a client supports it or not. You can dig into the features over here.

I was thinking that maybe the stuff posted to Google Video was encoded in Theora and it gets cross-posted to YouTube, while the stuff posted directly to YouTube gets encoded in H.264, but thats just a guess

Don't guess. In HTML5:

To support Safari, you have to use H.264 (OK, you can add Theora support to Quicktime, but let's assume very few users do this, and nobody wants to be the arsehole site that forces them to do so)
To support Mobile Safari, you have to use H.264
To support Firefox, you have to use Theora. (hence YouTube currently doesn't support HTML5 for Firefox)
Chrome handles both formats.
Opera: definitely handles Theora, not sure about H.264

To be viewable in all HTML5 browsers, you're going to have to encode twice. The Theora encoding/streaming is going to be free. The H.264 encoding/streaming is going to be gratis until 2016. But once you've started, it's going to be awfully difficult to stop.

Why would you use H.264 instead of Ogg Theora to create your videos? What we're talking about here is how you would play videos created by someone like Youtube. The standard doesn't mandate H.264. It just fails to mandate Ogg.

If you only put Theora videos on your site, they won't be viewable in Safari (using default Quicktime components), iPhone or Android.

Professor Markup says:

There is no single combination of containers and codecs that works in all HTML5 browsers.

To make your video watchable across all of these devices and platforms, you’re going to have to encode your video more than once.

As long as there are mainstream platforms that don't support Theora, either you have to encode to H.264 yourself (and pay) or have someone else (e.g. YouTube) encode and host it for you.

Indeed. And if a third party hosts and encodes your video (e.g. YouTube) that side of it's hidden too.

If you wanted to put H.264 video on your own site, you'd have to pay too.

http://diveintohtml5.org/video.html#licensing

It doesn't and it shouldn't. The problem is that browser makers can't decide which codecs to support.* A current list of which browsers support which codecs is here: http://diveintohtml5.org/video.html#what-works

*I still don't believe this is much of a problem though. You can specify a fallback format if the browser doesnt work with your preferred video format.

Client side form handling is the browsers job.

Roll on HTML 5

Firefox supports Ogg/Theora/Vorbis.
Safari, iPhone, Android support H.264,AAC,MP4
Chrome supports all of the above.

http://diveintohtml5.org/video.html#what-works

If you're a web site developer, it's probably best to host both, and have your pages detect what the browser supports.

Web sites that want to support it and also support legacy browsers will use something like Modernizr or other HTML5 detection techniques and provide alternate content - like flash video as alternate content for HTML5 video, javascript or flash charts as alt content for canvas charts, etc.

Some features like sockets and web workers and local storage aren't really feasible for legacy browsers even with workarounds like Gears but a subset can be implemented for specific apps which is the focus of this topic....

HTML 5 does exactly what it says it does.

Dive into HTML 5 tells you what that is, and whether your browser supports it.

It's up to developers to apply it. Google is doing so.