[B! opinion][CSS] efclのブックマーク

efcl id:efcl

opinionとCSSに関するefclのブックマーク (11)

Airbnb’s Trip to Linaria
CSS is a critical component of every web application, and many solutions have evolved for how styles are written by developers and delivered to visitors. In this post we’ll take you through Airbnb’s journey from Sass to CSS-in-JS and show you why we landed on Linaria, a zero-runtime CSS-in-JS library, and the impact it has had on the developer experience and performance of Airbnb’s web app. From S
efcl 2022/10/31
AirbnbでCSS-in-JSとしてreact-with-stylesを開発し使っていたが、パフォーマンスとメンテナンス性の問題から、Linariaへ移行していくという話

CSS

article

opinion
リンク
Why We're Breaking Up with CSS-in-JS
Hi, I'm Sam — software engineer at Spot and the 2nd most active maintainer of Emotion, a widely-popular CSS-in-JS library for React. This post will delve into what originally attracted me to CSS-in-JS, and why I (along with the rest of the Spot team) have decided to shift away from it. We'll start with an overview of CSS-in-JS and give an overview of its pros & cons. Then, we'll do a deep dive int
efcl 2022/10/31
CSS-in-JSのランタイムパフォーマンス問題についての記事。

CSS

JavaScript

article

opinion
リンク
https://twitter.com/sebmarkbage/status/1529622371333709825
efcl 2022/05/26
Atomic CSSはスタイルのパースが1回になるため、style属性にインラインで書くよりもパフォーマンスが良いという話。

CSS

JavaScript

opinion

performance
リンク
Replacing Sass · Discussion #44 · Shopify/foundational-design-system-proto
We’ve noticed several growing pain points to using Sass at scale. Some of these apply to Polaris and teams using Polaris, while others impact development across Shopify. In Polaris, the original Sass variables, functions, and mixins are creating a burden with newer techno logies that have been introduced: CSS variables and JS utilities. This has led to added overhead in how these techno logy layers
efcl 2021/08/08
ShopifyのDesign SystemであるPolarisにおけるCSSフレームワークの選定についての議論。 Sassを置き換えるためにTailwind CSS、CSS Modules、Stitches、vanilla-extractを比較している。 vanilla-extractを有力候補として選択している。

CSS

opinion

issue
リンク
ヤフー株式会社におけるWebフロントエンドの技術選定 - Yahoo! JAPAN Tech Blog
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech BlogYahoo! JAPAN Tech Advent Calendar 2018の6日目を担当します、Webフロントエンドエンジニアをやっている向井(@sakito)です！今回はヤフー株式会社でWebフロントエンドエンジニアがどのような取り組みを行なっているのかをお伝えします。ヤフーの組織体制 Webフロントエンドエンジニアの取り組みを紹介する前に、ヤフーがどのような組織体制なのか紹介します。冒頭画像のようにヤフーではカンパニー制度を取り入れており、それぞれのカンパニーにサービスを開発する事業本部があり、この事業本部単位でデザイナーやエンジニア、そのほかにもさまざまな職種の方が所属し、サービスごとで日々開発に取り組んでいます。
efcl 2018/12/11
ヤフー株式会社における各サービスごとのフロントエンドに利用しているフレームワークやライブラリなどについて。それぞれの技術を選定した理由などについてもまとめられている。

JavaScript

CSS

company

opinion
リンク
A Unified Styling Language
In the past few years we’ve seen the rise of CSS-in-JS, emerging primarily from within the React community. This, of course, hasn’t been without its controversies. Many people, particularly those already intimately familiar with CSS, have looked on in disbelief. “Why would anyone want to write CSS in JS? Surely this is a terrible idea! If only they’d learn CSS!” If this was your reaction, then rea
efcl 2017/06/05
> Why CSS-in-JS?

CSS

