（圖片取自 unconed 網站，版權為原網站所有。）

瞭解電腦字型如何被創造，能夠進一步理解文字如何在螢幕上顯示。本系列文章目的在於研究電腦字型在螢幕上顯示的原理，以便理解 CSS 有關字型的各項屬性背後的設計目的，以及要解決的問題。本文適合對象為從事網頁設計的專業人員，不論是網頁設計師、前端工程師，或是全端工程師。

Pixel

現代螢幕最小的基本單位為像素（pixel），由非常非常多的「小燈泡」組成。一個像素是由紅、綠、藍三個顏色的「小燈泡」組成，他們透過控制開關、亮度，組成不同變化的加法混色，能夠產生非常多種顏色。為了簡化概念，可以將像素理解成一個個小格子，整齊排列構成一個巨大的矩形網格。電腦在繪圖時，是按照網格座標逐一設定每個格子（cell）顏色屬性的 RGB 值來呈現圖案。有個說法，像素的英文 pixel 的是 picture + cell 組成的詞彙。

Full HD 的螢幕解析度是 1920x1080，表示螢幕橫向 X 軸有 1920 個像素單位，縱向 Y 軸有 1080 個像素單位，總共超過 200 萬個像素單位，這種螢幕實際所擁有的像素數量通常稱為裝置像素（device pixel）。

有些藝術家、工程師用人工的方式在網格上一格一格地點上顏色來製作圖案，這種圖案風格稱為 pixel art。使用像素方格將文字筆劃一點一點點出來的字型，稱為點陣字型（bitmap font）。以前螢幕解析度不高，要在有限的像素內顯示可判斷的文字筆畫，需要使用點陣字型。現在使用最多的場合是大眾運輸上的跑馬燈，或是某些車票、收據仍可以看到點陣字型的使用。

若要滿足動輒超過一、兩百萬像素的現代螢幕，便不可能一點一點地點出文字的筆劃，需要用數學方程式來表達向量的線條、幾何圖形，例如 Bresenham 演算法繪製線條、Bézier 曲線算法繪製曲線、Scanline 填充算法填滿實心的圖形。

透過記錄文字線條變化的節點座標（x,y）來繪製筆劃輪廓的字型，叫做輪廓字型（outline font）。輪廓字型使用許多直線與曲線組成文字筆劃的輪廓形狀，再以填充演算法填滿內部空間，繪製成文字，這個過程稱為算圖（render）。

目前算圖並沒有一個統一的規範標準，各個引擎的實作方式皆有些微差異，因此在不同的瀏覽器（Chrome、Firefox）、作業系統（macOS、Windows）上相同一套字型的同一個字母，都會看起來不太一樣。

不過螢幕像是個巨大的矩形網格，無法直接顯示向量的圖形，顯示過程需要經過點陣化（rasterization），由電腦程式自動設定每個格子的顏色屬性，將向量線條轉映到一格一格的像素上。

px 不是 Pixel

裝置像素的單位以 px 表示，但是 CSS 所定義的 px 並不與裝置像素 1:1 直接對應，至少不是想像中那麼單純的 1px 等於 1 個裝置像素單位，儘管他們都會使用相同的表示方式：1px、320px、1920px。可是兩者定義上卻有些微差異。

須知 CSS 支援的長度單位相當多，有字型排版歷史流傳下來的 pt 以及 pc（pica），也可以使用日常生活可能每天用到的公分（cm）、英吋（in），還有個最特別的單位是 px。對於已經熟悉 CSS 的工程師、設計師大概沒人不知道什麼是 px。px 不像其他單位有實際的物理長度可以相互轉換：

1in = 2.54cm = 25.4mm = 72pt = 6pc

因為他們是由實際的物理長度組成的絕對單位，物理長度不論在哪都是相同的，基本上每個人伸兩根手指大概都可以比出一公分大概有多長，但是螢幕因為解析度不同，每英吋像素密度（pixels per inch，PPI）都不一樣，例如 iPhone 5s 的像素密度是 iPhone 3G 的兩倍，兩者裝置像素 1px 不會是相同的物理長度。

W3 早在 CSS Level 1 就提出了參考像素（reference pixel）的概念，定義了 CSS 的 px 單位是參考像素而不是裝置像素。參考像素 1px 等於 1/96 英吋（大約 0.26mm）。與其他絕對單位的轉換公式可以寫成：

1in = 96px = 72pt = 25.4mm

當設定字級 12pt，電腦需要將 pt 單位轉換為參考像素 px，才能知道螢幕需要用多少像素來顯示文字。依照前述的公式做簡單的單位換算：

12 / 72 * 96 = 16

計算結果是 12pt 的文字在網頁上顯示的合理邊長為 16px；當 CSS font-size 設定 16px 即表示設定 EM square 邊長的對應像素為 16px，換句話說，font-size 的大小等於 EM square 的大小。然而這只是字型的 EM square 的高度，並非字形本身的高度，要計算字形本身輪廓的像素寬高則需要從 EM square 的座標系統換算。

字形座標轉換 Pixel

技術上 EM square 是個二維空間的座標系統，FUnit 是等分座標系統的單位，沒有實際的物理長度，只用來表示相對的距離。為了能在螢幕上顯示字型文字，需要將相對的輪廓座標（x,y）等比例縮放到具體的像素座標上。

輪廓字型以 Roboto Black 為例，這個字型 EM square 邊長為 2048 FUnit，大寫 I 用了四個座標點，座標點之間皆為直線線條連接：

x=474 y=0
x=137 y=0
x=137 y=1456
x=474 y=1456

網頁上如果設定 12pt 已經知道合理邊長為 16px，做個簡單的等比例縮放計算：

(round(x/2048*16), round(y/2048*16))

最後的像素座標分別為：

(3.7, 0)
(1.07, 0)
(1.07, 11.38)
(3.7, 11.38)

由此得知這個字形最後在螢幕像素上會是個寬高 2.63x11.38 的矩形。也可另外使用以下公式計算字形會用到的像素寬度跟高度：

X/Y軸使用的FUnit * ((字級大小pt * PPI / 72 * 字型UPM尺寸))

試算結果：

337 * ((12 * 96) / (72 * 2048)) = 2.63
1456 * ((12 * 96) / (72 * 2048)) = 11.38

因此可以計算出 Roboto Black 的大寫 I 寬度使用 2.63 個像素，以及高度使用了 11.38 個像素。不過像素是螢幕上的最小單位，基本上是一個一個的整數，無法只顯示半個像素，為了實現這個目的，需要用到反鋸齒與子像素的技術。

（圖片取自「Digitizing Letterform Designs」，版權為原網站所有。）

瞭解電腦字型如何被創造，能夠進一步理解文字如何在螢幕上顯示。本系列文章目的在於研究電腦字型在螢幕上顯示的原理，以便理解 CSS 有關字型的各項屬性背後的設計目的，以及要解決的問題。本文適合對象為從事網頁設計的專業人員，不論是網頁設計師、前端工程師，或是全端工程師。

EM square

傳統金屬活版印刷把每個字母刻在一個金屬方塊上，方塊不一定是正方形，寬度可能不同但是高度相同，這樣才能整齊地排列字母。由於英文中「M」這個字母比例接近正方形幾乎是最大的一個，因此金屬塊的寬度被稱為「em（M）」。

在數位時代一個字母的空間容器從實體金屬塊轉移到虛擬的電腦程式上，電腦程式會建構一個虛構的空間容器被稱為 EM square、EM size 或 UPM（Unit per EM），術語源自活版印刷技術的歷史，而數位字型也將以此作為容器基礎。

字體（typeface）指的是文字的外觀風格，常見的字體例如標楷體、新細明體、微軟正黑體、蘋方體、Times New Roman、Helvetica 等，基於相似概念組成的集合便稱為字體家族（font family），也是 CSS 的 font-family 所設定的名稱。

字形（glyph）指的是字元的形狀，由程式演算法或是文字工程師、設計師手動調整的形狀本身。一個字型的所有字形都有相同的 EM square 尺寸，差別在於字形的大小不同。

在技術上 EM square 可以看作是個有限的二維空間座標系統（x,y），寬高可能是 2048x2048（單位 FUnit），OpenType 官方規格建議大小是 16 到 16384 之間，但如果主流軟體無法支援便失去了意義，例如 InDesign、Illustrator 特定版本無法正確處理 EM square 超過 5000 的字型，所以 EM square 的尺寸需要取決於軟體的相容性。目前比較常見的尺寸通常是 1000 或是 2048，例如 Apple 主要字型都是以 2048 FUnit 去設計的。

字形基本上都會設計在 EM square 的範圍內，但也能超出這個範圍，視字型製造商的偏好及決定。

當指定 CSS font-size 16px 瀏覽器便會將字型 EM square 的大小映射到螢幕 16px 的大小上，可以參考我的另一篇文章「CSS Font (2) - 像素」。

字形解構

觀察英文字母的書法規則，可以歸納出一些模式，例如每個字母基本上都坐落在同一條水平線上，這條水平線稱為基準線（baseline），相對於其他字型或字形決定如何對齊，不過這是針對英文（正確來說是拉丁文）字型設計，中文字型由於都是方形等寬等高的，因此不需要基準線的設計。

此外，基線到字形最高的頂部稱為升部（Ascent）；基線到字形最底的底部稱為降部（Descent）。在數位字型中，這項規格制定在 OpenType、TrueType 的 OS/2 表格中 sTypoAscender 及 sTypoDescender 的值，或是 HHEA 表格中的 Ascent 及 Descent。OS/2 是給 Windows 的規格、HHEA 則是 Apple 的規格。

行高

