電子報側邊表單不要一路黏到歷史內容

整理日期：2026-06-18

狀況

一個 WordPress 電子報頁，右側有訂閱表單，左側是這封電子報會寄什麼、之後會整理什麼，以及過往發信內容。

原本想法很單純：讀者在看上半段說明時，右側表單可以固定在旁邊，方便訂閱。可是往下滑到「過往發信內容」時，表單就不應該還一路黏在右邊。

因為那一段的任務已經變了。

上半段是在說服讀者訂閱。下半段是在讓讀者先看以前寄過什麼，再自己判斷要不要訂閱。如果表單還黏著，畫面會變得太重，也會干擾歷史內容。

先拆成幾層看

這次不是「表單要 sticky」或「表單不要 sticky」二選一。

比較準確的需求是：

說明區：表單要跟著讀者往下看。
到歷史內容前：表單要自然離開視野。
歷史內容區：不要再出現右側固定表單。
文案之後會改，版面不能因為多一段或少一段文字就壞掉。

所以問題不在 sticky 本身，而是 sticky 的結束邊界要放在哪裡。

如果用標題文字、區塊高度、某一段文案位置來判斷，之後改文案很容易故障。

最後發現

一開始把歷史內容搬到訂閱區塊下面，方向是對的，但 sticky 表單的行為還不對。

常見幾種做法都會有問題：

直接取消 sticky：上半段的表單也不會跟著。
到某個位置切成 static：表單可能突然跳位。
歷史內容進入畫面就隱藏表單：看起來像表單突然消失。
用固定高度或固定 row 判斷：之後改文字、改區塊順序、換手機版寬度就容易壞。

真正缺的是一個可維護的「內容邊界」。

也就是在區塊編輯器裡，明確標記最後一段仍然屬於訂閱說明的區塊。表單只跟到那裡，到了邊界後就隨著頁面自然往上離開視野。

修正方式

做法分成三層。

第一層，在區塊編輯器裡，幫最後一個仍然屬於訂閱說明的區塊加上 class，例如：

newsletter-sticky-boundary

這個 class 不綁文案、不綁標題，也不綁固定高度。之後只要改文案，通常不會動到它。真的調整版面時，也只要把這個 class 移到新的邊界區塊。

第二層，表單本身維持 sticky。

.newsletter-form {
  position: sticky;
  top: 96px;
  transform: translateY(var(--sticky-release-y, 0px));
}

第三層，用一小段前台 JavaScript 讀實際 DOM 位置。

概念是：

找到表單。
找到 .newsletter-sticky-boundary。
讀出邊界區塊底部位置。
如果表單快要超過邊界，就用 CSS 變數把它往上推。
到歷史內容區時，表單不是被硬藏起來，而是已經自然滑出視野。

去識別化後的核心邏輯大概像這樣：

const form = document.querySelector('.newsletter-form');
const boundary = document.querySelector('.newsletter-sticky-boundary');

function updateStickyRelease() {
  if (!form || !boundary) return;

  const boundaryBottom = boundary.getBoundingClientRect().bottom + window.scrollY;
  const formHeight = form.offsetHeight;
  const stickyTop = 96;
  const scrollY = window.scrollY;
  const maxVisibleBottom = scrollY + stickyTop + formHeight;
  const releaseY = Math.min(0, boundaryBottom - maxVisibleBottom);

  form.style.setProperty('--sticky-release-y', releaseY + 'px');
}

window.addEventListener('scroll', updateStickyRelease, { passive: true });
window.addEventListener('resize', updateStickyRelease);
updateStickyRelease();

這樣之後改文案、調段落、增加一兩個區塊，只要邊界 class 還在對的位置，sticky 行為就不會跟著亂掉。

不建議先做的事

不要把表單直接藏起來。

如果表單在某個滾動位置突然消失，讀者會覺得畫面跳了一下。這不是自然離開，而是互動狀態被硬切掉。

也不要把判斷綁在「過往發信內容」這個標題上。

標題之後可能會改，內容也可能會重排。用文字當程式邏輯的錨點，維護成本會很高。

更不要靠固定高度。

這類頁面最常改的就是文案長短。固定高度一開始看起來快，之後每改一次內容都要重新試。

下次遇到可以先整理什麼

右側表單在哪個區段應該 sticky。
哪一段開始，表單應該離開視野。
這個邊界能不能用區塊 class 明確標記。
之後文案會不會常改。
手機版是否改成單欄，不需要 sticky。
表單高度是否可能變動。
是否有管理列、固定 header 或不同登入狀態造成 top offset 改變。
測試時要截三段：上半段、中間接近邊界、歷史內容區。

這類問題的重點不是把 sticky 寫出來，而是先講清楚它該停在哪裡。