opinion
リンク
Firebase, React, FluxでWebアプリ作って思ったこと - Qiita
ここで書いてることタイトルの構成でWebアプリ作った際に思ったこと作り方ではないのでコードは一切書いてない作り方的なのも書きたいけど多分無理きっかけ 2016年は結構ダラダラしてた仕事以外ではほとんど何も書いてない夏以降は筋トレのことばっか考えてたおかげで筋肉はついたよそろそろ何か始めようかと思った何を作ったか何をはさほど重要ではなかった今回重視したのは何を触るか Redux(Flux) React Webpack Firebase postcss 結局作ったのはメモ帳でした Redux ReduxというかFluxでちゃんと作ってみたかった Reduxのチュートリアルはやった公式ドキュメントは読んだ Fluxを調べる内に@azu_reさんの10分で実装するFluxに辿り着いたこれで良いじゃない Fluxの実装面をちゃんと理解して書ける別にReduxを使わなくても
efcl 2017/02/22
Firebaseをバックに色々書いた触感的な話

React

Flux

CSS

PostCSS

opinion
リンク
CSS for Software Engineers for CSS Developers
Applying traditional software engineering principles directly (or indirectly) to CSS.
efcl 2016/08/20
CSSにおけるSOLIDの原則のような開発指針についてのスライド。 DRY、単一責任の原則、関心の分離、Immutability、Open/Closed、直交性など

●CSS

●設計

●opinion
リンク
ウェブ組版は行間が基準なのではという話 - note
以前見かけたこの記事がきっかけで、実務でもずっと引っかかっていたことがあるので書こうと思う。＞ remの基準となる値を行の高さにする | yoshihiko com-blog行間 ≠ line-height という罠よくある疑問に、日本語で言う﹁いわゆる行間﹂と、CSSの﹁line-height﹂は違うというのがある。日本語の文章は、仮想ボディが基準の原稿用紙のようなグリッドがあって、それが﹁いわゆる行間﹂のピッチで繰り返されて本文ができている。文字の頭︵仮想ボディの上︶から次の文字の頭までがいわゆる行間とされている。もっと正確に書くと、これは行送りであって、正確な意味での行間は line-gap というものになる。行送り= line-height、行間= line-gapで、一方ラテン語圏が基本のウェブ︵CSS︶では、この line-gap のくっつき方が純粋な日本語組版とは異なっ
efcl 2016/05/11
> remの値に font-size ではなく line-height をつかう line-heightとline-gapと行間

CSS

opinion
リンク
スタイル・ガイド・ジェネレーターについて
僕は以前からJavadocを踏襲した形のスタイル・ガイド・ジェネレーターには構造的な欠点と思想的な欠点を持っていると考えている。実際にはスタイル・ガイドを中心としたウェブ制作体制をよく利用すること、そしてその中での作業を自動化してくれるであろうジェネレーターには期待していること、はあらかじめ断っておきたい。構造的な欠点は、コメントとして埋め込まれることになるであろうHTML断片が重複しやすいこと、だ。コンポーネントという単位ではまず重複することはないが、コンポーネント間で共有するクラスでは必ず重複することになる。もちろんコメントに埋め込むコードは短いもので、場合によっては軽量マークアップ言語を利用できるため、コストとしては微々たるものだ。しかし単純な繰り返し作業を省力化するための自動化ツール(ジェネレーター)が、そういったまた別の単純な繰り返しを強いるというのはどこかがおかしいと感じる。
efcl 2016/03/08
CSSのスタイルガイドジェネレーターについて

CSS

opinion

document
リンク
ID使っても別に問題ない
CSSでID使うの良くない……どころか、ID使うのはゴミクズカスみたいな風潮で辛い。その根拠はいくつかあり、それらはCSSだけをただそのまま書く場合には納得出来ないこともないかなーと思うので余計に辛い。特にOOCSSのようなアプローチではIDは混ぜるな危険。だからといってIDを使わないのがベスト・プラクティスなわけじゃない。 CSS Lintの利用が広まり、これがID使うなって怒るのも原因の一端な気がする。Disallow IDs in selectorsではIDの問題点として以下のようなものを取り上げている。 However, IDs have a downside: they are completely unique and therefore cannot be reused. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
efcl 2013/09/15
#CSS IDセレクタのユニーク性について

CSS

opinion
リンク
1