雖然 Microdata 的目的是易於機器理解,但最終也能惠於用戶

https://schema.org/docs/gs.html

Microdata 是 HTML5 引入的,是為機器而不是用戶所設計的,主要目的是為了機器能更好的理解內容。這看起來與前端沒什麼關係,一般理解的前端是服務於用戶的,主要負責與用戶交互的部分。但是 microdata 是 HTML 的一部分,雖然目的是易於機器理解,但最終也能惠於用戶。

Microdata & Schema.org 的現狀與未來
目前 Google, Bing, Yandex, Yahoo! 都支援 Microdata,但是進度不一效果不一,支援度最好的還是 Google。

各個搜索引擎商的接入文檔:

https://developers.google.com/structured-data/
http://www.bing.com/webmaster/help/marking-up-your-site-with-structured-data-3a93e731
https://help.yandex.com/webmaster/microdata/what-is-microdata.xml
https://help.yandex.com/webmaster/schema-org/what-is-schema-org.xml
結構化的數據不僅僅能被這些 Web 搜索引擎使用,還能被諸如 Siri, Cortana 等語音設備使用,當然,他們也能被當作搜索引擎。

實測 Siri 所推薦的網頁資訊都是有做 Microdata 的。

結構化的數據在未來相當有吸引力,方便未來的各種設備接入。比如「智能廚房」,你告訴它你要做什麼菜,於是它從下廚房找到了菜譜,因為下廚房使用了結構化數據,「智能廚房」就能直接列出需要的材料與材料的份量。

目前正在應用的點有很多,比如日曆、地圖、郵件等。尤其值得一提的是郵件,這個古老的通訊方式也許會在結構化數據下煥然一新。Gmail 已經在做一系列嘗試了,比如從郵件里提取出你的行程以及日程安排,比如匯總你的收據。

詳閱 https://lepture.com/zh/2015/fe-microdata

以下為頁庫存檔:


Microdata 以機器可解析的語言來描述網頁里的內容是什麼,比如網頁描述的是一本書、一篇影評或者一張菜譜。例如上面的這張圖,展示的是我的一篇書評在 Google 搜索里的結果,它有作者信息、有評分、有發表時間,這都是因為這篇書評的網頁里使用 Microdata 標示出了相應的信息。

Microdata 基礎

Mircodata 主要用到這幾個 attributes 來標注信息:itemscope, itemtype, itemprop,另外還有 itemid 與 itemref。
包含 itemscope 這個 attribute 的 DOM 樹就是一個事物(item),例如:
<div itemscope>
...
</div>
我們可以給這個事物定義一個類型,比如一本書,這時就需要用到 itemtype,它的值是一個或多個 URL:
<div itemscope itemtype="http://example.com/Book">
...
</div>
如上的代碼片斷,我們知道它是一本書了,但是它還缺少書的信息,需要用 itemprop 來標示:
<div itemscope itemtype="http://example.com/Book">
  <div>書名:<span itemprop="name">改革歷程</span></div>
  <div>作者:<span itemprop="author">趙紫陽</span></div>
  ...
</div>
也許因為奇怪的設計方案,也許因為 PM 的無理取鬧,也許就是因為代碼不太好寫,佈局並不能輕易合乎要求,itemprop 可能散落於其它地方,這時可以使用 itemref 將它們連接起來:
<div itemscope itemtype="http://example.com/Book" itemref="a b">
  <div>作者:<span itemprop="author">趙紫陽</span></div>
  ...
</div>

<!-- 因為某些原因,書名與價格不在 scope 裡面 -->
<div id="a">書名:<span itemprop="name">改革歷程</span></div>
<div id="b">價格:<span itemprop="price">$12</span></div>
Microdata 也定義了 DOM API,目前只有 Firefox 與 Opera 支持,用途不太大,可以在 Firefox 的終端里測試一下:
document.getItems()
document.getItems('http://schema.org/Article')

Microdata 與 Schema.org

