タグ

CSS設計に関するmanabuyasudaのブックマーク (51)

  • Naming Variables In CSS

    “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

  • よりよいCSSを書くための、CSS / Sass (SCSS) 30のルールとその理由

    Webエンジニアを始めて丸2年が経ちました。 複数プロジェクトを進める中で、CSSコーディングを行うときの「こうしておくと便利」「このほうが管理しやすい」といった知見が溜まってきたのでまとめます。 はじめに 長くなってしまった細かい説明はところどころ折りたたんでいます。概要だけで理解できたら飛ばしていただき、詳しい話が気になったら開いて読んでください。 これらは「自分がよく取り入れている手法」であって、必ずしもどのプロジェクトにも当てはまるものではないと思います。 各項目について、自分がその判断に至った 「理由」 を説明していますので、 理由を読んだ上で自分のプロジェクトに取り入れるか判断いただくと良いと思います。 この記事は、すでにCSSコーディングをしていてアイデアがほしい人に向けた記事で、 CSSをこれから学び始めるような 初学者向けではない ことご了承ください。 一般的と思われるキ

    よりよいCSSを書くための、CSS / Sass (SCSS) 30のルールとその理由
  • 垂直方向のマージンにはmargin-topを優先的に使う理由

    margin-bottomではなくmargin-topを使う派である旨をツイートしたら理由を尋ねられたので、それに対する回答です。大きくは次の3つです。 末尾の要素の存在が任意である場合が多いため Stackレイアウトとの取り合わせやすさのため 隣接セレクターを使った場合分けができるようにするため CSS、基コンポーネントの上にマージン取る派と、下にマージン取る派がいると思うですけど、自分は今までずっと下で。というのは、その方が直感的だと感じるからなんですけど、見出しの下って結構縮めるよね?それを上マージンでやると結構頭こんがらがらない?って思うんだけどどうなんだろう — Takazudo (@Takazudo) January 12, 2021 上です — 全部入りHTML太郎 (@_yuheiy) January 12, 2021 なぜですか? — u (@uknmr) Januar

    垂直方向のマージンにはmargin-topを優先的に使う理由
  • レイアウトプリミティブ

    DIST.30 「一歩差がつくCSSテクニック」にてライトニングトークをさせていただく機会がありました。この記事はそこでお話しした内容をもとに書き起こしたものです。 私が業務で携わるのはおもに、メディアサイトやコーポレートサイトのようなページ数がたくさんあるサイトの制作です。そのようなサイトでは特に、ページのテンプレートやコンポーネントをいかに堅牢な設計にできるかが重要だと感じます。 連想されるトピックとしては「CSS設計」がありますが、私見としては、CSS設計はセレクタの書き方やコンポーネントの整理の方法について述べたものであって、いかにしてレイアウトを組み立てるかという議論にはあまり踏み込んでいません。 具体的には、どのように宣言を組み合わせるか、どのようにレスポンシブにするかのような曖昧な領域については、実装において必ず意識される部分であるにも関わらず言及される場面は少ないのではない

    レイアウトプリミティブ
  • A (more) Modern CSS Reset

    I wrote “A Modern CSS Reset” almost 4 years ago and, yeh, it’s not aged overly well. I spotted it being linked up again a few days ago and thought it’s probably a good idea to publish an updated version. I know I also have a terrible record with open source maintenance, so I thought I’d archive the original and just post this instead. Do with it what you want! To be super clear, this is a reset th

    A (more) Modern CSS Reset
    manabuyasuda
    manabuyasuda 2019/10/04
    ul[class]みたいな指定はアリかも。詳細度は0,0,1,1で少し上がるけど、影響はあまりなさそう。
  • 堅牢で保守的な最低限度の CSS 設計 - Qiita

    CSS 設計でいう保守性とは、新しいルールの追加・更新のしやすさ をあらわす。保守性を高めるためには、変更の局所化、他のルールへの副作用を最小にするアーキテクチャ を採用します。 設計思想は FLOCSS ベースの ECSS + rscss + Tailwind CSS のいいとこ取り 命名規則は MindBEMding (以降、BEM) 開発言語は Sass + PostCSS コンポーネント粒度 FLOCSS ではプロジェクトにおいて繰り返されるビジュアルパターンをすべて Object として定義します。Object には、Component と Project のレイヤーがあり、この 2 つの判別において Atomic Design のコンポーネント粒度の考えを拝借します。具体的には、 Component:Atoms Project:Molecules に分類します。 単語間の区切り

    堅牢で保守的な最低限度の CSS 設計 - Qiita
    manabuyasuda
    manabuyasuda 2019/09/19
    考えが近しい
  • Designing CSS structure in a legacy frontend product

    事業戦略と組織のビジョンデザイン〜デザイン的アプローチで事業・組織づくりにどう取り組んでいるかのリアル〜

    Designing CSS structure in a legacy frontend product
  • CSS フレームワークを使いたくない - ジンジャー研究室

    CSS フレームワークが辛い。 ここでいう CSS フレームワークとは Bootstrap とか Bulma とかそういうやつのことである。昔から自分はこういうのが苦手で、一定の便利さは感じつつもどうしても馴染めないという状態が続いていて、それでも「それは使い方が悪いだけで、ちゃんと使いこなせばペイするんだろう」と思って今までズルズル使ってきてしまったのだが、やっぱりそれでもどうしても辛くなり脱フレームワークしようと思う。 もちろん使いこなせる人には使いこなせるんだろうし「使うべきでない!」という主張をするつもりはない。頭のいい人には使えるんだろう。昔は「今すぐ〜すべき 10 の理由」みたいなことを適当に書いてたんだけど、どうせ自分がやってることは「 Web 系」のメインストリームからは外れてるんだろうし、合わせるつもりもなければ合わせさせるつもりでもない。使う理由も使わない理由も人それぞ

    CSS フレームワークを使いたくない - ジンジャー研究室
    manabuyasuda
    manabuyasuda 2019/03/20
    CSSを覚えるのにBootstrapやFoundationをよく読んでた。デザインとコーディングをする人がそのフレームワークをよく理解してたらうまく利用できるかも。全体の7割以上にならないなら使わない方がいいかも。
  • [WIP]CSSの命名について - yuhei blog

    下書き供養 Advent Calendar 2018の9日目の記事です。 CSS命名規則じゃない命名についての体系的な何かができないかを考えていた。どういう要素に命名するためにどのように言葉を選定するのか、命名という切り口で具体的に説明する文書みたいなものを見たことない気がする。 きっかけはクラス名に使える単語リストみたいなのが流れてきたのを見て感じたなんか違う感。それはそれでわかるんだけど、そもそもどういった場合にどのような種類の言葉を探すのか、要素をどの視点から捉えて説明するのかみたいな話が先にあった方が良さそうに思う。 一旦コンポーネント名の命名に基準を合わせて、UI的な命名とドメイン的な命名に分解できるのではと考えた。有名なところではMCSSのベースとプロジェクト、及びそれに影響を受けたであろうFLOCSSのComponentとProjectのレイヤー分けに近いと思う。ただしこれ

    [WIP]CSSの命名について - yuhei blog
    manabuyasuda
    manabuyasuda 2018/12/10
    傾向はひとりで考えられるけど、最終的にはデザインと命名がイコールになるように話し合う必要があるなと思っていて、それをスムーズにするための手引書が必要なんだろうな。
  • CSS in JSはCSSの書き方をどのように変えるのか - yuhei blog

    CSSの難しさの根源はセレクタにある。CSS設計のための方法論ではどのようにしてセレクタと関わるべきかについて語られる。 その関わり方がCSSのみで実現できなければならないという制約を捨てたのがいわゆるCSS in JSの類(定義的に微妙なやつも全部ひっくるめて)だ。可能性は一気に広がり無数のライブラリが生み出された。 ある程度の期間を経ていくつかの着目すべきアプローチが見えてきた。これから僕はどのようにセレクタと関わっていくべきかという視点で記してみたい。 擬似スコープ 通常CSSのセレクタにはスコープはないが、HTMLCSSにハッシュ値を付与して特定のコンテキストを擬似的に閉じてしまおうというアイデア。実装としては、Vue.jsの単一ファイルコンポーネント、Angularのコンポーネントスタイル、styled-jsxなど。関連するウェブ標準技術としてShadow DOMがある。 例え

    CSS in JSはCSSの書き方をどのように変えるのか - yuhei blog
  • Atomic DesignとCSS設計 | 第2回 ワークフローとメンテナンス

    Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTMLCSSJavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。 著書に『改訂版 Webデザイナーのための jQuery入門』(技術評論社、2014年11月14日)がある。 CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

    Atomic DesignとCSS設計 | 第2回 ワークフローとメンテナンス
  • QiitaのCSS構成2017 - Qiita

    この投稿は Increments Advent Calendar 2017 の18日の記事です。去年に続き、2017年の Qiita の CSS 構成について述べます。 2016年版はこちら: QiitaのCSS構成2016 プリプロセッサー 2016年は CSS のビルドフローで一貫して PostCSS を使っていましたが、2017年では プリプロセッサーとして Sass (node-sass) を使っています。 プリプロセッサーとして PostCSS を使わなくなった最大の理由は @apply ルールが仕様から落ちた ことです。@apply は Sass でいう引数なしの mixin みたいなもので、Chrome の Canary では実装されていた時期がありましたが、消えてしまいました。 おそらく CSS Nesting Module や CSS Extend Rule も落ちると思

    QiitaのCSS構成2017 - Qiita
  • 抽象化を避けるCSS設計方法論「Enduring CSS」 第4回

    前回までで、Enduring CSS(以降ECSS)の考え方を紹介してきました。ECSSというのは端的に言うと「分けて考えよ」という設計思想です。当たり前ですけれども、どう「分けて」考えるかは、設計者自身に判断が任されています。 ECSSには、Webアプリケーション向けに考えられた設計方法であると書かれていますが、筆者Takazudoとしては、より広い範囲で応用できる考えだと感じました。今回は、どのようにECSSの考え方を活かすべきかという点について考えてみます。 コンポーネント指向のフレームワーク 2017年時点において、ReactAngularのようなコンポーネントベースでWebアプリケーションを構築できるフレームワークが台頭しています。このようなフレームワークでは、コンポーネントの中にだけCSSを適用するアプローチを取ることができます。 Reactを使ったモジュラーCSS : CS

    抽象化を避けるCSS設計方法論「Enduring CSS」 第4回
  • サービスの一貫性と高速開発をもたらす「動くスタイルガイド」  | Visional Designer Blog

    10月18日(水)に、株式会社ベーシックで行われた「Nextstage Nite vol.2 - 実践されるデザインガイドライン -」に、HRテック(HR × Technology)で採用を強くする「...

    サービスの一貫性と高速開発をもたらす「動くスタイルガイド」  | Visional Designer Blog
  • 細かすぎるけど伝わってほしい私的BEMプラクティス30(ぐらい)

    BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。 レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。 BEMを使いはじめてかれこれ3,4年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。 ただし、それはBEM

    細かすぎるけど伝わってほしい私的BEMプラクティス30(ぐらい)
  • CSSは簡単だなんて誰が言った - LIVESENSE ENGINEER BLOG

    はじめまして!正社員転職サービス転職ナビ(旧ジョブセンスリンク)のフロントエンドを担当しているsueshinです。 CSSはプログラミング経験の浅い方でも扱いやすく、比較的習得が早い言語だと言われることが多いと感じている次第です。 もちろん、それはCSSの素晴らしい側面の一つです。 一方で、設計のアンチパターンと言われることが、CSSでは積極的に採用され、長期の保守になると難しいという側面もあります。 今回は企業様用採用管理ツールのCSSの保守で苦戦し、リファクタリングした時のお話をいたします。 お手柔らかにどうぞ。 尚、ソースコードは一部記事に合わせて表現を変えています。 なぜCSSをリファクタリングしたの? 企業様用採用管理ツールのCSSをリファクタリングする前は以下のような大きな問題を抱えていました。 管理されていないCSS 転職ナビはリブセンスの創業初期からある歴史あるプロダクトで

    CSSは簡単だなんて誰が言った - LIVESENSE ENGINEER BLOG
  • プログラマーから見た、SCSSの正しい(かもしれない)使いかた - Qiita

    SCSSとは SCSSというのは、CSSのアレなところを何とかしようという目的で作成されたメタ言語です。詳細は省略します。 なにそれ? ってかたは、コチラなどがわかりやすいのではないかと思います。 CSSのメタ言語Sass(SCSS)、LESSの完全入門 でですね。 ここで大事なのは、こいつは要するにCSS周りの技術ですので、つまるところは基「デザイナーさんが使う」ものである、というところです。 彼らは概して、非常におおらかで、健康的で、寛容です。私たちサーバーサイドエンジニアのように、細かいことで「こんな仕様は許されんな!」「なんだよこの仕様設計したヤツって○○じゃねーの?」などとイラついたりしません。 なので、あんな欠点だらけのクソ規格であるCSSにも、特に気にしたりしないらしいのです。 ところがやはり、中には「CSSのそーゆーところって、やっぱ問題だよねー」って思う人々もいたらしく

    プログラマーから見た、SCSSの正しい(かもしれない)使いかた - Qiita
  • 真のコンポーネント粒度を求めて

    Object Oriented CSS https://www.slideshare.net/stubbornella/object-oriented-css Bootstrap - Components http://getbootstrap.com/components/ BEM https://en.bem.info/ Atomic Design http://atomicdesign.bradfrost.com/ Enduring CSS http://ecss.io/

    真のコンポーネント粒度を求めて
    manabuyasuda
    manabuyasuda 2017/08/10
    適切に分離をすることから始めるECSSは、ある意味真っ当な考え方だと思う。もちろん、デザインがグローバルなコンポーネントとして設計されているなら別だけど。
  • いまどきのコンポーネント設計をめぐる座談会 | 第2回 コンポーネントの試行錯誤

    Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTMLCSSJavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。 著書に『改訂版 Webデザイナーのための jQuery入門』(技術評論社、2014年11月14日)がある。 CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

    いまどきのコンポーネント設計をめぐる座談会 | 第2回 コンポーネントの試行錯誤
  • あのモジュールこのコンポーネントそのブロック

    CSS設計におけるコンポーネント粒度について Object Oriented CSS https://www.slideshare.net/stubbornella/object-oriented-css Bootstrap - Components http://getbootstrap.com/components/ BEM https://en.bem.info/ Atomic Design http://atomicdesign.bradfrost.com/ Enduring CSS http://ecss.io/

    あのモジュールこのコンポーネントそのブロック