  |
はてなキーワード:htmlとは
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）:Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）:Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml"title="RSS"href="/feed.xml">
<meta property="og:title" content="あなたの名前 |ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home /About /Posts</nav>
<footer>© 2025あなたの名前</footer>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
/* 400 (Regular) */@font-face { font-family: "SiteSans"; /* ページで使う一意の名前 */ font-style:normal; font-weight: 400; font-display:swap;src: /* まず Noto のローカル名を列挙（見つかればそれを優先）*/ local("Noto SansJP"), local("NotoSansJP"), local("Noto Sans"), local("NotoSans"), /* 次にApple のヒラギノ系ローカル名を列挙（Mac/iPhone にあることが多い）*/ local("Hiragino Kaku Gothic ProN"), local("Hiragino Kaku Gothic Pro"), local("ヒラギノ角ゴ ProN"), local("ヒラギノ角ゴ Pro"), /*最後にサーバー上の woff2（フォールバック） */url("/fonts/NotoSansJP-Regular.woff2") format("woff2");}/* 700 (Bold) */@font-face { font-family: "SiteSans"; font-style:normal; font-weight: 700; font-display:swap;src: /* Noto Bold のローカル名 */ local("Noto SansJP Bold"), local("NotoSansJP-Bold"), local("Noto Sans Bold"), local("NotoSans-Bold"), /*ヒラギノ Bold のローカル名（Macに存在する場合）*/ local("Hiragino Kaku Gothic ProN W6"), local("Hiragino Kaku Gothic Pro W6"), local("ヒラギノ角ゴ ProN W6"), local("ヒラギノ角ゴ Pro W6"), /*サーバーフォールバック（woff2） */url("/fonts/NotoSansJP-Bold.woff2") format("woff2");}使用例html,body { font-family: "SiteSans", system-ui, -apple-system, "Hiragino Kaku Gothic ProN", "メイリオ", "Yu Gothic", "YuGothic", "YuGothicUI", "Noto SansJP", sans-serif; font-weight: 400;}ふといならstrong{font-weight: 700;}
→ Noto ローカルで軽くて綺麗
▼ 古いWindows / ほか
→Webフォントで補完。もはや必要あるのか？游ゴだかメイリオでいいのかも
KVはともかく、本文とか見出し、これ良くないですか？
例.
質問：
「firebaseの使い方を知りたいんやけど」
ChatGPT回答：
Firebaseとは、Googleが生み出した「バックエンドいらずの全能実験装置」だ。君がコードを書けば書くほど、知らぬ間にクラウドが裏で息をしている。
データベース、認証、ホスティング、ストレージ、全部詰め合わせ。便利すぎて逆に怖い。
まずはnpm install -g firebase-toolsで召喚だ。
ターミナルでfirebaseloginを叩くと、ブラウザが勝手に開く。そう、Firebaseは君の“人間的アイデンティティ”を確認しないと力を貸してくれない。まるで神のくせに書類主義だ。
ログインが済んだら、firebase initでプロジェクトを構築する。ここが楽しい部分だ。
「Hosting？」「Functions？」「Firestore？」——次々と聞かれるだろう。まるで契約書の小さい文字を全部読み上げてくる悪魔みたいだ。
迷ったらHostingだけ選べばいい。HTMLを置く用の神殿ができる。
あとはfirebase deploy。それだけで、君のHTMLは空に放たれ、URLが授かる。
たとえばhttps://君のプロジェクト名.web.app だ。誰でもアクセスできる。つまり、失敗も世界に晒される。実験とは常にリスクを伴うのだよ、君。
Firebaseの裏には“Realtime Database”や“Cloud Firestore”といった可愛い怪物たちが棲んでいる。彼らはJSONで話す、気難しい連中だが、使いこなせば強い味方になる。データを瞬時に共有し、アプリを“生きている”ように動かす。
ただし、一度でも構成を間違えると——全世界の閲覧者にリアルタイムで恥を晒す。それもまた芸術的だと思わないか？
というわけで、君がやることは四つだけだ。
召喚：npm install -g firebase-tools
構築：firebase init
解放：firebase deploy
君のプロジェクトが光るか燃えるかは、たった一行の設定ファイルにかかっている。ふふ、実にロマンチックだろう？
なんか、最近「実は若者は恋愛離れしてないんですよ〜」みたいな専門家が多くて意味わからないんだけど
参考にしてるのはこれ
https://www.ipss.go.jp/ps-doukou/j/doukou16/JNFS16_Report03.pdf
（27ページ、2.1 異性との交際状況）
「独身者のなかで恋人いない率があまり変わってない」って、そりゃそうだろ、なんなんだこいつら？
| 男性 | 既婚 | 独身 | 独身 |
| 年 | 既婚 | 恋人あり | 恋人なし |
| 1982 | 43.8 | 21.9 | 34.3 |
| 1987 | 39.7 | 22.3 | 38.0 |
| 1992 | 36.2 | 26.3 | 37.5 |
| 1997 | 33.9 | 26.1 | 40.0 |
| 2002 | 31.6 | 25.1 | 43.3 |
| 2005 | 29.3 | 27.1 | 43.6 |
| 2010 | 29.0 | 24.5 | 46.5 |
| 2015 | 26.8 | 21.3 | 51.9 |
| 2021 | 25.4 | 21.1 | 53.5 |
| 女性 | 既婚 | 独身 | 独身 |
| 年 | 既婚 | 恋人あり | 恋人なし |
| 1982 | 63.0 | 23.9 | 13.1 |
| 1987 | 59.1 | 30.8 | 10.1 |
| 1992 | 53.2 | 35.4 | 11.4 |
| 1997 | 48.4 | 35.4 | 16.2 |
| 2002 | 43.8 | 37.1 | 19.1 |
| 2005 | 40.1 | 36.7 | 23.2 |
| 2010 | 38.5 | 34 | 27.5 |
| 2015 | 36.1 | 30.2 | 33.7 |
| 2021 | 34.2 | 27.8 | 38.0 |
明らかに離れている
そりゃそうだろ、騙されんなよ？
独身の恋人いる率は確かにそれほど変わっていないが、そりゃ結婚したら対象外になるからな、「恋愛離れ」に用いるのはおかしい
厳密にはこの数字も、恋愛離れというよりパートナー離れと言ったほうが正しいけどな
| 男性 | 既婚 | 独身 | 独身 | 独身 |
| 年 | 既婚 | 恋人あり | 恋人なし、交際を希望 | 恋人なし、交際を希望しない |
| 2010 | 29.0 | 24.5 | 33.7 | 12.8 |
| 2015 | 26.8 | 21.3 | 36.2 | 15.7 |
| 2021 | 25.4 | 21.1 | 35.6 | 17.9 |
| 女性 | 既婚 | 独身 | 独身 | 独身 |
| 年 | 既婚 | 恋人あり | 恋人なし、交際を希望 | 恋人なし、交際を希望しない |
| 2010 | 38.5 | 34 | 21.3 | 6.2 |
| 2015 | 36.1 | 30.2 | 24.9 | 8.7 |
| 2021 | 34.2 | 27.8 | 25.0 | 12.9 |
若者（18〜34歳）の男性の18％、女性の13％がガチで諦めている
あとグラフにしてみると女性の恋愛離れがとんでもなく急激に伸びてる
＿＿＿＿＿＿＿＿＿＿＿＿
本当はもっと「恋愛離れ」について厳密に調査すると思うんだけどなあ
ちなみに30ページも面白いぞ
2021年時点で、未婚者ｘ恋人ありの出会いの経路、思ったよりネットが少ない
31ページの性交経験も、たまに記事で見かけるんだけど、独身者に限った話だからデータとしてさほど使えない
https://www.ipss.go.jp/ps-doukou/j/doukou16/JNFS16_Report04.pdf
元はこれ
https://www.ipss.go.jp/ps-doukou/j/doukou16/doukou16_gaiyo.asp
2.結婚についての考え方
3.1 異性との交際状況 
5.1結婚時期・適齢期観
5.3 未婚期間・晩婚の志向
7.1 主な発見
7.3 今後の方向性
3.1 完結出生子ども数
3.3.2地域ブロック別
4.2結婚持続期間別・年次推移
5.1 主な傾向と変化点
5.3 今後の課題
＿＿＿＿＿＿＿＿＿＿＿
元データ見たけど「恋人がいると回答した独身者」の割合は載ってるけど、既婚者、恋人いない人の割合はどこにもない。別の調査混ぜて表作ってる？この手の調査で合計が100%になる（未回答者がいない）のは嘘っぽい。
調査年が若干ずれてるのと、人口分布を加味していないので「ざっくりした統計」です
＿＿＿＿＿＿＿＿＿＿＿
お前らほんと数字苦手だよな
未婚・恋人なしが増えているとは言え、結婚する人の方が多いというのが今の世の中だよ
印象で語ってんじゃねーよ
＿＿＿＿＿＿＿＿＿＿＿
おそらくここ10年20年で「結婚しろ、恋人作れ」の圧が減ったというのはあると予想できるよね
これって親世代が変わったからなのかな？今の親って団塊ジュニア世代？もう感覚が現代人なんよ
Permalink |記事への反応(15) | 21:53
上村十勝とはチャットワークでのやりとりをまずやめてください。
彼とやり取りする際は、基本的にやり取りをスクショすること。録音も録っておくこと。
また、対策されるので交渉材料として使うことはしないほうがいいです。
しかし、あえてそれを交渉材料にして、相手から脅し文句を引き出すこともありです。
その際は、全て記録をしてください。
被害に遭ったことをネットに公開すると、本人が下記のような連絡を取ってきます。
このような要旨の発言は特にスクショに加えてhtmlファイルごと落としておくと良いです。
悪質な脅しをしている&反省していない（≒更生の余地がない）証拠にできます。
また、名誉毀損罪というのは「公共性/公益性/真実性」これらがすべて担保されていれば成立しません。
つまり、このように上村十勝からあった被害について、人格否定をせずにどのような被害に遭ったか、どうすれば防げるかを書くこと自体は問題がありません。
彼にされたことを正直に真っ当に公開すること自体は、法に置いても倫理観に照らし合わせても全く問題がありません。
上村十勝はあらゆるログをとにかく消します。最近も自身のnoteを削除しています。そのためWEB魚拓やhtmlファイル、スクショなどすべてを使って記録をしておいてください。
もし法的に戦う予定がある人は、その証拠を持っていますなど言わずに、騙されたふりをし続けたほうがいいです。
また、何か声を上げるにしても最初は証拠を出さず、相手が事実無根だと言った段階で証拠をだし、そのやり取りをすべて保存しましょう。
上村十勝が自身のやったことをやっていないという実績が増えれば増えるほど、やっていることが悪質であることが証明されます。
・脅し文句も何もかもhtmlファイルやスクショなどで記録する
・毅然とした態度をあえて取らず、脅しがエスカレートしたらそれも全て記録する
・チャットワークでの連絡をしない
これを徹底しましょう
ただ、それでもaiに投げるより人が直接操作したほうが早い分野だったり、人がaiのために翻訳しないといけないがそれすらめんどくさいのは残ると思う。
選挙関係のチラシ貼りだとデーターベース用のサーバーを使いたくない事があるにはあってね…
増田の投稿をChatGPTに聞いたら、次のような答えが返ってきたよ。
----------
この投稿はインパクト重視の論調で書かれていますが、内容にはかなりの誇張と誤解が混ざっています。
確かに「Apps in ChatGPT」のような機能は、ユーザー体験の一部を「チャットUI」に統合する可能性を持っています。しかし、それが「フロントエンドエンジニア＝不要」という結論にはなりません。
人間が情報に触れるには、必ず何らかの「インターフェース」が必要です。AIが自動生成しようが、それを心地よく見せ、操作しやすくするための設計原理（アクセシビリティ、情報設計、心理的デザイン）は残ります。AIがHTMLを生成するようになっても、「どのような体験を提供すべきか」を定義するのは依然として人間です。
次に、Apps in ChatGPT＝Webの終焉という見方も現実的ではありません。
これは「一部のユーザー行動の置き換え」にすぎません。人々がすべての行動をチャット上で完結させたいとは限らず、ビジュアル的な体験（ゲーム、ECのUI、SNS、動画編集、ダッシュボード操作など）は、テキストUIよりも視覚的UIの方が圧倒的に優れています。Spotifyの例にしても、ChatGPT上で曲を探すことはできても、音楽体験そのものはSpotifyアプリ内のインターフェースで完結したほうが豊かです。
さらに言えば、「AIがUIを描く」時代は「フロントエンドの再定義」の時代です。
Reactコンポーネントを手書きする仕事は減るかもしれませんが、「AIに指示してUIを生成し、それを調整する」役割は残ります。人がHTMLを書かなくても、ユーザー体験を設計する力・AIが生成したUIを検証する力・アクセシビリティやブランド整合性を担保する力が求められるようになります。
一方で、この投稿が指摘している**「構造を設計できる人の重要性」**は確かに的を射ています。
API設計、データスキーマ、セキュリティ、AIと連携するバックエンド構造への理解はますます価値を増します。UIの自動生成が進むほど、裏側の整合性・信頼性を支えるエンジニアリングが中心的になるのは確かです。
要するに、フロントエンドは「消滅」ではなく「変質」していく段階に入っています。コードを書く職種から、AIを使って体験を設計・制御する職種に移行していくというのが、現実的な見立てです。
この一言に尽きる。
ChatGPTの新機能「Apps in ChatGPT」が登場した瞬間、フロントエンドという職種の地盤は音を立てて崩れた。
これまでは、Webアプリやサービスは「フロントエンドでUIを作り、バックエンドでデータを返す」
という分業構造の上に成り立っていた。
だがApps in ChatGPTは、その構造をぶち壊す。
ChatGPTのチャット画面内でSpotifyを操作し、Zillowで物件を探しEtsyで買い物をする。
あなたが書いてきたReactコンポーネントもボタンもフォームもすべてAIに吸収される。
もはやユーザーはブラウザを必要としない。URLをコピペすることも無くなるだろう。
「このホテル予約して」と言うだけでAIがAPIを呼び、レスポンスをカルーセル形式で提示する。
ReactもNext.jsも「人間が画面を操作する前提」で存在していた。
でもその前提はもう終わった。
AIがデータを直接受け取り、AI自身が人間に見せるUIを自動生成する。
あなたが設計した美しいフォームもAIにとってはただの "action": "submit" という構造情報にすぎない。
Apps in ChatGPT以降の世界では、
これらが新しいUIだ。
だからこれから必要なのは「見た目を作る人」ではなく、AIが読み取れる形式で世界を記述できる人 だ。
バックエンドに戻れ。
Apps in ChatGPTが意味するのは、
今後必要なのは、AIが扱いやすいデータスキーマを定義する力や認証・権限・トランザクションを安全に扱う力やMCPやWebAPIをAIが使いやすい形に整える力だ。
これは警告だ。猶予は短い。
Apps in ChatGPTの登場は、「AIがUIを直接扱い始めた」という歴史的転換点だ。
あなたがフロントにしがみつく間に、AIはすでにあなたの代わりにUIを描いている。
5年後にはブラウザから色んなサイトにアクセスするという行為は一部のマニアだけ行うものになっているだろう。
もう時間はないぞ。急げ
Permalink |記事への反応(17) | 09:37
昔はスタイルを自由にいじれたのでfont–sizeを0にしたり文字色を白や透明にすることで増田で隠し文字を使うことができた
しかし現在では自由な文字サイズや色を設定できず、一部のクラスを当てるかbig/small等のHTMLタグのみ使えるよう制限されてしまった
しかし重ねても徐々にしか小さくならないので0を目指すにはかなりの数のsmallタグが必要になる
あ１
あ２
あ３
あ４
あ５
あ６
あ７
あ８
あ９
あ１０
あ１１
あ１２
あ１３
あ１４
あ１５
あ１６
あ１７
あ１８
あ１９
あ２０
２０までいくと、font–sizeは計算上0.378pxになるが、最近のブラウザは小数点以下であっても表示するので0にはならない
「田舎に住む男」というだけで誰かに迷惑をかけていて、自分を責める気分になる。
ttps://b.hatena.ne.jp/entry/s/www3.nhk.or.jp/news/html/20250924/k10014930201000.html
という言葉を見ると、地方で生きててすみませんね、都会に出た方がいいんですかと卑屈になる。
人口3万人以下の田舎に住む当事者として、一度滅んだほうが良いというのもわかるし、かといって滅んだ後に良くなるとも思えない。
滅ぶというのは過去の膿のような慣習それらを支持する人たちが消えることだと思うが、その人たちも悪意があってやっているわけではなく、自分と同じで何かのしがらみにとらわれているんだろう。
「死すべき」と一蹴せずに、良い方向へ一緒に頑張っていくしかない。
誰かが消えれば解決するようなわかりやすい敵は残念ながらいない。
今はまだ高齢ではないが、田舎の高齢の男となったら生きている価値が無くなるんだろうなと残酷な気分になる。それでも生きていくしかないな。
いちおう、「最初の投稿では過去増田のテキストだけのコピペだけど、しばらくしてから不可視URLリンクを入れたり、また抜いたりする」という怪しい挙動の増田は何度か見たことあるけど、そのたぐいかな？(数としてはあまり見かけないけど、URLを抜かれたら確認もできなくなるので、実はたくさんあるのかもしれない)
たとえばこんな感じで画面の中に表示させることはできるで
html::after{ content: attr(data-entry-created); position:absolute; bottom: 0; left: 0;}
そこはなんか一時的にごっちゃになった
pythonのself.driver.get()とかでやるのがhtmlリクエスト
(でもたぶんhtmlリクエストって言葉自体ないってのが正解だろう)
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250910132103# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaMD8swAKCRBwMdsubs4+SBgDAQDsUXXO1zHRyA8Ss7PNZ1bhSv/7cuDt1Wc3EsD5wxgYhAD8Dg5Xp3KpkUOuQWUsXZJ6I9NbDrE24AkrHYnqTGfosA8==s2RT-----ENDPGP SIGNATURE-----
じゃあそのhtmlリクエストが受け付けられる条件として必須のrksトークンはどっから持って来るの？
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250910131333# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaMD68wAKCRBwMdsubs4+SLd9AQDDHnmGVamhwDWl7kG501VGcET3rlXyisSKDwLfMLzjPQEA6I0kZD8xeVnsXCuIoCWQ8Kjg6F/PxdtZXYOch6tOVQI==eWFy-----ENDPGP SIGNATURE-----
具体的なhtmlデータ取得してその要素をクリックする自動化を書くみたいにイベント経由で関数叩くんじゃ高速にならないだろ。
だから直接関数を叩きたいてrksトークン取得してそれを含めたデータをfetchで送ってブクマするってことをしたいがその関数がなんて名前なのか特定できない。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250910130926# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaMD5/gAKCRBwMdsubs4+SCjzAQCKUj2QzgY09jHZgTOPETAiwDuN17mRQlbl6GRekSHlkAEA7c+gCJtJFPza5GmYIFYerYlsmSFHd9dMIV8cR+RnYAY==IyFO-----ENDPGP SIGNATURE-----