印刷排版中的行高英文是 leading，指的是兩行文字中間的距離或空白，但是 CSS 的行高（line height）略有不同的定義，因為它不是只是單純地加在行與行的中間，而是先計算出 leading：

leading = line-height - (ascent + descent)

然後 CSS 將其中一半的 leading 加到文字的上方，一半加到下方。舉例來說，指定某區塊字級大小 16px，行高設定 24px，則 (24 - 16) = 4，CSS 會在 16px 的文字上面及下面同時加上 4px 的空白，最後整體文字區塊（inline box）才會得到 24px 的高度。

W3 規定 CSS line-height 預設的值是 normal，並且建議這個值可以介於 1.0 ~ 1.2 之間。為了測試實際 line-height 到底是多少，我準備了一個測試網頁，在 Chrome 跟 Firefox 兩種不同的 render engine 測試不同英文字跟中文字體，得到以下 4 個測試結果：

• 不同瀏覽器 normal 不同；
• 同個瀏覽器 font-size 不同 normal 實際值也不同；
• 同個瀏覽器 font-size 相同 font-family 不同 normal 實際值也不同；
• 雖然 W3 建議 normal 應該介於 1.0 ~ 1.2 但實際上隨著 font-size 與 font-family 變化，可能會大於 1.2；

不同瀏覽器預設 line-height 不同，要解決這個問題也容易，只要在 <html>、<body> 指定固定的值即可，例如 normalize.css 指定了 line-height 為 1.15，reset.css 設定 line-height 為 1。

行動裝置時代瓶頸：

• 手機頻寬小；
• 手機速度慢；

但是人們希望：

• 速度快；
• 速度要快；
• 速度更快；

快有什麼好處？遠古的網路傳說：

• Amazon 網頁平均載入時間多 1 秒，公司年度營收少 16 億美元；
• Google 網頁平均載入時間多 0.4 秒，每天搜尋次數減少 800 萬；
• 使用者開啟網頁 4 秒內沒有出現任何內容便會放棄；

所以 Facebook 推出「即時文章」，讓文章內容可以在毫秒之間顯示。

技術

即時文章原理：

• 簡單說，他們預先把內容載入到 FB app 裡，讓使用者可以「不離開 FB app」直接讀取內容，省去網路訊號來往半個地球的時間；
• 僅支援 iOS and Android，需要 iPhone iOS 7.0+ & FB app 30.0+，以及 Android Jelly Bean+ & FB app 57+。

我想要我的網站內容可以有即時文章，有什麼條件？

• 得要先有個網站；
• 遵守 FB 文章政策；
• 遵守 FB 設計規範；
• 網站內容頁面程式結構要為「即時文章」做準備；
• 提交申請，至少準備 10 篇文章做「文章審查」。

「即時文章」要怎麼做？有以下幾種方式：

• RSS：網站要另外製作 RSS feed 的端口方便給 FB 抓資料，文件參考「透過 RSS 摘要發佈」。
• API：網站內容頁面的結構需要特別設計過，符合 HTML5 語義話結構；然後網站的內容在 CRUD（建立、讀取、更新、刪除）每個動作，都要與 FB 的程式溝通一次。文件參考「即時文章 API」。
• 另外還有 SDK 跟 WordPress 套件，前者要用 PHP 不討論，後者要用 WordPress 架站。

實作了以上功能之後，要先提交 10 篇文章給 FB 進行「文章審查」，在那之前無法發佈即時文章。

一旦完成設定以及審查過程後，FB app 上有 Instant Articles 的內容會出現一個閃點符號，點了幾乎可以毫秒級出現內容。

商業

內容都跑到 FB 上去顯示了，我的網站流量豈不是沒了？

• 對，因為讀者「不離開 FB app」；
• 可以用 comScore、Google Analytics、Omniture 或 Facebook 自己的工具追蹤「即時文章」的流量；
• 因為網站本身流量減少，所以原本網站上的廣告收益減少；
• 但是可以在即時文章放廣告，詳細見「即時文章的獲利方式」。

我的內容在 FB app 上出現得好快好爽，都沒有副作用？FB 轉型做慈善事業？

簡單說，這是 FB 繼吃掉通訊平台、電商平台、支付平台的夢之後，另一個吃掉出版平台的夢。

首先，FB 為內容產出者提供非常好的平台，為許多媒體帶來非常大的流量、讀者和廣告收益等，但這有點像嗑藥，FB 是個一但染上很難戒除的癮，因為：

• 開始需要繳交「演算法維護費」跟「保護費」來維持流量；
• Facebook 網站如果掛了就無法導流；
• Facebook 有自己的一套「內容審查」決定權在他們，例如粉絲團被關閉的案例；

尤其當「即時文章」是要媒體把內容「直接顯示在 FB 上」，讀者連媒體自家網站都不用過去了，對於媒體來說，對自家網站的控制權變得更弱了。

所以，話說回來，我的網站適合「即時文章」嗎？ 以下是個思路：

• 問問為什麼當初選擇花錢自架網站？為什麼不去用免費的 BSP？
• 如果答案是說自己架網站可以對網站樣式、內容有更多的客製化跟掌控權……
• ……
• ……
• ……
• ……
• 那用「即時文章」等於放棄以上這些，那怎麼不去用 BSP？

報告完畢！👾

三年前曾經寫過「劣以為的 OOCSS 和 SMACSS 以及其他 CSS 規範」探討 OOCSS 模組化的方法論，時至今日對於模組化設計又有新的認識跟理解，大原則跟三年前的方法沒有出入，只是多做解釋跟補充。

OOCSS 物件導向是解釋設計原則，但是不限於語法的設計。

如果這個議題有興趣，歡迎繼續往下閱讀，如果有任何想法也歡迎留言與我討論！

這篇文章會解釋的內容，包括四個設計原則：

• 單一責任原則
• 極少化原則
• 介面設計原則
• 開放封閉原則

SCSS 模組化設計模式：

• 元件模式
• 語義化模式

單一責任原則

一個 class 只負責一件事情。這個原則不是指 universal.css 這種設計方式，事實上這個專案是個反諷。單一責任原則是指職責獨立、目的明確的 class。

1
2
3
4
5
6
7
8
9

.clearfix:before,
.clearfix:after {
  display: table;
  content: "";
}

.clearfix:after {
  clear: both;
}

極少化原則

對於層級的依賴應該盡可能減少。

多半的人剛開始寫 SCSS 都為它的巢狀語法感到著迷：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

.page {
  .content {
    .header {
      .inner {
        .group-list {
          .group-item {
            a {
              ...
            }
          }
        }
      }
    }
  }
}

這個寫法有改善的空間，因為：

• 不容易閱讀：當層級非常多的時候，哪段屬性屬於哪層 class 會看不清楚。
• 太倚賴 DOM 結構：一旦改變 DOM 層級結構，SCSS 也可能會需要做層級調整，層級越多耦合性越高，意味維護成本越高。

改善的方式便是在相同的命名空間下，試著將層級攤平。適當使用巢狀語法的範例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

.nav {
  list-style-type: none;
  margin: 0;

  li {
    display: inline-block;
  }

  a {
    display: block;
    text-decoration: none;
    color: blue;
  }
}

即便 <a> 的 DOM 結構是屬於 <li> 的子元素，仍然不影響它們的作用：

1
2
3
4
5

<ul class="nav">
  <li><a href="...">...</a></li>
  <li><a href="...">...</a></li>
  <li><a href="...">...</a></li>
</ul>

有時候與 DOM 元素本身有絕對關聯的 class，可以在使用區塊註解加以說明：

1
2
3

/* ul */.nav {
  ...
}

介面設計原則

針對介面設計，而不是針對實踐方式設計。這個原則可以減少重複的程式碼，增加可維護性。

例如兩個有著相似樣式的區塊，往往會針對區塊實踐它們各別的樣式：

1
2
3
4
5
6
7
8
9

.card-default {
  border: 1px solid hsla(0, 0%, 33%, 0.85);
  padding: 15px;
}

.card-primary {
  border: 1px solid hsla(0, 0%, 66%, 1);
  padding: 20px;
}

1
2
3
4
5
6
7

<div class="card-default">
  ...
</div>

<div class="card-primary">
  ...
</div>

應該先設計這個模組的介面（interface），再依照介面實踐它不同的樣式特性：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 先設計介面
.card {
  border: 1px solid transparent;
  padding: 10px;
}

// 再實踐不同的介面樣式
.card-default {
  border-color: hsla(0, 0%, 33%, 0.85);
  padding: 15px;
}

.card-primary {
  border-color: hsla(0, 0%, 66%, 1);
  padding: 20px;
}

1
2
3
4
5
6
7

<div class="card card-default">
  ...
</div>

<div class="card card-primary">
  ...
</div>

一旦先有了介面，後續也才能夠知道該怎麼對此模組進行擴充。

開放封閉原則

對修改封閉、對擴充開放。除非是根本性上地調整模組的樣式，才會需要去改動到介面層級的樣式。這裡引用上一則原則的範例：

1
2
3
4
5
6
7
8
9

.card {
  border: 1px solid transparent;
  padding: 10px;
}

.card-default {
  border-color: hsla(0, 0%, 33%, 0.85);
  padding: 15px;
}

1
2
3

<div class="card card-default">
  ...
</div>

當某個頁面需要對此介面做特殊調整，可以使用開放封閉原則，對此介面進行擴充，而不會影響到其他頁面樣式：

1
2
3

.card-users {
  border-color: hsla(0, 0%, 100%, 1);
}

1
2
3

<div class="card card-default card-users">
  ...
</div>

元件模式