Microdata 作為規範,定義好了語法,其中 itemtype 表示事物的類型。如果每一家都自己定義 itemtype的話,結局將相當糟糕,網站開發者也將頭疼不已。於是 Google, Bing, Yandex, Yahoo! 合作創建了 Schema.org 用以統一規範 Microdata。
Schema.org 不是標準化組織,所做的卻是標準化的事情。查閱 Schema.org 快速入門文檔,瞭解如何使用。例如你正在看的這篇文章所在的頁面便在使用 http://schema.org/Article 這個 itemtype,你可以查看一下本頁面的源碼。
Schema.org 定義了許多類型,仍然在創建更多的類型。這些定義對後端開發也有意義,幫助你理解業務模型,瞭解某一模型應該包含哪些數據,亦是不小的啓發。
比如我們來賣個車看看:http://schema.org/Car
<div itemscope itemtype="http://schema.org/Car">
  <h2 itemprop="name">奇瑞QQ</h2>
  <p itemprop="description">中國汽車製造商奇瑞汽車公司於2003年推出的一款微型車(...)</p>
  <img itemprop="image" href="2003_qq.png" />
  <div>
    <strong>顏色</strong>
    <span itemprop="color">黑色</span>
  </div>
  <div>
    <strong>齒輪數</strong>
    <span itemprop="numberOfForwardGears">6</span>
  </div>
  <div itemprop="vehicleEngine" itemscope itemtype="http://schema.org/EngineSpecification">
    <div>
      <strong>引擎</strong>
      <span itemprop="name">1.1 L SQR472F I4 DOHC 16v — 50 kW at 6000 rpm, 90 N·m at 3500 rpm</span>
    </div>
  </div>
  <div>
    <strong>氣囊數</strong>
    <span itemprop="airbags">4</span>
  </div>
</div>

RDFa, Microformats 與 JSON-LD

結構化數據在 Microdata 出來之前就已經有了,比如 RDFa,比如 Microformats。Microdata 正是站在他們肩膀上,總結他們的得失利弊發展起來的。
Schema.org 的示例通常包含 Microdata,RDFa 與 JSON-LD 格式。RDFa 主要引入了 vocab, typeof 與 property 作為 attributes。這裡不再談 RDFa 的格式與實現,推薦使用 Microdata。但是需知 RDFa 仍然在被使用,比如豆瓣網,因為創建時間早,又沒有升級代碼,仍然使用著 RDFa,他們使用的字典集是 http://www.data-vocabulary.org/。
Microformats 已經十年了,這是一套使用 class 輔以其它屬性來標記事物的方案。比如這篇文章的這個頁面亦使用 Microformats 做了標注,類型是 hentry。Microformats 現在推出了 2.0 版本,預測支持性不會太好,但是仍然值得一讀,當作指導前端的 class 命名也不錯。正在使用的 hentry 是 1.0:
<div class="hentry">
  <h1 class="entry-title">前端的基礎修養:Microdata</h1>
  <div class="entry-content">...</div>
  ...
</div>
JSON-LD 誕生的時間更晚,是一套使用 JSON 格式標注數據的方案。最大的優點是 JSON 格式便於解析,缺點是數據冗余,尤其是在需要 HTML 展示大段內容的情況下。

Microdata & Schema.org 的現狀與未來

目前 Google, Bing, Yandex, Yahoo! 都支援 Microdata,但是進度不一效果不一,支援度最好的還是 Google。據說百度也是支持的。
各個搜索引擎商的接入文檔:
結構化的數據不僅僅能被這些 Web 搜索引擎使用,還能被諸如 Siri, Cortana 等語音設備使用,當然,他們也能被當作搜索引擎。例如我問 Siri 最近有什麼電影可看,於是找到了《模仿遊戲》
Siri 展示的模仿遊戲

這個內容來自爛番茄,爛番茄的網頁有使用 Schema.org 的 Microdata 標注,不知道 Siri 是否解析了 Microdata,還是專門為爛番茄作了解析。

再次詢問 Siri 附近吃飯的地方,返回了大眾點評的數據:

Siri 展示的餐廳列表

查看大眾點評的網頁,亦是使用 Schema.org 的 Microdata 標注的。

因為沒有 Android 與 Windows 手機,無法展示 Google Now 與 Cortana 的效果。查閱 Microsoft Cortana 的文檔可知其是支持 Schema.org 的。Google Now 就更不必說了。

結構化的數據在未來相當有吸引力,方便未來的各種設備接入。比如「智能廚房」,你告訴它你要做什麼菜,於是它從下廚房找到了菜譜,因為下廚房使用了結構化數據,「智能廚房」就能直接列出需要的材料與材料的份量。

