web制作

AdobefontsのwebフォントがIE11表示されない！それでもIE11で表示させたい人へ

Posted on by admin

いままで問題なく表示されていたものが急にうまくいかなくなることはよくあることです。
Adobeが提供しているフォントサービス「Adobefonts」を利用して表示させていたwebフォントがIE11で表示されなくなり困りました。
IE11のコンソール画面を見てみるとjavascriptでエラーが発生しているようです。

Promiseが定義されていません

このようなメッセージが出ていました。
フォントを読み込むためにadobeから提供されている埋め込み用コードが変更され「Promise」を使用するコードになったためPromiseに対応していないIE11では読み込むことができなくなってしまったようです。

Promiseとは？

javascriptのオブジェクトです。これを使うことによって非同期処理の順序を思いどおりに組みやすくなります。
ES2015（ES6）バージョン以降のjavascriptから導入されています。
IE11はES6は未対応なのでPromiseは使用できないのです。

ではIE11では完全に使用できないのか？

世の中には親切な人達がいて最近の機能を使用できない古いブラウザで新しい機能を使用可能にするためのコードを提供してくれていたりします。そのコードをPolyfill（ポリフィル）といいます。
PromiseにもそのPolyfillが存在します。

▼ここにPromiseのPolyfillのURLが書いてあります。
https://www.promisejs.org/

※注意点

  • Browserという見出しのscriptタグを使用しなければいけません。

※2021年11月26日現在のscriptタグ

<script src="https://www.promisejs.org/polyfills/promise-7.0.4.min.js"></script>

↑これをheadタグ内に記入しておけばPromiseが作動し、IE11でもAdobefontのwebフォントの読込が開始されます。

最後に

webフォントは制作時点ではとても便利です。
が、運用・保守に入ったときに問題がでてくることがあるので定期チェックは必要だと改めて思いました。
また、Adobeサービスは丁寧にコード変更のお知らせがあるわけではないという事も頭に入れておこうと思います。

web制作

WordファイルがPHPで認識されない!？それGoogleと関係あるかもしれません

Posted on by admin

Webサイトなどでユーザーにファイルをアップロードさせファイル形式を判定して処理を行う場面があります。
画像ファイル、PDFファイル、Wordファイルなどがよくあるパターンですがプログラムの中ではファイルの種類を表す情報「mimetype」をもとに判定すると思います。
その際、Wordファイルの判定がうまく行かないファイルが存在することを知りました。

今までのwordファイルのmimetype判定に使用していた文字列

application/vnd.openxmlformats-officedocument.wordprocessingml.document

ファイルタイプは以下のコードで調べることができます。

$file_name = __DIR__ . 'target.docx';
$file_info = finfo_open(FILETYPE_MIME_TYPE);
var_dump(finfo_file($file_info, $file_name));
finfo_close($file_info);

うまく判定できなかった原因

googleドライブで作成したdocumentファイル（Wordに似たアプリケーション）からWord形式に変換したファイルの判定がPHPでうまくできていないからのようです。
このファイルのmimetypeをPHPのプログラムで判定すると

application/vnd.openxmlformats-officedocument.wordprocessingml.documentapplication/vnd.openxmlformats-officedocument.wordprocessingml.document

という文字列がかえってきます。
なぜか複数の情報が連結されてしまっていました。

PHPのバグとして情報もあるようです。
▼Bug #78028 finfo_file reports duplicate mime type for some docx files
https://bugs.php.net/bug.php?id=78028

このレポートを見るとPHPのバージョン7.2まではこの問題は発生せず7.3以降のバージョンで発生するようです。

Googleからの変換されたdocxファイルを判定するためには

使用可能なmimetype判定リストに

application/vnd.openxmlformats-officedocument.wordprocessingml.document

と

application/vnd.openxmlformats-officedocument.wordprocessingml.documentapplication/vnd.openxmlformats-officedocument.wordprocessingml.document

を追加すると判定に引っかかってくれます。
あとはPHP自体の修正を待ちましょう。

web制作

iPhoneでページ下部のタップイベントを確実に発火する方法

Posted on by admin

スマホ用に見やすく設定されたWEBページのパターンの1つに画面下に固定されたナビゲーションがあります。ユーザーの親指の位置に近いので良いデザインかと思いきやiPhoneで落とし穴があるので注意が必要です。

