HTML/CSS

まっすぐなシマシマ CSSでシマシマな縞模様（ストライプ）を作るためにパッと浮かぶのは本来グラデーションを作るために使われる background-image: inear-gradient() と background-size を使ったテクニックです。 .bg-stripe { background-image: linear-gradient(90deg, /* 90deg = to right */ black 0%, /* 黒 */ black 50%, /* 黒 */ white 50%, /* 白 */ white 100% /* 白 */ ); background-repeat: repeat; /* 縦横どちらも繰り返す */ background-size: 20px auto; /* 白・黒・縞どうしのサイズはどちらも10px(=20px÷2) */ } 範囲のうち半分（0〜50%）を黒、もう半分（50%〜100%）を白とすることで、グラデーションといいつつ境界のハッキリとしたボーダーを描画し、かつ background-size によって繰り返しグループ1回分のサイズ単位を制御することで以下のような縞模様ができます。「黒・白」で1グループなので、10pxごとの縞模様にしたければ倍の20pxが単位になります。 ※画像はイメージのため black は #999 に変更しています。 ただ、この方法では 0deg (to top )や 90deg（to right ）のように、垂直・平行でないとうまくいきません。135deg のように傾けてしまうと、以下のようなバラン型になってしまいます。これはこれで使う場面もありそうですが……。 斜めのシマシマ 垂直・平行方向にまっすぐでないシマシマを作るには頭に「repeating-」（繰り返す）を付けた repeating-linear-gradient を使います。 こちらなんとCSSのグラデーション表現が誕生した頃には既に使えるプロパティだったようで、IE（Internet Explorer）10での表示も可能なようです。 .bg-repeating-stripe { background-image: repeating-linear-gradient(135deg, black 0px, /* 黒 */ black 10px, /* 黒 */ white 10px, /* 白 */ white 20px /* 白 */ ); /* background-sizeやbackground-repeatは指定しない（auto）でも繰り返される */ } これにより単位ごとに背景をリピートする方法では難しい斜めの縞模様ができます。 つまりグラデーションの内部で繰り返しを行った状態を背景画像として提供してくれるので、サイズ指定を background-image 内で行ってしまえば、 background-size や background-repeat はデフォルトのままシマシマで埋め尽くすことができます。 もちろん「まっすぐなシマシマ」にも repeating-linear-gradient を使うことができますが、 linear-gradient の感覚でサイズやリピートを指定してしまうと「外」と「内」の二重で繰り返しが発生してしまい、うまくいかないので注意してください。 失敗例 100%まで繰り返しているため、 linear-gradient と同じになってしまう例 .bg-repeating-repeating-stripe { background-image: repeating-linear-gradient(135deg, /* 90deg = to right */ black 0%, /* 黒 */ black 50%, /* 黒 */ white 50%, /* 白 */ white 100% /* 白 */ ); background-repeat: repeat; /* 内部でもう繰り返してるのに外からも繰り返す */ background-size: 20px auto; /* linear-gradientと同じ結果になる */ } サイズを制限してしまい二重に繰り返すことで表示が刻まれてしまう例 .bg-repeating-repeating-stripe { background-image: repeating-linear-gradient(135deg, /* 90deg = to right */ black 0px, /* 黒 */ black 10px, /* 黒 */ white 10px, /* 白 */ white 20px /* 白 */ ); background-repeat: repeat; /* もう繰り返してるのにもう一回繰り返す */ background-size: 20px auto; /* 斜めの時点で縞のサイズ≠背景の繰り返し幅のためズレる */ } また repeating- による繰り返しグラデーションは他のグラデーション形式にも対応しており、 repeating-radial-gradient repeating-conic-gradient も同様に利用できます。円形のストライプを使う機会なんてかなりサイケデリックな場面しかなさそうですが……🌀 使う頻度に対して対応環境が思った以上に広くてびっくりしたプロパティでした。（きちんとやるなら三角関数的な計算は必須です） せっかくの午年ですしシマシマを作りたいときは積極的に活用していきましょう！