目前正在應用的點有很多,比如日曆、地圖、郵件等。尤其值得一提的是郵件,這個古老的通訊方式也許會在結構化數據下煥然一新。Gmail 已經在做一系列嘗試了,比如從郵件里提取出你的行程以及日程安排,比如匯總你的收據。

索引


Gmail 的部分没有细写,其实删掉了不少内容,不然看着就像 Google 家的软文了。不过文中提到的链接都能点开看看的话,应该就能了解了。


台南市政府與寶可夢的合作過程

零授權金的合作,帶來 3 億元商機!

11 月 1 日~5 日,台南市政府和寶可夢手遊的開發商 Niantic 合作,舉辦《Pokémon GO Safari Zone in Tainan》,這是暨今年 2 月的嘉義燈會之後,「精靈寶可夢」第二次在台灣舉辦大型活動。活動期間從早上 10:30 到下午 4:30 在大台南地區釋放稀有寶可夢,例如代表台南的「T.A.I.N.A.N. Z.O.N.E.」的未知圖騰,以及紐西蘭限定的「古空棘魚」等等。

「我們很早就看到遊戲觀光的趨勢,也希望觀光與數位科技有更多的結合。」台南市政府觀光旅遊局局長王時思表示。2016 年台南市觀光局就已經和 Niantic 接上線,洽談另一款虛擬實境遊戲 Ingress 的合作,成功讓台南成為 Ingress 在全球兩日活動的亞太區主場之一。

由於上次的合作讓雙方留下良好印象,所以當寶可夢熱潮席捲全球時,台南市也積極接洽,希望再次複製虛擬實境遊戲與城市景點結合的模式,帶動城市觀光。換句話說,這場寶可夢活動已經布局兩年。活動辦成一定會有觀光經濟效益,王時思只有一個要求,不要把活動集中在一個地點,最後整個大台南地區皆納入抓寶範圍,其中台南市有 30 個景點區都會出現出乎意料的寶可夢。

和 Niantic 的合作學到的事:想經營一個品牌,要足夠龜毛

和 Niantic 的合作,王時思得到不少收穫。

第一,對於智慧財產權的重視。「Niantic 很龜毛」王時思說,「尤其是對寶可夢這個IP(Intellectual Property,智慧財產權)的保護程度。」她舉例,像是觀光局拍的宣傳影片,影片裡的人拿的道具如果和遊戲畫面相關,他們都會確認是否已申請授權等等;影片中背景出現的市景街容,即使只閃過短短 1 秒,觀眾不一定會注意,但招牌上隱含有一點點不雅字眼,他們也會斟酌再三,觀光局最後以後製塗白處理。「從他們做事的態度,讓我知道一家企業對自己品牌的經營和保護,有多少細節要注意。」

第二,活動配套是否周全。王時思指出,Niantic 辦活動時非常注重 4 個面向:第一是交通,其次是電信流量是否能負荷,接下來活動腹地與安全問題,其中 3 項和活動的人流量有關,電子訊號穩定則關乎玩家的體驗。

王時思強調,這次合作 Niantic 沒有收權利金,只希望能擴大品牌效應,因此,他們考量的會是台南是否有足夠的能力舉辦一場安全又能吸引人潮的活動。市府除了事先加派台鐵、交警、救護人員之外,也請電信業者加強現場的 wifi 通訊,而台南市政府也在奇美博物館及台南都會公園設攤與設主舞台舉辦活動。

說服住宿、伴手禮業者等加入,提高「抓寶」民眾在地消費

另一個花比較多時間溝通的,還有當地商家和提供活動場地的業主。由於寶可夢在 2016 年推出不久,全球各地都湧現抓寶風潮,連帶影響不了解的人有負面印象,府方承辦人員必須事先一一解釋。「有些人聽到『寶可夢』,就會聯想到『喪屍、瘋狂』等字眼。」

例如,這次其中的一個活動地點之一,是台南一知名觀光景點奇美博物館,對方一方面樂見引進觀光人潮,但另一方面也會擔心展品或場地遭到破壞。「我們就得先問,如果他們不希望某個地點人太多,我們就不在附近設寶可夢的道館、補給站。」

