Web Platform Blog for China

Adobe

decor

Making the web awesome

归档

iOS 7 Safari 与新增的 Web 平台功能

当今,iOS 7 提供一个新版本的 Mobile Safari,其中引入了我们团队曾从事的多项功能!下面是我们曾从事的一些重大功能及其可帮您做些什么。

这些功能在内嵌的演示中进行展示,这意味着可能直到在浏览器中启用这些功能或在 iOS 7 上的 Mobile Safari 中查看本文时才能看到这些功能发挥作用。

区域

通过区域,可将内容无缝地安排到多个容器内,从而简化响应式设计。我们以前编写过有关区域的示例,但此处再给出一个有关如何实现此功能的简单示例,由 Alan Greenblatt 创建:

6

在 Chrome 中,还可在标志下使用区域

剪切路径

7

我们团队对于 clip-path 属性有所贡献,该属性可通过 CSS 使用类似于 SVG 路径的语法剪切元素。这样剪切元素可仅显示填入任何形状的内容。可随意观看其他 codepen.io 演示以了解剪切路径可做些什么。

画布路径对象

以前,无法保存和重用早先在画布上绘制的路径。通过 Path() 对象,现在可保存路径并填充/画出/剪切这些路径。Dirk Schulze 对于路径对象将在您的画布项目中如何起作用曾详细撰文。

画布混合模式

 8

通过画布混合模式,现在可对 2D 画布中的绘制操作使用混合模式。这意味着可使用在图形领域中熟知的混合模式(如正常、变暗、变亮、滤色、叠加等)在画布中混合像素。好消息是 Firefox 已具有画布混合模式,并且无需前缀!因此 Firefox 和 Mobile Safari 均支持画布混合模式。我们希望很快看到在 Chrome 中启用这些模式。

可详细研究 codepen.io 画布混合模式示例

反馈!

我们非常愿意了解您对这些功能有何看法。在 codepen 上研究这些功能并勤加练习,然后在此处或在 Twitter @adobeweb 上让我们了解您的所思所想。我们期待着看到这些功能逐渐融入更多浏览器并帮助您在网络上创造更多有趣的内容!

本文在 Web 平台功能中发表。

 

重复使用 Webkit 中的 mask-repeat 和 background-repeat 属性提供的间隔和取整

作为 CSS 遮盖以及 CSS 背景和边框规范的一部分,-webkit-mask-repeatbackground-repeat 属性的值可为 roundspace

例如,有一个具有以下样式的绿色 div 位于一个蓝色背景上:

div {
width:250px;
height:300px;
background-color:green;
-webkit-mask-image:url(star.png);
-webkit-mask-size:91px 65px;
-webkit-mask-repeat:repeat;
}

其中 star.png 为以下图像:

2

如图 1 所示,由于背景放置区域无法容纳整数个遮盖图像(由 background-origin-webkit-mask-origin 属性决定),因此该图像经过裁剪。为避免出现这种情况,我们可将 mask-repeat 的值指定为 roundspace

 3

图 1

取整

使用 round 值时,遮盖图像经过缩放,以便可放下整数个该图像,如图 2 所示。该图像从原始大小 91px x 65px 缩小为 83px x 60px,因此在 x 轴上刚好出现 3 次,在 y 轴上刚好出现 5 次。引述规范:“In the case of the width (height is analogous):if X ≠ 0 is the width of the image and W is the width of the background positioning area, then the rounded width will be X’ = W / round(W / X) where round() is a function that returns the nearest natural number (integer greater than zero).”

 4

图 2

间隔

使用 space 值时,遮盖图像重复的次数使其可容纳在背景放置区域中,同时不经过裁剪。然后,图像将拉开间隔以填满区域,其中第一幅和最后一幅图像碰到区域边缘。图 3 显示遮盖图像如何拉开间隔,以使将在 x 轴上出现 2 个遮盖图像,在 y 轴上出现 4 个遮盖图像。

 5

图 3

对于 background-repeat 属性也实现了 repeat 和 space 值。在撰写本篇博文时,我们发现了一个情况:当调整大小的窗口中包含具有 background-repeat: space 值的元素时,将不绘制间隔图像之间的部分。我们将在此纠正这一点:https://bugs.webkit.org/show_bug.cgi?id=120607

本文在 Web 平台功能中发表。

 

 

CSS 混合模式浏览器支持矩阵

如果要检查所使用的(或作为目标的)浏览器中 CSS 混合模式的实现状态,则查看 CSS 混合模式浏览器支持矩阵即可轻松做到这一点。

创建此矩阵时,我们利用了针对 CSS 区域编写的精彩作品。实际上,我们使用了相同的代码,因此在幕后,该支持矩阵使用 QUnit 进行单元测试,使用 BrowserScope 进行存储。对于后端唯一的一个重大更改是添加了一项手动测试功能。