元件模式的哲學在於 class 本身與語義化無關，應該關注它們是否合理，不要刻意強調 class 名稱要符合語義，而要注重使用的合理性與未來性。例如：子元素區塊使用 .list-item 上層元素使用 .list-group 作為子元素的集合，這與元素本身是否是個序列清單（<ol> ）無關。

在前面瞭解過四大設計原則之後，現在已經可以很輕易地設計出模組。先設計介面（interface），再實踐不同的模組樣式：

1
2
3
4
5
6
7
8
9
10
11

.card {
  background-color: transparent;
}

.card-default {
  background-color: white;
}

.card-primary {
  background-color: red;
}

在 HTML 上的使用方式：

1
2

<div class="card card-default">...</div>
<div class="card card-primary">...</div>

元件模式好處在於開發前端版型，只需要專注在刻寫 HTML 上，快速調用各種模組 class 名稱、減少花時間替 class 命名的 context switch 成本。缺點亦即很容易過度膨脹 HTML 體積，例如使用熱門框架 Bootstrap 的人們應該對此都不陌生：

1
2
3

<div class="col-lg-9 col-md-9 col-sm-9 col-xs-12 col-lg-offset-3 col-md-offset-3 col-sm-offset-3">
  ...
</div>

語義化模式

語義化強調元素本身所代表的意義，但並非漫無目的地設計 class；結合四種模組設計原則，加上 SCSS 語法的便利性，可以很容易地設計出容易維護及擴充的模組：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

card {
  @at-root {
    %#{&} {
      background-color: transparent;
    }

    %#{&}-default {
     background-color: white;
    }

    %#{&}-primary {
      background-color: red;
    }
  }
}

.content {
  @extend %card;
  @extend %card-default;
}

.sidebar {
  @extend %card;
  @extend %card-primary;
}

這會產生出以下的結果：

1
2
3
4
5
6
7
8
9
10
11
12

.content,
.sidebar {
  background-color: transparent;
}

.content {
  background-color: white;
}

.sidebar {
  background-color: red;
}

因此可以清晰、明確地定義出區塊所代表的意義：

1
2

<div class="sidebar">...</div>
<div class="content">...</div>

語義化模式的優點在於減少 HTML 冗長的 class 名稱串聯，透過 SCSS 語法優勢，對不同的區塊套入相同的模組樣式。缺點在於切出每個區塊時沒有那麼容易替其命名，增加了中間「做決定」的思考成本。

兩個模式並非相互衝突，可以在適當的時機交互結合應用。

語法

首先當然是要喜歡上該樣版引擎的語法，因為使用樣版引擎的主要目的就是為了加速撰寫 HTML 的生產力，給先讓自己喜歡使用它，才有辦法寫得有效率。多數樣版引擎的入口頁會用簡單的範例，快速火力展示它的特點，這是很好的開始。但也因為這是精心設計的著陸頁，目的是攻取心裡的小惡魔，所以在選擇採用這套樣版引擎前也得特別小心。

擴充性

一個好的樣版引擎可以讓自己掌控專案的伸縮性，例如註冊新的 helper 跟 block，節省撰寫重複的程式碼，靈活地設計版型架構。

安全性

對於經驗不足的開發者來說這很容易鑄成大錯，在沒有意識下的輸出未消毒的內容，都可能會造成使用者傷害，而一個好的樣版引擎應該要預設消毒輸出。如果對自己的經驗很有信心，覺得這是初學者才會犯的錯誤，但也不能夠保證其他同事們不會粗心大意。

勿矯枉過正

使用樣版引擎是為了增加團隊在撰寫 HTML 的效率，所以應該以團隊的技術水平作為優先考量，如果團隊的平均技術水平沒有達到而貿然採用也只是增加大家困擾而已。 不要為了使用而使用。

Zepto 是個跟 jQuery API 相容的套件，但是非常輕巧。

jQuery 1.11.2 不壓縮 278KB，壓縮後是 94.8KB。儘管 jQuery 2.0 比 jQuery 1.11 減少了 12% 的體積大小，仍然是個 200KB 級的套件。而 Zepto 不壓縮 56KB，壓縮後大約是 24.5KB，比 jQuery 平均小了 74%！

Zepto 極其輕巧的秘訣在於它預設只有 jQuery 最關鍵的幾個核心功能，並且用友善的模組化設計，保持每個功能能夠輕易地被擴充。

擴充 animate 模組

jQuery 的 animate 效能不是很好，上次在製作公司官網作品牆，讓圖片載完進行 fadeIn 的效果，造成 FPS 低到明顯感受到 lag。

通常需要用到大量的動態視覺效果的首選是 GreenSock 所提供的 TweenMax（344KB）。如果只是需要用來取代 jQuery 的 animate 操作 DOM 的動態效果，那麼能夠跟 jQuery 無縫整合的 Velocity（215KB）有更好的條件。Velocity 優點是效能高，體積比較小，也能夠相容 jQuery API。

Zepto 因為模組化設計的關係，預設是不包括 animate 這個方法的，因此便可以改用 Velocity 來擴充。

外部網站參考：

• Zepto 的專案網站
• Velocity 的專案網站
• TweenMax 的專案網站

瀏覽器相容性

jQuery 2.0 開始就直接放棄 IE 9 以下的瀏覽器，Zepto 更狠直接跳到 IE 10+；而 Velocity 則是不支援 IE 8 以下，所以能不能使用 Zepto + Velocity 這個組合要先觀察一下產品的目標使用群。

如果打算支援 IE 8，還是去用 jQuery 1.11.3 吧！

點擊連結傳送簡訊

1
2
3
4
5
6

<a href="tel:0912345678">打給我！</a>

<!-- Android -->
<a href="sms:0912345678?body=你到哪了？">傳簡訊給我！</a>
<!-- iOS -->
<a href="sms:0912345678&amp;body=你到哪了？">傳簡訊給我！</a>

延伸資料：

• How to pre-populate the sms body text via an html link - StackOverflow

地理定位 API

1
2
3
4
5
6

if (navigator.geolocation) {
  navigator.geolocation.getCurrentPosition(function (position) {
    var whereareyou = position.coords.latitude + ' ,' + position.coords.longitude
    alert(whereareyou)
  })
}

裝置方向與裝置體感 API

這兩個功能是建立在裝置的陀螺儀和指南針感測器上，它能夠傳回目前裝置的旋轉角度，以及三個維度。

1
2
3
4
5
6
7
8
9

if (window.DeviceOrientationEvent) {
  window.addEventListener('deviceorientation', function(event) {
    // gamma 是左到右傾斜的角度
    // beta  是前到後傾斜的角度
    // alpha 是裝置面向在指南針方位上的角度
    document.body.innerHTML = event.gamma + ' ,' + event.beta + ' ,' + event.alpha

  }, false)
}

有了裝置體感的 API，也可以做出搖一搖復原輸入的功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

if (window.DeviceMotionEvent) {
  window.addEventListener('devicemotion', function(evnet) {

    document.body.innerHTML = evnet.acceleration.x + '<br/>' + evnet.acceleration.y + '<br/>' + evnet.acceleration.z

    // 加速感測
    console.log(evnet.acceleration.x)
    console.log(evnet.acceleration.y)
    console.log(evnet.acceleration.z)

    // 加速感測包括重力參數
    console.log(evnet.accelerationIncludingGravity.x)
    console.log(evnet.accelerationIncludingGravity.y)
    console.log(evnet.accelerationIncludingGravity.z)

    // 旋轉率
    console.log(evnet.rotationRate.alpha)
    console.log(evnet.rotationRate.beta)
    console.log(evnet.rotationRate.gamma)
  }, false)
}

延伸資料：

• 裝置動作 - Web Fundamentals
• 裝置定向 - Web Fundamentals

震動馬達

目前只支援 Android 的 Chrome 以及 Opera、Firefox，iOS 尚不支援。

1
2
3
4
5

var btn = document.getElementById('btn')
var vibrate = navigator.vibrate || navigator.mozVibrate || navigator.webkitVibrate
btn.addEventListener('click', function (event) {
  vibrate(1000)
})

延伸資料：

• Navigator.vibrate() - MDN

剩餘電力管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var battery = navigator.battery || navigator.webkitBattery || navigator.mozBattery

function log(_battery) {
  document.body.innerHTML = '目前電力剩下：' + (_battery.level * 100) + '%'
  _battery.addEventListener('chargingchange', function() {
    alert('開始充電！')
  }, false)
}

if (navigator.getBattery) {
  navigator.getBattery().then(log)
} else if (battery) {
  log(battery)
}

亮度感測器

目前只有 Firefox 支援這個 API。

1
2
3
4
5
6

if ('ondevicelight' in window) {
  window.addEventListener("devicelight", function (event) {
  // 回傳的是亮度單位 lux
  console.log(event.value + " lux")
  })
}

近距離感測 API

這個也是只有 Firefox 支援。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

if('ondeviceproximity' in window) {
  // Fired when object is in the detection zone
  window.addEventListener('deviceproximity', function (event) {
      // Object distance in centimeters
      console.log(event.value + " centimeters")
    })
} else {
  console.log("deviceproximity not supported")
}

if('ondeviceproximity' in window){
  // Fired when object is in the detection zone
  window.addEventListener('userproximity', function (event) {
    if(event.near == true) {
      console.log("Object is near")
    } else {
      console.log("Object is far")
    }
  })
} else {
  console.log("userproximity not supported")
}

參考：

• 9 JavaScript APIs accessing Device Hardware

Page 1

node.js v0.12.0 TTFB 1.36s。

io.js v1.1.0 TTFB 1.21s。

node.js v0.10.36 TTFB 603ms。

Page 2

node.js v0.12.0 TTFB 910ms。