最後,王時思坦言,雖然嘉義的元宵燈會早一步成為台灣第一個舉辦寶可夢活動的地方,卻也讓他們從中學到不少的經驗。例如,不希望拜訪的人抓完寶就走,希望引導更多民眾提高在地消費。因此,台南市府這次說服了 111 家業者推出美食、住宿、伴手禮、觀光工廠、風景遊憩區等加入購物消費優惠,讓民眾有誘因留下來過夜,或增加購買商品的意願。

但是市府也得先向業者溝通、說明,這個遊戲怎麼操作,玩家會被帶到哪裡,來了之後他們會做什麼,解除業者對遊戲的負面印象,再說明這對他們的生意上的幫助,說服他們加入活動方案。據她預估,這次的活動應該可以帶來 20 萬觀光人次,若以人均消費 1500 元計算,可以帶進 3 億元的觀光效益。

CSS 排版兩大利器:Flexbox vs Grid

网页布局(layout)是 CSS 的一个重点应用。

布局的传统解决方案,基于盒状模型,依赖 display 属性 + position属性 + float属性。它对于那些特殊布局非常不方便,比如,垂直居中就不容易实现。


CSS 终极之战:Grid VS Flexbox

Flexbox 是为一维布局设计的,而 Grid 是为二维布局设计。

https://zhuanlan.zhihu.com/p/31952490
https://itw01.com/2HBQEPH.html

內容優先 vs 佈局優先

Flexbox 以內容為基礎, Grid 以佈局為基礎。



Flexbox 以內容為基礎,為一維布局而設計

https://eden-liu.com/frontend/css3-flexbox-key-points/
http://www.ruanyifeng.com/blog/2015/07/flex-grammar.html
http://www.ruanyifeng.com/blog/2015/07/flex-examples.html
https://www.oxxostudio.tw/articles/201501/css-flexbox.html
https://wcc723.github.io/css/2017/07/21/css-flex/

2009年,W3C 提出了一种新的方案----Flex 布局,可以简便、完整、响应式地实现各种页面布局。目前,它已经得到了所有浏览器的支持,这意味着,现在就能很安全地使用这项功能。

CSS3 Flexbox,是一種優於傳統 float 僅能水平流動的排版,更能做到置中、垂直與等距等等。

軸線觀念


  • 主軸:
    • justify-content
    • 可對其主軸的起點、終點或等距排列
  • 交錯軸:
    • align-items
    • 可對其交錯軸的起點、終點或置中
  • flex-direction,可改變主軸的方向性 (預設主軸是由左至右)
    • 水平
    • 垂直
    • 反轉

外層屬性

  • display:必備屬性
  • flex-flow
    • flex-direction:決定 flex 軸線
    • flex-wrap:決定換行的屬性
  • justify-content:主軸的對齊
  • align-items:交錯軸的對齊

內層屬性

  • flex
    • flex-grow:伸展比
    • flex-shrink:收縮比
    • flex-basis:絕對值
  • order:排序
  • align-self:單一物件的交錯軸對齊
接著來看一下細部的屬性介紹

flex-direction

對齊方法
  • row (default)
  • row-reverse
  • column
  • column-reverse

justify-content

主軸對齊 (外層) ,依據主軸的軸線決定物件之間的間隔方法
以下是 justify-content 所有屬性:

  • flex-start
  • flex-end
  • center
  • space-between
  • space-around
節錄:MSDN

align-items

交錯軸對齊 (外層),垂直於主軸的對齊方法

  • flex-start
  • flex-end
  • center
  • strech:拉滿整個軸線
  • baseline:與文字的行高有關係,以文字基準線來排列
節錄:MSDN

align-self

交錯軸對齊 (內層),內元件本身垂直於主軸的對齊方法

  • flex-start
  • flex-end
  • center
  • strech:拉滿整個軸線
  • baseline:與文字的行高有關係,以文字基準線來排列
以骰子布局為例子,實作所有基礎寫法範例:
http://www.ruanyifeng.com/blog/2015/07/flex-examples.html

看看Flex如何实现,从1个点到9个点的布局。有 codepen 可以查看Demo。
詳閱該文章有完整說明。



Grid 以佈局為基礎,為二維布局而設計

http://muki.tw/tech/css-grid-note/
https://blog.techbridge.cc/2017/02/03/css-grid-intro/

