トミー @SaekiTominaga@fedibird.com

これは盲点だったな。
代替テキストの活用例

- ブラウザの設定で画像表示をオフにしたとき
- 電波的な問題などで画像ロードに失敗したとき（実際は代替テキストは表示されないが、本来は表示して欲しい）
- スクリーリンリーダーで読み上げるとき
- 年齢や趣向的な理由でセンシティブ画像やグロ画像が表示されないとき ← New!

Blueskyの開発者に「鍵アカウントの実装予定は？」「日本支社の設立予定は？」など何でも聞けるイベントが開催されたので行ってみたら開発者の「やることリスト」に追加されるアイデアが続々飛び出す充実のイベントでした - GIGAZINE https://gigazine.net/news/20240414-bluesky-meetup-osaka/

「これは私のXでの経験なのですが、スレッド内の投稿に性的な画像が含まれた場合……画像の非表示の代わりに代替テキストを表示するような機能は実装できないでしょうか。」
センシティブ画像をブロックする代わりに代替テキストを表示するアイデアか。

今日も Markuplint の `heading-levels` ルールに救われました

Zenn の「リンクカード」をJavaScript 無効環境で閲覧するとこうなること、Zenn ユーザーは分かって使っているのかしら

最近はJavaScriptをデフォルト無効化してブラウジングしてる https://zenn.dev/oubakiou/articles/2d1b2931116847

デフォルトでスクリプト無効にしている人ですら、Zenn の「リンクカード」機能を使ってしまうのか。
Zenn のリンクカードはスクリプト無効環境では動作しないので、リンク先に飛べない……というかそこにリンクが存在することすら分からないのですよ。

とはいえ <time> で認められている機械可読形式は広すぎて、実際あれを機械可読として活用している実例はあるのかしらって話

リンクは <a href> に対して、href なしの単なる <a> が認められているように、<time> 要素も“不明な日時”を表現できたらいいのに。

<dl>
<dt>生まれる <dd><time datetime="19xx-xx-xx">19xx年xx月xx日</time>
<dt>初めて歩く <dd><span>19xx年前後</span>
</dl>

のように、正確な日時と不正確な日時が混在している場合に <time> と <span> で要素を分けないといけないのが気持ち悪い。
とはいえ <time> は機械可読性が重要な要素だろうから、<time unknown> とか導入するのもなんか違う気がするしやむを得ないのかな。

overflow の倫理プロパティ、Firefox しか対応していないのか。
overscroll-behavior は全ブラウザ対応済みなのになあ。

2024年が令和何年か覚えていないけれど、昭和以前は逆に西暦で言われても時代感がピンと来ない（個人の感覚です）

それを踏まえると
<time datetime="2000">2024<small>(令和6)</small>年</time>
は良さそうだが（HTML 仕様でいう side comments を意図しているので）、
<time datetime="1927">1927<small>(昭和2)</small>年</time>
はむしろ和暦がメインなので不適切に思える。マークアップむずい

つくった

西暦データから和暦を取得 https://github.com/SaekiTominaga/npm/tree/main/packages/wareki

getDate() のつもりで getDay() と書いてハマるの人生で何億回目だよ

Web が後方互換性を重視しているのは重々承知のうえで、それでも Date() の各メソッド名だけは許せない

new Intl.DateTimeFormat('ja-JP-u-ca-japanese', { year: 'numeric' }).format(new Date('1868-09-07')); // 慶応4年
new Intl.DateTimeFormat('ja-JP-u-ca-japanese', { year: 'numeric' }).format(new Date('1868-09-08')); // 明治元年

明治元年の最初の日は1868年10月23日のはずだけれど、旧暦の関係でこうなるのかな。
ていうか明治より前にも対応していたのね

コピペミスで new Date(new Date(input)) と二重にしてしまっていたけれど、これ型エラーにならないし、ESLint でも警告されないので、偶然目視で見つけていなければ一生気付かないやつでは

JS で和暦を扱う場合、今どきは Intl.DateTimeFormat とかあるけれど、Date オブジェクトで表すことのできない不正確な値はライブラリー使うしかないよなあ。
1989-02 を平成元年に変換したい（1989-01 は変換できなくて良い）。
で、そういうライブラリーが見つからないという。

HTML仕様では「Abbreviations do not have to be marked up using this element」とある一方で、スタイル付けの効用から title 属性なしで使っても良いとされている。
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-abbr-element

Emmet で <abbr> 要素を書こうとすると自動的に title 属性が設定されるけれど、<abbr> は決してフルスペルの提示に使うものではなく、省略表記であることを明示するために title 属性なしで使っても良いはず。
表の中とかで文字数削減のために固有名詞を省略するが、欄外で補足するか、補足せずとも自明な場合とか。

でも Emmet がわざわざこういったことをしてくるのは、title ありの使い方がされることの方が多いということだろうか。
https://github.com/emmetio/emmet/blob/54006706e42a6561317022e3f4ad13d9593e5f45/src/snippets/html.json#L7

特定のケース（広い画面を目で見ている場合）のみ省略した方が利便性が高いと判断されているのだろうけれど、その判断をするのは制作側でなくユーザー側よ。
Web においてはユーザーの方が偉いの。制作者スタイルシートよりユーザースタイルシートの指定が優先されるでしょ。
あなた（制作者）は判断できる立場じゃないの。越権行為よ。
って思っちゃう。

Mastodon は投稿の URL をコピーすると非表示のスキームや末尾の ellipsis された部分までコピーされる。
コピー先でもリンクとして有効になるから便利に感じているだけれど、いわゆる Visually Hidden の考え方は好きくない。コピペ対応にしろ、スクリーンリーダー対策にしろ、なら最初から表示して欲しい。
SNS は Web といってもほぼアプリ的な存在だからまー許容範囲か……。

ブログ書いた。

目黒蒲田電鉄、東京横浜電鉄モハ510形の制御装置の内訳
https://blog.w0s.jp/707

モハ510形の制御装置は当初3タイプがありましたが、搭載車両の対照データは文献により異なります。「鉄道省文書」と「日立評論」、および当時の研究発表資料から推測してみました。