In the last chapter, we have accomplished some skeleton of our app as well as the important model layer. In this chapter, I will guide you to complete the state management in this app and share some of my knowledge about state charts.

Statecharts

What are state charts? I got to know about state charts when learning about UML, unified modeling language. State chart is one of 23 classical diagrams. In fact, when you are creating model layer, chances are that you will already have used Class Diagram, which is another commonly used diagram of UML.

Of course, State charts exist prior to UML. It was invented by David Harel with his outstanding paper, A Visual Formalism for Complex Systems around 1986.

Sproutcore implements of statecharts inside. All views and event system are driven by it. So, it’s advisable to employ state charts to help us to organize app in case of complicated transitions of various views, concurrent status, etc.

There are three completely different statecharts frameworks for Sproutcore.

• SC.Responder and other related classes inside SC core
• Statecharts of Erich Ocean in the master
• Ki

Responder is the easiest way to implement statecharts in your app. Statecharts are more powerful, but less object-oriented. Ki, is just another story, much more powerful, but in the same time, more difficult to use.

See some discussions about these three frameworks in this post: http://markmail.org/message/o3y4lv2mvokrdxhz#query:+page:1+mid:o3y4lv2mvokrdxhz+state:results

Before I interpret statecharts of Flcikry, you’d get familiar with knowledge in following articles:

• Statecharts and Responders in SproutCore: a simple case
• Routes and Responders in SproutCore: the Routes sample app
• Building Simple Apps with Statecharts, part 1
• Building Simple Apps with Statecharts, part 2
• How to use StateCharts in a SproutCore app

States of Flickry

For this step, we will create three states of Flickry. Of course, in the real life, you app could have many more states to manage. For a later chapter, we will add some sub-states to make the story exciting.

Recall our mockup of this app. Click to see the full size.

It’s easy to find out that interactions in this mockup will trigger following events:

• Search Submit: When you click on the “ok” button of the search dialog, the app will undergo a search action and waits for the search response.
• Return from PhotoStream: When you click “return” button on the stream page. That means you want another search
• Search Cancel: When you click “Cancel” button of the search dialog, the dialog will dismiss and enter stream but without any photos.

The diagram above illustrates the flow of each states, which are driven by different events with the system.

Meet Responders

As mentioned before, we currently have three ways to implement state charts in SC. Considering the fact that statecharts are not the main theme of this tutorial, we choose the easiest way, SC.Responder.

In the world of Sproutcore, we not only have MVC, but also have three other friends, namely SDR. See more at: http://wiki.sproutcore.com/w/page/12412848/Basics-Introducing%20SproutCore%20MVC

As is called, a responder can respond events dispatched by RootResponder or directly assigned by some special views.

Inside responder, we fill the logics of switching of views, changing the look and feel at a larger context, etc.

Let’s create a folder named responder, and then add three empty js files to represent three states in our app: start.js, stream.js ,search.js.

Now, the START state. It’s a transition state of this app, encountered when the app is loaded for the first time. It will check wether we have an existing queries. It seems a little meaningless at present, though.

Open and edit start.js

/*global Flickry, SC */

Flickry.START = SC.Responder.create({
  didBecomeFirstResponder: function() {
    console.log("STATE: enter START");
    var state = Flickry.searchController.get("hasQuery") ? Flickry.STREAM : Flickry.SEARCH;
    Flickry.invokeLater(Flickry.makeFirstResponder, 1, state);
  },

  willLoseFirstResponder: function() {
    console.log("STATE: lose START");
  }
});

didBecomeFirstResponder and willLoseFirstResponder are two special methods that are called upon becoming and losing the status of first responder. We insert a simple console to demonstrate the flow of state transitions. Inside didBecomeFirstResponder method, we check if we “hasQuery”. Due to the fact that we haven’t implemented this customized property yet, it will always make Flickry.SEARCH as its next first responder.

Wo do it in other two files too.

stream.js

/*global Flickry, SC */

Flickry.STREAM = SC.Responder.create({

  didBecomeFirstResponder: function(){
    console.log("STATE: enter STREAM");
  },
  willLoseFirstResponder: function() {
    console.log("STATE: lose STREAM");
  }

});

search.js

/*global Flickry, SC */

