Tag: safari

用 picture + source + img 替代本來的 JavaScript 替換

目前我在 blog 上使用 Imgur 的圖檔主要是用 WebP 格式，然後針對不支援 WebP 的瀏覽器 (主要就是蘋果家的 Safari) 是用 JavaScript 換回 JPEG 格式...

昨天早上看到「AVIF has landed」這篇，提醒我有 <picture> 這個原生支援的方式可以用，翻了一下 Can I Use 上面的支援程度，看起來除了 IE11 以外幾乎都支援了 (參考「Picture element」)，而且 IE11 應該也會因為語法的關係走到正確的 JPEG fallback，大概是這樣：

<picture>
    <source type="image/webp" srcset="https://i.imgur.com/xxxxxx.webp" />
    <img src="https://i.imgur.com/xxxxxx.jpg" alt="" />
</picture>

換完後來觀察看看...

WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下，WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論：提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好)，然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候，宣稱失真壓縮的部份可以比 JPEG 小 25%～34%：(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%～34% 這個數字，是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg，而如果拿 MozJPEG 相比的話應該得不到這個結果，另外也把 AV1 的 AVIF 拉進來一起測試了：

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite，測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些，但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善)，而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了：

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好，不過要注意演算法會把非重點部位的細節吃掉：

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說，WebP 另外一個痛點是在 Safari 上的支援度，在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了，就剩下 Safari 還不支援，所以目前在 iOS 上得降回 JPEG：

不過這點之後也改變了，在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了：「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...

Safari 將會禁止長效憑證 (超過 398 天，大約十三個月)

在「Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months」這邊看到的，這次是 Safari 直接發難要幹掉長效憑證。

今年九月前發的憑證是照既有的協議，最長長度是 825 天 (大約 27 個月)，但九月開始發的憑證，如果有效長度超過 398 天就會直接被 Safari 視為無效，所以大約是砍半，其他家瀏覽器不知道會不會跟進...

最早的時候可以直接買五年 (有印像是因為當年的 group.nctu.edu.tw 是我自己買的)，後來好像降到三年，最近是兩年，看起來要變成一年了...

Webkit 的「反追蹤反追蹤」功能...

第一次看到標題的時候的確是 WTF 的感覺，愈來愈感覺到大戰的開始：「Preventing Tracking Prevention Tracking」。

在蘋果的平台上有 Intelligent Tracking Prevention (ITP) 功能，但先前這個功能比較簡單，所以還是有很多地方可以被當作 browser fingerprint 的一部份分析，所以蘋果決定改善，然後在新版的軟體裡引入：

This blog post covers enhancements to Intelligent Tracking Prevention (ITP) included in Safari on iOS and iPadOS 13.3, Safari 13.0.4 on macOS Catalina, Mojave, and High Sierra.

包括了跨站台時 Referer 的省略：

ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains.

然後後面三個改善都跟 3rd-party cookie 有關，其中預設擋掉帶 cookie 的 3rd-party requests 應該會讓一些網站掛掉：

ITP will now block all third-party requests from seeing their cookies, regardless of the classification status of the third-party domain, unless the first-party website has already received user interaction.

早期自己做自家 SSO 的奇技淫巧中，會設計出透過 ajax 打多個不同的網域自動登入，看起來應該會需要檢查了...

Safari 上 uBlock Origin 的情況

uBlock Origin 在 2016 的時候 porting 到 Safari 上，但在 2018 後就沒有再更新了，維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。

主要就是蘋果要廢掉本來的 Extension API，而替代的框架裡沒有對應的 content filtering 能力，所以在新的框架內無法實做 uBlock Origin 的功能...

維護者的建議是換瀏覽器，但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞)，所以維護者的建議就是換成 Firefox。

另外我自己會建議用看看 Brave，因為 Brave 已經決定，如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3)，他們會繼續維持本來的相容性，所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。

把 Blog 上的 PNG 圖片換成 WebP 格式

WebP 格式的大小比起 JPEG 或是 PNG 都小不少，支援度也都還行，但 Safari 不支援是個大問題，因為在行動裝置裡面 iOS 還是大宗...

目前想到的方法是只對 Imgur 的圖片使用 WebP (.webp)，當遇到不支援的 WebP 的平台時透過 JavaScript 改用 PNG (.png)。

這邊有判斷有沒有支援 WebP 的程式碼出自「Detect WEBP Support with JavaScript」，用 createImageBitmap() 建看看有沒有成功：

(() => {
  let supportsWebP = async () => {
    if (!self.createImageBitmap) return false;
    const webpData = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=';
    const blob = await fetch(webpData).then(r => r.blob());
    return createImageBitmap(blob).then(() => true, () => false);
  };

  (async () => {
    if (!await supportsWebP()) {
      document.addEventListener('DOMContentLoaded', () => {
        for (let el of document.getElementsByTagName('img')) {
          let src = el.getAttribute('src');
          if (src.match(/\.webp/)) {
            el.setAttribute('src', src.replace(/\.webp/, '.png'));
          }
        }
      });
    }
  })();
})();

這邊比較有趣的是網路上的文件 (MDN 與 CanIuse) 都說 Safari 不支援 createImageBitmap()，但實際上好像沒問題 :o

然後再用 WordPress 的延伸套件「Search Regex」把所有文章理出現 /https:\/\/i\.imgur\.com/(\w+)\.png/ 的字串換成 https://i.imgur.com/$1.webp，接下來就可以拿 Safari 測試了，這樣有點 hack 但看起來還行...

Apple 將移除掉 Safari 的 DNT 功能

在「Apple Removes Useless 'Do Not Track' Feature From Latest Beta Versions of Safari」這邊看到的，看起來包括 iOS 與 macOS 都會移除：

因為沒什麼單位願意遵守，沒必要多送幾個 bytes 還順便讓廣告商可以判斷...

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac，而不是講 app...

這次從高雄回來，在高鐵上想說用手機看看 Trac，發現桌機版的界面是會動，但在手機上不太好用，所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用)，標語是「A responsive, flat, blue theme using Bootstrap」，拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整：

裝好後用手機測了一下，還是有不滿意的地方，不過改善不少了，先這樣撐著...

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

Update：Apple 也宣佈了，時間點跟大家都差不多：「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」，而 Google 也宣佈了「Modernizing Transport Security」，兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除：

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除，換算成時間會從 2020 年一月開始影響到 canary channel，到 release channel 應該跟 Firefox 差不多時間：

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援，但如果伺服器想要只支援 TLS 1.2+ 的話，就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便，替代方案也比較多)，而行動平台看起來需要 Android 4.4+、iOS 7+，就要看各網站或是服務的族群了...