不要误会,过去自动测试的项目仍可自动进行。只有某些功能无法手动测试。为了确认两层之间的混合操作正确完成,我们将不得不检查所得层的像素颜色值。浏览器中没有 JavaScript API 这样做,并且为了安全起见,以后可能也不会有。唯一的一个例外是画布,其中有意让您可访问其像素,但这些测试自动进行。

如不添加手动测试,则仅能测试浏览器是否将相关的 CSS 属性视为有效,而这样将无法测试多项功能。误报可能会接踵而来。(如,当前,在某些浏览器中仅实现了 mix-blend-mode 的分析;该属性有效,自动测试也可通过,但并不真正进行混合)。

我们努力使手动测试体验尽可能不费力。这些测试简单易行,并集成在运行自动测试的同一 QUnit 套件中(通过 asyncTest)。为了避免进行不必要的测试,当某个特定的属性分析测试失败时,将不显示相关的手动测试,并且将其结果登记为失败。

随着实现方式的不断发展,我们将不断用最新的支持更新该矩阵。即在合理的限度内,我们将针对重要版本更新该矩阵,而并非在提交每个修补程序后均进行更新。当然,如果要获得有关 nightly 版本的最新信息,或出于某种原因对所提交的结果不满意,则始终可在浏览器中自行运行这些测试。只是在进行测试之前不要忘记启用相应的标志。还可在 github 上查看源代码。

由于从其 CSS 区域前身吸取了教训,因此为了使该矩阵保持整洁,不在外部提供结果提交机制。“区域”矩阵最初采用众包方法,但在 Internet 上自由进行了几个月后,证明这种方法的效果不甚理想。

测试当前涵盖 background-blend-modemix-blend-modeisolation(分析)CSS 属性和 2D 画布 globalCompositeOperation 特性。未来将支持测试 SVG 混合。

最后,如果未浏览上述链接,则务必查看 CSS 混合模式浏览器支持矩阵源代码

本文在混合模式新闻Web 平台功能中发表。

HTML 魔法 – 结合使用 CSS 形状与 CSS 区域

我从事呈现方面的工作已将近一年。由于我最初在 Blink 和 WebKit 中实现了区域上的形状,因此我迫不及待地想谈一谈这些功能以及如何能够将二者结合使用。

1

不知道 CSS 区域和形状是什么?从这里入门!

在我的 HTML 魔法厨房中,第一种原料是 CSS 区域。通过 CSS 区域,可将内容流入多种样式的容器,这样可大大提高创造力,产生杂志风格的布局。第二种原料是 CSS 形状,通过它,可将内容围绕在任何形状的内部或外部。在本文中,我要谈的是“shape-inside”CSS 属性,通过它,我们可将内容围绕在任意形状内部。

我们拿一个碗将 CSS 区域和 CSS 形状这两种功能混合在一起,产生一些很有趣的布局!

在最新的 Chrome Canary 和 Safari WebKit Nightly 中,启用所需的实验性功能后,可将内容连续流过多种形状。这太棒了!可摆脱一成不变的矩形文本流,将文本打散为多个非矩形形状。

演示

如果已有最新的 Chrome Canary/Safari WebKit Nightly,则即可尝试 codepen.io 上的一个简单示例。如果懒得动手,或要少按几次按钮,延长鼠标按钮的使用寿命,那么可继续阅读。

2

在上图中,我们看到“Lorem ipsum”的故事流过 4 种不同的彩色区域。在前两个固定大小的区域中均有一个圆形。查看下面的代码,了解我们如何将形状应用于区域。显而易见,对吗?

#region1, #region2 {
    -webkit-flow-from:flow;

 

    background-color:yellow;
    width: 200px;

 

    height: 200px;
    -webkit-shape-inside: circle(50%, 50%, 50%);

 

}

内容流入第三个(百分比大小)区域后,表示为一个心形(由我绘制,保留所有权利)。我用百分比定义了这个心形的坐标,因此这个心形将随着调整窗口大小而拉伸。

#region3 {
    -webkit-flow-from:flow;

 

    width: 50%;
    height: 400px;

 

    background-color: #EE99bb;
    -webkit-shape-inside:polygon(11.17% 10.25%,2.50% 30.56%,3.92% 55.34%,12.33%68.87%,26.67% 82.62%,49.33% 101.25%,73.50% 76.82%,85.17% 65.63%,91.63%55.51%,97.10% 31.32%,85.79% 10.21%,72.47% 5.35%,55.53% 14.12%,48.58%27.88%,41.79% 13.72%,27.50% 5.57%);

 

}

前三个区域容纳不下的内容流入第四个区域。第四个区域(参见复古蓝背景颜色)的 CSS width 和 height 设置为 auto,因此它经过扩大可容纳剩余内容。

真实示例

尝试演示并查看上述链接后,我确信您将发现有机会在下一个设计中将 shape-inside 与区域结合使用。如果您对本主题有任何观点,请不吝赐教。请注意,这些功能仍在开发中,您可能会遇到缺陷。如果遇到,应在 WebKit 的 Bugzilla(对于 Safari)或Chromium 的 issue tracker(对于 Chrome)上报告这些缺陷。感谢您的阅读!

