無標題文檔

推荐《jQuery 1.4 动画技术》

https://gracecode.b0.upaiyun.com/2011_05_30/1306744111.jpeg

编写网页脚本某种程度上说,不仅仅是光光技术方面,同时需要考虑到很多非技术因素,例如使用动画带给用户体验方面的影响。

而从实际情况下看来,很多为了所谓效果而使用的动画,其实这往往会适得其反。同时,还有很多新手对于动画还保留着莫名的恐惧感。

这里推荐的这本书的名字叫 《jQuery 1.4 Animation Techniques: Beginners Guide》 。但并不要被它的书名所迷惑,总体阅读下来这本书还是需要有一定的基础。Amazon 上有读者就抱怨,‘"beginning" is a little bit of a misnomer’,不过这不影响这本书的所提供的营养价值。

不过还是要抱怨下,本书的后两个章节在我个人看来有些鸡肋。使用 CSS3 以及 Canvas 等「新技术」完成动画并不是什么新鲜的技术,所以加入这些内容未免有些凑数的嫌疑。

三百多页的书,所要搭载的内容显得简单直接而富有价值(看目录其实可以抽看自己感兴趣的章节,似乎并不影响对前后文的理解)。抽空阅读下本书,无论是否使用 jQuery 都会对相关的知识面会有些帮助。

PS,由于时间差以及 jQuery 版本飞快增长的关系,推荐使用 1.6 版本,因为这个版本针对动画有所优化( 详细 )。

-- EOF --

关于 iPad2 的碎碎念

时隔境迁, 当时还在贸然预测 iPad 的时候转眼 iPad 已经发布到了二代

这一年来的 iPad 销售量让苹果又赚得腰包囊鼓鼓 ,所以丝毫不用怀疑 iPad2 未来在市场上的表现。

iPad2 的产品参数早已经被剧透的差不多 ,因此这次 iPad2 的发布似乎并没有给人带来多少的悬念 -- 这让已经铁了心购买一代的人们并不会捶胸顿足。

如果没有记错的话,iPad2 是苹果首台发布的双核处理器的 iOS 设备。硬件方面一向以保守派形象出现的苹果,竟然在 iPad2 上配备了双核处理器,随着苹果产品那惊人的销售速度,相信移动设备的双核处理器时代已经来临。

当然,用户不会总是关心处理器是否是双核,移动设备的续航能力提升远比显卡和处理器等硬件的提升重要得多,否则这只能说明它更适合玩游戏。

iPad2 底部那「丑陋」的喇叭孔,让人觉得这绝非出自苹果的设计,我甚至开始相信这是散热孔。

iPad2 没有装备 Retina 屏是情理之中的事情,装备上 Retina 屏幕成本将不可控制。试想如果 iPad 的价格逼近 MacBook Pro 的话,那么它的境地将会十分的尴尬。再者,是否是 Retina 屏幕这并不重要,相比 iPhone、iPod Touch 的分辨率,iPad 能表现的内容比它们多得多。

iWork 已经完全移植到 iOS 平台之上,因此 iLife 跟上也是时间问题。为何 iLife for iOS 要在 iPad2 发布的时候同时推出?硬件我想是块很大的原因。

iPad2 的影响力注定会远不及元代,它注定是个过度产品。妄自预测下,iPad2 其实真正是为了消化库存,以及为 iPad3 的发布争取时间,如果真是那样, iPad3 的发布时间就会在年底。

如果做类比的话,iPad2 之于 iPad 一代就好比当年的 iPhone 3g 与 iPhone 3gs 的关系一样,那么 iPad3 将会如 iPhone 4 一样,必然会给我们更多的惊喜。

看现在平板电脑的格局,就像是当年的上网本一样。相比 iPad,我其实更看好 MacBook Air 。现在的平板电脑能称之为产业,我想有点早。

iPad2 刚发布,旧款的 iPad 就降价 1k 多为其让路。苹果的产品纯利润到底有多少,这时候大家能否看出一瞥来?不管怎么说这也是好事,至少以后咖啡馆里拿着 iPad 装什么的人会少很多。

那么说了多,到底要不要入手 iPad2?其实,如果您当面问我这样的问题,我敢保证这玩意不是你生活的必需品。

-- EOF --

960 时代的终结

按照惯例,年底的 淘宝 的确是到了「需要改版的时候」。这次新版的淘宝首页上线,乍看并没有多少夺人眼球的地方,但仔细揣摩其中的细节,还是发现了不少的改变。