Flickry.SEARCH = SC.Responder.create({

  didBecomeFirstResponder: function(){
    console.log("STATE: enter SEARCH");
  },
  willLoseFirstResponder: function() {
    console.log("STATE: lose SEARCH");
  }

});

And we have make Flickry.START the first responder at startup, so in the main.js, we add

Flickry.makeFirstResponder(Flickry.START);

after

Flickry.getPath('mainPage.mainPane').append();

Now, open browse console, refresh. You ought to see the output just like this:

Up to now, the code of this project is at branch “chp1-2″ of the live repo: https://github.com/RobinQu/FlickrySteps/tree/chp1-2

Decorate Flickry

In this step, we will finally see something tangible. Let’s move on to setup the views.

Firstly, rename flickry/resources/main_page.js to stream_page.js. In the resources folder, we also need to create an empty page for our search panel. Call it search_page.js.

StreamPage is most important page in this app. It will display search results, if any. In case of empty result or search dialog is canceled, it will show a search button, which will trigger the search dialog.

Open and edit stream_page.js:

Flickry.streamPage = SC.Page.design({

  mainPane: SC.MainPane.design({
    childViews: "title busket".w(),
    defaultResponder: Flickry,
    title: SC.LabelView.design({
      layout: { left: 0, right: 0, top: 10, heigth: 30 },
      textAlign: SC.ALIGN_CENTER,
      value: "Flickry - a Flickr demo by RobinQu",
      tagName: "h1",
      controlSize: SC.HUGE_CONTROL_SIZE
    }),
    busket: SC.ContainerView.design({
      layout: { left: 0, top: 40, bottom: 0, right: 0 },
      nowShowingBinding: "Flickry.photosController.nowShowing"
    })
  }),

  searchBtn: SC.ButtonView.design({
    textAlign: SC.ALIGN_CENTER,
    layout: { width: 120, height: 24, centerY: 0, centerX: 0 },
    title: "Search Photos",
    action: "search"
  }),

  stream: SC.View.design({
    childViews: "reset list".w(),
    layout: {top:0, left:0, bottom:0, right:0},
    reset: SC.ButtonView.design({
      layout: { centerX: 0, height: 24, width: 100, top: 0},
      title: "Return",
      action: "reset"
    }),
    list: SC.ScrollView.design({
      layout: {left: 0, right: 0, bottom: 0, top: 30},
      contentView: SC.GridView.design({
        exampleView: SC.ImageView,
        columnWidth: 75,
        rowHeight: 75,
        contentValueKey: "url",
        contentBinding: "Flickry.photosController.arrangedObjects"
      })
    })
  }),

  loading: SC.LabelView.design({
    tagName: "h2",
    textAlign: SC.ALIGN_CENTER,
    layout: { left: 0, right: 0, height: 24, centerY: 0 },
    controlSize: SC.HUGE_CONTROL_SIZE,
    value: "Loading..."
  })

});

The code is pretty easy to understand. Put away the layout specs, we only have two child views in main pane of stream page. One is title and another is “busket”, a container view. The container will display correct view according to circumstances.

How can we do that? The magic binding! nowShowing property of a container view can point to a view class or the property path or name of a view. And we bind this view to another property on a controller.

Open and edit flickry/controllers/photos.js:

Flickry.photosController = SC.ArrayController.create(
/** @scope Flickry.photosController.prototype */ {

  isLoading: NO,
  nowShowing: function() {
    if(this.get("isLoading")) {
      return "loading";
    } else {
      return this.get("hasContent") ? "stream" : "searchBtn";
    }
  }.property("hasContent", "isLoading")

}) ;

nowShowing is, in fact, maintained in this controller. isLoading is a switch to represents the loading status of photo results.

Anyway, the result is that when we have results, the “busket” will show Fliclkry.streamPage.mainPane.stream, otherwise Fliclkry.streamPage.mainPane.searchButton.

You should also note that defaultResponder property of mainPane points to Flickry itself. By doing so, the actions generated by user interactions or app itself will be routed to Flickry, which is also a subclass of SC.Responder, first.

Refresh the page, you should now see the title and search button.

Need A Search Panel?

Yes, we need a search panel to carry on the job. Open and edit search_page.js:

