All posts tagged ‘HTML5’

File Under: CSS, HTML5

Amazon Embraces HTML5 for New E-Book Format

The new Kindle Format 8 uses HTML5 and CSS for better looking books and graphic novels

Amazon’s new full-color Kindle Fire tablet will arrive next month and with it will come a new e-book format that uses web standards to take advantage of the Fire’s new and improved features.

The new format, Kindle Format 8 (KF8), uses HTML5, CSS 3 formatting rules, embedded custom fonts and SVG graphics to create a richer toolset for book designers. It also means that if you can build a website, you can build a book.

KF8 isn’t the first e-book format to use HTML under the hood. Both EPUB and Mobi — the current Kindle format — are both built on HTML, but KF8 will be the first to embrace nearly all of HTML5 and its associated tools like CSS 3 and SVG.

With KF8 e-book designers can use the same tools web designers have long relied on to handle richer layout options like sidebars, pull quotes, callouts and other common print design elements that don’t translate well to the limited options of current e-book formats. The new tools will be particularly useful for creating better visuals in children’s e-books and graphic novels.

Interestingly, by making it possible to create e-books using the same tools you’d use to create a website, Amazon may be inadvertently making the web the new home of e-books. So far Amazon hasn’t released many specifics surrounding its KF8 format, but if KF8 is essentially a wrapper around HTML5 and CSS 3 then presumably it won’t be too hard to strip away that wrapper. What would be left behind will likely be a “e-book” that’s really just a single page of HTML and CSS — perfect for the web.

When browsers begin to support tools like the proposed Generated Content for Paged Media specification, it will likely be just as easy to markup and release the raw HTML version of an e-book — and let the browser paginate and format it — as it is to put it in Amazon’s storefront where the Kindle can paginate and format it.

Whether or not such an easy dual publishing route is actually possible will be clearer when Amazon releases its updated Kindle Publisher Tools. Amazon hasn’t set a date yet, but you can sign up to be notified when the new tools are available.

Amazon’s Kindle Fire will be the first Kindle to support the new KF8 format, but according to Amazon support for KF8 in the new e-ink Kindles and the various Kindle apps will be added “in coming months.”

See Also:

File Under: Browsers, HTML5, Multimedia

Metro-style Internet Explorer 10 Ditches Flash, Plugins

Windows 8 will have two versions of Internet Explorer 10: a conventional browser that lives on the legacy desktop, and a new Metro-style, touch-friendly browser that lives in the Metro world. The second of these, the Metro browser, will not support any plugins. Whether Flash, Silverlight, or some custom business app, sites that need plugins will only be accessible in the non-touch, desktop-based browser.

Should one ever come across a page that needs a plugin, the Metro browser has a button to go to that page within the desktop browser. This yanks you out of the Metro experience and places you on the traditional desktop.

The rationale is a familiar one: plugin-based content shortens battery life, and comes with security, reliability, and privacy problems. Sites that currently depend on the capabilities provided by Flash or Silverlight should switch to HTML5.

Microsoft has been vigorously promoting HTML5 for the last year and a half as the best way of providing rich interactivity on the Web. HTML5 potentially has reach far beyond that of Flash, since it can target both conventional browsers and closed ecosystems (such as iOS) alike. However, until now, Microsoft’s messaging has been tempered somewhat: use HTML5 when you can, but if you can’t—if you need support for DRM-protected media streaming, for example—then it’s reasonable to switch to an alternative, plugin-based technology.

With Windows 8, however, those reasonable decisions to use Flash or Silverlight will now be heavily penalized. Technically, there’s nothing wrong with the desktop browser, of course; the rendering engine and performance will be identical between both Metro and desktop. But the experience will be substantially inferior. The desktop browser isn’t designed for touch inputs, meaning that users will either have to switch to a mouse and keyboard, or fumble around with an interface that wasn’t built for fingers. The switch to the desktop browser also appears to discard things like back button history and current page state.

This puts the Metro browser in a peculiar position. Microsoft has positioned tablets as merely a different kind of PC. That, the company argues, affords capabilities and features not possible on iPad-style devices. But PCs have browser plugins—more generally, they have the ability to use the right technology for the job. If Metro doesn’t include that flexibility, that could be seen as diminishing the “PCness” of the platform.

HTML5 still isn’t a total replacement for plugin technologies, either. The gap is certainly narrowing: Web Sockets, Web Workers, built-in support for webcams and microphones, and more, are all coming to HTML5 browsers (or are available already), and these features will obviate the need for plugins for many applications. But certain corners are likely to remain; DRM-protected video, for example, might forever be impossible in HTML5, and while many people find DRM distasteful, many broadcasters feel they have little choice but to use it.

The solution to this conundrum on the iOS platform has been the app: companies like Netflix and the BBC have applications to watch video on these devices. The result is that in the desire to push an open, plugin-free Web, companies are being forced to migrate away from the Web entirely. Silverlight developers, at least, will have an easy migration path available to them: the new Metro development environment, used for producing native Metro applications, borrows heavily from Silverlight, and making the switch from an in-browser plugin-based application to a standalone Metro application should be relatively easier. Flash developers will have to wait to see what tools Adobe delivers.

HTML5 design and developer tools also remain weak, though this situation is improving with the creation of products like Adobe Edge.

