<strong>: 強い重要性要素 - HTML: HyperText Markup Language | MDN
https://developer.mozilla.org/ja/docs/Web/HTML/Element/strong#em_vs._strong

<em> は文章の解釈が変わるような強調で、 <strong> は特定部分の重要性を示すに留まっている、なるほど

#HTML #documentation

HTML Standard
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-em-element

もうちっと厳密には、 em は stress emphasis だから「発音するときそこを強調する」というもので、結果として、そこが強調されたときとされないときで解釈が変わるような文に使われる。

一方の strong は内容 (contents) の重要性を示すものなので、たぶん強調があろうがなかろうが重要なものは重要なんだよな。こっちはたぶん人間や機械が重要であるとされる場所を発見しやすくする程度のマーカー。

#HTML #documentation

> The em element represents stress emphasis of its contents.

> The strong element represents strong importance, seriousness, or urgency for its contents.

……ということをちゃんと言語化できるレベルまで噛み砕いて理解したうえで英語で説明できるようにならないと、今書いてるライブラリのドキュメントがちゃんと整備できないんだわ

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

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

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

駄目押しの「アンストします」で駄目だった

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

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

そういえば moonlander をﾎﾟﾁｰしてそろそろ1か月ですが、論理今日になって UHK 60 v2 発送の通知が来ました。
やっと moonlander の変態配列に慣れてきた頃なのにどうしよう……

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

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

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

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

ソフトウェアの持続可能な開発を考えるとき資金がないとどうしようもないじゃんという話は一理あるんだけど、その主張をするなら同時に「その資金でやりくりする権利者が解体されたり死んだ後の時代にどうなるのか」という観点でも論じないとフェアじゃないよねとは思う

「大規模ソフトウェアの開発・改修を持続させるためにはフリーライドを禁じる必要がある」は中期的には成り立つだろうけど、もっと長期的に見たとき同様のことが言えるのかは疑問に思うところです

なんかこう、メンテナが現役のソフトウェアをクソデカテックがプラットフォームに使っているという現状に特化しすぎた考え方に見えるというか。メンテナが不在になったソフトウェアをクソデカテックが拾うとかの可能性はないんですかと。

まあ実際そういう事態に直面してみないとどうなるかわかったものではないし、ここで論じていてもしょうがないかもしれないけど……

少なくとも近年の商用フリーライドへの対抗ライセンスは (由来が由来だけに必然的ではあるけど) 文脈が限定的すぎて、自由ソフトウェア思想ほど普遍的あるいは一般的なものではないように感じるので、最近流行りの対クソデカテックフリーライドライセンスが破綻する日はそう遠くないかもしれないと思わずにいられない

端的に言えば、 workaround 的に見えると。

まあそれを言うたら GPL-2 も workaround 突っ込んで GPL-3 になったり、 GPL へ workaround を突っ込んで LGPL や AGPL になったりしているわけで、どこまで本質的な差なのかというのは微妙かもしれない。

まあ結局リスペクトの足りない企業に金を出す人々が邪悪を助長しているのだというところはあって、言ってみれば「ブラック企業でブラックに働く時点でブラック企業を手助けしているのと同じ」と似たような構図が見える

もっと根本的なところまで遡るなら、自分が使っているソフトウェアのライセンスや思想に対する認識が弱すぎるということになるんだろうけど。

ｾﾃﾞｯｸ今回は言語系の話少なそうだったのでまあいいかの気持ちになっている

Pixiv をﾋﾟｰｶｲﾌﾞと読む人じゃん (?)

ﾋﾟｰｶｲﾌﾞ本当に好きなんだよなぁ

むしろﾊﾟｲｶｲﾌﾞか？ (英語的に妥当かは知らん)

ﾊﾟｲｸｼﾌﾞか (???)

なんもわからん

"hard break" と "soft break" ってたぶん英語圏特有の言葉だと思うけど、 AST のノード名として使うにはあまり良い命名ではないなと思った。じゃあどうするかというのがちょっと悩みどころではあるけど。

hard break は変換先の文書や表示においても改行として見えるべきもので、 soft break はソースでは改行になっているけど変換先や表示において改行として見える必要がないもの (たぶん)

あれ、もしかして違うか？

CommonMark Spec
https://spec.commonmark.org/0.30/#hard-line-breaks

あってた

hard break の方は、もっとこう…… forced break とかなんとか別の言いようがあったでしょ

explicit はちょっと違う気がしている

書きたいロジックはどんどん湧いてくるのに、いつも命名で手が止まるんだよなぁ