本文在区域形状Web 平台功能中发表。

 

 

Test the Web Forward 上海站

我们很高兴地宣布,8 月 17-18 日举办的第七次 Test the Web Forward 活动圆满结束。上海地区的开发团体对于 Web 展现出极大的热忱,此次活动第一天就吸引了将近 350 名 Web 开发人员,第二天又吸引了 150 名。到活动结束时,共进行了 1003 次测试,提交了 35 个漏洞,再创 Test the Web Forward 活动的世界纪录!

本次活动在博雅酒店举行(由百度云集团赞助),于周六下午正式开始。原计划下午两点开始,但大家在一点就陆续到场,排起长队进行登记。我们竖起一面签名墙,大家纷纷在上面签名,表示要努力让 Web 变得更美好,当然,还频频拍照。我们还为与会人员准备了许多礼品,其中包括 Test the Web Forward T 恤衫、HTML5 贴纸、标牌、W3C 马克杯和百度防辐射贴纸。开发人员都很喜欢这些礼品。

3 1 2 4 5 6

两位特别嘉宾为本次活动拉开帷幕:百度副总裁陈尚义先生和工信部成员、中科院声学研究所研究员侯自强先生。他们表达了 Web 标准对于中国政府和行业的重要性。

7 8 9 10

接下来发言的是 HTML5 工作组主席 Paul Cotton。Paul 汇报了 HTML 的最新进展,分享了路线图并介绍了发表 W3C 规范的过程。在问答阶段,Paul 澄清了 W3C 与 WHATWG 之间的误解。Paul 个人认为 W3C 与 WHATWG 之间是一种合作关系。虽然二者还未进入发布过程,但有一个共同的目标,即让 Web 变得更美好。

11

接下来是快速演讲,其中各位专家进行了自我介绍、简单扼要地评论了若干规范并针对其偏好的规范招募了新的测试编写人员。人们分为六组,分别针对 HTML 拖放、IndexedDB、文件 API、CSS 变换、网格布局、背景和边框编写测试。Adobe 中国公司的张建用一场“如何创建 W3C 测试”的演讲结束了当天的活动。

12 13 14 15

每组有 5 名评论员。

16 17

晚上举办了一场丰盛的自助餐。开发人员在优雅的环境下享用了美食。每个人都为第二天的攻坚作好了准备!

18

周日开始进行测试攻坚。Intel 中国公司的张志强针对“如何编写高水平的测试”和“如何记录高水平的漏洞”进行了一场有教益的演讲。

19

入乡随俗,我们使用一面中国堂鼓表示测试何时完成并驱使人们提交更多测试。年轻开发人员在本次活动中的测试首次获批后,鼓声即快速响起。

20

在整个活动中,我们看到每个人都聚精会神、全情投入。专家则忙着帮助开发人员并审阅其测试。

21 22

虽然让 Web 变得更美好本身已很有意义,但奖品和抽奖让它变得更加有趣。奖品包括 1000 美元现金(授予有突出贡献的个人)、一台 iPad Mini 和数台 Kindle。

1 2

杰出服务奖:张民先生以 319 个拖放测试获得了第一名!

23

最佳漏洞猎手:Tina 记载了 8 个 Webkit、Safari 和 Mozilla 漏洞!

 24

总的来说,本次活动共创建了 1003 个测试!通过这些测试,共找到并提交了多种浏览器上的 36 个新漏洞。

3

特别致谢
我们要感谢百度公司成功地在上海主办了本次活动,并感谢 Intel 提供的莫大技术支持!我们欣喜地看到人们结交了新朋友、提升了他们在 Web 标准测试方面的知识,并且我们在推动 Web 发展的过程中又前进了一小步。

在 Chrome Canary 和 WebKit Nightly 中现在提供了 CSS 背景混合模式

作为 CSS 混合与合成规范的一部分,HTML 背景混合允许直接从 CSS 中混合图像、渐变和背景色。

假设我们有一个包含以下内容的 html 元素:

#dummy_element {
  background:url('azure_by_kurokitsune777.png') no-repeat, blue;
}

我们现在就可以按如下方式使用 CSS 来混合该元素的背景层(指定的图像和背景色):

#dummy_element {
 background:url('azure_by_kurokitsune777.png') no-repeat, blue;
 background-blend-mode:difference, normal; // Chrome Canary
 -webkit-background-blend-mode:difference, normal; // WebKit Nightly
}

您可以在右侧看到在该元素的背景图像和背景色之间是如何应用差异 混合模式的:

 31

该功能是 Blink 呈现引擎和 WebKit 最近新增的,前者由 Chrome 使用,后者则是 Safari 使用的呈现引擎。

可通过按以下步骤操作来看看它是如何发挥作用的:

对于 Chrome Canary

  1. 此位置下载并安装 Chrome Canary。
  2. 了解如何在 Canary 中启用标志来查看背景混合模式

对于 WebKit Nightly

CSS 背景混合默认情况下在 WebKit Nightly 中处于启用状态,因此您只需从 nightly.webkit.org 下载一个内部版本即可。

完成上述步骤后,您就可以通过 codepen(展示了所有受支持的背景混合模式)看看该功能是如何发挥作用的。

32

不要忘了就此功能分享您的视频和想法!

本文在混合模式新闻Web 平台功能中发表。

在 CEF 中测试性能

Adobe 致力于打造最佳工具和服务来帮助您卓有成效地使用网络。只要有可能,我们就会使用 Web 平台本身来打造这些工具和服务。例如,Edge CodeEdge Reflow 就是基于 Chromium 嵌入式框架 (CEF) 使用 HTML、CSS 和 JavaScript 打造的。CEF 是由 Marshall Greenblatt 创建的一个开源项目,我的团队也为该项目贡献了代码。随着从 CEF1 到 CEF3 的过渡,我们也有机会为 CEF 贡献社区直接要求的一项功能:屏幕外呈现。

屏幕外呈现

对于在与 Chromium 网络视图交互时需要获得更大灵活性的嵌入者而言,屏幕外呈现十分有用。使用此功能时,嵌入应用程序将收到绘图通知,而实际的绘图工作则是在位图缓冲区中执行的。嵌入者随后将负责将此缓冲区绘制到屏幕。

这种模式所产生的结果是,网络视图失去了对输入事件的控制权,嵌入者则负责将鼠标和键盘事件转发到网络视图。屏幕外呈现功能的性能从一开始就成为了实现过程中的主要侧重点。早期的一项难题是,找到一种严格(但又不能过于复杂)的方法来在 CEF 中比较屏幕外呈现与标准呈现的性能。

Chromium Telemetry 框架

在寻找用来在 CEF 中测试呈现性能的工具时,团队找到了 Chromium Telemetry 框架。Telemetry 是一种基于远程调试协议运行的 Python 框架,用来在 Chromium 中进行性能测试。在 Telemetry 所支持的整组基准测试中,滚动基准测试最适合我们的使用情形。这种基准测试会在页面中滚动,并收集有关响应速度的指标,例如每秒绘制的百万像素数、丢弃的帧数以及帧速率(通过帧平均传输时间)。

Telemetry 可以在任意风格的 Chromium 和 Content Shell 中运行。由于 CEF3 基于新的 Chromium Content API,因此,为运行滚动基准测试,我们必须公开 JavaScript 中的一些专用 window.chrome API。滚动基准测试中的某些指标将需要用到这些 API。

使用 CEF 运行 Telemetry

Telemetry 依赖于 Chromium 源代码,因此需要进行 Chrome 源代码签出。可以从此处下载 CEF 的二进制版本。

要开始在 CEF 中执行滚动基准测试,必须从 Chromium 源代码树中的 src/tools/perf/ 中使用以下参数运行 run_multipage_benchmarks 脚本:–browser=exact –browser-executable=path/to/cefclient –output=outputfile.csv smoothness_benchmark path/to/chromium/src/tools/perf/page_sets/top_25.json

要在禁用了屏幕外呈现和硬件加速的 CEF 中运行 Telemetry,只需追加下面的额外开关即可:
–extra-browser-args=”–off-screen-rendering-enabled –disable-accelerated-compositing”

为获得可靠的测试结果,建议对复制到本地的一组页面运行该基准测试。要记录页面的这种副本,请运行:/tools/perf/record_wpr –browser=exact –browser-executable=path/to/cefclient path/to/chromium/src/tools/perf/page_sets/top_25.json

由于 Telemetry 框架目前存在的限制,必须先创建好 path/to/chromium/src/tools/perf/data 目录,然后才能尝试创建页面的本地副本。

我们测试的对象

由于屏幕外呈现不支持硬件加速,因此我们将采用屏幕外呈现模式的 CEF 测试应用程序 (cefclient) 与屏幕上测试应用程序进行了对比(禁用了加速合成)。

我们采用 CSV 文件输出格式,将结果串连成另一个文件,然后使用 path/to/chromium/src/tools/perf/utils/results_viewer/src/results_viewer.html 中的查看器将这些结果可视化。

在所呈现的 html 中选择两列后,产生了如下所示的图形:

29

调查结果

在 Mac 端口上,通过对结果进行比较,发现了一些意外行为:屏幕外呈现功能所报告的帧平均传输时间短于标准呈现功能。这意味着在相同的时间间隔内,采用屏幕外呈现时向屏幕发送了更多的帧。

经过一些调查,我们发现,如果在基于屏幕外呈现的 cefclient 内进行滚动,则呈现器会收到远比常规 cefclient 更多的滚动事件。这导致了呈现器向屏幕发送更多帧。对代码进行深入分析后发现,Chromium 过去常常跳过从系统接收的其中一些滚动事件 – 在屏幕外呈现过程中则不存在这种优化机制。

