Chrome 10 週年

Chrome 10 Years

Chrome 10 週年 Google 真的是很精心的規劃要幫它慶祝啊,我猜大概是找了個很有狼性的 PM 來,最近一下就被發現兩個問題,第一個小一點點,就是 Clear browser data 的地方,全部清除的功能不會幫你清除 Google 的資料喔:

第二個問題比較大一點,灣區日報看到的Why I'm done with Chrome,問題就是 Chrome 69 開始,登入網頁版的 Google 服務會自動把 Chrome 瀏覽器端的 Google 帳號也登入,然後根據 Google 工程師所說,這樣還不會觸發同步備份密碼和 autofill 等隱私資料(包括密碼、信用卡資料),不過在這狀態下你很可能不小心就觸發了,由於這個機制官方沒說過,介面上也沒明顯提示,就只有大頭那邊的頭像會變,幾乎都會被使用者忽略,而會不會自動備份隱私資料只是一部份,比較嚴重的點還是這個行為是破壞使用者的信任,事情鬧出來之後 Google 有官方回應說下一版會有修改讓使用者可以關閉(不過預設還是開啟啦~~),登入後的介面也有相對應的修改讓狀態更清楚,另外就是刪除所有 Cookie 不會保留 Google 的了,以上這些修改都要等十月中的 Chrome 70。

最後就是,隨著這次事件才注意到有ungoogled-chromium這個專案啊。


Intrinsic Size 媒體寬高比

HTML 文件在編寫插入<img>時,通常都會順便加上寬高的資訊,早期這樣做除了指定圖片呈現時的大小外,還有一個好處是提升頁面繪製的速度,不用在圖片讀取好、知道實際寬高時,又重新排版重畫版面,不過這個狀況在用 CSS 設定動態寬度時,就又回到原點了,像是設定width: 100%;這種,因為沒辦法設定相對於圖片寬度的高度值,所以瀏覽器只能自己先隨便決定一個高度,等圖片抓好再重排一次。

一直以來這問題都沒好的方案處理,在排版上比較多人採用的是外面多一層 block 元素然後用padding-top來把空間先佔好,不過這也只算是個替代方案,真的要處理應該還是要從 HTML 或是 CSS 下手,然後前兩天才終於看到有個不錯的方案 Chrome 要來實做了,叫做Intrinsic Size

<img intrinsicsize="250 x 200" src="cat.jpg">

就是一個長乘寬的概念,中間那個乘號其實是小寫的x,然後提供的長寬資訊其實是等於預先給的 naturalWidth、naturalHeight,為什麼不用 aspect ratio 呢?在提案的文件裡面其實都有寫到,基本上就是這種設計提供的資訊更多,有更多好處,例如都沒設定寬高時,可以拿intrinsicsize來先用之類的,intrinsicsize目前設計只能用在圖片和影片上,Chrome預計在 71 的時候推出這個功能,也已經做好有貓測試網頁了,感覺一切都箭在弦上了,不過這新提案在 WICG 上幾乎沒討論,提案者是 WICG 也是 Chromium 成員就是,另外就是另外三家的 web platform status 都還查不到,並且,其實也有一個 CSS 的aspect-ratio提案,所以到底會怎樣還很難說啊(不過我覺得是會變標準啦)。


Extensible Web at 2018

2013 年有一份 Extensible Web 宣言,簽署人同意致力於開發 Web Platform 更底層的介面,讓開發者可以自己擴展 Web Platform,而構成 Web 介面的基本三要素其實就是 HTML、CSS、JavaScript。

其實我在當時就覺得很奇妙,我可以想像的到開發者自己擴充 HTML 標籤,不過卻想像不出來到底 JavaScript 和 CSS 要如何讓開發者擴充,沒想到今天回過頭來看,整個網路標準的發展方向真的是有在朝這方向前進,首先來看 HTML 的部分,其實就是Web Component,包括了 Custom Element、Shadow DOM、Template、HTML Import 等標準,透過這些新的 Web API,開發者很容易就可以做出可重複利用,有自訂行為的自製標籤了。

JavaScript 的部分,其實在上一篇文章介紹那一串 ES6 新功能的最後,有提到 meta programming 的新功能,雖然不是完完全全想擴充什麼就擴充什麼,但是 JavaScript 確實是慢慢的有些可以讓開發者比較深入底層的介面可以用。

最後 CSS 的部分,就是 CSS Houdini 了,Houdini 其實就是史上最偉大魔術師胡迪尼,從名稱就可以感受到這個東西有多 magic 了,其實 Houdini 不是一個標準,而是一個W3C Working Group,他們主要的目標就是建構出一整套 API 讓 CSS 可以擴充,而目前也已經有些成果了,我自己是看了去年一場演講的影片才對 Houdini 有了初步的認識:

