iPhoneのスクロールバーをカスタマイズする時、jsで実装するとスクロールの挙動が変わる。
デフォルトの挙動を残したかったので、::-webkit-scrollbarを使おうとしたが表示されなかった。

参考URL

・iOS13でCSSでスクロールバー拡張できる::-webkit-scrollbarが使えなくなったよう
https://am-yu.net/2019/09/27/ios13-webkit-scrollbar/

・慣性スクロール実装でスクロールバーは常に表示できない？
https://fantastech.net/scroll-bar

・iOS デフォで慣性スクロールできるようになった？
https://qiita.com/cubkich/items/d192a70856e8bc63c7bc

考察

1. iPhoneで慣性スクロールを指定すると、::-webkit-scrollbarが使えなくなる
2. iOS13から慣性スクロールがデフォルトになった
3. デフォで慣性スクロールなので::-webkit-scrollbarが使えなくなる

参考URLから察するに、これが原因思われる

iPhoneのスクロールバーをカスタマイズする時、jsで実装するとスクロールの挙動が変わる。
デフォルトの挙動を残したかったので、::-webkit-scrollbarを使おうとしたが表示されなかった。

参考URL

・iOS13でCSSでスクロールバー拡張できる::-webkit-scrollbarが使えなくなったよう
https://am-yu.net/2019/09/27/ios13-webkit-scrollbar/

・慣性スクロール実装でスクロールバーは常に表示できない？
https://fantastech.net/scroll-bar

・iOS デフォで慣性スクロールできるようになった？
https://qiita.com/cubkich/items/d192a70856e8bc63c7bc

考察

1. iPhoneで慣性スクロールを指定すると、::-webkit-scrollbarが使えなくなる
2. iOS13から慣性スクロールがデフォルトになった
3. デフォで慣性スクロールなので::-webkit-scrollbarが使えなくなる

参考URLから察するに、これが原因と思われる。

解決策（模索中）

「iOS13から慣性スクロールがデフォルトになった」のはAppleの公式発表から読み取れる。

Added support for one-finger accelerated scrolling to all frames and overflow:scroll elements eliminating the need to set-webkit-overflow-scrolling: touch.

Safari 13 Release Notes
https://developer.apple.com/documentation/safari_release_notes/safari_13_release_notes#3314682

「-webkit-overflow-scrolling: touch」を記述しなくても慣性スクロールになるなら、
これを打ち消せば「::-webkit-scrollbar」が使えるのでは...??

「-webkit-overflow-scrolling: auto」と記述しましたが、うまくいきませんでした。

ここ 10 年ほどフロントエンドをやっている人ならこう言う場面に出くわしたことがあると思います。

この新しい JS と CSS のフィーチャーはめっちゃ良さそう！使って見よう！

やった！Chrome でテストして見たら思った通りに動いた！

他のブラウザーもテストしようと…はい、だめでした ?

私はこうなったことがあるしこれを読んでるあなたもそうでしょうね。

実はと言うと、こう言うブラウザーの互換性の問題はフロントエンドでありきたりすぎて最近 Mozilla さんがやって来たWeb DNA Report 2019で性別、国籍、フロントエンドをやっている経歴など関係なくダントツで一番の苦痛として選ばれました。

そして、最近で言えば大体 Chromium のチームは一番最初に新しい JS と CSS のフィーチャーを導入するけど、それを使いたいとサポートしていないブラウザーのために Polyfill を入れないといけないし Polyfill が存在しないともう使えなくなります。

しかし、この記事のタイトルから察したと思うがいつもそうとは限りません。

今回は Chrome もときどきおかしなことをする例を見せようと思います。

問題

私が今作っているプロジェクトでデザイナーは縦型のプログレスバーを入れようとしていました。

そのプログレスバーはいくつかのパーツに別れていてプログレスをそのパーツを通すグラディエントで見せる仕組みでした。

ザッと言えばこんなものです。

最終的にデザイナーは別案で行きましたがこれを最初に見たときこれをどうにか画像に頼らず CSS だけで作れないかな〜って思いました。

調べた結果background-size: coverと background-attachment: fixedとbackground-image: linear-gradient(params)の組み合わせで私がやりたいことに大変近いことができると知りました。

これを知って浮かれていた、早速テストしようと思ってこのコードでやってみました。

これを複数のブラウザーでテストしたら以下の通りになりました。

