{希哲16年4月5日の開発}{希哲16年4月5日の進捗}{CSS 変数}{生み出した}{伝証}{合理化した}{呼ぶべき}{汚い現実}{ウェブの理想と現実}{もたらされる}...=}(208)

{希哲16年4月5日14歩 K#F85E/E74C-6431}

CSS 変数(カスタムプロパティ)の導入舞覧ブラウザ五年対応原則採用決め終了今後デライトでは,「5年以内離立された版存主要舞覧」を中心に対応していく

希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義考えてはいたが,当時は,古い舞覧対応努力はするが推奨はしない程度の,もっと緩やかなものを想定していた


希哲13年ECMAScript 2015HTML5CSS3比較的新しいウェブ標準導入決めてからだいぶモダンにはなったが,まだデライトの舞覧対応方針には感覚的保守的なところがあった。感覚的に影響範囲の広い付徴主要舞覧対応から10年影響範囲の狭い付徴5年目安導入考えていたrem ですら必要以上には使わなかった

先日前次記法実装グリッド領当て導入したが,これはちょうど主要舞覧使えるようになってから5年ほど経つ機能だった。一記法装体過ぎなかったこともあり,ここまで辛うじて良かったが,他にも色々応用したいことが出てき舞覧対応方針見直し必要を感じていた

決め手は,デライトのダークテーマ対応見据えて CSS 変数の導入考え始めたことだった。CSS 変数主要舞覧対応から5年ほど経つが,本格的に導入するとなると影響範囲広がり過ぎる


Can I use対応舞覧よく調べるようになってから,「5年以内離立された版存主要舞覧」が意外に普及していることに気付いた大体90%以上はある。

地域にもよるだろうが,確かに今時古い舞覧使い続ける方が難しいかもしれない。個人機なら5年平均的な買い替え周期であり,スマートフォンなら古い部類だろう。自動更新標準的になった昔と違って多数派の“普通の人”ほど新しい舞覧使っている

あえて古い舞覧使い続ける場合というと,一昔前なら古い個人機再利用というのがあったが,格安インターネット端末普通に流通している今,新しい舞覧使えないほど古い端末使い続ける費用対効果疑わしく,制危考えれば推奨出来ることではない

一番面倒なのが舞覧の更新許されない企業内利用だが,そもそもそんな保守的な環境デライト利用出来るとは考えにくい

こう考えていくと,デライトにとって古い舞覧への対応重要性極めて低い言わざるをえない

奇しくも新生デライトの完成目指している6月15日に,IE11 のサポート終了がある。中途半端気もする内容だが,いわゆるモダンではない舞覧最後の砦崩壊する新しいウェブ標準への社会的移行象徴的な出来事にはなる。


ある程度古い舞覧への対応考慮してきたのは,企業体力がついた将来対応拡充することを考えていたからだったが,これもよく考えると合理性怪しい

技術的負債”は簡単に返せるものではない。大企業肥大化した交度にいかに苦しめられているかを考えれば合理的に古い舞覧への対応出来る来るかどうかも分からないむしろ組織大きくなった時にこそ見通しの良さ重要になる


もっと根本的なこと言えばデライトウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準普及牽引していくくらいの考えがなくてはいけない。

その伝証デモ足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。


舞覧五年対応原則導入によって,ウェブの理想と現実における汚い現実大部分だった古い舞覧正しく切り捨てることが出来るようになり,前縁整備はもちろん,デライト文書整備でも大きな効率化もたらされるだろう。文書整備では,対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明すっきりする

デライト開発劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則デライト正式離立という大きな節目目前にして生み出したものだった。


=}
{需要がある}{地味ながら}{厳密に考える}{見分けが付く}{開いている時}{実装出来た}{現仕様}{万能ではない}{resize: vertical}{高過ぎず}...=}(116)

{希哲16年3月30日の開発 K#F85E/E74C-7061}

描写欄高さ問題きっかけ自動リサイズ機能字数計実装出来た。ほか装体調整など。

出振るい済み

自動リサイズ機能

旧輪郭選り手では,描写欄出放り高さ新規描出フォーム10em再描出フォーム15emとしていたが,新輪郭選り手ではたまたま15em統一されていた画面撮り10emでは長文書きにくいのでこれはこれでいいかと思ったが,やはり新規描出フォーム一言だけや知名だけの描出使うことも多いためこの高さでは邪魔臭い

ここで,予てからぼんやり検討していた自動リサイズ機能導入考えた一応 resize: vertical設定してあるが,万能ではない10emから20em程度までの範囲で,改行毎に自動リサイズさせる。導入予定字数計では字数情報必要になるため,一緒に行数保持させることにした。

実際に試してみると,1em刻みでも2em刻みでも違和感があったため,10emから19emまで1.5em刻みリサイズするようにした画面撮り初期状態最大自動リサイズ19emだと個人機でも低過ぎず高過ぎずスマートフォン縦向き柔品キーボード表示させてもちょうど収まる程度の高さになる。折り返し多い1行もありうるため,厳密にするなら字数考えるべきだが,とりあえずはこれで様子を見ることにした。

再描出フォームに関しては,さほど目立つものでもなく,描写部高さ合わせて描写欄開くようになっている現仕様悪くないので,現状維持様子見しておく。

字数計

字数行数保持出来たことで字数計難無く実装出来た描出ボタン時印左側邪魔にならないように表示させてみた字数計の様子

下見字数分けようかと思っていたが,下見開いている時下見字数置換すれば十分であることに気付いた一応見分けが付くようにに「」を付けるようにした。

これも,厳密に考える特殊な文字符号などを考慮する必要があるが,キリがないのでとりあえず .length による概算でよしとしておく。

字数計は,地味ながら意外に需要があることを市場調査通して知った自分でもたまに欲しくなることがあった。

{overflow: hidden}{進捗記録}{希哲16年3月2日の開発}{希哲16年3月2日の進捗}{希哲16年3月2日}{position: relative}{overflow: clip}{調整していく}{揃わなくなる}{縦位置}...=}(83)

{希哲16年3月2日10歩 K#F85E/E74C-FDA9}

=}
{進捗記録}{目出し輪符の匿名化}{目出し輪符}{使えてもいい}{ありそう}{実用的な}{;}}{:}}{{;}{{:}...=}(50)

{希哲16年1月15日14歩 K#F85E/E74C-8E46}

(書きかけ)

進捗時限記録中略

類型化正規表現 rgx_IKON_T整理しつつ,目出し輪符実装出振るい手定め済み目出し輪符手定めの様子

5日5歩検討下敷きにしたが,これも実際使ってみる想像以上収穫だった。

使ってみるまで,前後両方表示するのは遊びくらいかと思っていたが,文中使う時の目印など実用的な使い道意外にありそうだ。

面白い閃きもあった。顔文字して {::}使うなら,ウインク型の {;;}使えてもいいとは思っていたが,これが出放りアイコン使えることに気付いたアイコン表示したいが利用者固有のものである必要はない,あるいは少し不都合がある場合に使える顔文字にもぴったりだ。


この手応えで類型化正規表現は漸次的に行っていくことにした。

{意外に}

{}