ENTER or SPACE, KEYDOWN or KEYUP

前一篇文章作動行為 Activation Behavior發佈之後,卡西又做了一些測試,發現到 ENTERSPACE 的觸發時機其實不一樣:

然後我仔細測試過發現真的是這樣,而且 SPACEkeypress的狀態,就像是滑鼠按鍵按下去但是還沒放開時的樣子,然後這又讓我有點好奇起來了,仔細搜尋一番,發現 web 標準都沒有提到這個細節的定義,唯一有一點關係的是卡西也有找到的WAI-ARIA Authoring Practices Issue 610,於是我就覺得這應該和 Web 標準定義沒關係,應該是更古老的預設行為,於是改變方向改找 Windows 預設行為相關的文件,搜尋一陣子其實也找不太到東西,大概是因為 GUI 和 Windows 剛出的時候其實 www 還不知道在哪裡吧,不過後來還是找到兩篇 stackoverflow 的問答看起來是相關的:

總和這兩篇的內容,大概整理一下:

這個行為應該是 Windows 一開始的時候就如此設計的了(看起來是很難找到相關設計的文件),然後實際上和 ENTER 相關(相對)的操作其實是 ESC 鍵,ENTER 鍵代表的是直接點 default button(例如 form 的 submit、dialog 的 ok 之類的),或是可以說是執行元件預設的行為,至於 ESC 鍵則是取消,不過取消在網頁的控制元件中幾乎是不存在的,過去有的大概只有<select>展開下拉選單後又決定不選時可以取消,到 HTML5 則又多了<dialog>有取消的行為(關閉 dialog),大概也是因為這個原因讓人忽略了 ENTERESC 的關係,變成注意到 ENTERSPACE 都可以操作元件;至於 SPACE 鍵其實就像是滑鼠點擊,keyDown如同mouseDownkeyUp如同mouseUp,要到keyUp才算一個點擊的動作,也就是到這時候才會去觸發click事件。

搞清楚這現象的原理之後,其實也就更容易理解WAI-ARIA Authoring Practices的範例那些 ENTERESCSPACE 幾個按鍵行為為什麼是那樣了,當然,以後需要客製 widget 時也不用再對這幾個按鍵的行為該怎樣定義苦惱了。


作動行為 Activation Behavior

前幾天全知全能的米奧大人在 Twitter 上徵求中階的 JavaScript 課程:

然後 Jedi 提供了一個題目:

後來米奧大人真的交作業了,也有提出一些問題,然後卡西有回應:

其中,「keyup 該觸發 button 上的 onclick」這句引起了我的興趣。

為了要顧及到網頁親和力,所有的控制元件的操作都應該要可以用鍵盤執行,所以像是 button 的動作也應該要可以用鍵盤控制,但是其實我以前一直搞不清楚,這之間正確的關係應該是怎樣,就三種可能性:

  • key 事件觸發 click 事件,click 事件有 default handler
  • click 事件觸發 key 事件,key 事件有 default handler
  • click 事件和 key 事件都有同一個 default handler

當我看到卡西那段文字的時候,我覺得他應該說的是有憑據的,不過我也覺得有些不正確,像是就我的認知,button 的 key 事件預設是不會觸發 click 事件的,於是我就花了點時間研究一下網路標準,這次終於找到規範和正確的關係了。

我先從 button 標籤開始查起,然後注意到一段,在說明 button 的activation behavior行為應該如何的文字,行為分成 submit button、reset button 和 button 三種,其中前兩個就像是在說 submit button 和 reset button 的行為一樣,所以我就了解到,activation behavior 就是我要找的關鍵字了,目前將它翻譯為「作動行為」。

然後在HTML 6.3 Activation找到:

Certain elements in HTML have anactivation behavior, which means that the user can activate them. This is always caused by aclickevent.

The user agent should allow the user to manually trigger elements that have anactivation behavior, for instance using keyboard or voice input, or through mouse clicks. When the user triggers an element with a definedactivation behaviorin a manner other than clicking it, the default action of the interaction event must be tofire aclickeventat the element.