/*global SC, Flickry */
Flickry.searchPage = SC.Page.design({
  mainPane: SC.PanelPane.design({
    layout: { centerX: 0, width: 400, centerY: 0, height: 240 },
    defaultResponder: Flickry,
    contentView: SC.View.design({
      childViews: "title keyword username go cancel".w(),
      title: SC.LabelView.design({
        tagName: "h2",
        value: "Enter a Query",
        layout: { top: 10, right: 0, left:0, height: 20 },
        textAlign: SC.ALIGN_CENTER
      }),
      keyword: SC.TextFieldView.design({
        layout: { centerX: 0, top: 40, width: 300, height: 30 },
        hint: "Keyword to Match",
        valueBinding: "Flickry.searchController.keyword"
      }),
      username: SC.TextFieldView.design({
        layout: { centerX: 0, top: 80, width: 300, height: 30 },
        hint: "By Who?",
        valueBinding: "Flickry.searchController.userName"
      }),
      go: SC.ButtonView.design({
        layout: { width: 100, height: 24, left: 50, bottom: 10 },
        title: "Search",
        action: "submit",
        textAlign: SC.ALIGN_CENTER
      }),
      cancel: SC.ButtonView.design({
        layout: {width: 100, height: 24, bottom: 10, right: 50 },
        title: "Cancel",
        action: "cancel",
        textAlign: SC.ALIGN_CENTER
      })
    })
  })
});

As you can see, we create a simple form SC.PanelPane. Besides, we bind the value of inputs to Flickry.serachController. Now, Flickry.serachController acts like a query proxy that stores all the info about current query.

Link Up The Interfaces

Up to now, we have completed the task of defining most user interfaces. But it needs a lot logics to make it really work. In this step, we are going to make this app work like the one in our earlier mockup, but it will not fetch any results for us.

Open the console, you can find that the app actually enter the SEARCH state, it’s just missing a search dialog. We are going to show the panel upon entering this state and remove this panel when leaving this state.

Open and edit flickry/states/search.js:

/*global Flickry, SC */

Flickry.SEARCH = SC.Responder.create({

  didBecomeFirstResponder: function(){
    console.log("STATE: enter SEARCH");

    var pane;
    pane = Flickry.getPath('searchPage.mainPane');
    pane.append(); // show on screen
    Flickry.photosController.set("content", null);//clear the photos before search
    pane.makeFirstResponder(pane.contentView.keyword); // focus first field
  },

  willLoseFirstResponder: function() {
    console.log("STATE: lose SEARCH");
    Flickry.getPath('searchPage.mainPane').remove();
  }

});

It’s pretty clear how we use didBecomeFirstResponder and willLoseFirstResponder to manage the display of the search panel.

Refresh the page, and you should see the search dialog along with an overlay behind it. Recall the state chart we made before. If we don’t have any query existing, we move to SEARCH state.

In fact, when you click on any buttons in this app now, it will trigger action and transmit these actions through responder chains. As responders we created have been add to that chain when we call makeFirstResponder method, they are capable of handling these actions! And they should.

States, represented by a SC.Responder instance, should take charge of what happening during this state.

You can find the action names in the action property of button views. So, in flickry/states/search.js, we need to handle following actions:

• Submit, triggered when “submit” is clicked
• Cancel, triggered when “cancel” is clicked

Open and edit this file:

/*global Flickry, SC */
Flickry.SEARCH = SC.Responder.create({

  didBecomeFirstResponder: function(){
    console.log("STATE: enter SEARCH");

    var pane;
    pane = Flickry.getPath('searchPage.mainPane');
    pane.append(); // show on screen
    Flickry.photosController.set("content", null);//clear the photos before search
    pane.makeFirstResponder(pane.contentView.keyword); // focus first field
  },

  willLoseFirstResponder: function() {
    console.log("STATE: lose SEARCH");
    Flickry.getPath('searchPage.mainPane').remove();
  },

  submit: function() {
    Flickry.makeFirstResponder(Flickry.STREAM);
  },

  cancel: function(){
    Flickry.makeFirstResponder(Flickry.STREAM);
  }

});

Well, we simply change the first responder of the responder chain. That means we want to enter another state.

Open flickry/states/stream.js, we add a handler for “search” and “reset” action, so it looks like:

/*global Flickry, SC */
Flickry.STREAM = SC.Responder.create({
  didBecomeFirstResponder: function(){
    console.log("STATE: enter STREAM");
  },

  willLoseFirstResponder: function() {
    console.log("STATE: lose STREAM");
  },

  search: function() {
    Flickry.makeFirstResponder(Flickry.SEARCH);
  },

  reset: function() {
    Flickry.makeFirstResponder(Flickry.SEARCH);
  }

});

