@hashi_nazumi 色々買っちゃったけど今度触ってみます
言葉と文字とヨッシーアイランドが好き。たまごっちやここたまのアニメを見ます。たまに絵を描きます。フォントを作ったりします。2023 年 1 月から https://mofu.kemo.no の副管理人です(いきなり権限を付与されたけど受け入れました)。
ソーシャルメディアの中では ここが常駐場所です。大体全ての活動をここに集約します。ActivityPub 対応サーバーからリモートフォローしてください。なおフォロー外からの非公開返信は受け取らない設定にしてます。
日本語の研究で博士号を持ってるけど、離れて長いし、自信ない。キーボードは新 JIS‐配列(JIS X 6004)微改変版です。今のプロフィール画像は『スーパーマリオブラザーズワンダー』の一般ポプリンの絵です(二次創作)。
全ての #絵 を見るにはこちら :
https://mofu.kemo.no/@sayunu/tagged/%E7%B5%B5
ここたまに興味がある人は、ここたまアンテナ(@cocotama_antenna)をフォローしてね。
@tizerm 顔は、ペン入れして色を塗ると印象が変わっちゃうので下絵の癖を壊さないようにしてみたというのが大きいかも知れません。
「body:has(…)」の影響で重くなってるなあ。心配してはいたので案の定だけど、多カラムでは軽くて単カラムでは重いのが不思議。
性能に悪影響が出てる以上、単カラムでの検索欄コマンドを無効化するのも やぶさかでないけど、単カラムが駄目で多カラムが快適な理屈が分からない。Chromium に固有の最適化戦略のせいとかではなく、一般的にそうなりそうだと言えればいいんだけど。
「body:has(…)」は単純に考えれば body‐内の文書構造に「何らかの変更」がある度に再計算を要するので、どっちかと言うと「なぜ重いか」より「なぜ軽いか」の方が謎。どうやって余計な計算を省けばいいかが自明ではない。なぜ、少なくとも Google Chrome では多カラムの場合に最適化が噛み合うのか。
ウエブページ筆者としては、主カラムの中身だけが書き替わる度に再計算が発生するのを回避できる事を願って、has の中では検索欄のカラムを名指ししてる。
Mastodon のウエブ画面で、外部リンクを含む投稿に表示されるカードは情報の取得をわざと少し遅延している…という話は前提として、サーバーが情報を取得したのにそれが閲覧者の画面に即座に反映されないという不便がある。これは一旦ブックマークを付けて外すという操作で再読み込みできるみたい。
Mastodon v4.2.10 で、外部リンクのカードの画像がカラム幅全体を占有して大きく表示されるか、小さく表示されるかを決める条件はよく分からない。(さっきから検索して調べてる。)
しょうがないのでソースを見ると、「画像が横長の時」かしら。
@admtan 今の Mofu UI だと、画像と説明が左右に並ぶような投稿も詳細表示では縦に配置するように上書きしてます(あまり美しくないけど…行長が短くなり過ぎる場合があったので)。通常の Mastodon では横に並んでる物と思ってください。