確かに横幅を圧縮できるのも良いですね
例えばですが、
#nobr{{
|~国名|~正式名称|~面積|~人口|
|イギリス|&fold{United Kingdom of Great Britain and Northern Ireland};|24.5万㎢|6645万人|
|スリランカ|&fold{Democratic Socialist Republic of Sri Lanka};|6.6万㎢|2103万人|
}}
といった形で正式名称をfoldで括ってしまえば、最初については画面幅が広くなくとも国名、面積、人口については折り返しなく見れる上に、正式名称のせいであまりにも横幅が長い、ということも回避できそうです。
自分は早急に実現して欲しいと思っています。
サンプルwikiを見る限りそういう仕様にしてある?
だとすれば正常に表示されるプラグインを追加してほしい
文字化けじゃなくてコード化でした。
この現象数年前からあるみたいですね
賛成です。
あまり詳しくないですけども、pukiwiki系で採用している所も多いですし導入自体はそれほど難しくないんじゃないですかね?
既存のwikiへの対応が大変そうではありますが…
誤字で申し訳ないですが「revert」でも反映されないです。
ミスった。
#aaプラグイン抜きだと普通に表示される模様。(++
++例
#aaプラグイン内に「‒」を入れる
↓
「‒;」←こうなる
私の環境 Chrome 97.0.4692.71(Official Build)(x86_64)で問題なく動作しています。
revent ではなく revert ですよ。
ちなみに絵文字でも同じ事が起こります。
特に空白のUnicodeを使いたいので
今月の27日に対応されていました。
https://twitter.com/WIKIWIKI_Japan/status/1475403578961719306
編集範囲が、末尾の連続した空行を含まない、「見出しの内容のみ」になったみたいです。
例えば、このコードで見出し1を編集しようとしたとき、
従来は、1~4行目までの「連続空行を含む」範囲を編集していたのを、
1~2行目までの「見出しの内容のみ」の範囲を編集するように。
ちなみに、編集範囲が変わっただけなので、新たに付け加えた空行は従来通り削除されるようです。
従来の挙動の良いところをとりつつ、要望を吸収したとても良い変更だと思います。
対応ありがとうございました。
レスありがとうございます。
なるほど、Tabキーに関しては全く知りませんでした。
それなら誤送信を減らした上でスムーズに送信できますね。
ありがとうございました。
PCなら内容を入力後Tabキーを押して挿入ボタンへ移動、Enterで送信ではどうですか。
入力途中でEnter誤送信はたまに見る光景です。誤送信しても直接ページ編集して消したり修正したりすればいいのですが、大抵の人はやり方がわからないのか新たなコメントで続きを投稿します。入力欄でのEnter無効は無難な対応だと思います。またwikiのコメント欄に限らず大抵の入力フォームは上記のようにTabで移動しながらの操作が楽です。
念の為、二回目も行いましたが改善されませんでした。
01vさん、ありがとうございます。
chrome ・・・>設定>プライバシー>閲覧履歴データの削除
を行いました。
しかし、削除後も不定期に3~5回に一回の割合で発生します。
不具合が発生するのはタイトル項目名のみなので、
タイトル項目に画像を貼り付けるのは非推奨であると
考えるべきでしょうか?
設定 プライバシーとセキュリティ 閲覧履歴データの削除で消せませんか。
wikiwiki公式のツイートで
スーパーリロードやキャッシュのクリア
https://twitter.com/wikiwiki_japan/status/1471822144296620032?s=21
をアナウンスされていました。
不具合一つ目と三つ目は、主にスマホ閲覧時に起きます。
スマホのchromeアプリはスーパーリロードやキャッシュのクリアがないので、スマホのアプリを削除→再ダウンロードしていますが、本日12/20も起きました。改善する方法はありませんか?
提案ありがとうございます。
ヘッダーとincludeで注意書きを追加し、様子を見てみます。
荒らしかと思って一応は確認していますがブラウザ・ネットワークID、IPやcookieはバラバラです。
大型アプデ&セールで新規参入者が多く、その上wikiに慣れていない初心者もいるのかと思います。
規制追加しても以降のHITが0のため事前策が欲しいところでした。
今日の分(ヘッダーに注意書き追加)
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=202112192109163ea24&page=*Lab. Violet keycard
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219124504b784d&page=*ポーチ
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219124312498ea&page=*SHORELINE
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219123825be894&page=*Hunter matches
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=2021121912322925f4f&page=*用語集
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219101411238d5&page=*ポーチ
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219042308b71ac&page=*スキル
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=202112190406523f8e5&page=*RESERVE
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218211458d3bd6&page=*LIGHTHOUSE
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=202112182043420e996&page=*LIGHTHOUSE
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218163916aea3b&page=*Dorm room 206 Key
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=2021121814294779d31&page=*MP-133
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218140348ffd7c&page=*操作の説明
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218032101650fd&page=質問掲示板ログ
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=2021121723443183406&page=*Factory exit key
誤入力の可能性は低いように思えます。
検索フォームの入力欄は「サイト内検索」、ボタンは「検索」になってますが、
コメントフォームは「コメント」「挿入」になっていますし、
皆無とまでは言い切れませんが、さすがに多発はないでしょう。
入力途中に誤ってEnterキー押してしまったり、
イタズラの可能性の方がはるかに高いと思います。
(「毎日10~数10個」もあるなら、イタズラでほぼ間違いないかと)
01vさんも述べているように、
毎回メッセージボックスが表示されたら、個人的には鬱陶しいですね。
たまにコメントに単語がポツンとあるのを見かけますが検索の誤入力とは気が付きませんでした。ただ確認表示が毎回でるのは普通にわかってる多くの人には鬱陶しい気がします。コメント欄の下に注意書きを書くとか、ページフッターに検索ボックスを配置するとかして誘導してみたらどうでしょうか。注書きはincludeで別ページ参照にすると管理が楽だと思います。コメント欄の注意書きは誤入力以外にも色々必要なことがあります。
キャンセル時の強制保存は修整されたようです。
見出し編集の文末の改行自動削除は私もやめてもらいたいとは思います。見ため以外の問題というか違和感として、例えばページ全体を編集するときは見出し間の改行は取られないわけで、これは改行が禁則やエラーを出すというわけでもなく、まあ当たり前に余計なことはされないわけです。一方で部分編集のときは勝手に取ってしまうちぐはぐさが気持ち悪い感じがします。エディタ的には読み込みの最後の部分に掛ける処理として判断してるのだと思いますが、ページの実体はファイル全体であり部分編集でファイルの終端処理みたいのを掛けるのは余計なことのように思います。
確かに横幅を圧縮できるのも良いですね
例えばですが、
#nobr{{
|~国名|~正式名称|~面積|~人口|
|イギリス|&fold{United Kingdom of Great Britain and Northern Ireland};|24.5万㎢|6645万人|
|スリランカ|&fold{Democratic Socialist Republic of Sri Lanka};|6.6万㎢|2103万人|
}}
といった形で正式名称をfoldで括ってしまえば、最初については画面幅が広くなくとも国名、面積、人口については折り返しなく見れる上に、正式名称のせいであまりにも横幅が長い、ということも回避できそうです。
こういうことですよね。
しかし、少し不格好かなーと思ってしまいます。
その場しのぎで使うにしても、要望が吸収された後にこれを外す手間も考えると、あまり使いたくはないです。
本題の要望が通るのが一番良いと思うのですが……。
少し試してみましたが、再現はできませんでした。修正されたのでしょうか。
文末に//コメントアウトを入れれば可読性は確保できます。
部分編集の保存動作は、文末の改行やスペースを削除して保存されるようです。よって文末にそれ以外の文字を置いておけばよいです。//で視覚的な区切りを入れつつ、表示に影響を与えない手法は巨大な表編集でも使える手です。
またこの整形動作は保存だけではなく、キャンセルボタンを押したときも強制的発動します。例えば、
この状態から#1を見出し編集で開いて、何も変更せずにキャンセルボタンを押すと勝手に空行が削除され保存されます。
更新メッセージも出力され、Last-modified日時も変わります。ソースを見ようとしてちょっと見出し編集ボタンを押したつもりが変更が掛かってしまうのは問題です。この動作は不具合と言ってよいでしょう。
何も押さずにページを閉じるかブラウザーの戻るボタンで移動すれば更新はかかりません。
ページ全体でみたときに見出し毎に空行で区切りを入れる書き方は私も同じです。
pukiwiki記法はコードというよりか、テキスト文章が基本にありそれを装飾するために部分的に機能を差し込む形なので元の文章のイメージは維持してもらいたいですね。
見出し上部(margin-top)の間隔の調整については、
WIKIのデザインの部分になるので、別トピックで議論できたらと思います。
仰る通り、全WIKIに影響することなので、慎重に議論を進める必要があると思います。
私はWIKIのレイアウトを flex_box や responsive_layout で組むようになりました。
きれいにboxを並べたいのに、上下に謎の間隔が開いてしまうとスカスカです。
影響の範囲が大きいので、個人的に実現は難しいかなと思っています。
文章を見やすくするために編集者が改行を入れたりすることは健全だと思います。
見出しの部分編集で、末尾の改行が維持できるようになればこのトピックは解決です。
それはそうなんですけど、
既にあるページ全てを後から修正するのは手間だし、
運営が修正してくれた場合に、今度はブランクが2行分になってしまい、
再度修正する手間が発生しかねない事を考えると
怖くてできないんですよね。
運営が「以前のようには絶対戻しません」とかコメントを出してくれれば
やってもいいんですけどね。
最後の行に &br; を入れて調整してみてはいかがでしょうか。
各見出しの行頭にスペースをつけると維持されますが、手間なのでやっぱり空行を維持してほしいですね...
そうなんですよね。
だから自分は見出しごとではなく、ページ単位で編集するようにしています。
それと、レスポンシブデザインになったら無くなってしまった、
見出し間のブランクも復活させて欲しいです。
不具合二つ目が解決済みであることを確認しました。
ご対応ありがとうございます。
運営が改善してくれるのを待ちます
例に挙げられた表は、実際と違いが大きいはずでこれをwikiwikiで表示しても問題がよく見えません。問題点を以下のように解釈し、その前提で回答をします。つまり実際に改善するかは確認してません。
要は表示領域から横幅がはみ出るくらい幅広な表で、表示幅による自動折り返しを抑制しつつ、各列の幅を任意に確保したいということだと思います。
ブロック型の#nobrで表を囲んだままの解決策は現状ありません。インライン型の&nobrを表に埋め込んで幅を制御します。&nobrは本来折り返しを制御するプラグインですが、折り返されないことを利用して幅を確保する方法です。
問題点
2列目の幅指定を100で固定する。
実際はもっと列が多く横長の表で各列の内容が表示領域幅に押しつぶされて表全体が縦長になる。
全体をnobrで囲って折り返しを抑制する。
しかしこれは2列目の幅指定100が無視される。
解決案
つっかえ棒で表全体の最小幅を定める方法
&nobr行は表示領域幅による自動折り返しを抑制し、余長は画面外へはみ出す。
表の各列幅は内容により自動で振り分けられる。つっかえ棒の文字列長と表示上の問題は自分で工夫する。
つっかえ棒で各列の最小幅を定める方法
各列で幅を制御したいとき。
特定の記述内容で最小幅を決めるとき。
↑やりたいこと
↓今の仕様
nobr{{(票の幅を変えさせないではみだたせる
||100|c
|あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
|あいうえお|かきくけこさしすせそたちつてと|
||なにぬねの|
列2の幅が改行位置まで横伸びする
列幅指定の効果がないので効果があるようにしたい
A:改行していないテキストの長さに依存させたままでいい列
nobr{{(票の幅を変えさせないではみだたせる
||100|c
|あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
||かきくけこさしすせそたち|
|あいうえお|つてと|
||なにぬねの|
A:改行していないテキストの長さに依存させたままでいい列
B:改行してるけど改行位置に依存させたくない列
これ以上の表現はできません
尋問されるなら取り下げます
伝わりません。
問題が発生してる例をコピペで再現できるように書いてください。
改行していないテキストの長さに依存させたままでいい列
改行してるけど改行位置に依存させたくない列
上記列が混在する表
表全体は上記の条件を満たしたいということです
試したんですけどセル幅(列幅)を150なら150に固定したいのですが
nobr{{を取ってしまうと画面幅やブラウザ幅に合わせて他の列が詰まってしまうのでダメですね
ほー
nobrをセルの中に入れるということですか
ちょっと試してみます