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


更之前的文章