通过解决屏幕外呈现性能问题使这种呈现方式与 Chromium 中的标准呈现方式更紧密地对应后,我们再次运行了基准测试并获得了以下结果:

30

总结

呈现性能的测试一直是个难题,但幸运的是,Chromium 团队通过 Telemetry 框架有效化解了这一难题。由于 CEF3 与 Chromium Content shell 共享一些必需的代码,因此我们以几乎免费的方式在 CEF 内实现了 Telemetry 支持。
虽然这些功能尚未广泛推出,但此类工具可以为所有主流网络浏览器带来的价值是显而易见的。

本篇博文是与 Ion Rosca 协力撰写的。

本文在测试中发表。

直接使用 CSS 区域指定流动区域

CSS 区域供您用来指定内容的流动区域,而不是屏蔽掉禁止内容流动的区域。

间接

CSS 提供了很多用来指定内容流动区域的工具。但到目前为止所提供的这些工具都是间接工具。您可以使用指示“不要在此区域流动”的浮块,也可使用边距来使某个区域保持空白。您将获得一个用来排布内容的矩形框,而借助这些工具,您可以将该矩形修剪成更加有趣的形状。

我们以下面的布局为例。一篇文章流过三个区域,从而产生一定的视觉吸引效果。目前有多种方式可以实现类似于这种布局的效果,但这些方式全都是间接的方式并且存在一些限制。

28

您可以使用边距来达到这种效果(暂时忽略蓝色的框):首先设定右边距,接着是左边距,然后将左右两侧设置为自动对齐。这种方法存在的主要限制是,您必须将内容划分成三个部分,以产生可将这些边距分配到的对象。这样一来,这些列的高度就是固定的。另一项限制是,您是通过将容器大小减去边距来指定列宽的。由于您指定的是单一边距值,因此当列宽采用特定长度或百分比时,您将束手无策。

也可以使用浮块来产生这种效果。采用这种方式时,需通过将容器大小减去浮块宽度来指定列宽,因此当列宽采用特定长度或百分比时,您依然将束手无策。不过,高度则可以灵活设定。您必须为第二个浮块增加一定的空白,列高则可以由浮块高度决定。但如果要保持高度方面的灵活性,您必须继续对最后一个居中的列使用(两个)浮块,从而使其具有更大的空白。所有这些浮块都需要位于或接近内容开头,以确保在一行文本会占据容器全宽的浮块区域之间没有任何间隙。这涉及到很多的维护工作,这里仅仅以内容不流动的区域为例加以说明。

直接

与上述间接方法不同的是,使用 CSS 区域可以直接指定这三个列区域。这会带来各种优势。其中一项优势就是,您可以使用最小宽度和最大宽度来创建灵活但仍然易读的列宽。由于每个列的 CSS 区域都是一个完全可设定样式的框,因此您可以使用自己喜欢的任意 CSS 方法来定位列,而不是依靠以奇特的方式使用浮块等单一功能。

我已经整理了一个使用 CSS 区域和 Flexbox 创建上述布局的 CodePen。您可以在 Chrome Canary 中看看它是如何发挥作用的。由于每个列都有自己的框,因此我可以将前两个列设为弹性项。得益于此,我就能够以最小宽度和最大宽度形式为列指定一个可随着可用空间增加或减少而灵活调整的宽度。如果可用空间很大,那么列与蓝色框之间的空间也可以灵活调整。我使用了两个弹性容器来确保最多只能有两个弹性项相互紧挨着排列。

使用 Flexbox 的最大好处在于,如果可用宽度很小,则起包装作用的弹性容器就会为移动平台创建一种单列布局,同时又不会对我所指定的宽度进行任何更改。我在该 CodePen 中确实包含了一个媒体查询,但该查询仅用于更改第二个蓝色框的顺序,从而使移动布局以“文本-框-文本-框-文本”形式呈现。请用其他屏幕宽度试一试。

适应未来变化

我之所以能够使用 CSS 区域和 Flexbox 创建出这种布局,是因为我直接指定区域框。Flexbox 不必了解有关 CSS 区域的任何信息 – 它只是在弹性容器内操作这些框。在开发基于框运行的任何新 CSS 功能的过程中,都可以使用 CSS 区域(通常适用于大多数功能)。因此,随着 CSS 的改进,您可以直接使用 CSS 区域指定内容流动区域,从而具备越来越高的表现力。

本文在区域提示和窍门中发表。

Adobe 使用《国家地理》杂志的内容探究响应式数字布局的前景

更新 (2013/5/21):要了解移动原型,请查阅利用网络技术在移动平台上打造已安装了应用程序的体验