io.js v1.1.0 TTFB 776ms。

node.js v0.10.36 TTFB 604ms。

Page 3

node.js v0.12.0 TTFB 221ms。

io.js v1.1.0 TTFB 217ms。

node.js v0.10.36 TTFB 150ms。

結論

每個頁面我都土法重複 reload 過好幾次，大概抓的數字是看到的平均值，想說這樣的測試太土法了，沒參考性，但是三個頁面的測試結果彼此比較後都很相像，所以應該可以說明什麼了吧！

• node.js v0.12.0 TTFB 1.36s +0%
• io.js v1.1.0 TTFB 1.21s +12%
• node.js v0.10.36 TTFB 603ms +126%

頁面一舊版 node.js v0.10.36 比其他兩頁都快得多！跟 io.js v1.1.0 比起來也快了至少 100%。

• node.js v0.12.0 TTFB 910ms +0%
• io.js v1.1.0 TTFB 776ms +17%
• node.js v0.10.36 TTFB 604ms +51%

頁面二也是 node.js v0.10.36 最快。

• node.js v0.12.0 TTFB 221ms +0%
• io.js v1.1.0 TTFB 217ms +1.8%
• node.js v0.10.36 TTFB 150ms +47%

頁面三其實都相差不遠，但 node.js v0.10.36 仍然反應最快。

結論就是……等網站上到遠端 server 之後再來測一次真實網路環境下的 TTFB 吧！以目前在本機測試的結果，還沒有很想更新到 node.js v0.12.0，而且以現在這局勢看來 io.js 勢頭很高，再過一段時間來評估直接把專案跳去改用 io.js 算了。:p

這個事件已經燒了好幾天，剛開始注意到是 Hacker News 上出現「IO.js – Evented I/O for V8 javascript」這篇推文，我甚至還不曉得到底該寫 IO.js 還是 io.js 比較正確。

整件事情發展詭譎得像 Prometheus 的 Elisabeth Shaw 剛發現黑色黏液一樣，不知道到底是希望還是崩壞的開始。最近公司有要用 Node.js 所以我就追了一下新聞，大概統整出來的概況寫了這篇觀察紀錄，或許有些可能有錯麻煩在幫我指正，感謝喔！

故事的序章

希臘傳說中的巨人族自殺喝下奇怪的黑色黏液來開創人類世界，Node.js 的創建者 ry（Ryan Dahl） 確實也有點像上帝創世後神龍見首不見尾地消失無蹤，怎麼有種 _why 風格的感覺……都回到真實世界去了嗎（The Matrix 梗）？

在 ry 消失之前他把 Node.js 版權賣給了 Joyent 還替他們工作了一陣子，但稍微有點信仰的 developer 都不會喜歡參與的 Open Source 專案跟商業公司扯上關係，這次 io.js 事件主導人之一的 mikeal（Mikeal Rogers）就寫了一篇「On Corporate Ownership of Open Source」說出他的想法。

Node.js 有另外兩個非常重要的 core commiter 分別是 piscisaureus（Bert Belder）和 bnoordhuis（Ben Noordhuis），他們成立的公司 StrongLoop 想要搶奪 Node.js 社群統治權的野心非常強，是 Joyent 最大的兢爭對手，但無奈商標權就是 Joyent 的，StrongLoop 也不能拿他們怎麼辦。

StrongLoop 你就直說吧！你就是想要取代 Joyent 來主導 Node.js 的發展！XD

分裂的跡象

Open Source 這回事嘛……就是授權範圍允許，當然可以 fork 一份出去改成自己想要的版本，只是看整個社群願不願意支持而已。我不是很了解 Node.js 核心的開發上，Joyent 是用什麼樣的風格來管理，但顯然有很多 core commiter 不太滿意，從很久之前就出現了分裂的聲音。

Joyent 做為 Node.js 所有者、掌門人也聞到了這個味道，當然不會坐視這種情況不管，因此成立了所謂的 Advisory Board，目的就是在於廣納所有 Node.js developer 的意見跟想法。

呃，傾聽人民的聲音？但似乎此舉在某些人眼裡看起來就是獨裁者的作秀，實質上沒什麼幫助，所以熱血革命鬥士開始組織 Node Forward 來討論該怎麼「推翻」政府，最後有了今日的 io.js。

說說看在這之間難道 StrongLoop 的人難道不會煽風點火嗎？:p

Update 2015.01.14：今天 io.js 發佈 1.0.0 版本把整個 Twitter 洗版洗得一塌糊塗，然後我也看到另外一個軼聞，就是 Ben Noordhuis 被當初被 Joyent「驅逐」的原因竟然是因為性別歧視用字的問題，也可以在這裏找到他本人的說法。另一層考量就是 Ben 為 Joyent 競爭對手工作，很難不讓人聯想這是一起政治事件。

io.js 是什麼？

io.js 目前在 Github 上的專案位置：https://github.com/iojs/io.js

它的前身是 node-forward/node，也就是 Node Forward 用來抵抗 Joyent 的專案，另一個 Node.js fork 版本，在正式 public release 前醞釀了大概 4 個禮拜左右。

io.js 目的是希望可以讓 Node.js 更加擁抱社群、更自由、更公開、更透明……之類的，而不是被 Joyent「跋扈的專制統治」，其實我也不曉得真實狀況是怎樣。總之，目前的核心成員有原本 Node.js 的重要貢獻者：

• Fedor Indutny（@indutny）
• Trevor Norris（@trevnorris）
• Ben Noordhuis（@bnoordhuis）
• Isaac Z. Schlueter（@isaacs）
• Nathan Rajlich（@TooTallNate）
• Bert Belder（@piscisaureus）

也有邀請 Advisory Board 大家長 TJ Fontaine（@tjfontaine）但是被婉拒了，劇情超像 Jimmy’s Hall 的神父啊！lol

賤人就是矯情

StrongLoop 在 io.js 公諸於世之後發表了「StrongLoop’s Position on io.js」文章，來表示「其實我們還是愛著 Node.js 啦！但如果……」，彷彿是在向 Joyent 下達最後通牒，不好好處理我們就分手吧！

分裂其實對於整個 Node.js 生態系來說絕對是有害無益，但 StrongLoop 的態度就是師馬昭之心。看吧！文末還不忘歌功頌德一下他們自己。

最近常在他們公司網站上看到自我宣傳的文宣，尤其是這次 v0.12 版本當中有很大比例的程式碼是由 StrongLoop 的人 commit 的，那是因為 v0.12 可以視為 v1.0 版本的候選版本，這也意味著在告訴大家 Node.js v1.0 正式版最強力的推動者是我們 StrongLoop 啊！

其實這也沒什麼不好，而且 io.js 給的方向確實就是現在 Node.js 需要處理以及解決的問題，純粹是一種給人的觀感差異罷了。:p

小結

「這是個政治問題，需要政治的智慧來解決」，已經無關乎技術。

整個事件對於 Node.js 還是有點影響的，那就是 Joyent 終於發佈消息說 v0.12 即將到來，可能也意味著 v1.0 正式版本要隨之釋出，不過……我想這已經無法阻止 io.js 那群人繼續 forking，接下來會如何繼續拭目以待吧！

短文版

用 jade。

長文版

因為這個專案效能不會是評估重點，語法設計、擴充性、使用彈性會是比較在意的部分。

活在樣版引擎這個群雄割據的戰國時代實在太多選擇，從各方的評論和簡略地掃描文件上的語法特性，挑出以下幾個我比較喜歡的：

• TJ 早期樣版引擎代表作 ejs
• 以及 TJ 後來的 jade
• 還有 wycats（Yehuda Katz）的 handlebars

TJ 當初設計 Express 承襲 Ruby micro-framework Sinatra 的設計理念，ejs 好像是因應而生（？），從 ejs 語法上面可以看到非常多 Ruby 樣版引擎 ERb 的影子，對我來說是最「友善」的。不過 TJ 另創 jade 樣版引擎加上投奔 Go 世界以後，ejs 的活躍程度越來越低，從今年 5 月之後就再也沒有更新過了。

我向來都會先以「社群活躍度」來評量一個程式專案計畫可靠度，jade 貢獻者在 Github 上成立 jadejs 組織來維護專案，長久來看蠻可靠的。而 handlebars 在 Github 上也廣受 Javascript 開發者歡迎，所以最後我就拿這兩套樣版引擎來比較，以下是值得提出來講的部分。

（再強調一次好了：語法設計、擴充性、使用彈性是我比較在意的項目）

Layouts

寫過 Rails 後就很喜歡那種把不同 controller actions 的 view，跟 layouts 拆得乾乾淨淨的做法。這點 handlebars 可以做到，也是我最喜歡的一點，jade 必須在每一個 view 裡面寫上重複的 code，來表示外層的 layout：

1
2
3
4

extends layout

block content
  h1= post.title

把內容的部分宣告成 block，然後套進 layout 裏去。這也不是大缺點啦，block 寫法可以讓 view 不同區塊使用上更有彈性，但這就很考驗 block 的拆分功力了，不然真的會很容易寫出大量讓人崩潰的縮進層級。

Partials

版型上共用的部分一定會拆出來到同個檔案去維護，例如 header、footer、sidebar 之類的，handlebars 要做到這點繞得也太大圈：得先告訴 handlebars 的實例（instance）某個目錄放著我要的 partials 檔案，例如有個 header.hbs partial 放在 /views/partials 目錄下，然後要在 app 主要程式中寫：

1
2

var hbs = require('hbs');
hbs.registerPartial(__dirname, '/views/partials');

