Scroll to Text

Scroll To Text

Chrome 最近有個新功能叫做Scroll to Text Fragment,雖然在 Chrome Platform Status 網站那邊寫 M80 會可以用,不過我實際上測試正式版的 Chrome 80 還沒有,但是 Chrome Canary 已經是預設啟用了。這個功能讓你可以在網址內的 Fragment 段(#後面那段),用新定義的語法來讓瀏覽器直接捲動到指定的文字位置,語法如下:

#:~:text=[prefix-,]textStart[,textEnd][,-suffix]
          context  |-------match-----|  context

如果有在用 Chrome Canary 的可以直接試試看這個連結。這個語法其實還蠻靈活的,可以和以前 id identifier 並用:

#targetID:~:text=theText

這樣如果找不到文字,瀏覽器還可以改用 targetID 定位;如果網頁內有多個一樣的文字,可以用prefix--suffix給出前後文來讓瀏覽器找到正確的目標;再來就是如果要標註的文字很長,也可以用textStart,textEnd來標註,這樣就不用在網址內放一大串文字了;然後也可以標註多段文字,用&切開,和給參數的格式一樣:

#:~:text=firstText&text=secondText

正式的文件現在是放在 WICG 那邊,GitHub 那邊的Proposal repo則是有一段解釋為什麼選擇用:~:當分割符號的段落,我覺得這種脈絡的紀錄是很重要的,這邊簡單說一下,一開始有考慮過##這種比較容易想到形式,但是有些 URL parser 是由右到左的可能會有錯誤,再來他們列出一堆不太會有人去用的組合來當候選,然後去看 Google 那邊過去五年的紀錄,結果就是:~:最沒人用,只有 0.0000039% 的比例,所以目前是選擇這個分割符號。

我是蠻喜歡這新功能(標準?)的,Mozilla 也覺得還可以考慮看看,不過目前這個功能似乎還沒在 stable channel 啟用,應該是因為隱私問題,Chrome 負責的團隊也有整理相關的資訊,大概簡單說就是有可能透過頁面的讀取時間或是scrollTop的值來判斷你開啟的頁面內有沒有特定字串,然後就會有外洩的疑慮。另外還有一個讓人擔心的問題是這個功能可能會讓那些本來用 fragment 當成 route 的 SPA 壞掉,W3C TAG design review那邊他們自己也有提到。

其實這個 scroll to text 的功能在之前還有一套提案,不過不是由瀏覽器開發商所提,而是 indieweb 提的,叫做Fragmention,這組提案功能就比較陽春而且不成熟了:

#some%20text

重點在裡面那個%20,也就是空白字元,Freagmention 的提案是你的目標文字要有空白,因為 HTML 的 id 不能包含空白字元,所以如果有空白字元就表示不是要找 id,這個提案由我來看就是很明顯沒搞過 i18n 的啊~


W3C TAG

去年我在規劃 COSCUP 的 Open Web Technologies 的時候,有準備了一個備用的演講,題目是關於到哪裡可以追蹤到新的網路標準發展,其中的一個可以關注的資源,就是W3C TAG(Technical Architecture Group)design-reviews,我一開始其實是誤打誤撞發現這個 issue list 的,有點像是發現寶庫一樣,幾乎所有的新標準都會到這邊提出審查請求,而除了標准之外,Web 相關的比較重要的修改提案也會發到這邊來,像是最近要進行的SameSite=Lax by default,還有剛提出的Partial freezing of the User-Agent string

W3C 有一份Consortium Process Document的文件(簡稱為 Process),內容包括了 W3C 的一些基本構成,規範如何建立 Working/Interest Group 以及這些小組如何發展技術報告(Technical Report),這邊說的技術報告包括了草稿到 W3C Rec(推薦標準),除此之外,這份文件還有制訂了兩個獨立組別的構成方法,這兩個組分別為:Advisory Board(顧問團) 和 Technical Architecture Group(TAG、技術架構組),兩者都有負責解決跨技術報告(aka 標準)之間的問題,前者是負責非技術的問題,後者則是負責技術問題。W3C TAG 的成員結構現在是:

  • Tim Bernes Lee 為終生成員
  • W3C 總監
  • 總監可以提名三位成員
  • 另外有六名成員則是由 Advisory Committee(諮詢委員會,其實就是所有 W3C 會員代表人)選出

其實看他們的審查意見都覺得真的很厲害,不過這些成員的名字其實曝光都很少。然後我一直很好奇,為什麼幾乎所有的技術報告都來這邊提審查,應該是有在技術報告開發流程上寫到才會這麼多,結果那份 Process 文件找來找去就是沒找到,花了幾個小時最後終於在其中一分外連的「如何建立一個工作/興趣小組」的文件中找到,其實找 TAG 做審查是Horizontal Review(橫向審查) 的一部分,Horizontal Review 指的是技術報告在發展的過程中,找各個相關/相依的小組一起來做審查,而這些組別間的關係其實是寫在小組各自的章程裡面的,該份文件還有列出一些比較關鍵的組別:

這五個確實是非常跨技術的主題,尤其是 TAG,技術的議題都跑不掉,我也循線去其它四個小組看了一下,發現真的也有相關的審查請求,不過不同小組申請審查的管道不一樣,有的還是用 W3C 傳統的 mailing-list,TAG 已經用 GitHub 算是非常先進而且方便訂閱了,從開發者的角度如果要關心網路標準的新發展可以以這邊為主,明顯比較缺的就是 CSS 的新東西不會發到這邊,我自己是還有訂 CSS Working Group 的 issue list。

最後就是現在台灣的 W3C 會員似乎只剩下台灣數位出版聯盟,日本現在倒是很多組織有加入了,像是不知道為什麼加入的 DWANGO,看起來也沒參加 Chinese Interest Group 的Danmaku


DNS CAA record

過年前因為工作關係第一次注意到CAA record(Certification Authority Authorization) 這個東西,簡單說明就是透過 DNS record 來設定你的 SSL cert 的簽發單位白名單,一開始的規範是RFC6844,其實原理也不複雜,不過我就在遇到用 AWS ACM 簽發憑證時說檢查不過的狀況,有趣的是該 domain 沒有設定任何 CAA,搜尋研究一陣子後發現可能是因為該 domain 是 CNAME 去到別的第三方 domain 才會這樣,然後果然發現這個問題其實很久了。

不過其實原始版本的 RFC6844 其實沒有要求檢查 CNAME 目標的 CAA,而是在 2017 年的勘誤 5065中才加入的,不過這個修改造成很多問題,所以 letsencrypt 在同一年就又換回舊的實做了。CAA record 看起來也因此放棄這個修改了,在用來取代 RFC6844 的RFC8659中,就完全沒有提到 CNAME 的檢查,甚至在與舊版相異的附錄也是特別提到這點差異,不過 RFC8659 還很新,是 2019 年 11 月的,看起來 AWS 還沒修正也情有可原(?)。


Public Suffix List

最近因為花了很多時間研究 Safari 和第三方 Cookie,常常看到一個專有名詞 eTLD+1,之前只知道和 domain name 及 TLD 相關,不清楚確切的定義,所以又去查了一下,結果找到解釋最清楚的竟然是 Go 的 publicsuffix 套件的說明文件,總之簡單比較不明確的解釋,eTLD 指的是 effective TLD,像是netnet.tw這類,域名註冊商可以提供的網址後綴,依此類推,eTLD+1 就是 eTLD 再多一段,也就是一般人可以註冊到的網域名稱,像是我這邊用的othree.net,至於部落格的子網域blog.othree.net就不是 eTLD+1 了。

其中的 eTLD 又稱為 Public Suffix,然後 Mozilla 有維護一份Public Suffix List,給瀏覽器用的,主要用途就是避免寫入太高權限的 cookie,例如我要是把 cookie 寫到.net層的話,所有的.net域名的網站都會讀的到它,就會有安全性問題,這份清單現在已經是主要瀏覽器開發商都有在使用了,它的內容除了那些 eTLD 之外,其實還有私人公司提交的,像是 blogspot 列了一大串,還有 github 有列github.iogithubusercontent.comgithub.io是 GitHub Pages 的預設 domain,像我的 Github Page 就會用 othree.github.io,GitHub 提交這筆記錄,在現代瀏覽器就會限制我在othree.github.io不能寫 cookie 到github.io,這樣可以確保所有使用者的頁面不會互相影響。

我還順便亂瀏覽一下內容,發現 Amazon 手上好多的 gTLD,像是booksong,然後他們的cloudfront.net也有提交,還有一堆其它的 aws 網域名稱;另外就是 DynDNS 和 no-ip 兩個類似服務都提交超多的;然後還發現一間叫nymnom.com的域名註冊商,專門提供一堆nomnym結尾的域名,搞不清楚這兩個單字的意思啊。


Robots Exclusion Protocol

Google Webmaster Central Blog 昨天發表了Formalizing the Robots Exclusion Protocol Specification這篇文章,介紹到 Robots Exclusion Protocol (REP) 這個正在標準化的草案,REP 其實就是已經被廣泛使用的robots.txt檔案,robots.txt 誕生至今已經 25 年了,當初是由Martijn Koster所設計,早期網路的東西基本上就是先做,設計的不錯大家就跟著抄,不一定會有什麼標準的文件,robots.txt 就是這樣其實一直都沒正式的標準文件,我以前還真的有懷疑過怎麼找不到,直到 Google 這篇文章才確定了,真的一直以來是沒標準的,雖然 Google 衝網路標準太快讓人有不少意見,不過這次我倒是覺得樂觀其成,而且他們也還公開了他們的 robots.txt 的parser matcher lib

消息來源


SameSite Cookie

Cookie Time

Cookie 的規格是 RFC 文件所定義的,其實一直以來都有在演化,目前為止已經有三個版本,照順序分別是RFC2109RFC2965和最新的RFC6265,像是HttpOnly就是 RFC6265 才出現的,而最近最新的屬性,就是SameStie了,其實它和HttpOnly的起源很接近,都是近年來比較被人重視的安全性和隱私的原因,Google 的 web.dev 有一篇圖文並茂的文章介紹的很詳細-SameSite cookies explained,建議還不清楚什麼是 SameSite cookie 的可以先去看一下。

SameSite Cookie 的標準文件其實還未正式定稿,目前還算是草稿RFC6265bis(bis 在The Tao of IETF有解釋),不過主流瀏覽器都已經支援了,然後其實這篇文章我想說的是最近在 W3C TAG 看到的 Issue 373:SameSite=Lax by default,是由 Google 的 Mike West 提案要把 SameSite 的預設值改為 Lax,現在 Google Chrome 已經有這個實驗選項了,而且除了 SameSite 預設值的改變之外,其實還有一個修改目標是SameSite要在Secure的時候才能設為None,這項改變相對而言是影響比較大的,所以提案的文件(Incrementally Better Cookies)也有提到可以分步進行,另外就是 Firefox 也表示有意願來實做,看起來至少 SameSite 預設改為 Lax 這件事應該是不會太久之後就會發生了。

在花時間看一些文件內的參考資料後,發現 Mike West 還有其它幾份相關的草案:

  • first-party-set是用/.well-known/URL 來跟客戶端溝通,可以提供 first party 的域名清單;
  • First-Party Sets and SameSite Cookies利用上面的 first-party-set 資訊,然後提供兩種新的 SameSite 值:FirstPartyLaxFirstPartyStrict
  • HTTP State Tokens定義了個標準化的 session token,是由瀏覽器端產生的 token,而不是 Web API,至於怎麼傳遞到 server 端,怎樣溝通有效期等都有寫在規範內,Incrementally Better Cookies 的想法也是從這份草案中的特性而來。

這些草案都還蠻有趣的,至於會不會定稿成為規範甚至大家都開始實做,目前就還很難斷定了。


瀏覽器多樣性 Browser Diversity

前陣子大事就是微軟要放棄自家的 EdgeHTML 引擎,轉用 Chromium 專案為基礎來開發新版的 Edge Browser 了,風聲剛出來的時候,我注意到微軟官方完全沒做出回應,也沒有任何微軟員工出來講話,加上有些媒體早就發現到有 Edge 的開發成員在貢獻 Chromium,我就覺得是真的了,後來十二月六日微軟正式回應,還有一份比較長的聲明,Mozilla 也有回應,其實這件事情對於網路生態算是很大的衝擊,不過一般使用者可能沒什麼感覺,加上都沒看到中文的文章寫這件事情的影響,所以只好我來寫一下了。

首先,我講可能沒什麼公信力,所以可以直接來看一下 Google(?) 其中一集 HTTP 203 短片,標題是 Browser Monoculture,Monoculture 剛好是 Diversity 的相對,mono 是單一,單聲道或是黑白影像都是用 mono,culture 就是文化,Monoculture 的意思自然可以明白:

事實上,當微軟放棄 EdgeHTML 引擎之後,現在整個生態圈只剩下 Firefox 的 Gecko 引擎和 WebKit 家族(Safari 的 WebKit 和 Chrome 的 Blink ),而 WebKit 家族現在的市佔率已經是超過八成的獨大局面,行動裝置領域更是嚴重,如果扣除 iOS 的 Mobile Safari 則幾乎都是 Chrome 的天下了,幾乎是回到 IE 壟斷的時光,不過其實我覺得現在狀況又比那時候更險峻一點,有兩個問題:第一個是現在的 Web Platform 已經太複雜了,HTML 本身還算是單純的部分,但是各種 CSS、Web API 的推陳出新,再加上安全性、親和力、網路連線、Extensible Web 等等,到底有多少東西呢?可以參考我之前貼過的Web Platform那篇文章中Google Chrome 的 Platform Status,光這邊登記在案的,現在就有 1255 個功能,還有不少面向的東西不會列在這邊,像是效能、開發工具、WebDriver 等,其實我已經不認為現在有什麼其他第三方勢力還有辦法維護一個獨自的瀏覽器引擎了,就算是 Google 一開始也是從 WebKit,Mozilla 也是從 Gecko 來發展,微軟今天放棄繼續開發 EdgeHTML 之後,可能過一兩年就會讓它難以再次跟上標準的發展,其實微軟當年能從把 IE 重構成現在的 Edge 我覺得實在很厲害了,不過未來這種事情難度只會越來越高。

第二個是如果 Chrome 已經佔有率這麼高,它是不是可以自己開始亂搞加功能呢?就像是以前的 IE。答案其實是可以,只是現在手法已經進化了,以下舉個例子,不過先消毒,我不是指控 Google Chrome 團隊這件事是 be evil,而是假設要 be evil,這已經是可行的方法,或是換個角度,他們其實不覺得自己在 be evil,只是結果就是這樣了。

我要舉的例子是前兩週 Chrome 發表了他們支援 Background Fetch 這個新標準的消息,我第一時間反應其實是,WTF 我怎麼完全沒聽過這東西,然後我就去查查怎麼回事,然後了解到:

  1. 看介紹大概就了解這個需求確實是有的
  2. Chrome 外其他家都還沒有說要支援(根據Chrome Platform Status
  3. 標準文件的兩位編輯都是 Google 的人,主要應該是 Jake Archibald
  4. WICG那邊是去年二月也是由 Jake Archibald 提的,然後 W3C 那邊根據 blink-dev 的正向回饋就決定接收提案了

這狀況有點讓我聯想到「進化的獨裁者」,一切該有的過程其實都有,但是就都是他們的人,自己提案說有這需求,有寫好文件了,在自己家的討論區得到正向回饋,然後實做起來馬上就有市場 80% 的支援度了,這樣要不要直接算正式的網路標準了,其他家(aka Firefox)又情何以堪。事實上 Chrome 這樣衝網路標準的狀況也好一陣子了,早在 2015 年 ppk 就已經有提出對於標準發展太快的疑慮而發了一篇Stop pushing the web forward

而除了快速的發展新功能之外,還有一種狀況是擱置他們覺得不重要的 Web API 開發,然後因為已經獨大了,所以開發者就算很想要這個新的 Web API 也是無能為力,這其實也就是 HTTP 203 短片有提到的,多樣性意味著開發者有選擇的權力,而有這個力量才能讓兩邊對等。

而除了這兩個問題之外,也有人提出我之前沒想過的安全性問題,剛好就在微軟發佈消息之後沒多久就爆發出SQLite 漏洞,ZDNet 的標題提到影響到所有以 Chromium 為基礎的瀏覽器,這也是一個我之前沒想到過的問題,如果獨大的軟體有嚴重的漏洞,那一下就直接影響超多人,不過其實這次的漏洞連 Firefox 也有受影響,然後也還好不是直接可以遠端就下手的漏洞,其實佔有率高的軟體或服務都一直是駭客的目標,想必 Chromium 的 Blink 核心之後勢必會更加受到駭客關注吧。

這陣子這個圈子很多人都已經發表過看法了,像是ppkZeldman都出來發表意見,如果有人不知道這兩位是誰,趁機介紹一下,Jeffery Zeldman 是Designing with Web Standards的作者,A List Apart(A Book Apart, An Event Apart 等)和Web Standards Project的發起人,也是當年推動瀏覽器實做應該回歸網路標準的意見領袖,ppk 也是那個時期蠻活躍的,做了很多相容性測試,著有 ppk on JavaScript,當年是很棒的入門書。大部分的人其實都是針對 monoculture 論述,然後建議大家現在就開始行動,包括確保你的網站支援 Firefox、開始使用 Firefox 等等,不過 Lea Verou 有則評論則是針對那些覺得少一個瀏覽器要測試很高興的開發者,講的比較重:

至於事主之一的 Google 則就裝死當沒他的事。總之,現在雖然 Firefox 還有個 10% 左右的佔有率,光看數字還比 IE 那時候好,但是我卻覺得情勢更加險峻,很難再有新的競爭者出來,只能希望 Google don't be evil,還有 Mozilla 能夠堅持下去,真是有點想念還有五大主流瀏覽器的時候啊。


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


此類別所有文章