現在最主要是已經有 Chrome 把 Paint API 實做出來,所以已經可以用 Canvas 畫圖了,雖然整個計畫離完成還要很久,不過看到 CSS 真的可以開始擴充了,還是覺得很 Magic~

Image Source:https://imgur.com/gallery/YsbKHg1


Web Platform

這篇記錄一下現在主要四個瀏覽器核心對於新標準的支援計畫的狀態網站,不然每次都要重新查。

Chrome 的應該是最多人看過,其實看過這個就能了解現在幾乎是無法從 0 開始開發一個瀏覽器了,Google Chrome 從 WebKit 的基礎開始,到現在也花了十年。


Web 前端文章廣播服務 ofrontend

frontend-news

前陣子弄了一個 web 前端文章的廣播服務,現在沒有正式的服務名稱,不過 code base 和一些帳號都叫ofrontend,所以就先這樣稱呼它吧,現在這服務有兩個末端:

會轉發的文章主要就是我看到和前端相關的為主,也會有少量其他的技術文章,大約 80% 英文、20 % 中文,不過不一定是我讀過覺得要推薦的,也是有過一些剛看標題覺得好像不錯,結果找到時間看完覺得沒什麼的文章,不介意的話可以 follow 一下。

目前資訊來源包括了:

會做這個服務有幾個原因,一個是我其實本來就有在轉發前端相關的文章連結,不過大多丟在一些非公開的地方,並且這些文章連結都沒好好整理,一直都有想找個書籤服務弄起來,然後這陣子看到灣區日報吹水 Just Share覺得也可以來做類似的傳播管道,研究和思考了好一陣子,最後決定花錢訂閱了個Pinboard服務來收集和管理連結,Pinboard 雖然介面沒找什麼設計師,看起來很陽春,不過其實他還蠻靈活的,API 很簡單可以用,不用 oauth,只要帶 token 發請求就可以,和 Telegram Bot 蠻像的,所以其實也不少工具可以用,Android、iOS、Firefox 都有,隨時看到相關的文章都可以很快的把連結丟進 Pinboard。

連結進 Pinboard 之後,就有個轉發的工具來把這連結丟去 Twitter 和 Telegram,轉發的程式也放在 GitHub 上,叫pinboardto,Python 寫的,本來有想趁機玩玩看 Rust,不過研究一下覺得還是先用 Python 把基本款弄出來,裡面東西很簡單沒什麼技術難題,並且不依靠外部儲存(資料庫、檔案),同步的機制是靠系統時間和 cronjob,所以不知什麼原因錯過就錯過了,不過因為這服務也沒有這麼要求可靠性,所以還好。

Facebook 的部分,本來有想接到 Fire-and-Forget 前端轉貼總部 去的,可是 FB 那邊弄不到永久有效的 token 就放棄。

最後成本部分,這個服務其實對我來說蠻低成本的,主要固定支出就只有 Pinboard 的年費,不過本來就要好好收集算是本來就要花,轉發服務掛在現有的主機上,最後就是 iPad 上有花錢買一個 Pinboard 的 app,不過其實也還沒有滿意就是,不知道為什麼抓 Twitter 的網頁 title 都會抓錯。


GitHub Pages Custom Domain HTTPS

GitHub Pages

等了好久終於出來的功能,追了蠻久,昨天 DK 也有提到,其實正式發佈前就看到有人已經可以用了,不過總之這篇稍微記錄一下如果已經是舊有的 GitHub Pages 還不能用可以怎麼處理,不過不完全有效,舊有的專案在設定看起來會像是:

GitHub Pages

下面有寫說因為用了 custom domain 就不能用,這時候把 custom domain 刪除,然後儲存重新加回去就會變成:

GitHub Pages

然後就等,我大概是等到隔天就有了(變成第一張圖的狀態),不過這幾天剛好完全沒空,到現在才有空檔紀錄一下。


TFN 域名轉出

dig markdown.tw,

我的 markdown.tw 在 TFN 註冊的,其實一直很想轉出,但是很怕轉的過程出意外,遲遲沒動手。不過剛剛看到 GitHub Pages 用 custom domain 也正式支援 HTTPS 了,如果是設定 A record 的話需要更新 DNS 設定,於是我就決定認真的來處理這件事,不意外的介面很難理解,決定記錄一下幫助眾生~

閱讀「TFN 域名轉出」全文

Accessibility Object Model

