SCSSがコンパイルされない原因を突き止めたものの、FVのカードの見た目は直りませんでした。結局、原因は単純なもので、メディアクエリの単位pxからpが抜けていたことでした。
この記事は、SCSSがコンパイルされない原因の続きとなっています。
FVのカードの縮小スタイルが効かなかった
LPの納品前に、SCSSのコンパイルエラーを直しました。しかし、その後も、FVのカードの見た目は崩れたままでした。
幅、余白、文字サイズ、リストの列数を狭い画面向けに縮小するスタイルが、カードに適用されていませんでした。
メディアクエリの単位がpxではなくxだった
FVのカード用のスタイルは、fv-narrowというブレークポイント名で、画面幅の条件を指定していました。ブレークポイントの名前と画面幅の条件は、$bpにまとめて定義しています。mq()というmixinが、渡された名前に対応する条件を取り出して、メディアクエリを作ります。mixinの説明は、前の記事に書いています。
$bpに定義していたfv-narrowの値は、次のとおりです。
"fv-narrow": "screen and (max-width: 1419x)",pxのpが抜けて、1419xになっていたことに気づきました。
Sassのコンパイルは通ってエラーが出ない
この書き間違いは、コンパイルエラーになりません。手元のDart Sass（Ver：1.105.1）で確認すると、エラーも警告も出ずにコンパイルが完了し、書いたとおりの1419xがCSSに出力されました。
@media screen and (max-width: 1419x) {
.card {
color: blue;
}
}コンパイルの結果だけでは、書き間違いに気づけませんでした。コンパイルエラーにならないことが、原因をなかなか見つけられなかった理由でした。
ブラウザでメディアクエリが一致するかを確かめる
単位が不正なメディアクエリは、ブラウザがエラーとして扱いません。どの幅でも一致しない条件として扱われ、中のスタイルは適用されません。
Chromeのコンソールで、画面幅が1419px未満の状態で確認しました。結果は次のとおりです。
window.matchMedia('screen and (max-width: 1419x)').matches
// false
window.matchMedia('screen and (max-width: 1419px)').matches
// truepが抜けた指定はfalse、正しい指定はtrueでした。
メディアクエリの単位の誤りをgrepで探す方法
コンパイル後のcss/style.cssに、単位がpx・em・rem以外の画面幅の指定が残っていないかを、検索で確かめられます。
案件のフォルダでターミナルを開いて、次のコマンドを実行します。Git Bashなど、bash系のターミナルの場合は、次のとおりです。
grep -nE "width: *[0-9.]+[a-z]*\)" css/style.css | grep -vE "(px|em|rem)\)"PowerShellにはgrepがないため、次のように書きます。
Select-String -Path css\style.css -Pattern 'width: *[0-9.]+[a-z]*\)' | Where-Object { $_.Line -notmatch '(px|em|rem)\)' }VS Codeの検索（Ctrl+Shift+F）では、正規表現を有効にして、次の文字列で検索します。
width: *[0-9.]+(?!px|em|rem)[a-z]*\)結果が何も出なければ、単位の誤りはありません。1419xの例では、該当する行が1行表示されます。
max()の中の0の単位を忘れた書き間違いは、CSSのmax()内の単位なしが原因でwidthが無効になったに書いています。
結論
今回の原因は、メディアクエリの単位の誤りでした。1419pxに直すだけで済みましたが、コンパイルは通り、ブラウザにもエラーが出ないため、見た目だけでは気づけません。ブレークポイントを定義したときは、実際にその幅で適用されるかを、単体で確認するようにしています。