スマホでも使える！パフォーマンスアップの為のCSS記述方法
「CSS Lint」は、CSS記述方法によるパフォーマンスをチェックできるツールです。開発したのは、Yahoo!、 Facebook でパフォーマンスチームだった Nicole Sullivan（ニコール・サリバン）です。Web Directions East 2009 で来日したこともあります。 モバイル端末の普及によって、回線速度が十分でない3GでもWebを快適に利用する為には様々な対策を講じる必要になってきました。テキスト量の制限からCSS, HTML, JS の最適化も重要な対策事項です。 このツールは、CSSの記述方法についてのパフォーマンスの側面から検証ができます。 チェックボックスで検証したい項目を自由に選択できますので自分で意図して検証にひっかかるCSSの記述を利用している項目があれば、予めチェックを外しておくことをオススメします。 下記にCSS LINT のドキュメントを
CSS LINT での警告 "Don't use IDs in selectors" について - {u:b}
今話題の CSS LINT (http://csslint.net/) ですけども。 チェックすると warnings で "Don't use IDs in selectors" って出るんですね。 理由を見てみるとこんなことが書かれていました。 IDs shouldn't be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It's much preferred to use classes in selectors and then apply a class to an element in the page. 簡単に訳してみると (あってるかどうかは分からない) セレクタ内で ID を使用しないでください。こ
スタイルシートを書く時のガイドライン - 2xup.org
2006-07-11T19:56:28+09:00 会社ではやっているのだけれど、自分のウェブサイトでもやってみよう。と簡略記述を利用する場合の値の順序やらもまとめとく必要があるのかもしれないけれど、セットフォーマットルールやプロパティの順番だけをサクッとまとめて資料にしてみました。課題は残したもののこれだけでも相当すっきり。詳細やセットフォーマットルールに関しては、ダウンロードできるようにしている資料を参考にしていただくとして、このエントリーではプロパティの順序についてまとめることに。自分自身が実際に作業を進めていくことを考慮し、その考えに基づいて設定したモデル別の順序は以下の通り。 生成 内容, 自動番号付け及びリスト (Generated content, Automatic numbering, and Lists) 利用者インターフェイス (User Interface) ビジュ
Code Style Guidelines
ContentsIndentationSpacingLine breakingBracesNull, false and zeroFloating point literalsNamesOther PunctuationPointers and References#include Statements"using" StatementsLambdasTypesClassesSingleton patternCommentsOverriding Virtual MethodsPython Indentation Use spaces, not tabs. Tabs should only appear in files that require them for semantic meaning, like Makefiles. The indent size is 4 spaces. R
Code Guidelines for Rich Internet Application Development
By Garrett Smith, with contributions from Asen Bozhilov, RobG, John G Harris, David Mark, and Dmitry Soshnikov. Abstract This document points to the causes of errors and problems related to javascript for web applications and provides explanation of what to do instead. When followed, these guidelines can improve the code stability and maintainability of a Rich Internet Application deployed across
Code Conventions for the JavaScript Programming Language
https://www.crockford.com/code.html
Dojo Style Guide - The Dojo Toolkit
Contents: General Quick Reference Naming Conventions Specific Naming Conventions Files Variables Layout Documentation This document follows the basic outline of the Java Programming Conventions Guide, a copy of which may be found at http://geosoft.no/javastyle.html. Widget authors are expected to adhere to this style guide and also to the Dojo Accessibility Design Requirements guidelines. General
JavaScript Style Guide | Contribute to jQuery
If the project supports browsers which do not implement ES5, then the es3 option must be included with the repo-specific options. link SpacingIn general, the jQuery style guide encourages liberal spacing for improved human readability. The minification process creates a file that is optimized for browsers to read and process. Indentation with tabs. No whitespace at the end of line or on blank line
Google JavaScript Style Guide
Revision 2.2 Aaron Whyte Bob Jervis Dan Pupius Eric Arvidsson Fritz Schneider Robby Walker This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there's a "toggle all" at
JavaScript style guide - Mozilla | MDN
else は上で示したように常に単独の行に書いてください。 return の後には else を使わないでください。 if (x < y) return -1; if (x > y) return 1; return 0; i++ も ++i も使用可能です。 インライン関数はそのデバッグが楽になるように名前を付けてください。関数をプロパティに代入しただけではその関数に名前を付けることはできません。次のようにしてください。 var offlineObserver = { observe: function OO_observe(aSubject, aTopic, aState) { if (aTopic == "network:offline-status-changed") setOfflineUI(aState == "offline"); } }; 名前や列挙値には interCap
JavaScriptのいろいろなコーディングルールをまとめてみた
JavaScriptの書き方はJavaScript自体がある程度自由なためいろいろな書き方ができますが、一貫性を持って書いた方がバグなども発生しにくくなるため、コーディングルールを定めておくのはよいことだと思います(特に複数人の開発の場合) 有名な企業やライブラリはコーディングルールも公開している事が多いので適当にまとめてみました JavaScript style guide – MDC Docs Mozilla/Firefox向けのものなので、一部ECMAScriptの範囲を超えたものも含まれています。 多くの人が見ていると思うので、見たことない人は一度読んでみるといいです。 jscsにこのコーディングルールをチェックするプリセットが用意されています。 Google JavaScript Style Guide Google JavaScript Style Guide 和訳 — Goo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
style.html