ちょっと待って！？ ?

見ての通り Mac OS 版の Chrome はちゃんと表示できるのにも関わらずなぜか Android 版の Chrome だけがこれをちゃんと表示できません。

これを不思議に思いました、Chrome はモバイルでも PC でも大体同じフィーチャーに対応しているのですから。

調べれば調べるほどおかしいと思いました。

CanIUseによると Android 版の Chrome でこれはちゃんと表示できるはずです、しかも iOS 版の Safari では表示できないはずです。

でもテストの結果はこれとは全く違うことになりました。 ?

理由を見つけ出す

いろいろなことを調べている内にこのStackOverflow の質問を見つけました。

ここでの答えによるとbackground-attachment: fixedはしばらくは対応されていたがパフォーマンスに影響が出ると言う理由でモバイルでの対応を切りました。

これにはある程度納得できるけど、iOS 版の Safari や Android 版の Firefox や IE11 までも対応しているのに Android 版の Chrome は対応していないのはやはりおかしいと思います。

結論

結局のところ対応したいブラウザーで表示できて、画像や JS を使わない他のやり方を見つけられませんでした。

幸い必要がなくなったけど他に方法を知っているなら教えて欲しいところです。

伝えたいことは主に、Chromium は大変素晴らしいエンジンですし作っているチームは Web でできることを進化するためにすごくがんばっていると思いますが結局のところ他のブラウザーと同様フィーチャーに対応したいかどうかをわりと勝手に決めることはできます。

もちろん、IE や Chromium ではない Edge や Safari に比較すればものすごく稀な例ですがこれがいつでも起こり得るのでそれを忘れてはいけないと思います。

他にこれと似たものに出会ったことはあるならぜひコメントで教えてください、勉強になります。

開発したもの

もぐら叩きゲーム（Webアプリケーション）
http://yusuke97.html.xdomain.jp/index.html

きっかけ

javascriptを触れる機会があり、勉強していくうちに楽しくなっていき何か形にしたかったこと。

こだわったところ

• スマホでもPCでも遊べるようにする
• 誤ってズームしたり,画像を選択しないようにする
• レスポンスを速くする
• シンプルなUI

使ったもの

• javascript
• CSS
• html
• Cent OS
• Apache HTTP Server（ローカル開発環境）
• XFREEのレンタルサーバー

開発の流れ（1人, 2週間）

1. 使う写真をダウンロード、加工
2. もぐらが動くようにする（1匹だけ）
3. 10匹のもぐらが動くくようにする
4. 配置を変える。
5. もぐらを叩いてから反応する時間を短くする。
6. 初級と上級に分ける。

難しかったこと

• javascriptの非同期通信
• もぐらを叩いてから反応する時間を短くする。
• スマホでもPCでも遊べるようにすること。
• ブラウザによって挙動が違うところ。

感想

コードによって全然レスポンスの速さが違ったりブラウザによってもぐらの挙動、位置、bgmが違っていたので、難しかった。しかし、javascript,CSSが意外と深いことがわかり面白かった。もっと速いWebアプリケーションを開発するためにもっと深く知りたいと思った。

最後に

間違いがあればコメントくださるとありがたいです。

はじめに

CSSとHTMLだけで、要素（画像など）を縦にフワフワと動かしてみます。
下記参考ページの「一番上のスマートフォン」のような動きが可能です。
【参考】
https://www.ana.co.jp/ja/jp/amc/promo/app-service/

方法

動かしたい要素のclassに任意の文字列を設定します。
この場合は「img scr="○○○"」に対して、classを設定します。

HTML

index.html

<img scr="○○○" class="####">

その任意の文字列に以下のコードを設定

CSS

style.css

.#### {
    animation-name: ▲▲▲▲;
    animation-timing-function: ease-in-out;
    animation-iteration-count: infinite;
    animation-direction: alternate;
    animation-duration: 1.5s;
}

「####」に対して設定した「animation-name」内の「▲▲▲▲」に対して、以下をCSSに記入

CSS

style.css

@keyframes ▲▲▲▲ {
    0% {
        transform: translate(0,0px);
    }

    100% {
        transform: translate(0,-15px)
    }
}

以上で要素「img scr="○○○" class="####"」が上下にフワフワ動きます。

ぜひお試しください！

参考リンク