Refresh the page, you can now play with these buttons.

Find those photos

First, we should add support to “hasQuery” property in Flickry.searchController:

Flickry.searchController = SC.ObjectController.create(
/** @scope Flickry.searchController.prototype */ {
  content: SC.Object.create({}),

  hasQuery: function() {
    var query = this.get("content"), k = query.get("keyword"), u = query.get("userName");
    if(query && k && k !=="") {//query exists and has keyword or username as the condition(s)
      return YES;
    }
    return NO;
  }.property("content").cacheable()

});

and open flickry/states/search.js. We have to modify submit method a bit:

submit: function() {
    Flickry.photosController.set("isLoading", YES);//will show "loading"
    var query, photos;
    query = Flickry.searchController.get("content");
    Flickry.PHOTO_QUERY = SC.Query.local(Flickry.Photo, query);
    photos = Flickry.store.find(Flickry.PHOTO_QUERY);
    Flickry.photosController.set("content", photos);
    Flickry.photosController.set("isLoading", NO);

    Flickry.makeFirstResponder(Flickry.STREAM);
  }

Now, this method build a local query with info inside the search controller and stores the results in photos controller. After completion, we enter STREAM state to enjoy the photos.

As we are playing with fixture data. We can only see three photos, no matter what you have typed into the search dialog.

In the next chapter we will discuss how to implement a datasource for flickr so that we can do the real search from flickr database.

All code in this chapter can be found at brach chp1-2 on Github.

但是CSS是被设计来渲染页面的，而不是描述程序外观的。即使是CSS3，在如今应该也是不能满足这个要求的。虽然现在有大量的项目拥有上万行的CSS，但这样的项目对于开发者来说是一个非常巨大的考研。CSS没有变量、命名空间、包这些当今程序思想中最为基本的概念，开发者只能通过事先口头约定进行协同开发。即便是一个人维护CSS，你也不一定记得你几天前写的那些样式是否会和你今天写的有重复的ID，或是你是否在定义冗余的样式。诸如此类的问题仔细想象，会是数不尽的。也许大家会告诉我，这个世界上有Blueprint和960.gs之类的CSS框架啊～可是这些框架在需求超过“布局”、“设备兼容性”之后，你会发现，他们其实并没有解决问题。更本质上的那些由于CSS语言本身而引发的问题，其实是需要一门新的“语言”来解决的。在这里介绍两个这样的“语言”，SASS和{Less}，两者均是CSS3的超集。

{Less}

{Less}想做的事情就是就如同其名字一样，减少CSS的代码量。它在遵循CSS语法的前提下，提供了变量、函数、层级(Nesting)、数值操作等功能。

感觉应该直接上代码来：

Variables

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}

上面的代码演示了less里面，CSS如果有变量是多么方便的一件事。

Mixins

.rounded_corners (@radius: 5px) {
  -moz-border-radius: @radius;
  -webkit-border-radius: @radius;
  border-radius: @radius;
}

#header {
  .rounded_corners;
}

#footer {
  .rounded_corners(10px);
}

你曾经抱怨过写圆角要写N句浏览器前缀的语法么？通过实用mixin，你可以如此潇洒的写那些该死的样式。

Nesting

#header {
  color: red;
  a {
    font-weight: bold;
    text-decoration: none;
  }
}

CSS的子选择器，往往会让你写N多的ID和Class串联起来，实际上你得确定你如果命名层级，最多多少层，等等。这些东西，都只能口头约定。但是如果你通过如上语法进行编写，这些问题其实你已经不需考虑了。

Operation

@the-border: 1px;
@base-color: #111;

#header {
  color: @base-color * 3;
  border-left: @the-border;
  border-right: @the-border * 2;
}

#footer {
  color: (@base-color + #111) * 1.5;
}

最后一个特性，数值操作。不多说了，这个特性省了很多JS代码了。

Deployment

官方要求将这种样式保存为.less扩展名。并且需要命令行工具“翻译”为浏览器能够理解的原生CSS。

当然，还有有一个GUI界面的程序能够进行自动化操作的，Less.app，不过是Mac only的。

SASS, aka, Syntactically Awesome Style Sheet