《国家地理》杂志与 Adobe 携手合作,精挑细选了一些内容与 Adobe 分享,供其用来开展数字布局试验。这些成果标志着技术团队与设计团队开始协作,这种协作将着眼于在布局方面实现创新,同时响应《国家地理》杂志设计师们的一些实际需求。通过将《国家地理》杂志的一个名为“Forest Giant”的专题与 Adobe 为网络标准作出的贡献结合起来,Adobe 形成了关于在不远的将来读者将如何消费网络内容的卓识远见。

配置

由于该演示所使用的部分功能仍处在试验阶段,因此该文章需在启用了两个运行时标志的 Chrome Canary 中进行查看。要了解如何启用 CSS 区域、CSS 排除和自定义滤镜,请参见启用尖端的图形和布局功能

要了解如何启用运行时标志,请观看此教程

安装并正确配置 Chrome Canary 后,请观看演示。(请注意,整个项目都是开源的,并且已在 GitHub 上提供。)当然,如果您比较匆忙的话,您始终都可以只观看上面的视频,大致感受一下这种体验。

编辑人员的标记

现代布局功能的某些优势可能不易察觉,因此我们创建了“编辑人员的覆盖图”模式,该模式突出显示了一些比较值得注意的功能,并解释了这些功能的实现方式。要启用编辑人员的标记,请单击位于该文章底部的栏(或者直接按波浪号键)。

 18

区域

为了能够更好地控制该文章的流动,我们使用了 CSS 区域。区域的核心功能是,使用它可以将内容与其显示位置和显示方式分开。具体而言,借助区域,您可以指定 DOM 的哪个部分是内容,以及内容应流过哪些元素。内容的流动是自动进行的,流动过程中会针对字号变化、大小调整、缩放等情况进行调整。

在“Forest Giant”演示中,我们使用区域使内容以十分有趣的方式流过页面,甚至会在一个实例中创建一些影子列。如果不使用区域,设计人员就必须手动中断内容,并且在内容发生更改的情况下必须对整个页面进行大幅调整。使用区域时,随着源文本流过指定的区域链,内容会自动在各个元素间中断。

 19

区域也是一款用于响应式设计的绝佳工具。当您更改区域的大小和/或位置来响应屏幕大小的变化时,内容会自动重新流过区域链。

 20

了解有关 CSS 区域的更多信息。

排除

借助 CSS 排除,文本可以沿着形状的内侧或外侧流动。我们来看一下该文章开头的首字下沉。如果不使用排除,则“O”右侧的文本将垂直对齐,从而产生不均匀的间距。通过使用排除(具体而言是 shape-outside),文本可以根据首字母的轮廓线进行调整,从而大大提升了视觉效果的整洁性和美观。

 21

另一个排除示例是该文章底部的文本。请注意这段文本是如何根据地图形状进行调整的。这种类型的高端布局是以前使用 HTML 内容所无法做到的。如果不使用排除,那么要在网络上做到这一点,最佳方式可能就是使用图像,不过这样的话就无法调整文本大小、为文本编制索引、搜索文本、复制文本和轻松更新文本。

 22

了解有关 CSS 排除的更多信息。

平衡文本

平衡文本的概念十分微妙,但一旦您领会了这一概念,您就会发现它将使内容的布局方式大大改观。默认情况下浏览器一次对一个字进行换行,这意味着您可以轻松地以仅包含一两个字的行收尾,而该行上一行的长度则可能会达到容器全长。尽管我们在网络上对这种情况已经屡见不鲜,但在印刷品中则不允许这种布局出现。当设计人员可以完全控制各行文本的断行方式时,他们将对文本进行平衡,以使每一行的长度大致相等。

我们对该文章的副标题以及第二段与第三段之间的醒目引文都使用了平衡文本 polyfill。如果要了解它是如何发挥作用的,可以尝试横向调整浏览器的大小。如果您所用的显示器足够宽,您应该会看到整个醒目引文独占一行。当您减小窗口宽度时,您将会看到文本始终以使各行宽度相接近的方式进行换行。

23

24

 25

了解有关平衡文本的更多信息。

自定义滤镜

我们当中的大部分人都已经习惯了在 Photoshop 和 Instagram 等应用程序中对图像应用滤镜。如果您在网络上大量使用过 SVG,您可能也试过 SVG 滤镜。现在,您可以使用 CSS 滤镜将同样的视觉效果应用于任何 HTML 元素。

滤镜的优点如下:

  • 可以动态地应用它们,这意味着您无需预处理您的资源。
  • 可以将它们应用于任何 HTML 元素(而不仅仅是图像)。
  • 可以使用 CSS 动画来为它们增添动画效果。

我们在该文章底部采用了自定义滤镜,以使用户可以在页面底部“向后翻页”并呈现一种交互式的信息图(单击“Explore the President Tree”文本即可查看滤镜是如何发挥作用的)。这种效果是一种可在内容中创造一种深度感的细微但有趣的方式,并且是完全通过 CSS 实现的。

 26

了解有关 CSS 自定义滤镜的更多信息。

WebGL

