語意化的 CSS 設定 (Contextual awareness) 減少 side effect

前幾天在 Hacker News 上看到 CSS-Tricks 上的文章「You want enabling CSS selectors, not disabling ones」這篇,在講 CSS 的設計問題,對應的 Hacker News 討論在「You want enabling CSS selectors, not disabling ones (css-tricks.com)」這邊。

文章裡面引用文章裡面提到的文章也都蠻值得看的:「You want enabling CSS selectors, not disabling ones (2021/03/08)」、「Axiomatic CSS and Lobotomized Owls (2014/10/21)」。

其中 2014 年那篇居然是 A List Apart 上的文章,好久沒看到了這個站了... 也發現居然不在 RSS/Atom feed 清單裡面,重新訂起來。

這邊拿 A List Apart 上面的圖來說明,出自「CONTEXTUAL AWARENESS」這個段落的例子。

在很多段落時,我們常使用 margin-top (或是 margin-bottom,例子可以自己變換) 來設定間距,也就是 (a) 的例子。但可以看到第一個元素就會「多出來」:

A List Apart 裡面提到的解法是 * + * (或是 p + p,看你怎麼選 CSS selector),也就是前面有相鄰的元素才需要設定 margin-top

回到 CSS-Tracks 上的文章,有些人會這樣指定 CSS (這邊用 margin-bottom,所以搭搭配的是 :last-child):

.card {
  margin-bottom: 1rem;
}

/* Wait but not on the last one!! */
.parent-of-cards :last-child {
  margin-bottom: 0;
}

也就是全部都先加上 margin-bottom,然後針對最後一個元素拿掉 margin-bottom。而另外的版本則是:

.card:not(:last-child) {
  margin-bottom: 1rem;
}

或是:

/* Only space them out if they stack */
.card + .card {
  margin-top: 1rem;
}

這樣就不用蓋來蓋去,可以降低 side effect:margin-bottom 可能會在其他地方指定,你設為 0 可能是不對的值;另外寫成兩組時 CSS 的優先順序其實是不同的,Mozilla 的 Specificity 可以參考,Specifishity 這個網站給了很有趣的 cheatsheet (你要先了解才能當 cheatsheet 用):

在文章最後面有提到 gap 這個用法,查了一下「CSS property: gap: Supported in Grid Layout」,看起來現代的瀏覽器應該是都支援了,不過如果要支援舊的瀏覽器的話就是問題...

另外順便提一下,早期大家會偏好用 + 是因為 IE7+,而 :last-child 則是 IE9+ 了:「CSS Selectors and Pseudo Selectors and browser support」。雖然現在看起都是時代的眼淚了,但可以了解一下 2014 年的時候為什麼會偏好 + 的設計。

Zoom 預設開啟密碼原因

最早的時候用 Zoom 只需要知道 meeting room 的編號就可以連進去,產生連結時也只需要提供號碼就能進去,後來 (不知道什麼時候開始的) 產生出來的連結會包括一組 token,而預設加入房間也需要密碼了。

現在知道原因了,因為被安全通報了:「Zoom Fixes Flaw Opening Meetings to Hackers」。

除了上面講到的問題以外,另外一個漏洞是本來的連結網頁就有資訊可以辨別是否為合法的 meeting room,可以讓攻擊者很快速的判斷哪些 meeting room 可以連進去。這次的修改變成不檢查,直接帶到 Zoom 的應用程式裡面,增加一些難度,但攻擊者還是可以透過 API 掃出來。

這主要是當初設計上的安全問題,當初沒有設計那麼長,應該就是考慮太長的號碼會讓使用者不太容易手動輸入...

MySQL (InnoDB) 的內部狀態

Percona 老大 Peter Zaitsev 在「MySQL – A Series of Bad Design Decisions」這篇裡提到了他認為 MySQL 設計上的問題,不過裡面也提到了不少有用的指令,平常可以先熟悉一下輸出,等真的有狀況的時候才會想起來可以用這些指令。

首先是最經典的 SHOW ENGINE INNODB STATUS,算是很多文件上面都會提到的指令。可以看 InnoDB 當下的情況,藉以猜測內部現在是怎麼卡住...

另外一個是 SHOW ENGINE INNODB MUTEX,就如同 Peter Zaitsev 所提到的,這個指令想辦法抓出最重要的資訊,但不要像 SHOW ENGINE INNODB STATUS 給了那麼多。

另外當然就是 INFORMATION_SCHEMA,他甚至希望 SHOW ENGINE INNODB 系列的指令應該要被整合進去,這樣才能用 SELECT 相關的指令整理... (因為 ORDER BY 以及蠻多的指令沒辦法在 SHOW ... 上面用)