以下の記事もご参考にどうぞ。

・cssのkeyframesで要素に動きや変化をアニメーションでつけるサンプル
http://mugen00.moo.jp/web/css/keyframes-sample

多少調べたのでメモがてら(というか残骸)。
なお本情報は2019/01/15日現在のもの。間違いがあればご指摘を。

ライブラリを導入する前に考えて起きたいこと

この記事などが特に参考になりますが、私が思うところとしては大きく分けて以下の４つ。

ライブラリの依存関係は複雑ではないか

導入が容易であるか。JSフレームワークを使っているのに、何の対応性も無いようなライブラリを使う選択肢ではないか。ライブラリ管理は常に複雑にならないようにすべき。

ドキュメントは参照しやすいものか

日本語であるかどうかは実はあまり関係ないかもしれない。サンプルコードの多さの方が大切。コードを読めば大体使い方が分かる。最終的には細かいcssは弄らないといけないのだし。

継続的に更新されているか

JSを利用するライブラリは定期的にメンテナンスされていないと安心感が無いのは事実である。CSSだけのライブラリにはそういった心配は無いかもしれない。とはいえ、古すぎると情報が出てこなくなることが多くなる。

ライセンスは商業的に利用出来るものか

当たり前だが厳しいライセンスは使用に耐えない時も多い。

フレームワーク

materialize

• MIT
• JS使用

---

メジャーどころ。これからの継続的更新も望めそうな気がする。
ボタンにアニメーションなども付いていてマテリアルデザインという考えに対して律儀なデザインやモーションをしてくれる。

vue.jsに利用するならvue-materializeというのも出てきたがこれはメンテされていないようだ(Vue.jsならば他にはVuetifyなどもあるようだが、コンポーネントとしてガッチリと使う必要があるようだ)。Angular や React ならそれぞれの独自フレームワーク使えば良いのではという印象。

Material Foundation

• MIT
• JS使用

---

CSS フレームワークとしては Bootstrap の次点くらいにつけていると思っていたライブラリのマテリアルデザインバージョン。
どうやら難儀していたようである。更新は止まりっぱなし。

Propeller

• MIT
• jQuery 使用

---

色々揃っている。サイトが時折遅く感じるのは私だけか？
最近は更新が止まっているように見える。

Material Design for Bootstrap

• MIT
• Bootstrap 4(jQuery)

---

もうちょっとドキュメントの記述が欲しい。
脱jQueryを目指すなら使えない・・・が別にjQueryをそこまでして取り除く必要もないのではないと思う私には良い選択肢に見える。

Daemonite

• MIT
• Bootstarp 4(jQuery)

---

時折更新が止まっているようだが、最近は更新をしているようである。
他のライブラリには無いようなパーツもチラホラと見かけられる面白い選択肢。

Onsen UI

• Apache 2.0
• JS含む

---

Using with Framework という欄があるようにフレームワークとの連携を重視している印象。
一方マテリアルデザインというよりもiphoneのミニマリズム的なデザインではある。webアプリをスマートフォンのようなデザインで作れる。

(本題から離れるが) CSS Only framework

CSSだけのライブラリの方が扱いとしては簡単かもしれないので一応載せる。JSのライブラリよりも体感として速いし、取り回しが良いのは事実である(特にアニメーション)。
ただし全てを内包するライブラリではないので他のライブラリよりもCSS/JSを書く必要がある。

bulma

• MIT
• 日本語記事多め

spectre.css

• MIT
• 更新止まり気味

調べた感想とか所管とか

• 有名所だけを並べただけの記事になってしまった。
• いつ見てもCSSフレームワークはどれも同じような見た目をしているように思える。
• どんなパーツがあろうとも、全体像がはっきりしないページはパーツの寄せ集め。

目次

・GoogleMaps印刷時に出る帯or余白のバグが起こる条件とは
・バグ内容について
・GoogleMaps印刷時に出る帯or余白のバグを回避解消する方法

GoogleMaps印刷時に出る帯or余白のバグが起こる条件とは

まず、今回の印刷時に帯のような余白のようなものがでる再現パターンは下記になります。

• GoogleMapsAPIを使用しての埋め込み
• chromeやsafariブラウザで横印刷時
• 特定のGoogleMapsサイズ

GoogleMapsAPIを使用しての埋め込み

