2019

2019

2019 年的回顧也是拖很久,這次也是拖到五月了,不過基本上和去年一樣,沒有什麼拍照,所以只能做一個整年度的紀錄,這一年最大的不同就是整個年度都要照顧小孩,其實我的生活形態已經變成像是過一週算一週的方式了,每週維持一樣的生活步調,咬牙苦撐完 52 週就結束了這一年,還蠻沒有什麼過了一年的實感,不過小孩在兩歲前的成長真的是不等人,去年還在那邊爬來爬去,現在已經可以跑來跑去講一堆話了,根據我周邊同事和我的感想,小孩最可愛就是一歲半到兩歲中間這段時期了(其實有點跨到今年了),還沒有生小孩或是小孩還沒到這個年記得朋友還請把握這段時期XD

另外一件值得記錄的就是 COSCUP 還有負責辦 Open Web Technologies 議程(今年因為眾多考量就沒繼續了,留待明年再說),一開始投稿階段稿量很高,結果仔細一看發現一人多投的還不少,有點尷尬,最後選出來的海外講者也比我預期的還多,我自覺是沒有統整的很好,甚至有些 TODO 自己都沒做好,當然也是因為要照顧小還有些事情不能親自下去,而且其實意外的不好找人幫忙,像是 Moztw 社群內就找不太到人來幫忙當天的雜事,另外就是去年半下來我認為最需要避免再犯的就是在徵稿階段就需要提示主辦方對於講者能提供多少補助,像是 COSCUP 無法對講者旅費做補助,就讓兩位外國講者無法參與,我印象中其中一位是內部審稿已經過關了但是才確定不行,因為我在跟他聯絡後,該名講者也有自己去找他們公司內部的補助,不過沒有過關,如果能提早告知這個部分的資訊,應該是可以避免這個過程,也不用讓雙方都有錯誤的期待了。


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結尾的域名,搞不清楚這兩個單字的意思啊。


➡ 看看其它文章