Kony’s KonyOne platform is available across smartphones, tablets and PCs, It allows developers to define an app just once, and deploy it across more than 9,000 devices, seven operating systems and multiple channels.

The US-based firm is already working with brands including Hotwire, Huntington Bank, Hyatt, Toyota and Capital One.

This new update adds HTML5 – and therefore web apps – to the range of formats that the platform can support. Specifically the features include:

* HTML5 elements: including new form fields, audio and video elements.
* Touch specific features: touch events and resolve them as a tap, double tap, long press or swipe.
* CSS 3.0 Specifications: leveraging media queries to target CSS specific to device DPI, with CSS gradients, rounded corners and shadows along with 2D and 3D transitions
* New JavaScript APIs: enabling features such as geolocation.
* Widget enhancements: designed to improve the application user experience.

Raj Koneru, CEO of Kony, said: “At Kony, we believe the future includes native, mobile web, and HTML5 hybrid or ‘mixed mode’ applications. Using the KonyOne platform, developers are able to use a single code base to create optimised applications for any device, operating system or browser.

Sencha sells frameworks for creating HTML5 Web apps, using advanced features such as geolocation, animations, reflections and transitions, so the company takes a keen interest in which mobile browsers best support those features. The latest test focused on Samsung’s Galaxy Nexus, which runs Android Ice Cream Sandwich.

“After putting the Galaxy Nexus through our test wringer, we can say that Ice Cream Sandwich is a major step for the Android browser,” Sencha’s senior director of product management, Aditya Bansod, wrote in a blog post. “However, it still falls short of iOS 5.”

One of the biggest improvements for Ice Cream Sandwich is full support for CSS3 effects, including smooth transitions and animations that can make Web apps look like native apps. “For Web developers, you can finally rely on HTML5 in Android 4.0 to build rich user interfaces,” Bansod wrote.

In addition, Android Ice Cream Sandwich supports embedded HTML5 audio and video. The Galaxy Nexus was able to play inline video at html5video.org — something that even the iPad and iPhone can’t do. “In one word: finally,” Bansod wrote.

Android fell short, however, in a head-to-head test of HTML5 features. The browser in Ice Cream Sandwich still doesn’t support Web Workers and Web Sockets, which basically means that Web apps can’t update in real-time. Instead, they must periodically refresh to get new information. Android’s browser also has weaker support for various input types, and no support for Emoji emoticons.

Still, the Ice Cream Sandwich update looks good for Google, which has promoted the idea of Web apps through the Chrome Web Store, and has argued that Web apps and native apps will eventually converge. Reading through Sencha’s report, I was surprised to see that Android was so far behind in mobile HTML5 support, but with Ice Cream Sandwich, Google is playing some serious catch-up.

Follow Jared on Twitter, Facebook or Google+ for even more tech news and commentary.

The concept behind the app is similar to that of Amazon Kindle Cloud Reader: You input the URL and then run TeleNav from within a browser, without installing a native app first. An added benefit: TeleNav can continuously update the service over time whenever it wants, without inconveniencing consumers with periodic software updates.

In an e-mail to PCMag, Mary Beth Lowell, TeleNav’s associate director of public relations, confirmed that the HTML5-based app will tap into each device’s GPS chip. The combination puts it several leagues ahead of Google Maps, which provides directions without voice prompts, meaning you can also use it in a car while behind the wheel, since you don’t have to look at the screen for the next step.

“For example, if I’m in a travel app and I’m looking at my hotel address, I could click on the address and get full voice-guided TBT [turn-by-turn] directions to the hotel,” Lowell said. “I wouldn’t need to be a TeleNav customer or even download an app.”

The new TeleNav app will feature many of the same basic features as its native counterpart, including animated 3D maps, voice prompts, and automatic reroutes. TeleNav also announced the app will be free to all consumers and developers, and that it will work on “all major mobile platforms” with an HTML5-compatible feature phone or smartphone.

TeleNav said that it plans to release the HTML5-based service sometime in early 2012. Rest assured we’ll put the HTML5 app through its paces; it will be interesting to see how many features make it over from the company’s existing iPhone GPS app lineup, such as text-to-speech, lane assistance, road speed limits, and POI search tuned for automotive (instead of pedestrian) use.

