lazyloadの独自属性対策

981 名前:名無しさん@お腹いっぱい。 投稿日:2020/11/24(火) 23:16:18.76 ID:SKoR9FCR0
2ページ目以降の画像の遅延読み込み (Lazy Load) の対策を、GreasyFork で公開しました。
https://greasyfork.org/ja/scripts/416710-autopagerize-lazy-load-assistant

982 名前:名無しさん@お腹いっぱい。 投稿日:2020/11/24(火) 23:58:48.54 ID:KxrmkJAv0
>>981
いいね完璧

983 名前:名無しさん@お腹いっぱい。 投稿日:2020/11/25(水) 01:43:44.25 ID:LlMgWYNX0
ImpressのWatchajaxプロパティ使ってるんだよなぁ
Watchはよく見るから自前スクリプトでは対応させてるんだけどajaxだからもちろんdatasetには無い
まあでも汎用的なプロパティ名じゃ無いわな……

984 名前:名無しさん@お腹いっぱい。 投稿日:2020/11/25(水) 04:18:17.98 ID:1F06LSlV0
const DATASETS = [
'src',
'lazySrc',
'original',
];
img.src = img.dataset[name];
srcがいらなくない?
img.src=img.srcしてるような
俺のはブックマだが他のが入ってる
["data-src", "data-lazy-src", "data-original", "ajax", "data-layzr", "data-gifffer"]

985 名前:名無しさん@お腹いっぱい。 投稿日:2020/11/25(水) 08:45:31.91 ID:Pm0TDhB80
>>983
うわーまじかぁ 自分もWatchたまに見るけど独自属性には付き合ってらんないな・・・
html埋め込みスクリプトで↓こんなことやってんね

$('.main-contents img[ajax]').each(function(){
$(this).attr('src', $(this).attr('ajax'));
$(this).removeAttr('ajax');
});

>>984
DATASETS で定義してるのはいずれも dataset 以下の項目なので、
src は実際には img.src じゃなくて img.dataset.src を探ってます。
例: https://toyokeizai.net/articles/-/362124

AutoPagerize質問・要望スレ page:5

一応data-imgとかdata-delayとかもありますよ。とはいえほどほどでいいと思います。
wedata.net
wedata.net

Tumblrのsiteinfo編集について その3


uAutoPagerizeの更新を確認しました。ここまで書いてきたTumblrのsiteinfoとお別れです。

ダミーコードに関してはダミー1、ダミー2、そして個別サイトごとのsiteinfoを全て削除しました。exampleUrlで動作が抑制されています。

汎用型のarticleも削除しました。残すと影響が大きいと考えられるためです。

本丸の681に関しては動作を限定しました。
wedata.net
これでもまだ問題が起きるかもしれませんが、その都度対応します。

postに関しては悩みましたが、ひとまず残します。これも問題を確認次第対応します。
wedata.net
ここまでの変更を踏まえsiteinfoを再度表にしておきます

番号 名称 呼称 種別
681 Tumblr メイン 汎用
31114 Tumblr - hAtom hAtom 汎用
31158 Tumblr - AutoPagerizeFORMAT APE、APF 汎用
63728 Tumblr - masonry masonry 汎用
85560 Tumblr - post post 汎用
85562 Tumblr - newDay newDay 集積
85564 Tumblr - content content 集積

pageElement

Tumblr