https://gracecode.b0.upaiyun.com/2011_01_10/1294635311.png

其中有一点就是感觉页面留白过多,仔细看了下发现是页宽从 原来的 960px 拉伸至 1000px。

https://gracecode.b0.upaiyun.com/2011_01_10/1294635263.png

不要小看这个增加了的 40px 页宽,这对于设计师们而言可能是做了个「异常艰难的决定」。

混沌时期

还记得用 Win98 拨号上网的时代吗?那时候分辨率也小得可怜,800x600 的标配分辨率甚至都不及当前的某个高端智能手机。

不知道什么时候开始,网页的页宽有了个经典宽度 600px -- 当然,那时候谁都不会在意它。

960 时代

后来,这个故事变得简单而且老套:随着硬件的发展,分辨率也不断的提升。从 1024x768 到 1280x800 再到 1440x900 甚至更高( 这里有个统计 )。

https://gracecode.b0.upaiyun.com/2011_01_10/1294635802.png

网页的页宽数字也在不断的增加,比较经典的几个数字为从 600px、740px 直到 960px 。然而这时候标准线出现了,那就是 960 页宽。

以淘宝为例,我印象中 960px 页宽从 2006 年沿用至今(2011)已经整整五年。这相比二十一世纪的前五年的页宽改变趋势而言,这实在是让人感到有些变化不大过于拘泥。

当然,设计师们采用 960 这个数字当作页宽的布局方案也有其道理:

  1. 其能兼容大部分的屏幕分辨率。800x600 已死,剩下分辨率最小的也有 1024x768。那么,为了更可能多的展现内容,页面的宽度自然会在 800-1024 像素之间,960 设置数值差不多是个中间值,不多不少刚刚好。
  2. 960px 方便栅格化布局 -- 其实从数学的角度上说,这个观点有点站不住脚。不过 960 页宽的栅格是最早出现的, 同时也是最广泛使用的 (附, 淘宝的栅格系统 )。

打破僵局

既然 960 页宽已经足够好,沿用传统的页宽也并不会犯错,那么回过头来我们再看这次淘宝首页为何要改变成规。

根据我的个人观点,可以总结部分:

  1. 960 页宽已经显得「过时」,1024x768 像素会像当年的 800x600 一样,迟早会被更大数字的分辨率所淹没。
  2. 需求的驱动,需要在页面中加入更多的内容。想想页宽增加 40px 乘以页长,整个页面将会多出多少设计和内容填充空间。
  3. 1000px 这个整数更容易计算和安排栅格 -- 不过从数学上这个说法也很难站住脚。不过整数 1000 的整除数比 960 多多了,也更容易安排。

单单 40 像素的改变,对于「粗心大意」的用户而言似乎无关痛痒(当然,也可以理解为淘宝其实不想让用户过多得在意他们的改变)。

个人觉得 1140 页宽 也是可以考虑的数字。那么,还有会不会有更大的页宽数字出现?我想应该会控制在 1200px 以内, 否则将会给用户阅读带来困扰

未来

我们来预测下未来的经典页宽将会是什么数字?说实话我也不知道,这一答案完全在设计师脑子里。有点可以预料到的是,移动上网设备的兴起会有促进两个大的趋势:

  1. 向下兼容针对小屏幕的弹性页宽( 详见 )。
  2. 页面布局将会针对不同的设备而定制,因此 800px 以下的页宽将会「复活」。

-- Split --

这次广泛采用 HTML5 标签、加大页宽等等的改变,看得出淘宝一直在做着细节方面的尝试和调整。然而从不谐调的留白、布局的不协调看得出来,淘宝对于新的页宽经验稍显不足。

但愿 1000px 这个页宽将又会是个经典的数字。毕竟,不客气的说,「山寨」淘宝首页的站点实在是太多太多了。

PS,淘宝还给我们留了个小彩蛋,新版在首页搜索框中输入「about:staff」会有惊喜(相应代码在 1970 行开始) :^D

-- EOF --

可用性有如此重要?

请原谅我取了个如此有争议的标题,原文的标题是《浏览器不是什么》。我个人觉得作者有点脱离题目,但这并不影响其想要陈述的观点。

可用性 一直是我们前端争论的焦点之一。但仔细想想,我们是否值得为那些连见都没见到过的盲人阅读器或者那些自行禁用 JavaScript 的用户投入额外的、大量的开发成本去「满足」他们?

-- Split --

