對於現在的瀏覽器,CSS 是否還需要加上 vendor prefix...

在「Do we need box-shadow or border-radius prefixes anymore?」這篇文章開頭就先給懶人包:

  • 如果沒有圓角 (border-radius) 或是陰影 (box-shadow) 會造成使用者不順。
  • 如果這四個平台 (以及瀏覽器) 的量夠大的話:Firefox 3.6-、Safari 4-、iOS 3.2-、Android 2.3-。

在這兩種情況下,你仍然需要加上 vendor prefix...

而比較長的說明,可以參考原文後半段,把這兩個效果分開說明。

如果是 Sass (SCSS) 使用者,就直接加吧,反正程式都幫你做好了... 雖然 validator 會叫 CSS 不合法,但也沒印象看過哪家瀏覽器會因為 css vendor prefix 就罷工... (真的有嗎?XD)

cdnjs (其實我要說的是 Bootstrap...)

之前曾經提過 BootstrapCDN,不過我不是很喜歡用。主要的原因包括 netdna.bootstrapcdn.com 所使用的 CDN 在是不包含亞洲範圍 (會需要到美西抓),加上之前因為換 url 結構結果本來的 url broken...

cdnjs 是之前就知道的服務,剛剛看了一下發現東西愈來愈完整了... 雖然名稱裡是放 js,但實際上上面放的 Bootstrap 是完整的:

//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/img/glyphicons-halflings.png
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/img/glyphicons-halflings-white.png
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap.min.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap-responsive.min.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap-responsive.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/bootstrap.min.js
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/bootstrap.js

剛剛在 CloudFlare 官方的 blog 上看到介紹 cdnjs 有點意外:「CDNJS: The Fastest Javascript Repo on the Web」。

翻了翻 cdnjs.cloudflare.com,看起來是包含亞洲的點,在 HiNetTWGate 上測試是導到香港的點,應該會用用看吧。至於其他 Google Hosted Libraries 有提供的應該是會用 Google 的服務,畢竟是直接從台灣的機房供應的...

修改中文維基百科的字體...

Mac 上面的中文版維基百科字體「很不友善」,沒有花太多時間看,但大概是用 font-face 改 sans-serif 造成的...

因為平常都有登入,懶得跟他囉唆,設個 css 進 User:Gslin/common.css,直接避開 sans-serif 被 font-face 惡搞掉的情況:

body {
    font-family: Helvetica;
}

這樣出來的字就好多了...

Bootstrap 2 的 CDN Hotlink

NetDNA 跳下去做 Bootstrap 2 的 CDN Hosting 了:「Bootstrap CDN - Twitter's Bootstrap hosted on NetDNA's Tier-1 Content Delivery Network」。

這項服務不包含亞洲區的 CDN PoP,從台灣 (HiNet) 或是日本 (Linode) 過去都是美西的點,不過至少有 CDN Hotlink 可以用了...

Mac 下 Google Chrome 的 textarea 預設字型...

要編輯維基百科的時候發現字寬好像不太熟悉,多看了幾個站台,發現 Google Chrome 在 Mac 下面對 textarea 預設的字型不是等寬字... 而且預設的套件沒辦法修改 :o

知道問題後,就是要找解法了... 目前的解法是裝 Stylish,對所有站台的 textarea 加上 font-family: monospace;,這樣就可以避免當網站沒有對 textarea 指定 font-family 時看起來很突兀...

Google Reader 改版,以及「自力救濟」的方法...

Google Reader 這次一改版後,在網路上可以看到一堆人抱怨到翻...

用「google reader site:userscripts.org」,然後設限 24 小時內更新的網頁,果然找到不少人試著用 Greasemonkey 寫了對應的 CSS 修改。目前看起來有兩個還不錯:

這兩個 script 在 Google Chrome 上沒問題 (沒測過 Firefox,所以不確定 Firefox 是否正常),安裝後 reload 看起來好不少...

工具類的網站還是要把空間留給資訊用,留白反而讓人不方便...

更新 blog css,加上 max-width...

本來圖片過寬會造成頁面有點亂,針對文章內的圖片補一下 max-width,不過這個屬性 IE6 就 sorry 了 XD

上一篇「IPv6 的進展,以及北美 IPv4 流量分析…」用到的圖都有超過,現在看起來應該好一些了...

微軟推出 IE6 Countdown 網站

微軟推出了 IE6 Countdown 網站,希望可以把 IE6 的佔有率壓到 1% 以下。以目前網站上更新的數字,台灣是 10.7%...

不過上面的數字是以 2011/2/28 的數據產生出來的,這天雖然是星期一,但台灣剛好是國定假日,使用公司電腦的人少很多,這使得使用 IE 的人也少很多 (可以參考 StatCounter 的數據)。如果抓平常日的數字,大約在 14% 上下,超過印度的 12.3%。

IE6 是 2001 年 8 月 27 日出版,快要滿十年了,不知道有沒有機會在十週年生日前 (七月的報表) 看到他 5% 以下...

如果可以不用管 IE6 的話,有什麼好處呢?先不論 bug 的問題,光是網頁設計時的 css selector 就多出許多可以用:(圖片來自「CSS selectors and pseudo selectors browser compatibility」)



用 IE 的 conditional comments 建立 class

IE 的 Conditional comments 可以拿來建立對應的 class,可以減少 css 使用 IE hack 的情況 (有些 IE hack 會使得 css 的語法不正確,用工具壓縮後可能會出問題),以 IE6 為例,下面的例子可以把 IE6 與 IE7 分別標上 class="ie6" 或是 class="ie7"

<!--[if IE 6]><body class="ie6"><![endif]-->
<!--[if IE 7]><body class="ie7"><![endif]-->
<!--[if gt IE 7]><!--><body><!--<![endif]-->

這個方式不需要 javascript,而且是合法的 HTML (只有 IE 會看懂 comment 內的說明)...

Protocol Preserve URI 的過濾

雖然知道 //host.domain/path 這種 Relative Protocol 用法 (而且也用很久了),不過最近在 irc.perl.org 上的 #plack 剛好有人提到,再加上最近剛好有人在探討安全性問題:「Bypassing "RequestPolicy" Using Protocol Relative URLs」,剛好可以拿出來再說一次。

簡單來說就是「以 / 開頭的 URI 並非一定是 same origin,不可以以此當作 same origin 的判斷」。因為「//ajax.googleapis.com/ajax/libs/jquery/1.5.0/jquery.min.js」這種用法是正確的用法,表示保留 Protocol。

另外講些題外話,這個用法也還是有缺點,用在 IE 的 css 時會造成重複抓取 (到 IE9 都還是):「CSS files downloaded twice in Internet Explorer with protocol relative URLs」,script 或是 relative path 都不會,只有 css 會...

反過來說,因為 js 的部份大家都沒問題,所以當使用 Google 提供的 jQuery 時,「永遠」都應該使用「//ajax.googleapis.com/...」,因為 Google Libraries API 是同時支援 HTTP 與 HTTPS 的。