才能在 view 裡面帶入 header 這個 partial：{{> header}}。這樣讓檔案的組織非常缺乏彈性，如果 partials 不是在同個地方而是多個目錄，這樣光是找到檔案就很直覺。

條件判斷

這個是壓死駱駝最後一根稻草，handlebars 沒有辦法用很簡單的條件判斷式，內建的 #if helper 根本不是拿來寫「條件判斷」的，當初掃描完文件後一定會很自然地寫下 {{#if query === 'list'}}，這樣是不行的喔！

#if 頂多拿來判斷物件裡面有東西還是沒東西而已，如果真要寫個「條件判斷」一樣要拆去寫 helper，不管你的是多簡單的判斷。

結論

當初 wycats 寫 handlebars 時主要是為了解決前端樣版引擎的問題，所以可以發現很多 server-side 應用的場景 handlebars 都不適用。jade 是 TJ 寫給 Express 用的，讓我最不適應的地方是像 HAML 那樣「縮進崇拜主義」簡化的語法我實在不敢恭維，但顯然目前沒有比「不習慣」更好的理由來阻止我用它，因為 jade 其他面向提供的 solution 確實都能解決問題。

結論就是用 jade！

mongoose 是一套給 Node.js 用的 MongoDB ODM，跟常聽到的 ORM 不同的地方只是一些技術名詞定義上的把戲，其實是差不多的意思。

透過 mongoose 可以用包裝過的、更高階的、更直覺的 API 語法，以及模擬 SQL 資料庫 schema-based 的方式，來操作 MongoDB 資料庫。以下是個官方文件給的簡單範例，先建立了一個叫做 Cat 的 Model，model 的第二個參數就是建立 schema 的所在：

1
2
3
4
5
6
7
8
9

var Cat = mongoose.model('Cat',
  { name: String }
);

var kitty = new Cat({ name: 'Zildjian' });
kitty.save(function (err) {
  if (err) // ...
  console.log('meow');
});

與 MongoDB 建立連線

這裡繼續沿用上一篇文章「Node.js 的 Http vs Connect vs Express」的例子，先把上一篇文章的範例程式碼複製過來，檔案名稱命名為 server.js，下指令執行 node server.js 這樣可以得到一台簡單的伺服器：

1
2
3
4
5
6
7
8
9
10
11

var express = require('express')
  , app     = express()

app.use(express.cookieParser())

app.get('/', function(req, res) {
  console.log(req.cookies)
  res.send('hello')
})

app.listen('4000')

打開瀏覽器訪問 http://localhost:4000 應該可以看到「hello」的文字，從 console 應該也能看到有關 cookies 的資訊（有可能只是一個空的物件）。

再來就是把 mongoose 給 requrie 進來，然後讓它跟 MongoDB 嘗試建立連線，連線的 URL 協議一定要用 mongodb:// 這個 prefix：

1
2

var mongoose = require('mongoose')
mongoose.connect('mongodb://localhost/test')

mongoose 的兩個概念：Schema 與 Model

MongoDB 是以 documents 為基礎，在 SQL 資料庫稱為 table 的東西，在 NoSQL 裡稱為 collection。當然，這又是一種名詞定義上的把戲，實質上大同小異。

Schema

mongoose 的 Schema 概念就是用 schema-based 的方式，定義一個 collection 的組成結構，用程式碼描述會這樣子寫：

1
2
3
4
5
6
7
8
9
10

var Schema = mongoose.Schema
var UserSchema = new Schema(
  {
    name:      { type: String },
    login:     { type: String, unique: true },
    email:     { type: String, unique: true },
    create_at: { type: Date, default: Date.now },
    update_at: { type: Date, default: Date.now }
  }
)

因為 MongoDB 是 schema-less 相當有彈性，所以如果上面這個 schema 某些「欄位」沒有賦值，那麼在 MongoDB 裡就不會有那個「欄位」。說「欄位」是 SQL 的思維，可是我覺得這樣講會比較好理解。

Model

而 mongoose 的 Model 概念，則是對一個 collection 結構定義與操作方法的集合，也就是用 Schema 定義了一個 collection 的結構，加上其他對這個 collection 的驗證設定、操作方法等等，便構成了一個 Model。

結合剛剛的 schema 範例，可以再加上一些驗證跟操作的方法：

1
2
3
4
5
6
7
8
9
10
11
12

UserSchema.pre('save', function(next) {
  // do something...
})

UserSchema.statics = {

  getUserByLogin: function(login, callback) {
    this.findOne({ login: login })
      .exec(callback)
  }

}

最後將這個 Schema 定義到一個叫做 User 的 model：

mongoose.model('User', UserSchema)

當要使用這個 model 只要用 mongoose.model() 將 model 讀出來，便可以對他進行操作了：

1
2
3
4
5

var User = mongoose.model('User')

User.getUserByLogin(login, function(err, user) {
  // here we have a user...
})

為什麼 Schema-less 的資料庫需要 Schema-based？

不過這就很奇怪了，NoSQL 的 MongoDB 本身就是 schema-less 的資料庫，結果用 mongoose 還要去刻意模擬成 schema-based，這樣的思路是什麼？

其實這是對 NoSQL 的 schema-less 的誤解，schema-less 並不代表 no-schema。在應用當中還是需要一個 schema 來代表 model，而 schema-less 只是代表一種彈性的模式。

否則的話，會需要在很多地方寫髒亂的判斷條件，像是這樣的東西：

1
2
3

if (cat.name) {
  console.log(cat.name)  // I got a name
}

這篇應該是我第一篇寫有關 Node.js 的文章，未來應該會開始多寫一些有關 Javascript 的東西。這次主題要來聊聊 Node.js 的 http 模組，跟知名的 Connect 和 Express 之間的關係，如果上網去問，有人會回說就像是 Ruby 的 Rack 一樣，但是具體到底是什麼東西呢？

http 模組

Node.js 自身就帶有一個叫做 http 的 module，可以呼叫 http.createServe 建立一個相當基本伺服器，具體用法會長得像是以下這個樣子，可以建立一份檔案命名為 server.js 來測試一下：

1
2
3
4
5
6

var http = require('http')

http.createServer(function(req, res) {
  res.writeHead(200)
  res.end("hello world\n")
}).listen(8000)

然後在終端機執行 node server.js 指令來啟動伺服器，因為程式碼裡面指定了 8000 port，所以當在瀏覽器裡打開 http://localhost:8000 看到「hello world」就代表成功了。

Connect

然而我需要更多的細節，例如讀取送來的 request 中的 cookies，因此 Connect 這樣的 middleware 框架，便是用來輕鬆安插各種 middleware 來處理 request，透過 connect.cookieParser() 讓 req 物件多了一個 cookies 屬性：

1
2
3
4
5
6
7
8
9
10
11

var http    = require('http')
  , connect = require('connect')

var app = connect()
  .use(connect.cookieParser())
  .use(function(req, res) {
    console.log(req.cookies);
    res.end('hello');
  })

http.createServer(app).listen(8000)

但是 Connect 充其量只是提供了安插 middleware 的 API，其他像是 route、view rendering 等工作，就會需要靠 Express 這套框架了。

Express

Express 其實就是延伸自 Connect 的加強版，所有 Connect 的 API 在 Express 裡都可以使用，並且提供了更多實用的 functions，一次解決所有問題。

將剛剛寫的程式碼修改成以下的範例，其中 get 這個 function 就是 HTTP 的動詞，有了這樣的 API 便能很輕鬆地策劃路由了：

1
2
3
4
5
6
7
8
9
10
11

var express = require('express')
  , app     = express()

app.use(express.cookieParser())

app.get('/', function(req, res) {
  console.log(req.cookies)
  res.send('hello')
})

app.listen('4000')

一言以蔽之，http 之於 Connect，就如 Connect 之於 Express。

參考資料

• What is Node.js’ Connect, Express and “middleware”?

（本文的例子用的是 SCSS 語法）

OOCSS

OOCSS 不是什麼新技術，只是一種撰寫 CSS 的設計模式，或者可以說是一種「道德規範」，大致上我覺得重點只有兩個：

• 減少對 HTML 結構的依賴
• 增加 CSS class 重複性的使用

減少對 HTML 結構的依賴

1
2
3
4
5
6
7

<nav class="nav--main">
  <ul>
    <li><a>.........</a></li>
    <li><a>.........</a></li>
    <li><a>.........</a></li>
  </ul>
</nav>

一般的導航欄寫法，結構應該會像上面的 HTML 範例一樣，如果要對那些 <a> 標籤定義樣式，CSS 的寫法可能寫成 .nav--main ul li a {}，這種寫法先不管效能上的問題，可以看出來過度地依賴元素標籤的結構，有可能之後 HTML 結構改變，這個 CSS 就必須跟著重構，造成維護上多餘的成本。

若從這個例子來考量，原則上 <a> 都一定會接在 <li> 標籤的後面，一個 <li> 只會有一個 <a>，通常不會獨立存在，那就可以寫成 .nav--main a {}，會是比較好的寫法，甚至是直接給 <a> 加上 class nav--main_item。後者是 OOCSS 所提倡的用法。

這樣的寫法，一來效能理論上比較好（我沒辦法驗證），二來層次比較單純。

增加 CSS class 的重複使用

在 OOCSS 的觀念中，強調重複使用 class，而應該避免使用 id 作為 CSS 的選擇器。這種想法就是像 OOP 盡量抽離重複的程式碼，例如以下這個例子，這是兩種按鈕的 CSS 樣式屬性：

1
2
3
4
5
6
7

.button {
  display: inline-block;
  padding: 6px 12px;
  color: hsla(0, 100%, 100%, 1);
  &.button-default { background: hsla(180, 1%, 28%, 1); }
  &.button-primary { background: hsla(208, 56%, 53%, 1); }
}

