雖然疫情的狀況目前尚未明朗，但是該要做的事情還是得持續下去才行。身邊絕大部分的人都已經 WFH 了，所以在家裡看一點新的東西也是挺合理的。 是說，Vue3 這件事情也不新了。很多東西 Kuro 都已經寫在書裡面，所以這邊我就不贅述太多基礎的東西。 Competition API - setup 首先，跟 2.x 最大的差異是這個。在 3.x 裡面起手式大概就 setup () 這件事情，根據官方對於這件事情的說法，大抵上的差異在於，這個 setup () 是介於
那個行動裝置 雖然我們都概括說是手機版，但 Media Query 其實支援更多裝置的呈現，只是，應該不會有人把 Switch 拿來裝瀏覽器之類的（等等還真的有）。對於 Media Query 來說，Switch 也是一種行動裝置，只是不能打電話而已。 在 Switch 上面裝 Ubuntu 所以，在整個 Media Query 所面對的，更廣泛的說法應該是 輸出裝置，例如大家很熟悉的， @media print and
Grid 與 subgrid subgrid 是一種很奇妙的跨維度設定，在 w3c 當中有詳細解釋。我這邊稍微提一下他到底是什麼樣的概念。 遵從父層格線系統，跳出現有維度形成單一欄（或行）的區塊。 子格線系統跟父層格線系統共享格線設定。 子格線系統格線總量與他所跨維度的父層格線軌跡相同。 若子網格系統跨維度軌跡固定，則取父層格線軌跡的跨度起始值。 若子網格系統跨維度不固定，則取父層格線軌跡跨度起算為 1。 子網格系統起算的 <數字> - <位置> 是獨立在自己的網格系統內。 子網格若是被填充在父層格線系統之前，那麼子網格軌跡會使用父層格線系統的格線命名，但這些名稱必須要是子網格系統以外的名字。 子網格系統的命名若跟父層格線系統重疊，
InAppBrowser 說在最前面的，以目前的 iOS / Android 生態來看，所謂的 InAppBrowser 大部分的支援程度都還算可以。最主要的差異在於使用了 JavaScript 的差異，跟真正的 瀏覽器 會有點落差。但是，對於樣式表來說，支援度基本上都還會有七八分像，至於不像的部分，那就是看 iOS / Android 給各種 App 的 WebView 是不是有什麼限制。 通常，對於一般用戶來說，在 App 裡面打開網頁這件事情很常見， 你的網站我打不開很爛耶！
Grid 還是 Flex 我們回歸到行動裝置本身，究竟我們在前端設計的時候，要採用 Grid 還是 Flex 來製作所謂的手機版？ 我認真說，如果你是 AWD 的話，用 Flex 就綽綽有餘。 如果你是採用 RWD 的話，用 Grid 或許比較方便。 當然，這些事情沒有一定的準則，不然你看看大家 Bootstrap 還不是用得很快樂，有人在意他到底是 Grid 還是 Flex 嗎？
從手機版到桌機版 講完一些基礎的 Media Query 之後，我們來看看全部都放在一起的一些情況。單就我們 前幾天 提到的狀況，在那個 .sidebar 屬於手機版或桌機版，所呈現的欄位問題來看。 .gird { grid-template-columns: repeat(auto-fit, [body] minmax(36rem, 1fr) [end]); } 一般來說從這裡開始沒有什麼太大的問題，唯一的狀況就在於，當你的 .sidebar 因為 @media 的設定而變成 columns 排列時，你的 .context-wrapper