2015年の記事（26件）

2014年10月28日に HTML5 が正式に勧告となりましたが、それ以前より多くのWebサイトが HTML5 や CSS3 を採用しています。弊社でも2012年辺りから HTML5 を採用し、丸角やシャドウ、グラデーションなどの CSS3 の一部のプロパティやセレクタを取り入れてきました。

特に、近年はレズポンシブWebデザインによるスマートフォンやタブレット対応も施していますので、CSS3 を使うことによって画像を少なくできることは、マークアップ作業やメンテナンスを楽にするだけでなく、通信速度やデータ量の面でも有効です。

ただ、そこで問題となるのが主に Internet Explorer 9 以前の古いブラウザへの対応です。HTML5 については IE8 以前が対応していませんし、CSS3 については IE8 以前のみならず、IE9 でも背景のグラデーションなどに対応していなかったり、IE10 でも対応していないプロパティがあります。

そのような古いブラウザ（というか、IE ）に対して、HTML5 と CSS3 を適用させる方法として、以下の JavaScript ライブラリが有名です。

“HTML5、CSS3 の古いブラウザへの対応について” の続きを読む »

昨日導入した、jquery.neosmart.fb.wall ですが、2点ほど問題がありました。その1つはセキュリティ上の問題でもあります。

1つ目は、25人を超える「いいね！」がある投稿に対して、「いいね！」数が25までしか表示されないことです。これは、Graph API がデフォルトで25しか「いいね！」した人を表示しないのが原因とのことで、jquery.neosmart.fb.wall.js の61行目を、

url: graphURL+o.id+'/'+type+'?limit='+o.max+'&likes.limit=200&access_token='+o.accessToken',

のように、likes.limit=いいね！の上限数 というパラメータを追加することで解決しました。（参考：永遠少年症候群 | fb.wallメモ最終版）

2つ目は、Facebook のアクセストークンを取得してこのスクリプトに設定するのですが、このアクセストークンを HTML か JavaScript に記述するため、誰にでもアクセストークンが見えてしまうこと。アクセストークンがあれば Facebook ページの非公開にしている情報までもが取得できてしまいます。

開発を終了した fb.wall のサイトにも「安全な方法でアクセストークンを提供することができなかった」といった内容の記述があります。これが開発終了の理由なんですね。

Since 2010 Facebook changed their Graph API a lot of times, they added server request limits and the need of access tokens. With a pure JavaScript solution it was not possible to provide access tokens in a safe way. Therefore we developed neosmart STREAM.

“続・jquery.neosmart.fb.wall を導入しました” の続きを読む »

このサイトのトップページに、Willさんいんの Facebook ページの投稿を表示するため、公式プラグインの Like Box を使用していました。

ところがこの Like Box、6月23日に廃止となり使えなくなるとのことで、新しい Page Plugin に移行するよう勧められています。

With the release of Graph API v2.3, the Like Box plugin is deprecated and will stop working on June 23rd 2015. Use the new Page Plugin instead. The Page Plugin allows you to embed a simple feed of content from a Page into your websites.

しかし、この新しい Page Plugin は、表示幅が 280px から 500px の間に制限されています。このサイトのトップページのレイアウトは、Facebook 表示領域を PC 画面で624px に設定しているため、124px もの余白ができてしまいます。

また、Like Box にしろ、Page Plugin にしろ、JavaScript で読み込んで表示しますが、実質はインラインフレームの中で facebook.com のページを表示していますので、フォントサイズや色などを CSS でコントロールすることが出来ません。その上、フォントサイズが 13px などに固定されているため、Internet Explorer では文字のサイズを変更できないことも気になっていました。

“jquery.neosmart.fb.wall を導入しました” の続きを読む »

CMS で作成されたサイトで、下層ページの一覧などにページのタイトルとサムネイル画像、ページの概要があり、そのタイトルとサムネイル画像それぞれに、リンク先となる同じページへのリンクが貼ってあるパターンをよく見かけます。例えば、次のような HTML です。

<h2><a href="hogehoge.html">ページタイトル</a></h2>
<div class="thumbnail"><a href="hogehoge.html"><img src="thmbnail.jpg" alt="" /></a></div>
<p>概要テキスト概要テキスト概要テキスト概要テキスト概要テキスト</p>

