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色になりました。

結局のところ対処法は…

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

クリッカブルマップがrwdImageMapsで消える|動かなくなる場合がある件

こんにちは、システムの渋谷です。
画像の一部分の領域からリンクを張る、クリッカブルマップという便利な機能があるのですが、レスポンシブで画像のサイズが変わってもリンクの領域は自動的に変わらないため、ブラウザのサイズ変更に応じてリンクの領域をjavascriptで変えてあげる必要があります。

その作業を簡単に行ってくれるResponsive Image Maps jQuery Pluginという著名なjQuery Pluginがあるので、通常これを使ってクリッカブルマップのレスポンシブ対応を実現しています。

使い方も簡単で、「jquery.rwdImageMaps.min.js」を読み込んで

$(‘img[usemap]’).rwdImageMaps();

とするだけでOK!
まったく簡単だ!

と思ってたら、なぜかクリッカブルマップが正常に動いていない案件が……

やせいの バグが とびだしてきた!

症状としては、

  • タブを使って複数のクリッカブルマップを切り替える仕様
  • クリッカブルマップを切り替えるとリンク領域が消えている
  • ブラウザサイズを変更するとなぜか復活する

いろいろ適当にいじってみても正常に動作しないので、泣きながら(というほどでもないですが)ソースを読んでみました。

画像ロード時にimg要素の大きさを取得して、それをもとにレスポンシブで変更された画像の大きさでのリンク領域の計算を行っているようです。

つまり…タブで切り替える仕様などで、rwdImageMaps()実行時にクリッカブルマップが非表示の状態になっていると画像の幅と高さが「0」とされてしまうので、リンク領域も出なくなってしまう、と。

それで解決方法は?

これを解決するには、画像を表示するタイミングでサイズを取得してあげるようにすればいいのですが、プラグインの中身に手を入れると管理が面倒になるので今回は「ブラウザサイズを変更するとなぜか復活する」点に注目して、タブの切り替え時にresizeイベントを発火させることで解決することができました。

コードとしては、タブ切り替え時のslideDown等の関数のコールバックに

function(){$(window).resize();}

を指定してあげればいいだけです。

rwdImageMaps自体が結構長い間メンテナンスされておらず、最新のjQueryで廃止された関数を使っていたりするのでいろいろ書き換えたいところがあるんですけどね。

ウェブアクセシビリティの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

[WordPress]公開済みの古い記事上に注意文を表示する。

ブログなんかで、「この記事は古いですよ」的なアナウンスをしている記事、ありますよね。

七夕ですね!システム部のヒライでございます。

デザインツールの使い方や技術系の解説、ブログ等を読んでいると、「この記事の内容は最新でない可能性があります」的な注意書きが目につきますよね。
書いた当時は最新の情報ですが、日がたつにつれその内容が正しくなくなる可能性もあるわけでして、
記事を読みに来られたユーザーさんへのとても良い配慮になると思います。

この様な注意書きですが、WordPressでは一瞬で出来ちゃいます。

投稿日が1年以上前の記事に注意書きを表示する。

サンプルとして、まずは適当に投稿日を古くした記事を作ってみます。

1

お使いのテーマ内にあるsingle.phpを開き、注意書きを表示されたい場所に以下を差し込みます。