今回の場合、google map の ifreme ではなく、 API を使用しての埋め込み時に起きました。
ifreme 使用時には起きなかったのですが、 google map API を使用すると起きるという現象でした。

chromeやsafariブラウザで横印刷時

また、再現の状況としては、 chromeやsafari ブラウザで起きており、
IEやEdgeなどでは帯や余白はないものの、
ページをまたがったり、他要素に被ったりと
これはこれでバグが起きていました。

特定のGoogleMapsサイズ

サイズが特定の場合、再現することはないのですが、
それ以外のサイズではこのバグは発生し、
発生率もそれなりに高いものなのかなと思います。

バグ内容について

埋め込んだグーグルマップで印刷時、横を指定すると帯がでる

埋め込んだグーグルマップで印刷時、横を指定すると帯がでる
Google Maps JavaScript API で埋め込まれた地図を、横方向で印刷しようとすると、ある部分で横に白い帯が出て上下に地図が続かない。
ブラウザで普通に見るのは問題がないが、印刷プレビューで帯が発生し、印刷するとプレビューの通り帯がでる。縦印刷は問題なし。

確かにこれと同じ症状だったのですが、
残念ならがら上記のフォーラムでは私の実装する内容での解決策はありませんでした。

フォーラムでは縦印刷は問題なしとありましたが、
私の場合、縦印刷でも帯・余白のようなものが出ることはありました。

また、teratailでも質問がされていました。
Google mapを印刷する時、地図が欠ける

Google mapを印刷する時、地図が欠ける
地図を印刷して来られる方がいるのですが、地図を印刷する際に地図の一部分が欠ける(グレーになる)と指摘を受けました。
確認してみるとChromeで印刷する時にどうやら発生するようで下数%がグレーになっていました。

GoogleMaps印刷時に出る帯or余白のバグを回避解消する方法

今回、実装する中でバグの調査をしつつ、回避、解消策を模索していました。

一つは、特定のサイズにして対応させることでバグが起きないようにということも考えましたが、
特定サイズの場合、印刷時にページがまたがってしまうなどの問題もあり、根本的な回避、解決にはならないため他の解決策を探りました。

そんな中海外フォーラムで見つけた内容が、私が直面した内容と同一のものでした。
その中で回避策として上がっていたのは、

#map_canvas div > img {
  position: absolute;
}

GoogleMapsAPIを使った地図描画はimg画像を256×256に分割した画像をタイル式に並べて描画しています。
そのimg画像にpositionをつけるというものでした。

この内容でも私が直面した問題は回避はできましたし、

.gm-style div > img {
  position: absolute;
}

という内容でも回避はできました。

Missing tiles when printing Google Maps API v3

コメントではこのようなことも書かれていました。

The position: absolute; workaround is not a reliable solution.
I am displaying a map with a polygon drawn via KML data and the position: absolute; style causes the polygon to be seriously misaligned when you zoom out.
Any alternate workarounds?

google 翻訳

位置：絶対;回避策は信頼できるソリューションではありません。
KMLデータを介して描画されたポリゴンと位置のマップを表示しています：絶対;スタイルを使用すると、ズームアウトしたときにポリゴンが大きくずれます。
別の回避策はありますか？

という一文もあったので、これで完璧に問題ないとは言い切れないかもしれません。

しかし、現状上記の対応によりバグは解消しており、印刷時の不具合を解消することができました。

もし、GoogleMapsAPIで同じようなことに直面してる人がいたら参考にしてみてください。

「おい、ダークモードには対応していないのか？」と、誰かから言われたり言われなかったり。

で、調べてみたらCSSとJSで良さげなのが見つかったので備忘録代わりに

CSS

@media (prefers-color-scheme: light) {
  /* ライトモード用CSS */
}

@media (prefers-color-scheme: dark) {
  /* ダークモード用CSS */
}

CSSの場合、まだ草案段階なので、ダークモードだけ@mediaを使っていくのが良さげ

対応率も良さげ（低いが、ダークモード対応端末だけで見るとよい割合な気がする。）

Can I Use

JavaScript

if(window.matchMedia('(prefers-color-scheme: dark)').matches){
  document.write('ダークモードだよ');
} else if (window.matchMedia('(prefers-color-scheme: light)').matches){
  document.write('違うな');
} else {
  document.write('何者だ？');
}

Can I Use

まとめ

なんか、業界見直したっす