幾年前出現的 FlexBox 宛如神兵利器,讓我們可以擺脫這些困擾,快速進行排版,而隨著 CSS Grid 規範的出現,我們即將有更好的武器了!

CSS Grid 不是要來取代 Flexbox,他們是相輔相成的角色,flex 可以看作是 one-dimensional layout solution,CSS Grid 則是 two-dimentional layout solution,用來解決我們所有先前需要各種 hack 才能完成的頁面佈局。

不過包括 IE 在內的舊瀏覽器仍是無法支援 CSS Grid 的。

IE exist. Use Grid?
https://www.youtube.com/watch?v=7msERxu7ivg

想從設計走到前端?先了解前端在幹嘛吧!

想從設計走到前端?先了解前端在幹嘛吧!
http://muki.tw/diary/front-end-introduce/

設計的工作流程

身為一個過來人,應該說我也還正在這條路上行走,有一些心得想跟大家分享。我是從設計起家的。設計的領域又可粗分為圖示設計跟排版設計…等等,而我是屬於排版這一塊。做網頁的流程大致是:
  1. 打開 PhotoShop / Sketch 從一張空白的圖層開始做出一個網站
  2. 進切版(用 PhotoShop / Sketch 切出需要的 icon) 以及 Layout (用 HTML + CSS 做出網站)
  3. 會碰到 JS 的互動時,我能找套件就先幫忙做好,不行就放著給後端
  4. 丟給後端套程式。
如果你不是純視覺,我想你的工作流程可能跟我差不多。那,這樣不算是前端嗎?

前端的工作流程

事實上,前端沒有大家想的那麼簡單歐,不過還是有個簡易版的工作流程(俗稱「看得到」),流程大致為:
  1. 收到視覺給的設計稿(通常是 PSD 存成的 JPG 圖片檔),跟視覺討論一下了解動線
  2. 開始切版(用 PhotoShop 切出需要的 icon,可由視覺提供,也可能自己要會一點 PhotoShop) 以及 Layout (用 HTML + CSS 做出網站)
  3. 開始做出 JavaScript 互動,不管是用套件還是自己刻
  4. 跟後端配合串資料,將後端提供的資料(通常是 API) 接到網頁上,使其能順利呈現資料
(按:「看得到」意指瀏覽網頁時看到的樣子,包含網頁長相 (HTML + CSS),用滑鼠或鍵盤點選的互動 (JavaScript),我們通常也可稱之為 Prototype )

前端與設計的工作流程差異

比對一下設計的工作流程,主要的差別在於:
  • 前端不產視覺 (廢話)
  • 前端跟設計都要會 HTML + CSS 做出靜態網頁 (除非你是純視覺設計)
  • 前端要比設計懂 JS,不只會套會用,還要會寫,厲害一點的人還會自己寫 plugin
  • 前端要懂一些後端的東西,包含如何互丟、接資料,簡單來說就是要懂得如何處理 Client 端 & Server 端的訊息
(按:「純視覺設計」一職通常是大公司才會開這樣的缺,有想了解其中差異的,可以留言告訴我你想看,這樣我才有動力再寫一篇XD)
有沒有開始覺得前端很令人抖抖?光是要會刻 JavaScript,應該就有很多設計卻步了吧!更別說還要跟後端串啊~!
畢竟從以前的觀念就是,做設計的畫面比較強(右腦發達)、寫程式的人邏輯比較強(左腦發達),除非很有才,否則很難左右腦都開發的完完整整。
但也別灰心,邏輯這東西是可以被訓練的喔!也許一開始寫的很差,只會土法煉鋼;但我相信寫久了、多看別人的 code,或是有好的主管帶領你,絕對可以慢慢進步!一起加油吧。

前端要做的工作


看到這,有沒有燃起了濃濃的信心!不過前面這些還只是前端「看得到」的工作,接下來,來告訴大家什麼是前端「看不到」的工作吧。
請先看這張流傳已久、強大的前端架構圖:


哈哈,有沒有驚了一下,所謂「看得到」的部份才只是冰山一角罷了。剛剛升起的自信心是不是又被打擊了呢!
假設你只是吞了一下口水,卻還是對前端很嚮往、很有愛,還是想轉前端試試看,我最後跟大家分享一下,你可以從哪些部份開始學起。(老話重提一萬遍:這是我自己的經驗,不是每個人都適用,所以大家可以參考看看,有喜歡的就吸收,沒喜歡的也別吐嘈,但歡迎討論)

從設計走到前端,推薦的學習流程

Step.1 結構化、模組化你的 HTML/ CSS code
我覺得設計跟前端寫出來的程式碼,最大的差別就在這。前端的邏輯性很重,他們會把自己寫程式的經驗往回套到 HTML / CSS 裡,並且以模組化和用 slim, scss 等工具為樂(尤其看到 HTML / CSS 可以使用 function 或是變數,眼睛就整個亮起來 XD)。
當然,我們這群轉職者不需要強迫自己眼睛亮起來,也不需要為了跟風而去用這些工具,就我所知還是有很多前端界的大老是不用 slim, scss 取代原本的 HTML / CSS,除非你真的從裡頭找到對你有幫助的點,否則工具只是輔助,你也還是要懂 HTML / CSS 的本質流程,才能寫出好的 code。
為了友好的跟其他前端人員 co-work,以及和後端人員溝通,你要先嘗試修改自己的 HTML / CSS code 發想思維,這部份很博大精深、也很看經驗,不過還是有幾篇文章可以給大家參考:
1. 成為 CSS 團隊的一員:CSS 團隊開發的最佳實踐 / MSDN Magazine
2. CSS-Guidelines : 編寫易於管理及維護的 CSS 的指導綱要
至於 HTML 的 markup 同樣也是很多眉角可以拿出來討論,加上每個人都有自己的想法,討論個三天三夜大概也說不完。如果你不知道要聽誰的意見好,那請以「你工作團隊的意見」為優先考量,畢竟你是要跟他們一起工作,而不是跟外面的那些討論者。多討論彼此能接受的寫法,並且嘗試將其他人的寫法吸收納入,等到以後你變成有決定權的人,就可以訂套 Guildline 出來啦(好像扯太遠了XD)
Step.2 JavaScript 不得不練,一定要練!
我想這沒什麼好說的了,這就是前端吃飯的工具阿 XD,你能不練嗎?如果真的學不起來 JS,或對 JS 沒興趣,那..你可以考慮往圖示設計或純視覺前進!?

前陣子在 JSDC,Even Wu 有個演講:如何教設計師前端技術。他在裏面提到:「不要丟一本工具書給設計」,設計是視覺的動物,你要先給他看網頁特效,如果他覺得有趣,他就會自己去學、去找。


大致來說是這樣沒錯,學做網頁本來就是要有興趣 XD。但有興趣只是領進門的必要條件,打好基礎才是能學到東西的重點。所以我認為,還是要給設計一本工具書,如果你想直接看網站文件也可以啦 XD。
工具書的重點是在打基礎,沒有這些基礎,你看到有趣的特效還是只會套用。但如果你真的想走前端,至少要懂得怎麼套用、怎麼改點 function、怎麼調用變數 … 等等吧!
雖然 Even Wu 演講的時候提到的例子是以 CSS3 為例,不過不管是 HTML / CSS / JavaScript…任何程式語言,「基礎」永遠是最重要的喔!,地基不先打穩,房子倒了都不知道是什麼問題呢 XD
Step.3 學會用 Developers tools 進行網頁除錯
Developers tools (開發者工具) 這也是一定要會的!有在寫 HTML / CSS 的人對他應該都不陌生了,利用開發者工具進行網頁除錯,應該是每個人必備的技能。
而如果要往前端邁進,必須將開發者工具的使用範圍擴大,除了「Elements」之外,你要開始學習「Network」、「Timeline」、「Console」…等這些面板的運用,假設你是使用 Google Chrome,Google 有提供一系列的相關入門教學,請大家好好認真研讀!!!
就連我自己也要認真研讀呢(握拳
如果很會用開發者工具進行除錯,對於網站的製作絕對可以省時省力(想想你們以前在用「Elements」的那種愉快之心吧 XD)
Step.4 你要開始在乎網頁效能
以往身為一個設計,只要把 layout 後的網頁檔丟出去就沒你的事情了(除非套程式的時候跑版 XD),但身為一個前端,你要開始注重網頁的效能,包含網頁讀取時間、網頁大小、連線數、元件載入的時間順序…等等阿裡不達所有關於「時間」的議題;甚至也要關心網站在 mobile / PAD 的效能喔。
其實說到這我一直很疑惑,以往 56k 逼逼逼數據機連線的時代,大家網頁動輒讀取 30 秒以上都在可忍受範圍,現在頻寬愈來愈大,大家卻連 1 秒都不願意等,這反差實在讓我百思不解(個人碎碎念請忽略)
至於哪些元件會影響網頁效能呢?舉凡所有網頁檔案都會喔,每個檔案都是一個連線數,所以這也是為什麼我們要用 css sprite, lazy loading, coding optimize 等技術,就是為了讓效能變好。這裡有一篇 20 個線上測試網站速度的工具 給大家做參考,我自己首推 Pingdom Tools。
以上這些,是我自己的前端入門,所以我也推薦給各位,如果你覺得跟你的狀況雷同,不妨參考。

至於前端串後端,我倒是覺得可以慢慢來,因為反過來思考,後端也是要懂如何串前端,假使一開始不熟,可以先請教後端再慢慢補強。其他的前端工作也是一樣,都可以透過學習再慢慢加強,但我認為首重還是前面這幾點。
從設計轉前端,是一條強大且漫長的路,跨過去了就是你的;跨不過也不要氣餒,純視覺設計也是一條強大且漫長的路喔,大家一起加油吧 :)




