New here? Please allow us to introduce ourselves.Welcome to BBC UX&D. We do the layer between people and technology. Every day, we focus on the stuff that makes things special, as well as the stuff that makes things happen. The Futures Bazaar: A Public Imagination ToolkitExpand horizons, explore new ideas, and transform everyday objects into things from the future. Download your toolkit here.
コーディングで時間のかかる要素の1つとして、id,class名や画像名などの命名規則が挙げられます。 特に中規模、大規模のサイトで、適当な名前を付けると名前が被る確率が上がり、 その結果、画像の上書きや不要なプロパティがかかってしまうなど、よくない結果になることも考えられます。 一つの例として、私の命名規則について紹介してます。参考程度に読んで頂けると幸いです。 カテゴリに分類して、つなげる。 ページのどの位置に属すか分類し、つなげる方法を取っています。 基本的に、CSSや画像名は同じにします。同名にすることで、名前を考える手間も省け、変更箇所の特定がしやすくなります。 例: CSS #top-side-nav 画像 top-side-nav-home.png top-side-nav-company.png 上記のように命名することで、 デザインを見なくても、どのような箇所に使われている
Posted on 07 Dec, 2011 in Web Design? hail2u.netで使われているスタイルの解説兼プレビューのページです。スタイルのコードそのものについてはその公開リポジトリを参照してください。このページのマークアップにはおかしいところが多々ありますが、その多くはやむを得ない事情によるものです。 コンテンツの見出しはh2でマークアップされます。ブログでは見出しに続けてfooterが配置され、更新日時とカテゴリをそこで示します。 FacebookのLikeボタンやはてなスターはその対象の最後にまとめて配置されます。つまり、それらが記事に対するものの場合はarticle要素内の最後になりますが、ページに対するものの場合はdiv#mainの最後になります。対してAdSenseの広告は常に最初のセクションの直後に挿入します。 ベース ブラウザーのデフォルト・スタイルシー
ディレクトリ構造 ディレクトリ構造、ファイル構成は案件毎に最適な方法を検討 公開ファイルと公開不要なファイル(SASS や node_modules など)は明確に分ける 特に理由がなければ下記の形にし、読み込み順とスタイルの優先度に整合性がとれるように心がける root/ ├── dist/ └──index.html └──assets/ └──css/ └──images/ └──js/ └──lib/ └── src/ └──sass/ └──style.scss └──foundation (基本的となるスタイル) └──_global_var.scss └──_mixin.scss └──_reset.scss └──_font.scss └──layout (ヘッダ、フッタ、共通ナビ、カラム構造) └──_flex.scss └──_float.scss └──_nav-ma
画像基本はPNG8とJPEG、必要に応じてGIFを利用画像ファイルは基本的に、イラストなどはファイル容量が軽いためPNG8、写真はJPEGファイルを利用します。ただし、IE6以前で透過PNGが利用できないため、必要に応じてGIFを使い分けます。 HTML<!DOCTYPE HTML> <html> <head> <meta charset="UTF-8" /> <meta name="keywords" content="ホームページ制作,東京" /> <meta name="description" content="東京世田谷のホームページ制作会社。「声」をテーマに、御社の顧客満足向上に貢献するWebサイト制作をお手伝いします。" /> <title>エイチツーオー・スペース[H2O Space.] | ちゃんとWebなホームページ制作会社(東京・世田谷)</title> <link
■簡単な内容紹介 Accessibility/HTML/CSS/JavaScript/jQuery/について基本的な事や知っておくべき、意識しておくべき事などについて書かれたドキュメントです。 あちこち触れている感じなので、一つ一つは余り濃くない内容が多めです。 ■Accessibility What's Up, DOCTYPE? DOCTYPEがないのは論外として、今までは以下のようなスニペットを使っていた人もいるだろう。 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> HTML5ではもっとスリムにしたスニペットを利用できます。 このスニペットはモダンなブラウザはサポートしていますし、IE6とI
What's Up, DOCTYPE? The absence of a DOCTYPE is a crime punishable by death. You may have relied on the following DOCTYPE in the past, but it's important to know that this is now being superseded by a leaner and meaner snippet. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Ideally, the HTML5 DOCTYPE should be used. It's suppor
GitHub ディレクトリ構造 ディレクトリ構造、ファイル構成は案件毎に最適な方法を検討 ただし公開ファイルと公開不要なファイル(SASS や node_modules など)は明確に分ける 特に理由がなければ下記の形にする root/ ├── dist/ └── index.html └──css/ └──js/ └──images/ └── src/ └──sass/ └──style.scss └──_var.scss └──_mixin.scss └──_header-footer.scss └──_compo-list.scss └──_compo-table.scss └──_compo.scss └──_single-propery.scss └──_animation.scss 基本ルール 命名規則 ID名、クラス名、ファイル名で単語をつなぐ場合は -(ハイフン)を使用親要
XHTML+CSSのid/class名でキャメルケースを使うべきではない7つの理由を、CSS WIZARDRYの「CSS: CamelCase Seriously Sucks!」から覚え書きです。下記はその意訳です(間違っていたらすみません)。 はじめに 今、この記事が何人かの人をいらだたせることは分かっているし、私が普段どのようにコードを記述しているのか伝えたいのではありません。私はシングルラインCSSがキライです。ただ、明瞭で、道理にかなった、理解しやすく、首尾一貫したコードであるならば、そんなに文句を言うことはありません。私の目から見て最も重要なのは一貫性です。しかしながら、キャメルケースは、本質的に矛盾していることが明らかなのです。 1. CSSはハイフンで区切られた構文 CSSはハイフンで区切られた構文です。どういうことかというと、font-size、line-height、bo
仕様 原則としてXHTML1.0 Strictに準拠する。 要件に応じて、適宜XTHML1.0 Transitionalを用いる。 CSS2.1に対応する。 文字コードはUTF-8を採用する。 ブラウザ対応 推奨ブラウザ Internet Explorer 6以降 Firefox 2以降 Opera 9以降 Safari 2以降 これらのブラウザに関して、標準準拠モードを使用する(XHTMLガイドラインDOCTYPE宣言の項を参照)。 過去バージョンのブラウザへの対応 IE4、NN4、MacIE5以前のバージョンには、以下のようにCSSを適用させない措置をとる。 XHTMLファイルにおいて、CSSファイルを読み込むlink要素のmedia属性に複数の値を指定する(NN4対策)。 <link rel="stylesheet" type="text/css" media="screen, t
コーディングガイドラインの必要性 私もはじめはガイドラインの必要性を感じずにいました。しかし、コーディングを続けていくうちにじょじょに必要性を感じてくるようになりました。 なぜなら、コーディングガイドラインを定めないままコーディングした結果、自分で作ったものですらどういう構造になっているか分からなくなったからです。そのため、更新に手間取ってしまいました。 一人のときですらこの有様ですから、二人以上で作業を行うことを考えるとコーディングガイドラインの必要性は明らかでした。 その後、何度もコーディングガイドラインを改善してきました。 項目1 データを編集した人が誰か分かるようにする HTMLファイル・CSSファイルともに、作成者と更新者の名前と日付をセットにした署名を入れるようにしましょう。 そのデータを編集した人が誰で・いつ編集したのかをわかるようにすることで、ミスが起きたときに責任の所在が
Blog » WordPress » How and where to learn WordPress plugin development (FYI, we build plugins) How and where to learn WordPress plugin development (FYI, we build plugins) It can be overwhelming when you first try to get into WordPress plugin development. Honestly, one of the best ways to learn is just to dive right in and start coding. However, this is something that doesn’t just happen overnight.
自分的HTMLテンプレートの組み方と例です。 まぁ、やるたびにちょこちょこ変えてるんですけど、2009年7月版ってことでざっくり説明。 空テンプレ モジュール一覧 サンプル ダウンロード用 エリアとモジュール 繰り返し使用される要素の塊をモジュールと呼び、エリアの中にこれを並べてページを作成するのを基本とする。 モジュールの開始要素には、「mod_moduleName」のようにclass(もしくはid)をつける。 モジュールやエリアのclass/idを起点に全てのスタイルを指定する。p、h1~h6、blockquote、table等、要素自体に直にスタイルを指定してはいけない。(グローバル変数を使っているような状態になってしまうため、以降考慮するのが面倒。リセット程度に済ます。) モジュールにスタイルを指定する際には、mod_moduleNameを起点としてスタイルを指定し、カプセル化を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く