SASS和Less的原理是一样的，都是在语法上提供CSS3的超集来解决矛盾，并且通过“翻译”生成CSS。但是SASS提供了更为强大的语法和特性。

• SASS支持任何位置的变量，不仅仅可以将其作为属性的数值，还可以作为属性名或者属性名的一部分。
• SASS内置了更多处理函数，例如色彩的精确调节等
• SASS内置了很多你经常会用到的mixin，例如圆角、阴影等，不需要你从头开始写
• …

基本来说，SASS和Less思想一致，但确实两个规模完全是两个概念。可能这也是为什么Sencha本身就是用SASS来写自己主题样式的原因了吧。

详细情况可以看看他们的教程，文档或是安装来看看。

PS 无论是SASS还是{Less}都是需要Ruby环境的，因为其命令行工具都是ruby写的。Windows下的ruby环境其实很不方便，Windows sucks，换Linux或者Mac吧⋯⋯

在这里我介绍三个比较优秀的HTML Start-up Packs。

HTML5 BOILERPLATE

非常帅的一个站点前端骨架。不仅包括apache、nginx的配置文件、crsossdomain.xml、robots.txt、单元测试，它的HTML和CSS文件为移动设备提供了很完善的兼容性（基于Media Query）。

对于新手来说，可能有点太过了。不过即使这样，你也可以抱着学习的心态去学习整个HTML框架的结构。

HTML5 Starter Pack by Radu Chelariu

这个骨架就相对于简单的多，更适合个人网站。仅仅包括必要的font-face和css query支持，以及html5 shim的简单代码。可定制性比较强。

Less Frameworks 2

这个框架强调的就是设备兼容性，思路很清晰，其余部分也是留下很多空间自由发挥的。也是个非常棒的框架。而且它的文件都是在线生成的。

Some Final Thoughts

HTML5的时代其实已经来临，这里也不是讨论HTML5还是Flash的问题了。去迎接HTML5的最好方法还是积极的融入这些技术洪流之内啊。

可以说HTML5解决了一些以往无法解决的问题，例如本地存储、动画、高级选择符等等，可是时代又给了我们新问题，例如浏览设备兼容性。

有一点可以肯定，没有HTML5，Web Developer的日子会更糟糕！

Future Trends

• HTML 5 Won’t Be Ready Until 2022：when on earth can we use HTML5?
• WhatWG, W3C and HTML 5.0：Relationships between W3C, WhatWG and HTML5
• The two specifications of HTML 5.0: WHAT WG vs W3C: the story behind two
• Thoughts On Flash by Steven Jobs

Tutorials for Novices

• DIVE INTO HTML 5
• What You Need To Know About Behavioral CSS
• The future of graphics on the web
• Browsers with wings
• The future of the web
• 15 Useful HTML5 Tutorials and Cheat Sheets
• HTML5 and The Future of the Web
• HTML5 JavaScript API. What’s new?
• W3C School, HTML5 Tutorial
• Understanding CSS3 and CSS2.1 Border Properties

Important Documentations

• HTML5, A vocabulary and associated APIs for HTML and XHTML
• Canvas 2D API Specification
• The Canvas Element
• Apple Safari Developer Center
• HTML5 – MDC
• CSS Properties Index

Live Demos

• Apple HTML5
• CSS3 Examples and Best Practices
• CanvasDemo

Compatibility

• CSS Compatibility and Internet Explorer
• Web Design Checklist
• THE HTML5 TEST，online test suite for html5
• Implementations in Web browsers on WhatWG

Open Source Projects

• HTML5 Canvas for Internet Explorer
• Modernizer.js
• CAKE – Canvas Animation Kit Experiment
• Gordon – An open source Flash™ runtime written in pure JavaScript with SVG
• Smokescreen – convert flash to HTML5/Javascript
• Raphaël: Raphaël is a small JavaScript library that should simplify your work with vector graphics on the web
• Processing.js is an open programming language for people who want to program images, animation, and interactions for the web without using Flash or Java applets.
• Cappuccino is an open source framework that makes it easy to build desktop-caliber applications that run in a web browser.

Online Tools

• JS Bin – an online sandbox for js
• CSS3 Generator
• CSS3, Please!
• Adobe BrowserLab
• Linear Gradients-Css3 Demo
• Box Shadow – Css3 Demo
• transform and transform-origin Css3 Demo
• border-radius Css3 Demo
  