soft break、 line break as a whitespace くらいのニュアンスなのでめちゃくちゃ弱い

enforcing いいな

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

結局ライセンスが「感染」とか言っちゃう人、ライセンスは守らないといけない鬱陶しいルールとしか思っていなくて、我々やその成果物を守ってくれるから能動的に選択していくものだという考えでないということなんでしょうね

たぶん法律のことを聞いても「守らないといけない鬱陶しいルール」くらいにしか考えてないと思う (超偏見)

GPL が感染とか言ってるけど、プロプライエタリの方がよほど “感染” してるからな。
GPL は “感染” したまま広がることができるから様子が可視化されているだけで、プロプライエタリは “感染” したら即死して広まりづらいというだけで。

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

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

まあ人々が思想に興味ないというのは、それこそ2017年の Mastodon ブームからわかっていたことではあるが……

ソフトウェア開発の本職でさえそういうレベルの人が多いというのは特別に残念ね

copyleft にせよ permissive にせよ、結局思想というか理想を知らずになんとなくで使っても「バナナは健康に良いと聞いたので食べてる」程度のことでしかなくて何もわかってないし応用も効かないし、バナナ食えなくなったときどうするかも考えられないままなんだよな……

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

UserAgent の再来じゃん

https://fedibird.com/@noellabo/106806561307445289

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

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

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

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

hard break を EffectiveBreak とするか ForcedBreak とするかで悩んでいる

単に "line break" とすると、ソース文書での改行と、出力文書のソースにおける改行と、出力文書のビジュアル表現における改行の区別が付かないんですよね……

https://ukadon.shillest.net/@ponapalt/106807351524994973

典型的ユースケースでは後者の2つを区別したくて、たとえば HTML のソースにおける soft break は単なる ASCII における LF とか CRLF で、 hard break は <br/> によって表現されるものなので、これらを区別するには mandatory か optional かではうまく表現できない

だもんで、 hard break には effective とか forced くらいのニュアンスが必要かなと思うんだけど、 "effective break" で調べると「詩を書くとき改行を効果的に使う」みたいな文脈の文章が出てきて、 effective…… うーんそうだね…… という

semantic はちょっと違うんだよな、純粋に visual 全振りで改行を使いたい場合には semantic とは限らなそうなので

こういうとき英語ﾈｰﾁﾌﾞの言語感覚欲しいなぁと思うんだけど、考え直してみるとそもそも連中が hard とか soft とか雑な表現してるのが元凶なんですわ

"guaranteed to be applied to / appear at the visual output" くらいのニュアンスを形容詞1〜2語で表現したいんだけど、まあ険しいのでどこかで妥協するしかない (最有力候補は effective だけど気持ちは forced に傾いている)

tab も hard tab と soft tab があってｵｴｰという……

hard tab は \t で表現するタブで、 soft tab はエディタとかが適切な数の whitespace を吐き出すことで表現するタブ

collapsible break... うーん

もう strong と weak でいい気もしてきた (最悪)

pull tab と push tab (???)

1文字で特定の倍数桁まで引っ張られる \t が pull tab で、インデントの深さ分空白文字を入れないといけないのが push tab #適当

やっぱそうなるかー

soft break 、解釈段階においては単なる空白と等価に扱われたりするので、実質的に break の仲間扱いすべきかさえ怪しいところがある

命名が上手なﾎﾟﾖｸﾞﾔﾏになりてえよ

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

なるほろ

文脈としては、複数の文書形式 (e.g. markdown, HTML, etc.) に共通の AST を定義したいみたいな状況で、 (ソース側でなく) 出力側に反映されることを確約するようなノードをどう命名するかという話なので、 cascading はちょっとだけ違う (<br> とかはソースにおける改行ではないため)

や、普通に line break にしてもいいのかもしれないけど……それだとソースの話をしているようにも読めてしまうため

visual line break / visible break とかも考えたけど、うーん？？？ という感じ

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

なるほど

breaker おもしろいな、命令的セマンティクスではあるけど意味はわかりやすい

ьrok3п !ine

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

最優先席の話します？

「全席優先席」でも効果なし？ 横浜市営地下鉄、新たに「最優先席」: J-CAST ニュース【全文表示】
https://www.j-cast.com/2012/02/28123685.html?p=all

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

マン防の次はオク防

持続性の観点で言うなら長期的には copyleft の方が生存しやすいし、短期的な利用・普及しやすさで言うなら permissive な方が使いやすいし、それは自由というよりスパンと想定用途の問題でしかないと感じる。使いやすい方を取るか長持ちする方を取るか。