很久以前介紹AMP的時候,有提到標準內的 HTML attribute,都是有其意義和用途,而當然 WAI-ARIA 的那堆aria-*屬性也是,不過以前那堆東西的介面在 web 開發端是碰不到的,不過前陣子在看Chrome Platform Status的時候,發現到了一個新的標準草稿叫做Accessibility Object Model,中文可以叫做親和力物件模型吧,還很早期不過 Firefox 有一些基本實做,預設關閉,掛在他們的Accessiblity API下面。

這個標準目前規劃四個階段,目前有內容的只有前兩個,分別要做的事情是:

  1. Accessible Property,建立存取親和力相關屬性的標準界面,包括了rolearia-*,目前的草案不是直接把這些屬性放在 ElementNode 下,而是在 ElementNode 新增一個accessibleNode
  2. Accessible Action,建立和親和力相關的事件,擴充accessibleNode並且讓它會接收到這些親和力相關事件;
  3. Virtual Accessibility Node,讓開發者可以產生虛擬的accessibleNode,然後這些虛擬的 node 也有前兩個階段的能力,所以可以預期像是用 canvas 畫的介面也可以生出介面讓數位輔具可以溝通;
  4. Computed Accessibility Tree,提供 Accessibility Tree 的介面,目前,Accessibility Tree 也還是網頁開發者碰不到的。

目前這份草稿還在 WICG,不過已經開始有些實做了,除了 Firefox 之外 Chrome 也有,我看作者是 Mozilla、Google、Apple 的人都有,之後應該會慢慢發展成統一的數位輔具介面吧。


WebDriver Level 2

Chrome DevTool Protocol,

這超新的,新到其實什麼都還沒有,不過總之記錄一下,有兩條路線匯流:

第一條是 E2E 測試,E2E 測試比較早期是 Selenium 一家獨大,以前不知道是用什麼方法控制瀏覽器,就我瞭解應該不是太正規的方式,後來到 Selenium 2 開始發展 WebDriver,而且各家 browser vendor 都還蠻支持的,也朝向標準化的方向前進,標準文件現在也已經是CR了,由Browser Testing and Tools 工作小組在維護,不過看了看 mailing list,該工作小組目前活躍度好像不高。標準化的好處就是大家都可以照著做,除了 Selenium WebDriver 之外的實做,現在還有WebDriverIO這個 nodejs 環境的實做,理論上可以只用 WebDriverIO 加上瀏覽器各自的 driver 而不用透過 Selenium 來做自動化測試

另外一條路線是 remote debugging,這個一開始是為了 debug 手機上的瀏覽器,後,讓手機上的 browser 傳送訊息到桌機上,用桌機瀏覽器的開發工具來顯示資訊,方便除錯,發展到後來,變成開發工具和瀏覽器之間的溝通協定都走同一套,也就是說現在桌機瀏覽器也是用 remote debugging 同樣的溝通方式在跟自己的開發工具溝通,兩者耦合就這樣拉開了,我最早知道可以這樣拆開的是 Opera 以前的Dragonfly,然後可以想見每家瀏覽器的協定內容不一樣,然後就有一位Kenneth Auchenberg的人出來說這應該要有個標準!然後弄了個remotedebug.org,初期計畫是希望大家都有個 adapter 可以轉譯自家的協定到公用的協定,像是 Mozilla 的Valence,然後接著就開始有一些利用這些協定的各種發展,像是幫 Node 程式除錯、或是 iOS App、Electron 應用程式的除錯,甚至是除錯工具的開發也是用除錯工具自己 remote debug 自己,同時 Kenneth Auchenberg 也在推動 W3C 的標準化,一開始(約三年前)就是找上 Browser Testing and Tools 工作小組,不過一開始不太順利,因為那邊的都是自動化測試專門的人,和除錯工具關係其實不大。

Remote debug protocol 的資訊種類和訊息量其實都很大,目前看起來也只有 Google Chrome 的DevTool Protocol整理的比較完整,而 Firefox 的 Valence 其實已經沒維護了,他們的 README 上說要盡量相容 Chrome 的 protocol,這點讓我有點失望也不太意外,一來是擴充套件的API已經被 Google帶著走了,二來是 debug 用的資訊太多太雜,不好維護,而且這樣似乎也是比較快可以統一的方式。而標準化的工作其實在去年有點進展,也就是 Browser Testing and Tools 工作小組 終於接納,要把他放進 WebDriver Level 2 裡面了,這其實是去年十月底的消息,在 remotedebug 的twitter上有發消息,也有工作小組章程修改的commit連結證實,接下來就看他們要怎麼標準化了,畢竟複雜度比 WebDriver Level 1 複雜許多,還有些部分是不穩定可能隨時會變動的。



此類別所有文章