Closed yuki-ohnaka-no4 closed 1 year ago
cc: @runa-sakagoshi0830
利用可能なスタイリング言語
・astro 参照: https://docs.astro.build/ja/guides/styling/
AstroはスタイリングやCSSの記述を簡単にするために設計されました。Astroコンポーネントの内部に直接CSSを記述したり、Tailwindなどのお気に入りのCSSライブラリをインポートできます。SassやLessなどの高度なスタイリング言語もサポートされています。
・svelte 参照: https://kit.svelte.jp/docs/integrations
vite-plugin-svelte には vitePreprocess という機能があり、Vite をプリプロセスに用いることができます。これによって Vite が扱える言語フレーバー (TypeScript、PostCSS、SCSS、Less、Stylus、SugarSS) の処理が可能になります。便宜上、これは @sveltejs/kit/vite パッケージから再エクスポートされています。プロジェクトに TypeScript を設定すると、これがデフォルトで含まれるようになります:
sass使えそう
@asada-no4
ありがとうございます!(夜遅くにごめんなさい)
とかも決める。。?
Sass導入する?
今回複雑で大規模というわけでもないし、コンポーネントごとにスコープきられてるので、無理して導入する必要もないのかなとおもいますが、いかがでしょうか。。? (というか最近プロジェクトで触ってなかったのでいまいち分かってないです。。)
フレームワーク
今回はデザインが決まってるので、あまり恩恵がない気がしてるので不要かなと思いますがいかがでしょう? (レスポンシブとか、書き方を揃えるという意味でしか発揮しない?)
ちなみに。。Tailwindをよく見かけますが、書き方がいまいち受け付けない。。けどどうなんでしょうか。。? もしご存知であれば。。 (使ってみると意外といいみたいな声もあったり。。どうなん?と思ってます)
CSS設計
BEMしかちゃんと使ったことないのですが、Sassを導入しないのであれば不要だし、今回はそんなに決め込む必要ない?
全体通してイマイチ分かってない感ありますが、ほか決めなきゃいけないこととか、あればお願いします。。
@runa-sakagoshi0830
・よく使うような色は変数で管理したほうが良さそう ・スタイルのネストが可能なので可読性が上がりそう & コード量が減りそう という理由から、導入したほうが良いかなと思ってましたが、いかがでしょうか? ただ確かにコード量があまりないのであれば不要な気もしてきました。
今回はデザインが決まってるので、あまり恩恵がない気がしてるので不要かなと思いますがいかがでしょう?
そうですね。固有のデザインやイメージが多い気がするので、不要で良いかと思います。 ありがとうございます。
Tailwind
私も使ったことがないですね。。。 パッと見てみましたが、汎用的なクラスを組み合わせてスタイリングするのは今回のケースには合わなそうですね。 デザインの制約も多そうですし、なしで良いかと思います。
BEMしかちゃんと使ったことないのですが、Sassを導入しないのであれば不要だし、今回はそんなに決め込む必要ない?
規則があったほうが見やすいかなと思ったのと、sassとBEMは相性が良さそうなので導入して良いかなと思いました。
他に決めたほうが良さそうなのはポストプロセッサかなと思いますが、 linterのissueが切られているので特に考慮しなくて良いかなと思ってます🙇♀
@asada-no4 (Cc: @yuki-ohnaka-no4 )
ありがとうございます!
・よく使うような色は変数で管理したほうが良さそう
slackで太中さんが共有していただいた通り、CSSでも変数使えるのでそこは大丈夫そうですね!
・スタイルのネストが可能なので可読性が上がりそう & コード量が減りそう
浅田さんが仰る通りスタイルのネストは可能なので、その点利点だと思いますが、今回はそこまで複雑で大規模な感じでもない?気がするので、そこで可読性やコード量の大幅な減少はないのかも?と思ってます! (+太中さんから共有いただいた既存のスタイルシートを見る感じ?)
その点踏まえて無理して入れる必要もない気がしてますが、いかがでしょう?
フレームワークは入れる? こちらは不要で良いですかね!
CSS設計 もしSassを導入しないのであれば、コンポーネントを切ってく上で逆にクラス名が冗長になってしまいそうなので、ある程度ルール決めるくらいで良いのかな。。
他に決めたほうが良さそうなのはポストプロセッサかなと思いますが、 linterのissueが切られているので特に考慮しなくて良いかなと思ってます🙇♀
🙇♀
@runa-sakagoshi0830 はい!sassも不要で設計もルール決めくらいで良いかと思います。 まとめていただきありがとうございます!
@yuki-ohnaka-no4 (Cc: @YuutoOse ) スタイリングについて以下まとめになります。
■Sassについて 不要とします。 理由:上記で出ていた変数についても、わざわざSassを使う必要がないのと、今回メリットを感じないため。(もはや冗長になる) 以下参考。 sassは必要?-sassからの卒業。back-to-css。 Sass、別に言うほどいらない説
■フレームワーク 不要とします。 理由:上記で浅田さんの方から記載していただいたとおり、今回デザインが決まっておりわざわざ導入する必要がないと判断したためです。
■CSS設計(参考:CSS設計の基本) ※箇条書き失礼します。
・命名規則:ケバブケース ・CSSのプロパティの順序はstylelint-config-recess-orderで整理する(導入済み) ・idの使用:基本しない(DOM操作に使用するのみOK。その場合は"js-xxx"で意図がわかるように) ・単語省略:基本しない ex.) ボタン→btnではなくbutton
・マルチクラスの有無:状態で変化するスタイル以外は基本なし ・動的にスタイルを変更する場合はis-xxxを付与する(状態変化) ex. )is-active ・クラス名では、基本スタイルベースではなく機能の名前をつける(red-button, blue-buttonではなく、close-buttonとか。) ・タグでスタイルを決めない(hとかstrongとか)→reset.css等で初期化させておきたい。 →スタイルとしては使用しないが、構造としては使用する(h1とか) ・!important使わない(リンターで制御)→どうしても必要なら要検討 ・インデント:スペース2(editorconfigで指定済み) ・HTML構造に依存しないように(セレクタにタグ名をしていない。初期化のみ)
・要素を並べて間隔を開けたい場合は、基本flex or gridで、gapを使う。(意図しないレイアウトにならないように) →MacOS Safari14.1未満と、iOS Safari14.5未満flex-gap未対応。ただシェア的にあまり考える必要ないかなと思うので、flex-gapでも問題なし。(参考:App Store - Support - Apple Developer) ・已む無くmarginで間隔を取りたい場合は、margin-right, margin-bottomで間隔をとる。 ・フォントサイズ:px指定はしない(emで相対的に設定する)→グローバルに定義しておく ・基本的な色は定義しておく。(あまり自分でカラーコードを入れない) ・imgタグはwidth height属性を指定する。(表示が遅いわけではないし、あまり考える必要はないのかもですが、レイアウトシフトを防ぐため。) →参考(ちょっと古いかもですが):【2020年夏】imgタグにはwidthとheight属性を書くのがいいらしい
@asada-no4 ほぼ差分ありませんが、追加等々あればコメントお願いします。
@runa-sakagoshi0830 @asada-no4
調査&検討ありがとうございます。 提案してくれた方針で概ね問題ないかと思います〜
以下だけコメントしておきます〜
■フレームワーク
こいつは元々bootstrapが入ってるので、それをそのまま残す感じでよいかなと👀 (リセットCSSはrboot)
@runa-sakagoshi0830 ↑だけ問題なければissueクローズお願いします〜
@yuki-ohnaka-no4 (Cc: @asada-no4 ) フレームワークも合わせて、承知しました。 こちらクローズとさせて頂きます。
CSS