Tokyo Otaku ModeがStylusを使う理由 | Tokyo Otaku Mode Blog
Здравствуйте! Tokyo Otaku Modeでフロント周りを担当している今吉です。 社内でロシア人という設定を付けられていますが、ロシア語は挨拶くらいしかできません。 Webサイトを作るのに避けて通れないのがCSSだと思います。エンジニアも多かれ少なかれCSSを書く事があるかと思います。 しかし、CSSを書くのはとても面倒くさいです。出来る限り楽をしたいと常々思っています。そこで、CSSプリプロセッサを導入してCSSを作成している方も多いでしょう。CSSプリプロセッサとは、乱暴に言ってしまえばCSSをクールにラクに書く事ができる言語です。(設計が素晴らしく、COOLなCSSというものも、もちろんあるとは思いますが、これは一旦置いておきます。) 恐らく最も知られているものは、LESSとSass/Scssでしょう。 しかし、Tokyo Otaku Modeでは、Stylusとい
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
チャットワークがLESSを使う理由 | チャットワーククリエーターズブログ
ChatWork デザイン部の赤堀巴絵です！ ChatWork Advent Calendar５日目を担当します〜。 ご存知の方もいらっしゃると思いますが、チャットワークアプリ側はLESSで運用されています。なんでLESSで運用してるの？と聞かれることがあるのでブログで紹介したいと思います。 チャットワークがLESSを選んだ経緯まずCSSプリプロセッサの導入を社内で検討し導入しようとなった時期が2011年11月頃でした。導入にあたって問題になったことがありました。 社内のOSの開発環境がWinとMacでバラバラ社内でCSSプリプロセッサの知識が浸透していないまず、SassだとみんなにRubyをいれてもらうというハードルがありました。スタイルシートはデザイナーもコーダーもシステムエンジニアも触る状況だったので全員の環境に合わせて構築するのが難しいと考えました。 また、社内でまだCSSプリプロ
CSS拡張メタ言語「SCSS(Sass)」と「LESS」の比較 - (DxD)∞
CSSを拡張するためのメタ言語として、代表的なものに「SCSS(Sass)」と「LESS」があります。今回、導入を検討するにあたり、両者を比較しました。 結果的には、「SCSS(Sass)」を導入することにしましたが、特に「SCSS(Sass)」を選択する決め手となった点に重点を置きつつ、両者の違いをまとめまてみました。 はじめに Webサイト、Webアプリケーションが大規模になるにつれて、CSSの設計・管理にもリソースを割かれるようになります。CSSのモジュール化、コンポーネント化による再利用性を考えたとき、現状のCSSを取り巻く状況は十分とは言えません。 一つの選択肢としてあがるのが「Blueprint」や「960 Glid System」等のCSSフレームワークの利用ですが、その再利用性と構造・表現の分離度はトレードオフです。 そこで、CSSの利点を活かしつつ、再利用性を高めるために
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モダンなCSS設計パターンを考える
http://atnd.org/events/21919