第一段就是說作動行為(activation behavior)都是click事件觸發,第二段則是說瀏覽器要讓其它方法(像是鍵盤、語音操作等)可以觸發作動行為的話,實做的方法應該是在該事件的處理器(event handler)內觸發click事件來觸發該 HTML 元素的作動行為。這段文字就可以證明卡西說的基本上沒錯,另外就是我有疑惑的,應該是keydown還是keyup事件呢?根據我自己的實驗結果應該是要用keydown,不過總還是想找一下標準定義的出處,雖然沒有找到很明確的文字說明,不過UI Events 3.5. Activation triggers and behavior裡面的 EXAMPLE 4 內確實是寫 keydown event,當然keydown的時間點也比較符合期待,目前在不同標準文件內看到的範例也都是用 keydown。

查到這邊大概就可以確定,正確的關係應該是「key 事件觸發 click 事件,click 事件有 default handler」,不過卡西說的小錯誤是應該要用 keydown 事件,然後我在 twitter 有回說普通 button 不應該 keydown 觸發 click 則是我當時的錯誤認知(請見ENTER or SPACE, KEYDOWN or KEYUP)。

再來,其實我還很好奇,哪裡有定義不同的元素分別用哪些按鍵 active 呢?因為表單送出是用 ENTER 鍵,但是像是 checkbox 的狀態切換卻是用 SPACE 鍵;上面提供的幾份文件也都沒講到這部分的定義,有種刻意避開的感覺,後來又找了許久才終於找到,其實是放在 WAI-ARIA Authoring Practices 這份 Working Group Note 內,拿checkbox為例,在它的 Keyboard Interaction 段落內就明白寫了:

When the checkbox has focus, pressing the Space key changes the state of the checkbox.

當然也有button的規範,就是同時有定義spaceenter;由於這份文件是 Working Group Note,規範的硬性比較低,這應該也是故意為之的。

最後來整理一下,首先是 HTML 文件有定義,預設的作動行為都是透過click事件觸發,但是同時也要保留其它操作介面觸發作動行為的可能性,像是常見的鍵盤行為,而其它操作方式都要透過觸發click事件的方式來觸發作動行為;再來就是不同 HTML 元素的作動行為要做哪些事情也是在 HTML 文件內;至於不同 HTML 元素要支援哪些按鍵呢,這部分就要交叉參考ARIA in HTMLWAI-ARIA Authoring Practices兩份文件了,前者用來查詢 HTML 元素對應的 ARIA role,後者可以根據 role 來判斷要支援哪些鍵盤按鍵。

以後要做自訂的控制元件的時候,就可以正大光明的把主要的動作寫在 onclick 事件下了(然後根據情況去加上 key event)。


Circle CI run Terraform and AWS deployment

最近花很多時間在 CI,其中一個比較大的目標是跑 Terraform 加上用它輸出的 S3 name 來作為後面發佈步驟的發佈目標,然後加上不想要用第三方的 docker image 和 orbs,不過網路上都沒看到有這樣子做的範例,所以花了些時間嘗試、看文件和範例,這篇就是把一些目前的結論記錄下來:

Terraform 是用 hashicorp 官方的image,基本上就是 alpine + go + terraform 而已,shell 只有 sh 沒有 bash,不過其實 Circle CI 的一些文件看起來,他們應該是建議要使用 bash 為主,其中一個主要原因就是BASH_ENV這個環境變數有沒有支援,支援的話就可以很輕鬆的在不同 command 間傳遞環境變數了,不過還好我在 Terraform 這邊只需要寫入,還不需要讀出,所以就是 Terraform 執行完之後加一個 command 執行:

echo "export S3_ID=`terraform output s3_bucket_name`" >> $BASH_ENV

當然你的 terraform module 要有定義好 output。

第二個是重點是$BASH_ENV的值,個人建議是設定絕對路徑,直接寫出完整路徑,不要用其它環境變數來組合,然後位置要放在 working directory 內,好方便能persist_to_workspace,這樣才能夠跨 job 使用,另外就是檔名建議不要用.開頭的隱藏檔名,我遇到過各種找不到檔案的錯誤訊息,然後 working directory 建議不要放在 home 目錄下,一來$BASH_ENV去用$HOME組合出來我遇到錯誤過,用~來寫路徑也是遇到錯誤過,二來不同 image 的 home 目錄路徑不同,如果要在 config 內直接寫死絕對路徑,建議直接定一個固定的位置,我現在是用:

/tmp/workspace

然後這樣後面就可以用官方的 s3 orb 下指令了:

- aws-s3/sync:
    from: build
    to: "s3://${S3_ID}"
    aws-region: "ap-northeast-1"

COSCUP 2019

COSCUP 2019

今年發生什麼事大家都知道了,我今年負責的是 Open Web Technologies 議程軌,相對是受影響比較小的單位,不過還是想從我的角度來記錄一下,這篇就流水帳吧。

前一天晚上聽到說台科大停電的時候,還沒什麼實感,而且研揚大樓很快就恢復了,想說應該不會停太久吧,直到後來要睡前都沒有恢復才有一點緊張感,不過基本上也做不了什麼事情,還是準時去睡覺,還把龍王的工作八給看完了,隔天早上七點多醒來一看已經確定要換場地了,各管道的宣傳也開始在跑了,我就邊處理小孩的東西,先發了一封信件給今天的所有講者說場地要換大樓了,當時新教室的位置還沒出來。然後也邊跟另外一位社群協調人 hlb 聯絡,他還要從新竹出發過來,比我還早出門,後來教室確定後我又再發一封郵件,還有在 Telegram 的 Mozillians at COSCUP 2019 群(專門開給國外來參加 COSCUP 的 Mozilla 人的群)也趕快發通知,剛好那邊還有今天下午的兩位講者在裡面。

我自己本來的規劃是九點到場,後來因為確定狀況和發信等等後來有比較晚到,不過還是去採買了要給講者喝的水,我準備了一個保冷袋還加買兩包冰塊,後來冰塊到離開時都還沒融化完,可是冷卻效果不是很好,或許還是專用的保冷劑效果會比較好,另外就是有一包冰塊好像袋子還有破洞漏水。停到研揚大樓停車場的時候,竟然只能使用悠遊卡,然後一刷,只剩下 80 塊,這表示我要離開前勢必要先找地方加值了,當然,當時校內的便利商店也都停電了 ~_~

九點多到場時很感謝 hlb 都已經確認完場地狀況了,而且看起來幾乎場地都已經準備好了,雖然還有攤位沒準備完,樓下其實還一直在搬東西過來,不過真的是要讓演講開始已經完全沒問題了,像是教室指標、背版、麥克風備用電池,甚至連新印的單間會議廳的議程表都有,隔壁教室的贊助商攤位看起來也很有一回事了。

之後就都還蠻順利的,講者都有準時到,沒有開空窗,也沒有人超時卡到下一位講者,分享後互動最熱烈的那場,也剛好排在午餐前,比較可惜是我的主持還不太行,介紹講者的部分都不太好,當然週五無法先去找講者聊一下也是蠻有影響的,不過更大的因素是我自己事前準備還不夠,沒有練習好,這部分就明年繼續努力了。

今年 Open Web Technologies 下午有三位海外講者,其實都是他們各自籌經費,Mozilla 的 Rabimba 和 Bob 都是 Mozilla Tech Speaker,所以應該是從那邊申請經費的,另外一位則是 LINE 的 Trustin Lee,LINE 也是今年贊助商之一,講者的經費應該是公司出的,剛好攤位就在隔壁教室,好像也有該主題自己的攤位和其它一起從韓國來的朋友,開場前就看到他們開始在拍照,然後我才想到,像這種公司出錢來的海外講者,要是因為活動因故取消的話,人都到了不知道他們的旅費要怎麼處理,這時才第一次體會到,推廣國際能見度其實也是伴隨而來更多的責任的啊。

總之議程過程還算順利,我自己因為主持的關係幾乎離不開,只有挑了一場演講開始的時間去 HKOSC 買預計要入手的 kotties,還有去拿個人贊助的紀念品,不過我沒有拿到大會手冊就是,最後議程結束後,我就把東西收好走去長興街 7-11 儲值悠遊卡,那段時間雨還不小,回來時在一樓跟小耕打招呼,他也提到了場佈兩次的事情,我腦中就響起了這個旋律:

每條大街小巷
每個人的嘴裡
見面第一句話
場佈快不快樂

搭配音樂:

之後還在閃電講時間,我去了記錄組工作區晃了一下,還遇到不少老人回來要準備幫忙撤場,沒停留多久就回家顧小孩了,停車費 400(應該是 50 x 8 小時),大概九點弄完才有時間去找出 YouTube 直播留存的影片來看最後的閃電講和閉幕,看完覺得第二天能順利辦完真是太好了,不只是對贊助商和講者的交代,要是沒有辦起來也沒機會再次緬懷 Ilya 和阿怪了。

最後個人想法,其實我聽到要換場地的時候,我腦中倒是完全沒有懷疑過 COSCUP 團隊會辦不到,有個替代場地可以用反而是我覺得真的是撿到的,不知道為什麼一開始會先把研揚大樓的供電恢復,而且校方還能迅速幫忙協調出空間給我們用這真的是非常關鍵,如果今天在其它地方辦搞不好就真的無法找到替代空間了;然後在研揚辦的效果其實也還不錯,走道有空調真是舒適不少,第一次到台科辦的時候好像也有考慮過這個位置就是,不過大概就是因為沒有比較正式的會議廳吧。第二是 Bobchao 從前年開始推動的社群議程其實也在這次事件發揮蠻大的功效,不然整個議程相關的問題就會擠在議程組內了,現在這樣倒是可以把很多事務和權責放到外部,對我來說,其實更換場地影響沒有很大(當然是因為我到場時東西都已經準備好了,十點社群議程才開始也提供了相當充足的時間),最重要的就是確定新的會議廳位置以及想辦法通知講者,尤其是海外講者,這次我們軌三位海外講者中有兩位都有 IM 管道可以跟他們聯繫(感謝 Irvin 有先建立群組),所以我都有確定他們知道場地變動的訊息,以後也可以考慮先建立好跟講者聯繫的 IM 管道。

然後比較個人部分的感想,要顧一間做整天的主持人,幾乎都沒有機會離開啊,更不用說拍什麼照片了,其實攝影器材有帶不少但是大概用不到一半,希望以後能更多時間到場,然後可以分個半天一天做自由記錄。

最後的最後就放其它人的紀錄吧(不過目前看到的公開的只有四貓的,歡迎提供其它連結):


京都動畫公司縱火事件

#PrayForKyoani

想不到我在這個類別隔這麼的發文又是為了記錄這種事情。

今天(2019 年 7 月 18 日)京都動畫第一工作室遭縱火,目前死者 33 人,不過也有十名重傷,火災重傷後續也很辛苦,所以數字還不排除有變化的可能性。這場火災是日本近年來死傷最嚴重的縱火事件,我一早就看到消息了,然後整天就一直看著傷亡數字上升,很難受。

其實我對京阿尼還算蠻有情感的,想當年他們要開始獨立製作動畫時,還有發新聞稿,強調他們要以著重動畫品質的時候,我還想著就來看看結果會如何,結果後來就是大家所知道的,他們推出了一部又一部品質精美的動畫作品,我自己很喜歡的一張我拍的cosplay 照片的角色六花也是從他們的作品中出來的,今天我認真的查了一下我看過哪些,發現沒看過的其實沒幾部,就這樣從我大學一直到現在。這個消息在全世界動漫圈都傳很大,美國的發行商 Sentai Filmworks 還為他們發起了募款活動,本來五十萬美金的目標已經達標,現在是新目標 75 萬,#PrayForKyoani這個 hashtag 也在世界趨勢中維持在第一位一整天了。

動物朋友的監督 たつき 在 twitter 上發表了一段文字,我想很正確的表達了這件事情為什麼讓人感受這麼深:

借一下 plurk 上 AT2 的翻譯

逝世者們到底花費多少龐大且踏實的時間,在不為人知的情況下拿來做動畫。 豐富了幾萬、甚至幾億人的時間,增加了人們幸福的總指標。 為什麼這樣的人們要非得以這麼痛苦、這麼悲傷的方法離世呢

最後就是突然又想到 ZEGAPAIN 這部動畫,ZEGAPAIN 其實是 ZEGA 和 PAIN 兩個單字,意思是人類(整個人類種族)難以承受的巨大傷痛,想我當年看完這部作品心情嚴重低落三天,嚴重到我爸媽問我怎麼了,今天這件事來看好像又更能體會一點了。


➡ 看看其它文章