像我这样需要 To-Do List ，又觉得 Google Calendar 太笨重的人应该不少吧。

Tasks界面如下：(猛击看大图)

或许有些 Gmail 界面设置为中文的朋友的还看不到这个功能，建议修改为英语试试。

开启 Tasks 很容易：点击 Settings → Labs, 选中 Tasks 右边的 Enable ，然后 Save Changes(保存设置) 。

Tasks 标签在 Contacts(通讯录) 下方，图中红色方框标注的地方。点击 list 中任何地方就可以添加任务了。

评论数量(0) | 我想对这篇文章说几句
本文网址：http://sk23.com/blog/gmail-labs-feature-tasks/

© 伤感熊日志, 2008. | 收藏到 Delicious.com

我举一些例子

1.Div和Table之间的误会

刚开始接触到W3C的时候，首先面临的问题是要把传统的table布局给去掉，利用Div+CSS做结构。这个是网页标准化的精髓。但是问题来了，大部分人都因为这个而误会说 “Table没有用了” “你的网页还有table阿，out了”。其实不然，如果这样想，那就大错特错了。W3C只是要求不用table布局，没有说table不标准呀。
每一个web标签都有它存在的意义，不是说完全遗弃某个标签。 我们应该合理利用好每一个标签，table并没有被放弃，相反的table只是回到他的本职工作—用来显示数据，当你要在网页上显示大量的表格数据的时候，就应该用table了，这样你可以花最少的时间，达到最好的效果。假如你一定要用”ul,li”来模拟”table”也可以，但是你将因此耗费过多时间在CSS上面，增加很多多余的代码量，而且还不一定能达到你想要的效果。

最有说服力站点:GMail 你说它不标准吗？不是，你说它全是Div+CSS吗，也不是。它是Div+CSS+Table结构，它合理了利用好了每个网页标签。严格来说GMail并没有按照W3C XHTML 1.0标准去做。首先，它的网页没有用到 XHTML 1.0　的过渡定义。因为它没有办法用，如果用了这个定义去设计GMail。估计大家看不到那么出色的程序了。即使没有用这个标准定义，但是它的CSS能写出这么好的兼容性也是一种最大的成功。

2.Ajax我们是否真的需要
最先带出这个话题的是GMail，这个时候就开始很多人开始研究这个老技术的混合体。现在也开始在泛滥，但是很多时候我们不需要Ajax。简单的说，对于一个普通站点来说，你要宣传就必须要让搜索引擎找到你，但是Ajax最大的问题就是搜索引擎无法判断你里面的内容。就算你的技术多么成熟，做出来的东西不方便宣传，那也是一种失败。
Ajax的主要是为提高程序的易用性为主，所以很多时候都会应用在后台程序中(当然部分操作也可以应用到前台)。来增强程序的人性化，以及易用性。
Ajax最主要是实现了异步更新的功能，这样使网页不用同步显示更多信息。有效的减轻了服务器的负担。而实现异步主要是因为Javascript，而不是XML。为什么这样说呢，没有XML，Javascript同样可以实现异步。但是没有Javascript，光有XML也没用。XML只是作为一种数据来源。我分析了GMail的代码很长一段时间了，又一点很让我感到很奇怪，GMail用到XML的地方其实很少。它主要还是利用了大量的Javascript。里面用得最多的是Javascript和iframe，它解决Js回退靠的是iframe、输出邮件，它直接输出了Javascript代码到一个iframe的页面里面(直接看代码就可以看到)，然后又利用Javascript重新构造这些JS数组，然后输出到网页上。中间的JS数组其实已经是直接写到了页面的，这样的过程用到的XML就很少了。整个GMail用得最多的是异步的JS方式。这样一来GMail也是传统，都是框架在利用JS控制着这个网页。而不是我们现在很多Ajax程序，一个页面上全是读XML,这样的方式是比较愚蠢的。
我们要做的是利用好Ajax里面的 Javascript ，而XML只能作为必要的辅助。

呵呵，文章结束了，以上均是我工作中遇到的问题的一些总结性的看法。希望大家不要因为这两个技术而“误入歧途”，重要的是理智考虑我们的网页如何给这两个技术一个合理的位置。

最后，希望有能力的朋友多去研究研究GMail，你会发现很多和业界炒作的所谓新技术有很多出入。
我对GMail的评价是一个很合理利用了以上两点技术的一个很成功的传统程序。

评论数量(0) | 我想对这篇文章说几句
本文网址：http://sk23.com/blog/gmail-w3c-ajax/

© 伤感熊日志, 2006. | 收藏到 Delicious.com