上面的 CSS 將兩種不同樣式的 button，抽離出重複的部份，並且定義在同個 class 上。因此，要使用這樣的樣式，HTML 的寫法可能長這個樣子：

1
2

<a class="button button-default">
<a class="button button-primary">

先用 button 宣告此為一個按鈕的樣式，再用 button-default 或 button-primary 作為按鈕底色的區別。這麼做可以維護成本變得比較低，例如：想要改網站上所有按鈕的大小，就只要修改 .button 的 padding 而已。

SMACSS

我對 SMACSS 的理解還不是很深入，或許把 Scalable and Modular Architecture for CSS 看完後會有更深一曾的理解。目前對 SMACSS 的概念僅限於它對 CSS 不同的業務邏輯所做的劃分方式：

但我認為原本的設計不是很妥當，因此我自己做了一些改良：

• Base
• Layout
• Module
• Partial
• State
• Theme

Base

Base 就是設定標籤元素的預設值，例如瀏覽器的 reset 可以寫在這裡，如果用的是 Compass，只要 @include global-reset 即可。這裡只會對標籤元素本身做設定，不會出現任何 class 或 id，但是可以有屬性選擇器或是偽類：

1
2
3

html {}
input[type=text] {}
a:hover {}

Layout

Layout 是指整個網站的「大架構」的外觀，而非 .button 這種小元件的 class。網站通常會有一些主要的大區塊，可能是 header 或 footer，Layout 就是用來定義這些「大架構」的 CSS。如果有做 Responsive Web Design 或是用 Grid System，也是把規則寫在 Layout 這裡。

以下這是個範例：

1
2
3
4
5
6

#header { margin: 30px 0; }
#articles-wrapper { ......; }
.sidebar {
  &.sidebar--right { ......; }
  &.sidebar-left { ......; }
}

通常只有一個選擇器，一個 id、或一個 class。

Module

原本的 SMACSS 對 Module 的設計我覺得不是很好，所以我硬是將 Module 拆分出一個 Partial。

這裡的 Module 顧名思義，就是可以在其他地方被重複使用，如果要找更明確的例子，我想就像 Twitter Bootstrap 的 Components 一樣，或者像前面 OOCSS 所舉例的 .button 這種會被重複使用的元件模組。

模組不需要用任何的 prefix，因為 Module 就是設計來可以重複應用在不同的 page 上。

Partial

Partial 跟 Latout 不同，也跟 Module 不同，他比 Layout 的範圍小，可能是 header 底下的某個子元素。他不像 Module，他是特定單一領域下特別的設定。

1
2
3

.nav--main {
  a { ......; }
}

通常會將 Partial 的名稱加在子 class 作為 prefix，例如 .nav--main 底下的 .nav--main_item。至於為什麼要用這麼奇怪的命名方式？這等等在 CSS 規範部分會說明介紹。

State

State 負責定義元素不同的狀態下，所呈現的樣式。但是並非指一個元素的 :hover 或 :active 下的狀態。舉例來說，一個導航欄分頁，目前所在頁面的分頁需要加上 .active 的屬性表示目前位置是在這個分頁，HTML 會長這樣：

1
2
3
4
5
6
7

<nav class="nav--main">
  <ul>
    <li><a>.........</a></li>
    <li class="active"><a>.........</a></li>
    <li><a>.........</a></li>
  </ul>
</nav>

因此可以替 .nav--main 增加 .active 這樣的子 class：

1
2
3
4
5
6

.nav--main {
  // others…;
  .active {
    background: darken($background-color, 16%);
  }
}

有時候為了讓閱讀更貼近語義，會用比較友善的命名方式，以此段的範例來說，.is-active 就比 .active 來得好讀。

Theme

Theme 是畫面上所有「主視覺」的定義，例如 border-color、background-image 或是 font-family 等相關的 Typography 設定。為什麼說是「主視覺」？因為有些元件模組仍然是留在 Module 去定義，Theme 就像 Layout 一樣負責「大架構」上的視覺樣式。

CSS 規範

這裡整理的是我覺得一定要知道的，其他還有很多規範可以轉到文末的參考資源連結，那篇文章有介紹更多的細節。

BEM

BEM 即 Block、Element、Modifier 的縮寫，這是一種 class 的命名技巧。如果整個 project 只有自己一個人做，那當然是不太可能出現 class 重複的問題，但是如果同時多個 F2E 一起寫同個部分的 CSS，就很容易出現共用 class 的問題，因此有了 BEM 這樣的命名技巧。

將 Block 區塊作為起始開頭，像前面 SMACSS 介紹的 Partial 就可以拿來作為 Block 的 prefix 名稱；Element 則是 Block 下的元素；Modifier 則是這個元素的屬性。

不同 Block 和 Element 用 __ 兩個底線區隔開來，不同的 Modifier 則用 -- 兩個 dash 區隔。至於 - 一個 dash 則表示這個 class 不依賴任何 Block 或 Element，是個獨立的存在，例如：.page-container 或 .article-wrapper。

這裡有個範例：

1
2
3
4
5
6

.sidebar {
  .sidebar--left__section {
    .sidebar--left__section--header {}
    .sidebar--left__section--footer {}
  }
}

Javascript Hook

透過 CSS class 來作為 Javascript 選取 DOM 節點的方式，就是 Javascript Hook。用 jQuery 可以常常看到這樣的寫法：$('.nav--main a')，可是當 CSS 跟 Javascript 攪在一起反而造成兩邊維護上的不便，當改了 CSS 時 Javascript 也要跟著改。

所以用 HTML 的屬性去選取 DOM 節點會更好，如果非要用 CSS 的 class 那也可以多寫一個 js- 的 prefix，以表示這個節點有被 Javascript 使用，例如：

1
2
3

<li class="nav--main__item  js-nav--main__item"><a>.........</a></li>
<li class="nav--main__item  js-nav--main__item"><a>.........</a></li>
<li class="nav--main__item  js-nav--main__item"><a>.........</a></li>

PS. HTML 裡兩個 class 之間用兩個空格，會比一個空格看起來好閱讀。

合理的選擇器

class 無所謂是否語意化的問題；你應該關注它們是否合理，不要刻意強調 class 名稱要符合語意，而要注重使用的合理性與未來性。

有時候為了表示更明確，在使用 CSS 的選擇器時，要表示某的 class 是搭配某個標籤元素使用，會寫成這樣：

1
2
3

ol.breadcrumb{}
p.intro{}
ul.image-thumbs{}

但是上面這個寫法效能不是很好，同樣的目的但可以減少多餘的修飾，試試改用下面這種寫法，將標籤名稱用註解標示起來，維護上有相同的效果，但是瀏覽器處理的速度會比較快：

1
2
3

/*ol*/.breadcrumb{}
/*p*/.intro{}
/*ul*/.image-thumbs{}

參考資源

• 撰寫可管理、可維護的 CSS 高階技巧

最近有位朋友的 Facebook 帳號第二次被盜，然後一堆人被他加進一些討厭又奇怪的團購社團，那位朋友也是尷尬又無奈，所以我就教他一些我設定密碼的「演算法」，聊天內容很多，我就順便整理到部落格來分享，希望對其他人有用。

在設定密碼前應該要有個基本認識，就是這個密碼可能對於你媽而言是保密的，但是在室友駭客面前、或是網站管理員面前，它是透明毫無隱藏的，所以在這前提下就不應該把每個網站全部設同個密碼，因為駭客可以拿這套帳號密碼去登入其他網站。

密碼演算法

但是每個網站密碼都不一樣怎麼記得住？所以需要一套「演算法」，以後只需要記憶這套算法，而不是去記密碼。「演算法」聽起來好像很神奇，其實只是一套組合的方法，隨便舉例：

網站分級變數 + 常數 + 網站辨識代號 = 密碼

以下來分別說明這些東西是什麼。

網站分級變數

網站分級是指依照網站的重要性分類，並且替每個級別設定不同的密碼。最核心的網站通常是信箱服務，例如 Google、Yahoo，你應該替他們設定一個獨立的密碼，與那些亂七八糟的小網站區隔開來。

那應該拿什麼來當變數？我的建議是，你可以選你最愛顏色的 16 進位色碼（如果你偏愛 HSL 也行…… :p），或是圓周率小數點後的第 108 位數到 116 位數（前提是你得背起來 XDD），又或者是一句名言每個字的開頭第一個字母，例如「Why join the navy if you can be a pirate」變成「Wjtniycbap」。

將網站依照重要性分成三種等級，並且每種等級分配一種變數：

• 核心（Google…）：Wjtniycbap
• 次等（Evernote…）：bion
• 下等（亂七八糟論壇…）：wwantm

太多不好記？寫下來也沒關係，反正別人猜不到你的算法，給他看也沒關係，只要別在紙上寫「這是密碼」就好了。不過，用不著分類太多，三種級別其實也不難記。

常數

這是一組夾雜在密碼裡不會改變的常數，主要目的是增加密碼整體的複雜度。最好是數字跟英文的混合，甚至大小寫混合都可以。綜合上一個變數，現在密碼變成了：

• 核心（Google…）：Wjtniycbap + 0rz
• 次等（Evernote…）：bion + 0rz
• 下等（亂七八糟論壇…）：wwantm + 0rz

網站辨識代號

這是這個網站的獨有特徵，可以是這個網站 domain 名稱的變體，例如 Google 的偶數字母：oge；或是該字母在 26 個字母當中的索引位置，o 是第 15 個字母、g 是第 7 個、e 是第 5 個，合起來就是 1575。

最後，我們的密碼就變成了這樣：