プロプライエタリはどちらも指向していないか、あるいは試みているものの長期的な生存に向いているか疑問だというのが元の話題なので

むろん企業が潰れる間際に全成果物を自由ソフトウェア化するようなことも原理的には可能なわけなので、短期的に収益化による持続を試みて長期的には自由ソフトウェアの戦略を採ることもできるにはできる。

とはいえ、たとえそのようにしたいと考えていたとしても皆が本当にそれを実行できるとは到底信じられないので、ほとんどナンセンスな仮定ね

copyleft の性質が自由を求める観点からどうなのみたいなのは、 GNU による「いつ LGPL を採用すべきか」みたいな FAQ 項目でかなり素朴に答えが提示されているものと認識している

つまりライセンスに “感染” 性を持たせるのは自由ソフトウェアのエコシステムへの参入のインセンティブを高めると同時にエコシステムを充実させるものなのであって、多分に政治戦略的な動機があると。

極めて雑に言ってしまえば、自由ソフトウェアに自発的に貢献する人々が十分に多い優しい世界では GPL のような強力な copyleft の意義は薄くなる。

が、残念なことに (ライセンスに疎い人々や槍玉に上げられがちなクソデカテック企業を見ていればわかるように) ここはそのような優しい世界ではなくライセンス違反とフリーライドの溢れた世界なので、それらに潰されないための戦略として copyleft が意義を持っている

copyleft は個々の成果物の生存戦略というよりはエコシステム全体の生存戦略といえる。

一方プロプライエタリで対価を確保しようとするライセンスは結局個々の成果物の持続的開発を試みているに過ぎないので、本質的な違いはそこにある
(というのが個人の見解)

で、 permissive なライセンスはというと開発の持続性とかそういうものを指向するものではないので、自由ではあるけど今回の文脈で Poly なんとかと並べて考えるには少し毛色が違いますね (べつに比較できないとは言わないけど……)

PolyForm だった。まあそれに限らず近年ポコポコ生えてきた諸々の類似ライセンス含めての文脈。

#今すぐ寝ることで救える命があります

wat 形式か

wat 、手書きすると従来のアセンブリ言語より真に強力くらいの表現力はあるんだけど (たとえば再帰的に部分式を記述できたりなど)、 wasm からの逆変換だとそこまで綺麗に出力されるとも考えづらい

逆汗がライセンスの文脈で「ソース」かというと相当疑わしいし、どこかに生成元言語のソース転がってそう (知らんけど)

GPLコンドームとかいう面白ワード思い出しちゃった

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

wat 手書きは一応現実的なので、よく読んでみると本当にそれがソースな可能性も十分ある

不思議すぎてワロてる

HTML なら画像の base64 エンコード埋め込みかもねの気持ちになるけど、 js でやる話はあまり聞かない気がするし

Wrap it before you tap it? No, say Linux developers: 'GPL condom' for Nvidia driver is laughed out of the kernel • The Register
https://www.theregister.com/2020/08/04/gpl_condom_nvidia_linux_kernel/

NeruPointerException

btrfs はいいぞ

https://twitter.com/kyotou_114514/status/1429703007873110016 #tw

草不可避

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

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

転送型の仮メールアドレスであってもサービス提供者がテキストを平文で読めるには違いないので、果たしてそこまでプライバシーを明け渡すべきか微妙

こればかりはユーザが自発的に MITM を受け入れている構造になってしまうので……
PGP とかで E2EE しようとしてもメールヘッダ部分の情報 (たとえば宛先の表示名やスレッド ID) は可読になってしまいそうだし

Kyash 、サービス品質はまあまあ信頼できるのにビジネスとしてのビジョンは信頼できないという

コンパイル時に定数を処理してしまうアレ | κeenのHappy Hacκing Blog
https://keens.github.io/blog/2021/08/22/konpairutokiniteisuuwoshorishiteshimauare/

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

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

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

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

xeyes をフォークして xpies を作ろう。
乳首がカーソルの方向を向きます。

クリックすると揺れます。

アリーナで1vs2から1vs1まで持ち込んだら動悸と身体の震えが止まらなくなってしまった (負けた)

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

bunzip2 とかあるからね

ダンケ水とか

というか性癖 (誤用) 全般それでは

ﾆｰｿとかもそうだけど、あのあたりのデカいグループでどこが何やっててどういう名前なのか、地味にわかりづらい