Back

・ 表示領域が広い場合の画面構成で、記入欄が狭いのは短所。
・ 狭い場合の画面構成で、記入欄を開くとタイムラインが読めなくなるのは短所。
・ 広い場合の画面構成で、投稿を記入しながらタイムラインを自由に切り替えて閲覧できるのはツイッターにない長所。 #Mastodon

ボタンをクリックしようとするとフォーカス対象が変わってニュルッと逃げる場合がある。これはしょうがないかなあ。

投稿欄の体裁を改造すると、使えないほど壊れた閲覧環境からはそれを報告してもらえないので怖い。

・ 記入欄の中に文字が書き込まれた状態でフォーカスが変わった時、縦幅が半端になる現象に対策しました。恐らくスクリプトで再計算されていて、CSS transition の影響を受けると遷移中の行数が使われてしまうみたい。外枠の横幅に transition を適用しつつ、入力欄自体の幅は transition なしで改めて指定するようにしたら直った。

・ 記入欄の下に現れるハッシュタグなどの候補メニューが途中で切り落とされないように修正しました。

予告 : 今から「フォーカスが当たってる時」ではなく「マウスカーソルが乗ってる時」という条件に変更してみます。

漢字変換候補がカーソルの直下に現れると遮られて幅が変わってしまう…。これはこれで厳しい。

「フォーカスが当たってる時」と「カーソルが乗ってる時」の両方を有効にしてみました。それと、投稿ボタンが多少逃げても押せるように、ボタンを巨大化してみました。

業務中なので細かい検討はまた今夜以降に。

#CSS の「:has()」を使えばもっとうまく挙動を制御できるだろうけど、新し過ぎるから使いたくないの…というか私自身の環境が古いから動作確認できないの。「:focus-within」だと条件が大雑把。

でも「pointer-events: none」の使用を前提にするなら工夫できる気がする。（重なって押せなくなる心配がないので、右へ広がる分の領域を予め取っておける。）この属性が主要ブラウザーに対応されたのは、最も遅い Edge で 2015 年か。意外と古かった。

というか改めて考えたら、この部分は重ね順が後ろになってるから どっちにしても問題ないかも ? ブツブツ。 #CSS

マウスカーソルの位置ではなくフォーカスによって記入欄の幅を固定している時、枠の色が変わって見分けられるようにしました。それと、投稿の公開範囲についての注釈が今まで薄い赤だったけど、ほかの箇所で使ってる黄色に統一しました。 #mofu_kemo_no #Mastodon

投稿記入欄の挙動を少し変更しました。複雑な話になるけど…単一カラム構成で表示領域の横幅がそこそこ広い時（主カラムの左右に副カラムが表示され、その左右に余白が残っていない時）、今までは左下の余白にマウスカーソルを置いたら記入欄の横幅を拡張するようにしていましたが、読む邪魔になるという意見も尤〔もっと〕もなので変更しました。以前の挙動に戻した事になるのかな。詳細は忘れちゃった。記入欄のフォームそのものにカーソルを重ねた時だけ横幅が拡張されます。