/* ======================================================================= 原站既有瑕疵修正（非本次遷移造成，經使用者確認後修正）。跟 inline-1~4.css 不同：那 4 份是原站 head 行內樣式的逐字照抄，這份是刻意手寫的覆蓋規則，不會被 _mirror/extract-inline.js 覆蓋。 ======================================================================= */ /* ------------------------------------------------------------------- 瑕疵：除了首頁，其他頁面的頁尾看起來都沒有貼齊視窗最下方，下面/旁邊還會多出一塊看起來不對勁的空白。這個瑕疵改了四版才定案，中間兩版方向錯了，記在這裡避免以後重蹈覆轍：第一版：以為淺橘色 #fff6e5（`.ast-page-builder-template{background-color: #fff6e5}`，掛在）是意外洩漏，把它蓋成白色。結果是錯的——這個顏色其實是全站內文背後真正的底色（Elementor 各區塊本來就沒有自己的背景，直接透出這個顏色），是每一頁正常會看到的設計，不能整個拿掉。第二版：把 `#page{min-height:100vh}` 取消，想讓頁尾直接接在內文結束處。方向也錯——取消它之後，只要視窗比實際內容高，頁尾下面會露出瀏覽器的「畫布背景」（沒設背景時，的背景色會被當成整個可視畫布的底色，範圍是整個視窗，不受自己高度限制），一樣是淺橘色，結果更明顯像沒修好。第三版：把撐開多餘空間的角色從內文區（`.site-content`）換成頁尾容器本身（`#colophon`），背景也跟著設成頁尾的灰色，想讓頁尾灰底真正貼齊視窗最下緣。這版技術上做到了「頁尾貼齊最下面」，但使用者實測後回報看起來像多了一塊突兀的灰色空方塊——灰色比淺橘色更像一個獨立的 UI 區塊，一大塊空的灰色反而更容易讓人覺得「這裡是不是壞了」。跟使用者討論後確認：那塊多餘空間**原站設計上本來就屬於內文區**（sticky-footer 的角色分工是「內文區彈性撐開、頁尾維持固定高度」），不該把它的歸屬改到頁尾去，顏色也應該維持內文區原本的淺橘色，不是頁尾的灰色。真正的根本原因（第四版）其實跟這個撐開機制無關：頁首導覽選單的下拉子選單 `.sub-menu{left:-999em;position:absolute;top:100%; visibility:hidden}`——收合時不是用 display:none，而是推到畫面極左邊再隱藏。`position:absolute` 元素的「垂直」佔位不受水平位移影響，仍算進頁面可捲動範圍：本站「投資人專區」子選單項目多、高達 1024px，導致整頁可捲動高度比實際內容多出 200 多 px。使用者捲到「瀏覽器認為的底部」時，其實已經捲進這塊完全空白的幽靈區域，看起來像頁尾沒貼齊最下面——這才是使用者反覆截圖看到的主要症狀。用 `document.querySelectorAll('.sub-menu')` 量測 bounding rect 確認最大子選單的 bottom 剛好等於 `scrollHeight`；直接在 www.ndb.com.tw 正式站測過同樣的幽靈捲動範圍也存在，確認是原站既有瑕疵。最終定案： - sticky-footer 本身（`#page` 的 `min-height:100vh` + `.site-content` 的 `flex-grow:1`）維持原站寫法，不覆蓋——多餘空間歸屬內文區、維持淺橘色，是原站設計本來的樣子。 - 只修子選單撐大可捲動範圍這個真正的瑕疵（見下方規則）。 - 內容較短的頁面（例如「公司簡介」）在夠高的視窗下，頁尾下面還是會看到一小段淺橘色留白——這是正常現象（跟全站背景色一致，只是留白），不是瑕疵，不需要再處理。 ------------------------------------------------------------------- */ .sub-menu { max-height: 0; overflow: hidden; } .menu-item.focus > .sub-menu, .menu-item:hover > .sub-menu, .sub-menu.toggled-on { max-height: none; overflow: visible; }