タグ

CSS設計に関するd4-1977のブックマーク (10)

  • 色々書き比べた結果Tailwind CSSにしたという話 - Qiita

    Twitterでこういう発言を見かけまして Tailwind CSSはデザインに凝ってるサイトでは使えない こだわりが無い場合に向いている は?何いってんの? って思ったので、自分がいろいろ試した結果、Tailwind CSSを選んだ話を書きます。 はじめに 以前、Tailwind CSSは結構いいぞって話を書いたんですが、この記事の立ち位置的にはその続きみたいなものなので、以下の記事を始めにご参照いただけるとより分かりやすいかもしれないです。 この記事では、前回記事を書いた後、個人仕事でWebサイトをGatsbyで作り、その中で、どうやってCSSを書くのが良いのか模索した結果、自分はこれを選んだっていうのを、同じUIを色々な方法で書き比べたコードを並べつつ、どうのこうの筆者の考えを述べていきます。 その仕事はほとんど筆者が「まかせてくださいよーいい感じに作りますよー。デザインそろってない

    色々書き比べた結果Tailwind CSSにしたという話 - Qiita
    d4-1977
    d4-1977 2021/06/13
    Code Gridの人の話だった。Tailwind CSSはともかく?Reactを使うか使わないかでCSSの設計が大きく変わるのは、デスヨネーって気持ちになりました。新卒研修するならReactあり無しで研修内容が異なるよね
  • 堅牢で保守的な最低限度の 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
    d4-1977
    d4-1977 2019/09/25
    ざっくりと読んで、ですよねー、という感じです。
  • 開発体制に合わせたCSS設計 | 吉川ウェブ

    Predictable 予測しやすい Reusable 再利用しやすい Maintainable 保守しやすい Scalable 拡張しやすい 参考:https://philipwalton.com/articles/css-architecture/ CSS設計の必要性 コスト削減 実装者の単価を減らせる 実装工数を減らせる 既存のコンポーネントを使うことで工数を減らせる デグレが起きる確率が減り改修工数を減らせる 部分的な改修を行うことで並行して実装ができる 観測した限りのCSS設計 OOCSS オブジェクト指向 Bootstrap BEM(MindBEMding) シングルクラスにする命名規則 SMACSS OOCSSやBEMなどから影響を受けている Base、Layout、Module、State、Themeのカテゴリーから構成される MCSS(Multilayer CSS) OO

    開発体制に合わせたCSS設計 | 吉川ウェブ
  • デザイナーがフロントエンド勉強会をやってみた2018 | GMO MEDIA CREATOR BLOG

    日々のWebサイトやアプリの制作を通じて、役に立ちそうな技術情報や楽しい話を発信しています。私たちはGMOメディア株式会社のクリエイターです。 初登場、大西です。コエテコというプログラミング教育のサービスでフロントエンドデザイナーをしています。 デザイン周り全般を担当しています。また、サービスデザイン部にも所属しています。 今回、2018年下半期にサービスデザイン部のグループミッションの一貫として、私を含む4名で改善・品質担保チームになり、以下のミッションを行うことになりました。(グループミッションについては、社内横断のデザイン活動を始めるまででまとめられています。) ミッション デザイン制作をスピードアップさせ、全体的な作業の効率化を実現する。 あるあるな手戻り・イライラする作業・一貫性のないデザイン等に対し業務プロセスの見直しやフレームワークの導入等によって改善を行う 「コーディング手

    デザイナーがフロントエンド勉強会をやってみた2018 | GMO MEDIA CREATOR BLOG
    d4-1977
    d4-1977 2018/11/25
    しっかりフロントエンドの話をデザイナーにしているなあ
  • WebサービスにおけるCSS再設計で考えたこと

    なぜこの記事を書こうと思ったか 配属されてからは、業務でCSSを書くといったら、Bootstrapのclass名を付与したり、機能追加の際にちょっと書くといったことだったのですが、大幅にサービス全体のCSSを見直さなきゃいけない機会があったので、どんなことを考えたのか書いておきます。 CSSのリファクタリングや再設計は工数がかかる上に、そこまで対価がない結構辛いことだと思います。また運用していて数年が経てば大体の場合がCSS設計は崩壊していきます...。 特に途中で気づいた、最初に決めておけばよかったということも多々あったので参考になればと思います。 前提条件 下記のような時に、この記事は役に立つのではと思って書いてます。 すでにあるWebサービスの大幅なデザイン改修がある 新しくCSSを書かなきゃいけないページが5ページ以上ある 既存のCSS設計を見なさなきゃいけない(CSSファイルが6

    WebサービスにおけるCSS再設計で考えたこと
  • GitHub - hiloki/flocss: CSS organization methodology.

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - hiloki/flocss: CSS organization methodology.
  • 宣言ブロックのCSS設計 - kojika17

    語で「CSS設計」を検索すると、記事やつぶやきなどでセレクタの命名規則に関する話題が多いです。 CSSを設計する上で、命名規則は重要な要素でしょう。 簡単なセレクタ名だと他のスタイルと重複する可能性もあります。他のスタイルと重複しないようにセレクタの子孫数を増やしてしまうと、今度はスタイルの取り回しが悪くなります。 またデザインをコンポーネントに分ける粒度について紹介されていますが、命名規則の分け方のように紹介されているよう感じます。 論理的に構造をわけて命名していくため、覚えやすく、伝えやすさもあわさって、現在の「CSS設計 = 命名規則」のような構図ができあがったと感じています。 CSS設計は命名規則だけか 命名規則CSS設計において、重要な要素です。 しかしCSS命名規則させ気を付ければ良い、というものではありません。 私は、すでにあるサイトの一部のコンテンツの作成やすでに用

    宣言ブロックのCSS設計 - kojika17
  • 抽象化を避けるCSS設計方法論「Enduring CSS」 第1回

    連載では、Enduring CSSというCSS設計方法論を紹介します。Enduring CSSは、Ben Frain氏の著書で、末永く破綻させずにサイトのCSSを設計するにはどうすればよいか。その方法論をまとめたものです。電子書籍でも販売していますが、Webサイトで全ての内容が公開されていますので、無料で全内容を確認可能です。 Enduring CSS by Ben Frain [Leanpub PDF/iPad/Kindle] Architect CSS and scale CSS with the ECSS CSS methodology CSS設計方法論(CSS methodology)と言うと、OOCSS、BEM、SMACSSの3つが著名なものと言えるのではないでしょうか。 An Introduction To Object Oriented CSS (OOCSS) – Smas

    抽象化を避けるCSS設計方法論「Enduring CSS」 第1回
  • サーバサイドエンジニアがCSS設計をした話 — みんなのウェディングエンジニアリングブログ

    この記事はmwedアドベントカレンダー11日目の記事です。 昨日の 最近使い始めた開発支援系サービスの話 に引き続き @koheisg が担当させていただきます。(2回目) エンジニアの幅を広げるという大層なことを書くと言ってしまいましたが、 この一年、みんなのウェディングで経験したCSS設計の経験を書こうと思います。 CSSの設計の話 CSSからサーバサイドのプログラミングまですべて、プログラマが担当するようになったとき、 まずオススメするのはシングルクラスのCSS設計です。 CSSはカスケーティングによって、記述をDRYにすることができますが、これはプログラミングの記述をDRYにする機能の継承やmixinよりも強力です。ですが、一歩間違うとすぐに設計が負債となってしまいます。 安易に継承しまくったオブジェクトの正体は突き止めにくいですよね? ですので、カスケーティングでクラスを記述する

    サーバサイドエンジニアがCSS設計をした話 — みんなのウェディングエンジニアリングブログ
    d4-1977
    d4-1977 2017/12/14
    CSSの設計の話。色々悩むところですね
  • 細かすぎるけど伝わってほしい私的BEMプラクティス30(ぐらい)

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

    細かすぎるけど伝わってほしい私的BEMプラクティス30(ぐらい)
  • 1