Developers interested in TeleNav’s new HTML5 GPS app can get more information by visiting www.telenav.com/developer/HTML5.

HTML5 has been in the spotlight lately. Last month, Adobe announced that it is killing off Flash development for mobile devices, after years of buggy versions that never measured up to the desktop Flash experience. Shortly thereafter, Revision3 said it was terminating development of its Flash player, and is now transitioning its online video platform entirely to HTML5.

Google’s Closure Tools previously focused primarily on JavaScript, offering developers a Library of code along with an optimizer, Firebug inspector and command line tools for working on large-scale JavaScript-intensive applications like Google’s own apps. In addition to JavaScript, Closure offers developers some HTML tools as well.

Now Google has added CSS to the list, and has, once again, opted to reinvent the wheel to suit its own needs instead of using any similar, existing projects.

Here’s how Google describes the new Closure Stylesheets:

Closure Stylesheets is an extension to CSS that adds variables, functions, conditionals, and mixins to standard CSS. The tool also supports minification, linting, RTL flipping, and CSS class renaming.

If that sounds a lot like Sass or Less, well, that’s because Closure Stylesheets are more or less the same wheel, slightly tweaked by Google. As with the rest of the Closure tool set, Closure Stylesheets feel first and foremost like they’re useful to Google developers. Those outside of the Google Plex who haven’t, for one reason or another, liked what Sass or Less offer might be interested in Closure Stylesheets. But if you’re already using another CSS extension library there aren’t any terribly compelling reasons to switch to Closure.

CSS for high traffic websites? Does it sound like a book a developer would really need to read.

After all what a high traffic website needs is a good server architecture coupled with caching and compression and CSS isn’t really top of the list in terms of what you might get back in performance from effort expended. However, there are other issues with CSS that are associated with high traffic websites – defined to be those with over 10,000 visitors per day. Such large web sites are likely to belong to big companies or to be managed by a team rather than a few lone developers. What this means is that, as well as having to be organized about HTML and JavaScript, you also have to organize your CSS. And CSS is generally an afterthought in the design of most website.

We love CSS’s dancey beats and their second single ‘City Grrrl’ doesn’t disappoint in that department, and now the video just makes wanna to get out of our offices and sashay down the NYC streets with pink hair just like Lovefoxxx.

The singer assures this song is quite autobiographical and based on some bullying she experienced while growing up for being so unique. “I’d be on the floor of my bedroom making the most ridiculous clothes and glue fake colored hair or x-ray pictures on clothes. I’d be sporting goth make up at 8am and when I hit the streets people would curse me from their cars in the most aggressive way. [Calling me] ‘drag queen’, ‘whore.’”

Feeling like an outcast is not good, but at least Lovefoxxx and CSS know how to turn all those experiences into one cool track. Watch do you think of the clip?

In more length: The term “HTML5″ is widely used as a buzzword to refer to modern Web technologies, many of which (though by no means all) are developed at the WHATWG, in some cases in conjunction with the W3C and IETF.

The WHATWG work is all published in one specification (known as “Web Applications 1.0″), parts of which are republished in a variety of other forms, including an edition optimized for Web developers (known as HTML5), and one which focuses mainly on the core HTML language (which you are reading right now). In addition, two subparts of the specification are republished as separate documents, for ease of reference: WebVTT and WebRTC.

The W3C also publishes parts of this specification as separate documents. One of these parts is called “HTML5″; it is a subset of this specification (the HTML Living Standard).

1.1.1 How do the WHATWG and W3C specifications differ?

The features present in both the WHATWG and W3C specifications are specified using identical text, except for the following (mostly editorial) differences:

• The W3C HTML specification refers to the technology as HTML5, rather than just HTML.
• Examples that use features from HTML5 are not present in the W3C specifications since the W3C specifications are published as HTML4 due to W3C publication policies.
• The W3C HTML specification defines conformance for documents in a more traditional (version-orientated) way, because of a working group decision from March 2011. This specification, in part driven by its versionless development model, instead uses a conformance definition that more closely models how specifications are used in practice.
• The W3C HTML specification omits a paragraph of implementation advice because of a working group decision from June 2010.
• The W3C HTML specification includes a paragraph of advice redundant with the ARIA specifications because of a working group decision from March 2011.
• The W3C HTML specification gives incomplete advice regarding the alt attribute and instead references other documents on the matter because of a working group decision from March 2011.
• The W3C HTML specification includes a link to an incomplete document that contradict this specification because of a working group decision from Februray 2011.
• The W3C HTML specification has different prose regarding the use of tables for layout purposes because of a working group decision from March 2011. In contrast, this specification unambiguously disallows the use of table elements for layout purposes.
• The W3C HTML specification requires authors who are writing HTML e-mails with images to people they know can see the images (e.g. a wife sending her husband photos of their child) to nonetheless include textual alternatives to those images, because of a working group decision from April 2011.
• The W3C HTML specification does not state that the img element’s alt attribute is its fallback content, because of a working group decision from April 2011.
• The W3C HTML specification is missing a clause that requires conformance checkers to discourage cargo-cult accessibility authoring because of a working group chair decision from May 2011.
• The W3C HTML specification is missing some conformance constraints that would make documents misusing canvas invalid, because of a working group chair decision from June 2011.
• The W3C 2D Context specification has a different API for handling focus and selection in the 2D canvas API, because of a working group chair decision from May 2011.

The following sections are only published in the WHATWG specifications and are not currently available anywhere else:

• The PeerConnection API and related video-conferencing features.
• New hyperlink features: the download attribute to make download links and the ping attribute for hyperlink auditing.
• The WebVTT format and some text track API features.
• Rules for converting HTML to Atom.
• The cssElementMap feature for defining CSS element reference identifiers.
• An experimental UndoManager interface.
• An experimental specification of the legacy window.find() API.
• Some predefined Microdata vocabularies.

You may well ask: “How can I start using HTML5 if older browsers don’t support it?” But the question itself is misleading. HTML5 is not one big thing; it is a collection of individual features. So you can’t detect “HTML5 support,” because that doesn’t make any sense. But you can detect support for individual features, like canvas, video, or geolocation.

You may think of HTML as tags and angle brackets. That’s an important part of it, but it’s not the whole story. The HTML5 specification also defines how those angle brackets interact with JavaScript, through the Document Object Model (DOM). HTML5 doesn’t just define a <video> tag; there is also a corresponding DOM API for video objects in the DOM. You can use this API to detect support for different video formats, play a video, pause, mute audio, track how much of the video has been downloaded, and everything else you need to build a rich user experience around the <video> tag itself.

Chapter 2 and Appendix A will teach you how to properly detect support for each new HTML5 feature.

2. You don’t need to throw anything away

Love it or hate it, you can’t deny that HTML 4 is the most successful markup format ever. HTML5 builds on that success. You don’t need to throw away your existing markup. You don’t need to relearn things you already know. If your web application worked yesterday in HTML 4, it will still work today in HTML5. Period.

Now, if you want to improve your web applications, you’ve come to the right place. Here’s a concrete example: HTML5 supports all the form controls from HTML 4, but it also includes new input controls. Some of these are long-overdue additions like sliders and date pickers; others are more subtle. For example, the email input type looks just like a text box, but mobile browsers will customize their onscreen keyboard to make it easier to type email addresses. Older browsers that don’t support the email input type will treat it as a regular text field, and the form still works with no markup changes or scripting hacks. This means you can start improving your web forms today, even if some of your visitors are stuck on IE 6.

Read all the gory details about HTML5 forms in Chapter 9.

3. It’s easy to get started

“Upgrading” to HTML5 can be as simple as changing your doctype. The doctype should already be on the first line of every HTML page. Previous versions of HTML defined a lot of doctypes, and choosing the right one could be tricky. In HTML5, there is only one doctype:

<!DOCTYPE html>

Upgrading to the HTML5 doctype won’t break your existing markup, because all the tags defined in HTML 4 are still supported in HTML5. But it will allow you to use — and validate — new semantic elements like <article>, <section>, <header>, and <footer>. You’ll learn all about these new elements in Chapter 3.

4. It already works

Whether you want to draw on a canvas, play video, design better forms, or build web applications that work offline, you’ll find that HTML5 is already well-supported. Firefox, Safari, Chrome, Opera, and mobile browsers already support canvas (Chapter 4), video (Chapter 5), geolocation (Chapter 6), local storage (Chapter 7), and more. Google already supports microdata annotations (Chapter 10). Even Microsoft — rarely known for blazing the trail of standards support — will be supporting most HTML5 features in the upcoming Internet Explorer 9.