サムネイル画像が左に、ページタイトルと概要がその右にあるようなデザインでは、1行目と2行目が逆の場合もありますし、サムネイル画像の代替テキストにページタイトルが付けられている場合もあります。

しかし、このような HTML は、スクリーンリーダーなどでは［Tab］キーで同じリンクを続けて2回辿ることになりますし、サムネイル画像の代替テキストが空だったりすると、そのリンク先を理解することが難しくなります。

これではアクセシビリティ的に問題がありますので、これを解消する3つの方法を考えてみます。

“タイトルとサムネイル画像の重複リンク” の続きを読む »

Willさんいんでは、モリサワのすべてのフォントが使用できる MORISAWA PASSPORT を契約していますが、すべての MORISAWA PASSPORT 製品契約者は、追加料金なくモリサワの Web フォント（モリサワでは“クラウドフォント”と称しています）TypeSquare を利用できるということで、Willさんいんのサイトに導入してみました。この MORISAWA PASSPORT プランは、利用可能書体数、利用可能ドメイン数に制限がなく、1,000万PV／年まで無料で利用できます。

今回、視認性が高く、読みやすいというユニバーサルデザインフォントを採用し、本文を含むすべてに “UD新ゴ” をベースフォントとして使い、見出しには “UD新丸ゴ” を使ってみました。

“くもやじ” とか “プリティー桃” とか “はるひ学園” とか “すずむし” といったデザインフォントも使えます。

“Web フォントを使ってみました” の続きを読む »

CSS によるレイアウトが当たり前となり、十数年前のようなバリバリのテーブルレイアウトというのはほとんど見られなくなりました。一方で、CMS の普及により、WYSIWYG エディタ上の編集エリア内で、複雑なレイアウトを実現するためにテーブルを使うという場合があると思います。

当然、編集エリアにデータテーブルを置く場合もありますので、枠線の有無やセル内余白など、レイアウトテーブルとデザインを区別する必要があります。

WYSIWYG エディタのスタイルボタンなどに予めレイアウトテーブル用の class を登録しておくという方法も考えられますが、最も単純で明快なのは、テーブルの枠線を付けるか付けないかという区別です。

HTML5 では、table 要素の border 属性の値には、1 または空文字列（border=""）のみを指定することができ、これ以外の値を指定することはできません。（ WYSIWYG エディタによっては、テーブルを挿入する際の枠線の初期値が 0 になっているものが多く、これは HTML5 では使えないので、設定ファイルで初期値を 1 か空に修正しておく必要があります。）

以前、テーブルの枠線は CSS で付けるべきで、border 属性は使うべきでないという考え方もありましたが、HTML5 では、table 要素に border="1" を追加することで、その表がレイアウト目的ではないということを示すことができます。

“データテーブルとレイアウトテーブルを区別する” の続きを読む »

弱視の方がパソコンを利用される際に通常の配色では眩しい場合など、画面の配色をハイコントラスト（白黒反転）に設定して利用されることが多いのですが、Windows でハイコントラストに設定すると、背景色や背景画像は表示されなくなります。そのため、通常の配色では見えない配慮が必要になる場合があります。（ちなみに Mac の機能にあるカラー反転は、背景を含めてすべての色が反対色になります。）

まず、配慮以前の問題なのですが、“オフレフト” や “画像置換” などと呼ばれるコーディング手法は致命的な問題が発生します。これは、HTML 上のテキストを text-indent: -9999px などとして画面の外に飛ばし、代わりに画像テキストを背景として配置するというもので、ナビゲーションやタイトル部分など、今でも多くの Web サイトで取り入れられています。

しかし、これをハイコントラスト設定で見ると、当然背景として配置した画像は表示されませんので、その部分は何も見えない真っ黒な空間になってしまいます。

テキスト情報なので SEO にも有利で、スクリーンリーダーでも読み上げられるからアクセシビリティも向上するなどという誤った考え方が広まったこともありますが、これは全くの論外で、装飾目的でない意味のある画像はきちんと代替テキストを伴った img 要素を使って HTML に記述すべきです。

“ハイコントラスト環境への配慮” の続きを読む »