課題 よくある「トップページに戻る」ボタンが画面固定されている場合について、自分がページトップにいれば非表示（非活性）・いなければ表示（活性）するようにしたい。 問題 もっとも容易に考えられる条件はY方向のスクロール値 window.scrollY が「ゼロか」「ゼロでないか」の時である。 つまりスクロールイベントが発生するたびに window.scrollY === 0 かを判定すればよいのだが、 window.addEventListener(’scroll’, … ) はご存知の通り（？）悪名高く、DebounceやThrottleといったテクニックがないと不要なスクロール処理が過剰発生することで知られている。 ただ、これらの「処理を間引く」ためのテクニックを使った場合、間引いているために少し反応が遅れて見えてしまったり細かいUI上の違和感が現れることもあり、適切でない場面もある印象。 そのため具体的な要素（ヘッダーが隠れた時）などの条件であればIntersection Observerで監視してあげるのがスマートでよいのだが、「ページトップか」を判断するにはそのためだけに見えない1pxの要素をページの一番上に置いて〜などのハックを使うことになるため少し煩わしい。 タイトル通りやりたいのはただ自分がページトップにいるかどうかを判定したいだけなのに……。 解決 アクセスした時点では活性状態にしたくないため、あらかじめ「トップページに戻る」ボタンには inert 属性を付けておく。 <a href="#" id="pagetop" inert>トップページに戻る</a> ※ hidden （非表示）と違いinert （非活性）属性だけでは非表示にはならないため、別途CSSにて非表示するための記載が必要。 /* CSSアニメーションを付けたい場合は別途transitionなどを使ってください */ #pagetop[inert] { visibility: hidden; } この前提をもってJavascript上で #pagetop の表示・非表示＝ inert の真・偽を切り替える。 function pagetopToggle() { let ticking = false; const pagetop = document.querySelector('#pagetop'); window.addEventListener('scroll', function() { if (!ticking) { window.requestAnimationFrame(function() { // 画面のフレームレートに応じて処理を間引く const isTop = window.scrollY === 0; // scrollTop: 0ならtrue if ( pagetop.inert !== isTop ) { // isTopがinertの有無と一致しなくなった時 pagetop.inert = isTop; // ページトップ(true)かトップでないか(false)を一致させる } ticking = false; }); ticking = true; } }, { passive: true }); // 既存のスクロール処理を邪魔しない＝preventDefaultを使用しないことを明示 } もちろん window.scrollY はスクロールのたびに取得されるが、 inert の付け外し＝画面上の変更処理については「ページトップでなくなった」「ページトップに戻った」の2回のみ働くため、パフォーマンス上はIntersection Observerによる監視と同等の軽量さが得られる（はず）。 また、念のため requestAnimationFrame ないし ticking によって画面のフレームレートごとに最低限の「間引き」も行っている。おそらくこれが一番お手軽かも。 ※別解：animation-timeline 動くか試せていないのとパフォーマンス的な観点では未知数だが、CSSの animation-timeline が使えるようになればこれだけで済むらしい（すばらしすぎる……）。 ただ、現状ではFirefoxなどにpolyfillが必要なためいずれはJSでCSSをゴニョゴニョする時代も終わるのかもしれないという希望だけ……。 https://caniuse.com/mdn-css_properties_animation-timeline body { animation-timeline: scroll(); animation-range: 0 1px; } #pagetop { visibility: hidden; /* content-visibility: none; */ animation: toggle-pagetop linear both; } @keyframes toggle-pagetop { to { visibility: visible; /* content-visibility: visible; */ } }