• Transform Matrix – Css3 Demo
• MockFlow

但是看看现实状况，你会非常有喜感，Safari 5、FF3、Chrome 5都已经支持了60％以上的HTML5功能，甚至连IE9 Preview3里面都有好多新功能的支持。

我们何去何从？

完全放弃之前的HTML是不可能的，广大的IE用户群会让你发疯。但这本身就是一种博弈，你如果继续将IE，尤其是IE6作为你的WebApp的主要客户端，那么你就在助长IE6，到头来让开发者更痛苦。

Yahoo所提倡的Progressive Enhancement和Graceful Degradation是两个美好的准则，面对于日益扩张的产品线、快速的产品更新速度，让你觉得多花一行代码给那些垃圾浏览器做功能支持都觉得蛋疼——有时候你甚至连SWFObject都不想用。

当然，我们不能继续停留在抱怨诸如IE之类（也就只有IE）这种垃圾浏览器的怪圈之中。

现在，已经有开发者拥有足够勇气去放弃IE6的支持了。包括google在内的一线厂商，实际上已经再为高级浏览器和IE6单独开发不同的版本的应用。也就是说，如果用户使用老掉牙的IE6进行浏览，他会看到一个催促他们换浏览器的对话框，以及一个Web 1.0的传统应用程序（没有ajax、没有canvas、没有offline功能）。

好吧，在做出这个决定的时候，你可能要说服你的主管去做用户调研以及SWOT分析。

我们不得不承认，我们自己和那些使用高级浏览器的用户没有理由去忍受因为某些弱智浏览器而削弱的用户体验。用户喜欢圆角边框、界面动画、离线存储和更智能的表单等等。

好吧。那些高级浏览器就很好么？其实，大家又回到了上次浏览器大战。Netscape和IE不断的添加自己的私有属性和方法，这就是这次我们遇到的。

诸如”-webkit-”、”-moz-”之类的前缀根本就无法通过W3C的验证，而你也无法保证这些私有的CSS属性的效果是一致的。也许大家写一个CSS3的旋转就得这个样子：