從 CSS sprite 進化到 SVG sprite

從 CSS sprite 進化到 SVG sprite:
http://muki.tw/tech/css-to-svg-sprite/

Web Icon Font (簡稱 icon font):
https://www.oxxostudio.tw/articles/201406/css-icon-font.html

未来必热:SVG Sprite技术介绍
https://www.zhangxinxu.com/wordpress/2014/07/introduce-svg-sprite-technology/

SVG 的使用細節:
http://www.ruanyifeng.com/blog/2018/08/svg.html
https://zhuanlan.zhihu.com/p/25016633
https://github.com/YIXUNFE/blog/issues/31
https://www.oxxostudio.tw/articles/201410/svg-tutorial.html


CSS Sprite:

可以有效減少 HTTP 需求,但他終究是圖片,只要把網站等比放大,圖片就可能會失真。在現今螢幕解析度提高,以及 RWD 網站盛行的環境下,用 CSS sprite 要面對的可能就是這種失真的小瑕疵。

另外一個比較惱人的困擾,就是要把所有的 icon 排在同一張圖片,再自己算出定位,其實很麻煩。雖然可以使用 compass 這樣的 CSS 預處理器幫忙,但也不是所有人都用 compass 啊。


Web Icon Font:

好處是解決了「失真」的困擾,因為即使放大縮小,它的本質還是文字,文字放大縮小是不會失真的,可以保持它原有的清晰度。

但困擾來了,正因為他是文字,所以必須乖乖遵守文字的規範,我們常碰到的問題就是在「鋸齒」與「抗拒齒」之間徘徊,通常瀏覽器都會替文字進行抗拒齒的優化,以免放大閱讀文字時,會有凹凸不平的鋸齒狀,有的時候,某些圖標我們需要這些鋸齒,但另外一些圖片我們需要抗鋸齒,線段類的圖案、圓弧狀的圖案 … 等等,會依照不同的樣式有不同的需求。

Icon font 還有其他不方便的地方,例如受到 font-size, line-height 等等字型屬性的限制。一次要載入上百張 Icon font 的字型檔,但實際上用到的只是那幾張小圖,浪費了讀取的時間。最後還有一點是各家的 Icon font 整合不易。

補充資料:
Icon Font 導入 SVG 後,開始支援彩色圖標,通過一些技巧,支持像字體那樣,可以通過 font size 或 color 來微調。

 IcoMoon,他是一個整合眾家 Icon font 的網站,此外也支援 SVG 匯出。


SVG sprite:

在講 SVG sprite 之前,需要先簡單講一下什麼是 SVG。SVG 簡單講就是用程式碼畫圖,這句話傳達了兩個意思:一、你必須要寫程式碼;二、他是不會失真的向量圖。

SVG 圖片所有的線段(<path>)都是寫在 HTML 裡面,然後再利用 CSS 屬性去修改它的顏色、大小等樣式。