概要 これまでVS Codeの拡張機能「Live Sass Compiler」を使用してSCSSをコンパイルしていましたが、環境（設定やバージョン）によって出力されるCSSに差分が生じる問題が発生しました。 この問題を解決し、チーム全員が同じ設定でコンパイルできるように、npm scriptsを利用した管理に移行した際の手順をまとめます。 起きていた問題 VS Codeの拡張機能設定を同じにしても、出力結果に微妙な差分が出る。 解決策：npmスクリプトへの移行 プロジェクト自体にコンパイル環境を持たせることで、OSやエディタ環境に左右されない「共通のコンパイル設定」を構築します。 1.Node.jsのバージョン設定 古いバージョン（v14など）を使用していると、最新のSass機能が使えない可能性があるため、安定したバージョンに変更します。今回は nodenv を使用してプロジェクトのローカルバージョンを指定しました。 # 現在のバージョン確認 node -v # v14.17.1 (古い) # 利用可能なバージョンを確認して切り替え nodenv versions nodenv local 20.18.2 # 切り替わったか確認 node -v # v20.18.2 # 切り替わったか確認 node -v # v20.18.2 2.Sassパッケージのインストール プロジェクトのルートディレクトリで公式の Sass（Dart Sass）をインストールします。 # package.jsonがない場合は初期化 npm init -y # Sassを開発用依存関係(devDependencies)としてインストール npm install -D sass 3.package.json にスクリプトを追加 package.json の scripts セクションにコンパイル用のコマンドを追記します。これにより、パスの設定やオプション（Source Mapの有無など）を共通化できます。 コード スニペット { "scripts": { "sass:watch": "sass --watch src/scss:dist/css --style expanded --no-source-map", "sass:build": "sass src/scss:dist/css --style compressed --no-source-map" } } --watch: ファイルの変更を監視して自動コンパイル --style expanded: 開発時に読みやすい形式で出力 --style compressed: 本番公開用に圧縮して出力 --no-source-map: 今回はソースマップを出力しない設定 4.実行方法 チームメンバーはリポジトリをクローンした後、以下のコマンドを叩くだけで全員同じ設定で監視が始まります。 # 初回のみ npm install # 監視開始 npm run sass:watch 5. .gitignore の確認 不要なファイルがリポジトリに混入しないよう、.gitignore ファイルに以下が記述されているか確認します。 node_modules .DS_Store

概要 以前、Sassのコンパイル環境をnpm scriptsで構築しましたが、今回はさらにHTMLをEJSに置き換えて、ヘッダーやフッターなどの共通パーツを効率的に管理できる環境を作ります。 1. 必要なツールのインストール EJSをコマンドラインから変換（コンパイル）するために ejs-cli を導入します。また、複数コマンドを並列実行するために npm-run-all なども合わせてインストールします。 npm install -D ejs-cli onchange npm-run-all 2. package.json の設定 package.json の scripts 部分に、EJSを変換するためのコマンドを追加します。 "scripts": { "build:ejs": "ejs-cli --base-dir src/ejs \"**/*.ejs\" --out public", "scss": "..." (今のSCSSコマンド) } 3. 「共通パーツ」と「ページ本体」の分割 header部分を_header.ejsに移動、footer部分を_footer.ejsに移動した後ページで両方を読み込みます。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>トップページ</title> <link rel="stylesheet" href="/css/style.css"> </head> <body> <%- include('_header') %> <main> <p>ここがメインコンテンツです。管理が楽！</p> </main> <%- include('_footer') %> </body> </html> 4. ページごとにタイトルやJSを動的に変える include する際にオブジェクトを渡すことで、ページごとにタイトルや読み込むJSファイルを制御できます。 _header.ejs（タイトル制御）： <% let titleParts = []; if (typeof title !== 'undefined' && title !== '') { titleParts.push(title); } titleParts.push('サイト名'); %> <title><%= titleParts.join(' | ') %></title> 注意： 記述ミス（.の欠落やスペースの有無）で動かなくなることがあるため、EJS内のスクリプトタグは慎重に記述しましょう...。 _footer.ejs <script src="/js/common.js"></script> <% if (typeof pageJs !== 'undefined') { %> <% pageJs.forEach(function(url) { %> <script src="<%= url %>"></script> <% }); %> <% } %> 5.【重要】発生した問題と解決策 問題1：共通パーツ用のファイル（_footer.html等）が出力される_から始まるファイルは出力不要なので、package.json のコマンドで除外設定を行います。 "build:ejs": "ejs-cli --base-dir src/ejs \"**/!(_)*.ejs\" --out public", 問題2：でリンクが機能しないpublic フォルダをルートとして認識させる必要があります。 .vscode/settings.json に以下を追記します。 { "liveServer.settings.root": "/public" } 6. npm scripts の完成形 最終的な package.json の設定です。SassとEJSの「監視（watch）」を1つのコマンドで同時に実行できるようにします。 { "scripts": { "sass:watch": "sass --watch src/scss:public/css --style expanded --no-source-map", "sass:build": "sass src/scss:public/css --style compressed --no-source-map", "ejs:build": "ejs-cli --base-dir src/ejs \"**/!(_)*.ejs\" --out public", "ejs:watch": "onchange \"src/ejs/**/*.ejs\" -- npm run ejs:build", "build": "npm-run-all -p sass:build ejs:build", "start": "npm-run-all -p sass:watch ejs:watch" } } 7. チーム向けREADMEの更新 移行後は、以下のルールをチームに周知します。 開発開始： npm start を実行 ソース管理： src フォルダを編集する 画像・JS： これらは直接 public フォルダ内に配置する（※ビルドフローに入れない場合） 拡張機能： Live Sass CompilerなどのVS Code拡張機能は競合するためオフにする