<br />
&lt;?php<br />
// 投稿日が1年以上前であれば表示する<br />
if( date(&#8216;U&#8217;) &#8211; get_the_time(&#8216;U&#8217;) &gt; 60*60*24*365 ) {<br />
?&gt;<br />
	&lt;!&#8211; ↓ここにhtmlで注意書きを入力 &#8211;&gt;<br />
	&lt;div style=&quot;background: #FFEDED; border: solid 1px #B84749; color: #B84749; padding: 10px; font-weight: bold; margin-bottom: 20px;&quot;&gt;<br />
		&lt;p&gt;本記事は&lt;?php the_time(&#8216;Y年n月j日&#8217;) ?&gt;に投稿されました。&lt;br&gt;現在の状況とは違う可能性があることをご了承下の上、お読み下さい。&lt;/p&gt;<br />
	&lt;/div&gt;<br />
&lt;?php<br />
}<br />
?&gt;<br />

これで、投稿日が1年以上前の記事のみに注意書きが表示されます。
1年では長すぎるので短くしたい、等の場合は2行目の「365」を変更すればOKです。(30にしたら30日以上前となります)

それでは同じ記事を表示してみます。

2

一目で古い記事なんだなとわかるようになりました。
というわけで私もブログを書くようなことがあれば積極的に使おうと思います。

ご存知でしたか?Google Map APIの使用にAPI Keyが必須になりました

システム部の鈴木です。

もはやwebサイト制作だけではなく日々の生活に無くてはならなくなったGoogle Map
世界中の人が無料で使えて、これを活用したサービスだって無料で作れる。
当たり前になりすぎてしまいこの恩恵の価値を忘れてしまうくらいでしたが
ここにきて少し動きがあった事、ご存知でしたか?

Google Map API

これを使うと、自分のサイトの中にこんな感じで、沢山の好きなアイコンを並べたり
様々なカスタマイズを加えた独自のマップを作ることができます。

現在のAPIはVer.3 となり、Ver.2 までは煩わしかったAPI Keyが不要になった、ということで制作者にとっては非常にありがたいアップデートになりました。

2016-07-01_21.47.20

ところが、それは突然の出来事でした・・・

Mapが表示されない!?

いつも通りに作ったはずが全く表示されない?
今まで動いていたサイトのコードを流用しているんだから間違ってるはずもないのに?

そこでChromeのデベロッパーツールでコンソールを開くと見慣れないエラーが。。

Google Maps API warning: NoApiKeys https://developers.google.com/maps/documentation/javascript/error-messages#no-api-keys

NoAPIKeysエラー?

APIKeyはいらないはず、と思いながら調べたところ、Google が2016年6月22日に以下のようなアナウンスを出していた事が分かりました。

http://googlegeodevelopers.blogspot.jp/2016/06/building-for-scale-updates-to-google.html

これによると6/22より、スタンダードプラン(無料のもの)を使って新しく作成するアプリケーションでは
API Keyが必須になったとあります。

Google developers blog でもそんな事書いていなかった気がするんですが。。

API Keyはどうやって取るの?

まずは予めGoogle アカウントにログインをしておいてください

160701

Google Map API のサイトにある「キーを取得」を選択します

 

160701_02

するとこんな感じのモーダルが表示されるので「続ける」を選択

 

160701_03

今度はGoogle API Console に遷移します。
「プロジェクトを作成」を選択したまま「続行」します。

160701_04

するとこのような「認証情報」という画面が表示されます。

ここでAPI Keyを発行するのですが、とりあえず「作成」します。

 

160701_05

なにやらAPIが発行されたようです。

 

160701_06

まだこの段階では発行されたAPIが使われるサイトのドメインが登録されていません。

作成されたAPIキーの名前を選択してドメインを登録しましょう。

 

160701_07

API Key発行の画面が表示されるので、ここで改めてアプリケーションを作成するサイトのドメインを設定します。
テストサイトと本番サイトがサブドメインでわかれている場合は、サブドメインをワイルドカードにすれば環境ごとにキーを設定する必要が無く便利です。

 

これで、API Keyの準備ができました。

あとはアプリケーション側で、APIのロードをこんな感じで変更します。

変更前
変更後
これで今までどおり、Google Map APIが使用出来るはずです。

前に作ったアプリケーションはどうなるの?

6/22以前にすでに稼働しているアプリケーションは、今のところAPI Keyなしでも動きます。
今のところはAPI Keyをいつまでに付けなければいけない、という事も無さそうです。

しかし今後いつ、今回のように突然の変更があるかは分かりません。

今後はAPI Keyを必須にするという方針に沿って、直せるうちになおした方が良いでしょう。

jQuery 3が来ていますが

Photoshopのアップデートが来て、新機能にテンションが青天井なシステムの渋谷です。
先月開催されたAdobeデジタルフォト&デザインセミナーでは、新機能が「コンテンツに応じた切り抜き」しか紹介されていなかったのですが、それ以外にも細かいところが改善されていて、今回のアップデートはかなり好感触です。

jq

アップデートといえば、今月jQueryの「3」がリリースされていました。
動作が速くなったということで早速新規立ち上げサイトで使ってみたかったのですが、システム部で鈴木さんに相談したところ「初期ロットは不具合が出やすい」ということでもうちょっと枯れるまで待つことになりました。

変更点をかいつまんで

3.x系を入れる準備だけはしておこうということで、とりあえず実験的に2.xで使っていたコードをそのまま動かしたら案の定エラーはいて止まってました。
結構たくさん変更点があるようで、やっぱりこういうのはちゃんと読まないとだめです。

じっくり読んだので、多くのサイトで使っていそうな機能の変更点を2点ほどピックアップしました。

display:noneをhtmlに直接style=”~”の形で書くと.show(),.hide(),.toggle()等で意図した動作にならない

今どきのレスポンシブ対応サイトだとstyle=”display:none”を直接書くようなケースはあまり考えられないのですが、これをインラインで書いてしまうと上書きされず、.show()を使っても表示されないようです。

.load(), .unload(), .error()が削除された

非推奨だったものが削除されたようです。ブラウザからそんな関数知らんと怒られます。
.load()の代わりに.on()を使ってくださいとのこと。

$("#hoge").load(fn);
↓
$("#hoge").on("load", fn);

こんなもの使ってないよー、と思っていたのですが、先人が太古の昔に入れたコードに含まれていました。
文字のサイズを変更してクッキーに保存する機能を標準でいれることが多いのですが、ここでunload()を使って怒られていました。

当面はjQuery2を使っていくものの

新規サイト立ち上げの際は、いつjQuery3に移行しても良いように古いコードは使わないよう書き換えていきたいです。

ウェブアクセシビリティの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つに分けて、注意したい対応項目をまとめたいと思いますが、
長くなったので次回に!

【MDの夏採用、始めました】

FB

こんにちは。病院チームのTです。

現在、3月4月のどたばたを乗り越え、1年を通して案件が落ち着く時期を迎えています。

いつもは時間を割けられず後回しになっていたところを改修するいいタイミング、ということで、
今回はリクルートページを大幅にリニューアル致しました。

img01

img02

社内の雰囲気をお伝えできれば、ということで社内の写真を多く起用しています。

また、今回の改修で応募フォームを新たに設置しました。
3ステップで簡単に応募できるようになっています。

現在はディレクター、エンジニア、デザイナーを募集中です。
採用を検討している方はこの機会にぜひ、ご覧になってみて下さい。

http://www.medical-design.co.jp/recruit/

[PHP]タイトルや本文に文字数制限して表示する場合に、出来るだけ終了地点を揃える。

タイトルのセンスがなさすぎて辛い…。

うまく伝える魅力的なタイトルが思い浮かびませんでした、システム部のヒライです。
端的に言いますと、WordPress等の記事一覧ページで、タイトルやら本文を省略して表示する場合に、それぞれの終点を揃えたいということです。

mb_substr()を使う。

文字数制限なんかで探しますとmb_substr()という関数が引っかかります。

75文字で省略し、最後に「…」を付けてみます。

mb_substr

 

・・・美しくない。

 

終わりに表示している「…」の位置がずれていてキレイじゃありません。

そんなときはmb_strimwidth()を使います。

こちらも同じく75文字で省略し、最後に「…」を付けてみます。

mb_strimwidth

 

・・・美しい。

 

終わりの「…」の位置が揃っています。大変キレイです。

mb_substr()とmb_strimwidth()の違い。

mb_substr()は全角文字列と半角文字列を判別せず、1文字としてカウントするのに対し、
mb_strimwidth()は全角なら2文字、半角なら1文字としてカウントしてくれるので、終了地点があまりズレないということですね、とても優秀です。

冒頭の話に戻り、例えばWordPress上でタイトルを省略しつつ、且つ終点を揃える場合。

// 第一引数にタイトル、第二に始点(0文字目から)、第三に終点(100バイト分の文字)、第四に終点に付け加える文字列、第五に文字コード<br />
&lt;?php echo mb_strimwidth($post-&gt;post_title, 0, 100, &quot;…&quot;, &quot;UTF-8&quot;); ?&gt;

※mb_strimwidthについて詳しく知りたい方はこちらをご覧下さい。

一覧画面上に複数出ているタイトルや本文の終わりを揃えたいとお考えの方、ぜひお試し頂ければと思います。

プログラマのためのthree.jsでの絵作り

03

システムの渋谷です。

three.jsでのモデル描画ができないままだと何か負けた気分だったので、モデル描画サンプルを用意しました。
方言に苦しめられるFBXとかではなく、json形式でデータを書き出したので今回は描画の乱れ等は起きずに済みました。

サンプルはこちら

ステレオカメラが標準で実装されていたので、裸眼立体視にしてみましたが、標準だと画角が小さいせいか効果が弱すぎたのでソース弄って効果を10倍にしています。

サンプルを用意する中で、レンダリング画像が簡単にきれいになるいくつかの抑えておきたい項目を紹介しておきたいと思います。

1.  アンチエイリアス設定

var renderer = new THREE.WebGLRenderer({antialias: true});

レンダラーを初期化するときにantialias: trueを指定しておくと汚いジャギーが消えてくれます。
three.jsのソースを見た限り特に処理の内容が書いていなかったのでブラウザに処理が依存していると思われます。
標準のandroidブラウザでは反映されていませんでした。

2. premultiplied gamma

renderer.gammaInput = true;
renderer.gammaOutput = true;

この2つを指定しておくと光が当たってるところの白とびが抑えられたり、暗すぎるところが明るくなります。

a02

3. HemisphereLight(半球ライト)

lighting

表示したいモデルに当てる光について、屋外を考えた場合

  1. 太陽光
  2. 青空からの環境光
  3. 地面にあたった太陽光の反射

がざっくりあるので、これを用意していきます。

 var directionalLight = new THREE.DirectionalLight(0xfff1d7,0.80);
 directionalLight.position.set(-6, 11, 10);

太陽光は通常の平行光源を使っています。
青空からの青い光と合わせて白になるように若干黄色がかった白を指定しておくといい感じになります。

環境光と地面からの反射は通常はアンビエントライトで我慢するのですが、three.jsではHemisphereLightが用意されているのでこれを使います。

 var hemisphereLight = new THREE.HemisphereLight( 0xd7fbff, 0x7e94a8, 0.7 );
 scene.add( hemisphereLight );

HemisphereLightの第1引数が空の色で、第2引数が地面からの反射の色になります。

反射の色は空の色に合わせたものか、明度を抑えておくと自然な感じに落ち着きます。

a03

というわけである程度見られるレベルにはなったと思うのですが、いかがでしょうか…?

3Dで見せたい商品がある等の場合、写真から3Dモデルが作れる123D Catchmementoなどを組み合わせれば、そう難しくなく実現できそうですよね。