iPhoneでページ下部固定メニューをタップしても一回では動かない問題

iOSの標準ブラウザsafariで下に表示されるステータスバーが非表示の時はその表示エリアのタップイベントがブロックされる仕様になっています。さらにiPhoneX、iPhone11は今までと画面の形が違うのでセーフエリアというものが存在します。これもも含めてタップイベントがブロックされます。

解決方法（ブラウザハック風）

CSSでイベントブロック箇所を避けて配置されるように指定します。

  1. viewportにviewport-fit=coverを加える
   <meta name="viewport" content="initial-scale=1, viewport-fit=cover" />

これを加えることで後述の「safe-area-inset-*」が使えるようになります。

  1. css変数「safe-area-inset-*」を使用して位置を調整する
  .selector {
    position: fixed;
    left: 0;
    bottom: calc(env(safe-area-inset-bottom) + 44px);
  }

safe-area-inset-*はiPhoneX、11用の値になります。
env()はセーフエリアの大きさを取得するための関数です。
つまりbottom値は「下のセーフエリア分の高さ＋ステータスバーが隠れているデッドゾーンの高さ44px」という事になります。
「calc使ってたらIE11で効かないじゃん」と一瞬思いますがスマホ前提なので問題ありません。

更に詳しくは以下の記事がとてもわかりやすく書いてあります。
CSSだけでiphoneの特殊な画面に対応する方法と、XcodeとXAMPPを使って実際に確認する方法|Webデザインの教科書

解決方法（ステータスバーを隠さない）

CSS変数で対応する方がスマートですがviewportがいじれなかったり、CSSを位置をずらしたくない場合は無理やりステータスバーを常時表示することで確実にタップイベントを発火させることができます。

<body>
  <div id="body">
    <p>コンテンツ</p>
  </div>
</body>
#body {
  height: 100vh;
  overflow: scroll;
  /* -webkit-overflow-scrolling: touch; @XXX 不要になりました */
}

※なぜ「-webkit-overflow-scrolling」が不用になったか？

これはiOS5～13のsafariだけのプロパティになります。もともとページ全体のスクロールはスムーズでしたが要素内のスクロールは以前は現在のようにスムーズではありませんでした。そのため要素内のスクロールはこのプロパティをつけることでスムーズに惰性スクロールを再現できました。現在はこのプロパティがなくても十分スムーズにスクロールされるように端末（ブラウザ？）が改良されているのでなくても問題ないようです。

ステータスバーはやっかいなのでじっくり対応しましょう

今回だと解決法１の方がスマートで好きですが、デザインを変更しなくてよいので２の方が使用頻度は高いかもしれません。一番良いのはメニューを画面下部に置かないことですね。ブラウザの機能を阻害することは避けたいものです。

生活

いくらかかる？いまさらメリットある？子供に習わせる前に知っておきたい習字、書道のこと。

Posted on by admin

子供の習い事で昔から言われていることは「読み書き、そろばん」です。
このうち「読み書き」にあたる習字ですがパソコンでほとんどの作業が終わる現代に筆を習うことは本当に有意義なのでしょうか？「子供に書道をならわせようかどうしようか……」迷っている親子さんに書を習わせるメリットを紹介します。

大人になったら結構必要な書道経験

子供時代には必要性を感じない書道経験ですが社会人になると書道経験を積んでおいた方が良いなという場面は少なくありません。

結婚式でのご祝儀、お葬式のご香典、会社・役所に提出する書類などはだいたい手書きになります。

書道経験がないと結構大変かもしれません。

社会人でも若いうちは良いかもしれませんが中年以上になったら文字が汚いと恥ずかしいです。

文字が汚いと何が一番問題なのかというと相手に伝えたいことが伝わらないことがあるということです。

以外と文字の汚い大人は多く、手書きでの指示書が読みづらいことも多々あります。読ませる気があるのかと思うくらいです。

人間長い期間で染みついてしまった悪習はなかなか治らないものなので子供のうちから書道を経験しておくと長い目で見て大きな財産になります。

書道教室や筆耕（お金をもらって代筆する）で報酬を得られる可能性がある

書道はどんなにパソコンが浸透してもなくなることがないでしょう。逆にパソコンが浸透していけばいくほどその価値は高くなるかもしれません。

書道を続けていき師範のレベルまで行けば書道教室を開くことができお金を稼ぐことができます。

また、人に教えなくても筆耕という仕事にもつける可能性があります。

もちろん書家になることもできます。

始める時期はいつが良いのか

子供が漢字に触れ始めるのは小学一年生からです。

そのころには子供の友達で書道教室に通いはじめる子が出てきます。

そうすると「〇〇ちゃん〇〇くんは習字習っているんだけどすごいな」「自分も通ってみたいな」と興味を持ち始めます。

興味を持ち始めた時が行かせる絶好のタイミングと言えるでしょう。興味がないのに強制的に行かせると長く続くことはほぼないでしょう。

費用はどれくらいかかるの？

月およそ3000～6000円程度です。

教室によっては月謝のほかに教材、半紙、墨などの消耗品を別途請求する場合もあるのでそこは月謝込みかどうか確認が重要です。

ほかの習い事に比べて比較的安価ですが毎月の固定費が増えることには変わりないのでなるべく費用は抑えたいですね。

どこに通わせればよいのか？

書道界には全体的に統一された基準というものが存在しません。

ですのでどこの書道教室に通っても基本的には問題ないと言えますが子供には長く続けてほしいですからやはり「先生との相性」が大事でしょう。

書道は書けば書くほど上達すると言われています。

書家のような特別な存在になるというのは置いておいて、続けることさえできていれば大人になってから活用できるレベルまでになれます。

書道の公的な唯一の資格「毛筆書写検定」

書道界には全体的に統一された基準がないので書道〇〇級、段などの階級は各教室独自の階級になりますが公的な書道の唯一の資格があります。

文部科学省が後援している「毛筆書写検定」というものです。

一級から五級まで階級があり、一級になると指導者として書道教室を開くことができるようになります。

公的な資格扱いなのであくまで書道教室独自の階級よりかは履歴書の資格欄に迷いなく書ける資格といえるでしょう。（採用担当者がこの資格のことを知っているかは疑問かつ文字が綺麗なら履歴書の文字を見ればわかりますけどね）

突き詰めなくても「たしなみ」として身につけるべき

まだまだ我々は「文字が綺麗な人はちゃんとしている」という先入観を持っています。

また日本の書道は世界でも人気で世界に誇る日本の文化になっています。

だからこそ書道は日本人の「たしなみ」として当たり前に習うべきと思っても良いかもしれません。

web制作

そのページでは使っていないjQueryプラグインでエラーを出さないように。jQueryプラグイン存在判定の方法

Posted on by admin

フロントエンドは開発方法の発展のスピードがすさまじくjavascriptもそのまま書かずwebpackなどのツールを使用することが増えてきました。
jQueryに関しては脱jQueryが段々広まっているように見えますが案件によってはまだまだjQueryのお力を借りなければいけません。それはライブラリが豊富でスピーディーに開発できるからです。

WordPressのテーマを作成する際javascriptは共通フッターで呼び出し、どのページを読み込んでも同じjsが呼び出される処理を書いているものも多くあります。

しかし特定のページでまったく使用しないのにライブラリの外部ファイルを呼び出すのはとてもパフォーマンスに悪影響な気がしてなりません。

そこで外部ライブラリを呼び出している部分をheadタグ内から削除します。これで1つ呼び出しがなくなりすっきりすると思いきや開発ツールでエラー表示が……。

内容を読んでみるとwp_foot()で呼び出している共通javascriptファイル内でさきほど消した外部ライブラリを呼び出してるとのことでした。

私は外部ライブラリをwp_head()で吐き出されるように、共通javascript（自作）をwp_footer()で呼び出すようにしているためこのような事態に陥ってしまいました。

このような時はどうすれば良いでしょうか？javascript内でプラグインを読み込んでいるか判定してからプラグインを呼び出すようにjavascriptコードを変えてあげればよいのです。

▼プラグインを読み込んでいるか判定してからプラグインを呼び出すコード

<script>
$(function) {
  if (typeof $.fn.対象プラグイン名 !== 'undefined') {
    // 対象プラグイン呼び出し部分
  }

  // もしくは……
  if ($.fn.対象プラグイン名) {
    // 対象プラグイン呼び出し部分
  }
}
</script>

↑このように書くことによって外部プラグインを読み込んでいない場合でもエラーは表示されません。