有些人接受了 ,有些人丢弃它太遥远的未来,有些人放弃了滥用的朋友有利于旧火焰在筹备。任何一方的辩论你的,你最有可能听到的所有的博客聊天围绕“新炎热” ,也就是html5 。它无处不在,它的未来,和你想知道的一切,您可以收到的旧新闻。
像jQuery插件,格式技术,并设计趋势的变化非常迅速地在整个网络社会。并在大多数情况下我们都接受的是,有些事情我们知道今天可以过时的明天,但是这是我们行业的性质。 在寻找一些稳定,我们通常可以转向代码本身,因为它往往会保持不变了很长一段时间(相对而言) 。因此,当一些惊喜和改变我们的代码,这是一个大问题,以及将有一些成长的痛苦,我们必须通过。幸运的是,据传,我们已经少了一个变化的担心 。 在这篇文章中,我希望能够给你一些提示和洞察html5 ,以帮助减轻疼痛的必然附带过渡到一种略有不同的语法。
Welcome to html5.
When I first started researching html5 a few months ago, one of the main things I struggled to find was the doctype. A simple thing, you’d think it would be everywhere, but after much frustration, I finally found it buried within w3.org and here it is:
<!DOCTYPE html>
我也好奇,为什么他们选择“的HTML ” ,而不是“ html5 ” ,这似乎合乎逻辑的方式来告诉浏览器,目前的文件写于html5 ,并提供了一个良好的范本,以供未来。但我发现, <!DOCTYPE html5>触发夸克斯模式中的IE6 ,和向后兼容时,考虑到<!DOCTYPE html>是一个相当不错的选择(在我看来) 。 总之,我真的很喜欢这个新的文档,它的小的,有意义的,也许我们会实际上能够记住这个时刻的心,而不是将其粘贴在网站上。
At first glance, with html5, the new elements immediately jump out and command attention. The W3C really listened to the community and planned for the future when architecting the abundance of new elements available. We have everything from basic structural elements like <header>
and <footer>
to others like <canvas>
and <audio>
that tap into, what seems to be, a very powerful API which allows us the freedom to create more user-friendly applications while further distancing ourselves from reliance on Flash for saving data and intense animation.
<header>
<nav>
<section>
<div>
does by separating off a portion of the document.<article>
<aside>
<footer>
When you take a look at these new elements, it looks like they’re just replacing our common DIV IDs; and in a way, it’s true. But, the diagram below shows that elements like <header>
and <footer>
can be used more than once on a single page where they behave more like classes and normal HTML elements that you can use over and over again to retain a semantic structure.
Elements like <header> and <footer> are not just meant to represent the top and bottom of the current document, but they also represent the <header>
and <footer>
of each document section, much the way we use <thead>
and <tfoot>
in data tables.The benefits of using these structural elements is mainly due to the fact that they are extremely well defined and provide a great way to semantically structure your document. However, these elements do need to be used with some careful thought because they can, very easily be overused.
Even though HTML 4.01, XHTML 1.0, & html5 are all very similar there are some small syntax differences that can, very easily, slip past anyone and invalidate code. Keeping this in mind, html5 has some built-in “slack” to make the transition a little easier.For example, when marking up a form in html5, this is the proper syntax for an input text element:
<input type="text" id="name">
But this is also accepted as valid code in an attempt to ease the pain for avid XHTML coders (like myself) who are used to self-closing elements:
<input type="text" id="name"/>
The same rules apply to <meta>
and other self closing elements. Legacy elements like <b>
and <i>
were also left in to help those coming over from HTML 4.01.l
With any new technology there has to be benefit; why else would you use it? If your old code works just as well and efficient as the new code there’s no reason to upgrade. No reason at all, trust me, I checked.Luckily html5 is packed with cool new features, code slimming techniques and a lot of stuff I would call very large benefits. Most of which circle around the new APIs and the DOM tree.
The most obvious benefit built into html5 is the numerous APIs and the opportunities it opens up for the future of web apps with Holy Grail of application cache and offline capabilities. Google Gears gave us offline data storage and Flash introduced us to the power of application cache (Pandora uses it to save your log in information). With html5, these capabilities are now available to use right in the language and can easily be expanded with JavaScript.html5 relies on light scripting to flex its muscles on the Web; this is very possibly the first time, other than jQuery, that one (front-end) technology has fully acknowledged another. Sure, we connect them with classes and IDs but up until now, they have been perceived as separate layers by the principles of progressive enhancement. But as the Web grows we need unity like this across the Web.
The coolest part about html5 is definitely its offline capabilities. Programs like Thunderbird and Outlook (and now GMail to an extent) let you browse through your old data while staying offline. With html5, you’ll have this same functionality, but in the browser. This is the first serious step towards bridging the gap between the desktop and the Web, and opens all sorts of doors for the future of Web apps.The W3C has taken the best parts from the various Web technologies and rolled them into, what is being dubbed the most powerful markup language to date.
<video width="400" height="360" src="vid.mp4">
<video>
, that are not.
Semantically aligning your DIV names with that of the new html5 elements will help you get used to the names themselves and also the new functionality and nesting that they want you to do with the <header>
and <footer>
elements. These are akin to learning the intro the Enter Sandman (for the guitarist out there); it’s not very difficult, but it takes a little practice to get it to feel natural.Before jumping in full-force to html5 production sites, I recommend trying the soft transition with changing your DIV names slightly. There’s no downside that I’ve found to doing this, you can even use the new DOCTYPE with very little consequence.
First off, I’d like to say: Please don’t do this in production. If the client side scripting fails, it will completely collapse the site in browsers that won’t take CSS applied to the new elements. This is simply not a good option. It is, however, an option and I’m all about knowing your options no matter what they are.
Working in jQuery is cool and all, but as it turns out, there is a built in function to JavaScript to deal with creating new elements:
document.createElement('header'); document.createElement('footer'); document.createElement('section'); document.createElement('aside'); document.createElement('nav'); document.createElement('article'); document.createElement('figure'); document.createElement('time');
…and so on in that fashion.This will allow you to style these elements in Internet Explorer. Again, the downside of using this technique is that, without the all-important JavaScript, the site will not only be unstyled, all the unrecognized elements will default to inline. So your site will literally collapse on itself.Client side JavaScript is not the answer for using html5. Server side javascript, now that’s a completely different story…
I’ve always promoted building sites for your audience, so depending on your audience, building browser-specific applications may be a real option. As I mentioned above, it’s all about controlling the environment, if we can control the environment we can control features delivered to the user much better. Google is currently attempting to do this with Google Wave.The idea behind Google’s new monster product is to revolutionize communication, and do so with the newest technology. Google Wave is built in html5 and isn’t usable in all browsers yet. But that’s alright since they’re controlling the audience by only releasing it to select developers for testing.
With Wave, Google is pushing html5 as far as it will go (and even a little further). They are taking blogs, wikis, instant messaging, e-mail and synchronous communication to the next level by combining them into place.Here is what the Wave inbox looks like.
Below is a sort of wiki/chat area with all sorts of real-time communication treats for you to check out (once they release it).
Google Wave being powered by html5 is definitely the biggest step forward we have seen in this area. They have done a phenomenal job putting together a creative and innovative product.
Just like Google is currently doing with Wave by selectively releasing it to developers, we can control the viewing environment when working with mobile devices. By grabbing the user agent, we can design specific applications that use html5 for supported devices.Targeting the user agent of a device is not an ideal method in designing for the general mobile web, but when we need to specifically target a device, like the iPhone, Pre or Google’s Android it’s a pretty solid option.Right now, the best mobile testing platform we have is the iPhone. With the recent software upgrade, it is very close to having full support. But, if you just want to use the new elements, most any of the big 3 mobile platforms will work fine. If you’re looking for API support I suggest testing on the iPhone with the new upgraded software.
With the strong foundations set up by previous versions of (X)HTML and large community activity surrounding.Web standards, we’re coming into a new age with a wealth of knowledge and the ability to learn from our past mistakes (and make some new ones). html5 is being set up with the expectations of a very powerful markup language and it’s up to us to utilize it in a way that can benefit us all. There are so many great features to look forward to from new elements to tons of killer APIs. We can make data available offline, easily combine technologies and create very intricate animations all within a familiar landscape. If you have the time, I encourage you to browse through the entire spec and familiarize yourself even further with all the bells and whistles (there are a lot) so we can use html5 to build stronger, richer Web applications for years to come.Here’s to html5, let’s hope it lives up to the hype.
Preparing for html5 with Semantic Class Names