【jQuery】 slick カルーセルスライダーを使ってみる

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-11-10-14-50


%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-11-10-12-46

システム部の渡辺です。

設定が楽で使い回せるスライダーを探してました。

レスポンシブ対応が細かくできて、
自前で何かを書き足さなくてもすむスライダーの候補として
slick.js はけっこういいです。

slick 公式

サンプル

よく使うスライダーの代表例のサンプルを作成してみました。

レスポンシブ対応

最近の案件はほぼレスポンシブなので、
PC、タブレット、スマホの設定を、わかりやすく簡単に設定できるかがポイントだと思いますが、例えば「768px 以下になった時には2列に変更」などといった指定を複数できる setting が用意されてあり、重宝しそうです。


$('.slick-3').slick({
  responsive: [
    {
      breakpoint: 959,
      settings: {
        slidesToShow: 3,
        slidesToScroll: 3,
      }
    },
    {
      breakpoint: 768,
      settings: {
        slidesToShow: 2,
        slidesToScroll: 2,
      }
    },
    {
      breakpoint: 470,
      settings: {
        slidesToShow: 1,
        slidesToScroll: 1,
      }
    }
  ]
});

その他

タブ切り替え機能を、用意されている setting ですぐできます。( asNavFor )

スライドさせる列に、div などではなく、いきなり img 要素を指定すると、妙な動きがある気がするので、 div の方がよさそう。どうせだから .slick-slide というデフォクラス名つけておくとロード時の崩れ防止になる様子。

IEの画像縮小がきれいに表示されない理由

システム部渋谷です。

このごろはレスポンシブデザインでのWeb制作が当たり前のようになってきました。
レスポンシブデザインでは閲覧環境に合わせて見え方を変える都合上、大きな画像を用意してそれをブラウザ上で縮小させて表示することになります。

「レスポンシブで縮小した画像がIEだけ汚い…」

古いIEが消えてだいぶましな描画がされるようになったほのぼのIEだったのですが、またしても問題に!

berry

この画像を各ブラウザで縮小してみてみると…

hikaku

あたかもニアレストネイバーで縮小したかのような汚さなのですが……。
(縮小したものをニアレストネイバーで2倍に拡大しています)

各ブラウザの画像補完について

どういう処理をしているのかを調べるために、画像を縮小拡大になんのアルゴリズムを使ってるのか見てみました。

kakudai

上の画像は、小さい画像を大きく表示させた場合どう表示されるかを表したものです。
8×8の小さな画像を256×256に引き延ばしています。
上段はPhotoshopで作った参考画像で、下段は各ブラウザでの表示結果。

もしかしたら画像によって、または縮小と拡大によって切り替えているかもしれませんが、
IE11:バイリニア
Edge:バイリニア
Chrome:バイキュービック
Firefox:バイリニア
という結果でした。
バイリニア以上を各ブラウザがデフォルトとして使ってることは確定のようなのでそんな汚くならないと思うんだけどなぁ…と。

今度は別な画像を使っての縮小テスト。
しましまな横512の画像を横63に縮小表示させています。
割り切れない微妙な数字にするのがポイント。

shukushou

IEとEdgeだけ妙な縞になってます。

バイリニアでは求める位置のピクセルと周囲の1ピクセルを線形的に補完するため、半分以下の大きさに縮小する場合一度半分の大きさにして、そこから再帰的に小さくしていかないときれいな画像になりません。
(無視して捨てられるピクセルがたくさん出てくる)

元の画像が大きければ大きいほどニアレストネイバーに表示結果が近づいていくことになります。
そのぶん処理は軽くなりますが。

上記結果からの推測になるのですが、おそらくIEは処理を軽くするために意図的に2回目以降の縮小処理を省いているのではないでしょうか?

……あくまで推測ですが。

ChromeとFirefoxでは画像が半分まではしましま、半分以下はどのサイズでもグレー1色になりました。

結局のところ対処法は…

元の画像の半分の大きさになるまではきれいに縮小されるので、半分以下の大きさにならないように気を付ける必要がありそうです。

ウェブアクセシビリティのJIS規格対応2

システム部の渡辺です。

前回記事「
ウェブアクセシビリティのJIS規格対応」の続きで、

具体的な作業に関する部分を書きたいと思います。

アクセシビリティのJIS規格「JIS X 8341-3」の詳細がわかる公開されているページは現在、


公式ページ「実装チェックリストの例 2012年11月版」

になります。

38項目のリンク先ページに約10個ぐらいの対応内容が書かれていますので相当な量になりますが、基本的に常識的なWEB制作をしていれば大抵のものはクリアできるかと思います。

私個人の判断で、


「あまり一般的ではない内容」


「登場頻度が多く、うっかり忘れてしまいそうな内容」

「デザイン時」「コーディング、特にベース部分制作時」「コーディング、特に各ページの制作時」に分けてピックアップすると下記の表のようになりました。

もし参考になりましたら幸いです。

  • ※ 上記は動画に関する項目は省いています。サイト内に動画を設置する場合は気をつける点が増えます
  • ※ 「達成基準」の部分を、公式ページへのリンクにしています。

デザイン時に気をつける項目

番号 達成基準 状況 項目の内容 説明 追記 等級
7.1.3.3 感覚的な特徴に関する達成基準 理解すべき情報を感覚的にだけ伝えることのないように、テキストでも情報を伝える 「フォームを送信するには、次へと記された円形のボタンを押して下さい」など操作方法を説明するようなシーンで、その「ボタン」の説明には、形や大きさ又は相対的な位置についての情報がない場合でも、アイテムを見つけて特定するための追加情報を含めましょう。 A
7.1.4.1 色の使用に関する達成基準 状況 A: 特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合 色の違いで伝えている情報をテキストでも入手可能にする 色によって伝えられている情報は、テキストでも説明するようにしましょう。 A
7.1.4.1 色の使用に関する達成基準 状況 A: 特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合: テキストの色の違いで情報を伝える際は、視覚的な手がかりを補足する A
7.1.4.1 色の使用に関する達成基準 状況 A: 特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合: リンク又はコントロールを色だけで識別している箇所の視覚的な手がかりを補足するために、周囲にあるテキストとのコントラスト比を 3:1 以上にする A
7.1.4.1 色の使用に関する達成基準 状況 B: 情報を伝える画像の中で色を用いている場合: 色とパターンを併用する 色を用いて伝達されている情報の全てに、色に依存しないパターンも併用しましょう。 A
7.1.4.1 色の使用に関する達成基準 状況 B: 情報を伝える画像の中で色を用いている場合: 色の違いで伝えている情報をテキストでも入手可能にする 画像の中であっても、色によって伝えられている情報は、テキストでも説明するようにしましょう。 A
7.1.4.3 最低限のコントラストに関する達成基準 状況 A: 太字でないテキストが18ポイント(日本語は22ポイント)未満、太字のテキストが14ポイント(日本語は18ポイント)未満の場合: テキスト(及び画像化された文字)とその背景の間に、少なくとも4.5:1のコントラスト比をもたせる 小さい文字は、コントラスト 4:5:1 もたせましょう

ロゴか装飾的なテキストは例外
AA
7.1.4.3 最低限のコントラストに関する達成基準 状況 B: 太字でないテキストが少なくとも18ポイント(日本語は22ポイント)、太字のテキストが少なくとも14ポイント(日本語は18ポイント)の場合: テキスト(及び画像化された文字)とその背景の間に、少なくとも3:1のコントラスト比をもたせる 文字が大きいならコントラストは 3:1 もたせましょう AA
7.2.4.6 見出し及びラベルに関する達成基準 目的や内容が分かるラベルを提供する サイト内で、入力を受け付ける input 属性には適切なラベルを表示しましょう AA

コーディング、特にベース部分制作時に気をつける項目

番号 達成基準 状況 項目の内容 説明追記 等級
7.1.1.1 非テキストコンテンツに関する達成基準 状況F:

非テキストコンテンツを支援技術が無視するようにしなければならない場合:
CSSで指定する画像は、装飾的なものだけである 意味のあるテキストやアイコンを、CSS だけで表示してしまうと、CSSを無効にした場合に表示されないので避けましょう。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
CSSを用いて構造と表現を分離する ブラウザの CSSをオフにして、情報が伝わることを確認しましょう A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
h1要素~h6要素を用いて、見出しを特定する A
7.2.1.1 キーボード操作に関する達成基準 JavaScriptでイベントハンドラを用いる場合は、キーボードで操作できるようにする

ただし、軌跡に依存した入力を要する機能(お絵描きプログラム等)は除く
キーボードだけで操作して、すべて操作可能であることを確認しましょう。

例)

キーボードでリンクを選択できる。

キーボードでリンク移動ができる。

メニューなど mouseover で表示されるサブメニューがある場合は、focus イベントも追加して、キーボードで操作できるようにする。
A
7.2.1.2 フォーカス移動に関する達成基準 利用者がコンテンツ内に閉じ込められないようにする A
7.2.4.1 ブロックスキップに関する達成基準 以下のいずれかを用いて、繰り返されるブロックをスキップ可能にする

1) 以下のいずれかを用いて、繰り返されるブロックをスキップするリンクを作成する

a) メインコンテンツへ直接移動するリンクを各ページの先頭に追加する

b) 繰り返しているコンテンツのブロックの開始位置に、そのブロックの終了位置へのリンクを追加する

c) ページの先頭に、コンテンツの各エリアへのリンクを追加する

2) 以下のいずれかを用いて、スキップ可能な方法で繰り返されるブロックをグループ化する

a) コンテンツの各セクションの開始位置に見出し要素を提供する

b) 構造を示す要素を用いて、リンクをグループ化する

c) frame要素を用いて繰り返しているブロックをグループ化し、frame要素にはtitle属性を付与する

d) 展開可能及び折り畳み可能なメニューを用いてコンテンツのブロックをバイパスする
A
7.2.4.3 フォーカス順序に関する達成基準 TABキー又は矢印キーを用いて、フォーカスを受け取る要素を移動し、その順序が意味及び操作性を保持していることを確認する。 レスポンシブウェブデザイン時では特に注意した方がよさそうな点。 A
7.1.4.4 テキストのサイズ変更に関する達成基準 以下のいずれかの実装方法を用いて、コンテンツ又は機能を損なうことなく、テキストを支援技術なしで 200%までサイズ変更できるようにする(ただし、キャプション及び画像化された文字は除く)

ユーザーエージェントの機能を用いて拡大できるコンテンツを作成する

コンテンツを拡大するためのコントロールを提供する

コンテンツ又は機能を損なうことなく、テキストを支援技術なしで 200% までサイズ変更できることを確認する(ただし、キャプション及び画像化された文字は除く)。
忘れると後からの修正が大変な項目です。

文字を 200% 拡大して、隠れる文字がないかを確認する

ブラウザによっては文字だけではないズーム機能も用意されているが、この場合は「文字だけを200%に拡大」した際に、コンテンツの意味が失われないように気をつけましょう。

具体的な作業としては、文字を含む要素には高さを指定せずに、縦幅リキッドレイアウトを意識してコーディングします。
AA
7.1.4.5 画像化された文字に関する達成基準 例外に該当しない文字は、画像化しない

いずれかを満たす場合は例外とする
画像化された文字が利用者の要求に応じて視覚的にカスタマイズできる



または

文字の特定の表現が、伝えようとする情報にとって必要不可欠である(ロゴタイプを含む)
7.2.4.6 見出し及びラベルに関する達成基準 内容が分かる見出しをつける

(見出しがある場合は、その内容が適切かを確認する。)
AA
7.2.4.7 視覚的に認識可能なフォーカスに関する達成基準 すべてのコントロールでフォーカスインジケータが視覚的に認識可能にする

キーボードのtabキーを押下し、フォーカスインジケータを移動させた場合に、すべてのコントロールにおいてフォーカスインジケータが視覚的に認識できるか、または、認識できるようにキーボードで変更する機能を有することを確認する。
AA
7.3.2.3 一貫したナビゲーションに関する達成基準 繰り返されるコンポーネントが表示されるたびに、それを相対的に同じ順序で提示する ウェブページの集合(例えばウェブサイト)にて繰り返し利用されるコンポーネント(例えば、ロゴ、タイトル、検索フォーム、ナビゲーションバー、ナビゲーションメニュー等)が、相対的に同じ順序で表示されていることを以下の方法などを用いて確認する。

  • CMS等により、繰り返し利用されるコンポーネントが相対的に同じ順序で提示されるように管理されている
  • 各ページを作成する際にテンプレートを利用したり、Webページ製作・編集ツールの機能を用いることなどにより、繰り返し利用されるコンポーネントが相対的に同じ順序で提示されるように管理されている
  • CMS、テンプレート等で管理されていない場合は、試験実施ガイドライン2.3節のb)c)に示された選択方法などを用いて試験対象ページを選択し、該当ページ間で繰り返し利用されているコンポーネントが相対的に同じ順序で表示されている
AA

コーディング、特に各ページの制作時に気をつける項目

番号 達成基準 状況 項目の内容 説明 追記 等級
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
img要素にalt属性がある imgタグに alt属性をいれましょう。

alt属性が不要な場合は alt=”” と属性値なしで書きます。
A
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
隣り合う画像とテキストのリンクが同一のhref属性値を持つ場合、画像とテキストを1つのa要素でマークアップする 例えば、キャプチャ画像と説明テキストが同じリンクで隣あっているような時は、1つの同じ a要素にいれましょう A
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
a要素のリンクの目的を説明するリンクテキストを提供する 音声読み上げされる a要素に含むテキストの意味に気をつけましょう。 A
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
画像のグループにある一つの画像に代替テキストを提供して、そのグループのすべての画像を説明する 画像が連続していて連続で alt属性読み上げが無駄そうな時はむしろいれない方がいい。例えば「★☆☆」というような画像など A
7.1.1.1 非テキストコンテンツに関する達成基準 状況B:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できない場合(例:チャート又はダイアグラム):
以下のいずれかの方法を用いて長い説明を提供する

  • 短い説明の中で長い説明の場所を示す
  • 非テキストコンテンツのすぐ隣に長い説明へのリンクを提供する
  • object 要素のボディに代替テキストを記述する
A
7.1.1.1 非テキストコンテンツに関する達成基準 状況F:

非テキストコンテンツを支援技術が無視するようにしなければならない場合:
支援技術が無視すべき画像の img 要素は、alt属性値を空にして、title 属性を付与しない 音声読み上げで伝える意味のあるテキストであり、不要な場合は alt=”” と属性値なしで書きましょう。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
セマンティックなマークアップを用いて、強調したテキスト又は特別なテキストを示す 太字で強調するテキストには、 em か strong を使いましょう。など。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
引用箇所がある場合、blockquote要素でセマンティックにマークアップする A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
引用箇所に参照情報がある場合、参照先を cite 要素でセマンティックにマークアップする A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
下付き文字、上付き文字がある場合、それらを sub、sup要素でセマンティックにマークアップする A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
色の手がかりを用いる場合には、セマンティックにマークアップする

色で情報を伝えている場合、セマンティックなマークアップ(例えば、em、strongなど)を用いていることを確認する。
A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
table 要素の summary 属性を用いて、データテーブルの概要を提供する html5 では summary を書いてしまうと、valid ではなくなってしまいますので、html5 でマークアップしている際はつける必要はないと思われます。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
見出し構造が複雑で、scope属性だけでは見出しセルが指定できないデータテーブルでは、id 属性及び headers 属性を用いて、データテーブルのデータセルを見出しセルと関連付ける A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
リストに、ol 要素、ul 要素、dl 要素を用いる

リストのマークアップを用いて、リストの情報を提示する
7.1.3.2 意味のある順序に関する達成基準 単語の文字間にスペースやタグを用いない A
7.2.4.2 ページタイトルに関する達成基準 title要素を用いて、コンテンツの内容が分かるページタイトルを提供する A
7.2.4.4 文脈におけるリンクの目的に関する達成基準 以下のいずれかを用いて、リンクの目的を特定する

  • 1) a) b)を用いてリンクの目的を説明したリンクのラベルを提供する
    • a 要素のリンクの目的を説明するテキストリンクを提供する
    • b) イメージマップの area 要素に代替テキストを提供する
  • 2) リンクのラベルとそれが含まれている文章中のテキストとを組み合わせる
  • 3) リンクのラベルとそれが含まれているリスト項目とを組み合わせる
  • 4) リンクのラベルとそれが含まれている段落とを組み合わせる
  • 5) リンクのラベルとそれが含まれているデータセル及び関連づけられた見出しセルとを組み合わせる
  • 6) リンクのラベルとその直前にある見出し要素とを組み合わせる
  • 7) 入れ子になったリスト項目にあるリンクのラベルとその親のリスト項目とを組み合わせる
  • 8) CSSを用いて、リンクの目的の説明を補足したリンクテキストの一部を非表示にする
A
7.4.1.1 構文解析に関する達成基準 ページをバリデートし、問題がないことを確認する。

ページがバリッドでない場合、少なくとも下記のいずれかを満たすこと

  1. 開始タグ及び終了タグが仕様に準じており、属性値のクオーテーションが正しく組になっていること
  2. ページがwell-formedであること
A

ウェブアクセシビリティのJIS規格対応

システム部の渡辺です。
ユーザビリティという言葉はよくききますが、
アクセシビリティについて説明するのはなかなか難しいのではないでしょうか。

アクセシビリティといえば高齢者・障がい者の方々を考慮したWEBコンテンツ、
病院サイト、介護老人施設サイトなどを多く扱う弊社では特に気を使う点です。

一般的に制作時に気にする点といえば、

「視力が悪い人が困らないように大きくてわかりやすい色の文字を使う」
「画像の alt 属性を記入する」

このぐらいかと思いますが、
日本で定められているアクセシビリティ規格を正しく守るには、

「音声読み上げを考慮したコーディング」
「キーボードだけで全ての操作を可能にする」
「CSS、Javascript をオフにした状態の対応」

など、普段あまり触れることのない対応も必要になってきます。

公的機関の公式ホームページのウェブアクセシビリティ

厳密にどのように対応すべきか、というところですが、
日本国内では JIS(日本工業規格)の中で規格が定められてます。

名称 JIS X 8341-3
正式名称 高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス-第3部:ウェブコンテンツ
URL http://waic.jp/docs/jis2016/understanding/201604/

公的機関ではアクセシビリティ対応を試験されています。
「公的機関におけるウェブアクセシビリティ方針策定と試験結果表示の実態調査(2014年11月)」
例えば、東京都では、「東京都公式ホームページ作成に関する統一基準」というものが決まっています。

東京都立○○の公式ホームページなどを制作する場合、上記に注意する必要があります。

JIS X 8341-3対応

JIS X 8341-3対応のサイト制作をする場合は、
サイトを作る前から充分に気をつけたいところです。
正直、JIS X 8341-3対応するつもりでつくっていなかったサイトを、
JIS X 8341-3対応するのは、かなり骨の折れる作業です。

  • デザイン時に気をつける項目
  • コーディング、特にベース部分制作時に気をつける項目
  • コーディング、各ページ固有の制作時に気をつける項目

の3つに分けて、注意したい対応項目をまとめたいと思いますが、
長くなったので次回に!

【Mac】 Dash で開発の作業効率アップ!

作業効率をあげたい!

開発作業のスピードアップは常に課題の1つですよね。

当然、サイトは一つ一つ違うニーズがあり、違う問題を解決していく作業ですが、

やはり違うサイトといえど同じような記述を書く必要がある場面はあるもので、

書きたいと思ったものを瞬時に呼び出すことができるスニペットアプリは多いに役に立ちます。

Dash


Dashのロゴ

Dash


スニペットアプリは複数利用していますが、開発でオススメなのは「Dash」!

「登録した文字列を素早く呼び出すスニペット機能」

「言語の関数を素早く検索して調べる」

の2つを兼ね備えたソフトウェア Dash はかなり便利なのでご紹介です。


Dash は App Store からダウンロードできます。

基本機能は無料のままで利用可


https://itunes.apple.com/jp/app/dash-3-api-docs-snippets./id449589707?mt=12

すべてのアプリケーションを対象にできる

Dash を使うメリットは

  1. いつどんな場面でもショートカット1つですぐに呼び出せる
  2. どんなソフトウェアに対してもテキストの貼り付けしてくれる

です。

なので、テキストエディターが何であろうと同じように機能してくれます。

私の場合は、プログラミングに限らず個人的によくタイプすることの多いもの、

例えばメールのテンプレ文章やら、

自社の住所や、電話番号、メールアドレスなども登録しています。

具体的に私の登録しているスニペットでの操作例を書きますと、

「address # medical」と入力すると、その文字が瞬時に

「東京都港区赤坂二丁目23-1 アークヒルズフロントタワーRoP 902号」と弊社メディカルデザインの住所に変換されるようにしています。

この便利なところは、
わざわざ Dash を呼び出して操作を行うわけではなく、

Dash が起動していれば、「address # medical」とタイプするだけ、
というところです。

また、その登録しているスニペットを「タグ付け」しておけるので、

Dash の画面から「php」やら「css」「javascript」など、言語ごとに整理できるのもとても便利です。

多言語のドキュメントを検索

Dash は スニペット機能だけでなく、複数言語ドキュメントの検索を一括でおこなえる機能も兼ね備えています。

自分が使う言語のドキュメントをローカルにダウンロードでき、

それらを対象に、ドキュメント内を文字列検索してくれるので、

うろ覚えの関数のドキュメントを高速に参照することができるのがありがたいです。

私は、テキストエディターは SublimeText がメインですが、


「文字を選択してショートカット一発で、その選択文字の Dash 検索結果を一発で呼び出す」プラグインが、とんでもなく便利なのです。

うろ覚えのあの関数の、ああ、こいつの引数はどういう順番だったけ、など、

それらをいかに早く呼び出して正確に書けるか、

作業中何度もやる短いアクションをいかに素早くできるかはけっこう大きいと思います。

Dash をご存じなかった Mac ユーザーのかたはぜひお試しを!

Smartyを導入するメリット

システム部の松田です。

サイトのお問い合わせや応募の入力フォームの実装・テストを担当することが多いのですが、その際によく利用するPHPのテンプレートエンジン「Smarty」について、まだまだ断片的な知識の整理を兼ねて、今回紹介したいと思います。

投稿は、前後編と2度に分ける予定で、

  • 前篇:PHP実装の問題点、それを補うSmartyのメリットなど概要
  • 後編:Smartyの使い方、ハマりやすいポイントなどの具体的な内容

のような構成でお伝えしたいと思います。

Continue reading

【HTML】見る側のブラウザのキャッシュのCSSや画像を更新する方法

更新したはずなのに!

HTMLの更新完了! お客様、ご確認ください、というシーンで

お客様「変わってないようだけど?」

ブラウザに残ったキャッシュの可能性がありますのでキャッシュの削除を・・
削除方法は・・ブラウザは何をお使いでしょう?というようなやりとりがまれにあるかと思います

原因は?

見る側のパソコンのブラウザに残っていた古いデータ(キャッシュ)が
更新後の初回アクセス時に使われてしまい、
ページが予期せぬ表示になってしまうあの現象です。

どうしたらいいの?

つまり見る側のパソコンのブラウザに
「このCSS、今回は新しく読み込んでくださいね」と、どう教えるかですが、
てっとりばやく簡単な方法として

例えば、今までこう書いて読み込んでいたCSSだとしたら、

<link rel=”stylesheet” href=”/css/default.css” />

キャッシュ更新したい時はこう変えます

<link rel=”stylesheet” href=”/css/default.css?20150802″ />

その読み込むCSSのパスの最後に「?」をつけまして、
でたらめな文字をクエリとして渡すと、

ブラウザ「このCSSは、今までと違うこの値によって、違うデータに変化するかもしれない」

と認識して新しく読み込んでくれます。

上記の例の「default.css?20150802」は年月日ですが、
「?」の後は、URLとして意味を持たない文字列なら何でもいいです。

レイアウトを大きく変えるときなどちょっと加えておくと、
大きなタイムロスと信頼感へのダメージを未然に防げますので、
おまじないのように入れておくといいと思います!

【制作事例】HTML5によるアニメーションとゲーム

昨年11月にJAセレサ川崎様のHPリニューアルの制作をさせていただきました。
PC/スマートフォンに対応しています。

セレサアニメ

http://www.jaceresa.or.jp/
PC版のトップページのメインビジュアルは
川崎の臨海部〜都市〜里山を気球でめぐる楽しいアニメーションになっています。
ポイントは多重スクロールによる奥行き感と、それがきちんとループでつながっている点です。
気球も動かせます!

 

また、せっかくリニューアルするなら、利用者が楽しめるようなコンテンツを作りたい、というご要望があったので
同じイラストを利用して、オリジナルゲームの制作をご提案しました。

game02_ol
「旬の野菜をキャッチ!GO!GO!CERESA!」
http://www.jaceresa.or.jp/game/

飛んでくる野菜を時間内にできるだけ多くキャッチする!という単純なゲームですが、
季節によって高得点のアイテムが変わったり、ハイスコアランキングがあったりします。
スマホ版もあるので遊んでみてください。

 

何年か前だと、Flashで制作するところですが、
HTML/CANVAS/Javascriptでの制作となるとちょっと手間がかかります。
最近は逆に、ホームページ内でこういったコンテンツを見かける機会が減ったかもしれないですね。

続・アイコンフォント

すっかり梅雨入りしましたね。
昼休みにグァバジュースを買って、トロピカル気分で働いております、國宗です。

さて、以前岩井さんがアイコンフォントについて記事を書いていましたが、 今回はわかりやすく、もう少し深く掘り下げたアイコンフォントのお話をしたいと思います。

そもそもアイコンフォントって何なの?

