7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

HTML、CSSは、将来を見越して書こう!

Posted at

開発環境でHTML、CSSなどでページ作成している時は公開が目標になってしまいがちです。あのブラウザだけレイアウト崩れが…その端末だとうまく表示できない…突然の仕様変更!など、いろんな理由で「もうこれでいいや!えいやー!」とその場凌ぎな書き方になってしまうことがあります。
公開後に直そうと思っても影響範囲が広すぎて、なかなか難しいといったことはないでしょうか?
困ったことになりにくいようにポイントを紹介していきます。

■!importantは最後の切り札
困ったときに!importantで指定してしまえば、自分の書いたstyleが優先されるので便利です。
でも、その後その近くに新しく要素を追加することになった時どうなりますか?
うまく配置できなかったらどうなるでしょうか?
・!importantを外してまた作り直す
・さらに!importantを使って優先順位をあげる

こんなことをやり続けていたら、いつまでも手を入れ続けなくてはならず、運用が楽になりません。
!important以外にも優先順位を上げる方法はありますし、上書きしてしまうという手段もあります。
他にどうしても手段が見つからない場合だけにしましょう。

■styleで直接書かずにCSSでなんとかする

お知らせです

このような書き方をすると、testClassを修正してもmargin-bottomが10pxのままになってしまいます。
また、あとでstyleの部分を削除する手間も発生してしまいます。
こういった修正をしたことを覚えていたら大丈夫ですが、もし新しいメンバーが加入した時、
その人はそのことを知らずに困ることになるかもしれません。

■再利用しやすい作りにする
このページでは使えるのに、他のページでは使えない。
同じデザインなのに!

リンクやリストのような他のページでも使うものは、他のページでも使えるように再利用できることを意識する。
また仕様変更にも対応できるように。リストの項目が一つ増えてもすぐに修正できるように作ると運用がぐっと楽になります。

■コーディング規約を作成し閲覧できる場所においておく
・なんで〇〇さんは、なんでもtableで作るの!(怒)
・!importantでなんでも書きすぎ!!(怒)
こういった不満や不機嫌になりがちなプロジェクトには、
・コーディング規約がない(自由でいいよ!ってケースも…)
・wikiの更新が1年以上とまっている
・古参メンバーの暗黙の了解になっている

なので、質問したり、HTMLやCSSを読んで研究して合わせようとしたり、
コミュニケーションコストがかかったり、書き方を自力でつかみにいかなくてはならず大変です。

また、HTML、CSSはフロントエンド担当者のレベルで書き方が違っていたり、
バックエンドに強いプログラマがフロントエンドに強いとは限らなかったり、
いろんな人が編集します。
なので、これは守って欲しい!といったことはドキュメント化しましょう。

いかがでしたでしょうか?
一度作ってしまうと影響範囲が広くてなかなか直せないといったケースにあたったり、
簡単に書けてしまう分、いろんな人が編集することもあり、運用がなかなかうまくいかないことがあります。
少しでも参考になれば幸いです。
こんなことをやるとうまくいくよ!といったコメントも歓迎です。

7
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?