由于“Forest Giant”这篇文章介绍的是世界上的第二大树(不过就质量而言,可能是世界上最大的),因此我们想传达一种规模感。如果您单击巨杉缩略图下方的“Click Here to Pan & Zoom”链接,您将看到该树的一张巨幅图,这幅图像由图块拼合而成,直至达到最顶部为止。请试着在该图像周围滚动,看看三位科学家相对于他们所研究的这棵树看起来有多小。

这种效果是使用 WebGL 实现的(通过一个名为 three.js 的库)。虽然 WebGL 并不是 Adobe 直接贡献的规范或实现,但我们是它的狂热粉丝,它是可用来制作顺畅三维动画的完美技术。

 27

了解有关 WebGL 的更多信息。

总结

技术的进步一次又一次地证明了方便性常常胜过保真度。例如,MP3 之所以流行(甚至在最初它们的比特率很低的情况下也流行了起来),是因为与获得最佳音质相比,不论身在何处都可以欣赏到我们的所有音乐对我们更为重要。同样,数字图书、杂志和报纸也正在以越来越快的速度取代它们的模拟版本,因为方便、即时地访问内容常常比美感更为重要。

现在,由于在互联网的助力下,内容已经无处不在,因此我们也开始看到向制作水准回归的趋势。用户希望体验到高清的视频、美观流畅的用户界面,并且他们也日益期望内容以有趣、吸引人的方式呈现出来。借助区域、排除、平衡文本、自定义滤镜和 WebGL 等功能,内容制作者们将无需再于覆盖面和设计间取舍。通过对《国家地理》杂志令人惊叹的视觉内容进行处理,Adobe 已经证明了未来的网络将可以做到两全其美。

本文在 CSS 着色器CSS 文本自定义滤镜排除新闻区域形状Web 平台功能WebKit 中发表。

Chromium 嵌入式框架

在此由衷地感谢 Chromium 嵌入式框架的创始人 Marshall Greenblatt,他撰写并帮助编辑了本篇博文的部分内容。

Chromium 嵌入式框架 (CEF) 是一个开源项目,可使开发人员轻松地在其桌面应用程序中显示 HTML 内容。通过可用的 API,可以精细地控制甚至可以扩展 HTML 视图。在底层,HTML 呈现是通过 Chromium 浏览器项目完成的,该项目基于 Blink 引擎(以前称作 WebKit)和 V8 JavaScript 虚拟机。

就像框架通常的做法一样,CEF 主要提供一组标头和一个库。它可以在 Windows、Mac OSX 和 Linux 上使用,不过仍需要完成一些工作才能在平台间实现功能对等。C++ 和 C API 作为此项目的一部分提供,但已经存在为 .NET、Java 和 Python 等其他环境维护包装程序的项目。

与 Chromium 的关系

CEF 推出了两种版本,分别是 CEF1 和 CEF3,这两种版本都得到了积极维护。这两个项目向嵌入客户端公开的 API 几乎相同,同时使用 Chromium 风格的 WebKit(现为 Blink)来呈现 HTML。二者的不同之处体现在它们与底层 HTML 引擎结合的方式上,不过,为了更好地了解这一点,对 Chromium 体系结构进行总体概述会十分有用。

Chromium 体系结构主要有三个层:Blink(以前称作 WebKit)API、Content API 和 Chrome。借助 Blink API,可以访问呈现引擎和 V8 JavaScript 引擎,这两个引擎在单个进程中一起运行。Content API 增加了多进程体系结构,并为更为复杂的 HTML5 和浏览器功能(例如加速合成、地理位置和 WebRTC)提供了具体实现。Chrome 层包括 Chrome 浏览器用户界面以及与 Chrome 浏览器紧密耦合的各种功能实现,例如历史记录管理、扩展程序和书签。Chromium 团队目前正在致力于引入称作“组件”的第四种概念,此概念将为跨多个层的浏览器功能提供模块化实现。

Blink API 和 Content API 不稳定,而且很多功能都有其他的实现要求。CEF 便提供了这些实现,以及一个隐藏了大部分底层 Chromium 和 Blink 复杂性的稳定 API。CEF1 直接使用 Blink API,并因此而共享单进程体系结构。CEF3 使用 Content API 并受益于多进程体系结构以及 Content API 中实现的很多高级功能。得益于“组件”方面的变化,将更容易有选择性地启用和共享目前因与 Chrome 层紧密耦合而无法共享的功能实现,这对 CEF3 而言是一项额外的益处。

CEF3 实现了 Content API 提供的一部分接口和委派,实现方式与 Chrome 颇为相似。虽然开发人员可以直接从 Content API 开始嵌入 Chromium,但这会涉及到相当大的工作量,而这些工作在 CEF3 中已经完成。这些工作包括实现应用程序希望操纵的 Content API 接口和委派,并且在实现的过程中,还要为应用程序所需的运行平台 (Windows/Mac/Linux) 编写平台代码。另一方面,使用 CEF 时则十分简单:只需先编写几行代码,然后直接在应用程序内触发一个现代、最新的 HTML5 视图即可。

