回到未來

網頁在很久很久以前,是使用 HTML 來製作的,約莫過了 20 幾個年頭,現在的網頁還是 HTML 製作的。只是版本號的推演進度比較慢,目前來到 HTML5,約莫也有 6 年的發展痕跡。

胡說!網頁明明就是 FrontPage 製作的。

工具的大鳴大放大概真的是從 FrontPage 開始,然後 Dreamwaver,然後 Photoshop 也可以匯出,到現在 Sketch 的外掛工具也能幫你做好這些事情。不過,比較不一樣的是,人工介入的機會相對的變少了,當然你可能需要的一些彈性也變少了。所以,堅持使用 NotePad++ 開發的人,真的是要致上崇高的敬意。

現在要手刻網頁其實也不困難,HTML5 起手式這樣就結束了,

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>Homepage</title>
  </head>
  <body>
    <h1>Homepage</h1>
  </body>
</html>

然後打開瀏覽器就會得到一個很巨大的 Homepage 字樣的純白畫面,恭喜你第一個烘焙雞已經完成了!然後我們開始考慮一些其他的事情,諸如 SEO、社群分享、第三方套件、GA 追蹤碼等等,先不考慮我們到底網頁是長成什麼樣子。我們繼續下去就會變成,

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0">
    <meta name="HandledFriendly" content="True">
    <meta name="msapplication-TileColor" content="#190703">
    <meta name="msapplication-config" content="/static/browserconfig.xml">
    <meta name="theme-color" content="#190703">
    <meta name="keywords" content="">
    <meta name="description" content="">
    <meta name="apple-mobile-web-app-title" content="">
    <meta name="application-name" content="">
    <meta name="twitter:card" content="summary_large_image">
    <meta name="twitter:title" content="">
    <meta name="twitter:url" content="">
    <meta name="twitter:description" content="">
    <meta name="twitter:image:src" content="">
    <meta property="fb:app_id" content="">
    <meta property="og:url" content="">
    <meta property="og:type" content="website">
    <meta property="og:title" content="">
    <meta property="og:description" content="">
    <meta property="og:image" content="">
    <meta property="og:image:secure_url" content="">
    <title>Homepage</title>
    <link rel="manifest" href="/static/manifest.json">
    <link rel="shortcut icon" href="">
    <link rel="stylesheet" href="/static/css/main.min.css">
    <link rel="preload" as="style" href="/static/css/pages.min.css">
    <link rel="preload" as="script" href="/static/css/pages.min.js">
    <link rel="preload" as="font" href="/static/fonts/fontawesome-webfont.woff2" type="font/woff2" crossorigin="anonymous">
  </head>
  <body>
    <h1>Homepage</h1>
    
    <script>
      // GA
      // 略
      
      // FB
      // 略
      
      // Twitter
      // 略
    </script>
    <script href="/static/js/main.min.js"></script>
  </body>
</html>

修但幾累!為什麼寫網頁要寫這些像程式的東西?

嗯哼,容我再說一次,這些東西在這裡叫做 標籤,是一種結構化的標籤,每一種都有他自己的任務跟功能。扣掉 <script> 所包含的部分,其他的都只是結構。就如同你在玩樂高積木一樣,每一個 標籤 都是一塊特定的積木,這些積木有的有規範你一定要放在什麼位置,有的沒有。

這些積木所展現出來的樣子,取決於瀏覽器是否能正確解析你的結構,如果瀏覽器看得懂,或者他能夠理解你的結構想要表達的意思,那就沒有太大的問題。如果看不懂,那就不是一個有效的寫法。具體來講,這些標籤主要是寫給機器看的,用以告訴瀏覽器,在什麼地方要放什麼東西。

至於放的東西是不是真的會長成這個樣子,則取決於樣式表的設定。亦即,你可以決定某一個標籤能夠擁有什麼樣的樣式設定,舉例來說,在 Word 編輯器裡面,你可以決定字體大小、顏色、行距、字型爾等。我們在 HTML 裡面,透過樣式表的設定,也能夠決定那個標籤會以什麼樣的形式呈現。

但是,這些標籤的「結構」,並不一定是最終呈現在使用者面前的樣貌。我們在樣式表中,也是有可以干涉標籤的擺放位置、對齊效果跟顯示與否的設定。最終,我們在網頁上所呈現的,會是 HTML + CSS 所組合出來的樣貌。在此,我們先撇除 <script> 對於整個結構的控制或是干預,畢竟他能做到的事情有點超出 HTML 文本定義標籤的範疇。


語意化

在 HTML5 的規範中,有比較強調語意化(Semantic Elements)這件事情。也許你會覺得奇怪,這些標籤不就是寫給機器看的,為何會有語意化的事情產生?