每一張圖片都有一個自己的 <path> 或者 <circle> 等屬性,通常會寫在網頁的最上方,再利用<use xlink:href="#icon-video-camera"></use>呼叫。

雖然使用 SVG 可以有效解決解析度、鋸齒 等等問題,但如果要載入多張不同的圖片,程式碼會拖得很長。為了解決這個問題,我們可以改用 SVG sprite,也就是將所有圖片存在 SVG 檔案,再從 HTML 呼叫他。

SVG sprite 實作

以 IcoMoon 網站為例,先選好你要的圖片,在匯出 SVG 之前勾選 Include Tiles (CSS Sprite)


解壓縮之後,找到sprite/目錄,裡面有一個sprite.svg,原理就跟 sprite.png 一樣,會把所有圖案排列整齊,差別在於它是向量圖,放大縮小都不會失真。

接下來只要在 HTML 載入這張 SVG 檔案,並且透過ID去呼叫對應的 icon 就可以了。

<svg class="icon" xmlns="http://www.w3.org/2000/svg">
 <use xlink:href="sprite.svg#icon-facebook"></use>
</svg>
<svg class="icon" xmlns="http://www.w3.org/2000/svg">
 <use xlink:href="sprite.svg#icon-feed"></use>
</svg>

在 xlink:href 的地方,輸入這個 svg 檔案的相對路徑,後面再寫 ID 即可,跟 CSS sprite 相比是不是簡單許多呢。我們不需要再寫 background-position 去調整他的位子,往後要新增其他的 icon,直接打開 sprite.svg 編輯就可以了!



使用 IcoMoon 的 SVG sprite 注意事項:

 IcoMoon 可以直接提供我們 SVG 的 path 程式碼,而且可以個別匯出,但如果想用 IcoMoon 做 SVG sprite,需要特別注意一件事情,就是可能需要自行修改它的 SVG 檔案。

什麼意思呢?因為 IcoMoon 把 icon 的顏色、大小都寫死在 SVG 檔案裡,這恐怕不是很好的管理方式。

以icon-facebook為例,IcoMoon 是這樣寫的:

<svg id="icon-facebook" width="32" height="32" viewBox="0 0 32 32" x="48" y="0">
<path fill="#444444" d="M26.667 0h-21.334c-2.945 0-5.333 2.388-5.333 5.334v21.332c0 2.946 2.387 5.334 5.333 5.334h10.667v-14h-4v-4h4v-3c0-2.761 2.239-5 5-5h5v4h-5c-0.552 0-1 0.448-1 1v3h5.5l-1 4h-4.5v14h6.667c2.945 0 5.333-2.388 5.333-5.334v-21.332c0-2.946-2.387-5.334-5.333-5.334z"></path>
</svg>

以下則是建議修改後的版本:

<svg>
 <symbol id="icon-facebook" viewBox="0 0 32 32">
  <path d="M26.667 0h-21.334c-2.945 0-5.333 2.388-5.333 5.334v21.332c0 2.946 2.387 5.334 5.333 5.334h10.667v-14h-4v-4h4v-3c0-2.761 2.239-5 5-5h5v4h-5c-0.552 0-1 0.448-1 1v3h5.5l-1 4h-4.5v14h6.667c2.945 0 5.333-2.388 5.333-5.334v-21.332c0-2.946-2.387-5.334-5.333-5.334z"></path>
 </symbol>
</svg>

可以發現改用 <symbol> 管理 icon,並且移除了他們固定的樣式,當然要更加結構化,可以再加上<title>或<def>等標籤。

重點在於,如果不把 IcoMoon 寫的樣式移除,我們將無法用 CSS 控制這些樣式,所以請特別記住這一點!

筆者將 IcoMoon 跟修改後的 SVG 檔案放在網站上,可以自行打開原始碼比對。



程式語言編年史

程式語言編年史原文 下面這張圖片描繪了整個程式語言的歷史。包括各種程式語言的發明人、程式語言的特點和適用領域、被什麼網站或公司使用等 (檢視 完整高清圖 )。 之所以會有那麼多不同的程式語言是因為設計程式語言的初衷不同、對語言學習曲線的追求不同、不同程式之間的執行成本差異...