メモ

要素をタイルで並べておいて、フィルタをかけたりソートしたりできる、便利なjQueryプラグイン「MixItUp.js」。 これを使ったところ、アニメーションがおかしくなるという現象が起こりました。 発生するのはこんな感じ。 １．フィルタを設定してあるボタンをクリック ２．条件に応じて要素の表示が切り替わり、移動のアニメーション開始 ３．一度移動が終了 ４．要素が再びおかしな位置にワープし、アニメーションがもう一度発生 要するに、ちらつくといいますか、一回終わったのにまたパパっと２回目のアニーションが始まってしまうのですね。 で、これ、原因は簡単でして、CSSのtransitionが指定してあると発生します。 transitionはCSSの設定が変わったときに、一瞬で切り替わるのではなく、アニメーションしながら切り替わるようにする設定です。 MixItUpの場合は、移動はjQueryで制御しているのに、CSSのtransitionも入っていると両方が動作してしまうということですね。 transitionを設定するときはめんどくさいのでallとしてしまうことが多いと思いますが、jQueryのアニメーションと競合しがちなので最低限の要素に設定したほうが安全です。 また、もちろん不要なら削除しましょう。

Firefoxでアンカー付きで別のページに移動したときに、ページが正しくない位置にスクロールするという現象が発生しました。 A.htmlページ内のリンクで、「href="B.html#anc1"」などとなっていて、クリックすると、B.htmlのanc1の箇所が表示されないということです。 この現象、ググってみると、同じような症状の報告が結構古くから有るようです。 Firefoxに以前から存在する問題なのかも。 ただし、古くから報告されている問題が、現在発生している問題と同じものかどうかは分かりません。 現象が同じでも原因が違うことは考えられます。 当然もともと発生しない場合もあるし、「こうするとなおる（かも）よ」というアドバイスはいろいろ出てきます。 しかし、いくつかの方法を試しても今回僕が遭遇した現象は解消しなかったのと、いちいち原因を考えるのもしちめんどくさえので、一気に解決できるJavaScriptを組んでみました。 ■■==スクリプトここから  window.onpageshow = function(){   //ページのURLからアンカー部分を取得   var myhash = $(location).attr('hash');   if ( myhash.length > 1 ) { //アンカーがあった場合     if($(myhash).length){ //アンカーに対応するidの要素があった場合       var nScrolltop = $(window).scrollTop();       var nOffset = $(myhash).offset().top;       //現在のスクロール位置とアンカーに対応するidのY座標（本来有るべき位置）を取得       if( Math.abs(nScrolltop-nOffset) > 5 ) { //2つの位置の差が5以下の場合   ...

条件がいまいち確実にわからないのですが、iPad miniでレイアウトが崩れることがあるようです。 おそらく条件はこんな感じ。 ・display:inline-blockを指定している ・iOS9  どんな現象かというと、文字であらわすとこんな感じです。 【正しい表示】 このボタンをクリック 【1文字落ちた表示】 このボタンをクリッ ク 派生して、overflow:hiddenを同時に使っている場合は、最後の1文字が消える現象のようにも見えます。 また、改行する要素としない要素が並んでいる場合、inline-blockは基本が下ヨセなので、頭がそろわずにガタガタになります。 どうやらiOS9のバグなのではないかと思いますが、簡単に解決する方法があります。 それは、 white-space:nowrap を指定する。 これで落ちなくなります。 nowrapが指定できない場合は、、、、困りますね。

簡単に使えて便利なスライド用のjQueryプラグイン「Slick.js」ですが、１つ気に入らない点が。 それは、カルーセルをやって、マウスでつかんでスライド使用とすると、カルーセルの各コマに枠線が表示されてしまうところ。 これは中身をクリックした時点で発生しますので、つかまなくても、「slick-slide」というクラスがついた要素の中身をさわると囲み線が表示されます。 カルーセルからlightboxを表示しようとしている場合などにも問題で、裏で枠線が表示されているというちょっとかっこ悪い感じになってしまいます。 解決法は簡単で、「slick-slide」のクラスに「outline:none;」を指定するだけです。 最初から設定してあると良いのですけどね。

css3には「vh」という単位があります。 ウインドウの縦幅を100vhとして計算されるため、数値で固定してしまうpxでの指定よりレスポンシブデザインと相性が良いですね。 さらに縦幅は%が使いづらい（親のボックスに依存したり、縦方向のpaddingを%で指定しても横幅基準だったり）ため、とても有用です。 しかし。 iPadでvhを取得したときの話。 内容全体を100vhとしているのになぜか縦方向にスクロールが発生してしまうという現象が起こりました。 これは「ウインドウの縦幅を100vhとする」という定義からしてあり得ません。 どうやらiOSのsafariでは、vhはアドレスバー部分も含めたサイズとして計算されてしまうようです。（ホントか？） まぁ、平たく言ってバグ、と思えるのですが、実際そうなってしまっている以上、泣きをみるのはサイト制作者であり（笑）、何らか対処せざるを得ません。 かといって、端末判定などはしたくない。 今後のことなど汎用性を考えるとなるべくトリッキーなことはしたくないのです。 そこで今回やった対処はこんな感じ。 １．基本的には100vhで設定しておく 　→PCや正しくvhが取れるブラウザはこれでOK。 ２．jQueryで、$(window).height()と、100vhを指定してある要素のheight()を比較し、$(window).height()の方が小さい場合は100vhを指定してある要素の高さを設定し直す。 ３．一瞬ちらっと見えてしまうのは嫌だったので、内容全体はいったん外に飛ばすか、loadingを被せるなどして隠し、処理が終わったら見えるようにする。 これで、今後iOSでvhが正しくとれるようになったらそれはそれで大丈夫。 問題は３点。 １．100vhが設定してある要素が多い場合は再設定が面倒。また、今後増えたときにも設定を忘れないようにする必要がある。 ２．100vh以外にもvhを各所に使ったレイアウトの場合はずれが許容できるかどうか要チェック。 ３．一瞬ちらっと見えてしまうのを嫌っての対処が追加になってしまう。 まぁ、スマホ・タブレットは、スクロールしたときにアドレスバーが縮む影響でvhの値も変わるし、ウインドウのリサイズイベントが発生するし、制作者的にはいろいろネ...

Web制作において、サポートが終わっていると分かっていても、一定数のユーザーがいることからなかなか切れない古いIE。 さすがにIE8はもう良いでしょとなってきています。 IE9、IE10も良いでしょ、と個人的には思いますけれども、対応出来ないわけでも無かったりするので、じゃあした方が良いかって話しになっちゃったりします。 まぁ減っていたとしても少しはいて、観られるなら観られるに越したことはないのですよね。 （ベンダーのサポートが切れている場合は正式に対応していますとは言えないでしょうけど） で、対応するとなると困るのは検証環境。 サポートが切れた環境なので用意もしづらいのですよね。 IEtesterなんていう古いブラウザをエミュレートするようなソフトを使っていた時期もありましたが、最近では、OS含めて環境自体をバーチャルマシンで動かして確認出来るようです。 ちょっとこの際環境を作ってみました。 （１）VirtulBoxをインストールして、仮想環境を動かす準備をする （２）マイクロソフトから配布されている旧OSのイメージをダウンロードして仮想環境を構築する この２ステップ。 無料です。 ただし、全て自己責任で！ （１）について https://www.virtualbox.org/ ここからVirtualBoxというソフトを入れます。 これをインストールするとコンピューターの中に仮想のコンピューターのハードができる感じ。 （２）について https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ このマイクロソフトのサイトからOSのイメージファイルを入手します。 OS+IEのバージョンが選べます。 またプラットフォームはVirtualBox用のものを選んでください。 ダウンロードしたら解凍し、VirtualBoxの「ファイル」→「仮想アプライアンスのインストール」で出てきたファイルを読み込みます。 特に設定変更する必要は無さそうですけどお好みに応じて。 しばらく待つと完了して晴れて使えるようになります。 僕の場合はネットも普通に繋がりました。 注意点は ・ハードディスクの容量が結構必要なこと ・マイクロソフトのOSイメージは...

IE9なんてもう過去の遺物なんですけど、どうしても対応せい、ということもあるわけで、しかし実際に確認できる環境を用意するのも一苦労だったりして。 で、仕方がないのでIE11の開発者ツールについているエミュレーター（エミュレーション）で、IE9モードにしてとりあえず見てたりします。 で、おおざっぱにはIE9っぽい動きになってくれるのですけれどもどうもこれが不完全でして。 例えば、css3のtransformという設定はIE9ではプレフィックスなしでは効かないはずなのですけれども、エミュレーションだと効いてしまう。。。 あくまでエミュレーターだから100％信頼できるとは思っていないけど、それにしてももうちょっと再現性を高くしてほしかったところです。 ちなみにcss3のtransformをIE9で聞かせるには「-ms-」というプレフィックスが必要です。 念のためにプレフィックス付きの設定も一緒に入れておくことに多分デメリットは無いんですけれども、どうしても不要ならできるだけ減らしたいという思いがあって抜いてしまうとIE9でハマるという、罠に堕ちました。。。 IE9は2016年中にほぼサポートが終了、WindowsVista版のみ、OSの都合上IE10が入らないことからサポートが続いていましたが2017年4月11日をもってマイクロソフトのサポートが終了したようです。 サポートしていないブラウザには対応したくないのですが、アクセス解析で見ると、全体の1～2％程度のシェアはあるようで、月間10万人来るサイトだと1000人くらいですか。 うん、少なくない。 しかしここから、「ほぼゼロ」というレベルになるまではたぶん相当時間がかかると思われるし、ほんと、そこに対応する意味があるのかどうかは考えたほうが良いと思う。

最近あまりやりませんが、昔流行った、背景に画像を敷いてtext-indent:-9999pxなど、マイナスの大きな値を設定し、文字を消すテクニック。 それがSEO的にどうだとかそういうことはおいといて、単純にそれを設定しても思ったように文字が消えなかった時の話。 text-align:rightと一緒に設定していると、文字を左側に飛ばしても、右に出てきちゃうから消えないという、言われてみれば単純なことでした。。。

古いIEでアンカーリンクが効かないという事は、残念ながらよく起こります。（笑） まぁ、いろいろありまして、よくある解決としては ●アンカーリンクの中身が空（何も入っていない）と飛ばない。 　→何か入れる、もしくは何か入っている要素にIDを設定し直す ●なぜかアンカーリンク（ ... ）の前に タグを入れると飛ぶようになる。 とかね。 一般的な方法はGoogle先生で出てきます。 だがしかし、今回遭遇した現象は前例を見つけることができず、自力で解決しました。 その現象とは、「マイナスのマージンが付いている要素を飛び先にすると、アンカーが効かない」というもの。 うーむ。 まぁ、マイナスのマージンなんて使わない方が良いとは思っています。 が、そこはそれ、大人の事情で使っちゃったよテヘみたいな場合もあるのです。 その要素をアンカーリンクの飛び先にした場合、IE9以前で無効になるようです。 対応としては、今回は下記のように書き換えました。 （元） margin-left:-10px; （書き換え） position:relative; left:-10px; ということで。 これで表示を維持してアンカーリンクも効くようになりました。 が、場合によってはこういう置き換えができずにちょっと大きく構成を変える必要がでてくる可能性もあるよねー。 いやいや、ハマッた、ハマッた。

昔から有る手法ですが、テキストの画像置換というものがあります。 見た目をきれいにするために画像を使いたい、だけど、検索エンジン対策を考えるとテキストの量も確保したい、そういうときに使うテクニックですね。 文字が入っているボックスにCSSでtext-indent:-9999pxを指定すると、文字が左側に大きく飛んで消え、画面に表示されません。 同時にボックスの背景に画像を指定すれば、文字なしで画像だけが表示される仕組みです。 ※最近ではtext-indent:100%なんかを使う手法も有りますが、結局は同じ事。 　その他にも文字をdisplay:noneするとか、画像を上にかぶせちゃうとかありますが、まぁ、これらも同じでしょう。 これらは言ってみれば重要なテキストを隠しているということです。 検索エンジンのボットにだけ見えて、人間に見えないテキストを入れているということは、 極端な話スパムと言われても反論しづらい。 遙か昔にあった、背景と同じ色にした文字を大量に入れ込むことで検索上位を狙うとかそういうのと同じと取られる可能性もあります。 が、違う点は、（多くの場合）スパムとしてやっているわけではない、ということ。 つまり、画像に含まれている文字だけを入れているのであって、不正にキーワードを水増ししているわけではない場合がほとんどでしょうし（そうでないならスパムですけど）、画像を使って見た目をととのえるというのはユーザビリティの向上にもつながります。 不正にキーワードを埋め込むスパムとは発想が違う点もあるので難しいところ。 先に結論を言いますと、この問題、白黒つけがたいです。 私個人の意見としては、現状使っても問題ないと思われるが、使わずにすむなら今後は避けていきたい、というところです。 さて、まず、文字を画像に置換するメリットをもう一度整理。 ●メリット １．見栄え良くできる ２．検索エンジン用にテキスト（キーワード）の量を増やせる ３．ソースの見栄えが良い １は大事なことです。 最近海外のサイトではWebフォントの使用も増えてきたし、そもそも元々アルファベットは画像化しなくても見栄えよくしやすいと思うのですが、日本語はなかなかそうもいきません。 文字数が多いので昔から書体は高い。Webフォントも出てきて...

なんというか、関連するテーマが多すぎて分類できない話なんですが、事の発端は別々の表組みのtdの横幅をそろえたくて、必ず広くなる方が分かっているため、width()で値を取得して、もう一つに設定という方法を思いついた。 が、IE9でうまくいかない。 現象はこんな感じ。 ・設定を取得する表（以降「取得元」）は普通。 ・設定を適用する表組み（以降「設定先」）はcolspanを使っている ・tableのcellpaddingで「5」を設定している ・DOCTYPEはTransitional この場合、Operaでは取得元のtdのwidthをとってきて、設定先のtdに入れても幅がきっちりそろったのだが、IEではやや設定先がやや狭くなる。 比較してみると、一律10ピクセル小さいことが分かった。 どうやらcellpadding分（左右分だから5×2）だけ小さくなっているようだったので、試しにcellpaddingを0にしてみたらきっちり合った。 IEのTransitionalの場合、jQueryのwidth()は、「取得する値にはpaddingを含まない値」をとってくるが、width(数値)で値を設定する場合は、「設定した値にはpaddingを含んでいる」ということだろうか。 この現象はcolspanを使っているときに発生するらしい。 試しにCOCTYPEをStrictにしてみたところ、Operaでもうまくいかなくなってしまったりして、どうも表組みのtdの幅というのはcolspanを使っているセルがある場合にいろいろ怪しいみたいだ。 colspanを設定しているセルに対してもきちっと適正なwidthを設定すればいいのだろうけど、そりゃめんどくさかったので却下。 結局tdの中にdivを入れて、div通しで幅を合わせる方法に変更。 コードが長くなるが、とりあえずcellpaddingやcolspanに影響されずに二つの表組みの間でセルの横幅を合わせることができた。 これはjQueryというより、HTMLとCSSについての話になるのかな。 結果的にはかなり強引な解決方法になってしまった。。。

（最近はあまり使わないですが）iタグ、それとスタイルシートのfont-style:italicを指定したとき、WindowsのInternet Explorerで斜体（イタリック）にならない時があります。 （Windows Vista/IE8にて確認。ただし、後述する原因のため、他の組み合わせでも広く発生するはずです） 原因は非常に単純で、メイリオを使用している場合には、メイリオに日本語の斜体が用意されていないため、斜体にならない、ということでした。 このことはMicrosoftのサイトにも掲載されています。 ■Windows Vista のメイリオ フォントの文字列が斜体にならないことがある http://support.microsoft.com/kb/929886/ja 英数半角文字は斜体になるようです。 メイリオを使っていても、FireFox・Operaでは斜体になります。 これらのブラウザは、用意されている書体を使うのではなく、独自に斜体を作るのでしょうか。（もしかしたら斜体がない書体だけ？） とにかく、ブラウザ毎に動作が違うもので、例によってIEのバグの線で調べていたので、こんな単純なことに時間を食ってしまいました。 まぁ、バグと言えばバグのような気もしないでもないですけどねぇ。 もっとも、日本語の斜体というのは読みづらく、とくにWebの本文で使うことはほとんど無いと思います。 今回はCKeditorというAJAXの文章装飾ツールを組み込むにあたって、動作検証中にこの問題が起こりました。 お客様のクライアントはIEである可能性が高いので、結局斜体の機能は削除することにしました。 うん、まぁ、使わないよ、有っても。（笑）

パスもちゃんと設定しているはずの外部ファイルが、正しく読み込まれない（適用されない）場合があります。 私がたまにはまる原因は単純ですが、文字コードが違う、というもの。 別ファイルだとたまにやってしまいます。 当たり前のことですが、読み込むHTMLと読み込まれるCSS、JavaScriptの文字コードはあわせなくてはいけません。 さらに、先日起きた現象。 Safari4、iPhoneOS3のSafariで、CSSが無効になると言うもの。 調べてみたら、外部CSSの最初に入れるべき文字コードの宣言が２行目になされており、文字コード宣言の前に日本語のコメントが入っていたことが原因でした。 これも当たり前と言えば当たり前のことですが、文字コードの宣言はできるだけ上に入れるものです。 ファイル自体のエンコードが正しかったせいか、Safari5を含め、ほとんどのブラウザで正しく表示されていたため、最後の最後まで見落としてしまいました。 社員の一人がアップデートしていないiPadでサイトを見たことで気づくことができたという。。。 無精もたまには役に立ちます。（笑） 文字コードは目に見えないので、注意が必要ですね。 --

サイト製作時に別の作業者のところで発生した問題。 IE6とIE7で ～ が消えてしまうというものでしたが、いろいろ調べた結果、親要素に「text-indent:-9999px」が指定してあったことが原因と分かりました。 1つ上の に設定していたのではないのですが、継承されて影響したようです。 しかし、text-indentで位置が変わってしまうと言うことは、IE6/7では、 はインライン要素として処理されているということです。 FireFox、Opera等では意図通りだったため、これらのブラウザではブロックレベル要素扱いになっていたと言うことです。 さて、これはどういうことか。 どうもこの辺のHTMLの定義が、曖昧なようなのですね。 他にもtableの子要素のなども、インラインなのかブロックレベルなのかよく分からない。リストとテーブルが怪しいですね。 に関しては、新しいブラウザではブロックレベル要素と扱われているようなので、一般的にはそっちに分類されるのだろうか。 まぁ、こういうことになってしまっているのは仕方ないし、そうなってしまった経緯とか、本来どうあるべきなのかは興味ないです。僕ら製作者としては現象が全てなので、意図通りに表示されれば何でも良いです。 そんなわけで僕自身は基本的に は「display:block」を指定して、明確にブロックレベル要素として設定するようにしています。

cssだけに限りませんね。jsとかphpでincludeするファイルとか、要するにそれらの文字コードが揃っていないと文字が化け化けになった結果、タグに使う文字（三角括弧やクォーテーション）が出てきてしまうと全体のタグ構成がおかしくなるので崩れます。 最近では基本UTF-8で組めば良いんだろうけど、携帯対応とか古いプログラムの流用とかでShift-JISを使わざるを得ない場合もあったりして、DreamWeaverの設定を切り替えながら作業していると、たまに忘れちゃうときがあるんですね。複数スタッフで１つのサイトを時なんかに紛れ込んだりもします。 文字コードって重要ですね。。。

新人がよくはまります。 classやidの名前を数字で始めてはいけないんですね。 文字としては使えるんですけど、最初はアルファベットを使うと。 ところがなぜかブラウザによってちゃんと見えてしまったり、そもそもDreamWeaverのプレビューでOKだったりしちゃうので、ハマルと気づかないのです。たしかIEでcssが利かないと思った。 基本的なチェックポイントなんだけど、あまりに基本過ぎて見落としてしまう事があるので記録。

文字を画像で表現したいときにblock要素の背景に画像を指定して、text-indentにマイナスの値を指定して飛ばすというのは良くある方法。（画像置換、CSSでググるといっぱいでてきます） これの是非はともかくとして、実際問題よく使う。 で、たまに起こるのが、IE6で、CSSで指定したheightよりもボックスの高さが大きくなってしまってレイアウトが崩れたり、見えちゃ行けない部分の背景画像まで見えてしまう。 例えば次のように書くと発生する。 ■HTML側 <a id="test" href="#">画像置換</a> ■CSS側 a#test {  display:block;  font-size:12px;  line-height:18px;  width:200px;  height:12px;  background-image:url(img/test.gif); } aをblock要素にして文字を画像で置き換えたいのだが、問題はaボックスの縦よりもline-heightの指定のピクセル数が多いこと。こうするとIE6ではaボックスは高さが18pxになってしまうようで、上記のコードだと、背景画像がリピートしてしまう。 上記のようにline-heightとheightを同じ場所に書いているなら気づくでしょうが、line-heightが別のところに（初期設定として全体に影響するように）書いてあると気づきづらいかも。他のブラウザで大丈夫なので、「またIE6かよ」と思ってしまうが、これはこれで一理あるような気もしますね。

CSSで上下中央揃えをする方法。 横のセンタリングはtext-align:centerとmarginのautoを使えば良いですが、縦で中央にそろえるのはちょっと面倒。 昔はある意味簡単に、Tableタグを使ってやってましたが、最近はそうも行かず。かといって「display:table-cell;」はIE6、IE7が非対応。 調べてみたところ、結局はIE6とIE7はhackを使ってinline-blockとする、次の方法が今のところ良いみたい。（2年前の情報ですけど、役立ちそうなので忘れないようにリンク。） CSS で簡単に上下中央揃えを実現する display:table-cellが実用的に使えるようになるのはいつのことか。。。jQueryで同じことができるプラグインとか有ればいいのに。