Each chapter of this book includes the all-too-familiar browser compatibility charts. But more importantly, each chapter includes a frank discussion of your options if you need to support older browsers. HTML5 features like geolocation (Chapter 6) and video (Chapter 5) were first provided by browser plugins like Gears or Flash. Other features, like canvas (Chapter 4), can be emulated entirely in JavaScript. This book will teach you how to target the native features of modern browsers, without leaving older browsers behind.

5. It’s here to stay

Tim Berners-Lee invented the world wide web in the early 1990s. He later founded the W3C to act as a steward of web standards, which the organization has done for more than 15 years. Here is what the W3C had to say about the future of web standards, in July 2009:

Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the HTML Working Group, W3C hopes to accelerate the progress of HTML5 and clarify W3C’s position regarding the future of HTML.

What is HTML5?

What we understand today as HTML5 has had a relatively turbulent history. You probably already know that HTML is the predominant markup language used to describe content, or data, on the World Wide Web. HTML5 is the latest iteration of that markup language, and includes new features, improvements to existing features, and scripting-based APIs.

That said, HTML5 is not a reformulation of previous versions of the language — it includes all valid elements from both HTML4 and XHTML 1.0. Furthermore, it’s been designed with some primary principles in mind to ensure it works on just about every platform, is compatible with older browsers, and handles errors gracefully. A summary of the design principles that guided the creation of HTML5 can be found on the W3C’s HTML Design Principles page.

First and foremost, HTML5 includes redefinitions of existing markup elements, and new elements that allow web designers to be more expressive in the semantics of their markup. Why litter your page with divs when you can have articles, sections, headers, footers, and more?

The term “HTML5” has additionally been used to refer to a number of other new technologies and APIs. Some of these include drawing with the element, offline storage, the new and elements, drag-and-drop functionality, Microdata, embedded fonts, and others.

It should also be noted that some of the technologies that were once part of HTML5 have been separated from the specification, so technically, they no longer fall under the “HTML5” umbrella. Certain other technologies were never part of HTML5, yet have at times been lumped in under the same label. This has instigated the use of broad, all-encompassing expressions such as “HTML5 and related technologies.” Bruce Lawson even half-jokingly proposed the term “NEWT” (New Exciting Web Technologies) as an alternative.

However, in the interest of brevity — and also at the risk of inciting heated arguments — we’ll generally refer to these technologies collectively as “HTML5.”

How Did We Get Here?

The web design industry has evolved in a relatively short time period. Twelve years ago, a website that included images and an eye-catching design was considered “top of the line” in terms of web content.

Now, the landscape is quite different. Simple, performance-driven, Ajax-based web apps that rely on client-side scripting for critical functionality are becoming more and more common.Websites today often resemble standalone software applications, and an increasing number of developers are viewing them as such.

Along the way, web markup evolved. HTML4 eventually gave way to XHTML, which is really just HTML 4 with strict XML-style syntax. Currently, both HTML 4 and XHTML are in general use, but HTML5 is gaining headway.

HTML5 originally began as two different specifications: Web Forms 2.0 and Web Apps 1.0. Both were a result of the changed web landscape, and the need for faster, more efficient, maintainable web applications. Forms and app-like functionality are at the heart of web apps, so this was the natural direction for the HTML5 spec to take. Eventually, the two specs were merged to form what we now call HTML5.

During the time that HTML5 was in development, so was XHTML 2.0. That project has since been abandoned to allow focus on HTML5.

Would the Real HTML5 Spec Please Stand Up?
Because the HTML5 specification is being developed by two different bodies (the WHATWG and the W3C), there are two different versions of the spec. The W3C (or World Wide Web Consortium) you’re probably familiar with: it’s the organization that maintains the original HTML and CSS specifications, as well as a host of other web-related standards, such as SVG (scalable vector graphics) and WCAG (web content accessibility guidelines.)