是,標籤絕大部分是讓機器閱讀的沒錯,但,倘若能讓機器透過特定標籤,來得知你的區塊的用途、目的或文件結構,其實對於整個文件來說是加分的。講白一點,就是讓搜尋引擎能夠理解你的文件結構,對於搜尋引擎的機器人來說,相對會比較友善。

舉例來說,

<div class="header">
  <img src="logo.png" alt="Logo">
  <ul class="nav">
    <li><a href="/">Homepage</a></li>
    <li><a href="/about.html">About</a></li>
  </ul>
</div>

上面的語意結構想要表達的是:

  1. 我有一個 header 區塊。
  2. 區塊當中有一個圖片,用來放我的 Logo。
  3. 當中有一個無序清單,裡面用來放我的選單。
  4. 我的選單項目有 Homepage 跟 About 兩個頁面。

對於撰寫或是規劃這個網頁的人來說,看起來像是理所當然的事情。但是,對於機器來說,他只會知道一件事情,

這裡有個天殺的 div
然後我不知道他是做三小
裡面還有一個無序清單
我也不知道他是做三小
這個清單有一堆連結

在 HTML5 所提供的語意化標籤當中,我們可以這樣做,

<header class="header">
  <img src="logo.png" alt="Logo">
  <nav class="nav">
    <ul>
      <li><a href="/">Homepage</a></li>
      <li><a href="/about.html">About</a></li>
    </ul>
  </nav>
</header>

所以我們使用了 <header><nav> 這兩個標籤,這樣對於機器來說,就可以被這樣描述:

這裡有個 header
所以我知道這是頁面的首要區塊
裡面有一個 nav
歐這裡有一個導航列(導覽列)
這個導航列是個無序清單
導航列的連結有這些

這樣可以理解語意化標籤的用意了吧。其實最主要的目的,就是要讓搜尋引擎看得懂,或者是讓人家更好爬你的網站(欸不是。在 HTML5 的定義中,語意化標籤雖然沒有固定的使用方式,但還是有些規定,例如 <main> 在整個文件當中,只能有一個。只是,你寫兩個也沒有人會阻止你(笑


關於機器人

首先,你可以把你的網站丟到 Rich Results Test 跑跑看結果。不是說我偏好 Google,而是目前搜尋引擎的大宗就只能聽他的。所以,當你跑不出結果的時候,可能就是你給的資訊量相對太少。

為何我需要額外的資訊給「機器人」?

當然,首要的目的就是增加搜尋引擎中「被」搜索到的機會。確實,如果是精準關鍵字,或是跟 Google 下廣告,這個就另當別論,錢能解決的問題都不是問題

那麼,除了剛剛提及的語意化標籤以外,我們可以透過 JSON-LD 來提供資訊給 Google 搜尋引擎的機器人來參考。如果要用中文來描述,就是提供一個結構化資料給搜尋引擎。

這件事情跟設計師、前端工程師比較無關,他所需要面對的面向,是網站架構規劃或是設計人員需要提供相關資訊。而這些結構化資料可以操作的方式有這些,

  • JSON-LD
  • Microdata
  • RFDs

目前多數都建議使用 JSON-LD 的方式來提供,有個地方需要留意,你只需要「挑 1 種」來做就好,三個都做並不會比較強。你可以透過這個 Codelabs 來製作你的結構化資料設定。

至於誰要去研究 這些東西?這件事情實在是不好說。

我只好出賣 Paul 了!
叫做 Paul 的都炸強的!


所以說那個手機版

先把網站丟到 Mobile Friendly 是綠燈再來跟我說話。

我們這裡暫時不談版面的設計是否符合行動裝置使用,單就幾個比較明確的地方來說明。

  • 沒有設定 viewport,或是 viewport 沒有設定 device-width
  • 網頁的內容比行動裝置的畫面尺寸還要大(寬度超出畫面)。
  • 文字過小不利於閱讀。
  • 可點擊的元件過小或是距離太近。

所以我說啊,那個拿 @1x 的 iPhoneX 的 1125px 當作寬度來設計的,我直接縮小 3 倍放到手機裡面會發生什麼事情呢?

不要問,你會怕。

在樣式設定當中,會有諸如以下這些屬性,並不是沒有道理的。

  • @media screen and (max-width: 23rem)
  • @media (max-resolution: 3dppx)
  • @media (-webkit-max-device-pixel-ratio: 3)

關於尺寸這件事情,這裡有一個 古董文章 可以參考一下。如果不知道 @3x 到底是什麼意思,可以參考這一篇 對照表

所以說,以 iPhoneX 為例子,我們是以寬度 375points 來當基準點,然後最多渲染的放大倍數是 3 倍,所以可以渲染出 1125px 的寬度。然而,如果以基準點的 @1x 來看,他就僅僅只有 375px 的裝置寬度(device-width)而已。

關於 viewport 我大概 8 年前幹古過,有閒情逸致可以去看看。

[CSS] 淺談 @viewport 與 @media
[CSS3] 深入 @viewport 與 @media queries