CEF1 和 CEF3 都将 Chromium 的某些部分纳入到了所产生的库中,并因此形成了对 Chromium 代码的依赖性。该项目保持了与底层特定版本 Chromium 代码的兼容性,这些代码的更新颇为频繁。从这个角度而言,嵌入者不必担心更新 Chromium 会破坏他们的应用程序。

从此处开始,除非另有说明,否则 CEF 这个术语将称作 CEF3。

快速入门

要着手使用 CEF,最简单的方式或许就是下载其中一个二进制版本。CEF 维护的一些分支与用于各版本的 Chromium 稳定分支兼容。定期发布的二进制版本通常都是基于一个此类稳定分支生成的。

可分发程序包包含标头、库、一些必需的资源以及一款称作 cefclient 的测试应用程序。这正是您应该着眼的地方。它完美地展示了如何使用 CEF,从启动该框架到实现通过 API 公开的 HTML 内容回调,都一一说明。您可以通过修改应用程序代码、快速重新生成等方式进行测试。

请注意,您还可以将 Chromium 命令行开关传递给 cefclient,以这种方式使用时它们所产生的效果将与在浏览器中产生的效果(如果适用)相同。

如果您要作出贡献,或者要使用其中一个二进制版本目前未提供的功能,您必须基于源代码生成 CEF 库。虽然 CEF 本身是非常轻便的,但这还涉及到生成 Chromium,从而使工作复杂性略有增加。在本篇博文中我不作细致阐述,但如果您想知道要从何处着手,可以浏览一下 CEF 的 automate 文件夹。其中的 python 脚本会签出 CEF 和 Chromium 源代码,并继续生成最终 CEF 程序包。同一文件夹中的 README 文件更加详细地描述了这一过程,并且还包含了在运行该脚本前要执行的一些必需步骤。

Adobe 贡献

下面列出的是除了各种缺陷修复之外,我们为 CEF 作出的更重要的贡献。

Mac 上的 IME [CEF1]

我们为 CEF 作出的第一项重要贡献就是为 Mac OS X 的输入法编辑器 (IME) 实现了缺失的平台代码。在 CEF1 中,此代码完全缺失。在 CEF3 中,Content API 类别下已经提供了此代码。

跟踪 API [CEF3]

跟踪机制是一种 Chromium 开发工具,可用于跨线程和进程分析 Chromium 代码。如果您想一探究竟并开始跟踪,只需在 Chrome URL 栏中键入 chrome://tracing 即可。我们作出的贡献是将内部跟踪 API 作为 CEF API 的一部分进行了公开。嵌入者可以使用这些方法在他们自己的客户端应用程序内通过与整个“CEF – Chromium – Blink”堆栈相同的视图来分析调用。

Windows 和 Mac 上的屏幕外呈现 [CEF3]

借助此功能,嵌入者可以收到 CEF 发来的绘图通知,而不是让 CEF 直接呈现到本机窗口。随后,嵌入者便可以使用诸如 OpenGL 或 Direct3D 等技术来自行处理呈现。UI 事件也可以转发到 HTML 页面,这也是此功能的一部分。当嵌入者希望在 HTML 视图上绘制其他内容或者希望与自行执行呈现的现有应用程序框架集成时,这尤为有用。使用屏幕外呈现的做法为在两个重叠视图甚至是两个 HTML 视图间进行同步绘制提供了一种简单的解决方案。处理两个重叠、透明的本机视图时,进行同步绘制将非常麻烦。

另一种使用情形是打破 64 位进程与 32 位进程之间的界限。由于 Chromium 目前尚不支持 64 位内部版本,因此 CEF 二进制文件也将受到 32 位限制。故而,64 位应用程序将无法直接与 CEF 关联。不过,得益于屏幕外呈现,HTML 呈现可以隔离在 32 位进程内,而不在任何 UI 上呈现。所呈现的 HTML 结果随后可以通过一个网桥传回 64 位应用程序,并绘制在属于它的内部 UI 对象中。

后续步骤

我们计划贡献 IME 功能以便在 Mac 上实现屏幕外呈现。由于实现屏幕外呈现会覆盖其中一些内部 Content API 实现,因此需要使 IME 适应在没有它所绑定到的本机窗口的情况下工作。

我们也正在致力于为 CEF 搭建一种自动化的生成基础架构。该基础架构将定期生成 CEF、运行单元测试,并在公共位置发布内部版本。我们仍在斟酌此项目的相关细节(是每夜生成一次还是每进行一项改动便生成一次、是分支还是主干,等等)。

总结

如果您需要通过一种简单的跨平台方式在桌面应用程序中显示 HTML 内容,CEF 可能正合您意。它是开放的,并且有一个运作良好的社区在支持它,此外所有使用它的应用程序也无不证明了它的功用。

本文在 Web 平台功能中发表。