• 核心（Google…）：Wjtniycbap0rz + oge
• 次等（Evernote…）：bion0rz + vro
• 下等（亂七八糟論壇…）：wwantm0rz + xxx

這樣就能產生每個網站都不一樣的密碼，而且不同級別的網站也不會彼此影響到。密碼不是背起來的，而是推理出來的。很酷！也很宅，對吧？

還有些事情必須知道

• 正妹說會經常換密碼的男人最性感，你可以定期更改「網站分級變數」這個部分，或是修改整套算法。
• 網站分級不是依你常去的網站來劃分（我知道你常去那種網站，但你也要知道那種網站一定會偷你的密碼），而是這個網站不可被攻破的重要性來區別。
• 越重要的核心服務建議啟用多一點的認證機制，例如 Google、Facebook 都有提供手機簡訊的登入認證機制，請一定要啟用它。
• 可以變化的不是只有密碼，不同網站當然也可以使用不同的帳號。如果有些網站是「只使用一次」性質的網站，可以多多利用 10 Minute Mail 這個服務。
• 依賴算法其實也有些缺點，例如網路銀行的密碼通常會硬性規定要 8 個字元，迫使我必須要另外想一個特例的密碼給網路銀行，下場就是我從來記不住我網路銀行的密碼是什麼。:p

關於密碼管理工具

儘管現在很多人喜歡用 KeePass 和 LastPass 這類的軟體，但我始終不是很信任這類軟體，也不喜歡用。況且……人類發明了機器，並且替機器上了鎖，卻又用了另外一台機器來管理這把鎖，然後又替這台機器上了另外一把鎖，還真是有趣？要是這把鎖掉了，那就真的全面失控了啊！

再說……連駭客都說不敢用了，你敢用嗎？XDD

常用電腦的人一定都很熟悉 Ctrl + Tab 這個功能，可以快速在不同視窗之間切換，可是在 Windows 下當我使用這個功能時，給我的介面是這樣的：

主要是一個視窗縮圖，和一個小小的應用程式 icon 塞在右下角，辨識度非常地差，我很難一眼就快速認出哪個視窗是我要切換的應用程式。再來看看 OS X 切換視窗的介面：

清楚的應用程式 icon 辨別度非常的強，我一眼就能看出哪個應用程式是我想要切換過去的。這裡也能說明一個應用程式的 icon 設計也是很重要，不需要特別的華麗只需要留下足夠的印象，讓人很容易辨識。

順便分享一下我的 Chrome 常用書籤長這樣，也是靠清楚的 icon 來做為辨識：

但是我在整理 Windows 那台電腦硬碟時，遇到最惱人的狀況其實是這個，同一個應用程式都是長得差不多的縮圖：

這樣我完全不知道到底該切到哪一個視窗，而 Windows 下好像也沒有類似 Command + ` 的功能。如果是 OS X 下，還可以用 Mission Control 或是 Expose 等方式，方便地在不同視窗之間做選擇，這部份 Windows 的介面體驗就做得讓人很難受。

好在我現在只是要整理資料夾，以前我有玩過不少檔案總管的視窗管理軟體，可是介面都做得很宅（不友善）。OS X 上我現在用的是 XtraFinder 這套模擬 Chrome 的標籤介面，看起來相當簡潔，外觀長這樣：

所以我也想要在 Windows 上，找一個相似風格的視窗管理軟體，後來找到了 Clover 3 用起來還不錯，還有類似書籤的功能，可惜我覺得有點雞肋就是了，外觀長這樣：

題外話，我現在已經漸漸不太用 Command + Tab 的方式切換應用程式，而是改用 Alfred 這套軟體直接輸入應用程式名稱關鍵字來切換，因為有時候程式開得太多，一直 Tab、Tab、Tab 也是很煩的。XD

過幾天，有空來寫一篇介紹一些 mouseless 操作電腦的方法好了。:)

先前曾經寫過怎麼使用 Pathogen 管理 Vim 的外掛，Git 的 submodule 用久了開始覺得很不方便，有時候只是要測試一下新玩具，用完就刪掉，可是前後要操作的指令至少超過四個，實在有夠麻煩。

正打算來寫個 script 自動化過程，但這種東西怎麼可能沒人寫過，於是上網找了一下，被我發現 Vundle 這個管理工具，看完 README 後馬上就把 Pathogen 刪掉了，然後寫了這篇文章。XD

Vundle 的優點

• 可以保持 git repo 的簡潔
• 讓安裝/更新/刪除外掛更方便

需要參考的話，可以看我放在 Github 上的 .vimrc 範例。

保持 git repo 的簡潔

透過 Vundle 管理外掛我不再需要讓 git 追蹤 .vim/bundle/ 目錄，甚至連 Vundle 本身也不用追蹤，只要在 .vimrc 裡這樣寫：

1
2
3
4
5
6
7
8
9

let iCanHazVundle=1
let vundle_readme=expand('~/.vim/bundle/vundle/README.md')
if !filereadable(vundle_readme)
  echo "Installing Vundle.."
  echo ""
  silent !mkdir -p ~/.vim/bundle
  silent !git clone https://github.com/gmarik/vundle ~/.vim/bundle/vundle
  let iCanHazVundle=0
endif

這樣一來，啟動 Vim 的時候就會自動去檢查 Vundle 安裝了沒，因此可以在 .gitignore 裡把 bundle 目錄直接忽略掉，不用再拖著一坨外掛跟著跑了。XD

安裝/更新/刪除外掛更方便

安裝、更新外掛是同一條指令，在 .vimrc 裡加上外掛的 Github 的作者名和 repo 名稱，像這樣：

1
2
3
4
5

Bundle 'Lokaltog/vim-easymotion'
Bundle 'Lokaltog/vim-powerline'
Bundle 'airblade/vim-gitgutter'
Bundle 'Townk/vim-autoclose'
Bundle 'kien/ctrlp.vim'

然後下指令 :BundleInstall，Vundle 會去搜尋對應的 repo，如果已經下載過便會檢查有沒有更新。要移除也很簡單，只要把該外掛那行刪掉或是註解掉，重新下一次指令就行了。

Vim 的外掛腳本基本上都可以在 vim-scripts.org 搜尋到，如果沒有 host 在 Github 上也可以直接輸入該外掛的名稱，例如這樣：

1
2

Bundle 'L9'
Bundle 'FuzzyFinder'

若是該外掛放在別的 git 主機上，也可以丟 git URL，Vundle 會很聰明地判斷該去哪裡抓：

1

Bundle 'git://git.wincent.com/command-t.git'

早上整理 .dotfiles 因為對 Git 的 submodule 指令不熟悉弄得灰頭土臉，最後把整個目錄砍掉重新 clone 回來，結果發現 submodule 裡面的目錄都是空的，才知道原來 Git 不會自動去抓 submodule 的 repo，還要另外加一些指令。

這些指令因為不會很常用（吧？），最近是因為在摸索 Vim 的補丁管理才開始碰到 git submodule 問題，如果不寫可能後天就忘光了，所以我把今天碰到的問題整理記錄下來。

新增 submodule

git submodule add git://github.com/majutsushi/tagbar.git .vim/bundle/tagbar

如果這個 repo 先前沒有用過 submodule 那麼 Git 會在目錄下建立一個叫做 .gitmodules 的目錄，這裡記錄了 remote repo 的 URL 和這個 submodule 在此專案的路徑。

執行此命令後 submodule 和 .gitmodules 會自動 staged，這個時候可以 commit 和 push。

更新 submodule

個別 repo 更新比較麻煩，必須到個別的目錄底下執行 git pull 去拉 upstream 的程式碼，可是這樣會比較安全；若要一次全部更新所有的 submodule 可以用這 foreach 指令：

git submodule foreach --recursive git pull origin master

刪除 submodule

本以為會有像是 git submodule rm 這樣的指令，結果竟然沒有，必須辛苦地一個一個手動移除，不知道不實作這個指令的考量是什麼，希望未來的版本能把它加上去。

移除 submodule 有以下幾個步驟要做，先把 submodule 目錄從版本控制系統移除：

git rm --cached /path/to/files
rm -rf /path/to/files

再來是修改 .gitmodules，把不用的 submodule 刪掉，例如：

1
2
3
4
5
6

 [submodule ".vim/bundle/vim-gitgutter"]
   path = .vim/bundle/vim-gitgutter
   url = git://github.com/airblade/vim-gitgutter.git
-[submodule ".vim/bundle/vim-autoclose"]
-  path = .vim/bundle/vim-autoclose
-  url = git://github.com/Townk/vim-autoclose.git

還沒完喔！還要修改 .git/config 的內容，跟 .gitmodules 一樣，把需要移除的 submodule 刪掉，最後再 commit。

clone 時把 submodule 一起抓下來

執行 git clone 時 Git 不會自動把 submodule 一起 clone 過來，必須加上 --recursive 遞歸參數，這樣可以連帶 submodule 的 submodule 通通一起抓下來：

git clone --recursive git@github.com:chinghanho/.dotfiles.git

如果已經抓下來才發現 submodule 是空的，可以用以下指令去抓，init 會在 _.git/config` 下註冊 remote repo 的 URL 和 local path：

git submodule init
git submodule update --recursive

或是合併成一行 git submodule update --init --recursive 也可以，如果 upstream 有人改過 .gitmodules，那 local 端好像也是用這個方法 update。

指令解釋

