Tag: css

用純 HTML + CSS 做出來的踩地雷...

一樣還是 Hacker News Daily 上看到的東西，不過這個東西主要就是趣味性為主而已。這次看到的是純 HTML + CSS 做出來的踩地雷 (Minesweeper)，沒有 JavaScript 在內：「css-sweeper from PropJockey」。

自從 HTML + CSS3 證明是 Turing-complete 後，再加上 CSS 本身又一直加各種互動性質的操作，出現這些東西好像不太意外就是了 XDDD

依照他的說明，這邊用到的 CSS 技巧主要是 Space Toggle 這個技巧 (也就是 --toggler 這個)，但試著找了對應的文獻說明居然沒翻到，有人可以給個 hint 嗎...

模擬 Windows XP 風格的 CSS

在 Hacker News 首頁上翻到的，先前提到的「模擬 Windows 98 風格的 CSS」是對 Windows 98 風格設計出的 CSS，接下來就有人也生出經典的 Windows XP 版本出來：「XP.css」。

XP.css started as a fork of 98.css (a fun project started by Jordan Scales) and is now trying to boilerplate the GUI to be able to theme it easily.

Bootstrap v5 將會拔掉對 IE 的支援

如同標題所說的，Bootstrap 打算拔掉對 IE 的支援，在 GitHub 上的 Pull Request：「v5: drop Internet Explorer support」。

當然下面可以看到有反對意見，不過基本上還是尊重 Bootstrap 團隊做的決定，另外一方面也是現在的選擇多了很多，市場自由競爭總是會看出結果的。

測了一下先前提到的「MVP.css」，本來以為只做 semantic html 的設計，純 css 應該是有機會往下支援到蠻早的版本，結果拿 IE11 一開官網，看起來還是不少東西掛掉了 XD

看起來還得再找找... 也許繼續龜在 v4？

MVP.css

看到「MVP.css — Minimalist stylesheet for HTML elements」這個，目標是只需要寫 semantic html，剩下的就交給 css 處理：

No class names, no frameworks, just semantic HTML and you're done.

這種專案主要是看樣式喜不喜歡，畢竟選這種方案主要目的就是「懶」而不是要做太多效果，之後有機會來用看看...

Google Fonts 的加速方式

這邊講的是透過 css (以及 js) 使用的 Google Fonts，作者想要改善這塊，加速網頁的速度：「Should you self-host Google Fonts?」。

作者第一個提到的技巧是個懶人技巧，只要加上 preconnect 預先把 HTTPS 連線建好，就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect，但從前後比較可以看出，整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的)：

另外一個技巧是增加 swap，讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖，然後突然字都冒出來的情況，也就是把一般在用的：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

加上 &display=swap：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

最後一招就是把字型放在自己家，差異就更大了：

另外一個好處是改善 privacy，不過好像沒特別提到...

把 BOOKWALKER 的書名完整顯示出來

從剛開始工作就有在看輕小說，但是現在住在外面租屋，實在不方便買一堆實體書，所以就弄了 iPad 在看電子書 (yeah，我對電子紙的材質還是不太喜歡，不過那是另外一回事了...)，平台的話主力就是 BOOKWALKER。

然後每次買書都會遇到很討厭的問題，最重要的集數給我顯示出來啊啊啊 (上排中間的書名，與下排左二與中間的書名)：

看起來是被 height + overflow 幹掉了，所以寫了一個 www.bookwalker.com.tw.user.css 處理，讓他不受到 height 限制冒出來 (需要安裝 Stylus (Chrome) 或是 Stylus (Firefox) 之類的套件)：

這樣總算是好了點...

HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論，無論是 HTTP/1.1 時代，或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push)，各種讓下載速度最佳化的技巧以及造成的複雜度：「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧，也就是 JavaScript 的 bundle，或是 CSS 的 Image sprites，甚至是 API 的合併，像是很多人會考慮的 GraphQL。

雖然在 HTTP/2 年代我們常說可以省下來，但這並不代表「打包」在 HTTP/2 情境下沒有效果，只是改善的幅度比較少，所以這個最佳化的技巧比起 HTTP/1.1 年代，可以放到後面一點再做，先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了)，其實繼續使用沒有太大問題...

另外是 Server Push 的情境，意外的反而可以提昇不少速度，看起來主要是少了請求的時間，所以快不少。

再來是跨網域時 CORS 的問題，在 Flash 的年代是一個 crossdomain.xml 解決，但現在的解法是多一個 OPTIONS request，反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制：「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的：

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

延遲載入 CSS 的方式

在「Simpler way to load CSS asynchronously」這邊看到的技巧，利用了 onload 與 <noscript> 的方式，達成延遲載入 CSS 的效果：

<link rel="stylesheet" href="/path/to/my.css"
      media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>

對於非必要的 CSS 可以用這樣的方式加強，看起來頗不賴... 這邊提到的方式，作者是引用「Smashing Newsletter: Issue #234」，不過查了一下發現 2015 的時候有人在 StackOverflow 上回答過：「How to load CSS Asynchronously」，不確定有沒有更早的資料...

另外一個比較新的語法是使用 rel="preload"，但支援度就不太好了，需要靠 polyfill 之類的方式補上 (於是又多了一些東西要 load)，反而不如前面提到的方式來的簡單。