教你怎麼設計爛 API

看到「API Practices If You Hate Your Customers」這個,在講如果你不想給客戶用 API,或是你被迫要給,你要怎麼設計這些 API XDDD

作者在文章後面有把重點整理成一張表,你也可以先看再拉回去看感興趣的細節部份:

裡面超多奇怪的技巧,像是把文件藏起來不讓 Google 搜的到之類的都出現了 XDDD

然後我發現我在接某個印度公司的 API 的時候滿滿的既視感 XDDD

謠言說蘋果要將蝴蝶鍵盤退役...

9to5Mac 的報導說 Apple 要改用剪刀式的設計:「Kuo: Apple to include new scissor switch keyboard in 2019 MacBook Air and 2020 MacBook Pro」。

取自「File:Scissor switch mechanism.svg」這頁。

Apple is apparently set to ditch the butterfly mechanism used in MacBooks since 2015, which has been the root of reliability issues and its low-travel design has also not been popular with many Mac users.

In a report published today, Ming-Chi Kuo says that Apple will roll out a new keyboard design based on scissor switches, offering durability and longer key travel, starting with the 2019 MacBook Air. The MacBook Pro is also getting the new scissor switch keyboard, but not until 2020.

還沒真的放出來前都不能確認...

對 UI Redesign 的砲火

看到「UI redesigns are mostly a waste of time」這篇,標題說明了他想講的重點... 把粗體字的部份標出來:

Just stop redesigning the UI all the time.

People use applications because of their purpose, not because it is pleasing to the eye.

The only time a UI should be updated is if it impacts the ability of a user to actually use your application.

Please stop changing everything, stop making it more work for us to relearn the applications we like to use.

Does it really add up, or are you just giving designers busywork that doesn't amount to anything in the end?

Sometimes, if we are able to do it does not mean we should.

這讓我想到 Gmail 了...

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac,而不是講 app...

這次從高雄回來,在高鐵上想說用手機看看 Trac,發現桌機版的界面是會動,但在手機上不太好用,所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用),標語是「A responsive, flat, blue theme using Bootstrap」,拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整:

裝好後用手機測了一下,還是有不滿意的地方,不過改善不少了,先這樣撐著...

HTTP/2 時代的 API 設計

在「Let’s Stop Building APIs Around a Network Hack」這邊提到了以前為了解決 HTTP/1.1 的問題而發展出來的 workaround,在 2015 年發展出來的 HTTP/2 從底層直接解了不少問題,加上很快被許多瀏覽器支援 (就算不支援 HTTP/2 也只是降到 HTTP/1.1 跑,比較慢而已):

Guess what else was released in May 2015? RFC 7540, otherwise known as HTTP/2. In retrospect this seems highly poetic, as HTTP/2 kinda makes the compound document aspect of JSON-API a little bit pointless, and compound documents to me go hand in hand with what JSON-API is as a standard.

2012 年在 MOPCON 第一屆講的「API Design Optimized for Mobile Platform」剛好就是這個主題:

有種懷念感... XD

iOS 11 的無線網路與藍芽關假的讓 EFF 不爽...

這次 iOS 11 的無線網路與藍芽需要到 Settings (設定) 裡面才能有效關掉的設計,讓 EFF 不爽寫了一篇文章:「iOS 11’s Misleading “Off-ish” Setting for Bluetooth and Wi-Fi is Bad for User Security」。

On an iPhone, users might instinctively swipe up to open Control Center and toggle Wi-Fi and Bluetooth off from the quick settings. Each icon switches from blue to gray, leading a user to reasonably believe they have been turned off—in other words, fully disabled. In iOS 10, that was true. However, in iOS 11, the same setting change no longer actually turns Wi-Fi or Bluetooth “off.”

不過藍芽的洞真的不少,儘量避免吧... +_+

Flat UI 反而造成使用者困擾

在「Flat UI Elements Attract Less Attention and Cause Uncertainty」這邊透過追蹤眼球的技術,發表了研究結果:

Summary: Flat interfaces often use weak signifiers. In an eyetracking experiment comparing different kinds of clickability clues, UIs with weak signifiers required more user effort than strong ones.

其中最明顯的一個例子就是大家被訓練「有底線的文字應該可以按」,這也是最能馬上被想到的問題... 不過這算是 Flat UI 的問題嗎?

The popularity of flat design in digital interfaces has coincided with a scarcity of signifiers. Many modern UIs have ripped out the perceptible cues that users rely on to understand what is clickable.