このアカウントは、notestockで公開設定になっていません。

知識の面でみたらたしかにだけど、知らんかった人と仲良くなったりとかはけっこうある

あと、情報が増えたというか、インターネットでしか拾えないニッチ情報はたしかにあった。

terminfo でカーソルとか描画制御しようとするの難しすぎるな...

tputとかで頑張って端末上にUIらしきものを構築しようと試みているけど、Webはめちゃくちゃ楽だわ。やっぱりDOMは自動化されたレイアウトの仕組みなんだよな。

terminfoから端末の絶対座標への移動や書き込みはできるけど、ただの絶対座標情報しかなくて構造性なんてないから、自分で情報管理区画を整理しないといけない。それに対してDOMのレイアウトしやすさというのは、画面の矩形を入れ子状に反復することができるということに尽きる。簡単に画面を分割することができる。

DOMってコンテンツのセマンティクスがどうこう以前に、そういう矩形操作技術として受け入れられたのは明らかで、だからテーブルレイアウトがあったしいまでもdivで矩形操作している。それは画面が矩形であってそれを楽に操作する技術が必要だったからなんだと思う。

terminalだと画面中の絶対座標位置にカーソルを動かしてその位置にあれを出力してとかやってると、構造性ないしすぐ壊れる。vimみたいなのはマジでよく作ったなと思う。tmuxとか見るとたぶん矩形反復操作は端末でも可能なんだろう。ただし、矩形の反復をめちゃくちゃ容易に記述できてしまうHTMLは圧倒的にレイアウトしやすい。

Googleが目立ってきてセマンティクスが云々となったんじゃないかという気がするんだけど(botはレイアウトに関心ない)、このへんはティム・バーナーズ=リーはどう思ってるんだろうな。a11y問題あるから、この意見には必ずしも賛成してくれないだろうけど。

矩形反復についてキュビスムとHTMLの類似性についてなんか分析できそうだけど誰も必要としていないことはあきらか

Audon まだ使ったことがない

今の自分の装備でマイナス20℃テント泊いけるのかはやってみたいな

あとで見る
https://vimeo.com/event/2667716/dac315c3b5

このアカウントは、notestockで公開設定になっていません。

マストドンというか fediverse のなかで fediverse ってなにとかどうあるべきみたいな話よくながれてきて、それじたい興味深い

このアカウントは、notestockで公開設定になっていません。

仕事とちょっと離れた領域の言語は必要かなとつねづね思っている

これ悪くない気がする
https://twitter.com/horikoki_ksks/status/1618192840995241989

@pokarim そうだとおもうのですが、さいきんterminalの画面操作とかを記述してDOMの作りやすさを理解できたわけですが、そもそも一番最初にティム・バーナーズ=リーがHTMLを作ったときに「terminal でのレイアウトがめちゃくちゃ記述しづらい、ドキュメントをもっといい感じにレイアウトする仕組みがほしい」という動機でつくったりしていないかなーとかおもいました。

SGML
https://ja.wikipedia.org/wiki/Standard_Generalized_Markup_Language

「1989年、CERNのティム・バーナーズ＝リーは、オリジナルのHTML（および多くの関連したプロトコル、HTTPなど）のメモを提案し、1990年5月にコード化した[10]。NEXTSTEPの動作するNeXTcubeワークステーション上で開発された。当時のHTMLは仕様ではなく、直面していた問題を解決するためのツール群であった。直面していた問題とは、ティム・バーナーズ＝リーやその同僚たちがどのように情報や進行中の研究を共有するかということである。」
https://ja.wikipedia.org/wiki/HyperText_Markup_Language

"HTMLの初期のバージョンはゆるい文法規則によって定義されており、ウェブ技術になじみのない層に受け入れられる助けとなった。ウェブブラウザはウェブページの意図を推測し、レンダリングを実行するのが一般的であった。"

HTMLって端末とGUIの中間くらいだという感じがする

HTMLの入れ子モデルはのビットマップディスプレイ的な抽象ではないし、かといって端末のキャラクタベースのものでもない。
ディスプレイは端末だろうとGUIだろうと四角で、その矩形を反復する形で入れ子にできるというのは、端末的でもGUI的でもないとおもう。

HTMLのDesign Constraints、これかなり初期の文献っぽいけど、ここでもテキストドキュメントのネストがないということが問題視されている。この入れ子階層はそのまま画面へレイアウト可能になるというのが、本来の基礎的なアイデアなんじゃないかという気がしている。そういう意味では、むしろ意味の表現を排除したレイアウトモデルこそがやっぱり当初問題だったんじゃないかという気がしてしまう。
https://www.w3.org/MarkUp/HTMLConstraints.html

SGMLにおけるタグは意味の記述が主で、スタイルは別途スタイルシートを記述することになっていた。HTMLとの差分を考えると、(ハイパーリンクの導入というのもあるけど)入れ子モデルの導入というのが大きいような印象があるんだけど、どうなんだろうな。
https://ja.wikipedia.org/wiki/Standard_Generalized_Markup_Language

@pokarim @nsiena
この HTML Design Constraints を見ると、TBL本人がセマンティックな記述を排した入れ子モデルを提唱していたように読め、このへんが後に忘れられたか抑圧されたかなのかなーという印象があります。
https://mstdn.jp/@tenjuu99/109750189175026417

@pokarim ああ、そうか読み違えました。編集システムでは、さまざまな仕方でテキストのスタイリングをできるが、SGMLが許容する入れ子の概念がないから、入れ子をなるべく作らないようにすれば編集システムがわでも扱いやすくなる、という主張ですね。