nDiki : CSS

CSS - Cascading Style Sheets - カスケーディングスタイルシート

2019年10月30日 (水)

HTMLCSS についての勉強会【日記】

今年2回目の部内での HTMLCSS についての勉強会が今日あった。 複数人・複数チームでで開発保守する大規模サイトにおける共通部品化のデメリットの話など、なるほどと。

[ 10月30日全て ]

2020年12月3日 (木)

百科事典型ナレッジベースに向いているナレッジベース Obsidian

以前ノート間リンクのできるノートアプリを探してみた時に触った Obsidian をもう少し試してみた。

Obsidianナレッジベースアプリケーションで、一般的なノートアプリよりも情報間のネットワークを重視している。ローカルホスト上の特定フォルダ以下に置いた個別の Markdown ファイルを [[ファイルベース名]] 形式で内部リンクしていくのが基本。

ファイルの拡張子が md 固定で txt では駄目というのが個人的に不便(拡張子 txt にできないと Google ドライブ的に困る)なのだけれど、過去のノートテキストファイル拡張子を変更してお試ししてみた。

内部リンク

ファイルベース名を指定して内部リンクを文中に書いていくのだが、ファイル名の先頭を日付にする流儀との相性が良くないな。[[ファイルベース名|表示テキスト]] 形式でプレビュー時のテキストを指定できるけど、編集モードだと文章として読みにくい。各ファイルで YAML front matter 形式で別名を宣言しておけばその別名で内部リンクできる機能があるので、丁寧に管理すれば読みやすくはできる。

ただ Obsidian 方言で書きすぎると「ローカルホスト上の Markdown ファイルなので特定アプリケーションに依存しない」良さがスポイルされてしまう。Markdown のショートカット参照リンク形式で内部リンクを張れるようになると良いのになと感じた。

グラフ表示

1ファイル1トピックにしてきちんと内部リンクを張っていかないと価値あるグラフにならない。1日1ファイル + 個別トピックファイルというスタイルだと役に立たないかな。

その他

検索は使いやすい。TaskPaper ほど優れてた UI ではないけれど、フォールディングやアウトライン表示もできたりする。デフォルトのスタイルは個人的に見出しが大きいなと感じるので、常用するなら CSS をいじる必要がありそう。

パーソナルナレッジベースとして

「時間とともに記録・整理しておきたいことが変遷していく」「ナレッジベースを作ること自体が主目的ではない」パーソナルナレッジベースの世界では、静的な情報を丁寧にネットワーク化していく百科事典型よりも日誌/日記型の方が良いと思ってる。内部リンクは編集・維持コストが高いので、パーソナルナレッジベースでは頑張らないのが幸せだ。

Obsidian は百科事典型のナレッジベースが欲しい人にはあいそう。一方自分のような日誌/日記型派にはやはり検索主体の howm 系の方がいいなとあらためて感じた。

[ Mac アプリケーション ] [ ノート・日記はテキストファイルに ] [ ファイル名の先頭を日付にする ]

[ 12月3日全て ]

2021年1月20日 (水)

今日のさえずり: Zettlr 2日目。カスタム CSS を設定して見出しが大きすぎるの直したら使いやすくなった。

  • 21:47 Zettlr 2日目。ちょっと分かってきて楽しい。カスタム CSS を設定して見出しが大きすぎるの直したら使いやすくなった。
[ 1月20日全て ]

2021年2月22日 (月)

Obsidian Publish サイトでノート埋め込み部分の CSS 変更失敗

Obsidianノートに別のノートの全体や一部を埋め込む機能があるのだけれど、埋め込むコンテンツの量が多いと全部は表示されず縦スクロールバーが出てしまう。

max-height が指定してあったので Obsidian アプリケーション用の CSS スニペットや Obsidian Publish サイト用の publish.css で max-height 設定を上書きするようにしてみた。

アプリケーションの方はうまくいったのだけれど Obsidian Publish サイトの方は何か変(リロードすると表示されなくなったりする)。やはり埋め込みは使わないのがいいかなあ。

[ 2月22日全て ]

2021年9月19日 (日)

ObsidianCSS スニペットから publish.css を生成する

Obsidian の表示のカスタマイズ用に複数の CSS スニペットを用意して個別に有効・無効を切り替えられるのに今頃気が付いた。

プレビュー画面用の CSS と編集画面用の CSS」「Obsidian 標準の構造用の CSS と独自の構造・クラス用の CSS」など分けたらずいぶん見通しが良くなった。

今までアプリ用の CSSObsidian Publish サイト用の CSS (publish.css) の2重管理が手間だった。「アプリだけ用の CSS」「Obsidian Publish だけ用の CSS」という切り口でもファイルを分けておき、 必要な CSS ファイルだけを make でマージして publish.css を生成するようにしたら解決できた。なるほどー。

[ 9月19日全て ]

2022年1月26日 (水)

今日のさえずり: 70:20:10 モデルのソース調査

[ 1月26日全て ]

2022年2月21日 (月)

Obsidian Publish でセクションやブロックの embed が正しく表示されない

Obsidian Publish でセクションやブロックの embed が正しく表示されなくなったので、通常のリンクに書き換えた。

CSS の管理も煩雑だし Obsidian Publish での埋め込みは最小限にしておこう。

[ 2月21日全て ]

2022年3月6日 (日)

今日のさえずり: 鈴カステラいまいずこ

[ 3月6日全て ]

2022年8月30日 (火)

今日のさえずり: 唐突にTweetDeckプレビューがやってきた

[ 8月30日全て ]

2022年9月27日 (火)

自分の Tweets のいいね数・Retweets 数はやっぱり表示する

7月から Twitter のいいね数・Retweets 数を非表示にしてみている。他人の Tweets のいいね数・Retweets 数が分からないのなかなか良い。

一方で自分の Tweets のいいね数・Retweets 数はやはり知りたくて仕方ない。トライブの報酬が欲しいの。

TweetDeck については Better TweetDeck のカスタムCSSを修正して自分の Tweets のいいね数・Retweets 数は表示するようにした。

 .stream-item:not([data-tweet-user-id='自分の ID (数字列)']) .like-count {
     display: none;
 }
 
 .stream-item:not([data-tweet-user-id='自分の ID (数字列)']) .retweet-count {
     display: none;
 }
 
 .stream-item:not([data-tweet-user-id='自分の ID (数字列)']) .reply-count {
     display: none;
 }
[ 9月27日全て ]

About

Process Time: 0.024023s / load averages: 0.18, 0.22, 0.23