猎云网9月15日报道（编译：小酪）
在不久的将来，网速将会变得更快！不过跟汪二条一样悲剧的是，这样的消息还不足以上头条。
虽然我们的设备在提速，科技大佬们可能也创造出了一些超赞的东西，但这都不会是网速提升的根本动力。之所以能大言不惭地说网速即将在不久后得到提升，是因为现在正有一群堪称业界良心的开发人员发现了一个导致网络龟速的问题所在，并决心合力解决这个困难，造！福！人！类！
问题就是网页图片。自今年8月起，Web上排名前1000的网站平均网页大小为1.7兆，而图片大小就占了其中近1兆之多。
如果你用的是光纤，那加载个图片不会有什么大问题。但要上的是移动网络，那爆表的加载值不仅会拖垮网速，还会耗光有限的带宽。万一流量套餐不够用，那大出血的还有你的腰包。
使用移动设备上网时，图片加载还有一点更烦人：明明用的只是巴掌大点的手机，却要加载这些专门为电脑的大屏幕编写出来的图片！耗掉带宽传送一些根本没必要的像素真的是一种资源浪费。
开发人员早就在过去被称为“移动Web”的发展过程中发现了这个问题。最近，他们中的一部分人决定齐心做一件过去人们从来没有尝试过的事情——创造出一种全新的HTML元素。
千里之行，始于“移动Web”
过去，在手机上浏览网页并不像现在这样方便。在为数不多拥有真正Web浏览器的早期手机产品中，即使是第一代iPhone的网页浏览体验也是惨不忍睹。
过去，要想在手机的小屏幕上看清页面上那些专为电脑显示屏优化过的内容，就必须一直点击放大镜进行放大。那会儿要想通过iPhone的龟速EDGE网络加载图片，简直得加载上一辈子；后来Flash网页兴起了，加载的进度条更是不带动的。不过以上这还是用iPhone的体验；要用的是Blackberry或者其它“残疾”系统的移动浏览器开网页，那绝对更心塞。
虽然移动浏览器过去（好吧现在很多情况下也是）远远滞后于他们电脑桌面上的同胞，不过这也不能全怪设备。大部分错误还得怪在Web的开发者身上！Web本就是灵活变通易适应的，但开发人员当初为了大型桌面显示器而做了很多站点优化，在现在看来已然是固步自封。
为了解决这个问题，很多网站都开始建立第二个站点。虽然这些在现在听起来很疯狂，但就在几年前，诸如Blackberry、iPhone和早期Android手机这些新设备浏览网页的解决方法，常常是利用服务器端设备检测脚本将用户重新定位到第二个专门为移动设备准备的站点，典型的例子就是像m.domain.com这样的URL。
但是这类备用移动URL地址——通常默认为M-dot站点——常常缺乏桌面浏览器上对应的地址所具备的特性。很多时候，网站并不能很好地进行跳转，结果就是点击了具体的链接却仍然停留在主页。
开发人员有时很会作死，比如发现一个问题，然后设计出一套解决方法让情况变得更糟糕：M-dot网页就是个很好的例子。不过幸运的是，大多数网页开发人员没有随大溜：因为在越来越多人选择作死之前，事情有了转机。
自适应网页设计：收了M-Dot这妖孽
2010年，Web开发者Ethan Marcotte发表了一篇关于他称为“自适应网页设计”的文章。
Marcotte在文章中建议，随着移动设备数量的激增以及建立备用M-dot站点的痛苦有增无减，重新重视Web固有的自适应本质才是出路，并呼吁各路开发者共同建立灵活性更强的网站。在Marcotte的设想中，站点能够使用相关联的带宽以适应不同的屏幕大小，在任何设备上都能运行良好。
Marcotte的观点启发了开发人员寻找建立自适应网站的方式，并在设备的大小和特性基础上重新组织网页内容。虽然这种自适应网页设计理念可能不是万能之计，但已经很接近了。
自从一些比较有分量的开发者将个人网页进行自适应设计起，自适应网页设计也悄然兴起。但当Marcotte和来自网页设计与前端开发工作室Filament Group的开发人员一起，将波士顿时报网页Boston Globe重新设计为自适应时，这一理念才迅速发展起来。The Globe重新设计的成功证明，除了开发者的个人简历和博客站点外，自适应设计也能在其它网页实现。它还证明，自适应网页设计是未来的发展趋势。
虽然仅从使用者的角度来看，网页的重新设计是成功的，但Marcotte和Filament团队确实也在幕后工作过程中碰到了一些困难，特别是图片方面。Marcotte发表的原文中载明的图片处理方式是利用CSS对图片进行压缩。如此一来就能让图片适应小屏幕的同时保持原有的页面布局，但这也意味着移动设备在不打算把分辨率显示全的情况下，也会加载大图。
其实这种情况在使用小屏幕进行任何网页的浏览时仍有发生。不止那些开发The Globe的开发者，所有开发人员都清楚这是个问题，只不过解决起来并没有想象中的容易。
如今的困境就是这个悲剧结的果。要想解决这个图片问题，就必须给HTML添加一系列新元素。
引进新图片元素
Picture图片元素的提出来自Boston Blobe的开发者，其中包括将最终成为HTML规范合著者的Mat Marquis。
然而，这个项目的参与人员一开始都没有想过创造出一个新的HTML元素，Marquis和其他开发人员都只是想建立一个能够在移动设备上加载得更快的站点。
对此，Marquis的解释是，他们以为他们已经找到解决方法了。“我们从一张移动网络上的图片开始，并在此基础上有选择性地进行加强。它就像个摆弄cookies和JavaScript的黑客，直到网站问世前的一礼拜都在不断壮大。”
同一时期，Firefox和Chrome浏览器都在忙着提升他们的预取能力，而它们的新型图片预取工具更是打破了基于The Globe模板的常规。实际上，浏览器预取已经不仅仅是The Globe初始解决方案中存在的一个问题，更是自适应图片难题的关键。
一般情况下，当计算机服务器给浏览器传来一张网页时，浏览器会首先把所有的HTML下载下来然后再进行解析。现今的Web浏览器则会试图在解析发生之前就进行图片的下载，以提升网页的加载速度。也就是说，在获知图片出现的位置和大小之前，浏览器就能早早开始下载图片。
这是极好的，但同时也是极难办到的。因为这样做意味着既要下载图片，还要对图片信息进行预取，所以即使想下载的是小图，利用JavaScript进行处理实际上还是会拖慢网速。
Marquis和其他参与研究的开发人员不得不抛弃最初的计划重新回到原点：“我们开始绞尽脑汁构思一些能够让我们有所突破的解决方案…但毫无结果。”不过，他们开始把这个问题写成文章发表，吸引了其他开发人员参与探讨。很快，他们就发现在自适应图片的问题上，他们并非奋战的孤军。
遗憾的是，Marquis说：“目前为止，尽管我们的团队拥有10或者15名开发人员，但没人有任何头绪。”
因此，The Globe网站最终以一个没有解决方案的状态发布了。移动设备在下载大图上存在的困难仍旧牢不可破。
虽然The Globe项目外的其他一些开发名人，包括Google的前端开发工程师、Chrome的推广者Paul Irish和Opera公司CEO Bruce Lawson，在此不久后也提出了一些重要的解决方案，但对于开发者发现的所有可能存在的问题，这些方案只是治标不治本。
“我们发现”，Marquis说，“即使我们有能力写一段JavaScript解决掉这个问题，那我们也无法在浏览器层面的优化工作上发挥什么作用。”换句话说，把JavaScript作为解决方法就意味着要跟浏览器内置的预取功能对立。
一来二去，高手之间的对话渐渐转移向一些较低水平的解决方案上了，包括创造出一种新的HTML对象以JavaScript不可能做到的方式解决图片预取的问题。
Bruce Lawson首先提出，问题的解决需要一种新的<picture>标签。虽然他们都不熟悉<picture>，但这在过去确实曾有人提出过，只是不了了之了而已。
欢迎来到标准的世界（可好玩了呢）
Marquis等人确定网页的提速需要一种新的HTML元素是一回事，但要让这个Web标准四分五裂又错综复杂的世界跟着他们一起鼓掌认同就是另一回事了——特别是当团队里没人有过标准制定的经验。
不过比起那些知道前路有多艰难的人，“无知”最大的好处就是会让人义无反顾地坚持走下去。于是参与HTML图片元素研究的开发人员就向WHATWG谏言了。作为监管HTML发展的两大组织之一，网页超文本技术工作小组WHATWG主要是由浏览器厂商构成。因此，要想知道浏览器有多大的可能推广自己的作品，走一趟WHATWG就知道了。
用托尔斯泰的话说，每一个标准机构各有各的不幸。Marquis可能会领教到，看着别人在自己的领域内“指手画脚”，WHATWG可能是最不高兴的那个。不用说，Marquis和其他人吃了闭门羹。
就在这时，另一监管机构HTML WG的总舵万维网联盟W3C开始推行“工作组”。工作组作为W3C试图让行外人员参与进标准制定过程中来的尝试，是一个让Web开发者提出问题并创造解决方案的地方。
不过自从被WHATWG拒之门外后，也有人提出开发者应该自己建立一个工作组。于是自适应图片工作组（RICG）应运而生。
工作组唯一的问题在于不能得到那些权威机构内实际工作组的重视，至少2011年是这样的。
不过Marquis和其他开发者彼时都在乐呵着工作组的成立，并未意识到这点，仍旧在组内热火朝天地开发着自适应图片解决方案。
这要首先要归功于现服务于Mozilla基金会的Marcos Caceres。比起组内的其他成员，Caceres在编制Web标准方面有过一些经验，这使得他能够跨越Web开发和标准开发之间的鸿沟。他将RICG的力量组织起来，协助小组创造出了标准机构一直在寻找的用例和测试。就像Marquis说的：“我们在群里乱成一锅粥，是Marcos站出来把一切规划得井井有条。”
Caceres开玩笑说：“我就像努力看住淘气猫的猫爹。”而他确实也做到了。他创立了Github让一切资源汇集起来，为自适应图片站点开辟出了一片天地，并协助小组将所有资源输入第一个用例文档。Caceres说：“这对我和工作组来说都是相当重要的，它让我们能够将真正需要解决的问题列清楚，并排出紧慢先后。”
几个月的努力过后，RICG再一次把他们的想法告诉了WHATWG。不幸的是他们没能实现逆袭。就像Caceres说的：“那些标准机构总是这样，嘴上说着‘啊我们很希望开发人员向我们提供创意’，不过真的等到开发人员上门了，结果总是很令人遗憾。”
如果你留意过WHATWG IRC自那以后的工作日志，你会发现WHATWG的成员个个都陷入了一种典型的“跟我搞创新就毙掉你”的困境。他们不止会拒绝来自外界开者的建议，还会不顾RICG累死累活的努力，反过来提出自己的解决方案：一种称为set的东西，也是一种只能解决Marquis和他的团队早就发现的诸多问题之一的属性。
不用说，这点让开发人员相当不爽。
这边开发者努力推行着新的HTML图片对象，那边浏览器制造商和标准机构却一意孤行地偏爱那个相比起来更加施展不开的、尽管有点用却相当令人费解的set提案，尤其自从有了个高大上的新名字“srcset”后，RICG看起来更加孤立无援了，好像所有的努力永远都不会有结果一样。
对此，Paul Irish在采访中说：“(Marquis)聚集并引领一批最好的移动Web开发人员，组建了个共享小组，拿着一套解决方案孤芳自赏，在小组内赢得共识，然后起草了一套规范还大张旗鼓地向权威进行提议。标准机构觉得所有‘权威’才该做的事情，这哥们儿基本上已经都干完了。这正是让他们觉得自己的权威备受挑战的地方。”
Irish也不是一个人在战斗。开发者针对WHATWG的提议进行了强烈抗议，强烈到以致于有些全新的提案也被披露出来了。不过浏览器厂商并未就任何事项达成共识：Mozilla基金会否决了WHATWG关于图片的srcset提议，Chrome也一如既往地将图片对象的提议拒之门外。
如果你觉得这些剧情看起来都很狗血……那它确实相当狗血。不管你信不信，如今的局面都是你此刻正用着的Web造成的。
亲！这回我们是真的需要你哦
经历了两败俱伤，WHATWG终于克服了他们“跟我搞创新就毙掉你”症，或者说克服了一点。就这点来说，它还是值得摸摸头的。
WHATWG开始有了折衷，已有不少声音支持RICG的创意进入提案流程。虽然这并不足以说服WHATWG，但至少WHATWG已经安排了一些工作人员与Marquis和RICG合作。尽管他们还是不喜欢Picture，但至少不会公开表示否决了。
在局外人看来，整个过程就像一场乒乓赛，只不过不同的是，每回球被打出去都会变个型。
Picture研究的重大突破要归功于Opera的Simon Pieters和Google的Tab Atkins。他们提出了一个小而有力的建议——将Picture设计为img的包装形式。如此一来，Web上就不会出现同一张图片存在两个分离元素的情况（虽然这相当费解），不过仍需要找到一种全新的方法来控制浏览器该呈现哪一张图片。
以下是最终版本的Picture规范中所使用的方法。
当浏览器处理一个Picture元素时，它首先会检测Web开发人员有可能写入的任何条例。检测过不同的规则后，浏览器会根据自己的标准选择一张最好的图片。这是另一个比较赞的特性，因为浏览器的标准可以自己设定。比如，将来的浏览器可能可以让用户自行设置为3G环境下不加载高清图片，而不管页面上的Picture元素作何建议。一旦决定哪一张图片是最佳选择，浏览器即会在原有的img元素上进行下载并呈现给用户。
这种方法能够一举两得：在浏览器预取问题上，预取动作仍能照旧进行没有冲突；而在浏览器无法识别图片时该作何反应的问题上，浏览器则会返回原有的img标签进行加载。
在最终提案中，Picture被作为img标签的包装而存在。如果浏览器版本过旧无法识别<picture>，那么图片将会以应变备用标识符的形式进行加载。而且所有可能的好处都保留了下来，因为变动的属性仍留在img元素上。
Web赢了，喜大普奔！
想法不错，有成果了么？
说得比唱的好听，可只有当浏览器真正支持这些提案标准，Web才算是真正的赢家。截至去年的这个时候，还没有哪款Web浏览器支持Picture。
尽管Firefox和Chrome都承诺予以支持，但诺言要兑现恐怕还要花上几年。Picture似乎只是个不错的理论。
Enter Yoav Weiss是为数不多的跨界进行Web开发和C++开发的人。Weiss是一个希望把Picture变成Web的一部分的独立承包人。他懂得大多数浏览器编写所用到的C++语言，但此前却从未从事过Web浏览器的研究。
不过Weiss和Caceres一样是个善于牵线搭桥的人，这回他牵线的是Web开发者和C++程序员。熟稔Picture需要做什么以及如何做到，这点让Weiss变得特殊。在同Chromium的其他开发者深入交谈过后，他开始黑入支持Chrome浏览器的引擎Blink。
实施Picture标准并非易事。Weiss说：“将Picture植入Blink需要一些基础设施，而这些设施根本还不曾存在过。所以我有两种选择：要么在接下去两年内等着这些设施自然产生，要么自己动手创造出来。”
但是，作为忙着顾家的新晋爸比，Weiss意识到仅仅利用晚上和周末的时间工作不是长久之计。所以Weiss不得不把自己变成“合同工”：他、Marquis和其他来自工作组的成员在Indiegogo上发起了一项集资活动。
表面上看来，这似乎有点落魄。除了<picture>这个属性之外，开发人员对Web浏览器没有任何可以掌控的地方，更何况这个属性最终还是要投入Web浏览器的怀抱的，为什么他们还要为这个小小的属性做出这么大的牺牲上网集资呢？但不可思议的是，这项集资活动不仅达到甚至超过了预期的资金目标。可见Web开发人员有多希望Picture成功。
可能是因为宣传T-shirt起了作用；可能是这种集资目的比较新奇；也可能是因为Web开发者意识到图片问题解决方案的重要性而浏览器制造商和标准机构却没有。最可能的是，这些可能性甚至更多其它可能性共同起了作用。
项目筹得资金不仅可以让Weiss继续将Picture在Blink内实施，还能让他继续WebKit内核的研究，好让WebKit浏览器（包括苹果iOS版本的Safari）也能具备Picture的属性。于此同时，Caceres也开始了Mozilla内的工作并协助争取Firefox对Picture的支持。
时至今日，Picture对象将于今年底在Chrome浏览器和Firefox浏览器上问世。现在在面向开人员的Chrome浏览器开发版，以及Firefox 34位版也有Picture的影子。
同样是基于Blink的Opera浏览器也将不久的将来支持Picture。虽然没有赶上最新的Safari 8，但苹果也开始通过backport到WebKit的方式对Safari进行Picture属性的添加。而微软也在考虑下一代IE内对Picture予以支持。
Web的未来
Picture的发展历程并非只是一个关于Web开发者如何齐心协力让Web变得更好的有趣故事，它同样也是对未来的惊鸿一瞥。Web的开发和Web标准的制定之间的鸿沟正在逐渐消失，W3C的共享组也在发展壮大，而诸如Move the Web Forward这样致力拉近开发人员创新和标准机构之间距离的网站也如雨后春笋般成长。
甚至还有一个所谓的“specifiction”的专门网站——为Web开发提供一个平台，开发人员能够在此征求所需开发工具、讨论可能的解决方案，然后提供给相关的W3C工作组予以实现。
Picture的开发可能即将告终，但RICG并未走远。实际上，他们已经开始了新项目Element Queries的开发，很快就能来到你身边。
Source：Arstechnica