原文地址: http://blog.istvan-antal.ro/2010/10/what-is-not-a-browser/ 发声 。而后过了段时期,出现了能够同时使用扬声器和声卡的应用程序。

话说回来,现在是否还有人关心自己的机子上有无声卡吗?我想恐怕已经没有。甚至我觉得人们已经遗忘了机箱中的扬声器了。

例如,我从来没有见过某款游戏因为机子上没有声卡而自动关闭其声音--当然,如果我耳朵听不到那是另外回事情(老外的这个说法比较冷)。

说了那么多,上述故事和浏览器以及 JavaScript 的故事非常的相似。不同的是现在的开发人员,在开发应用的时候,仍然在考虑如果没有脚本支持的这一情况。

其实和当年的声卡普及情况差不多,JavaScript 发明于 1995 年(已经是 15 年前了)。当时其在浏览器中的份额不到 1%,而且当时的用户(甚至开发者)都认为这玩意是可有可无的。

我的观点是,每个 Web 应用程序应该能够尽可能的运行在不同环境中,但它并不说明无条件的迁就于某一情况,在任何情况下都表现一致。

例如,在浏览器没有 JavaScript 支持的情况下,新闻类站点仍然可以显示其主要内容(新闻),同时不保证那些依赖 JavaScript 的相册脚本,仍然还能正常工作。

我们现在称之为「浏览器」的应用程序必须为:它能理解 HTML、能使用 CSS 渲染页面、同时能驱动 JavaScript 脚本。某个应用程序只能够完成上述一项或者其中两项功能,那么这压根就无法称之为「浏览器」。

例如,搜索引擎理解 HTML(以及部分 CSS 防止作弊),我们只需要提供内容让其收录 -- 同时它不需要过多的了解 GUI 相关的设计。

从内容方面考虑,其实我只关心两件事物:搜索引擎和浏览器。首先,我第一步需要做的就是创建具有语义的 HTML(这对于 HTML 来说并不容易),然后再使用 CSS 排版并且使其支持现代浏览器,然后再使用 JavaScript 增加针对 IE 的 CSS 规则(很明显原作者非常讨厌 IE)。

我的上述工作流程有时候会收到指责,因为这样必须让老旧的浏览器具备 JavaScript 支持才能引入针对其自身的 CSS 规则。同时情况可能变得模棱两可,我真的不认为我们称之为「浏览器」的玩意竟然不支持 JavaScript,哪怕是那些可以称之为古董的玩意(暗指 IE 吗?)。

总而言之,我们的思路应该为未来而开发,而非迁就过去(We should develop for the future not for the past.)。

我们应该为大多数(用户)而非少数服务。如果我们的用户中有 0.1% 禁用了 JavaScript,那么在我看来,我们可能不值得去耗费大量的开发时间去争取那些 0.1% 的用户。

同时另一个事实是,如果我们让用户觉得在没有使用 JavaScript 的情况下也能使用我们的应用,那么他们会毫不犹豫的禁用它(类似 noscript 插件 )。那么这样,我们推进 Web 的前进几乎是不可能的,我们和用户都会认为 JavaScript 是额外的附属品。

最后,其实我想说明的是:在着手实际开发之前,我们首先规划那些有限的资源(例如时间、人力等)-- 它们的计划投入和实际产出是否能符合我们的预期。

-- EOF --

警惕 WebQQ2.0 的 Gmail 钓鱼

WebQQ 2.0 上线腾讯又多了款重量级的应用 ,但是用过程中发现其 Gmail 模块存在钓鱼的嫌疑。当使用 Chrome 访问其 Gmail 模块时提示为诱骗网站。

http://pic.yupoo.com/feelinglucky/AtjUsvYn/medium.jpg

展开这个页面的 iframe 地址,发现是在 qq.com 域下

https://web2.qq.com/cgi/gmail/gmail.html ,对其感兴趣的可以关注。

UPDATE

-- EOF --

我的照片

嗨!我叫「明城」,八零后、技术男、伪苹果粉、微软无脑黑、宁波佬,现居杭州。

除了我的博客,同时也欢迎您访问我的 GitHubTwitterInstagram 主页。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,因为我曾经为这个名字伤透了脑筋。最后想到的这个名字都没啥特别的,说到 底是因为我实在给它不了个非常酷的名字。

如果您想联系我,可以发我邮件 echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d

注:本站点所持观点仅代表个人意见,不代表所服务公司的立场。

文章

项目

微信公众号