改行削除するくらいなら gzip したらいいじゃない
CSS や JavaScript ファイルなどを gzip 圧縮して転送量の削減や Web サイト表示速度の向上を実現する方法を解説。既存 Web サイトのソースには一切手を加えない方法でまとめています。おまけでキャッシュ関連の記述もあり。 いや、1バイトの無駄もゆるせねぇんだよとか、難読化したいとかなら別にやればいいんですけど、CSS や JavaScript ファイルの改行やスペースを削除しただけでファイル容量圧縮、読み込み速ーい的なこという人がいるので今さらですが書いてみます。すでに色々なところで書かれてるのでかぶるのは承知の上で。 改行や無駄なスペースなどを削除すること自体が悪いと言ってるわけではありませんのでその辺は誤解ないようにお願いします。ただ、gzip 使って圧縮するのに比べたら、改行削除して削れるファイルサイズなんて微々たるものです。もちろん、両方やれば最大限ファイルサイ
新しくWebサイトを作る際に疑いたい制作側の常識
ここ最近クライアントの受託制作や自社のWebサービスでユーザー様の声を見ていて気がついたことがあるので書いてみます。 iPadやスマートフォンの普及でWebサイトがより身近になってきて、今までPCを起動するのが面倒だった方まで気軽にインターネットを使うようになってきています。 その分、Webサイトを作るにもいろいろなことを配慮しないといけなくなってきています。 デザイン、インターフェイス的に各媒体に最適化されていることも大事ですが、Webサイトを見慣れている人の常識というのを少しづつ疑って、見直していく必要があると思うのです。 制作側の常識が通じないとネットリテラシーが低い、などとまとめてしまうような風潮もありますが、そのリテラシー自体見直すべきなんじゃないかな？なんて思ったりもします。 実際にWeb制作業界ではない色々な方のご意見をうかがったうえで、Web制作をする際に、自分たちが割と「
CSS： marginの正しい理解 - kojika17
toggle()や変数、calc、:matchなど、今までにないCSSプロパティ、セレクタが提案・実装されて、CSS3, CSS4も楽しくなってきています。 border-radiusや、box-shadowなども、古いAndroidブラウザ以外なら、prefixなしで使える状況も増えてきました。 最新技術は、これから必要になってくるかもしれませんが、基本も大切です。 float や position など、CSSコーディングを悩ませるタネはいくつもありますが、今回はその中でも私がCSSで一番難しいと思う margin について書きます。 「marginはバグが多い」という声をたまに聞きます。 しかし話を聞いてみると、正常な動作をバグと間違って認識しているケースもあります。 marginを正しく理解することによって、効率的なレイアウトを構築できますので、基本的な内容ですが、読んで頂ければ幸
-webkit-border-radius なんて書いているWeb開発者は腹を切って死ぬべきである - hogehoge @teramako
地獄の火の中に投げ込むものである。 いや、まあそんなネタはどうでも良くて... そのベンダー接頭辞はいつまで書くの？ | Unformed Building 書いてあることは至極真っ当なこと。もろ手をあげて賛成である。 また、 ベンダー拡張プリフィックスはそれそのものがWebを破壊することはないし、ベンダー独自のプロパティーや関数が数万追加されて使われまくったとしても本当はWebは壊れない。またその文法が変更されても修正または追加すれば対応できるし、その余裕は十分にある。つまり壊れるのはほとんど全てのケースで開発者の怠慢に過ぎないので、ちゃんと仕様と実装を理解して必要ならば寝る間を惜しんで修正作業に血眼になるべき。みたいな実践を伴わない意識を僕は持っている。 なので憂うべきこの現状は、IE6が拡散して残り続けたことと同じようにベンダー側ではなくWeb開発者側に非があると思っている。 ベンダ
レスポンシブにデザインするために克服すること : could
画像の課題は解決されつつある 先日 Web担当者 Forum で、レスポンシブ・ウェブデザインの功罪とモバイルファースト という記事が掲載されました。Media Queries を活用するなど実装のための概要を説明した上で、非表示だけど読み込まれているから膨大な画像素材が存在する PC サイトのレスポンシブデザインは不適切であると書かれています。 現存の Web サイトを Media Queries だけでレスポンシブ・ウェブデザインをするのであれば、Web担当者 Forum での指摘は間違っていませんが、実際のところレスポンシブにデザインすることは、Media Queries による対応だけではありません。例えば、画像の表示のさせ方を工夫すれば、記事で指摘している課題はある程度解決できます。Web担の記事からもリンクされている CSS Rador でも取り上げられている解決策もありますが
文字拡大/縮小機能の実装を外しました｜ウェブユーザビリティ向上を支援するWebsite Usability Info
コラム記事「Webページにおける文字の拡大/縮小機能」で述べたように、当サイトでは、グローバルナビゲーションエリアに[文字拡大]、[縮小]、[標準]というリンクを設けて、文字（テキスト）のサイズを任意に設定できるようにしていました。 ブラウザの文字拡大機能が一般ユーザーに意外と知られていなかった（ブラウザのメニューの中に隠れていて認知度が低かった）ことへの対策として、それなりに意義があったと思いますし、「文字拡大/縮小機能を使うときは代替手段も明示する」で述べたような、JavaScriptが使えない環境のユーザーへの配慮もしていたので、アクセシビリティ対策としては、悪くないソリューションだったと考えています。 しかしながら当サイトでは、熟考を重ねた結果、このたび、この文字拡大/縮小機能の実装を外すことにしました。理由は、以下の通りです。 「Webページにおける文字の拡大/縮小機能」で述べ
コーディング前に確認しておきたいこと。 - CSS HappyLife
CSS HappyLife ZERO が移転したのでお手数ですが、消えちゃう前にブックマーク等変更してもらえるととても嬉しいです。 制作会社でコーディングする場合、社内のガイドライン的なのが有ったりデザイナーもある程度固定されてると思うので、毎回似たような事を確認したりとか、このデザインはどういう意図なんだろう？ってのも、何度か同じ人とやってれば見えてくる訳ですが、フリーランスの場合だとデザイナーは毎回違っていたり、当然ディレクションをする人も違うので最初に確認しておきたい事が有ったりします。 って事で、その辺りをまとめてみたり、デザインを渡されたときにこのデザインの意図は？って思う事とかもばーっと書いてみます。はい。 なので、デザイナーさんもコーダーにデザインを渡すときに気をつけて欲しい点とかもわかってしまうすばらしい内容（だと良いな）！ じゃあまずは最初に確認しておきたい基本的なことか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
