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 的啊～
去年我在規劃 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。