第一页：多媒体标记
和今天大多数开发网站内容的人一样，我从另一个方向来到这条路上。我大学毕业后的最初两年在视频产业工作。事实上，使我离开这个行当的原因是在工作中丢失了我做的一卷演示用的录象带，迫使我转向互联网事业。
我从那时起再也没回头，虽然偶尔感到一些怀旧的痛楚。我并不真的在意在网上观看我最喜欢的电视节目。
虽然在网上播放视频产品是可能的，但还不可行。未压缩的视频每秒需要播放几乎4兆的信息，这种传输速率在局域网上都很难达到，就更不用说大型网络了。人们正试图在将来的芯片中实现有效的视频压缩，但是当它实现时，视频也只是网上一种非常浪费的媒体。不管是运用快速蒙太奇还是别的方法，被传输的文件仍然相当大。
为了使视频在网上可行，我们需要实现聪明的内容。edl（edit decision list）和smpte(society of motion picture and television engineers)等视频编辑们认为是理所当然的时间编码标准很难转换到网上。smpte时间编码是视频时间片的标准，把视频信号分成小时、分、秒和祯（在视频中每秒30祯，在电影中每秒24祯）。
一旦smpte成为一种可采用的标准，就有可能描述基于时间片的一段视频。例如，第一个编辑发生在20秒和22祯处，持续2秒和4祯，然后切换到持续1秒和15祯，等等。很快，很多编辑台提供了可以记住某个给定片断的edl，可以把edl存储为只有几kb的计算机文件。这样，如果主卷丢失或被破坏，或者增加新的胶片，可以简单地用edl来重建脚本。
这就是smil的基本原理。
直到现在，描述网上临时数据的明确定义的方式还没有真正出现。
公平地说，确实有一些面向网页的技术。其中的大多数，如macromedia的shockwave或realnetwork的realmedai，需要插件、activex控件甚至单独的应用程序首先被下载下来，然后使用百分之百所有权的文件格式。而且，这些技术产生的文件对搜索引擎没有意义。
基于web的多媒体缺乏标准部分是由于今天的混乱，但是同时也是可以原谅的。带宽依然是个问题，假设大多数人用28.8kbps的速率上网，1m的信息要花几分钟来下载，对音频和视频，1m的信息根本算不了什么。所以除非你知道你的大多数观众有一个快速连接，使用基于web的多媒体是没有意义的。
好象我们可以在18个月内可以看到一些带宽的戏剧性的增长，或者象xdsl和电缆modem等技术的发展超过测试阶段。最重要的事实是通常很保守的w3c已经发布了一种试图处理多媒体的标记语言的工作草案：smil。
第二页：进入smil
smil，同步多媒体集成语言（synchronized multimedia integration language）的首字母缩写，把它的视线对准音频和视频世界。如果现在的工作草稿能够成为将来最终标准的指南，那么我们以后可能要做很多smil的工作了。
技术领导们注意了 - 因为siml只是一个工作草稿，它不被现在的任何浏览器支持，我不会深入到如何建立smil文档上。它的进展完全取决于w3c。
首先要知道的是smil是xml的子集。xml本质上是关于meta-data的，允许创建新的html方式的标记符来描述web内容。
最明显（和最常见）的xml的例子是<author>或<byline>标记符的创建。
很多网页有清楚的author和byline，但是现在它们通过没有差别的html来表达。处理这种类型的信息的明显的标记符对搜索引擎很有价值，这样可以马上分辨出文章的作者。xml使用文档类型定义（dtd）来描述xml的特定子集是如何组织的。在xml中，一般通过添加新的实体定义来扩展dtd（然而在smil中，不推荐这样做）。因为smil是基于xml的最早的工作草稿之一，所以最好等到xml成为现实那一天。
第三页：基础知识
smil的好处是它的结构很象html，所以不难掌握它的基础知识。实际上，最基本的smil文档看起来与基本的html文档基本相同：
<smil>
<head>
</head>
<body>
</body>
</smil>
用<smil>标记符替换<html>标记符，就得到一个smil文档。smil的另一个好处是它的核心功能基于这两个标记符：<par>和<seq>。知道了这两个标记符，就可以写smil表达式了。当你知道<par>是"parallel"的缩写，<seq>是"sequence"的缩写时，它们的功能就显而易见了。所以可以把<par>放在想要开始播放媒体的地方，把<seq>放在播放某个序列条目的地方。这两个标记符可以嵌套，所以可以在子序列中开始几个平行的其它媒体对象，或者可以在一个序列中平行地播放几个对象。smil媒体类型的表示与html略有不同。图像的表示几乎相同，但是因为所有xml标记符不需要第二个结束标记符，所以需要一个反斜线放在结尾。因此：
<img src="http://www.hotwired.com/images/thing.gif"> 变成：<img src="http://www.hotwired.com/images/thing" />
注意我们没有明确指明我们在调用一个gif图像。smil独立地处理这种情况，从服务器、操作系统，或者smil中的"type"属性中提取信息。这不如开始时那么复杂：smil知道我们在标记符中处理图像，所以不需要直接指明是gif图像。当然，既然它是一种多媒体标记语言，它就包含了不只图像一种媒体类型。有效的媒体类型包括音频、动画、a(anchor标记符)、ref(通用的媒体类型指示，用在不能确定媒体类型时)、img、文本、文本流、视频，当然还有par和seq标记符。
第四页：结构
你们中的很多人可能曾经咬牙切齿地盼望停止使用表格和控制间距的gif的一天 - 用样式表控制页面上元素的布局和表现。
smil的好消息是允许马上精确控制元素。坏消息是它不只使事情容易和使用样式表作为它的缺省布局协议。它不采用封装<region />标记符的<layout>和</layout>标记符。然而，基本的smil布局元素与css很相似，而且css本身它也支持，所以确定"text/css"将允许用样式表对页面进行布局。这两种方式都可以有效地在页面上定位元素：
<smil>
<head>
<layout>
<region id="smile" top="200" left="100" z-index="5" width="100" height="220" />
</layout>
</head>
<body>
<seq>
<img id="smile" src="http://www.hotwired.com/images/thing" />
</seq>
</body>
</smil>
和
<smil>
<head>
<layout type="text/css">
#smile {top:200; left:100; z-index:5; width:100; height:220 }
</layout>
</head>
<body>
<seq>
<img id="smile" src="http://www.hotwired.com/images/thing" />
</seq>
</body>
</smil>
我不知道w3c为什么不直接选择css，但我肯定他们有自己的原因。
第五页：不用脚本的条件化内容
过去，在html文件中建立条件化的内容一般要涉及到某种服务器端的方案，如xssi或asp，或者某些使用相当广泛的客户端脚本。smil使用<switch></switch>标记符实现这样的功能。<switch>是smil规范中很好的一个特征，因为它可以提供一页的多次重复或基于客户/终端用户的设定而不需要任何比smil规范本身更多特殊知识的完全定制页的版本。
可以简单地把<switch>标记符包围在一堆内容的周围，然后smil检查每个媒体对象的属性，看哪个最符合客户的设定，然后选取最适合的。实际上，它选择第一个可以起作用的，所以媒体对象的排列顺序很重要。
作为一个例子，假设你建立了一个视频表现，而且你有对各种不同连接速度的不同的表现版本。使用<switch>，可以保证用户得到合适的文件：
<smil>
<head>
<layout type="text/css">
#smile {top:200; left:100; z-index:5; width:100; height:220 }
</layout>
</head>
<body>
<switch>
<video id="smile" src="http://www.hotwired.com/images/ video_highest" system-bitrate="56000" />
<video id="smile" src="http://www.hotwired.com/images/video_high" system-bitrate="33000" />
<video id="smile" src="http://www.hotwired.com/images/video_good" system-bitrate="22000" />
<video id="smile" src="http://www.hotwired.com/images/video_slow" system-bitrate="12000" />
<video id="smile" src="http://www.hotwired.com/images/video_crap" system-bitrate="8000" />
</switch>
</body>
</smil>
很甜，是吧？
第六页：属性
现在，假设你已经具备了smil的基本知识，但是建立真正功能强大的smil文档需要了解所有可用的smil标记符。不幸的是，本文不能对此涉及太多。我前面说过，smil现在只是一份工作草稿，还不值得花费精力学习所有的smil属性。
那么就让我们看看一些最常用的smil属性：
abstract - 提供附加信息，或者内容的概述。
author - 内容的整理者。
begin - 决定媒体对象在它的父包容器中何时出现。
copyright - 版权信息。
dur - 媒体对象的持续时间。
end - 媒体对象的结束。
id - 对象的名称。
repeat - 媒体对象重复的次数。
system-bitrate - 连接速度。
system - captions - 是否使用音轨的基于文本的等价物。
system-language - 表现的语言。
system-overdub-or-caption - 使用子标题还是配音对话。
system-required - 扩展的名称。
system-screen-size - 特定的屏幕大小。
system-screen-depth - 表现的像素深度。
第七页：前景
现在，我把这样的想法充满你的头脑：一种规范的工作草稿，所有的主流浏览器都不支持。
smil是一种在网上实现多媒体内容的尝试，但是是否最终规范会得到广泛使用，或者甚至是否能发展为可以发布的规范，都是一种猜测。和smil草稿直接竞争的技术，如shockwave、realflash和active movie control的市场可能都比smil媒体对象类型的大。
实际上，对smil的真正威胁来自于动态html。浏览器厂商已经试图使动态html包容多媒体内容，他们可能把smil当作不必要和令人困惑的选择。另一方面，w3c在互联网社会中得到广泛的尊敬，她支持的多媒体规范应该能使网景和微软做出一些装模做样的笨拙的和不和谐的尝试 - 在为共同的目标而处理多媒体时。
网景和微软好象都对smil保持一种观望的态度，每一方在宣布某种支持之前都在等着对方的声明。可能至少要一年的时间，smil才能被考虑集成到浏览器中，这取决于w3c是否能给这份草稿正式的祝福（也取决于便宜的、高速的连接是否能成为现实）。总之，smil还是不错的。它还不够强大，但是孕育着希望。我宁愿css成为smil缺省的布局协议，除非它的草稿作者有使用基于smil的布局的更好的理由。我也期望看到不同的回放速度和在给定媒体对象内设置开始和结束点的能力。以我的理解，草稿还不支持这样的功能。因此，我们现在我们不得不等待，并期望这种目前不被支持的规范能实现我们喜欢的浏览器能支持的版本。