descendant::*[count(.//*[@class="permalink"][not(self::a)])>=4][last()]/*

Tumblr - hAtom

//*[contains(concat(' ', @class, ' '), ' hentry ')]

Tumblr - AutoPagerizeFORMAT

//*[contains(concat(' ',@class,' '), ' autopagerize_page_element ')]

Tumblr - masonry

id("blog wrap")[./*[starts-with(@id,"1")]]

Tumblr - post

(//div[@class="post"]|//div[@class="post"]/following-sibling::div[@class="date" or @class="bottom"]|//div[@class="post"]/preceding-sibling::div[@class="date" or @class="bottom"])[count(//*[./div[@class="post"]])=1][count(//div[@class="post"])>2][//div[@class="post"]/following-sibling::*[1][@class="post" or @class="bottom"]]

Tumblr - newDay

descendant::div[@id="newDay"][1]|descendant::div[@id="newDay"][1]/following-sibling::div[@id="newDay"]

Tumblr - content

id("content")

Tumblrのsiteinfo編集について その2

wedataのsiteinfoが適用される優先順位は、URLの長さで決まります。他のsiteinfoよりURLが長ければ優先され適用される仕組みです。既存のTumblrで汎用的に適用されるsiteinfoはこの点をよく考慮されています。

Tumblr(681)

^.+://[^/]+\.tumblr\.com/

Tumblr - hAtom(31114)

^.+://[^/]+\.tumblr\.com/.*

Tumblr - AutoPagerizeFORMAT(31158)

^.+://[^/]+\.tumblr\.com/.*.*

Tumblr - masonry(63728)

^https?://[^/]+\.tumblr\.com/*

下から順にURLが長い分だけ優先して適用されます。しかし私案は汎用的に適用したい場合は、Tumblr - masonryからコピペしたURLを使います。どれを優先させるか考えるのが面倒だからです。

Tumblrのsiteinfo編集について

これまでに関わった複数のURLが適用されるsiteinfoを表にしておきます。

番号 名称 呼称 種別
681 Tumblr メイン 汎用
31114 Tumblr - hAtom hAtom 汎用
31158 Tumblr - AutoPagerizeFORMAT APE、APF 汎用
63728 Tumblr - masonry masonry 汎用
85560 Tumblr - post post 汎用
85573 Tumblr - article article 汎用
85562 Tumblr - newDay newDay 集積
85564 Tumblr - content content 集積
85563 Tumblr -Dummy for uAutopagerize ダミー1 集積
85566 Tumblr -Dummy for uAutopagerize2 ダミー2、ダミーラスト 集積

pageElement

Tumblr

(id("posts")[count(//*[@id="posts"])=1]|//*[@class="main" or @role="main"][not(self::main)][not(id("posts"))])[not(@style)][not(.//article[@style])][not(.//*[contains(@class,"masonry")])][not(id("sidebar-nav"))]

Tumblr - hAtom

//*[contains(concat(' ', @class, ' '), ' hentry ')]

Tumblr - AutoPagerizeFORMAT

//*[contains(concat(' ',@class,' '), ' autopagerize_page_element ')]

Tumblr - masonry

id("blog wrap")[./*[starts-with(@id,"1")]]

Tumblr - post

(//div[@class="post"]|//div[@class="post"]/following-sibling::div[@class="date" or @class="bottom"]|//div[@class="post"]/preceding-sibling::div[@class="date" or @class="bottom"])[count(//*[./div[@class="post"]])=1][count(//div[@class="post"])>2][//div[@class="post"]/following-sibling::*[1][@class="post" or @class="bottom"]]

Tumblr - article

//article[not(contains(@class,"loaded"))][count(//*[./article[./following-sibling::article]])=1]

Tumblr - newDay

descendant::div[@id="newDay"][1]|descendant::div[@id="newDay"][1]/following-sibling::div[@id="newDay"]

Tumblr - content

id("content")

Tumblr -Dummy for uAutopagerize

descendant::*[@style="display: none;"][1]

Tumblr -Dummy for uAutopagerize2

descendant::*[@style="display: none;"][last()]

uAutoPagerize ver 0.1.7の仕様変更について その2

Grieverさんからのコメントにお答えします。

私の使いたい XPath と多野さん(?)が作り上げてきた XPath が大きく違い編集しづらいこと、pageElement の取得・継ぎ足し時に JavaScript でチェックと補正を掛けたいのが大きな理由です。


動作サイトについては死ぬほどテストしたので減ってはいないと思います。

uAutoPagerize ver 0.1.7の仕様変更について - 1300

コメントありがとうございます。もちろんGrieverさんが優秀な技術者なのは認めますが、JavaScript自体が使えるとしても誤動作に気を使いながら400や649を無効にしてこれまでと同様の動作サイト数を維持するのは難しいはずです。すごい気迫ですね。

これまでと何がどう違うのかを確認したいのですが、日頃の行いが悪いのか独自設定が機能しているサイトがほとんど確認できません。MY_SITEINFO無しで以下全てのサイトが機能していません。

wedata URL
400_a https://www.newyorker.com/magazine/food-and-drink
400_b https://gadget-shot.com/
400_c https://www.jinnsblog.com/
400_d http://bash.org.pl/latest/
400_e http://octech.jp/modules/wordpress/
649 https://blog.nicovideo.jp/3d/2014/06/pmx.html
650 http://majikichi.com/
85437 https://oiio.jp/

Grieverさんのコメントを読む限り、これらのサイトを切り捨てているとは思えません。私が何かを見落としているはずです。

追記


無事アップデートで上記サイトが機能しています。素早く対応していただき助かりました。

uAutoPagerize ver 0.1.7の仕様変更について

Build-in SITEINFO
誤作動の多い items/400 と items/649 を無効化して独自の汎用サイト設定を組み込んだ。
正確には items/80660, items/430, items/401 以外の https://www.example.com/ にマッチする SITEINFO を無効にした

400や649といった汎用のsiteinfoは無効化され、独自の設定だけで動作するようです。

これまでより動作するサイトが限定されるのが不満な方はMY_SITEINFOに400や649からコピペして設定されるのをお勧めします。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
アイテム: hAtom - データベース: AutoPagerize - wedata

参考までに私の設定を置いておきます。
http://plsk.net/uap_set_general

一つ心配していることがあります。Grieverさんがこの仕様変更に踏み切った理由は、wedataのsiteinfoに不満があるからと考えるのが自然です。おそらくその原因の一つは400への私の対応でしょう。

もしこれまでより独自設定で動作するサイトが減れば、uAutoPagerizeユーザーにとっては動作する範囲が狭くなって手間が増えたと責められるのではないでしょうか。我ながら小物の発想ですね。

幸いにして今のところそういった動きはありません。uAutoPagerizeユーザーはGrieverさんに似て理性的な方ばかりでよかったなと思います。

400や650が採用されないのは悲しいですが致し方ありません。コーダーは感情に流されてはなりません。その瞬間瞬間でベストを尽くすしかありません。

wedata:400でcount()を使用した意図 その5

このシリーズはひとまずこれで終わりにしたいと思っています。
codepen.io
昨日やり残していたEntry + subとEntry 非 article + subですが、対応が難しいです。メイン側とサイドバー側をXPathで汎用的に見きわめる方法がないからですね。

多野さんの意図を自分なりに書くという当初の目的は現状で十分に果たされていますので、今後の課題として残しておきます。

自分でコードを書くのにこだわらず、もっと早い段階で多野さんやGrieverさんのコードを受け入れていればそう苦労しなかったはずです。wedataコーダーの皆さんには、ご迷惑をおかけしました。私が狭量と言ってしまえばそれまでですが保守の手間を考えればそう悪くないのかなとも感じています。

最初にexampleUrlを整理していたのがまさかA or B - A and Bの発想で活かせるとは思っていませんでした。幸運に恵まれた結果です。

Grieverさんのおかげで、XPathと向かい合う時間を作れました。コードにどういう意図があるのかを明確に伝えるのが大事だとよくわかりました。厳しい目を持ってコーディングと向き合わねばならないと教えられた気がします。ありがとうございます。

最後にこれから挑戦される方のために、メイン(メインエントリ側)とサブ(サイドバー側)に適用される数でそれぞれ現状と理想の動作を表にしておきます。n>1です。

メイン サブ 現状 理想
0 1 機能しない 機能しない
0 n サブ側で機能する 機能しない
1 0 機能しない 機能しない
1 1 機能しない 機能しない
1 n サブ側で機能する 機能しない
n 0 メイン側で機能する メイン側で機能する
n 1 メイン側で機能する メイン側で機能する
n n 機能しない メイン側で機能する