Element.scrollIntoView() with options
「だいたいあの辺に飛べば良いや」というときに便利な scrollIntoView() メソッド。
呼び方は三通り。
element.scrollIntoView(); element.scrollIntoView(alignToTop); // Boolean parameter element.scrollIntoView(scrollIntoViewOptions); // Object parameter
そのうち、三番目の記法の話。
MDN は、こうある。
https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView
こ、これだけ?
リファレンスを見に来るような人は、その選択肢の挙動が知りたいんだろうに。
以下、それぞれの属性の取りうる値(リファレンスのまま)と、その挙動。
選択肢で、気持ち赤くしてあるのがデフォルト値。
behavior
スクロールするときの動作の指定。
- smooth
- 滑らかにアニメーションしてスクロールする
- instant
- アニメーションせずに、ぱちっとジャンプする
- auto
- マウスやキーの操作でスクロールしたときの動作と同じ動きをする
auto
に影響を与えるのは、ブラウザの設定と、css の scroll-behavior 。
「ブラウザの設定」は、Firefox だと、about:config の general.smoothScroll
。
true でアニメーション、false でいきなりジャンプ。
その挙動を要素ごとに変更できるのが、css の scroll-behavior 。
general.smoothScroll
が false になっていても、scroll-behavior
が smooth
になっている要素のスクロールはぬるっと動く。
block
指定した要素がどの位置に見えるようにスクロールするかの指定(縦方向)。
- start
- 要素がウィンドウの上端に来るように移動する
- center
- 要素がウィンドウの中央に来るように移動する
- end
- 要素がウィンドウの下端に来るように移動する
- nearest
- 要素がウィンドウの中に入るように、最小限の移動距離で移動する
nearest
が指定されたときは、対象の要素が
現在位置よりも下にある場合:要素がウィンドウの下に来るように、
現在位置よりも上にある場合:要素がウィンドウの上に来るように、
移動する。
更に、もし、対象の要素がウィンドウ内に一部でも見えているとスクロールしない。
その他の start
、center
、end
の場合には、要素が見えていても指定された位置になるようにスクロールされる。
start
の残念なところは、よくウィンドウの上に配置されている position: fixed
の下に潜り込んじゃうところ。
キーでのスクロールの場合には、position: fixed
のサイズを除外してスクロールしてくれるのに(Firefox の場合。他は知らん)。
inline
指定した要素がどの位置に見えるようにスクロールするかの指定(横方向)。
- start
- 要素がウィンドウの左端に来るように移動する
- center
- 要素がウィンドウの中央に来るように移動する
- end
- 要素がウィンドウの右端に来るように移動する
- nearest
- 要素がウィンドウの中に入るように、最小限の移動距離で移動する
縦方向の block
と考え方は同じ。
横方向のスクロールがあるページは見づらいので、最近はほとんど見ないので、デフォルトの nearest
を変更しなければいけないことは、まずないんじゃないかと。
block
と inline
は分かりにくい。
vertical
と horizontal
じゃダメだったんだろうか。
(おしまい)
ページの途中に表示するメッセージ
この質問の件。
「どんな方法でもいいので」ということなので、元のコードを修正するのではなく、動くコードを提示してみる。
↓にメッセージ。
パラメータは、質問に合わせて key で、値は大阪と広島。
お試しのリンク。
- http://a-kuma3.hatenablog.com/entry/answer_of_1536391733?key=大阪
- http://a-kuma3.hatenablog.com/entry/answer_of_1536391733?key=広島
- http://a-kuma3.hatenablog.com/entry/answer_of_1536391733?key=東京タワー
- http://a-kuma3.hatenablog.com/entry/answer_of_1536391733?key=札幌
こんな感じのコード。
(function() { var m = /\bkey=(.*?)(&|$)/.exec(location.search); if (m) { var msg = "", img_src; switch (decodeURIComponent(m[1])) { case "大阪": msg = "大阪でっせ"; img_src = "http://www.pref.osaka.lg.jp/houbun/reiki/reiki_honbun/word/k201IG00000410.jpg"; break; case "広島": msg = "広島じゃけえ"; img_src = "https://www.pref.hiroshima.lg.jp/soshiki_file/kouhou/kids/kids02-01.jpg"; break; } if (msg != "") { document.write('<p class="message-by-key">' + '<img src="http://q.hatena.ne.jp/images/icon-jinriki-og3.gif">' + '<img src="' + img_src + '">' + msg + "</p>"); } })();
今どきのコードだと、こんな感じ?
(_ => {
const message = {
"大阪" : "大阪でっせ",
"広島" : "広島じゃけえ",
};
const url = new URL(location.href);
const param = url.searchParams;
if (param.has("key")) {
const key = param.get("key");
if (message[key]) {
const c_ = document.currentScript;
c_.parentNode.insertBefore(Object.assign(document.createElement("p"), {
innerHTML: message[key],
className: "message-by-key",
}), c_.nextSibling);
}
}
})();
Internet Explorer だと、この辺りがダメ。
- Arrow functions - JavaScript | MDN
- URL() - Web APIs | MDN
- URLSearchParams - Web APIs | MDN
- Document.currentScript - Web APIs | MDN
- Object.assign() - JavaScript | MDN
もうひとつ質問きた。
エリア1
エリア2
エリア3
エリア4
エリア5
Google の検索順位判定ロジックに変更が施されたかもとか、そんなこと
「突然奈落の底へ落ちる【Google大変動2018年8月】何も言えなくて…夏」の件。
ブログでの広告収入なんて興味ないので、書きたいことを書き散らかしてるだけのブログをいくつか持ってる。
年に数回くらいしか開かない Search Console を見てみた。
その中でも書き込み量が、まあまああるふたつの流入の様子。
グラフの右側 くらいが 2018年8月の分。
はてなブログの方は、人力検索がつまらなくなったこともあって、無駄に長い投稿が最近 増えてきたかなあという気はする程度で、真面目に更新してるとは言えない。
FC2の方は、ほんとに倉庫というレベルで、一ヶ月放置すると出てくる広告を消す程度にしか更新してない。
確かに、2018年8月に入ってから、検索順位の判定に何か変わったのかも、という気がしなくもない程度にはうっすらと傾向が変わってる。
何かしらの判定が厳しくなったのかしらということを想像してるらしいけれど、はてなブログの方は、(ほんのりだけど)むしろ増えてるので、一律に厳しくなったのではないような気もする。
2018年8月は、どちらのブログにも記事を投稿してないから、過去記事のクロール結果、もしくは、クロール済みの結果の判定に何かあったのかも。
広告収入を期待してる人は大変だね :-p
# 一般論にするには、PV 少なすぎるな(ケラケラ