1 - 22 件 / 22件
テキストを画像の上に配置、タグを重ねたい、ヒーローセクションで画像の上にコンテンツを配置、画像のアスペクト比を維持させたい時など、CSSの絶対配置(position: absolute;)を使用することがあります。もちろん、それでうまくいく時はありますが、なんらかの制約があったり、テキストが長いと崩れたりします。 position: absolute;が必要だと思われていた実装で、使用しなくても実装できるモダンCSSのテクニックを紹介します。 Less Absolute Positioning With Modern CSS by Ahmad Shadeed はじめに ケース1: カードのオーバーレイ ケース2: カードのタグ ケース3: ヒーローセクション ケース4: display: contents; ケース5: カードアイテムの並べ替え ケース6: 中央寄せ ケース7: 画像のアス
margin-bottomではなくmargin-topを使う派である旨をツイートしたら理由を尋ねられたので、それに対する回答です。大きくは次の3つです。 末尾の要素の存在が任意である場合が多いため Stackレイアウトとの取り合わせやすさのため 隣接セレクターを使った場合分けができるようにするため CSS、基本コンポーネントの上にマージン取る派と、下にマージン取る派がいると思うですけど、自分は今までずっと下で。というのは、その方が直感的だと感じるからなんですけど、見出しの下って結構縮めるよね?それを上マージンでやると結構頭こんがらがらない?って思うんだけどどうなんだろう — Takazudo (@Takazudo) January 12, 2021 上です — 全部入りHTML太郎 (@_yuheiy) January 12, 2021 なぜですか? — u (@uknmr) Januar
Twitterでこういう発言を見かけまして Tailwind CSSはデザインに凝ってるサイトでは使えない こだわりが無い場合に向いている は?何いってんの? って思ったので、自分がいろいろ試した結果、Tailwind CSSを選んだ話を書きます。 はじめに 以前、Tailwind CSSは結構いいぞって話を書いたんですが、この記事の立ち位置的にはその続きみたいなものなので、以下の記事を始めにご参照いただけるとより分かりやすいかもしれないです。 この記事では、前回記事を書いた後、個人仕事でWebサイトをGatsbyで作り、その中で、どうやってCSSを書くのが良いのか模索した結果、自分はこれを選んだっていうのを、同じUIを色々な方法で書き比べたコードを並べつつ、どうのこうの筆者の考えを述べていきます。 その仕事はほとんど筆者が「まかせてくださいよーいい感じに作りますよー。デザインそろってない
Webエンジニアを始めて丸2年が経ちました。 複数プロジェクトを進める中で、CSSコーディングを行うときの「こうしておくと便利」「このほうが管理しやすい」といった知見が溜まってきたのでまとめます。 はじめに 長くなってしまった細かい説明はところどころ折りたたんでいます。概要だけで理解できたら飛ばしていただき、詳しい話が気になったら開いて読んでください。 これらは「自分がよく取り入れている手法」であって、必ずしもどのプロジェクトにも当てはまるものではないと思います。 各項目について、自分がその判断に至った 「理由」 を説明していますので、 理由を読んだ上で自分のプロジェクトに取り入れるか判断いただくと良いと思います。 この記事は、すでにCSSコーディングをしていてアイデアがほしい人に向けた記事で、 CSSをこれから学び始めるような 初学者向けではない ことご了承ください。 一般的と思われるキ
はじめに 業務で開発をしていて、Pull Requestを送るたびに命名について厳しいレビューをもらうので、業務で特に重要だと感じた部分のみまとめてみました! 最初は「動けばいいじゃん!」と思っていたのですが、チーム開発、仕事となるとそうはいきません。 品質も含めて評価されるため、読みやすいコードを書くということは非常に重要です。 レビューで毎回のように 「ちゃんとリーダブルコードを読みましたか?」 と厳しい指摘を受けるので、できるだけその回数を減らしていきたいです。 毎日レビューで厳しい指摘を受けるのは(おそらく上司も仕事のためとしてコードに対しての指摘をしていると思われるが)とても辛いです。 レビューは あくまでもコードの指摘をしているだけ で、自分自身の人間性や仕事に対するダメ出しをもらっているということではない!と思うようにしてます。 とはいえできるだけレビューで受ける指摘は減らし
こんにちは。ZOZOTOWN部フロントエンドチームの菊地(@hiro0218)です。 2021年3月、ZOZOTOWNは10年ぶりのリニューアルをしました。この記事では、そのリニューアルで再考したCSS設計について紹介します。 背景 今回のリニューアルでは、ウェブとアプリが部分的に共通のデザインになりました。 アプリ ウェブ このデザイン刷新には、CSSの大規模変更が必要です。チーム内で検討を重ね、最終的に、大きく書き換えるのであればコンポーネント駆動開発1ができるようにCSS設計を見直すべきという結論に至りました。 CSS設計で特別に考慮する点 現在、ZOZOTOWNのフロントエンドは、「Classic ASP」から「React」へのリプレイスを進めています。新規開発や変更のタイミングで、Classic ASPに依存した実装をReactへ改修します。 ただ、今回のリニューアルではClas
後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。 BEMによってもたらされた、コンポーネントベースのアプローチでは、「ページはコンポーネントの集合によって表現されるべきであり、ページに含まれるのはすべてがコンポーネントである」と考える。しかしこれまでCSSを書いてきた経験から、これではデザイン意図をまともに表現することができないと感じ始めた。なぜなら、普通デザイナーはページのすべてがコンポーネントであるとは考えないからだ。 もちろんページの構成要素のなかには、明らかにそれが「コンポーネント」であると意識して作られたものもある。ただしそれは一部であり、全部ではない。「コンポーネントもあれば、コンポーネントではないものもある」という感覚のほうが普通なのだ。 典型的なUIライブラリにある、「ザ・コンポーネント」みたいなものだけではページは完成しない。例として、一貫してB
未経験からコーダーとして仕事をし始めて2年が経過しました。 最初の頃はとにかくスピードややりやすさ、デザインの再現などを重視し、保守性は特に考えていませんでしたが、ページが多くなってきたり自分以外の人と一緒にコーディングする機会が増えるにつれ、当初とはまるで違う意識で書くようになった気がします。 自分のコーディング手法もまだまだ発展途上だとは思いますが、自分なりに保守しやすいであろうコーディング手法が確立されつつあるので、コーディングルールも兼ねて記事に残しておこうと思いました。 デザインが再現できればOKというコーディングから一歩進んだコーディングを目指す方の参考になれたら嬉しいです。 この記事の前提 コーディングに付随するいろんな用語が出てくるかと思いますが、詳しくは説明していません...。なので、今コーディングを勉強中であったり仕事でコーディングしたことない人にとっては、理解しづらい
宣伝💡 この記事の内容の超大容量版がこちらの本になります。興味がある方は是非チェックしてみてください。 Web業界に新卒で入ってから7年と数ヶ月が経ちました。私はデザインからフロントエンド全般が守備範囲です(Next.jsを使った軽めのWeb開発くらいまで)。 最近ようやく自分の中での「コーディングの手法やルール」が固まってきたので、言語化してこの記事で解説していこうと思います。 はじめに まず最初にこの記事の方針や前提をいくつか書いておきます。 用語や知識の詳しい解説はしていないので、分からない内容が出てきたら調べながら記事を読んでいただくとより理解しやすいと思います 実務を数年経験していないと理解できない部分があるかもしれないです(完全初学者向けではなく、初・中級者向け) あくまで自分の中での手法やルールであり、全ての実装者・会社・プロジェクトなどに当てはまるわけではありません(もち
なんとなく自分の中で言語化しておきたかったので、整理も兼ねて記載しておきます🙆🏻♂️ 普段仕事で様々なAngular、またはReactのコンポーネントを作ったりメンバーから出るPRを読む中で、コンポーネントのスタイルはどういうふうに当てるのが破綻しにくいんだろうと考えていました🤔 Angularは良くも悪くも一つのComponentが結構おっきくなりがちだったのでそこまで意識しなかったですが、Reactは何なら分割しないと気持ち悪いとすら思えるくらいにコンポーネントを分割しやすいです。 コンポーネントを分割することは各ファイルごとに把握すべき事柄が減るので基本的にはいいことだと思っていますが、スタイリングについては意識しないと破綻してしまうなーと思っています。 (もちろん、スタイリングに限らず意識しないと破滅するんだけど、今回はスタイルについての話です) スタイルの破綻っていうのは
乗りこなせ! モダンフロントエンド 新しい擬似クラス:has()、:is()、:where()を使いこなそう [CSS Modern Features no.1] 本連載について はじめまして! サイボウズ フロントエンドエキスパートチームの麦島です。 本連載では、Webフロントエンドに関してもう一歩踏み込んだ知識について、サイボウズ フロントエンドエキスパートチームのメンバーによって不定期で解説記事を掲載していきます。モダンな仕様の紹介・普段使っているライブラリのコア部分で何が行われているのかの解説・ハンズオンなど、さまざまな内容でお届けする予定です。 CSSの進化 本連載での最初のコンテンツは「CSS Modern Features」です。 CSSの表現力は年々新しい仕様の策定や実装とともに進化しています。従来であれば複雑なCSS定義が必要であったものが簡潔に表現できたり、Ja
こんにちは。TAK(@tak_dcxi)です。 2020年最後のZennの投稿ということで、Web制作テンプレートの年末大掃除も兼ねて僕がよく使うSassのmixinとfunctionを厳選してまとめてみました。 Sassを使っている方でmixinとかfunctionをあまり利用してないという方は参考にしてみてください。 ブレークポイントの指定 おそらくmixinで最も利用されているのはレスポンシブでのブレークポイントの指定だと思います。 $breakpoints: ( 'xs': (min-width: 0), 'sm': (min-width: 576px), 'md': (min-width: 768px), 'lg': (min-width: 992px), 'xl': (min-width: 1200px), 'xxl': (min-width: 1400px) ) !defau
HubSpotやCSS設計に明るい半田のウェブサイトです。 ウェブサイトの本質は情報を伝えることですので、それを言い訳にデザインは全体的に工事中です。 みんな大好き、あるいは大嫌いなCSS設計。そんな言葉が生まれてから久しく、JavaScriptフレームワーク(以後JSフレームワーク)を始めとする技術が提供するスコープ付きのコンポーネント環境の登場によって、そのなりを潜めている気がしなくもない。 そんなCSS設計とは何だったのか、をちょっと小難しく振り返ってみます。 なお本記事では、区別のためCSS設計が「再利用可能なパーツ」とみなす単位を(あるいは慣習的に)「モジュール」、JSフレームワークにより提供される単位を「コンポーネント」と呼びます。 CSS設計が行っていたこと 「CSS設計」と聞くと Block__Element–Modifier という形式の長ったらしいクラス名を付けることだ
HTML 側の内容とセレクタがマッチすればスタイルが適用されます。このように CSS はとても単純な仕組みですが、その単純さゆえに大規模な実装では管理が難しく簡単に破綻してしまう問題点を抱えています。 CSS が破綻してしまう主な理由は以下の通りです。 セレクタには詳細度 (優先順位) が存在するスタイルには子要素にまで継承する同じセレクタを多重定義できるHTML 側の各要素はスタイルが複合的に適用される 開発現場では CSS が単純であるがために軽視されてしまう嫌いがあります。多くのプロジェクトでは Java や SQL などのコーディング規約やアンチパターンなどは用意されていますが、CSS は用意されていないケースは珍しくありません。その結果、統一されたルールがない状態でプロジェクトが進み、開発が佳境にさしかかったタイミングで CSS の逆襲が始まります。CSS が悪いわけではありませ
皆様こんにちは。フロントエンドエンジニアのレンツです。僕の連載では初学者向けに、コーディングのノウハウを提供しています。 今回はHTMLに付けるclassの名前について考えてみたいと思います。classに付ける名前によってタグの組み方もコーディングの速さも変わってきますし、拡張性の高さも変わってきます。 classの命名についてちょっと知識をつけていただいたら、コーディング時間が短くなってもっと楽しく開発できるようになりますよ! というわけでいってみましょう。 コーディングの悩み:classの命名規則 さて、HTMLとCSSを勉強したら何かサイトを作ってみたくなりますよね。HTMLタグを書いてclassをつけてCSSでスタイルを当てていく〜......という作業を延々と繰り返す日々が始まります。 勉強しはじめでアドレナリン全開のころは勢いでいくらでもできる作業なのですが、考えなしにスタートしてしま
Spoilers! Like with so many things, the answer is "it depends." How come? Read on. Tailwind and BEM are two approaches to writing and maintaining CSS. Comparing them is a bit like comparing apples and oranges, in that while they’re separate, they’re still fruit. This is to say that having an approach to manage your CSS—like any other code—is a good thing. Tailwind is the newer of the two, with the
"Naming things is hard" goes the software engineering axiom and CSS is no exception. Here are some collected thoughts related to naming CSS Custom Properties. I’m going to use use the terms "variable" and "custom property" interchangeably since they are effectively the same thing for the purposes of what to call them. Disclaimer: What follows is not gospel. CSS to me is a very poetic language, the
こんにちは。 どうもしばひろです。 皆さんは、Webサイトをコーディングする時、文字サイズはどうやって指定してますか? 「px」や「pt」などの絶対値ですか? それとも「rem」や「em」などの文字サイズをベースとした相対値ですか? CSSには色んな単位があり、色んな考え方があります。 一概にどれがベストだとかは言えませんが、僕は基本「rem」や「em」などの文字サイズをベースとした相対値で文字サイズを指定しています。 最近では、「もう、remやemなどの文字サイズをベースとした相対値じゃなくてpxでいいんだよ。」系のツイートやブログを目にすることが多いのですが、それでも僕は今現在は、rem や em などの文字サイズをベースとした相対値を使っています。 あ、決して 「px で font-size を指定しているサイトはダメだ!」とか、「今日から君も rem を使うんだ!」とか言うつもりは
Media Queryとは Webページの見た目を画面の幅に応じて表示を変えるCSSの機能です。1つのページで、レスポンシブに画面の表示を行うことができます。 一般的にCSSでは、以下のように記述します。
こんにちはTANE-beのエンジニアです! 皆さんはCSSをどのように意識して記述しているでしょうか? CSSの書き方は10人いれば、書き方も10通りあると言われるほど、自由に構築することができます。しかし、その自由さが原因で書き方を乱雑にしてしまうとCSSが重複したり、修正の際に大変になることがよくあります! CSSの中身を見ると!importantを使い回されていたり、1つのCSSを変更するといろんな箇所のスタイルが変更されたりと色々大変な目にあったことも! そこで今回は、破綻しないCSS設計、FLOCSS(フロックス)についてご紹介しようと思います。
「ファイル名」「クラス名」「変数名」「メソッド名」「DBのテーブル・フィールド名」「HTMLのid・class名」など、様々な場面で命名する必要があります。 このような場面で活用できる命名規則の記法を紹介します。 命名規則 current user item を要素語とした複合語の記法を確認します。 キャメルケース( camelCase ) currentUserItem のように書きます。 先頭の要素語( current )は小文字で書き始めます。 先頭以外の要素語( user item )の最初を大文字で書き始めます。 ローワーキャメルケースともいいます。 パスカルケース( PascalCase ) CurrentUserItem のように書きます。 要素語( current user item )の最初を大文字で書き始めます。 アッパーキャメルケースともいいます。 スネークケース(
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く