With Microsoft’s promotion of HTML5, and the precedent set by iOS, the decision to get rid of plugins in the Metro browser is perhaps unsurprising. But it’s not clear that this will truly help Windows 8; the awkward user experience penalizes users who, for no fault of their own, need to use plugins, and detracts from Windows 8′s PC claims. A switch to a more HTML5-powered Web will happen regardless—does Microsoft really need to force the issue like this?

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

File Under: HTML5

A Quick Guide to Using HTML5 Forms

Web forms are everywhere—contact forms, comment forms, sign up forms—these days you’d be hard pressed to find a website without a form. Sadly, HTML wasn’t originally developed with forms in mind and working with forms on the web is more difficult than it should be. Even something as basic as adding a date-picker to a search form requires JavaScript. But HTML5 forms will change that.

In HTML5 forms get a shot in the arm with dozens of new tricks, including, yes, a built-in date-picker. As with much of HTML5, the new form elements are designed to make developers’ lives easier by off-loading tasks like rendering a date-picker to the web browser.

If you haven’t had a look at the new HTML5 form elements, Robert Nyman, a Technical Evangelist for Mozilla, has a very thorough post examining all the new input types, attributes and elements for HTML5 forms. Even better, Nyman has plenty of examples, demos and sample code to show how each element works. As you can see from the screenshot above (taken in Opera) the default datepicker is pretty ugly, but fear not Nyman covers how to style the new elements as well.

Of course, as with all things HTML5-related, the new form tags are not supported in every browser. In fact, when it comes to HTML5 forms, Opera is the only browser that’s anywhere near full support. The developers over at Wufoo have a page devoted to tracking HTML5 form support in browsers, which is well worth checking out before you decide to dive in with both feet.

Like much of HTML5, support for the new form elements is uneven and it might be a bit early to rely solely on HTML5 form tools in production sites, but it’s never too soon to learn the basics.

See Also:

File Under: HTML5, Web Standards

W3C’s New ‘Community Groups’ Give Everyone a Voice in HTML5

The World Wide Web Consortium (W3C), the web’s governing body, has launched a new "Community Groups" plan designed to help speed the development and standardization of HTML, CSS and other web tools.

Despite the W3C’s role as overseers of web standards, the W3C has never moved at the speed of the web. Much of the HTML5 and CSS 3 that powers the web today won’t officially be a standard for several more years. For those hoping to move the web forward the pace of the W3C sometimes makes the organization seem like a joke. Ten years to standardize HTML5? But HTML5 is already here.

Well, now is your chance to do something more than whine about the slow pace of standards on your blog. The W3C’s new community groups are designed so that anyone can contribute to the development of HTML. Just head over to the site and join a group that interests you. There are eight groups at the moment, including groups dedicated to topics like semantic news, web payments and web education.

The groups also go a long way toward making the W3C more accessible for mere mortals. With the new community groups you don’t need to be a Google or Apple employee to catch the attention of the W3C’s members, you just need to sign up and post your ideas for everyone to read.

The web is changing at an ever-accelerating pace and the W3C knows that if it doesn’t keep up, it’s going to be left behind. The W3C has already been abandoned once. When the W3C decided in 2004 that it would bow out the HTML standardization process, browser makers and web developers wasted no time creating their own separate standards body known as the Web Hypertext Applications Technology Working Group (WHATWG). The WHATWG is largely responsible for creating what we now call HTML5.

Clearly the web will move forward with or without the W3C, though as those who lived through the dark days of the blink tag can attest, the web is a better place with the W3C and web standards at its back.

See Also:

File Under: CSS, HTML5, Web Basics

Popular HTML5 Boilerplate Releases v2.0

The developers behind HTML5 Boilerplate have released version 2.0 of their boilerplate HTML, CSS and JavaScript templates for quickly prototyping HTML5 designs.

You can grab a copy of HTML5 Boilerplate v2.0 from the HTML5 Boilerplate website.

Version 2.0 of HTML5 Boilerplate has several significant changes, including ditching the traditional reset stylesheet for normalize.css. Normalize is a bit different in that it retains useful browser defaults and only resets those elements necessary to achieve cross-browser default styling consistency. It’s a minor point, but my favorite part of normalize.css is that it doesn’t litter your dev tools (Firebug, WebKit Inspector, etc) with endless reset rules.

Other new features in HTML5 Boilerplate include support for Respond.js (which helps if your site uses a "mobile first" approach), faster build times (up to 80 percent faster according to the release notes) and, with v2, your IE 6 visitors will now be prompted to install Chrome Frame.

For more details on everything that’s new in HTML5 Boilerplate v2, head on over to the official site and read through the changelog. Perhaps the most refreshing thing about this release, is this note in the FAQs:

Do I need to upgrade my sites to a new version?

Nope. So far there have been no critical bugs within our code that we’ve fixed from version to version. There are some nice changes that reduce your stress, but updating your HTML or CSS to the new stuff is probably more effort than it’s worth.

However, the .htaccess and Build Script you probably didn’t edit and therefore can be dropped into your existing sites with little hassle and likely a significant reward. So feel free to update those, and also update your Modernizr and jQuery versions to the latest versions they have.

See Also: