收費、免費；自發、被要求；文章、書、圖、影片；技術、不技術的，雖然做過很多不同的翻譯，倒是不敢說自己做得有多好。心自然都用上了，足是不足就讓他人評斷，不過有些想法或許還是可以註記一下：
對文本的掌握是基礎。所以，將外文翻譯為中文，對原文的理解應是最低要求。這包括外語能力，也包括專業詞彙。外文好的人就能翻譯？這絕對是錯的，就是會有哪種「每個字我都知道意思，拼起來卻不知道在說什麼」的狀況。
在紀錄片的字幕翻譯時，這點的困難度大幅提昇。考慮記錄片的本質，被記錄者說的話原本就很可能不是說給螢幕前的觀眾聽，要從斷簡殘篇中了解意思當然不容易。就算了解了意思，怎麼兼顧說話的語氣同時翻出原意，又是另一個挑戰。這很容易造成翻譯者照著（自以為理解的）原意，另創語句的情況。有時這不見得有什麼影響，有時就失之毫釐差之千里了。
（廣義的）HTML5 除了絢麗的各種 CSS3 及新 JavaScript API 組合技之外，還有一個十分實用、卻比較容易忽略的 HTML5 Forms。Firefox 4 實作了其中不少東西，這篇文章將大致介紹一下這玩意。
本文編譯自 Mozilla Hacks 的文章：Firefox 4: HTML5 Forms。原文亦採 CC:BY-SA 3.0 釋出。要實際試用文中的表單效果，你需要以支援 HTML5 表單的瀏覽器觀看此頁。關於各瀏覽器的支援程度，文末將略提一下目前的概況，可逕自參考。
HTML5 中新增了不少 INPUT 元素 的 type 屬性值，可以表達我們希望使用者輸入哪一類的資料，從而在語意甚至互動呈現方式上獲得更好的結果。
舉例而言，手機上虛擬鍵盤的輸入一向受限於顯示區域、經常得在各種模式（中文、英文、數字）間切換。假若一開始就擺明了要輸入電話號碼、那麼瀏覽器就可以自動呼叫數字鍵盤出來，節省時間也增進體驗；又或者，如果這個欄位就是要輸入 URL，那麼或許也可以跟瀏覽器的瀏覽紀錄互相結合以節省使用者記憶的功夫。
Firefox 4 Beta 7 裡新增了以下幾種 type：
<input type="search">
<input type="tel">
<input type="url">
<input type="email">其中 url 與 email 會自動驗證使用者是否確實輸入了網址或電子郵件地址格式的資料，等下會再提一下這個部份。
還有一個新的 OUTPUT 元素，用來表達某個區域的內容是因應表單的輸入而改變的。例如，你填了出生年月日後，就在此顯示你幾歲那類的。寫法如下：
<output for="i1 i2">for 屬性中是以空白字元分隔的、「構成這個輸出結果」的表單元素 ID 清單。使用這個元素主要是可以讓補助工具（如螢幕閱讀軟體）了解該區域的語意並提供對應服務，但 OUTPUT 裡的內容並不會「自動」計算出來，你還是得用 JavaScript 算好後填進去。畢竟，瀏覽器怎麼知道你想如何計算呢？
長久以來，網頁世界裡一直缺乏「ComboBox」這樣的元件：一方面能接受使用者自由輸入、二方面也能提供預選的清單，讓使用者更方便。過去我們可以利用 JavaScript 「做」出類似的效果，而以後則可以使用 DATALIST這個新元素來處理。在DATALIST 中所有的 OPTION元素，都會被視為是這份清單裡的備選答案。在清單定義完畢之後，則可在 INPUT 裡加上 list 來使用。範例如下：
<label>輸入所在城市：<input list="cities"></label>
<datalist id="cities">
或
<label>從清單中挑選
<select>
<option value="Taipei">台北</option>
<option value="Tainan">台南</option>
<option value="Taichung">台中</option>
<option value="Taidong">台東</option>
<option value="Taihsi">台西</option>
</select>
</label>
</datalist>
以這個方式書寫的話，如果訪客的瀏覽器不支援這個功能，也會直接略過 DATALIST 而將當中的 SELECT 選單顯示出來，所以不必擔心使用者就因此無法使用。你可以另外拿一個不支援這個標籤的瀏覽器來看本頁試試。
不必再仰賴 JavaScript 將輸入焦點移到使用者第一個要輸入的表單欄位了！只要在要搶輸入焦點的 INPUT 元素上加入 autofocus 屬性即可：
<input autofocus>在使用者未輸入文字前，要在欄位裡顯示的東西。可以用來提示使用者該輸入些什麼，例如：
<label>電話：<input placeholder="02-22223333#311"></label>
<label>意見：<textarea placeholder="請輸入您對本產品的意見。"></textarea>現在表單元素的書寫方式將有更多靈活的變化。
form 屬性INPUT 不再需要放在 FORM 元素中了，現在放在任何地方都行，只要加上 form 屬性指明要歸屬的 FORM id，此部份的資料就會隨該表單一併送出。
舉個實用的例子：你想在網頁頁首放一個簡單的搜尋欄位，又想在頁尾另外提供更進階的搜尋功能選項。那麼，頁首可以這麼寫：
<input type="search" name="search_field" form="search_form">而頁尾可以這麼寫：
<form id="search_form" action="search.php" method="post">
<fieldset>
<legend>進階選項</legend>
<input type="checkbox">也搜尋私人內容
<!-- 其他內容 -->
</fieldset>
</form>這麼一來，兩個部份就屬於同一個表單，而你可以更自由地隨意擺放。
在 FORM 元素中定義的屬性，都可以視情況、由表單欄位中的設定來推翻。目前表單的送出按鈕（包括 BUTTON 跟 type="submit" 的 FORM）支援的相關屬性有：formenctype、formaction、formmethod 及 formtarget。
有個可能的使用情境是，若表單尾附上「預覽」及「送出」兩個按鈕，則按下去後的表單行為不見得要都相同：
<form action="new_post.php" method="post">
<label>標題：<input type="text"></label>
<label>內文：<textarea></textarea></label>
<input type="submit" formaction="preview.php" formmethod="get" value="預覽">
<input type="submit" value="送出">
</form>若使用者按下「預覽」鈕，則表單送出的方式會從 POST 改為 GET，且傳送目標也從 new_post.php 改為 preview.php。
我們經常需要驗證表單中的資料，確定使用者輸入了正確資訊。我們可以在表單送出前用 JavaScript 驗證資料，也可以在表單送出後以 PHP 等後端語言驗證。一般來說我們都希望使用者盡早知道自己輸入錯誤的地方，所以前端的 JavaScript 多少是會做的，那麼如果瀏覽器就可以處理這塊，不是很好？
required在表單元素中加上 required 屬性，就代表要求使用者一定要填寫這個欄位。以 Checkbox （多選方塊）來說就代表這個格子一定要勾，而 Radio button （單選鈕）的情況則代表這群按鈕中要選一個。
直接試試以下範例吧！
<input type="text" required><input type="checkbox" required>
<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>url自動驗證是否為 URL。
<input type="url" value="mozilla">
<input type="url" value="http://mozilla.org">email自動驗證是否為電子郵件地址。如果再加上 multiple 屬性的話，就可以驗證以逗號分隔的多個郵件地址。（multiple 屬性也適用於 type="file" 的欄位。）
<input type="email" value="foo">
<input type="email" value="foo@bar.org">
<input type="email" multiple value="foo@bar.org, spongebob">
<input type="email" multiple value="foo@bar.org, spongebob@squarepants.org">這種驗證方式並不會排除有「+」號的 email 地址，所以 Gmail 那類可以在帳號上另外指定標籤（如 bobchao+spam@gmail.com）的方式也適用。
如果你想進一步控制驗證方式，可以使用 setCustomValidity 方法撰寫 JavaScript 來驗證表單。傳入字串就代表未通過驗證的錯誤訊息，以 tooltip 方式顯現（且，該表單元素會被標為未通過驗證）；傳入空字串則表示驗證通過。
<label>請輸入密碼：<input type="password" id="password1" oninput="checkPasswords()"></label>
<label>請再輸入一次密碼：<input type="password" id="password2" oninput="checkPasswords()"></label>
<script>
function checkPasswords() {
var password1 = document.getElementById('password1');
var password2 = document.getElementById('password2');
if (password1.value != password2.value) {
password2.setCustomValidity('您這兩次輸入的密碼不同，請再次確認！');
} else {
password2.setCustomValidity('');
}
}
</script>若表單中有任何元素被標為未通過驗證，則送出表單前就會被擋下來、將輸入焦點自動移至第一個未通過驗證的表單元素、顯示錯誤訊息。若你想自訂這樣的行為，可以在 FORM 元素上設定 novalidate 屬性，或於送出表單的按鈕加上 formnovalidate 屬性。
關於驗證表單這點，Mounir 寫了另一篇文章，可參考。我（柏強）可能也會翻譯那篇，資訊很豐富。
因應這些新增的表單功能，CSS 部份也有些新的選取符。
:required、:optional預設情形下，所有的元素都屬於 :optional 的影響範圍。如果你為某元素加上 required 屬性中是以空白字元分隔的，則該元素會改套用 :required 的樣式。以下是自訂樣式的必填資訊輸入欄位：
:-moz-placeholder這個擬似類別可以調整 placeholder 的樣式。這種設定方法還沒進入 CSS 標準，這麼寫就只有 Gecko 相關瀏覽器看得到了。WebKit 瀏覽器也有一個一樣的東西，以下為兩類瀏覽器都能看到效果的範例：
<style>
#selectors2 :-moz-placeholder {
font-style: italic;
}
#selectors2 ::-webkit-placeholder {
font-style: italic;
}
</style>
<form id="selectors2">
<input placeholder="Style me">
</form>HTML5 Forms 還算比較新的功能，各瀏覽器的支援程度也大不相同。Opera 在 HTML5 Forms 還叫做 Webforms 2 時就實做了部份規格草案內容，所以雖然支援情形良好，但有些行為反而與後來的規格修訂結果有些出入；WebKit 的瀏覽器也已經支援了部份規格，所以也可以實際試試看。
Firefox 4 已經不會再加上更多表單相關功能，而要完整支援 HTML5 Forms 則還有一段路要走：還有些新的欄位型態（數字、色彩、日期）、屬性（數字變動間距、最大值、最小值）、事件（onforminput、onformchange）等等，尚未實做。在未來的版本中，我們會一步步加上去。
這篇文章只是表單功能的概括介紹。Mozilla Developer Network 上還有更詳細的資訊，歡迎參考。
Interactive Sketching Notes 0.1，姑且譯為「互動素描標記法」。前端工程的工作裡，無論是跟別人解釋互動點子、跟設計師溝通出圖什麼的，有套一致的標記方式應該是比較有幫助。
字不多，又是 CC:BY-SA，我就翻完了，請用。有什麼翻譯建議，或者你實務上的經驗想分享的話，也當然歡迎留言。
有點遺憾沒能用語義良好的 SVG 來呈現，搞不好哪天會發瘋把 Style 全部抽出來 XDD 有空再說吧。
原文 The Perfect 404 by Ian Lloyd
Translated with the permission of A List Apart Magazine and the author[s]. 授權採 CC:BY-NC-SA 3.0（因為 ALA 不給商業利用。）
Bob: 我譯得很隨性，就原有的句子的意思、在描述上自由發揮了。也就是說，我不會變更作者的意思，但如果發現原意用中文不好體會，就會改用容易體會的方法換句話說。所以總之，相當程度上，我在改寫。但，翻譯原本就是改寫了，我並不真的是信達雅的信徒。
又，原文程式碼部份採「對讀者友善」的方式用了折行標記等東西，我這邊改採「對剪貼簿友善」的作法、把原文折行的部份又併回一行了。這樣比較好複製，至於如果你要印出來… well…
如果您發現哪些部份翻譯有誤，請留言指教。
糟，好像有什麼出了問題，但你也不確定是什麼 — 是你的問題、還是網站的問題？接下來又該怎麼辦？
歡迎來到 404 錯誤頁的世界。你直接輸入網址、也或許是點了某個已經年久失修的連結，向伺服器要求一份網頁，隨即發現自己身處虛擬世界中的飄渺之處。對訪客好一點的網站還會提供幫助，但大部分則就什麼事也不做、單純仰賴瀏覽器內建的功能向訪客描述目前狀況。我們當然能做得更好點，不是嗎？
對於在伺服器上設定自訂 404 頁的方法，我就不提了，建議你可以讀這些文章：
然而，我在此將針對大部分造成這種錯誤的原因，提出打造自訂 404 網頁的策略建議。
要開始著手設計，我們得先看看大眾發現自己身處 404 網頁的常見理由：
這些理由都會前往同樣的地方，但處理的方法卻應該稍有不同 — 404 網頁必須針對不同狀況分別量身訂作。有些小技巧可以用來處理上述的情境，但我的第一個建議卻非常簡單…
無論如何，都要告知訪客情況有誤，但不要指責訪客、就算你知道真的是他們的錯也一樣！這邊可用「可能」、「或許」等詞彙，別弄壞與網站訪客的關係，一旦搞砸、搞不好再也沒機會彌補了。
除了「出錯了」的文字外，請確保錯誤訊息網頁上包含這些：
也請避免使用術語。我的意思是，因為我們算一掛的，所以在這裡可以討論 404；不過 60 歲的阿姨逛編織網站碰上錯誤連結，來到這頁後可能就完全不瞭「404」是什麼東西。如果你想使用「Error 404」這樣的詞，那便隱晦點 — 例如放在頁尾，留它向看得懂這些電腦黑話的網路咖打聲招呼。
接著，來看看怎麼打造 404 網頁可以讓它幫你一把、而非推你一下。
到此，我得先說清楚，這邊的技巧需要用上不少 JavaScript（你不見得可以用伺服端的程式來解決這些問題，這端視伺服器設定）。所以，記得使用 <noscript> 標籤，讓關掉 JavaScript 的訪客也能獲得妥當的訊息。如果你能用伺服端程式，那便最好，可以無視瀏覽器跟網頁無障礙等等的問題，下面這些程式碼就斟酌參考。
首先，要設定一些變數：
var strReferrer=document.referrer.toLowerCase();
var blnSearchReferral = false;
var blnInsiteReferral = false;
var str="";
var strSite = "";接著，要拿這些變數做什麼呢？
網址打錯，或從過期書籤來的訪客不會有 HTTP referrer，所以要處理這種狀況的程式如下：
if (strReferrer.length==0)
{
str+='我們猜想下列連結對您可能有用：<\/p>';
str+='<a href="\/home.php"><img src="/images/home.gif" alt="Home Page" width="100" height="30"\/> <\/a>';
str+='<a href="\/site-map.php"><img src="/images/site-map.gif" alt="Site Map" width="100" height="30" \/><\/a>';
str+='<hr \/>';
str+='<p><strong>您找不到這個網頁，或許是因為：<\/strong><\/p>';
str+='<ol type="a">';
str+=' <li><strong>書籤\/我的最愛過期了<\/strong><\/li>';
str+=' <li>搜尋引擎上<strong>關於我們網站的連結過期了</strong><\/li>';
str+=' <li><strong>打錯網址</strong><\/li>';
str+='<\/ol>';
document.write(str);
}如果訪客有 referrer 值，我們可以先辨識出幾個特定的搜尋引擎（你可以依據自己的喜好調整辨識清單）。辨識後，我們拆解搜尋參數，看是否有與此次搜尋相關的頁面：
if (strReferrer.length!=0)
{
if ((strReferrer.indexOf(".looksmart.co")>0)||
(strReferrer.indexOf(".ifind.freeserve")>0)||
(strReferrer.indexOf(".ask.co")>0)||
(strReferrer.indexOf("google.co")>0)||
(strReferrer.indexOf("altavista.co")>0)||
(strReferrer.indexOf("msn.co")>0)||
(strReferrer.indexOf("yahoo.co")>0))
{
blnSearchReferral=true;
//取得網址 — 切到第一個斜線為止
var arrSite=strReferrer.split("/");
//找出搜尋字串
var arrParams=strReferrer.split("?");
var strSearchTerms = arrParams[1];
arrParams=strSearchTerms.split("&");
strSite=arrSite[2];
var sQryStr="";
//定義不同引擎查詢關鍵字的方式
var arrQueryStrings = new Array();
arrQueryStrings[0]="q="; //google, altavista, msn
arrQueryStrings[1]="p="; //yahoo
arrQueryStrings[2]="ask="; //ask jeeves
arrQueryStrings[3]="key="; //looksmart
for (i=0;i<arrParams.length;i++)
//跑 URL 中所有的參數
{
for (q=0;q<arrQueryStrings.length;q++)
{
sQryStr = arrQueryStrings[q];
if (arrParams[i].indexOf(sQryStr)==0)
{//找到搜尋關鍵字了！
strSearchTerms = arrParams[i];
strSearchTerms = strSearchTerms.split(sQryStr);
strSearchTerms = strSearchTerms[1];
strSearchTerms = strSearchTerms.replace("+", " ");
}
}
}
//告知訪客網站有誤，以及原先搜尋的詞彙
document.write ("<p>您先前在 <a href='" + strReferrer + "' target='_blank'>" + strSite + "<\/a> <\/strong> 搜尋 「<strong>" + strSearchTerms + "<\/strong>」。然而，這個搜尋引擎可能有段時間沒來了，你找到的連結已經過期。<\/p><h2>放心，一切都好<\/h2><p>我們猜想下列連結對您可能有用：<\/p>");接著，針對不想流失訪客的特定來源關鍵字詞，可以加上幾行識別程式。舉例來說，假如搜尋「電器」跟「設備」時你的網站排得蠻前面、但相關的網頁卻搬家了，這時你當然不想流失那些 Google 來的訪客，對吧？
if (
(strSearchTerms.indexOf("widgets")>=0)||
(strSearchTerms.indexOf("electronics")>=0)
)
{
document.write("<a href='\/cool-widgets.htm'>我的電器設備大展<\/a><br \/>");
}
}
}當然，如果你的網站有站內搜尋功能，現在可以拿這個搜尋關鍵字來搜尋一次。站內搜尋或許能自動產生相同搜尋字詞的網頁連結，無須動用上述的工人智慧。但無論如何，建議採用工人智慧的方法，不然可能只是讓訪客多增加一次找不到網頁的機會而已。
從搜尋引擎來的迷途羔羊們都關照過了，接下來就必須對付 referrer 不是從搜尋引擎來（或至少不是從你挑的那幾個引擎來）的情況。我們得再增加些條件：
if (!blnSearchReferral)
{
strSite = strReferrer;
strSite = strSite.split("/");
strSite = strSite[2];
document.write("<p>從 <strong><a href='" + strReferrer + "'target='_blank'>" + strSite + "</a></strong> 來的這一頁已經不存在消失。<br/>建議您試試看下列連結：</p>");
}接著提供的連結就是首頁、網站地圖等等。
即使發現 referrer 是從自己的網站來，你也不好在 404 網頁上單單說「本網站有錯誤連結」。在這種情形下，你可能需要調整字詞，承認犯了小錯：
blnInsiteReferral =((strReferrer.indexOf("http://www.mysite.co.uk")>=0)||
(strReferrer.indexOf("http://www.myothersite.com")>=0))
if (blnInsiteReferral)
{
document.write("<p>這是我們的疏失！對您說聲抱歉，我們會揪出負責這條連結的人，在他修完錯誤後給他二十鞭。<\/p>");
}這下我們已經提供逃離 404 黑洞的路，但真的修好了什麼東西嗎？沒有。既然已經知道訪客索求的文件網址及其來源（如果有來源），那確實還有一些事情可作。我們可以自動、或要求碰上 404 網頁的訪客按下「回報錯誤」鈕，接著把這些資訊存進資料庫裡。要求訪客手動回報可以減少雜音，確保你看到的都是最重要的錯誤連結。接著要怎麼處理這些錯誤連結，就看你了。
想看上述建議實際運行的樣子，可以查閱下列放在 A List Apart 上的範例：
也可下載上面提的範例 404 網頁，將其依照需求修改。
前言：CC 在台灣時間昨天稍早發佈了「非商業性」認知調查報告，這是大家都很在意的一份研究，所以我利用 Google Translator Toolkit 很快地翻譯了一下 CC 的網誌文章。雖然報告本身不能真的直接拿來「定義非商業行為」，不過可以想見這一份 (以及未來可能的) 研究結果都會一步步反應在未來的 CC 授權條款中，值得有興趣的大家參考。以下翻譯部份原作為 Mike Linksvayer，以創用CC姓名標示3.0條款授權使用：
大約一年前，我們開始研究人們如何理解「非商業性」這個辭彙。這項研究由Andrew W. Mellon 基金會慷慨支持，內容含括深入訪談和兩階段的面談、線上焦點團體及網路問卷調查。最後這些調查的對象是從美國網路使用者隨機抽樣（因資源有限造成的地域限制），並額外包括由此網誌散佈消息所回收的開放問卷 （在報告中稱為「CC 之友」）。
今天，我們在此公佈定義非商業性使用的研究報告和原始數據，分別以CC 姓名標示授權條款及CC0公共領域宣告釋出 —— 沒錯，這份與「非商業性」相關的報告，完全可以用於商業目的。請參考今天的新聞稿 。
這項研究由Netpop Research執行，並由學者及一個工作小組擔任顧問。工作小組的成員包含數位CC 司法領域專案成員、CC 工作人員、及 CC 董事會成員。
在 CC 與「非商業性」相關的授權條款中，皆包括一段「商業性用途」的定義，以此避免相關使用權利授予任何商業目的：
您不得以主要為獲取商業利益或私人金錢報酬的方式…
多數受訪者（含87％的創作者及85％的利用人）表示，這段定義與他們心中的認知「基本相同」（43％的創作者與42％的利用人）或「不太相同，但 仍符合」（44％的創作者及43％的利用人）。只有7％的創作者和11％的利用人表示，這段定義與他們心中的認知「不同、且不符合」；而有6％的創作者及 4％ 的利用人回答「不知道/不確定」。有74％的創作者及77％的利用人認為他們個人的定義與其他人都相同，而只有13％的創作者和11％的利用人在完成問卷 後想更改他們自己的定義。
在以 1 代表「肯定為非商業行為」、100 代表 「肯定為商業行為」的評分中，創作者與利用人都認為作品與線上廣告結合使用為「商業行為」 (評分分別是84.6及82.6分）。然而，其他更具體的案例，讓我們發現許多情況下要根據脈絡來決定是否為商業行為。例如，創作者和利用人對於「非營利 組織在網站上利用了作品，並藉網路廣告賺取足夠費用支持網站運作」這個案例的商業性認知程度，分別給予 59.2 及 71.7分。
同樣 的評分方式下，創作者和利用人皆認為利用作品來獲取金錢屬於商業行為（分別評為89.4及91.7分），但針對非營利組織 (或僅為平衡成本) 的相同利用方式則再次給予較低的分數。最後，兩個族群皆認為「個人或私密」的利用方式為「非商業性使用」，不過創作人在這個項目上較利用人略為傾向以商業 行為解釋（分別評以 24.3 及 16.0 分）。
在開放問卷調查中，雖然由調查數據難以比較全球「CC 之友」與美國網路抽樣兩者的實際經驗，但兩個族群在某些項目上的評分傾向確實不同。舉例來說，創作人與利用人針對同樣的「非營利組織線上廣告」案例，分別評以 35.7 及 40.3 分，也就是說他們較傾向以非商業行為解釋。全球 CC 之友也認為「個人或私密」使用為非商業行為，分別評以 8.2 和 7.8分；再回顧一次，1 分代表「肯定為非商業行為」、100 分代表「肯定為商業行為」。
JavaScript Object Notation (JSON)在網站開發的世界裡已經有很多人採用，成為不可或缺的一部份。Firefox 3.5 起以 window.JSON 來原生支援 JSON 格式，本篇 (原文) 將為各位做個相關介紹。
JavaScript 等腳本語言的標準原型 ECMAScript 在第五版時將 JSON 原生支援列入規格，目前 Firefox 3.5 跟 IE8 都支援，而且其他瀏覽器必定也會很快加入支援行列。JSON 原生支援有兩個優點：
來看些範例 —— 一個以 HTTP GET 等方法傳回的簡單 JSON API 搜尋結果看起來大概像這樣：
/*
從主機取回一段搜尋結果的 JSON 資料
*/
var data = ' { "responseData":
{"results": [
{
"SafeSearch":"true",
"url":"http://www.arunranga.com/i.jpg",
},
{
"SafeSearch":"false",
"url":"http://www.badarunranga.com/evil.jpg",
}
]}}';您可以用這樣的方式處理資料：
/*
取回、操作上一段的 JSON 資料
如果用支援原生 JSON 的其他函式庫，會更容易一些
*/
if (window.JSON) {
var searchObj = JSON.parse(data);
for (var i=0; i++; i < searchObj.responseData.results.length) {
if (searchObj.responseData.results[i].SafeSearch) {
var img = new Image();
img.src = searchObj.responseData.results[i].url;
// ... 在 DOM 中插入圖片...
}
}不過，網頁設計師通常並不直接使用 JSON 原生支援，而常用 jQuery 等函式庫自不同網域取回、解析 JSON 資料，這也是 JSON 大展身手的地方。考量到效能問題，有些函式庫已經開始採用瀏覽器的原生 JSON 能力來解析資料。目前 jQurey 與 Dojo 都已支援原生 JSON，所以您使用這些函式庫時一方面在已原生支援 JSON 的瀏覽器上將獲得更好的效能、另一方面在尚未支援的瀏覽器上也可以順利解析 JSON 資料。
這篇有一個用 Firefox 3.5 新增之 -moz-transform 所製作出來的範例，非常有趣 (強烈建議要看啦)，一例勝千文，看了再說：
當然，-moz-transform 目前還是個 2D 效果的玩意，製作出來的「3D」也是可稱為 2.5D 的視覺效果而已。目前要做到真正的 3D，用這個特性還辦不到。
來看程式碼：首先以 DIV 標籤圍出立方體的三個顯示面：
<div class="cube">
<div class="face top">
</div>
<div class="face left">
</div>
<div class="face right">
</div>
</div>.cube {
position: absolute;
}
.face {
position: absolute;
width: 200px;
height: 200px;
}接著把這 3 個 div 都轉為平行四邊形：
.top {
-moz-transform: rotate(-45deg) skew(15deg, 15deg);
}
.left {
-moz-transform: rotate(15deg) skew(15deg, 15deg);
}
.right {
-moz-transform: rotate(-15deg) skew(-15deg, -15deg);
}至此，三個方塊已經以平行四邊形的樣子排成正六芒星，接著我們只要調整位置即可。你可以用方程式算出三個面所應該排列的座標點，或者慢慢一步步調整到正確的地方也行。下方的陰影其實就是 top 那一面的位移複製品，只是設定了 opacity: 0.5 的背景色。另一個方塊也是把樣式與標籤直接再複製一份做出來的，並以 translate(600px, 400px) 位移、以 scale(0.5) 將尺寸縮小 50%
方塊中間要填入什麼都行，其中有一面以 HTML5 Video 標籤放入了影片，你可以看到影片也被調整成平行四邊形的樣子 :P
除了 Firefox 3.5 之外，Safari 3.1+ 與 Google Chrome 亦以 -webkit-transform 的型態支援。相關文件可參考 https://developer.mozilla.org/En/CSS/CSS_transform_functions
原文出處，篇數太多不曉得怎麼開頭了 orz 反正大家看這系列下來應該都知道我是重點節譯。
現在可以上網看網頁的裝置越來越多，大家對網頁的期待也因裝置限制或功能而有所不同。CSS2 因此加上了媒體類別相關的設定，讓你可以指定某 CSS 宣告適用的裝置，像這樣：
<link rel="stylesheet" media="print" href="print.css">這樣的確有效解決某些問題，不過網頁設計師要面對的不只是裝置的不同：即便是同一類型的裝置，也有可能有直放、橫擺、螢幕大小、解析度等等各式各樣的問題。Firefox 3.5 開始支援 CSS3 草案的 media query (媒體型態查詢) 機制，提供因應裝置各項特性而套用不同樣式的能力，讓各式裝置可以更適切地套用相應的樣式。以範例網頁來說，如果顯示範圍高大於寬 (直式)，則「all and (orientation:portrait) 成立、套用 portrait.css 樣式：
<link rel="stylesheet" media="all and (orientation:portrait)"
href="portrait.css">而如果顯示範圍寬大於高 (橫式)，則套用 landscape.css：
<link rel="stylesheet" media="all and (orientation:landscape)"
href="landscape.css">最棒的是，每次螢幕狀況有所轉換時，都會重新計算、套用一次樣式，所以當你以橫式的視窗開啟範例後，不妨慢慢調整視窗大小；一旦高大於寬 (變成直式)，套用的樣式會立即變更。
如果你打開 landscape.css 瞧瞧，會發現其中的某些樣式也採用 media query 來調整。例如網頁文字尺寸預設為 14px，但若顯示範圍寬度至少有 600px，則改用16px 字體顯示：
@media all and (min-width: 600px) {
body {
font-size: 16px;
}
}倘若顯示範圍再大一點、至少有 700px 寬的話，則採用 20px 的字體尺寸顯示文字：
@media all and (min-width: 700px) {
body {
font-size: 20px;
}
}還有另一條規則讓 800px 以上寬度的顯示介面擁有更大的字體，不另贅述。總之，當你調整視窗大小，就可以馬上發現變化。有一個不錯的應用點子，是隨著螢幕寬度調整內容欄數 — 越寬的的螢幕，分成越多欄來呈現。
目前 Firefox 3.5、Safari 3、Opera 7 以上的瀏覽器都媒體型態查詢，一般來說新版本瀏覽器是加上更多型態或查詢方式。Firefox 的相關文件請參考 MDC，而 Opera 9.5 的相關說明則在這篇接近最後的地方。目前沒有找到 WebKit 的相關資料。
無論使用者用哪樣的裝置瀏覽你的網站，利用媒體型態查詢功能、可以讓你做出更方便他閱讀的網頁。我的網誌應該會採用相應的技術來製作邊欄，你也試試吧！
這篇主要比較開放影片編碼格式的品質問題，緣起是 Google 的 Chris DiBona 在 WhatWG 郵件群組貼了一篇文章，裡頭提到：
如果 YouTube 要採用 Theora 編碼、還得維持目前的播放品質，那會佔掉全世界大部份的頻寬。
目前關於影片編碼的論戰已經慢慢嘴炮化、缺乏實質的比較，所以 Greg Maxwell 回了他一篇、並放上下列的比較結果。(本篇由原作者授權張貼於顛覆網路 35 天專欄，柏強我只依據往例、節譯重點。)
以下是將同一段影片分別以兩種尺寸編碼、丟上 YouTube 處理後再下載，然後與 Ogg/Theora+Vorbis 比較的情形，各位可以下載觀看以便比對。
~499kbit/sec 比較
YouTube
Download (H.264+AAC; 17MiB)
Ogg/Theora+Vorbis
Download / Watch (Ogg/Theora+Vorbis; 17MiB)
~327kbit/sec 比較
YouTube
Download (H.263+MP3; 12MiB)
Ogg/Theora+Vorbis
Download / Watch (Ogg/Theora+Vorbis; 12MiB)
位元率都分別標示出來了，而 Theora 的版本故意稍稍降一點位元率，以防止略大一些的檔案大小會被懷疑是故意提高品質。要真的公平比較的話，請把音效也考慮進去，光看靜態圖片絕非比較影片品質的好方法。這邊的靜態圖片只是為了方便讀者而做。
以下是這四個檔案的完整製作方法：
Greg Maxwell 的信件可以查閱原文。
拜我偷懶到今天才動手看這篇所賜，有另一篇補充的文章可以即時一併翻譯。Maik Merten 為 HD 畫質的影片也做了比較，截圖如下：說實在差異不大，而且 Theora 的仔細看感覺好像還比 H.264 更好 (注意頭髮的地方)。別忘了看看影片來比較喔：
所以綜上所述，別嘴炮了，要比較畫質還是實際用眼睛看看吧。
今天 (好吧，又是大前天…) 的顛覆網路 35 天綜合前面所說的 @font-face 及一些 Firefox 3.5 新支援的 CSS，組合成一個有趣的範例。直接看一下：
以下分別簡單說明所用到的東西：
首先是整個「工具列」的樣式。我們使用 -moz-border-radius 將左上及右下的邊框設定為圓弧：
-moz-border-radius:10px 0px 10px 0px;接著利用之前提過的 -moz-box-shadow 設定這個方塊的陰影，分別向右向下位移 5 像素、且柔邊為 6 像素：
-moz-box-shadow: #9BD1DE 5px 5px 6px;接下來是其中的按鈕，我們也會用到 -moz-border-radius，但額外使用 -moz-box-shadow 來區分按鈕目前狀態。一般的按鈕是普通陰影，不過滑鼠游標移上 (hover) 時則利用 inset 關鍵字設定內部陰影、文字本身也套用 text-shadow 陰影效果。點選按鈕後保持內部陰影狀態，但加深色彩、加大範圍：
#superbox button {
-moz-border-radius: 5px;
-moz-box-shadow: #000 0px 0px 8px;
}
#superbox button:hover {
-moz-box-shadow: inset #989896 0 0 3px;
text-shadow: red 0px 0px 8px;
}
#superbox button:active {
-moz-box-shadow: inset #1C1C1C 0 0 5px;
}在此以 @font-face 設定每個按鈕個別的字體，舉第一個按鈕為例：
@font-face {
font-family: Brock Script;
src: url("BrockScript.ttf");
font-style: normal;
font-weight: normal;
}
.first {
font-family: Brock Script;
}@font-face 的說明可以看先前的文章，另外這個範例裡也利用一點 JavaScript 技巧動態替換下方文字段落的類別，以便在你點選按鈕時以相應字體顯示。
利用這些效果，我們就做出了「很像圖片，但不是圖片」的按鈕囉！大家可以試試看。
我終於趕上今天該有的進度了 XD 這一篇的重點我想是相容性與效能比較，重點節譯如下：
W3C 的萬年草案之一 DOM 選取符 (Selector) API 可以幫 JavaScript 程式設計師以 CSS 選取符方式輕鬆選取文件中的 DOM 元素，而且大部分的新瀏覽器，包括 IE8、Chrome、Safari 及即將 (?) 現身的 Firefox 3.5 都已經有基本支援了。
選取符 API 提供 querySelector 與 querySelectorAll 兩種方式協助你選取 DOM 元素，差別在於 querySelector 僅傳回第一個符合條件的元素、而 querySelectorAll 會以元素陣列的方式全部傳回。例如下面的 HTML 碼：
<div id="id" class="class">
<p>First paragraph.</p>
<p>Second paragraph.</p>
</div>你可以用下列程式輕輕鬆鬆把 id 為「id」之 DIV 中的兩個 P 元素背景設為紅色：
var p = document.querySelectorAll("#id p");
for ( var i = 0; i > p.length; i++ ) {
p[i].style.backgroundColor = "red";
}也可以用這樣的方式讓類別為「class」之 DIV 中的第一段套用「first」類別：
document.querySelector("div.class < p:first-child")
.className = "first";這類的條件在早期都蠻麻煩的，有了選取符 API 後就方便多了！不過有個瀏覽器方面的問題：大部分的瀏覽器 (Firefox、Opera、Safari、Chrome) 都可以用 CSS3 選取符 來選取元素，IE8 則沒支援那麼多、大多還落在 CSS2 選取符的範疇內。雖然一些比較複雜的選取條件可能受限於相容性問題而無法利用 CSS3 選取符，但至少還是挺有用的。
而對於開發人員，問題可能就是怎麼選用適當的選取符組合。你可以看這些文件增進對選取符的相關知識：
其實就算瀏覽器並非全都完整支援，Web 開發者用選取符 API 也早已用得很兇了：已經有不少 JavaScript 函式庫時做出類似的東西：
當然，用這類函式庫「模擬」出來的 API，效能跟原生的還是有差。下面這張圖是先前測試的結果，供您參考：
由這張圖可以明顯看出，原生支援此 API 亦可能大幅提升網際應用程式的執行效率。
今天 (是昨天吧？對不起我富奸化了…) 討論的是 box-shadow 方塊陰影。box-shadow 是 CSS3 草案的一部份，Firefox 3.5 在此以 -moz-box-shadow 實驗性支援、待規格定案後則會繼續以 box-shadow 出現。這個特性可以繪製一個區塊的陰影，我們直接看幾個範例來說明。以下的範例都會先秀程式碼、接著是 Live demo、再為您提供 Mac OS X 上的螢幕截圖：
-moz-box-shadow: 1px 1px 10px #00f;
如你所見，頭兩個值是設定陰影位移點數，接著是柔邊、陰影色彩。事實上你還可以在最前面加上「inset」來製作內部陰影：
-moz-box-shadow: inset 1px 1px 10px #888;
接著，你還可以用第四個數值「延展距離」來調整陰影的大小，可以向外延展(正值)也可以向內縮減(負值)：
-moz-box-shadow: 0px 20px 10px -10px #888;
跟 text-shadow 一樣，這裡也可以設定多重陰影 (感謝 Markus Stange)：
-moz-box-shadow: 0 0 20px black, 20px 15px 30px yellow, -20px 15px 30px lime, -20px -15px 30px blue, 20px -15px 30px red;
四層陰影疊起來，形成彩虹一般的效果。如同 text-shadow 一樣，Firefox 3.5 在這邊跟的是 CSS3 的規格，也就是先定義的陰影會放在最上層，在定義多層陰影時請記得這點。
最後一個範例裡，我們將色彩值以 RGBA 格式指定，這跟 RGB 方式類似、只是最後加上了代表可以製作半透明效果的 alpha channel 值。這個例子的透明度為 .5 (50%)：
-moz-box-shadow: inset 5px 5px 0 rgba(0, 0, 0, .5);
看不太出來？按一下加上背景圖應該會更明顯。圖片感謝eschipul提供，CC:by-sa。
box-shadow 算是草案中晚近出現的特性，瀏覽器的支援程度也不算很廣：
所以如果現在就要用，那最好把三條都列上去。下面這個範例可以讓支援此特性的瀏覽器都看得到效果，而不支援的也不過是以原本無陰影的面貌出現而已：
-moz-box-shadow: 1px 1px 10px #00f;
-webkit-box-shadow: 1px 1px 10px #00f;
box-shadow: 1px 1px 10px #00f;範例
這篇提到的非技術問題點其實不少，我盡可能大幅翻譯。當然還是要付註：請別要求精準翻譯，那不是我的本意。
Firefox 3.0 已經在許多方面添上讓網頁字體看起來更美觀的技術，而 3.5 版加上的 CSS @font-face 技術則是要幫網頁設計師逃離系統預設字體的苦痛。以 @font-face 將 TrueType 或 OpenType 字體檔案「連」進網頁，就像連結外部 CSS 檔、JavaScript 檔一樣輕鬆愉快，而且 Safari 從 3.1 起已經支援、Opera 也打算在第 10 版支援這項技術。
要動態連結自訂字體，只要在 CSS 中以 @font-face 指定名稱就可以了。瀏覽器會視需求下載必要字體、所以你可以列舉一堆字型名稱也無妨：
/* Graublau Sans Web (www.fonts.info) */
@font-face {
font-family: Graublau Sans Web;
src: url(GraublauWeb.otf) format("opentype");
}
body {
font-family: Graublau Sans Web, Lucida Grande, sans-serif;
}支援 @font-face 的瀏覽器會使用 Graublau Sans Web 字體顯示文字，不支援的就用 Lucida Grande 或系統預設的無襯線字體了。請見範例。
大部分的字體設計時都只考慮一般、粗體、斜體、粗斜體這些情況，你可以使用 font-weight 與 font-style 來定義某特定情況要使用的字體，若沒特別指定則視為「一般」。
/* Gentium by SIL International */
/* http://scripts.sil.org/gentium */
@font-face {
font-family: Gentium;
src: url(Gentium.ttf);
/* font-weight, font-style ==> default to normal */
}
@font-face {
font-family: Gentium;
src: url(GentiumItalic.ttf);
font-style: italic;
}
body { font-family: Gentium, Times New Roman, serif; }這個範例顯示起來如下：
可別以為就是這樣而已，@font-face 常被忽視的特點、就是可以讓同組字體處理多達九段的字體粗細設定。日文開放字體 M+ Fonts 專案共有七段的粗細，範例如此頁：
有時我們可能會希望儘量使用使用者電腦上已安裝的字體、僅在沒有安裝時才從網路上動態下載。此時可以在 @font-face 裡的 src 特性以 local() 方式指定字體名稱。瀏覽器會依序試圖採用 src 列出的各個字體、直到其中一組讀取成功。
/* MgOpen Moderna */
/* http://www.zvr.gr/typo/mgopen/index */
@font-face {
font-family: MyHelvetica;
src: local("Helvetica Neue"),
local("HelveticaNeue"),
url(MgOpenModernaRegular.ttf);
}
@font-face {
font-family: MyHelvetica;
src: local("Helvetica Neue Bold"),
local("HelveticaNeue-Bold"),
url(MgOpenModernaBold.ttf);
font-weight: bold;
}
body { font-family: MyHelvetica, sans-serif; }下面的圖分別是此範例在 Mac OS X、Windows 及 Linux 上的顯示模樣。Helvetica Neue 在 Mac OS X 系統上很常見，不過 Windows 和 Linux 通常就沒裝，所以此範例在 Mac OS X 執行時會使用系統中的 Helvetica Neue、不會下載任何字體檔。在 Windows 與 Linux 中、瀏覽器發現本機上沒有相關字體後，終究會下載、使用 MgOpen Moderna 字體。MgOpen Moderna 原先就是為了當作 Helvetica 的代用品而生，所以看起來會很像。這樣設計師就可以在必要時才下載字體檔。
指定字體名稱時使用的是字體全名，這一般來說是字體名加上樣式名 (好比「Helvetica Bold」這樣)。Mac OS X 裡，可以在 FontBook 先選取字體後按下 Preview 選單的「Show Font Info」來查閱字體全名：
Linux 裡也有類似的工具，而 Windows 使用者可以到微軟網站上下載 Font properties extension，安裝後字體檔的「內容」就會顯示很多資訊，字體全名就在「Name」頁籤的「Font Name」裡。
僅有 Mac OS X 裡的 Safari 才支援 PostScript 名稱，所以 Mac OS X 下也可以使用 PostScript 名稱；而若字體格式為 OpenType PS (通常附檔名為 .otf)，則在 Windows 裡全名與 PostScript 名稱。綜上所述，設計師採用這類字體時最好把全名與 PostScript 名稱都寫進去以確保相容性。
即便使用 Unicode，大部分的語言還是會遇到缺字問題，少數民族語還更嚴重。有了這個動態連結字體的功能，就可以讓訪客看到這些特殊語言文字：
@font-face {
font-family: Scheherazade;
src: url(fonts/ScheherazadeRegAAT.ttf) format("truetype-aat"),
url(fonts/ScheherazadeRegOT.ttf) format("opentype");
}
body { font-family: Scheherazade, serif; }阿拉伯文這類的字體，文字的顯示方式與相鄰的文字有很大關係。不同作業系統有各自的技術來處理這類情形，在 Mac OS X 上需採用 AAT 字體、而 Windows 和 Linux 則需要 OpenType 字體。如果不為個別作業系統提供適當的字體格式，就無法正確顯示這個範例。範例裡由於 Windows 跟 Linux 平台不支援 AAC 格式，所以就會轉而下載 OpenType 格式字體；因此各平台各取所需，便可正常顯示：
Firefox 3.5 預設無法跨站取用字體檔。如有此類需求，必須依據 Firefox 3.5 支援的檔頭存取控制資訊格式、調整存字體檔伺服器的 HTTP 檔頭相關設定：
# example Apache .htaccess file to add access control header
<FilesMatch "\.(ttf|otf)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>要動態連結字體檔時，請先確認授權相關問題。若字體授權中用了什麼看不懂的字眼，則小心為妙。要是你確定授權沒問題，也建議可以在 CSS 的註解中註明授權方式以備存。
你電腦中大部分的字體檔都不見得能以這類連結的方式使用，畢竟這項技術還在應用初期，很多作業系統內建的字體也規定只能在單機上使用，或許日後對相關的方式會有更進一步的授權系統也難說。
另外，並不是免費的字體就一定可以用，有的字體規定不可再散佈，所以檢查一下比較好。
其實 IE 也早已支援字體連結，只是、格式用的是獨門的 EOT 檔。你可以用 (只有 Windows 上有的) MS WEFT Tool 將 TrueType 或 OpenType TT 字體轉為 EOT，OpenType PS (.otf) 則無法使用。
又，IE 只認 @font-face 中的 font-family 及 src，我們可以利用這點來寫跨瀏覽器的設定：
/* Internet Explorer 用 */
/* (*一定*要擺第一個) */
@font-face {
font-family: Gentium;
src: url(Gentium.eot) /* 不可用 format() */;
}
/* 其他瀏覽器用 */
@font-face {
font-family: Gentium;
src: url(Gentium.ttf) format("opentype");
}Firefox 3.5 還不支援 font-stretch 與 unicode-range，也不支援 SVG 文件中的字體定義。這些都會在未來的版本慢慢支援，一如往常、我們歡迎您的幫忙喔！
以下是從 CC 新的簡明版 FAQ 翻譯過來的草稿。因為覺得這個比較多人問，所以先跳過各種程序直接以個人名義翻譯一下：
視情況而定。要判斷是否違反「非商業性」(正確來說應該是定義「商業性」使用) 並不容易，我們已明白畫清界線事關複雜、也已經著手進一步釐清這個問題。
如果你對某種使用方式是否為商業性使用有所疑慮，我們建議你還是使用清楚標記可商業使用的作品較好 (例如以「姓名標示」、「姓名標示—相同方式分享」及「姓名標示—禁止改做」授權的作品)，或者直接與著作權所有人連繫、詢問對方是否願意直接授權您將作品用於商業行為。
為了幫助我們釐清商業性/非商業性這個問題，請閱讀非商業性方針的草稿，並且在討論頁留下你的想法與意見。
雖然 dotsub 上原先已經有人翻好了，不過我還是手癢修改一下... anyways 這可以讓你對朋友解釋 Twitter 是啥玩意：
Lee LeFever, CC: by-nc
那就給...
1
00:00:00,100 --> 00:00:03,000
有些 PowerPoint 實在很鳥
2
00:00:03,000 --> 00:00:05,500
我覺得自己必須跟大家講明白，請看
3
00:00:05,500 --> 00:00:07,500
最常見的 PowerPoint 錯誤第一名
4
00:00:07,500 --> 00:00:12,500
大夥老愛把所有要講的話
一字不漏地打上投影片...
5
00:00:16,300 --> 00:00:26,800
雖然這樣就不會忘記要講啥，但對聽眾來說實
在無謂無趣又無聊。如此聽眾肯定會晃神，甚
至根本不用等到你講完你的... 呃...
6
00:00:26,800 --> 00:00:28,300
（續前頁）第一張投影片！
7
00:00:32,500 --> 00:00:36,000
拜託，別再這麼搞了，拜託
8
00:00:36,500 --> 00:00:41,000
第二常見的是
很多人懶得按檢查拼 _自_
9
00:00:41,500 --> 00:00:44,000
大 _挫_ 特 _挫_！
10
00:00:44,000 --> 00:00:47,500
拼字錯誤會讓你看起來 _項_ 個白 _吃_
11
00:00:49,000 --> 00:00:52,500
要是看到紅色底線
拜託檢查一下拼字！
12
00:00:53,100 --> 00:00:55,100
而接下來我討厭的是...
13
00:00:55,100 --> 00:00:59,400
不要. 分成. 太多. 點.
留下. 重要的. 就好.
14
00:00:59,400 --> 00:01:04,600
太多. 點. 你的. 演講. 就.
沒了. 重點.
15
00:01:04,600 --> 00:01:05,100
事實上
16
00:01:05,100 --> 00:01:08,000
項目符號. 之所以. 叫. 「Bullet Point」（彈孔）. 是. 因為.
17
00:01:08,000 --> 00:01:10,600
聽眾. 忍不住. 對. 煩死人. 的講者. 開槍了！
18
00:01:17,000 --> 00:01:19,400
還指著照唸咧
19
00:01:22,400 --> 00:01:25,600
色彩配置太差勁也不好
20
00:01:25,600 --> 00:01:29,800
配色不協調、色彩太鮮豔
會使人無法集中注意力
21
00:01:29,800 --> 00:01:34,600
感覺迷惑、不適想吐
造成尿失禁！
22
00:01:34,600 --> 00:01:37,800
連我都不想停在這張太久
23
00:01:39,000 --> 00:01:41,000
還有些事情得講
24
00:01:41,000 --> 00:01:43,200
你使用的投影片張數越多
25
00:01:43,200 --> 00:01:46,900
這場演講實際上就越沒用
26
00:01:47,000 --> 00:01:47,900
可惜...
27
00:01:47,900 --> 00:01:49,900
...我的演講看來是在這
28
00:01:52,000 --> 00:01:55,500
我還發現更糟糕的
大夥也愛在投影片上貼堆數據資料
29
00:01:55,500 --> 00:01:58,500
他們貼的數據越來越多，以為這樣比較好
但根本不是這麼回事
30
00:01:58,500 --> 00:02:02,500
太多資料，根本看不清楚
溝通也越沒效
31
00:02:02,500 --> 00:02:04,800
想證明溝通效率多差很簡單
32
00:02:04,800 --> 00:02:07,800
只要加上數據、陰影、立體效果
33
00:02:07,800 --> 00:02:10,800
關係折線圖
34
00:02:11,000 --> 00:02:13,800
文字標籤也可以幫上不少忙
35
00:02:14,000 --> 00:02:17,800
好！差不多每張行銷投影片都長這樣
36
00:02:24,800 --> 00:02:27,300
行銷副總裁會站在投影片前跟你講
37
00:02:27,300 --> 00:02:28,600
「第四季的趨勢非常清楚...」
38
00:02:28,600 --> 00:02:30,600
清楚才有鬼勒
39
00:02:34,000 --> 00:02:36,800
接下來我要談關於動畫的事
40
00:02:36,800 --> 00:02:38,250
PowerPoint 可以使用動畫效果
41
00:02:38,250 --> 00:02:39,700
讓東西在投影片上飛來飛去
42
00:02:39,700 --> 00:02:40,700
這不見得不好
43
00:02:40,700 --> 00:02:43,600
視覺上搭配得宜的話，就更有說服力
44
00:02:43,600 --> 00:02:45,600
不過如果你沒想太多就隨便擺
45
00:02:45,600 --> 00:02:48,000
動畫就會讓聽眾根本不瞭你要講啥
46
00:02:48,000 --> 00:02:50,600
他們只會想「哇，酷，哇！」
47
00:02:50,800 --> 00:02:52,200
附帶一提
這張圖可以歸納出一些區域
48
00:02:52,200 --> 00:02:56,200
例如這邊是簡單有效的
49
00:02:54,200 --> 00:02:56,200
例如這邊是簡單有效的
還有花俏沒重點的
50
00:02:56,200 --> 00:02:59,000
簡單但無聊的、兩者皆失的
51
00:02:59,000 --> 00:03:01,200
簡單但無聊的、兩者皆失的
超保守派的、極端沒用的
52
00:03:01,200 --> 00:03:03,800
簡單但無聊的、兩者皆失的
超保守派的、極端沒用的
注意力喪失的、亂七八糟的
53
00:03:03,800 --> 00:03:06,800
天兵三角、逆天兵三角
54
00:03:06,800 --> 00:03:07,800
鑽石菱形
55
00:03:07,800 --> 00:03:08,900
鑽石菱形、五力結合
56
00:03:08,900 --> 00:03:13,000
以及毫無意義的亂動
57
00:03:15,500 --> 00:03:18,700
做那張投影片花了我一個半小時
58
00:03:19,700 --> 00:03:22,900
PowerPoint 居然可以這麼浪費生命
太神奇了
59
00:03:24,900 --> 00:03:29,600
另外，我還研究出一種識人術
叫做「字型人格分析」
60
00:03:29,600 --> 00:03:33,100
基本上，什麼人就會用什麼字型
61
00:03:33,100 --> 00:03:35,100
那麼多種字型，你居然就選了那種
62
00:03:35,100 --> 00:03:36,500
這一定有什麼原因
63
00:03:36,500 --> 00:03:38,700
所以選字型要謹慎啊！
64
00:03:38,700 --> 00:03:40,700
舉例來說，如果你選擇中黑體
65
00:03:40,700 --> 00:03:42,500
這是我最愛的字體
66
00:03:42,500 --> 00:03:44,700
你可能是個組織邏輯較強的人
67
00:03:44,700 --> 00:03:46,900
如果你選細圓體，可能是俐落簡潔的人
68
00:03:46,900 --> 00:03:48,700
如果選新細明體
69
00:03:48,700 --> 00:03:50,700
如果選新細明體
那表示你是個懶鬼，永遠只用預設值
說實在我並未獲得翻譯授權，所以很低調 =.= 結果看來是有需求的，這樣我有點麻煩... 還是寫個信去問一下好了 orz
UPDATE: 感謝 nign 的提醒，這個字幕的原文出處來自 Life after the death by PowerPoint
因應下個月北京謀智網路（Mozilla China Office）的宮力博士在 ICOS 的演講「Mozilla、開放源碼與網路未來」，我把以前翻譯的 Mozilla 宣言原則拿出來又大修了下。本文參考了宮博士提供的簡體中文譯稿，不過比較多還是我自己的意思，所以盈虧自負、責任自理了 ;) 還請提供建議，也歡迎大夥參加下個月初的 ICOS 及 COSCUP 喔！
同時，要幫我 Debug 的也歡迎下載中英對照版 PDF。（感謝 nign 提供建議，文章都還沒貼出就修改了一些重要部份 XD）
網際網路在我們生命中的重要性日漸增加。
Mozilla 專案為全球性社群，成員們信奉開放、創新及機會是網際網路健全發展的關鍵因素。我們自 1998 年起為確保網際網路的發展裨益全民而生，以創作 Mozilla Firefox 網頁瀏覽器聞名。
Mozilla 專案以社群力量建立世界一流的開放源碼軟體，並開創各種新式的合作活動；成員們志同道合，為了提昇全民的網路體驗而努力。
我們依據過往的努力整理出一系列理念的原則，涵蓋我們認為能同時對全民及商業活動有益的網際網路發展重要方針，在以下的 Mozilla 宣言中將闡述這些理念。
有了理念，還待人來實踐；需要以個人努力、團體合作並發揮領導作用，來維持網際網路的開放參與。Mozilla 基金會承諾推行 Mozilla 宣言裡的理念，也邀請更多夥伴加入我們的行列、致力令網際網路變得更好。
網際網路是現代生活的一部份，是教育、溝通、合作、商業、娛樂和整個社會的關鍵組成要素之一。
網際網路是全球公用資源，應該保持開放並易於取用。
網際網路應能豐富每個個體的生活。
使用者的網路安全應為基本要求，不能妥協。
使用者應能依其個人意願決定網際網路的使用方式。
網際網路作為公共資源，其效用倚賴透通性（包括協定、資料格式、內容方面）、創新及全球使用者的自主參與。
自由軟體及開放源碼軟體能促使網際網路作為公用資源持續發展。
透明化的社群式流程則能促進參與、責任及信任。
商業力量在網際網路發展中能帶來很多益處，維持商業目標與公眾利益的平衡相當重要。
擴大全民在網際網路方面的利益是重要目標，值得賦予時間、精力及承諾。
宣揚 Mozilla 宣言的途徑很多，我們歡迎各式各樣的活動，並希望參與者展現像在 Mozilla 專案其他部份那樣的創造力。對於尚未參與深入 Mozilla 專案的朋友，支持此宣言最簡單的方法便是使用 Mozilla Firefox 及其他具體展現此宣言理念的產品。
Mozilla 基金會誓以行動支持 Mozilla 宣言。具體來說，我們將：
建立、協助認同此宣言理念的開放源碼軟體及社群；
開發、提供符合此宣言理念的優良消費性產品；
以 Mozilla 相關智財（如版權及商標）、組織、資金及聲譽方面的資產，讓網際網路平台保持開放；
倡導為公眾利益創造經濟價值的模式，並
於公開場合及網際網路產業間宣揚 Mozilla 宣言。
基金會的部份活動（目前為建立、提供並推廣消費性產品）將主要由基金會附屬的 Mozilla 公司執行。
Mozilla 基金會邀請支持此宣言理念的眾人，一同探索實踐這份網際網路願景的新方法。
很快講一下我的構想
我一直想把 Mozilla Links 中文版的 RSS 併進 moztw.org 首頁一角（事實上，去年 Firefox Party 的網頁裡我就偷偷這麼做了），不過它的更新頻率不比主站，多的時候一個月甚至有十九篇的紀錄、少的話兩個月才一篇的情形也發生過，這樣不合格啦 T_T
那就多點人翻譯就好啦？不過即使是 Mozilla Links，咱們依然維持鬆散無組織、無敵不理效率的狀態，事實上目前 mozilla links 中文版的翻譯成員已有六人之多，成果... 嗯，你看了也知道。說實在這並不能怪誰，因為這很合理... 我們都有自己的事情要忙，而且熱情是會燃燒完的啊！我自己就常是個三分鐘熱度的人，我很清楚也能理解。
所以從上回的 Firefox 2 要點概覽起，我就嘗試著用游擊隊的方式翻譯：臨時號召、馬上處理、立即解決。只要大家交稿的速度快，我在 review 時也比較有動力，所以還可以維持一定的翻譯水準（ㄜ，我承認這水準也不見得高就是了）。
這幾回的 Mozilla Links 我已經用類似的方法請人翻譯，效果也還不錯，所以我想或許可以趁這個機會請願意幫忙的人報上名來等候任務。
完全不多，長的篇幅拆成四個人分之後每人不過就是一個問題、短的篇幅就算是全翻其實也不多。專有名詞？你能查就查，不過基本上原文都會附參考連結，照著附上來就對了 XD。
翻譯的過程全部用即時通訊軟體處理，我覺得值得翻的文章就會找人丟段落請您幫忙，您可以選擇接受或拒絕。文章最後會總結有幫忙的夥伴，另外也會附上您的 blog 網址禮尚往來。所以如果你有 MSN 或者 GTalk，請找我喊聲旺旺我可以幫忙吧！（MSN: bobchao1981在hotmail點com、GTalk 就是 bobchao在gmail點com 囉）
當然你還有其他方法貢獻：
有問題？這有可能是兩種意思
無論是哪種，MSN 上談或是留言吧！