CFXIXI工作室首页
CF西西的博客 | Html5

学习方向

25. 一月 2017
http://www.ferecord.com/webpack-summary.html

Html5

react-tap插件

25. 一月 2017
https://github.com/zilverline/react-tap-event-plugin

Html5

解决IOS滑动触发Body的滑动

14. 一月 2017
参考:http://stackoverflow.com/questions/8488447/iphone-web-app-stop-body-scrolling 解决方法其实很简单,用户上拉时设置滑轮到顶部的位置人为的设置1px 滑到底部加载更多的时候也是如此,这样就能不触发body的滑动事件

Html5

小程序生命周期

11. 一月 2017
转自:http://www.52jb.net/biancheng/8161.html object 参数说明:   属性 类型描述 data Object 页面的初始数据 onLoad Function 生命周期函数--监听页面加载 onReady Function 生命周期函数--监听页面初次渲染完成 onShow Function 生命周期函数--监听页面显示 onHide Function 生命周期函数--监听页面隐藏 onUnload Function 生命周期函数--监听页面卸载 onPullDownRefreash Function 页面相关事件处理函数--监听用户下拉动作 其他 Any 开发者可以添加任意的函数或数据到 object 参数中,用 this 可以访问   示例代码:

Html5

微信小程序开发文档

11. 一月 2017
https://mp.weixin.qq.com/debug/wxadoc/dev/api/?t=201716  

Html5

移动前端调试页面–weinre

23. 十一月 2016
转自:http://web.jobbole.com/82967/ 一:远程调式工具—weinre Weinre是什么? Weinre是Web Inspector Remote的缩写(远程web检查器),它的作用就是相当于chrome的审查元素一样,界面和用法也基本一样,无非不同的是:weinre适合在移动端页面调试,比如手机访问页面的时候,我们可以使用chrome浏览器查看页面的html元素和css代码,我们可以对此进行更改,然后在手机端不需要刷新,立即可以看到效果;在移动端调式html和css比较方便。目前weiner也发布到npm上,我们可以使用npm进行安装;npm如下: https://www.npmjs.com/package/weinre 二: 安装weinre     1 npm install-gweinre 安装完之后,需要在本地开启一个监听服务器,比如我现在的IP地址是:172.16.28.162 现在需要执行如下命令: weinre –boundHost 172.16.28.162 可以开启本地监听服务器如下: 如上面网址 http://172.16.28.162:8080  weinre默认使用8080端口,我们也可以使用如下命令进行更改端口号;如下命令: 三: 访问weinre及在页面上调用 打开浏览器,访问如下地址: 172.16.28.162:8081 如下: 如上截图页面;我们需要在调式的页面中加入远程调式所需要的JS代码即可,比如上图截图的最后一句JS代码:             JavaScript   1 <script src="http://172.16.28.162:8081/target/target-script-min.js#anonymous"></script> 引入到需要远程调式页面即可; 我们现在先访问页面 http://172.16.28.162:8081;如下所示: 现在我们继续使用我手机来访问我本机上的网页后,在查看刚点击进去后的页面显示如下: 如下: 但weinre可以方便我们调式HTML元素及css代码,至于JS,我们可以使用Fiddler替换即可满足前端在移动端基本调式了; 四:多用户 Weinre的默认使用中,都是用anonymous作为id的; 比如上面的代码引用:             JavaScript   1 <script src="http://172.16.28.162:8081/target/target-script-min.js#anonymous"></script> 但是如果多个用户同时调式各自的页面会有问题,weinre使用多用户机制解决该问题。Weinre默认支持多用户的,这样一个局域网同事只需要一台电脑上安装weinre即可,不需要每个人都安装,多个用户同时使用时,每个用户使用自己的id来区分,每个用户调式信息可以独立,不会相互影响; 操作如下: 然后继续刷新设备中的页面,然后在电脑端就可以看到如下信息: 就可以进行多用户调式了;

Html5

anywhere使用方法

23. 十一月 2016
 转自:http://blog.csdn.net/gxz1989611/article/details/38826101 先贴出项目地址,防止大家觉得我唠叨。 平时工作会分享一些文件的场景,但是自己又懒得一个个的拖到qq里分享给大家。之前自己的习惯是把文件放到nginx服务里,碰到文件比较大的时候除了慢慢等拷贝/粘贴,就是更改nginx.conf文件里静态资源服务器的根目录。今天在逛知乎时,偶然看到@朴灵 在这个帖子里的回答,顿时有种“我靠,我要找的就是这个”的感觉。 我们要介绍的就是Anywhere了,安装很简单。只要有node执行环境,直接在命令行中执行:   [plain] view plain copy   npm install anywhere -g   等待若干时间后就安装就完成了。   想要以某个路径作为静态文件服务器的根目录分享,只需要在该目录下执行:   [plain] view plain copy   anywhere   默认不添加 -s 命令会在命令敲击后,同时打开浏览器访问 http://localhost:8000/ 这个路径。   更多命令:   [html] view plain copy   anywhere -p 8000 ## 指定静态服务器的端口号   anywhere -s ## 静默执行,不打开浏览器  

Html5

使用toLowerCase方法将大写英文转成小写

28. 十月 2016
language:(navigator.browserLanguage || navigator.language).toLowerCase()这样能获取纯小写的字符串

Html5

关于location.search

28. 十月 2016
1.document.location.href 返回完整的 URL。 如:http://www.cftea.com/foo.asp?p=1 引用 location.search是从当前URL的?号开始的字符串 如:http://www.51js.com/viewthread.php?tid=22720 它的search就是?tid=22720  通过这个函数就可以轻易取到连接后面带的参数,这个可用户父窗口向子窗口传递参数 eg:  function openTable(id){    var feathers="status=no,width=650px,height=670px,top=0px,menubar=no,resizable=no,scrollbars=yes,toolbar=no,channelmode=no";    var openWin = window.open("allInfo.html?"+id+","+new Date().getTime(),"declare",feathers);    openWin.focus();    }   在allInfo.html页面中如果我们要获取id的值的话,可以这样获得  <script type="text/javascript">        var params= window.location.search;//params:?id,date                var arr = params.substring(1).split(",");                var id = arr[0];    </script>     2.document.location.search 返回 URL 中的 QueryString 部分,含“?”。 如:?p=1

Html5

前端之React实战-JSX介绍与使用

9. 十二月 2015
转自:http://segmentfault.com/a/1190000003748270 JSX HTML 语言直接写在 JavaScript 语言之中,不加任何引号,这就是 JSX 的语法,它允许 HTML 与 JavaScript 的混写。 var names = ['Alice', 'Emily', 'Kate']; React.render( <div> { names.map(function (name) { return <div>Hello, {name}!</div> }) } </div>, document.getElementById('example') ); 上面代码体现了 JSX 的基本语法规则:遇到 HTML 标签(以 < 开头),就用 HTML 规则解析;遇到代码块(以 { 开头),就用 JavaScript 规则解析。JSX 允许直接在模板插入 JavaScript 变量。如果这个变量是一个数组,则会展开这个数组的所有成员: var arr = [ <h1>Hello world!</h1>, <h2>React is awesome</h2>, ]; React.render( <div>{arr}</div>, document.getElementById('example') ); Transfer JSX编译器的核心是将基于XML的语言编译成JS代码,主要是依赖于React.createElment函数。 var Nav; // Input (JSX): var app = <Nav color="blue" />; // Output (JS): var app = React.createElement(Nav, {color:"blue"}); var Nav, Profile; // Input (JSX): var app = <Nav color="blue"><Profile>click</Profile></Nav>; // Output (JS): var app = React.createElement( Nav, {color:"blue"}, React.createElement(Profile, null, "click") ); JavaScript Expressions 属性表达式 如果需要在HTML中混入JavaScript变量值,需要利用{}来代替""。 // Input (JSX): var person = <Person name={window.isLoggedIn ? window.name : ''} />; // Output (JS): var person = React.createElement( Person, {name: window.isLoggedIn ? window.name : ''} ); Boolean Attributes // These two are equivalent in JSX for disabling a button <input type="button" disabled />; <input type="button" disabled={true} />; // And these two are equivalent in JSX for not disabling a button <input type="button" />; <input type="button" disabled={false} />; Child Expressions // Input (JSX): var content = <Container>{window.isLoggedIn ? <Nav /> : <Login />}</Container>; // Output (JS): var content = React.createElement( Container, null, window.isLoggedIn ? React.createElement(Nav) : React.createElement(Login) ); Comments:注释 JSX 里添加注释很容易;它们只是 JS 表达式而已。你只需要在一个标签的子节点内(非最外层)小心地用 {} 包围要注释的部分。 var content = ( <Nav> {/* child comment, put {} around */} <Person /* multi line comment */ name={window.isLoggedIn ? window.name : ''} // end of line comment /> </Nav> ); Multiple Case If-Else 在JSX中是不可以直接在{}中加入if-else的,可以使用下面这种三元表达式: React.render(<div id={condition ? 'msg' : ''}>Hello World!</div>, mountNode); 不过三元表达式往往并不能满足需求,React建议的方式是在JS代码中使用if表达式: var loginButton; if (loggedIn) { loginButton = <LogoutButton />; } else { loginButton = <LoginButton />; } return ( <nav> <Home /> {loginButton} </nav> ); Show-Hide <style type="text/css"> .hidden { display:none; } </style> render: function() { return ( <div className={this.props.shouldHide ? 'hidden' : ''}> This will be hidden if you set <tt>props.shouldHide</tt> to something truthy. </div> ); } Switch-Case return ( <section> <h1>Color</h1> <h3>Name</h3> <p>{this.state.color || "white"}</p> <h3>Hex</h3> <p> {(() => { switch (this.state.color) { case "red": return "#FF0000"; case "green": return "#00FF00"; case "blue": return "#0000FF"; default: return "#FFFFFF"; } })()} </p> </section> ); Loop:循环 全选复制放进笔记 var rows = []; for (var i=0; i < numrows; i++) { rows.push(<ObjectRow />); } return <tbody>{rows}</tbody>;

Html5

css3通过渐变来做2色竖条