• git submodule init：根據 .gitmodules 的名稱和 URL，將這些資訊註冊到 .git/config 內，可是把 .gitmodules 內不用的 submodule 移除，使用這個指令並沒辦法自動刪除 .git/config 的相關內容，必須手動刪除；
• git submodule update：根據已註冊（也就是 .git/config ）的 submodule 進行更新，例如 clone 遺失的 submodule，也就是上一段講的方法，所以執行這個指令前最好加上 --init；
• git submodule sync：如果 submodule 的 remote URL 有變動，可以在 .gitmodules 修正 URL，然後執行這個指令，便會將 submodule 的 remote URL 更正。

從官網上的描述，tmux 是個 terminal multiplexer，意思就是可以讓終端機同時跑多個程式，不用的時候可以把他們藏到背景去，需要的時候再叫出來，甚至 ssh 登入到遠端主機也不會斷掉，此外還可以在同個視窗下切割區塊，如下圖（圖片來源）：

右邊開 Vim 寫程式，左上角跑 RSpec 測試，同時左下角開 Rails server 看 log，神奇的是這些狀態可以保存起來，不需要的時候可以藏到背景去，可是用 Sublime Text 2 就沒這麼理想，害我有種想改用 Vim 的衝動。

在 OS X 上使用 Homebrew 安裝 tmux

首先要安裝 Homebrew，沒有安裝過的話只要在終端機執行這一行指示即可：

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

儘管剛剛才安裝 Homebrew 但是還是要先更新一下再安裝程式：

brew update
brew install tmux

tmux 運作方式

2013.04.19 更新：Youtube 上 tmux Quick Start 這部影片介紹非常清楚，值得一看。

從 SuperUser 看到的答案，如果關閉終端機掛載在上面的 shells 也會跟著被刪除，結構就像是這樣：

iterm2
  +---- shell
  +---- shell
  +---- shell

tmux 採用 client-server 的 model，每一個 session 作為一個 client。透過 tmux 仍然會保持所有 shells 繼續運作，即便把整個終端機都關閉，因此可以之後重新將他們重新掛載上去，這也是為什麼在 tmux 下用 ssh 登入遠端主機不會斷線的原因：

iterm2
  +---- tmux
          +---- shell
          +---- shell
          +---- shell

tmux 基本用法

直接在終端機執行 tmux 會開啟第一個 client，可以執行 tmux ls 查看有哪些 client，如果沒有任何 client 可以用，tmux 會自動建立一個。執行 tmux 後終端機底部會顯示一條狀態欄：

tmux 預設的操作要加上 Ctrl-b 功能鍵；tmux 也有類似 Vim 的指令模式，快捷鍵 Ctrl-b 後按 : 可以執行指令。以下是一些基本、常用的功能：

• Ctrl-b + c：建立新的視窗；
• Ctrl-b + d：卸載目前的 client；
• Ctrl-b + l：與先前選擇的視窗間切換；
• Ctrl-b + n：移動到下個視窗；
• Ctrl-b + p：移動到上個視窗；
• Ctrl-b + &：刪除目前的視窗；
• Ctrl-b + ,：重新命名目前的視窗；
• Ctrl-b + %：將目前的視窗分離到兩個區塊；
• Ctrl-b + q：顯示各分割區塊的號碼（用來切換到不同的區塊）
• Ctrl-b + o：切換到下個區塊；
• Ctrl-b + ?：列出所有快捷鍵的說明；
• Ctrl-b + w：列出目前 clinet 的視窗，可以用數字鍵切換；

要將目前視窗切割多個區塊，快捷鍵如下：

• Ctrl-b + %：垂直分離視窗；
• Ctrl-b + :split-window：水平分離視窗；
• Ctrl-b + o：移往下一個區塊；
• Ctrl-b + q：顯示區塊的數字代號，當數字顯示時使用數字鍵移往該區塊；
• Ctrl-b + {：將目前的區塊移往左邊；
• Ctrl-b + }：將目前的區塊移往右邊；

個人設定

切割面板區塊的快捷鍵好像有點難記，可以在根目錄下建立 ~/.tmux.conf 檔案，定義自己容易記憶的快捷鍵：

unbind %
bind | split-window -h
bind – split-window -v

Ctrl-b 距離太遠也很難按，先前有用 GNU screen 的人會將它改成 Ctrl-a，可是這會和某些快捷鍵衝突，所以我把它改成 Ctrl-f：

set -g prefix C-f
unbind C-b
bind C-f send-prefix

我的 .tmux.conf 檔案放在我 Github 上的 .dotfiles 裡，有興趣可以去看看，這裡附上最後我修改的成果圖，加上原本 oh-my-zsh 修改結果，整個變得超級花俏啊 XD（點圖可放大）：

底下的 status bar 是抄 wemux 作者的設定，我覺得非常漂亮。最後推薦這兩個連結的文章，介紹非常詳細：

• TMUX – The Terminal Multiplexer (Part 1)
• TMUX – The Terminal Multiplexer (Part 2)

可以與 iTerm2 整合

iTerm2 wiki 頁面上有教怎麼跟 tmux 整合，看了一下說要下載一些東西，然後還要編譯過才能用，可是我發現我直接輸入 tmux -CC 就可以用了，不清楚發生什麼事。

跟 iTerm2 整合的好處是可以用 iTerm2 的分頁和切割區塊功能取代 tmux 那些一堆的指令，可是我試用的結果發現很多不方便的地方，所以我還是用原本 tmux 切割區塊的方式。

已知問題

目前發現有兩個問題。

在 tmux 下無法使用系統 pbcopy 等複製貼上的指令，在 thoughtbot 網站上找到解決方法：

brew install reattach-to-user-namespace

然後在 .tmux.conf 檔案裡加上以下這行設定：

set-option -g default-command "reattach-to-user-namespace -l zsh"

還有個問題是 git commit 我預設用的是 Sublime Text 2 編輯器，可是編輯提交訊息後會卡住不動，也就是 subl -w 無法返回，目前無解。

2013.04.12 更新：今天把 Command-T 移除掉換用 ctrlp，優點是用不用 Ruby 去編譯，用的是 Vimscript 去寫，所以效能跟問題也會比較少。 2013.05.25 更新：今天起改用 Vundle 來管理，可以參考我的新文章：「更好用的 Vim 外掛管理工具：Vundle」

安裝 Pathogen

管理 Vim 補丁我用的是 Pathogen 這套，可以讓所有補丁統一放在 ~/.vim/bundle 下，每個補丁就是一個獨立的資料夾，想要移除就直接砍掉即可。安裝方法是將 pathogen.vim 腳本放在 ~/.vim/autoload 目錄下，可以用以下指令完成：

1
2
3

mkdir -p ~/.vim/autoload ~/.vim/bundle; \
curl -Sso ~/.vim/autoload/pathogen.vim \
    https://raw.github.com/tpope/vim-pathogen/master/autoload/pathogen.vim

然後將這行加進 .vimrc 裡，啟動 Vim 時便會自動讀取 ~/.vim/bundle 下的補丁檔案：

" auto load all plugins in vim bundle
execute pathogen#infect()

安裝補丁

之後只要將下載的補丁資料夾拖進 ~/.vim/bundle 裡面即可，不過我更偏愛使用 Git 來管理。假設要安裝 Command-T 補丁，可以用 Git 的 submodule 指令完成：

1
2
3
4
5

cd ~/.vim
mkdir ~/.vim/bundle // if you have not yet created this directory
git submodule add https://github.com/wincent/Command-T.git bundle/command-t
git add .
git commit -m "install Command-T plugin as a submodule"

更新補丁

使用 Git 安裝補丁的好處是可以自己動手 hack，也可以保持更新。對單一補丁更新只要變更所在目錄到該補丁的位置，然後 git pull 去拉 upstream 的最新程式碼：

1
2

cd ~/.vim/bundle/command-t
git pull origin master

要一次更新所有已安裝的補丁，則可以用 Git 的 foreach 指令來更新每個補丁的最新版本：

git submodule foreach git pull origin master

後記

平常被 Sublime Text 的 Package Control 寵慣了，來用 Vim 感到非常的麻煩和不習慣，而且 Command-T 安裝後還要用 Ruby 跟 C 去編譯才能用，這到底是什麼鬼編輯器啦！XD

既然現在 Google 對於已登入的用戶已經預設用 HTTPS 連線，那這個東西還留著幹嘛？所以問一下 Google 找答案，原來 encrypted.google.com 另有其他特異功能，兩者之間的差異，主要在於點擊廣告與搜尋結果時，處理 HTTP 參照位址的方式不同。

點擊一個廣告

• https://www.google.com：Google 將會把你帶到一個 HTTP 的重新導向頁面，在那裡他們會把你的搜尋字串塞進參照資訊裡去。

• https://encrypted.google.com：如果這個廣告主用的是 HTTP，Google 不會讓他們知道你的查詢字串是什麼。而如果廣告主用的是 HTTPS，他們將會如常地收集到你的參照資訊（包括查詢字串）。

點擊一般的搜尋結果

• https://google.com：除果網站使用 HTTP 連線，Google 將會把你帶到 HTTP 的重新導向頁面，但是不會把你的搜尋字串給塞進參照資訊裡面。他們只會告訴網站你是從 Google 來的。如果你的網站使用 HTTPS 連線，便可以正常地搜集到參照資訊。

• https://encrypted.google.com：如果你點擊的網站使用 HTTP 連線，Google 既不會告訴它查詢字串是什麼，也不會告訴它你是哪裡來的。如果該網站使用 HTTPS 連線，它則會正常地收到參照資訊。

所以我的 blog 從搜尋引擎來的訪客中，用關鍵字去查有 74% 都是「not provided」大概就是這個原因。如果這篇答案的結果是正確的，採用 HTTPS 連線加密的網站便可以正確地搜集到帶有查詢字串的參照資料，那網站採用 HTTPS 將會變成最基本的條件。