What To Expect From HTML5 272
snydeq writes "InfoWorld's Neil McAllister takes a deeper look at HTML5, outlining what developers should expect from this overhaul of HTML — one that some believe could put an end to proprietary Web technologies such as Flash and Silverlight. Among the most eagerly anticipated additions to HTML5 are new elements and APIs that allow content authors to create rich media using nothing more than standards-based HTML. The standard also introduces browser-based application caches, which enable Web apps to store information on the client device. 'But for all of HTML5's new features, users shouldn't expect plug-ins to disappear overnight. The Web has a long history of many competing technologies and media formats, and the inertia of that legacy will be difficult to overcome. It may yet be many years before a pure-HTML5 browser will be able to match the capabilities of today's patchwork clients,' McAllister writes. 'In the end, browser market share may be the most significant hurdle for developers interested in making the most of HTML5. Until these legacy browsers are replaced with modern updates, Web developers may be stuck maintaining two versions of their sites: a rich version for HTML5-enabled users, and a version for legacy browsers that falls back on outdated rendering tricks.'"
Re:Vector animation? (Score:3, Informative)
In order that HTML 5 may replace Flash on Newgrounds.com, what tool for creating vector animations for HTML 5 is comparable to Adobe Flash CS series?
You might try Adobe Illustrator paired with Ikivo Animator, that's what Adobe recommends anyway.
Re:Thank you Apple (Score:5, Informative)
Big thanks to Apple for standing up to the Flash juggernaut and showing the world we could live without it, thereby paving the way for HTML 5.
And big thanks to Google for creating a non-Flash dependent version of YouTube to help Apple do it, and starting to move YouTube away from Flash in general.
Re:What to except (Score:3, Informative)
I think you underestimate the "without breaking backwards compatibility" part of this.
XHTML2 was pretty much designed to not work with any existing web infrastructure (either existing content or existing browsers). If you think a parallel web built from the ground up is the way to go, feel free to work on it, but the network effects involved make it a pretty risky prospect.
Re:End of Proprietary Formats? (Score:5, Informative)
If something is done in flash, it is almost definitely done using a proprietary codec(either one of Adobe's weirdo legacy proprietary codecs, or h264), wrapped in Flash, a proprietary runtime for which no good-enough-to-be-particularly-useful implementations exist. If something is done with an HTML 5 video tag, it will(outside of nests of Free software idealists) almost certainly be h264. However, while the patent situation is a mess, good Free implementations of h264 exist, and Free browsers will be on the leading edge of HTML5 development.
With flash based stuff, it is essentially impossible to function on a Free stack, no matter where you live, what patent licences you either posses or are willing to ignore, or whatever. It just isn't possible. Gnash is Not There Yet, and even if you are willing to go proprietary, Flash pretty much sucks on anything that isn't 32-bit windows, and it's a pit of resource consumption and security flaws even there. Silverlight is incrementally better, with Moonlight covering a greater subset of Silverlight than Gnash does Flash, and it not sucking architecturally as much; but it still doesn't cover enough(and pretty much any Silverlight based media application will be using a patent encumbered codec and/or DRM in any event).
h264/HTML5 still suffers patent encumbrance; but anybody not subject to, or willing to ignore, those patents can have a very functional Free implementation more or less now. That counts for something.
Re:...Now help standardize on non-proprietary code (Score:1, Informative)
If Apple really had our best interests at heart, they would be either 1) pushing Ogg Theora as a baseline video standard, or 2) working to release H.264 into the public domain so that everyone can use the arguably "better" codec.
Every piece of Apple hardware that can play video supports H.264 which is also what they provide in their iTunes store. They can't change that overnight. Furthermore they'd need to support H.264 anyway since Youtube uses it. Apple can't release H.264 into the public domain, because they don't own it.
In fact, speaking of an unencumbered codec, have you noticed that Safari, by deliberate choice, does not support Ogg Theora?
Safari, at least on the Mac, supports everything the Quicktime framework supports. While they have been shipping H.264 support with Qicktime for years they are not preventing you from installing a plugin [xiph.org] if you want to watch Theora videos in HTML5.
Firefox, of course supports Ogg Theora, and due to its open source nature, can't support H.264 unless it's released to the public domain.
Firefox could easily support H.264 if they used the codec framework the operating systems provide. There are free (as in beer/licensed and as in freedom) H.264 decoders that you can download for DirectShow and Qicktime. The situation with GStreamer isn't that good, but since Fluendo provides a free and legal MP3 decoder for linux I'm sure it wouldn't be so hard for someone with the resources (for instance Mozilla and Opera) to get together and provide the same thing for H.264. Realistically it wouldn't be a problem though since most people have the GStreamer Bad and Ugly plugins installed anyway.
Another thing Firefox could do is to use FFMpeg for Vorbis and Theora decoding. That way it would be trivial for the user to replace a stripped FFMpeg with a full featured one and play basically every video on the web.
Re:...Now help standardize on non-proprietary code (Score:3, Informative)
That and Apple is a holder of H.264 and MP4 patents.
Re:Vector animation? (Score:4, Informative)
Just use anything with SVG support.
And CSS3 has native support for animation control, quite powerful control at that.
Please point me to CSS3's support for interpolation between SVG keyframes. Then please point me to the graphical timeline editor for CSS3 animation. Flash has had both since before it had ActionScript.
The only thing that it doesn't have great support for yet is some of the things that people are used to with Flash development. Preloaders are one thing
HTML5 has onload. Just set the animation to start once all your assets' onload events have fired.
Of course, considering how most of the imagery is usually vectors in Flash games, it shouldn't be too much of a problem.
SVG is bloated unless you gzip it.
Re:...Now help standardize on non-proprietary code (Score:3, Informative)
It is not significantly worse either. h.264 has a deadline set for when free use ends. That deadline may or may not be pushed back and the royalties may or may not be extortionate. By using Theora, you don't have to worry about that.
http://arstechnica.com/media/news/2010/02/royalty-free-codec-still-needed-despite-no-cost-h264-license.ars
Re:Thank you Apple (Score:3, Informative)
And? Even at one patent that are still heavily invested in H.264, MP4 (which they also hold patents on) and AAC. I see no good reason for them financially to drop all those years of investments in this formats to go to Ogg and Theora.
Re:Vector animation? (Score:4, Informative)
I've seen these before, and "please e-mail sales" in lieu of a base price usually turns out to be code-word for "if you have to ask, you can't afford it".
According to a review in MacUser, it's £199+VAT (=~ $350 US), or at least that was the price for v1.1 (I think there may have been a few updates since then).
Re:HTML5 (Score:1, Informative)
At a guess I'd assuming he's referring to the fact that HTML5 encourages sloppy markup over XML based markup. The problem is that this makes the web less parasable, the general argument is that this is false, because a reference parser exists for HTML5 and parsing of it is fully documented, but that argument is useless because HTML5 parsers do not exist as commonly and widely as XML parsers, and it's also absolutely pointless having to have an HTML5 and possibly an XML parser as well. Other advantages of XML include the ability to use the plethora of XML tools to manipulate it, transform it and so forth- none of this exists for HTML5. It makes life a hell of a lot more of a headache for applications that wish to make use of page data. Some of the arguments that go against XML markup are that XML doesn't handle errors gracefully, but this is really a poor argument- it'd have been better to solve that problem than it would use a incompatible spec which relies on new parsers being provided.
Further, there is a big issue with the new "semantic" tags, things like , and so forth rather than the use of say,
. Whilst the former are certainly tidier, they're also not generic, the tags were decided based on a study that is now a fair few years old at Google into the most commonly used classes and ids, the problem is, as we know, the web doesn't remain static for long- in fact, the tag selection for HTML5 is already arguably obsolete, it doesn't have things like for comments sections that have become so common and prominent in a web 2 world, further, specifications DO remain static, and the previous HTML/XHTML specs are around a decade old now- can we be sure those tags wont just be obsolete messes in another 5 - 10 years? Do we release a new version of the spec just to produce new semantic tags each time the web evolves? No, the reality is we're stuck with divs anyway because they're generic, a better solution for the semantic web would've been to have a semantic definition language that allows you to attach semantics to sections just like you attach content and allow for semantics to be handled by a different member of a dev team, or even handled by 3rd parties for sites that are no longer maintained.
There are a fair few other issues, it's done a poor job of improving accessibility for example, but these stand out particularly.
HTML5 has some nice new features like canvas certainly, but it's certainly a poorly designed spec- it has a hell of a lot of clutter, it regularly flies in the face of good practice, and it has failed at one of it's primary goals- standardised, open video. It's really a spec that's absolutely not been designed with professional developers of large scale web apps in mind, nor with the future of the web in mind. It's really focussed on amateur publishers, but that seems a poor goal seeing as most amateur publishers nowadays use applications built by professionals to publish content - i.e. Facebook, MySpace, Wordpress, Blogger and stuff. The days of your average Joe writing markup are gone, so I'm not sure why HTML5 takes so much effort to focus on the preferences of amateurs rather than the requirements professionals in this respect.
Good developers can continue to simply ignore the tools they don't want- they can ignore tags like etc. and just use classic tags, they can ignore the sloppy SGML based markup and just use XML so it's not that it hinders them directly in this respect. It just means that when they inevitably have to deal with markup written by amateurs, or even a previous code base written by bad developers then HTML5 only increases the headache.
You may be wondering why things have ended up this way, well it effectively seems to come down to pressure from the likes of Apple, and Mozilla- it seems rather than actually give their browsers and rendering ages the overhauls they need to modernise them and take the web forward, they'd rather hack what they've got to continue on the old mess, hence this is also going to do nothing to solve the problem of
Re:Er... standing up? Really? (Score:4, Informative)
Re:Flash Player is a cost center (Score:2, Informative)
Re:HTML5 (Score:1, Informative)
The obvious case is that things like SVG, MATHML, etc. only work in XHTML.
But proper, validated XHTML also saves me time versus proper validated HTML. Think of a website template that is the container for content from a rich-text-editor. Lets assume the content is not only valid, but also correct and there is an error in the template surrounding it. This error is valid HTML, but it's result is that the site looks fine with certain simple content but not with other content. This can happen because something like <div><p>content</div> is valid, but where the <p> is closed depends on what comes after it.
I think having to add a / to every <br> and any other tag that has no content is not really much work.