The WHATWG (aka the Web Hypertext Application Technology Working Group), on the other hand, might be new to you. It was formed by a group of people from Apple, Mozilla, and Opera after a 2004 W3C meeting left them disheartened. They felt that the W3C was ignoring the needs of browser makers and users by focusing on XHTML 2.0, instead of working on a backwards-compatible HTML standard. So they went off on their own and developed theWeb Apps andWeb Forms specifications discussed above, which were then merged into a spec they called HTML5. On seeing this, the W3C eventually gave in and created its own HTML5 specification based on the WHATWG’s spec.

This can seem a little confusing. Yes, there are some politics behind the scenes that we, as designers and developers, have no control over. But should it worry us that there are two versions of the spec? In short, no.

The WHATWG’s version of the specification can be found here, and has recently been renamed “HTML” (dropping the “5”). It’s now called a “living standard,” meaning that it will be in constant development and will no longer be referred to using incrementing version numbers.

The WHATWG version contains information covering HTML-only features, including what’s new in HTML5. Additionally, there are separate specifications being developed by the WHATWG that cover the related technologies. These specifications include Microdata, Canvas 2D Context, Web Workers, Web Storage, and others. The W3C’s version of the spec can be found at here, and the separate specifications for the other technologies can be accessed here.

So what’s the difference between the W3C spec and that of WHATWG? Briefly, the WHATWG version is a little more informal and experimental (and, some might argue, more forward-thinking). But overall, they’re very similar, so either one can be used as a basis for studying new HTML5 elements and related technologies.

Why Should I Care About HTML5?

As mentioned, at the core of HTML5 are a number of new semantic elements, as well as several related technologies and APIs. These additions and changes to the language have been introduced with the goal of web pages being easier to code, use, and access.

These new semantic elements, along with other standards like WAI-ARIA and Microdata, help make our documents more accessible to both humans and machines — resulting in benefits for both accessibility and search engine optimization.

The semantic elements, in particular, have been designed with the dynamic web in mind, with a particular focus on making pages more modular and portable.

Finally, the APIs associated with HTML5 help improve on a number of techniques that web developers have been using for years. Many common tasks are now simplified, putting more power in developers’ hands. Furthermore, the introduction of HTML5-based audio and video means there will be less dependence on third-party software and plugins when publishing rich media content on the Web. Overall, there is good reason to start looking into HTML5’s new features and APIs.

What is CSS3?

Another separate — but no less important — part of creating web pages is Cascading Style Sheets (CSS). As you probably know, CSS is a style language that describes how HTML markup is presented or styled. CSS3 is the latest version of the CSS specification. The term “CSS3” is not just a reference to the new features in CSS, but the third level in the progress of the CSS specification .

CSS3 contains just about everything that’s included in CSS2.1 (the previous version of the spec). It also adds new features to help developers solve a number of problems without the need for non-semantic markup, complex scripting, or extra images.

New features in CSS3 include support for additional selectors, drop shadows, rounded corners, multiple backgrounds, animation, transparency, and much more. CSS3 is distinct from HTML5. We’ll be using the term CSS3 to refer to the third level of the CSS specification, with a particular focus on what’s new in CSS3. Thus, CSS3 is separate from HTML5 and its related APIs.

Why Should I Care About CSS3?

Some design techniques find their way into almost every project. Drop shadows, gradients, and rounded corners are three good examples. We see them everywhere. When used appropriately, and in harmony with a site’s overall theme and purpose, these enhancements can make a design flourish.

Perhaps you’re thinking: we’ve been creating these design elements using CSS for years now. But have we?

In the past, in order to create gradients, shadows, and rounded corners, web designers have had to resort to a number of tricky techniques. Sometimes extra HTML elements were required. In cases where the HTML is kept fairly clean, scripting hacks were required. In the case of gradients, the use of extra images was inevitable. We put up with these workarounds, because there was no other way of accomplishing those designs.

CSS3 allows you to include these and other design elements in a forward-thinking manner that leads to so many benefits: clean markup that is accessible to humans and machines, maintainable code, fewer extraneous images, and faster loading pages.

What Do We Mean by the “Real World”?
In the real world, we don’t create a website and then move on to the next project while leaving previous work behind. We create web applications and we update them, fine-tune them, test them for potential performance problems, and continually tweak their design, layout, and content.

In other words, in the real world, we don’t write code that we have no intention of revisiting. We write code using the most reliable, maintainable, and effective methods available, with every intention of returning to work on that code again to make any necessary improvements or alterations. This is evident not only in websites and web apps that we build and maintain on our own, but also in those we create and maintain for our clients.

