※未来では当て嵌まらない可能性あり。
俺の文法力とは別で、サービス仕様上の話。
読みづらい部分について了承あれ。
もし俺のマニュアル不足による誤認なら申し訳ない。
不足発覚しても、今さら必ず直すとは限らない。
そこも了承あれ。
フィードバッグ済み。
Googleは日々進化する。いつか全てが贅沢に叶うことを願おう。
…そういう結論。
筆者も読者も、それを踏まえての利用を。
リスト題
・子リスト
・子リスト
・子リスト
…これは手打ちでやった目標像。
GoogleSite標準『箇条書き記法』でやったら、こうはならない。
例1
子リスト3行だけ範囲選択して記法コマンド実行↓
リスト題
子リスト
子リスト
子リスト
なぜかリスト題まで巻き込まれる。全てが子リスト扱い。
「子リスト内で改行(br)された関係性」として処理された。
例2
リスト題を、改行(/br)ではなく段落(/p)で隔て、そこに実行↓
リスト題
子リスト
子リスト
子リスト
そりゃそうなるわな。題が離れすぎで直感視しづらい。
どうあれ次はリスト内brをどうにかしてみよう。
例3
全て段落で隔て、その子リスト3行だけ範囲選択し、実行↓
リスト題
子リスト
子リスト
子リスト
箇条書きになったぞ!
しかし題の距離はどうしろっつーねん。
もし段落を捨てりゃ今度は例1(リスト内br)の話に戻る。
モドカしすぎる。
HTMLのリスト記法(li)というものが元々そうなんか…?
人間の視覚的には題と子を引っ付けるほうが絶対いいんだが。
(Gサイトだけの仕様上ではないが)
画像alt部分。
本来の代替テキストに加え、パス文字列まで記した。
この長い文字列が読み上げられてしまうかも。
自ら読み上げ機能併用を推しておきながらだが。
一応ChromeとEgdeで試したところ読み上げられない。
※現時点。またはブラウザ設定次第か。
パス(=フォルダ住所)をなぜ記したかと言うと、txt化バックアップ用。
txtが最も汎用的そして管理しやすい。
記事開いて全選択コピー、からのtxtにペーストで、画像の代替テキスト含め一斉に貼り付け可。
読み上げ機能派は了承あれ。
altが万一読み上げられたら「長ぇ…」ってなるけど、この半自動的な当体制により、読者(読み上げ機能派含む)に一層良い内容をお届けできている…つもり。
※これも現時点での体制。
一方、Gサイト自体のバックアップ機能利用やGドキュメント利用(画像ごとペースト化)は、汎用性に欠けまくり。
特にGドキュメントは、いちいちプロジェクト規模だわ自動クラウド同期されるわで、管理が面倒臭すぎる。
「記事開いて何かのコマンドでbody覗いてコピペ」…の方法も、無理ではなかったけど実質無理だった。
これも何か方法あるんかね?
怖すぎる量のコード99% 日本語文1%未満って感じで、バックアップとは言えない。
HTML化してブラウザで開いてみると本文と添付画像が抽出表示されるものの、今度は画像パスコードが無い。