みなさん、スムーススクロール（慣性スクロール）してますか。 jQueryの世界ではいにしえより伝わる以下のコードがあり、 # で始まるIDへのアンカーリンクの「スクロールがヌルっと動くため」だけにコピペで動くコードとして重宝されてきました。 $(function(){ $('a[href^="#"]').click(function(){ var speed = 400; // ページ中のどこに行くにも4秒で着く var href= $(this).attr("href"); var target = $(href == "#" || href == "" ? 'html' : href); var position = target.offset().top; $('body,html').animate({scrollTop:position}, speed, 'swing'); return false; }); }); ただ近年、このようなスムーススクロールを実装したい「だけ」であれば、以下のCSS1行の記述だけで完結するようになりました。 html { scroll-behavior: smooth; /* これだけ……だが…… */ } イージング（アニメーションの緩急）やデュレーション（辿り着くまでの時間＝スピード）は各種ブラウザの取り決めに従うため調整用のオプションはありませんが、先ほどのjQueryで行っていたスムーススクロール程度の動き・要望についてはこちらのCSSのみで事足りる便利な記述です。 https://caniuse.com/?search=scroll-behavior 日本ではモバイル天下一ブラウザであるSafariについても2022年から（遅くない……？）対応しているためほぼ問題なく活用でき、実際 scroll-behavior: smooth; について調べると、滑らかなスクロールはこれだけで解決！という記事ばかり引っかかるようになりました。めでたしめでたし ……はたして本当にそうでしょうか……？ 全てのスクロールバグの生みの親 たとえばLPペライチ内でのアンカーリンクのためだけにスムーススクロールの処理を書くのは……といった程度の場合には先ほどのCSSによる置き換えが有効ではあります。 ただし、サイトの規模が大きくなるほど scroll-behavior: smooth; は実用に耐えない場面が多いです。 つまりWeb記事の通り「これだけで解決！」と単純に思って reset.css や style.css の頭なんかに書いてしまうと他プラグインとの兼ね合いが悪く、原因不明のスクロール関連バグにつまづくことが多くなり……結局便利なスムーススクロールを使えなくなってしまう場面が稀にあります。 悪さをしている事例 原因不明といいつつほとんどは先の scroll-behavior: smooth; の記述があるためなのですが、具体的には以下のような事例が挙げられます。 https://seeder.site/web/610.html Swiper.jsでいつものように無限ループさせていたら、１周目を終わろうとしていたときに高速移動している。 https://note.com/chino8234/n/n538c02cf5dd0 「アンカーリンクでTOPページの特定のセクションに飛ばそうとしたのに、なぜか毎回“次のセクション”に遷移してしまう…」 https://x.com/tak_dcxi/status/1781708160484692054?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1781708160484692054%7Ctwgr%5E6865e621c16247d4df7f699d0f88d3aa328110a0%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fwww.tak-dcxi.com%2Farticle%2Fsmooth-scroll-implementation-example%2F （https://www.tak-dcxi.com/article/smooth-scroll-implementation-example/ ） ページ遷移後にスクロールで待たせる挙動はCSSのスムーススクロールでも同じ。JSならこの挙動を無効にできるけどCSSではできない。 https://x.com/tami_design/status/1815737711099248742?s=20 GSAPのScrollTriggerとscroll-behavior: smooth;は同時に使用しない横スクロールを実装したのですがリロードや画面リサイズすると表示が崩れたりして安定しなかった… ※こちら、GSAPのアニメーションがやけに重いと思ったら原因これだったので実体験です。 主にスライダー（カルーセル）やスクロールアニメーション系のプラグイン、ページ遷移時のアニメーションによくない影響を及ぼしていることがわかります。近頃はこういったプラグインもアニメーションの軽量化のためCSS animationを活用していることが多いのですが、そちらとCSS側の「全てをスムーススクロール」させる命令が干渉・衝突しているためかと思われます。 しかも scroll-behavior: smooth; は html に当てないとその効力を発揮しないため、必ずグローバル（ページ内すべて）のスクロールに対して反映されることになり……、衝突は避けられません。これではいけませんね こういった問題が発生した時の対策も必ず「scroll-behavior: smooth;を外してCSSでスムーススクロールしない」になってしまうため、実装をラクしたサボったツケを喰らうことになります。 そこでサイトの規模が大きくなりそうだけどCSSではなく、かつjQueryにも依存しないJavaScriptでスムーススクロールするための代替コードを考えてみました。 scroll-behavior: smooth; の代替メソッド 具体的に辿り着きたい対象＝ターゲットがはっきりしている場合、JSでは scrollIntoView() というメソッドを活用することができます。こちらに behavior: "smooth" という引数を与えると、CSSで行っていたスムーススクロールと同じ動きを行うことができます。 element.scrollIntoView({ behavior: "smooth", /* CSSで指定したものと同じ振る舞い */ block: 'start' /* 上揃えの位置にスクロールする */ }); ここでいう element （または window ）がスムーススクロールで辿り着きたい対象となります。 また、この behavior: "smooth" は直接スクロール位置の座標を指定する scrollTo() メソッドでも利用することができます。 window.scrollTo({ behavior: "smooth", /* CSSで指定したものと同じ振る舞い */ top: 0 /* topからの位置が0 → ページトップへのスクロール */ }); /* 余談：scrollIntoView()で書きたい場合はelementを「document.body」とするとよいらしい document.body.scrollIntoView({ behavior: "smooth", block: 'start' }); */ どちらのメソッドであってもCSSで scroll-behavior: smooth; とした際と全く同じブラウザ側で定められた動きのスムーススクロールが行われます。 実用例 例えば冒頭のjQueryによる記載は以下のように置換できます。 const anchors = document.querySelectorAll('a[href^="#"]'); // 「#」で始まるアンカーリンクすべてを取得 anchors.forEach(anchor => { // アンカーリンクそれぞれにクリック時のイベントを設定 anchor.addEventListener('click', (e) => { e.preventDefault(); // 本来のアンカーリンク挙動によるスクロールをキャンセル const href = anchor.getAttribute('href'); if ( href === '#' || href == "" ) { // hrefが「#」のみまたは空＝ページトップに戻る場合 window.scrollTo({ behavior: "smooth", // スムーススクロール top: 0 // ページトップ }); } else { // hrefが「#◯◯◯」の場合 const target = document.querySelector(href); if (target) { // 「#◯◯◯」のID＝アンカーリンク先が見つかった場合、その位置にスクロール target.scrollIntoView({ behavior: 'smooth', // スムーススクロール block: 'start' // 上端合わせ }); } } }); }); また繰り返すようですが behavior: "smooth" によるスムーススクロールはCSSと同じくブラウザ側でスクロール挙動を行うため、 scroll-margin-top のようなCSSによるスクロール位置の調整も問題なく適用され（てしまい）ます。 シンプルな固定ヘッダー分だけずらすようであれば以下のようなクラスを用意しておけばわざわざJSでヘッダーの高さを取得してスクロール位置を計算する……などの処理は必要ありません。（固定ヘッダーの高さが幅によって可変する場合は、きちんとJSで計算する必要がありますが……） .anchor-target { scroll-margin-top: 100px; /* ヘッダーの高さ分スクロール位置をずらす */ } ※上記CSSの適用には :target 疑似要素を使う方法もありますが、今回は e.preventDefault(); によって本来のアンカーリンク挙動をキャンセルしているため、スクロールの際 # で始まるハッシュ（URLフラグメント）が付かない＝ :target 要素が機能しません。そのため仮に .anchor-target というクラスをアンカーリンクさせたいID位置に付ける想定をしています。 （他にルート相対 /#◯◯◯ で始まる場合などの考慮も場合によっては必要ですが）あくまでページ内アンカーリンクのスムーススクロール化であれば上記のJSで事足りるかと思います。 便利なプロパティほど思わぬところや実装が進んだところでのつまづきに繋がるので、スムーススクロール「だけ」の機能であっても正しく・意図した挙動になるよう心がけて実装しましょう。