Movable Type で画像やファイルをアップロードする際の、デフォルトのアップロード先を任意のディレクトリに設定するカスタマイズについては、様々なブログ等で紹介されています。”MTディレクトリ/tmpl/cms/include/asset_upload.tmpl” を “MTディレクトリ/alt-tmpl/” 以下にコピーして、先頭に以下のように追記するというものです。

“uploads” というディレクトリに設定する場合は

<mt:setvar name="extra_path" value="uploads">

“uploads/年/月/日” というディレクトリとする場合は

<mt:setvarblock name="extra_path">uploads/<$mt:date format="%Y/%m/%d"$></mt:setvarblock>

ブログ毎に設定を変える場合は

<mt:If tag="BlogID" eq="2">
<mt:setvarblock name="extra_path">uploads/<$mt:date format="%Y/%m/%d"$></mt:setvarblock>
<mt:Else>
<mt:setvar name="extra_path" value="uploads">
</mt:If>

という感じです。これでデフォルトのアップロード先が設定されます。

しかし、アップロードの際にフォルダ（ウェブページで設定したフォルダ）を選択すると、せっかく設定したアップロード先が消えてしまい、フォルダ名のみとなってしまいます。これではそのフォルダに属すウェブページの html ファイルと同じディレクトリに画像がアップロードされてしまい、予めアップロード先を設定した意味がありません。

“アイテムのアップロード先フォルダ選択時のディレクトリ設定” の続きを読む »

画像の代替テキスト（alt 属性）は、Web アクセシビリティの基本中の基本とよく言われますが、適切な代替テキストを付けるということに関しては十分に考慮しなければなりません。

参考：HTML5: 有用な代替テキストを提供するためのテクニック

また、画像がリンクとなっている場合、その代替テキストは単に画像の代わりではなく、同時にリンクの目的を示すものである必要があります。例えば、その Web サイトのホームへのリンクとなっているロゴ画像の場合、その代替テキストは “有限会社Willさんいん” ではなく “有限会社Willさんいん ホーム” などとすべきです。

画像がリンクとなっているパターンの一つとして、近年よく使われている Lightbox 系のスクリプトがあります。サムネイル画像をクリックすると、拡大画像がオーバーレイで表示されるというものですが、当然この場合もサムネイル画像の代替テキストはリンクの目的を示さなければなりません。例えば、”○○の拡大画像” といった具合です。

でも、CMS などの WYSIWYG エディタの中で更新担当者が自由に挿入する画像の場合、画像の代替テキストはアップロードする際に付ける場合が多く、その画像をリンクとして挿入するかどうかは後で決めることが多々あると思います。そもそも、拡大画像へのリンクは代替テキストを変更するという運用の徹底は難しいでしょう。

そこで、jQuery を使って拡大画像にリンクする場合の代替テキストを書き換えてみます。

“拡大画像にリンクするサムネイル画像の代替テキスト” の続きを読む »

WordPress に様々な投稿タイプを追加することができるカスタム投稿タイプや、カテゴリやタグのような分類を追加することができるカスタム分類。これを管理画面から設定できるプラグインとして、有名なもので Custom Post Type UI や Custom Post Type Generator などがあります。

これまで、Custom Post Type Generator を使っていましたが、先日バージョン 2.3.0 が公開され、これに更新したらカスタム投稿タイプやカスタム分類のラベルが消えて名前（スラッグ）と同じになり、管理画面のメニューからも消え、カスタム分類アーカイブのパーマリンクも変わってしまいました。こういうことがあるから、出来るだけプラグインを使わない方がいいんですね。

これを機に、これまで構築したサイトも含め、カスタム投稿タイプとカスタム分類についてプラグインの使用をやめ、function.php で定義する方法に変更しました。

既に function.php には様々な記述をしているため、管理しやすいように custom-post-type.php というファイルを作ってこれに記述し、function.php に読み込むようにしています。（custom-post-type.php の記述はこの記事の最後に記載）

いくつかのサイトを同じようにしてプラグインから function.php による定義に変更していきましたが、一つだけマルチサイト機能を使って複数のサイトを作り、それぞれに異なるカスタム投稿タイプを設定しているサイトがありました。

“マルチサイトでサイト毎にカスタム投稿タイプを使う” の続きを読む »