アイコンフォントを分かりやすく説明しますと、 「機能のいっぱいある、アイコン集のフォントをブラウザ上で動かす」という事です。 これだけだと、まだ分かりにくいので、 まずはOpentypeというフォントの形式を説明します。

Opentypeとは……

Opentypeには、リガチャー(合字)、スウォッシュ(単語の頭や末にアクセントをつける)、分数など様々な機能があり、 これを使うと、ただキーボードで入力した文字がプロフェッショナルの組版に変わるのです。 リガチャーを例に上げますと、
例えば「Office」という文字を入力します。(illustrator CC、Adobe Garamond Premium proを使用)
欧文合字機能をONにすると……

Officeの「ffi」の部分が、1文字になりました。 これは、フォントの作り手側が意図的に「f」と「f」と「i」が入力された場合に1文字の「ffi」に変換しているのです。 fiやflの黒く中途半端な部分をなくし、本文を読みやすくさせるためです。

さて、これからアイコンフォントの話に移ります。今までの「ffi」を応用したのがアイコンフォントです。僕のよく使っている「Symbolset」のサイトです。

アニメーションの文字の部分をクリックするとテキスト入力に切り替わります。 この状態で「love」とキーボードで入力して下さい。

すると、「l」、「o」、「v」とここまでは、普通のテキストなのですが、
最後の「e」を入力すると「♥」になりました。

https://symbolset.com

これがアイコンフォントの使い方です。

まとめ

【メリット】

  • 画像の代わりにテキストを入力しているので、SEO的に良い。
  • ビットマップの画像データではないので、拡大縮小しても汚くならない。Retinaもバッチリ。
  • CSSでの色の変更や装飾も自由自在。

【デメリット】

  • IEでもWebフォントを読み込めますが、クロスブラウザでつかうには、
    様々な種類のアイコンフォント形式を読み込まないといけない。

また、僕は正しい使い方ではないのですが、アイコンフォントを通常のフォントとしてインストールし、 カンプデザインにも使ったりしています。
こうする事で、いちいちアイコン集を探す手間が省けるので、 重宝しています。 ただし、この場合は画像ファイルになってしまうので注意が必要ですね。

機会があれば是非お試しください。

【無料!】ファイル圧縮オンラインサービスのまとめ

こんにちは。デザインおよびコーディング担当の黒木です。

弊社では様々なウェブサイトの運営管理を行っており、「このファイルをホームページにアップしてください」と、お客様から日々、様々なファイルをお送り頂いております。

jpgファイルであったり、Wordファイルであったり、PDFファイルであったり形式は様々ですが、中にはファイルサイズが数十メガバイトにも達するものもあります(PDFファイルの場合がほとんどですが)。

そんな時、如何にファイルサイズを縮小・圧縮などの軽量化を図って、サイトにアップロードするかが、大変悩ましいところです。

今は、スマホなどのモバイルデバイスでサイトを閲覧する方も多いので、やはり重いファイルはサイズを削った上でアップロードし、ウェブサイト全体をできるだけ軽量化したいものですね。

そこで今回は、ファイルサイズを軽量化してくれる便利なオンラインサービスを、ファイルの形式ごとにご紹介したいと思います。

jpgファイルを軽量化!

JPEGmini - Your photos on a diet!

インターフェイスのわかりやすさもさることながら、トップページのデモンストレーションも非常にわかりやすく、面白い仕掛けが施されています。

JPEG Optimizer - Compress and Resize Your Digital Photos

こちらは、どのくらい画質を落とすか、どのくらいリサイズするかを入力する事ができます。

pngファイルを軽量化!!

TinyPNG – Compress PNG images while preserving transparency

ややリアルなパンダのキャラがユニーク。軽量化が完了すると…?

Compress PNG Images Online

こちらも画質の圧縮度合を選択する事ができます。画像に含まれる色数の増減も選択できるのが特徴。使い方がややわかりづらいかもしれません(画像をドラッグ&ドロップしたら、「UPLOAD QUEUE」をクリック→アップした画像のサムネイルをクリック!)。

PDFファイルを軽量化!!!

Compress PDF – Reduce your PDF Online for Free

デザインや軽量化する際のアニメーションが素敵です。使い方もシンプル。

Compress PDF Files Online!

非常に細かく設定を変更できる点がポイント。しかし5MBまでしかアップロードできないようです。

どれも無料かつ簡単に使用できるサービスですので、試してみてはいかがでしょうか。