We need to continually search out new and better ways to write our code. HTML5 and CSS3 are a big step in that direction.

The Varied Browser Market
Although HTML5 is still in development, and does present significant changes in the way content is marked up, it’s worth noting that those changes won’t cause older browsers to choke, or result in layout problems or page errors.

What this means is that you could take any of your current projects containing valid HTML4 or XHTML markup, change the doctype to HTML5, and the page will still validate and appear the same as it did before. The changes and additions in HTML5 have been implemented into the language in such a way so as to ensure backwards compatibility with older browsers — even IE6!

But that’s just the markup. What about all the other features of HTML5, CSS3, and related technologies? According to one set of statistics, about 47% of users are on a version of Internet Explorer that has no support for most of these new features.

As a result, developers have come up with various solutions to provide the equivalent experience to those users, all while embracing the exciting new possibilities offered by HTML5 and CSS3. Sometimes this is as simple as providing fallback content, like a Flash video player to browsers without native video support. At other times, though, it’s been necessary to use scripting to mimic support for new features. These “gap-filling” techniques are referred to as polyfills. Relying on scripts to emulate native features isn’t always the best approach when building high-performance web apps, but it’s a necessary growing pain as we evolve to include new enhancements and features.

So, while in Introducing HTML5 and CSS3 we recommend fallback options and polyfills to plug the gaps in browser incompatibilities, we also try to do our best in warning you of potential drawbacks and pitfalls associated with using these options.

Of course, it’s worth noting that sometimes no fallbacks or polyfills are required at all: for example, when using CSS3 to create rounded corners on boxes in your design, there’s often no harm in users of older browsers seeing square boxes instead. The functionality of the site isn’t degraded, and those users will be none the wiser about what they’re missing.

The Growing Mobile Market
Another compelling reason to start learning and using HTML5 and CSS3 today is the exploding mobile market.

According to StatCounter, in 2009, just over 1% of all web usage was mobile. In less than two years, that number has quadrupled to over 4%.8 Some reports have those numbers even higher, depending on the kind of analysis being done. Whatever the case, it’s clear that the mobile market is growing at an amazing rate. 4% of total usage may seem small, and in all fairness, it is. But it’s the growth rate that makes that number so significant — 400% in two years! So what does this mean for those learning HTML5 and CSS3?

HTML5, CSS3, and related cutting-edge technologies are very well supported in many mobile web browsers. For example, mobile Safari on iOS devices like the iPhone and iPad, Opera Mini and Opera Mobile, as well as the Android operating system’s web browser all provide strong levels of HTML5 and CSS3 support. New features and technologies supported by some of those browsers include CSS3 colors and opacity, the Canvas API, Web Storage, SVG, CSS3 rounded corners, Offline Web Apps, and more.

In fact, some of the new technologies have been specifically designed with mobile devices in mind. Technologies like Offline Web Apps andWeb Storage have been designed, in part, because of the growing number of people accessing web pages with mobile devices. Such devices can often have limitations with online data usage, and thus benefit greatly from the ability to access web applications offline.

On to the Real Stuff

It’s unrealistic to push ahead into new technologies and expect to author pages and apps for only one level of browser. In the real world, and in a world where we desire HTML5 and CSS3 to make further inroads, we need to be prepared to develop pages that work across a varied landscape. That landscape includes modern browsers, older versions of Internet Explorer, and an exploding market of mobile devices.

Yes, in some ways, supplying a different set of instructions for different user agents resembles the early days of the Web with its messy browser sniffing and code forking. But this time around, the new code is future-proof, so that when the older browsers fall out of general use, all you need to do is remove the fallbacks and polyfills, leaving only the code base that’s aimed at modern browsers.

HTML5 and CSS3 are the leading technologies ushering in a much more exciting world of web page authoring. Because all modern browsers (including IE9) provide significant levels of support for a number of HTML5 and CSS3 features, creating powerful, easy-to-maintain, future-proof web pages is more accessible to web developers than ever before.

As the market share of older browsers declines, the skills you gain today in understanding HTML5 and CSS3 will become that much more valuable. By learning these technologies today, you’re preparing for a bright future in web design.