It’s Time To Talk About “CSS5” — Smashing Magazine
Have you ever wondered what happened after CSS3? It’s common knowledge that we never saw CSS4 come after it, yet we have a plethora of new features that have no similar way of defining when they were introduced. The W3C CSS-Next community group is actively searching for better approaches for how we describe the evolution of CSS over time and identify feature sets as effectively as we did with CSS3
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
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
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 technologies that have been introduced: CSS variables and JS utilities. This has led to added overhead in how these technology layers
ヤフー株式会社におけるWebフロントエンドの技術選定 - Yahoo! JAPAN Tech Blog
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo! JAPAN Tech Advent Calendar 2018の6日目を担当します、Webフロントエンドエンジニアをやっている向井(@sakito)です！ 今回はヤフー株式会社でWebフロントエンドエンジニアがどのような取り組みを行なっているのかをお伝えします。 ヤフーの組織体制 Webフロントエンドエンジニアの取り組みを紹介する前に、ヤフーがどのような組織体制なのか紹介します。 冒頭画像のようにヤフーではカンパニー制度を取り入れており、それぞれのカンパニーにサービスを開発する事業本部があり、この事業本部単位でデザイナーやエンジニア、そのほかにもさまざまな職種の方が所属し、サービスごとで日々開発に取り組んでいます。
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
Firebase, React, FluxでWebアプリ作って思ったこと - Qiita
ここで書いてること タイトルの構成でWebアプリ作った際に思ったこと 作り方ではないのでコードは一切書いてない 作り方的なのも書きたいけど多分無理 きっかけ 2016年は結構ダラダラしてた 仕事以外ではほとんど何も書いてない 夏以降は筋トレのことばっか考えてた おかげで筋肉はついたよ そろそろ何か始めようかと思った 何を作ったか 何をはさほど重要ではなかった 今回重視したのは何を触るか Redux(Flux) React Webpack Firebase postcss 結局作ったのはメモ帳でした Redux ReduxというかFluxでちゃんと作ってみたかった Reduxのチュートリアルはやった 公式ドキュメントは読んだ Fluxを調べる内に@azu_reさんの10分で実装するFluxに辿り着いた これで良いじゃない Fluxの実装面をちゃんと理解して書ける 別にReduxを使わなくても
ウェブ組版は行間が基準なのではという話 - note
以前見かけたこの記事がきっかけで、実務でもずっと引っかかっていたことがあるので書こうと思う。 ＞ remの基準となる値を行の高さにする | yoshihiko com-blog 行間 ≠ line-height という罠よくある疑問に、日本語で言う「いわゆる行間」と、CSSの「line-height」は違うというのがある。日本語の文章は、仮想ボディが基準の原稿用紙のようなグリッドがあって、それが「いわゆる行間」のピッチで繰り返されて本文ができている。文字の頭（仮想ボディの上）から次の文字の頭までがいわゆる行間とされている。もっと正確に書くと、これは行送りであって、正確な意味での行間は line-gap というものになる。 行送り= line-height、行間= line-gapで、一方ラテン語圏が基本のウェブ（CSS）では、この line-gap のくっつき方が純粋な日本語組版とは異なっ
スタイル・ガイド・ジェネレーターについて
僕は以前からJavadocを踏襲した形のスタイル・ガイド・ジェネレーターには構造的な欠点と思想的な欠点を持っていると考えている。実際にはスタイル・ガイドを中心としたウェブ制作体制をよく利用すること、そしてその中での作業を自動化してくれるであろうジェネレーターには期待していること、はあらかじめ断っておきたい。 構造的な欠点は、コメントとして埋め込まれることになるであろうHTML断片が重複しやすいこと、だ。コンポーネントという単位ではまず重複することはないが、コンポーネント間で共有するクラスでは必ず重複することになる。もちろんコメントに埋め込むコードは短いもので、場合によっては軽量マークアップ言語を利用できるため、コストとしては微々たるものだ。しかし単純な繰り返し作業を省力化するための自動化ツール(ジェネレーター)が、そういったまた別の単純な繰り返しを強いるというのはどこかがおかしいと感じる。
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. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/sebmarkbage/status/1529622371333709825
CSS for Software Engineers for CSS Developers