5. 十二月 2015
background-image: linear-gradient(top, #33cc33 70%, #ddd 70%, #ddd);background-image: -webkit-linear-gradient(top, #33cc33 70%, #ddd 70%, #ddd);

Html5

如何写出左右顶个的列表样式

3. 十二月 2015
<div> <span class="Title">充值</span> <span class="Result">易方达天天理财</span></div> Title{ display: inline-block; width: 32%; overflow: hidden; white-space: nowrap; text-overflow: ellipsis;}Result{ float: right;}

Html5

IOS IFrame 父窗口调用子窗口事件困惑

13. 十一月 2015
楼主尝试在父窗中使用$("body",window.frames[0].document).trigger("changeChildFrame"); 调用iframe中的body所绑定的事件,发现在android机上可行,在ios上不能执行,非常的困惑。希望以后能够以别的方式解决。  

Html5

webkit-box用法

13. 十月 2015
这篇文章很棒 http://wenlong883.blog.163.com/blog/static/1718109162011102281912385/

Html5

一个制作三角形非常好的网站

10. 十月 2015
一个制作三角形非常好的网站 http://cssarrowplease.com/

Html5

Grunt安装

8. 十月 2015
1.安装nodejs 2.安装npm 3.执行命令npm update -g npm 检查npm升级 4.安装grunt-cli npm install -g grunt-cli 完毕

Html5, Html5 APP

写一个css3页面切换的动画函数

26. 十二月 2014
  movePageHover:function(start, end, anim, callback, _this){ //获得页码数判断切换层级 var startPid = start.attr("pid") || start.attr("bid"); var endPid = end.attr("pid") || end.attr("bid"); //ab为-1,从右到左划。其他则从左到右划 var ab = catchId(startPid,endPid); //定义动画结束时执行的事件 start.css({"display": "block", "zIndex": "1", "opacity": "1"}).off("webkitAnimationEnd").on("webkitAnimationEnd", function(){ start.removeAttr("style"); start.css("display", "none"); }); end.css({"display": "block", "zIndex": "2", "opacity": "1"}).off("webkitAnimationEnd").on("webkitAnimationEnd", function(){ end.removeAttr("style"); end.css("display", "block"); }); //开始定义动画 var moveAnaFrames = $("#_moveAnaFrames_"); if (moveAnaFrames != null) { moveAnaFrames.remove(); } var _styleCss = "<style id='_moveAnaFrames_'>"; var runTime = 0.3; var ease = "ease-out"; switch (anim){ case "move": if (ab != -1) { _styleCss += "@-webkit-keyframes pageAnimateRunCurrent { from {-webkit-transform: translate3d(0px, 0px, 0px);} to {-webkit-transform: translate3d(-100%, 0px, 0px);} }"; _styleCss += "@-webkit-keyframes pageAnimateRunTarget { from {-webkit-transform: translate3d(100%, 0px, 0px);} to {-webkit-transform: translate3d(0px, 0px, 0px);} }"; } else { _styleCss += "@-webkit-keyframes pageAnimateRunCurrent { from {-webkit-transform: translate3d(0px, 0px, 0px);} to {-webkit-transform: translate3d(100%, 0px, 0px);} }"; _styleCss += "@-webkit-keyframes pageAnimateRunTarget { from {-webkit-transform: translate3d(-100%, 0px, 0px);} to {-webkit-transform: translate3d(0px, 0px, 0px);} }"; } break; } _styleCss += "</style>"; $("head").append(_styleCss); //开始执行滑动动画 start.css("-webkit-animation", "pageAnimateRunCurrent " + runTime + "s " + ease); end.css("-webkit-animation", "pageAnimateRunTarget " + runTime + "s " + ease); //start.css("display", "none"); //end.css("display", "block"); if(callback instanceof Function) callback(); return false; },

Html5

Canvas 刮奖

13. 十二月 2013
http://www.cnblogs.com/ms_config/p/3144438.html  

Html5

html5 app人工将一个输入框抬高50px防止键盘挡住输入框影响输入

17. 九月 2013
/* $("#withdrawalAccountInput").on("focus",function(e){ if ($.system.type() == "android") { $("#withdrawalPageScroller").css({ "top": "100px" }); } }).on("blur",function(e){ if ($.system.type() == "android") { $("#withdrawalPageScroller").css({ "top": "46px" }); } });*/

Html5

LET’S TAKE THIS OFFLINE(Html5离线功能讲解)

19. 七月 2013
转自:http://diveintohtml5.info/offline.html LET’S TAKE THIS OFFLINE show table of contents   DIVING IN What is an offline web application? At first glance, it sounds like a contradiction in terms. Web pages are things you download and render. Downloading implies a network connection. How can you download when you’re offline? Of course, you can’t. But you can download when you’re online. And that’s how HTML5 offline applications work. At its simplest, an offline web application is a list of URLs — HTML, CSS, JavaScript, images, or any other kind of resource. The home page of the offline web application points to this list, called a manifest file, which is just a text file located elsewhere on the web server. A web browser that implements HTML5 offline applications will read the list of URLs from the manifest file, download the resources, cache them locally, and automatically keep the local copies up to date as they change. When the time comes that you try to access the web application without a network connection, your web browser will automatically switch over to the local copies instead. From there, most of the work is up to you, the web developer. There’s a flag in the DOM that will tell you whether you’re online or offline. There are events that fire when your offline status changes (one minute you’re offline and the next minute you’re online, or vice-versa). But that’s pretty much it. If your application creates data or saves state, it’s up to you to store that data locally while you’re offline and synchronize it with the remote server once you’re back online. In other words,HTML5 can take your web application offline. What you do once you’re there is up to you. OFFLINE SUPPORT IEFIREFOXSAFARICHROMEOPERAIPHONEANDROID · 3.5+ 4.0+ 5.0+ 10.6+ 2.1+ 2.0+   THE CACHE MANIFEST An offline web application revolves around a cache manifest file. What’s a manifest file? It’s a list of all of the resources that your web application might need to access while it’s disconnected from the network. In order to bootstrap the process of downloading and caching these resources, you need to point to the manifest file, using a manifest attribute on your <html>element. <!DOCTYPE html> <html manifest="/cache.manifest"> <body> ... </body> </html> Your cache manifest file can be located anywhere on your web server, but it must be served with the content typetext/cache-manifest. If you are running an Apache-based web server, you can probably just put an AddType directive in the .htaccess file at the root of your web directory: AddType text/cache-manifest .manifest Then make sure that the name of your cache manifest file ends with .manifest. If you use a different web server or a different configuration of Apache, consult your server’s documentation on controlling the Content-Type header. ASK PROFESSOR MARKUP Q: My web application spans more than one page. Do I need a manifestattribute in each page, or can I just put it in the home page? A: Every page of your web application needs a manifest attribute that points to the cache manifest for the entire application. OK, so every one of your HTML pages points to your cache manifest file, and your cache manifest file is being served with the proper Content-Type header. But what goes in the manifest file? This is where things get interesting. The first line of every cache manifest file is this: CACHE MANIFEST After that, all manifest files are divided into three parts: the “explicit” section, the “fallback” section, and the “online whitelist” section. Each section has a header, on its own line. If the manifest file doesn’t have any section headers, all the listed resources are implicitly in the “explicit” section. Try not to dwell on the terminology, lest your head explode. Here is a valid manifest file. It lists three resources: a CSS file, a JavaScript file, and a JPEG image. CACHE MANIFEST /clock.css /clock.js /clock-face.jpg This cache manifest file has no section headers, so all the listed resources are in the “explicit” section by default. Resources in the “explicit” section will get downloaded and cached locally, and will be used in place of their online counterparts whenever you are disconnected from the network. Thus, upon loading this cache manifest file, your browser would downloadclock.css, clock.js, and clock-face.jpg from the root directory of your web server. Then you could unplug your network cable and refresh the page, and all of those resources would be available offline. ASK PROFESSOR MARKUP Q: Do I need to list my HTML pages in my cache manifest?A: Yes and no. If your entire web application is contained in a single page, just make sure that page points to the cache manifest using the manifest attribute. When you navigate to an HTML page with a manifest attribute, the page itself is assumed to be part of the web application, so you don’t need to list it in the manifest file itself. However, if your web application spans multiple pages, you should list all of the HTML pages in the manifest file, otherwise the browser would not know that there are other HTML pages that need to be downloaded and cached. NETWORK SECTIONS Here is a slightly more complicated example. Suppose you want your clock application to track visitors, using a tracking.cgiscript that is loaded dynamically from an <img src> attribute. Caching this resource would defeat the purpose of tracking, so this resource should never be cached and never be available offline. Here is how you do that: CACHE MANIFEST NETWORK: /tracking.cgi CACHE: /clock.css /clock.js /clock-face.jpg This cache manifest file includes section headers. The line marked NETWORK: is the beginning of the “online whitelist” section. Resources in this section are never cached and are not available offline. (Attempting to load them while offline will result in an error.) The line marked CACHE: is the beginning of the “explicit” section. The rest of the cache manifest file is the same as the previous example. Each of the three resources listed will be cached and available offline. FALLBACK SECTIONS There is one more type of section in a cache manifest file: a fallback section. In a fallback section, you can define substitutions for online resources that, for whatever reason, can’t be cached or weren’t cached successfully. The HTML5specification offers this clever example of using a fallback section: CACHE MANIFEST FALLBACK: / /offline.html NETWORK: * What does this do? First, consider a site that contains millions of pages, like Wikipedia. You couldn’t possibly download the entire site, nor would you want to. But suppose you could make part of it available offline. But how would you decide which pages to cache? How about this: every page you ever look at on a hypothetical offline-enabled Wikipedia would be downloaded and cached. That would include every encyclopedia entry that you ever visited, every talk page (where you can have makeshift discussions about a particular encyclopedia entry), and every edit page (which you can actually make changes to the particular entry). That’s what this cache manifest does. Suppose every HTML page (entry, talk page, edit page, history page) on Wikipedia pointed to this cache manifest file. When you visit any page that points to a cache manifest, your browser says “hey, this page is part of an offline web application, is it one I know about?” If your browser hasn’t ever downloaded this particular cache manifest file, it will set up a new offline “appcache” (short for “application cache”), download all the resources listed in the cache manifest, and then add the current page to the appcache. If your browser does know about this cache manifest, it will simply add the current page to the existing appcache. Either way, the page you just visited ends up in the appcache. This is important. It means that you can have an offline web application that “lazily” adds pages as you visit them. You don’t need to list every single one of your HTML pages in your cache manifest. Now look at the fallback section. The fallback section in this cache manifest only has a single line. The first part of the line (before the space) is not a URL. It’s really a URL pattern. The single character (/) will match any page on your site, not just the home page. When you try to visit a page while you’re offline, your browser will look for it in the appcache. If your browser finds the page in the appcache (because you visited it while online, and the page was implicitly added to the appcache at that time), then your browser will display the cached copy of the page. If your browser doesn’t find the page in the appcache, instead of displaying an error message, it will display the page /offline.html, as specified in the second half of that line in the fallback section. Finally, let’s examine the network section. The network section in this cache manifest also has just a single line, a line that contains just a single character (*). This character has special meaning in a network section. It’s called the “online whitelist wildcard flag.” That’s a fancy way of saying that anything that isn’t in the appcache can still be downloaded from the original web address, as long as you have an internet connection. This is important for an “open-ended” offline web application. It means that, while you’re browsing this hypothetical offline-enabled Wikipedia online, your browser will fetch images and videos and other embedded resources normally, even if they are on a different domain. (This is common in large websites, even if they aren’t part of an offline web application. HTML pages are generated and served locally, while images and videos are served from a CDN on another domain.) Without this wildcard flag, our hypothetical offline-enabled Wikipedia would behave strangely when you were online — specifically, it wouldn’t load any externally-hosted images or videos! Is this example complete? No. Wikipedia is more than HTML files. It uses common CSS, JavaScript, and images on each page. Each of these resources would need to be listed explicitly in the CACHE: section of the manifest file, in order for pages to display and behave properly offline. But the point of the fallback section is that you can have an “open-ended” offline web application that extends beyond the resources you’ve listed explicitly in the manifest file.   THE FLOW OF EVENTS So far, I’ve talked about offline web applications, the cache manifest, and the offline application cache (“appcache”) in vague, semi-magical terms. Things are downloaded, browsers make decisions, and everything Just Works. You know better than that, right? I mean, this is web development we’re talking about. Nothing ever Just Works. First, let’s talk about the flow of events. Specifically, DOM events. When your browser visits a page that points to a cache manifest, it fires off a series of events on the window.applicationCache object. I know this looks complicated, but trust me, this is the simplest version I could come up with that didn’t leave out important information. As soon as it notices a manifest attribute on the <html> element, your browser fires a checking event. (All the events listed here are fired on the window.applicationCache object.) The checking event is always fired, regardless of whether you have previously visited this page or any other page that points to the same cache manifest. If your browser has never seen this cache manifest before... It will fire a downloading event, then start to download the resources listed in the cache manifest. While it’s downloading, your browser will periodically fire progress events, which contain information on how many files have been downloaded already and how many files are still queued to be downloaded. After all resources listed in the cache manifest have been downloaded successfully, the browser fires one final event, cached. This is your signal that the offline web application is fully cached and ready to be used offline. That’s it; you’re done. On the other hand, if you have previously visited this page or any other page that points to the same cache manifest, then your browser already knows about this cache manifest. It may already have some resources in the appcache. It may have the entire working offline web application in the appcache. So now the question is, has the cache manifest changed since the last time your browser checked it? If the answer is no, the cache manifest has not changed, your browser will immediately fire a noupdate event. That’s it; you’re done. If the answer is yes, the cache manifest has changed, your browser will fire a downloading event and start re-downloading every single resource listed in the cache manifest. While it’s downloading, your browser will periodically fire progress events, which contain information on how many files have been downloaded already and how many files are still queued to be downloaded. After all resources listed in the cache manifest have been re-downloaded successfully, the browser fires one final event, updateready. This is your signal that the new version of your offline web application is fully cached and ready to be used offline. The new version is not yet in use. To “hot-swap” to the new version without forcing the user to reload the page, you can manually call the window.applicationCache.swapCache() function. If, at any point in this process, something goes horribly wrong, your browser will fire an error event and stop. Here is a hopelessly abbreviated list of things that could go wrong: The cache manifest returned an HTTP error 404 (Page Not Found) or 410 (Permanently Gone). The cache manifest was found and hadn’t changed, but the HTML page that pointed to the manifest failed to download properly. The cache manifest changed while the update was being run. The cache manifest was found and had changed, but the browser failed to download one of the resources listed in the cache manifest. THE FINE ART OF DEBUGGING, A.K.A. “KILL ME! KILL ME NOW!” I want to call out two important points here. The first is something you just read, but I bet it didn’t really sink in, so here it is again: if even a single resource listed in your cache manifest file fails to download properly, the entire process of caching your offline web application will fail. Your browser will fire the error event, but there is no indication of what the actual problem was. This can make debugging offline web applications even more frustrating than usual. The second important point is something that is not, technically speaking, an error, but it will look like a serious browser bug until you realize what’s going on. It has to do with exactly how your browser checks whether a cache manifest file has changed. This is a three-phase process. This is boring but important, so pay attention. Via normal HTTP semantics, your browser will check whether the cache manifest has expired. Just like any other file being served over HTTP, your web server will typically include meta-information about the file in the HTTP response headers. Some of these HTTP headers (Expires and Cache-Control) tell your browser how it is allowed to cache the file without ever asking the server whether it has changed. This kind of caching has nothing to do with offline web applications. It happens for pretty much every HTML page, stylesheet, script, image, or other resource on the web. If the cache manifest has expired (according to its HTTP headers), then your browser will ask the server whether there is a new version, and if so, the browser will download it. To do this, your browser issues an HTTP request that includes that last-modified date of the cache manifest, which your web server included in the HTTP response headers the last time your browser downloaded the manifest file. If the web server determines that the manifest file hasn’t changed since that date, it will simply return a 304 (Not Modified) status. Again, none of this is specific to offline web applications. This happens for essentially every kind of resource on the web. If the web server thinks the manifest file has changed since that date, it will return an HTTP 200 (OK) status code, followed by the contents of the new file, along with new Cache-Control headers and a new last-modified date, so that steps 1 and 2 will work properly the next time. (HTTP is cool; web servers are always planning for the future. If your web server absolutely must send you a file, it does everything it can to ensure that it doesn’t need to send it twice for no reason.) Once it’s downloaded the new cache manifest file, your browser will check the contents against the copy it downloaded last time. If the contents of the cache manifest file are the same as they were last time, your browser won’t re-download any of the resources listed in the manifest. Any one of these steps can trip you up while you’re developing and testing your offline web application. For example, say you deploy one version of your cache manifest file, then 10 minutes later, you realize you need to add another resource to it. No problem, right? Just add another line and redeploy. Bzzt. Here’s what will happen: you reload the page, your browser notices the manifest attribute, it fires the checking event, and then... nothing. Your browser stubbornly insists that the cache manifest file has not changed. Why? Because, by default, your web server is probably configured to tell browsers to cache static files for a few hours (via HTTP semantics, using Cache-Control headers). That means your browser will never get past step 1 of that three-phase process. Sure, the web server knows that the file has changed, but your browser never even gets around to asking the web server. Why? Because the last time your browser downloaded the cache manifest, the web server told it to cache the resource for a few hours (via HTTP semantics, using Cache-Control headers). And now, 10 minutes later, that’s exactly what your browser is doing. To be clear, this is not a bug, it’s a feature. Everything is working exactly the way it’s supposed to. If web servers didn’t have a way to tell browsers (and intermediate proxies) to cache things, the web would collapse overnight. But that’s no comfort to you after you spend a few hours trying to figure out why your browser won’t notice your updated cache manifest. (And even better, if you wait long enough, it will mysteriously starts working again! Because the HTTP cache expired! Just like it’s supposed to! Kill me! Kill me now!) So here’s one thing you should absolutely do: reconfigure your web server so that your cache manifest file is not cacheable by HTTP semantics. If you’re running an Apache-based web server, these two lines in your .htaccess file will do the trick: ExpiresActive On ExpiresDefault "access" That will actually disable caching for every file in that directory and all subdirectories. That’s probably not what you want in production, so you should either qualify this with a <Files> directive so it only affects your cache manifest file, or create a subdirectory that contains nothing but this .htaccess file and your cache manifest file. As usual, configuration details vary by web server, so consult your server’s documentation for how to control HTTP caching headers. Once you’ve disabled HTTP caching on the cache manifest file itself, you’ll still have times where you’ve changed one of the resources in the appcache, but it’s still at the same URL on your web server. Here, step 2 of the three-phase process will screw you. If your cache manifest file hasn’t changed, the browser will never notice that one of the previously cached resources has changed. Consider the following example: CACHE MANIFEST # rev 42 clock.js clock.css If you change clock.css and redeploy it, you won’t see the changes, because the cache manifest file itself hasn’t changed. Every time you make a change to one of the resources in your offline web application, you’ll need to change the cache manifest file itself. This can be as simple as changing a single character. The easiest way I’ve found to accomplish this is to include a comment line with a revision number. Change the revision number in the comment, then the web server will return the newly changed cache manifest file, your browser will notice that the contents of the file have changed, and it will kick off the process to re-download all the resources listed in the manifest. CACHE MANIFEST # rev 43 clock.js clock.css   LET’S BUILD ONE! Remember the Halma game that we introduced in the canvas chapter and later improved by saving state with persistent local storage? Let’s take our Halma game offline. To do that, we need a manifest that lists all the resources the game needs. Well, there’s the main HTML page, a single JavaScript file that contains all the game code, and… that’s it. There are no images, because all the drawing is done programmatically via the canvas API. All the necessary CSS styles are in a <style> element at the top of the HTML page. So this is our cache manifest: CACHE MANIFEST halma.html ../halma-localstorage.js A word about paths. I’ve created an offline/ subdirectory in the examples/ directory, and this cache manifest file lives inside the subdirectory. Because the HTML page will need one minor addition to work offline (more on that in a minute), I’ve created a separate copy of the HTML file, which also lives in the offline/ subdirectory. But because there are no changes to the JavaScript code itself since we added local storage support, I’m literally reusing the same .js file, which lives in the parent directory (examples/). Altogether, the files look like this: /examples/localstorage-halma.html /examples/halma-localstorage.js /examples/offline/halma.manifest /examples/offline/halma.html In the cache manifest file (/examples/offline/halma.manifest), we want to reference two files. First, the offline version of the HTML file (/examples/offline/halma.html). Since these two files are in the same directory, it is listed in the manifest file without any path prefix. Second, the JavaScript file which lives in the parent directory (/examples/halma-localstorage.js). This is listed in the manifest file using relative URL notation: ../halma-localstorage.js. This is just like you might use a relative URL in an <img src> attribute. As you’ll see in the next example, you can also use absolute paths (that start at the root of the current domain) or even absolute URLs (that point to resources on other domains). Now, in the HTML file, we need to add the manifest attribute that points to the cache manifest file. <!doctype html> <html lang="en" manifest="halma.manifest"> And that’s it! When an offline-capable browser first loads the offline-enabled HTML page, it will download the linked cache manifest file and start downloading all the referenced resources and storing them in the offline application cache. From then on, the offline application algorithm takes over whenever you revisit the page. You can play the game offline, and since it remembers its state locally, you can leave and come back as often as you like.

Html5

【转】Android的WebView控件载入网页显示速度慢的究极解决方案

19. 七月 2013
【转载请注明来源自http://hi.baidu.com/goldchocobo/】        Android客户端中混搭HTML页面,会出现虽然HTML内容载入完成,标题也正常显示,但是整个网页需要等到近5秒(甚至更多)时间才会显示出来。研究了很久,搜遍了国外很多网站,也看过PhoneGap的代码,一直无解。        一般人堆WebView的加速,都是建议先用webView.getSettings().setBlockNetworkImage(true); 将图片下载阻塞,然后在浏览器的OnPageFinished事件中设置webView.getSettings().setBlockNetworkImage(false); 通过图片的延迟载入,让网页能更快地显示。 但是,通过实际的日志发现,Android的OnPageFinished事件会在Javascript脚本执行完成之后才会触发。如果在页面中使用JQuery,会在处理完DOM对象,执行完$(document).ready(function() {});事件自会后才会渲染并显示页面。如下图            可以看到在载入完最后一个JS脚本之后,对DOM元素的渲染和处理就花了8秒,然后执行了AJAX方法载入外部页面又花了2、3秒,最后才会触发onPageFinished显示页面。再往后由于程序中设置了setBlockNetworkImage(false),所以开始载入外部图片。(如果不控制这个参数,图片载入会在渲染期间下载。  综上,由于JS脚本的处理,造成了一张页面打开多花了10秒左右时间。而同样的页面在iPhone上却是载入相当的快,显示完页面才会触发脚本的执行。(提示:如果使用JQueryMobile,更会慢得离谱)          要解决这个问题,就是想办法让浏览器延迟加载JS脚本,但是Android的WebView控件没有这样的参数。无法单独阻塞JS脚本,另外有个setBlockNetworkLoads,用了之后也无法实现类似图片的异步载入的功能,页面成了光板,连CSS也阻塞了。          就是这个问题困扰了很久,直到在做HTML照片墙时,由于setBlockNetworkImage在OnPageFinished之后才会释放,导致在JS脚本载入图片过程中无法获取图片的高宽信息,最后巧妙地通过$(document).ready(function() {setTimeout(func,10)});,成功将函数在onPageFinished之后运行。那么延伸来想,是否可以将JS脚本也用同样的方式延迟载入呢?           答案是肯定的,在http://wonko.com/post/painless_javascript_lazy_loading_with_lazyload可以找到JS脚本延迟加载的第三方组件。          我改造了之前速度奇慢的界面,我所使用的核心JS代码如下:             <script src="/css/j/lazyload-min.js" type="text/javascript"></script>         <script type="text/javascript" charset="utf-8">         loadComplete(){           //instead of document.read()        }         function loadscript()         { LazyLoad.loadOnce([  '/css/j/jquery-1.6.2.min.js',  '/css/j/flow/jquery.flow.1.1.min.js',    '/css/j/min.js?v=2011100852' ], loadComplete);         }         setTimeout(loadscript,10);         </script>                      就是混搭setTimeout和layzload,让JS脚本可以真正在onPageFinish之后执行。         最终执行的效果如图:         可以看到非常显著的改善,从onPageStarted到onPageFinished只用了2秒不到的时间,这个时间主要花在HTML和CSS渲染上。从界面上来看,就是一闪而过的网页载入进度条,立即显示CSS渲染过的页面效果,然后再载入并执行JS脚本,逐块显示需要通过AJAX获取的数据。         综上,解决Android载入WebView页面慢的问题,不是Android程序员的事情,而是Web前端工程师的问题。如果您使用基于WebView的Android第三方壳工具(例如PhoneGap,可以通过这种方式改善UI界面的响应时间)。         发布这个解决方案,希望基于Web的客户端解决方案能更上一层楼,让HTML和原生APP混搭或的纯WEBAPP实现效果可以更理想,功德无量......

Html5

对一个list绑定iscroll

20. 六月 2013
$("#unAvaBalDetPageScroller").style({ 'height' : '100%' }); this.unAvaBalanceDetailPageScroller = new iScroll("unAvaBalDetPageScroller", { snap: 'li', momentum : false, hScrollbar : false, vScrollbar : false, checkDOMChanges : true, onBeforeScrollStart : function(e) { e.preventDefault(); }, //topOffset : pullDownOffset,// 显示 onScrollMove: function(){ }, onScrollEnd: function(){ } }); $(".selectField").style({ 'height' : 45*15 + 'px' }); $('.selectField ul li ').style({ 'height' : 45 + "px" });

Html5

解决Android上e.pageX无法获得问题(touchmove事件监听手的的维度)

17. 六月 2013
在android上touchmove事件监听手的的维度需要使用:   var x = e.targetTouches[0].pageX, y = e.targetTouches[0].pageY; 这点和ios很不同,ios只需要e.pageX就可以了 参考:http://stackoverflow.com/questions/16680331/android-4-x-e-preventdefault-e-pagex-e-pagey-coordinates-non-jquery

Html5

理解CSS3线性渐变(gradient)

14. 六月 2013
转自:http://www.qianduan.net/understand-the-css3-gradient.html 为了显示一个渐变而专门制作一个图片的做法是不灵活的,而且很快会成为一种不好的做法。但是遗憾的是,截至写这篇文章,可能还必须这样做,但是希望不会持续太久。多亏Firefox 和Safari/Chrome,我们现在可以使用最少的努力实现强大的渐变。在本文中,我们将展示CSS渐变的简单实现以及该属性在Mozilla和webkit内核浏览器中的不同。   PS:本文原文本来提供了一个视频,但是由于众所周知的原因,我们无法观看这个在Youtube上的视频,想看的同学请自己想办法观看(最高720P) : http://www.youtube.com/watch?v=9D2hyM5SSCE Webkit 尽管Mozilla和Webkit通常对CSS3属性采取同样的语法,但是对于渐变,他们很不幸的不能达成一致。Webkit是第一个支持渐变的浏览器内核,它使用下面的结构: 1 2 3 4 /* 语法,参考自: http://webkit.org/blog/175/introducing-css-gradients/ */ -webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*) /* 实际用法... */ background: -webkit-gradient(linear, 0 0, 0 100%, from(red), to(blue)); 不要担心这些语法会让你看花眼,我也是这样的!只要记得我们需要用一个逗号来隔开这个参数组。 渐变的类型? (linear) 渐变开始的X Y 轴坐标(0 0 – 或者left-top) 渐变结束的X Y 轴坐标(0 100% 或者left-bottom) 开始的颜色? (from(red)) 结束的颜色? (to(blue)) Mozilla Firefox,从3.6版本才开始支持渐变,更喜欢和Webkit略微不同的语法。 1 2 3 4 5 /* 语法,参考自: http://hacks.mozilla.org/2009/11/css-gradients-firefox-36/ */ -moz-linear-gradient( [ <point> || <angle>,]? <stop>, <stop> [, <stop>]* )   /* 实际用法*/ background: -moz-linear-gradient(top, red, blue); 请注意我们将渐变的类型——linear——放到了属性前缀中了 渐变从哪里开始? (top – 我们也可以使用度数,比如-45deg) 开始的颜色? (red) 结束的颜色? (blue) Color-Stops 如果你不需要从一个颜色到另一个颜色的100%渐变怎么办?这就是color stop起作用的时候了。一个普遍的设计技术是使用一个较短而细微的渐变,比如: 注意顶部的浅灰色到白色的细小的渐变 在过去,标准的做法就是制作一个图片,并将其设为一个元素的背景图片,然后让其水平平铺。然而使用CSS3,这是个小Case。 1 2 3 4 background: white; /* 为较旧的或者不支持的浏览器设置备用属性 */ background: -moz-linear-gradient(top, #dedede, white 8%); background: -webkit-gradient(linear, 0 0, 0 8%, from(#dedede), to(white)); border-top: 1px solid white; 这次,我们让渐变结束于8%,而不是默认的100%。请注意我们也在头部采用了一个边框,以形成对比。这很常用。 如果我们想要添加多一种(几种)颜色,我们可以这样做: 1 2 3 background: white; /* 备用属性 */ background: -moz-linear-gradient(top, #dedede, white 8%, red 20%); background: -webkit-gradient(linear, 0 0, 0 100%, from(#dedede), color-stop(8%, white), color-stop(20%, red); 对于-moz 版本,我们定义,从元素的20%的高度的地方开始是红色。 而对于-webkit,我们使用color-stop,采用两个参数:哪里开始停止,使用哪种颜色。 IE IE并不支持CSS渐变,但是提供了渐变滤镜,可以实现最简单的渐变效果: 1 2 filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#ff0000'); /* IE6,IE7 */ -ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#ff0000')"; /* IE8 */ PS:事实上,我们在《RGBa色彩的浏览器支持》提到的IE的解决方法,就是使用这个渐变滤镜。 关于CSS渐变的一些要点: 尽可能的使用它。如果让IE用户看到一个固定的纯色,我鼓励你使用这种方法; IE6/7/8, Opera, Safari 3, 和Firefox 3 不能渲染CSS3 渐变,Firefox 和Safari用户通常经常升级浏览器,而Chrome的自动升级机制会在后台自动升级,所以这并不是个大问题; 总是为不支持这些浏览器私有属性的浏览器应用一个默认的,纯色背景; 永远不要使用红色到蓝色的渐变,就像我用作例子的这种; 页面无须在每个浏览器里面看起来完全一样! Firefox可以使用角度来设定渐变的方向,而webkit只能使用x和y轴的坐标。

Html5

Html5 各游览器适配对照表

13. 六月 2013
  http://mobilehtml5.org/   html5 cros api http://www.html5rocks.com/en/tutorials/cors/ 

Html5

Html5制作活动按钮

10. 六月 2013
转自:http://bbs.cfxixi.com/showtopic-862.aspx 效果1:点击后效果:附代码: <style>         .box{                 width: 65px;                 padding-top: 11px;                 -webkit-box-flex: auto;         }         .bool[val="yes"] {            /* background-color: #367FDE;*/                 background-color: #CFCFCF;         }         .bool[val="no"] {                 background-color: #CFCFCF;                 /*background-color: #367FDE;*/         }         .bool {                 display: block;                 width: 56px;                 height: 23px;                 padding: 1px 0 0 1px;                 background-color: #367FDE;                 background-image: url(./icon_yn.png);                 background-size: 50px 23px;                 border-radius: 3px;                 box-shadow: 0 0 3px rgba(0, 0, 0, 0.2) inset;         }         .bool[val="yes"] strong {                 margin-left: 31px;         }         .bool[val="no"] strong {                 margin-left: 0;         }         .bool strong {                 width: 23px;                 height: 21px;                 display: block;                 border-radius: 2px;                 /*background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, white), color-stop(100%, #E6E6E6));*/                 background: rgba(0, 0, 0, 0.1);                 -webkit-transition: all .1s linear;                 box-shadow: 0 1px 1px rgba(0, 0, 0, 0.3);         } </style> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js"></script> <script>                                  $(function(){                         var ios6_ = (/iphone\sos\s(6|7|8)/gi).test(navigator.appVersion);                         $(".bool").on("click", function(e){                                 var item=$(this);                                 var _this = $(e.currentTarget);                                 console.log(_this);                                 if( _this.attr("val") == "yes" ) {                                         _this.attr("val", "no");                                         if (ios6_) {                                          _this.find("strong").css({"margin": "0", "-webkit-transform": "translate3d(0, 0, 0)"});                                          }                                         //globalParams [item.attr('xname')]='no';                                 } else {                                         _this.attr("val", "yes");                                         if (ios6_) {                                                 _this.find("strong").css({"margin": "0", "-webkit-transform": "translate3d(31px, 0, 0)"});                                         }                                         //globalParams [item.attr('xname')]='yes';                                 }                                 //localStorage["config"]=JSON.stringify(globalParams);                         });                 })                  </script> </head> <body>         <div class="box">                 <span class="bool" xname="MolecularWeight" val="yes">                         <strong></strong>                 </span>         </div> </body> 复制代码 Demo下载: html5活动按钮.rar (4.02 K, 下载次数:0)

Html5

修改html5 range Button的样式

1. 六月 2013
转自:http://stackoverflow.com/questions/4448491/styling-input-type-range-elements-in-webkit-browsers

Html5

localStorage删除一个键值

28. 四月 2013
转自:http://www.cnblogs.com/beiyuu/archive/2011/07/20/js-localstorage-userdata.html localStorage.removeItem(key):删除指定key本地存储的值 此外: localStorage.getItem(key):获取指定key本地存储的值 localStorage.setItem(key,value):将value存储到key字段

Html5

使用 HTML5 WebSocket 构建实时 即时通信 应用

26. 四月 2013
转自:http://www.ibm.com/developerworks/cn/web/1112_huangxa_websocket/ 作为下一代的 Web 标准,HTML5 拥有许多引人注目的新特性,如 Canvas、本地存储、多媒体编程接口、WebSocket 等等。这其中有“Web 的 TCP ”之称的 WebSocket 格外吸引开发人员的注意。WebSocket 的出现使得浏览器提供对 Socket 的支持成为可能,从而在浏览器和服务器之间提供了一个基于 TCP 连接的双向通道。Web 开发人员可以非常方便地使用 WebSocket 构建实时 web 应用,开发人员的手中从此又多了一柄神兵利器。本文首先介绍 HTML5 WebSocket 的基本概念以及这个规范试图解决的问题,然后介绍 WebSocket 的基本原理和编程接口。接下来会通过一个简单案例来示范怎样实现一个 WebSocket 应用,并且展示 WebSocket 如何在功能强大和编程简单易用上达到的完美统一。最后介绍了目前主流浏览器对 WebSocket 支持的状况、局限性以及未来的展望。 实时 Web 应用的窘境 Web 应用的信息交互过程通常是客户端通过浏览器发出一个请求,服务器端接收和审核完请求后进行处理并返回结果给客户端,然后客户端浏览器将信息呈现出来,这种机制对于信息变化不是特别频繁的应用尚能相安无事,但是对于那些实时要求比较高的应用来说,比如说在线游戏、在线证券、设备监控、新闻在线播报、RSS 订阅推送等等,当客户端浏览器准备呈现这些信息的时候,这些信息在服务器端可能已经过时了。所以保持客户端和服务器端的信息同步是实时 Web 应用的关键要素,对 Web 开发人员来说也是一个难题。在 WebSocket 规范出来之前,开发人员想实现这些实时的 Web 应用,不得不采用一些折衷的方案,其中最常用的就是轮询 (Polling) 和 Comet 技术,而 Comet 技术实际上是轮询技术的改进,又可细分为两种实现方式,一种是长轮询机制,一种称为流技术。下面我们简单介绍一下这几种技术: 轮询: 这是最早的一种实现实时 Web 应用的方案。客户端以一定的时间间隔向服务端发出请求,以频繁请求的方式来保持客户端和服务器端的同步。这种同步方案的最大问题是,当客户端以固定频率向服务器发起请求的时候,服务器端的数据可能并没有更新,这样会带来很多无谓的网络传输,所以这是一种非常低效的实时方案。 长轮询: 长轮询是对定时轮询的改进和提高,目地是为了降低无效的网络传输。当服务器端没有数据更新的时候,连接会保持一段时间周期直到数据或状态改变或者时间过期,通过这种机制来减少无效的客户端和服务器间的交互。当然,如果服务端的数据变更非常频繁的话,这种机制和定时轮询比较起来没有本质上的性能的提高。 流: 流技术方案通常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。这种机制在用户体验上有一点问题,需要针对不同的浏览器设计不同的方案来改进用户体验,同时这种机制在并发比较大的情况下,对服务器端的资源是一个极大的考验。 综合这几种方案,您会发现这些目前我们所使用的所谓的实时技术并不是真正的实时技术,它们只是在用 Ajax 方式来模拟实时的效果,在每次客户端和服务器端交互的时候都是一次 HTTP 的请求和应答的过程,而每一次的 HTTP 请求和应答都带有完整的 HTTP 头信息,这就增加了每次传输的数据量,而且这些方案中客户端和服务器端的编程实现都比较复杂,在实际的应用中,为了模拟比较真实的实时效果,开发人员往往需要构造两个 HTTP 连接来模拟客户端和服务器之间的双向通讯,一个连接用来处理客户端到服务器端的数据传输,一个连接用来处理服务器端到客户端的数据传输,这不可避免地增加了编程实现的复杂度,也增加了服务器端的负载,制约了应用系统的扩展性。   回页首 WebSocket 的拯救 HTML5 WebSocket 设计出来的目的就是要取代轮询和 Comet 技术,使客户端浏览器具备像 C/S 架构下桌面系统的实时通讯能力。 浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求,连接建立以后,客户端和服务器端就可以通过 TCP 连接直接交换数据。因为 WebSocket 连接本质上就是一个 TCP 连接,所以在数据传输的稳定性和数据传输量的大小方面,和轮询以及 Comet 技术比较,具有很大的性能优势。Websocket.org 网站对传统的轮询方式和 WebSocket 调用方式作了一个详细的测试和比较,将一个简单的 Web 应用分别用轮询方式和 WebSocket 方式来实现,在这里引用一下他们的测试结果图: 图 1. 轮询和 WebSocket 实现方式的网络负载对比图  通过这张图可以清楚的看出,在流量和负载增大的情况下,WebSocket 方案相比传统的 Ajax 轮询方案有极大的性能优势。这也是为什么我们认为 WebSocket 是未来实时 Web 应用的首选方案的原因。   回页首 WebSocket 规范 WebSocket 协议本质上是一个基于 TCP 的协议。为了建立一个 WebSocket 连接,客户端浏览器首先要向服务器发起一个 HTTP 请求,这个请求和通常的 HTTP 请求不同,包含了一些附加头信息,其中附加头信息”Upgrade: WebSocket”表明这是一个申请协议升级的 HTTP 请求,服务器端解析这些附加的头信息然后产生应答信息返回给客户端,客户端和服务器端的 WebSocket 连接就建立起来了,双方就可以通过这个连接通道自由的传递信息,并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。 下面我们来详细介绍一下 WebSocket 规范,由于这个规范目前还是处于草案阶段,版本的变化比较快,我们选择 draft-hixie-thewebsocketprotocol-76版本来描述 WebSocket 协议。因为这个版本目前在一些主流的浏览器上比如 Chrome,、FireFox、Opera 上都得到比较好的支持,您如果参照的是新一些的版本话,内容可能会略有差别。 一个典型的 WebSocket 发起请求和得到响应的例子看起来如下: 清单 1. WebSocket 握手协议 客户端到服务端: GET /demo HTTP/1.1 Host: example.com Connection: Upgrade Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 Upgrade: WebSocket Sec-WebSocket-Key1: 4@1 46546xW%0l 1 5 Origin: http://example.com [8-byte security key] 服务端到客户端: HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://example.com WebSocket-Location: ws://example.com/demo [16-byte hash response]   这些请求和通常的 HTTP 请求很相似,但是其中有些内容是和 WebSocket 协议密切相关的。我们需要简单介绍一下这些请求和应答信息,”Upgrade:WebSocket”表示这是一个特殊的 HTTP 请求,请求的目的就是要将客户端和服务器端的通讯协议从 HTTP 协议升级到 WebSocket 协议。从客户端到服务器端请求的信息里包含有”Sec-WebSocket-Key1”、“Sec-WebSocket-Key2”和”[8-byte securitykey]”这样的头信息。这是客户端浏览器需要向服务器端提供的握手信息,服务器端解析这些头信息,并在握手的过程中依据这些信息生成一个 16 位的安全密钥并返回给客户端,以表明服务器端获取了客户端的请求,同意创建 WebSocket 连接。一旦连接建立,客户端和服务器端就可以通过这个通道双向传输数据了。 在实际的开发过程中,为了使用 WebSocket 接口构建 Web 应用,我们首先需要构建一个实现了 WebSocket 规范的服务器,服务器端的实现不受平台和开发语言的限制,只需要遵从 WebSocket 规范即可,目前已经出现了一些比较成熟的 WebSocket 服务器端实现,比如: Kaazing WebSocket Gateway — 一个 Java 实现的 WebSocket Server mod_pywebsocket — 一个 Python 实现的 WebSocket Server Netty —一个 Java 实现的网络框架其中包括了对 WebSocket 的支持 node.js —一个 Server 端的 JavaScript 框架提供了对 WebSocket 的支持 如果以上的 WebSocket 服务端实现还不能满足您的业务需求的话,开发人员完全可以根据 WebSocket 规范自己实现一个服务器。在“WebSocket 实战”这一节,我们将使用 Microsoft .NET 平台上的 C# 语言来打造一个简单的 WebSocket 服务器,继而构建一个简单的实时聊天系统。   回页首 WebSocket JavaScript 接口 上一节介绍了 WebSocket 规范,其中主要介绍了 WebSocket 的握手协议。握手协议通常是我们在构建 WebSocket 服务器端的实现和提供浏览器的 WebSocket 支持时需要考虑的问题,而针对 Web 开发人员的 WebSocket JavaScript 客户端接口是非常简单的,以下是 WebSocket JavaScript 接口的定义: 清单 2. WebSocket JavaScript 定义 [Constructor(in DOMString url, in optional DOMString protocol)] interface WebSocket { readonly attribute DOMString URL; // ready state const unsigned short CONNECTING = 0; const unsigned short OPEN = 1; const unsigned short CLOSED = 2; readonly attribute unsigned short readyState; readonly attribute unsigned long bufferedAmount; //networking attribute Function onopen; attribute Function onmessage; attribute Function onclose; boolean send(in DOMString data); void close(); }; WebSocket implements EventTarget;   其中 URL 属性代表 WebSocket 服务器的网络地址,协议通常是”ws”,send 方法就是发送数据到服务器端,close 方法就是关闭连接。除了这些方法,还有一些很重要的事件:onopen,onmessage,onerror 以及 onclose。我们借用 Nettuts 网站上的一张图来形象的展示一下 WebSocket 接口: 图 2. WebSocket JavaScript 接口  下面是一段简单的 JavaScript 代码展示了怎样建立 WebSocket 连接和获取数据: 清单 3. 建立 WebSocket 连接的实例 JavaScript 代码 var wsServer = 'ws://localhost:8888/Demo'; var websocket = new WebSocket(wsServer); websocket.onopen = function (evt) { onOpen(evt) }; websocket.onclose = function (evt) { onClose(evt) }; websocket.onmessage = function (evt) { onMessage(evt) }; websocket.onerror = function (evt) { onError(evt) }; function onOpen(evt) { console.log("Connected to WebSocket server."); } function onClose(evt) { console.log("Disconnected"); } function onMessage(evt) { console.log('Retrieved data from server: ' + evt.data); } function onError(evt) { console.log('Error occured: ' + evt.data); }     回页首 浏览器支持 下面是主流浏览器对 HTML5 WebSocket 的支持情况: 浏览器支持情况 Chrome Supported in version 4+ Firefox Supported in version 4+ Internet Explorer Supported in version 10+ Opera Supported in version 10+ Safari Supported in version 5+   回页首 WebSocket 实战 这一节里我们用一个案例来演示怎么使用 WebSocket 构建一个实时的 Web 应用。这是一个简单的实时多人聊天系统,包括客户端和服务端的实现。客户端通过浏览器向聊天服务器发起请求,服务器端解析客户端发出的握手请求并产生应答信息返回给客户端,从而在客户端和服务器之间建立连接通道。服务器支持广播功能,每个聊天用户发送的信息会实时的发送给所有的用户,当用户退出聊天室时,服务器端需要清理相应用户的连接信息,避免资源的泄漏。以下我们分别从服务器端和客户端来演示这个 Web 聊天系统的实现,在实现方式上我们采用了 C# 语言来实现 WebSocket 服务器,而客户端是一个运行在浏览器里的 HTML 文件。 WebSocket 服务器端实现 这个聊天服务器的实现和基于套接字的网络应用程序非常类似,首先是服务器端要启动一个套接字监听来自客户端的连接请求,关键的区别在于 WebSocket 服务器需要解析客户端的 WebSocket 握手信息,并根据 WebSocket 规范的要求产生相应的应答信息。一旦 WebSocket 连接通道建立以后,客户端和服务器端的交互就和普通的套接字网络应用程序是一样的了。所以在下面的关于 WebSocket 服务器端实现的描述中,我们主要阐述 WebSocket 服务器怎样处理 WebSocket 握手信息,至于 WebSocket 监听端口的建立,套接字信息流的读取和写入,都是一些常用的套接字编程的方式,我们就不多做解释了,您可以自行参阅本文的附件源代码文件。 在描述 WebSocket 规范时提到,一个典型的 WebSocket Upgrade 信息如下所示: GET /demo HTTP/1.1 Host: example.com Connection: Upgrade Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 Upgrade: WebSocket Sec-WebSocket-Key1: 4@1 46546xW%0l 1 5 Origin: http://example.com [8-byte security key]   其中 Sec-WebSocket-Key1,Sec-WebSocket-Key2 和 [8-byte security key] 这几个头信息是 WebSocket 服务器用来生成应答信息的来源,依据 draft-hixie-thewebsocketprotocol-76 草案的定义,WebSocket 服务器基于以下的算法来产生正确的应答信息: 逐个字符读取 Sec-WebSocket-Key1 头信息中的值,将数值型字符连接到一起放到一个临时字符串里,同时统计所有空格的数量; 将在第 1 步里生成的数字字符串转换成一个整型数字,然后除以第 1 步里统计出来的空格数量,将得到的浮点数转换成整数型; 将第 2 步里生成的整型值转换为符合网络传输的网络字节数组; 对 Sec-WebSocket-Key2 头信息同样进行第 1 到第 3 步的操作,得到另外一个网络字节数组; 将 [8-byte security key] 和在第 3,第 4 步里生成的网络字节数组合并成一个 16 字节的数组; 对第 5 步生成的字节数组使用 MD5 算法生成一个哈希值,这个哈希值就作为安全密钥返回给客户端,以表明服务器端获取了客户端的请求,同意创建 WebSocket 连接 至此,客户端和服务器的 WebSocket 握手就完成了,WebSocket 通道也建立起来了。下面首先介绍一下服务器端实现是如何根据用户传递的握手信息来生成网络字节数组的。.NET 平台提供了很方便的对字符串,数值以及数组操作的函数,所以生成字节数组的方法还是非常简单明了的,代码如下: 清单 4. 生成网络字节数组的代码 private byte[]   BuildServerPartialKey(string clientKey) { string partialServerKey = ""; byte[] currentKey; int spacesNum = 0; char[] keyChars = clientKey.ToCharArray(); foreach (char currentChar in keyChars) { if (char.IsDigit(currentChar)) partialServerKey += currentChar; if (char.IsWhiteSpace(currentChar)) spacesNum++; } try { currentKey = BitConverter.GetBytes((int)(Int64.Parse(partialServerKey) / spacesNum)); if (BitConverter.IsLittleEndian) Array.Reverse(currentKey); } catch { if (currentKey!= null) Array.Clear(currentKey, 0, currentKey.Length); } return currentKey; }   得到网络字节数组以后,服务器端生成 16 位安全密钥的方法如下所示: 清单 5. 生成 16 位安全密钥的代码 private byte[] BuildCompleteServerKey(byte[] serverKey1, byte[] serverKey2, byte[] last8Bytes) { byte[] concatenatedKeys = new byte[16]; Array.Copy(serverKey1, 0, concatenatedKeys, 0, 4); Array.Copy(serverKey2, 0, concatenatedKeys, 4, 4); Array.Copy(last8Bytes, 0, concatenatedKeys, 8, 8); System.Security.Cryptography.MD5 MD5Service = System.Security.Cryptography.MD5.Create(); return MD5Service.ComputeHash(concatenatedKeys); }   整个实现是非常简单明了的,就是将生成的网络字节数组和客户端提交的头信息里的 [8-byte security key] 合并成一个 16 位字节数组并用 MD5 算法加密,然后将生成的安全密钥作为应答信息返回给客户端,双方的 WebSocekt 连接通道就建立起来了。实现了 WebSocket 握手信息的处理逻辑,一个具有基本功能的 WebSocket 服务器就完成了。整个 WebSocket 服务器由两个核心类构成,一个是 WebSocketServer,另外一个是 SocketConnection,出于篇幅的考虑,我们不介绍每个类的属性和方法了,文章的附件会给出详细的源代码,有兴趣的读者可以参考。 服务器刚启动时的画面如下: 图 3. WebSocket 服务器刚启动的画面  客户端可以依据这个信息填写聊天服务器的连接地址,当有客户端连接到聊天服务器上时,服务器会打印出客户端和服务器的握手信息,每个客户的聊天信息也会显示在服务器的界面上,运行中的聊天服务器的界面如下: 图 4. 有客户端连接到 WebSocket 服务器的  以上我们简单描述了实现一个 WebSocket 服务器的最基本的要素,下一节我们会描述客户端的实现。 客户端实现 客户端的实现相对于服务器端的实现来说要简单得多了,我们只需要发挥想象去设计 HTML 用户界面,然后呼叫 WebSocket JavaScript 接口来和 WebSocket 服务器端来交互就可以了。当然别忘了使用一个支持 HTML5 和 WebSocket 的浏览器,在笔者写这篇文章的时候使用的浏览器是 Firefox。客户端的页面结构是非常简洁的,初始运行界面如下: 图 5. 聊天室客户端初始页面  当页面初次加载的时候,首先会检测当前的浏览器是否支持 WebSocket 并给出相应的提示信息。用户按下连接按钮时,页面会初始化一个到聊天服务器的 WebSocekt 连接,初始化成功以后,页面会加载对应的 WebSocket 事件处理函数,客户端 JavaScript 代码如下所示: 清单 6. 初始化客户端 WebSocket 对象的代码 function ToggleConnectionClicked() { if (SocketCreated && (ws.readyState == 0 || ws.readyState == 1)) { ws.close(); } else { Log("准备连接到聊天服务器 ..."); try { ws = new WebSocket("ws://" + document.getElementById("Connection").value); SocketCreated = true; } catch (ex) { Log(ex, "ERROR"); return; } document.getElementById("ToggleConnection").innerHTML = "断开"; ws.onopen = WSonOpen; ws.onmessage = WSonMessage; ws.onclose = WSonClose; ws.onerror = WSonError; } }; function WSonOpen() { Log("连接已经建立。", "OK"); $("#SendDataContainer").show("slow"); }; function WSonMessage(event) { Log(event.data); }; function WSonClose() { Log("连接关闭。", "ERROR"); document.getElementById("ToggleConnection").innerHTML = "连接"; $("#SendDataContainer").hide("slow"); }; function WSonError() { Log("WebSocket错误。", "ERROR"); };   当用户按下发送按钮,客户端会调用WebSocket对象向服务器发送信息,并且这个消息会广播给所有的用户,实现代码如下所示: function SendDataClicked() { if (document.getElementById("DataToSend").value != "") { ws.send(document.getElementById("txtName").value + "说 :\"" + document.getElementById("DataToSend").value + "\""); document.getElementById("DataToSend").value = ""; } };   如果有多个用户登录到聊天服务器,客户端页面的运行效果如下所示: 图 6. 聊天客户端运行页面  至此我们已经完成了一个完整的 WebSocket 客户端实现,用户可以体验一下这个聊天室的简单和快捷,完全不用考虑页面的刷新和繁琐的 Ajax 调用,享受桌面程序的用户体验。WebSocket 的强大和易用可见一斑,您完全可以在这个基础上加入更多的功能,设计更加漂亮的用户界面,切身体验 WebSocket 的震撼力。完整的客户端代码请参阅附件提供的源代码。   回页首 WebSocket 的局限性 WebSocket 的优点已经列举得很多了,但是作为一个正在演变中的 Web 规范,我们也要看到目前用 Websocket 构建应用程序的一些风险。首先,WebSocket 规范目前还处于草案阶段,也就是它的规范和 API 还是有变动的可能,另外的一个风险就是微软的 IE 作为占市场份额最大的浏览器,和其他的主流浏览器相比,对 HTML5 的支持是比较差的,这是我们在构建企业级的 Web 应用的时候必须要考虑的一个问题。   回页首 总结 本文介绍了 HTML5 WebSocket 的横空出世以及它尝试解决的的问题,然后介绍了 WebSocket 规范和 WebSocket 接口,以及和传统的实时技术相比在性能上的优势,并且演示了怎样使用 WebSocket 构建一个实时的 Web 应用,最后我们介绍了当前的主流浏览器对 HTML5 的支持情况和 WebSocket 的局限性。不过,我们应该看到,尽管 HTML5 WebSocket 目前还有一些局限性,但是已经是大势所趋,微软也明确表达了未来对 HTML5 的支持,而且这些支持我们可以在 Windows 8 和 IE10 里看到,我们也在各种移动设备,平板电脑上看到了 HTML5 和 WebSocket 的身影。WebSocket 将会成为未来开发实时 Web 应用的生力军应该是毫无悬念的了,作为 Web 开发人员,关注 HTML5,关注 WebSocket 也应该提上日程了,否则我们在新一轮的软件革新的浪潮中只能做壁上观了。 下载: new-source.zip (93.85 kb)

Html5

12种JavaScript MVC框架之比较

21. 二月 2013
Gordon L. Hempton是西雅图的一位黑客和设计师,他花费了几个月的时间研究和比较了12种流行的JavaScript MVC框架,并在博客中总结了每种框架的优缺点,最终的结果是,Ember.js胜出。 此次比较针对的特性标准有四种,分别是: UI绑定(UI Bindings) 复合视图(Composed Views) Web表现层(Web Presentation Layer) 与其他框架良好协作(Plays Nicely with Others) 对于各种JavaScript MVC框架,Gordon都总结了优缺点: Backbone.js——优点:强大的社区,强劲的势头;缺点:抽象较弱,很多功能亟待增加。 SproutCore——优点:对绑定的支持,可靠的社区,大量特性;缺点:过度规范,难以和不需要的特性解耦。 Sammy.js——优点:易于学习,更容易和现存的服务端应用程序整合;缺点:过于简单,无法应用于大型应用程序中。 Spine.js——优点:轻量级,文档很完备;缺点:它的核心概念“spine”是异步的用户界面,这意味着理想状况用户界面永远不会发生堵塞,而这个基础有缺陷。 Cappuccino——优点:大型深思熟虑后的框架,良好的社区,很棒的继承模型;缺点:由iOS开发者创建,使用JavaScript模拟Objective-C。 Knockout.js——优点:对绑定的支持,完备的文档和教程;缺点:绑定语法拙劣,缺少统一的视图组件层级关系。 Javascript MVC——优点:可靠的社区;缺点:基于字符串的继承模型很差,控制器与视图关系过密而缺少绑定。 GWT(Google Web Toolkit)——优点:全面的框架,良好的社区,可靠的基于Java的组件继承模型;缺点:可能无法经受时间的考验,另外,Java在客户端上的抽象有些笨拙。 Google Closure——优点:很好的基于组件的UI组合系统。缺点:缺少UI绑定支持。 Ember.js——优点:很丰富的模板系统,拥有复合视图和UI绑定;缺点:相对较新,文档不够完备。 Angular.js——优点:对模板范围和控制器设计有很好的考虑,拥有依赖注入系统,支持丰富的UI绑定语法。缺点:代码的模块性不强,视图的模块化也不够。 Batman.js——优点:代码清晰,绑定、持久化的方法简单;缺点:使用了单例控制器。 经过对以上各种Javascript MVC框架特性的比较,Gordon认为只有Ember.js能够完全满足他的要求,从而成为他最终选用的框架。 你是否也使用过某些JavaScript MVC框架呢?欢迎参与讨论。

Html5, Html5 APP

html5重力感应

11. 一月 2013
 http://www.pjhome.net/article/Javascript/html5_Orientation.htm#page=2 html5重力感应    http://www.pjhome.net/web/Orientation.html如果你有iphone 或者手机支持重力感应的话可以试试这个网址他们写的一个简单的demo

Html5

【使用Html5 CfxixiJS制作APP】如何用iscroll制作水平滚动的List布局

25. 十二月 2012
Html5 APP 交流 QQ 群 273843464欢迎您的加入 Demo下载可去lz的Q群共享(273843464) 实现效果如下:   使用iscroll实现这样的布局可不容易。。。需要前端拥有良好的css功底然后利用js(这里lz用了zeptoJS或者大家可以用jquery) 假设我们有这么一段html   [html] view plaincopy   <div id="wrapperIndexActivity" class="wrapperIndexActivity">                   <div class="scrollerActivity" id="scrollerActivity">                           <ul>                                   <li>1</li>                                   <li>2</li>                                   <li>3</li>                                   <li>4</li>                           </ul>                   </div>               </div>     首先先对ID(wrapperIndexActivity)加载iscroll   [javascript] view plaincopy   var homeScroll = new iScroll("wrapperIndexActivity", {           snap : true,           momentum : false,           hScrollbar : false,           vScrollbar : false,           checkDOMChanges : true,           onScrollEnd : function() {                             }   });     对Id所属class附加样式:   [css] view plaincopy   .wrapperIndexActivity{ width:100%;height:100%;position:relative; z-index:1;overflow:hidden;display: block;}         然后需要对ID(scrollerActivity)计算有几幅屏幕可以切换(这里假设有4幅)   [javascript] view plaincopy   $("#scrollerActivity").style({           'width' : document.body.clientWidth * 4 + 'px'       });     对应class需附加样式:   [css] view plaincopy   .wrapperIndexActivity .scrollerActivity{ height:100%; float:left; padding:0;overflow:hidden;}       再然后对li 让每一个列表项都撑满屏幕   [javascript] view plaincopy   $('#wrapperIndexActivity ul li ').style({       'width' : document.body.clientWidth + "px"   });     对应class附加样式:   [css] view plaincopy   .wrapperIndexActivity .scrollerActivity ul li {-webkit-box-sizing:border-box;  display:block; height:100%; float:left;}       最后刷新iscroll   [javascript] view plaincopy   // 刷新数据   omeScroll.refresh();   Demo下载可去lz的Q群共享(273843464)

Html5, CfxixiJS

KnockOutJS介绍

18. 十一月 2012
http://knockoutjs.com/  做前端数据绑定的通过标签绑定的形式基本消除用js通过$去操作dom元素的隐显和样式等等 

Html5

一个“随他去了”推荐的html5流畅框架

18. 十一月 2012
https://github.com/rbiggs/chocolatechip-ui

Html5

webSQL 经常使用的几个必要函数

15. 十一月 2012
http://blog.csdn.net/xiaoguang44/article/details/8186356

Html5, WebSQL

chrome实验室一个html5游动动画

8. 十一月 2012
 http://500.chromeexperiments.com/

Html5

Facebook:“把宝压在HTML5上是一个错误”—技术原因及其反响

8. 十一月 2012
Facebook决定不再使用这两三年所规划的HTML5,回到原生应用的道路上。本文讲述了FB转变背后的技术细节,以及Xamarin和Mozilla对这一转变的反应。 Facebook的CEO 马克·扎克伯格最近在TechCrunch的一次采访中宣称:“作为一个公司,我们最大的错误是在HTML5上下注太多了,我们没有选原生应用,因为HTML5没有达到我们的预期”,而且,“自从发布了iOS应用后,我们发现人们订阅feed的数量增加了一倍。” 扎克伯格没有谈及他们在使用HTML5时遇到的问题,但他认为这些产品的质量不够好:“外界已经有非常好的移动体验了……我们追求最高品质,唯一的办法就是使用原生应用。” Tobie Langel是Facebook软件工程师和W3C咨询委员会代表,他在一篇帖子中详细描述了Facebook基于HTML5做移动网页时遇到的性能问题。Langel提到的第一个问题是缺少调试工具: 移动浏览器缺少工具,从而很难深入进去,发现真正的问题是什么…… 我们遇到的最大的问题是内存相关的。对于给定内容大小,我们的应用很容易耗尽设备硬件能力,引起系统崩溃。不幸的是,我们很难理解到底是什么引起了这些问题。GPU缓存耗尽?达到资源限制?或是其他原因?很难说。 Langel希望知道堆栈、对象、GPU缓存的内存使用情况,以及GC(垃圾回收)周期、FPS和其他资源限制信息。 Langel谈到的HTML5的另一问题是其页面滚动性能,大部分页面滚动通过JavaScript实现,因为“其他选择不够快”。他提道: 不连贯的帧率,UI线程滞后(断断续续)。 由于内容大小和图片数量导致的GPU缓存耗尽。 在不同操作系统中,原生的滚动有着不同的体验。针对一种操作系统优化过的JS实现,在其他系统上的体验却很差(机器人学中的“神秘波谷”)。 安卓设备上触摸事件相关的性能问题(延时,事件不足)使JS实现的页面滚动更加脆弱。 Langel提到的其他问题有:以“黑盒”出现的GPU、安卓系统中更好的触摸跟踪支持的需求、平滑动画以及更好的缓存。其中一些问题已经提交给W3C Web性能工作组。 Nat Friedman是Xamarin的CEO,Xamarin是构建跨平台本机应用的工具提供商。在一次InfoQ评论中,他表示欢迎Facebook的改变:“对包括设备提供商,应用发布商以及最重要的消费者在内的整个移动生态系统而言,这一支持原生体验的转变是非常重要的事件”。他还指出,移动标准现在还为时尚早: 移动创新仍在飞速发展,远超“标准”方式能达到的速度。历史上,当新的操作系统出现时,它的能力非常新,使用它们的唯一方式就是在操作系统层次使用。这一阶段,最好的应用和最具突破性的创新都在靠近操作系统层面出现。对于当前移动设备平台,这种状态非常准确。市场份额的竞赛驱动了设备操作系统层面上巨大的变革和创新。在接下来的几年里,这些操作系统将会稳定下来,这一层次的创新将会变缓,使得标准化方式更加可行。但这种转变需要几年时间。 Mozilla(Mozilla是致力于Web技术的组织)的CTO Brendan Eich在ZDNet对Brendan Eich的采访中,他对Facebook在HTML5上的失败表达了不同的看法: 如果你品一品言外之意,他(马克·扎克伯格)说的应该是将原生应用和HTML糅合起来。当这样糅合时,两个系统间总会有差距。Joe Hewitt是我的一个朋友,他曾在Facebook工作,做了第一个糅合应用,将两者很好地集成起来。但他离开了Facebook,后续版本中,将两者无缝集成的技能(可能还有苹果公司的一些支持)不见了。 Eich坚信Web将最终胜出: 我从不相信Web会失败。这只是个语用学的问题,而你却被这些给绕进去了。 像Facebook这样的公司搞得起开发原生应用,尤其是iOS上的原生应用。但根据长尾理论,开发者将主要集中于开发Web应用,并且以此为乐。 如果Web发展到提供缺失的API,并具有更好的性能,开发者就没必要开发其他应用了。 我有一种感觉,Web将变得非常好(十年之后),那时将不会有现今这样地在原生应用对Web应用之间无休止的论战了。 Matt Asay是The Register的编辑,他在“本机应用vs.HTML5应用的争论”中,引用了一位匿名Facebook工程经理的话说: 现在,Fackbook通过写原生代码是行动最快的。这并不是说HTML5将一直无法达到宣称的效果,而是在当前情况下,摩尔定律和Web引擎仍然有效。因此我们做了一个务实的决定。最终,如果HTML5使得我们发展更快,你将看到我们会回归到HTML5。我们将使用任何让我们高效高质量工作的技术栈。 马克·扎克伯格也看好HTML5的长远前景: 并不是说HTML5不好。长期来看,事实上HTML5真的让我非常兴奋。有趣的是,实际上每天使用移动Web Facebook的人比使用iOS应用或Android应用加起来的更多。因此移动Web对我们来说非常重要。 Facebook八月份发布了iOS本机应用,他们正在开发Android上的类似应用,应该很快会在Google Play应用商店上架。

Html5

ios6 网页实现拍照录像功能

2. 十一月 2012
利用游览器的api现在网页也呢过实现拍照摄像,大家可以参照腾讯微博。 代码示例如下 <input type="file" accept="image/*" capture="camera">  拍照   <input type="file" accept="video/*" capture="camcorder">  摄像   <input type="file" accept="audio/*" capture="microphone">  拍照/摄像

Html5

特殊的链接:打电话,短信,email;iPhone 和Android应用

25. 十月 2012
感谢﹎涳.`鮊 原文:http://www.mmxsoft.com/post-30.html 下面的这篇文章主要是说,网页中的链接如何写,可以激活电话的功能。 例如,页面中展示的是一个电话号码,当用户在手机浏览器里面点击这个电话号码的时候,手机会弹出拨号的面板,或者是短信程序会启动等。 1. 打电话 在android的浏览器中,如果电话号码是 XXX-XXX-XXXX的型式的话,用户点击的时候,拨号面板会激活,但是如果不是这一特定的格式,那么拨号功能是不会启动的。其实可以通过链接的方式激活拨号面板。 (1) IPhone的写法 [phone_number] 就是电话号码了 <a href="callto:[phone_number]">phone_number</a> 例子: <a href="callto:12345678">12345678</a> (2) Android的写法 [phone_number] 就是电话号码了 <a href="wtai://wp/mc;[phone_number]">phone_number</a> 例子: <a href="wtai://wp/mc;12345678">12345678</a> 在电话号码前面可以加上 + (加号)表示国际号码。如: <a href="wtai://wp/mc;+12345678">+12345678</a>   2. 短信 如果是需要调用短信的接口,可以将链接写成下面的格式: sms:<phone_number>[,<phone-number>]*[?body=<message_body>] 例如: <a href="sms:12345678">给 12345678 发短信</a> <a href="sms:12345678?body=hello">给 12345678 发送内容为"hello"的短信</a> <a href="sms:12345678,98765432?body=hello">给12345678和98765432 发送内容为"hello"的短信</a> 3. Android Market 如果希望一个链接能够激活Android市场的功能,可以把链接写成: <a href="market://search?q=[query]">Android Market link</a> 其中<query>就是搜索的内容,你应用的名称 例子: <a href="market://search?q=MyApp">MyApp</a> 4. Ovi Store这是诺基亚Nokia的一个应用市场。 <a href="http://store.ovi.com/content/XXXXX">MyApp</a> XXXX就是你的应用的ID(application Id)。   5. Windows Marketplace 微软的应用市场 <a href="http://marketplace.windowsphone.com/details.aspx?appId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">MyApp</a> 其中 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 只的就是应用的ID   6. BlackBerry App World 黑莓的应用市场 <a href="http://appworld.blackberry.com/webstore/content/XXXXX">MyApp</a> 链接中的XXXX就是应用ID。下面这个是作者页面的URL <a href="http://appworld.blackberry.com/webstore/vendor/XXXX">MyApp</a> 其中的XXXX是指作者的ID   7. 地图定位GPS <a href="geopoint:[经度],[纬度]">我的位置</a> 例如: <a href="geopoint:100,23">我的位置</a> 8. 聊天工具 (1) Yahoo Messager <a href="ymsgr:[动作]?[用户名]&m=[消息]">Yahoo Messager</a> [动作]有:addfriend, sendIM, call 例子: <a href="ymsgr:sendIM?my.account@yahoo.com">给my.account@yahoo.com发消息</a> (2) Windows Messager (MSN) <a href="msnim:[动作]?contact=[用户名]">Windows Messager</a> [动作]有:chat (聊天), add (添加成联系人), voice (语音), video (视频)例子: <a href="msnim:chat?contact=my.account@hotmail.com">MSN</a> (3) Google Talk (GTalk) <a href="gtalk:[动作]?jid=[用户名]&from_jid=[自己的用户名]">GTalk</a> [动作]有:chat (聊天),call (语音) 例子: <a href="gtalk:chat?jid=your@gmail.com&from_jid=my@gmail.com">GTalk</a> (4) Skype <a href="skype:[用户名]?[动作]">Skype</a> [动作]有:chat, add, userinfo, voicemain 例子: <a href="skype:mySkypeId?chat">Skype</a>   9. Mail 邮件 就和普通的html一样使用mailto <a href="mailto:nobody@wordpress.com"></a> <a href="mailto:nobody@wordpress.com,no.one@wordpress.com"></a> <a href="mailto:nobody@wordpress.com?subject=Testing"></a> <a href="mailto:nobody@wordpress.com?subject=Testing mailto&cc=no.one@wrodpress.com"></a>

Html5

一个html5进度条插件

22. 十月 2012
 http://www.andreacammarata.com/tutorials/sencha-touch-2-tutorials/progressbar-development.html

Html5