.box_rotate {
     -moz-transform: rotate(7.5deg);  /* FF3.5+
       -o-transform: rotate(7.5deg);  /* Opera 10.5
  -webkit-transform: rotate(7.5deg);  /* Saf3.1+, Chrome
             filter:  progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand',
                     M11=0.9914448613738104, M12=-0.13052619222005157, M21=0.13052619222005157, M22=0.9914448613738104); /* IE6,IE7
         -ms-filter: "progid:DXImageTransform.Microsoft.Matrix(SizingMethod='auto expand',
                     M11=0.9914448613738104, M12=-0.13052619222005157, M21=0.13052619222005157, M22=0.9914448613738104)"; /* IE8
               zoom: 1;
}

实在是太华丽了，这一条CSS规则就可以增大3到4倍，乐观估计整个CSS文档会因为兼容性需求增大2倍吧？

那JS方面呢？webkitTransitionEnd、webkitAnimationEnd⋯⋯乖乖，你这兼容性到底怎么做？

门户站点的前端工程师会哭的，所以HTML5的使用真的是要深思熟虑，考虑到自己的目标浏览器。

总是有人诟骂Adobe Flash是个私有技术，不如HTML5通用，就目前这种状况，现实版的HTML5就是每个浏览器厂商的“私有技术”。每个公司都维护这一套自己的命名规则，自己的文档⋯⋯原来W3C所提倡的“共产主义”就和XX一样⋯⋯

那HTML5真的是爷爷不疼奶奶不爱么？

面向广大的PC端，HTML5的应用需要大量的兼容性代码，甚至考虑到制作IE的降级版本，这个成本，对于小巧型的APP完全ok，做Gmail级别的？还是别找刺激了。

个人认为手机市场才是HTML5的天下。本身手机市场里，系统软件和手机本身都有开发商控制。iPhone下跑Safari的人绝对是占大多数，如果做iPhone4的webapp，完全有可能按照Apple的那些私有版本的HTML5写程序。基本上，满足了webkit引擎，大部分的智能机你都可以搞定了。

再加上还有个WebOS的概念在，可以期待HTML5在移动平台上会先火起来！

另一个HTML5的栖息地，可能是各大厂商的研发中心里。HTML5给了广大开发者另一个快速原型工具。以往，一个设计流程走下来，最终不管你愿意与否，你只能用Flash去实现那些复杂的动画和应用程序逻辑，但是我们现在有Flash。

CSS3的Animation和Transition，HTML5的Canvas足以满足大部门DEMO的要求了吧？

虽然这样，HTML5和CSS3已经“沦为”一个RPD工具了，但是它仍旧证明了其价值所在。

在那些CEO眼里，HTML5也将成为遏制Adobe Flash扩张的法宝。微软的Silverlight如此疲软，Apple也是希望能够将效率地下的Flash敢出移动平台⋯⋯

好吧，让我们拭目以待。我们能做的，可能只有把HTML5和Flash全部学一遍吧⋯⋯泪⋯⋯

Read More

Read More

这篇文章是目前少数一些介绍即将取代CSS2的新标准——CSS3的文章。我们将从非常基础的东西开始讲解，即使你对CSS3毫无了解，读完了之后相信也能很好的介绍这些将被广泛使用的一些功能。

什么是CSS3

CSS3带来的一些改变，为你在创造新的具有冲击力的设计提供更多方法。这篇教程提供了一些关于这个新标准带给我们的一些可能性。

模块

CSS3的开发被分为不同的“模块”。之前的划分方法太过于庞大、复杂，以至于更新十分困难，所以它被打散，并且有所增添。其中的一部分模块包括：

• 盒模型
• 列表模型
• 超链接的表现
• 语音模块
• 背景以及边框
• 文字效果
• 多栏布局

察看模块的完整列表

开发日程

包括SVG（可缩放矢量图型）、媒体查询和命名空间的一些模块已经完全开发完毕。其他的也会很快跟进。但是预测众多浏览器合适才能支持CSS3的新功能确实无比的困难。Safari的新版本已经支持了一些。

准确的说想在近两年内完成对CSS3的大范围支持是不太可能的事情，因为微软向来不太支持标准化。FF和Safari的支持加起来也不到一半的用户量，对CSS3的推广不是决定性的。但是IE支持若干CSS3属性确实相当有可能的，例如IE8已经支持一些选择符语法。长期之内，我们还会和hacks打交道。

CSS3将如何影响我？

CSS3能完全的向后兼容，这样我们就不用更改先用得设计。浏览器也会继续支持CSS2。

主要的冲击来自于新的选择符使用方法以及新的属性。这些能帮助我们实现一些新的功能（比如动画或渐变效果），或者改良现有设计（比如说使用列）。

这一系列文章的之后部分会介绍CSS3的一些模块以及他们的新功能。

CSS3模块——边框

用过CSS的人都知道border属性——它是一个构建内容结构、创造图片相框以及改善页面结构的好方法。CSS3将border属性提升到另一个高度，它允许使用渐变、圆角、阴影或图片来创造边框。我们来一一解说。

圆角边框

使用现在的CSS2完成圆角边框很困难，虽然有很多种可用的办法，可是没有一个是直接了当的。往往都涉及额外的图片。

用CSS3创建圆角边框则非常简单，代码如下：

.border_rounded {
background-color: #ddccb5;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border: 2px solid #897048;
padding: 10px;
width: 310px;
}

渐变边框

渐变边框用起来可以让内容看起来很显眼。

这些代码有些复杂，要求你定义渐变中的每个颜色：

.border_gradient {
border: 8px solid #000;
-moz-border-bottom-colors:#897048 #917953 #a18a66 #b6a488 #c5b59b #d4c5ae #e2d6c4 #eae1d2;
-moz-border-top-colors:  #897048 #917953 #a18a66 #b6a488 #c5b59b #d4c5ae #e2d6c4 #eae1d2;
-moz-border-left-colors: #897048 #917953 #a18a66 #b6a488 #c5b59b #d4c5ae #e2d6c4 #eae1d2;
-moz-border-right-colors:#897048 #917953 #a18a66 #b6a488 #c5b59b #d4c5ae #e2d6c4 #eae1d2;
padding: 5px 5px 5px 15px;
width: 300px;
}

容器的阴影

目前来说给一个元素添加阴影是相当苦难能的。

但在CSS中：

.border_shadow {
-webkit-box-shadow: 10px 10px 5px #888;
padding: 5px 5px 5px 15px;
width: 300px;
}

边框图片

边框图片是最有用的新增功能之一，我真的对人们将如何使用这个功能而感到好奇。CSS将有能你为你重复、伸展你选择的边框图片。

CSS代码会和下面的这些类似（目前这些代码根据不同的浏览器将有所不同）：

.border_image {
-webkit-border-image: url(border.png) 27 27 27 27 round round;
}

CSS模块——字体

字体无疑是设计排版时的一个重要方面。文字能引导读者穿越整个页面，留下某种印象，产生冲击力，或者其他一些微妙的效果。
CSS目前已经在文字显示方面具备很多功能，但还是在某些方面限制了设计。CSS3正朝着减少这些限制的方向而努力。

文字阴影

字体阴影听起来并不是那么好，但这要看你怎么运用它。当我在为这篇文章做测试的时候，我发现有一些组合看起来很具有吸引力。阴影用在标题上是很不错的。Matthias Kretschmann的BLOG上面有一些很好的例子。

.text_shadow {
color: #897048;
background-color: #fff;
text-shadow: 2px 2px 2px #ddccb5;
font-size: 15px;
}

文字换行

目前，如果一个词太长以至于一行都装不下，它就会跨越边界，造成溢出。这个现象不是很常见，但偶尔也能遇到。新的文字换行功能将会强迫文字去换行，即使这会造成词语分裂。

实现这个的代码是很简单的：

.text_wrap {
word-wrap:  break-word;
}

在线字体

虽然这个严格地说不算是“字体效果”，但我们还是打算包含这一条。在线字体的使用能让浏览器自动的下载你指定的字体。这个改变对于网页设计将是革命性的，因为之前的设计都仅限于10到15种被广泛支持的字体。但是，这个新功能有可能造成一些版权的争议。

目前Safari的最新版本（3.1）是唯一支持在线字体的浏览器。Opera马上也会支持这个功能，其他的浏览器也会马上跟进。下面是实现这个功能的代码：

@font-face {
font-family: 'Name of the new font';
src: url('http://www.designshack.co.uk/fonts/font.ttf');
}

目前已经有一些页面使用了这个功能。下面的例子就是CSS Zen Garden里面的页面，其作者是A List Apart。当然这个页面只能在某些浏览器里面正常显示：

CSS模块——用户界面

CSS3增加了很多关于用户界面方面的新属性，例如元素的尺寸伸缩、光标手势、轮廓(Outlining)、盒状布局(Box Layout)等等。我们将关注其中三个最重要的增强属性。

缩放

最新版的Safari是能够允许元素的缩放的。CSS3允许你将这个属性应用到任意元素，这将使缩放这个功能拥有跨浏览器的支持。

实现代码如下：

.ui_resizable {
padding: 20px;
border: 1px solid;
resize: both;
overflow: auto;
}

盒尺寸(Box Sizing)

关于CSS3的盒模型已经是属于本文的扩展领域了，完整的信息你可以到官方站点找到。就单独盒尺寸这个方面来说，它能够让你定义元素以何种方式填充一个容器。举例来说，如果你想将两个有边框的盒子（译者注：即通常概念下按照盒模型计算的容器）毗邻的紧紧的卡在另一个容器内，你就可以通过设置”box-sizing”为”border-box”。这个值将强迫浏览器把padding和border的宽度放在盒子的内部（译者注：即不会向外”扩张“了）。

目前，可能需要使用一些私有属性才能让所有浏览器都支持这个功能。这里给出一个很基本的例子：

.area {/* 放置这两个盒子的容器  */
width: 300px;
border: 10px solid #ddccb5;
height: 60px;
}
.boxes {/* 应用属性的盒子 */
box-sizing: border-box;
width:50%;
height: 60px;
text-align: center;
border: 5px solid #897048;
padding: 2px;
float:left;
}

轮廓

在CSS2里面我们已经能通过设置border属性给一个元素设置轮廓边框了，但是在CSS3我们可以通过设置一个数值而更方便地设置边框的偏移。同时，它和border属性有两点不同：

• 轮廓是不占用控件的
• 轮廓不一定是矩形的

你可以通过如下代码创建：

.ui_outline {
width: 150px;
padding: 10px;
height: 70px;
border: 2px solid black;
outline: 2px solid #897048;
outline-offset: 15px;
}

这篇文章并完成，近日将有更新！