リクエスト広場

views
6 フォロー
963 件中 601 から 640 までを表示しています。
5
款冬華 2023/03/05 (日) 01:31:46 >> 4

私自身もそうですがWIKI管理者側ではなく、閲覧者側で基となる表組みを自由に行・列のフィールド制御ができるようになると、使い勝手が格段に上がるのでみんなが声を上げていると推測しています。tablesortプラグインとも相性が良いので、是非とも導入をお願いいたします。参考:行の抽出のプラグイン追加要望

4
款冬華 2023/03/05 (日) 01:17:29

ここ数日、このトピック以外にも表組みに関する機能改善・要望の投稿が続いております。
ご検討のほど、どうぞよろしくお願いいたします。

2
名前なし 2023/03/05 (日) 00:14:05 0a221@571ce

賛成です。
この機能を追加していただけると情報を表形式で羅列するしかないページの利便性が格段に上がると思います。

3
名前なし 2023/03/05 (日) 00:10:51 0a221@571ce

似たものとして表の中のものを抽出するようなオプションも欲しいです。

名前種類
うし哺乳類
ねこ哺乳類
かえる両生類
かぶとむし虫類
いるか哺乳類

みたいな表で「チェックボックスを押すと哺乳類だけを抽出」のようなものだったり
「検索ボックスで いるか と打つといるかのみになる」ものだったり

8
01v 2023/03/02 (木) 01:12:15

不具合を再現しました。

条件

  • Android Chrome
  • 構文ハイライト0.2.1有効

再現手順

  • 新規ページを作成
  • なんでもいいので日本語モードで文字を入力。
    全角半角は関係なし。例
    123
    
  • 変換入力を確定する。
  • カーソルキーを適当に動かす。あるいは入力キーのモードを切り替える。
  • 次に文字キー押下した直後、入力中の文字の右側にあったキャレットが文字の左側に戻される。

問題が発生しないパターン

  • 構文ハイライトを無効にする。
  • 日本語入力モード以外。記号など変換を介さない入力。
  • 他のブラウザーで入力する。
    Habitでは問題が発生しなかった。他は未確認。

構文ハイライトのためのパターンマッチングが、入力途中に割り込んでる?

7
とくめい 2023/03/01 (水) 19:59:50 77631@33300

投稿主です。
回答ありがとうございます。Google日本語入力がサ終してたとは...
Gboardに入力を変更し、端末再起動等実行したのですが事象は変わっていません。
他に案が見つからなければ、β版と言う事もあるので既知の不具合or解消できない要素としてスキップしようかなと思っています。

改めて環境について載せておきます。
使用端末:Andoird(バージョン問わず)
使用キーボード:Gbord
広告ブロック:未使用
発生条件:「構文ハイライトあり」かつ「何かしらの要素を含んだ行で入力」

2
01v 2023/03/01 (水) 01:03:00

デザインテンプレートにより見え方が違います。
多分ほとんどのサイトでは表を組み込んで、何もせずともページ背景の色と一致します。
なのでその書き方ではリクエストの意図が伝わらないと思います。現在どのように見えてるのか画像があったほうがいいです。
おそらくOfficial系のテンプレートを選択してると想像しますが。

  • 以下のように書けば表の背景は透明になります。
    色として透明色を指定してるだけです。色指定がある機能ならどれでも同様に使えます。

    個別セル
    |BGCOLOR(transparent):A|
    列毎書式
    |BGCOLOR(transparent):|c
    |A|
    |B|
    |C|
    
  • 枠線の色指定はできないと思います。
    これは指定できるようになると良いと思います。
    枠線なしとか、外枠だけとか、横線なしとか、線種(破線など)とか。
    例えば現在のやり方として、一つのセルに箇条書きのように複数行記載するために&br;を使ったりするのですが、ソースの記述は長い1行になり内容の確認や編集が大変です。表で行ごとに分けて記載して横線を消せれば、あたかも一つのセルのように見せることができます。
    また各セル毎の上下左右の枠線を個別に指定できるなら、現在の結合書式(~、>)ではできないような罫線が書けます。

  • デザインテンプレートによりページ背景と表の背景の関係が変わります。
    リンク
    default系はページ背景とテーブル背景は一致ます。
    Official系はテーブル背景に色が付くと思います。
    ただメニュー内のテーブルはデザインによらず白抜きになったような気がします。

  • 類似の話題
    flexboxの境界線と背景色指定

1
あくあ 2023/02/28 (火) 18:24:06

:Headerでは希望通りの完全透明にできます。
これをMenuBarや普通のページでも使いたいです。

6
名前なし 2023/02/27 (月) 20:56:42 68c4a@c12eb

ATOK for Android(買い切り版)、かつ構文ハイライトあり
→カーソルが想定外の位置に行く現象が起こったので、01vさん>> 4の説が腑に落ちました。
買い切り版はサポートを終了しているためPOBox Touchと同じ状態です。

2
名前なし 2023/02/27 (月) 20:50:10 68c4a@c12eb

アリかなと思います。

データ編集用のページで全情報を入れておき、includexで取り込む際不要な列は非表示にしたいことがあります。
このケースの場合、行であればnullプラグインとincludex側指定で代替できますが、列はどうしようもありません。
導入されれば便利になると思います。

(tracker_plus_listでやれはごもっともですが)

3
koishiba 2023/02/27 (月) 13:35:24 0b3fb@6efbf

いいですね。便利に使えそうです。

kanateko氏は便利なプラグインをいくつも作っていますね。
sliderプラグインの実装も是非!)

1
koishiba 2023/02/26 (日) 11:56:24 0b3fb@9ac97

閲覧制限ではなく「編集制限」ですよね?
(閲覧制限はあり得ないです。
レンタルwikiだけでなく個人でサーバーを運用する場合も同様です)

閲覧を含めてグループ内だけで共有…ということなら、
グループウェアをご利用ください。

1
もちチーズ 2023/02/25 (土) 22:43:11

同じく、テーブルの行を格納・展開できる機能があると嬉しいです。
列の方を必要とする機会はあまりないですが、行の方は無暗に表が長くなるのを避けることができて便利そうですね。

1
アカサカ 2023/02/25 (土) 16:13:37 a0551@3cb94

運営が対応されるまで、しばらくの間は以下の記述で画像を表示してください。(編集プレビューで画像表示を確認済)

**譜面 [#score]
//~BPMは中盤が172でそれ以外は258。
~&attachref(https://cdn.wikiwiki.jp/to/w/taiko-fumen/%E5%8F%8E%E9%8C%B2%E6%9B%B2/%E3%81%8A%E3%81%AB/Spectral%20Rider/::attach/Spectral%20Rider5.png,nolink);

~見た目重視
~&attachref(https://cdn.wikiwiki.jp/to/w/taiko-fumen/%E5%8F%8E%E9%8C%B2%E6%9B%B2/%E3%81%8A%E3%81%AB/Spectral%20Rider/::attach/Spectral%20Rider%E8%A6%8B%E3%81%9F%E7%9B%AE4.png,nolink);
5

そうだったのか、半年前に知りたかったぜ…

4
01v 2023/02/24 (金) 19:27:46 >> 3

poboxもサービス終了してます。
想像ですが、どこかのタイミングでOSかブラウザ全般の入力仕様の変更があり
開発を中止してるIMEはそれに対応できてないのでは。

3

gboard使ったら確かにならなかった。poboxが悪かったのかな?

2
01v 2023/02/24 (金) 14:25:16

Android + Gboardで確認しましたがそのような現象にはなりません。
(構文ハイライトあり・なし、どちらも。)
Gboardあるいは他の入力アプリで確認してみてください。
Google日本語入力Android版はサポートが終了し、Gboardに統合されてます。

1
まるね 2023/02/24 (金) 11:55:37

同じ不具合でかれこれ半年以上困ってる…去年はまだedgeとか使えばならなかったけど最近はどのブラウザでもなる

2
LEGLEG 2023/02/24 (金) 04:05:41

ありがとうございます。
このことをヘルプページにも追記していただければ、利用者の方も混乱なくプラグインを利用できると思いますので、宜しければ追記の方をお願い申し上げます。

1
01v 2023/02/23 (木) 09:50:12 修正

TITLE:やLEFT:などの後に半角スペースを入れると行頭スペースと同じように扱われ、整形済みテキストと解釈されるようです。
これは参照文字だけではなくインライン要素も展開されません。
半角スペースを参照文字にする必要があります。

LEFT: &color(lime){ボーカロイド};
LEFT: &color(lime){ボーカロイド};
LEFT:&color(lime){ボーカロイド};

ちなみに段落書式~の後に半角スペースを入れてもスペースは詰めて表示されます。

LEFT:~ &color(lime){ボーカロイド};
4
款冬華 2023/02/20 (月) 13:37:24 >> 3

どちらのブラウザについても手動アップデートに設定変更していて、バージョンは変わっていませんでした。拡張アドオンも変更していないため改善された理由は不明です。今後とも、より良いサービスの提供をよろしくお願いします。

3
WIKIWIKI運営 2023/02/20 (月) 13:21:04 >> 1

構文ハイライトは動作保証をしておりません。
使用している端末の環境設定によって使える機能、使えない機能があります。
今回、修正は行っておりませんので、環境設定をご確認ください。
ご理解いただけますと幸いです。🙇‍♂️

2
款冬華 2023/02/20 (月) 12:35:40

zawazawa掲示板で表データ作成は思うようにいかないので、いつか書式付き貼り付けが出来るようになると嬉しいです。

1
款冬華 2023/02/20 (月) 11:47:07

ご対応ありがとうございます。
本日、当環境でどちらのブラウザでもMicrosoft officeのExcel内の簡単なレイアウトの表をコピーして構文ハイライトβ版の編集画面に右クリックして貼り付けしてみたところ、書式付き貼り付けになっていることを確認しました。

10
名前なし 2023/02/16 (木) 15:26:05 50f3f@94f39 >> 9

Renameプラグインの中に置換などの機能も含まれてるのが大きな原因なのでしょうか。
管理者が積極的ではないのに毎回お願いするのも、編集者に新規作成を促すのも負担でしかないです。
https://pukiwiki.osdn.jp/dev/?BugTrack/506

1
アカサカ 2023/02/16 (木) 09:57:20 b013e@3cb94

>理論上、規制ルールとして、ページ名を対象に、ワイルドカードで*を指定、全ページをSMS認証必須ページとすることのみで、初回でのSMSトークン判別が可能かと思います。
>しかし、一般の利用者の編集等を委縮させてしまう効果があり、可能な限り運用したくはありません。

ページ内容で特定ワードの規制することに賛成です。
当wikiでも以前、荒らし対策として全ページをSMS認証に変更したことがあります。その結果、編集してくれる利用者が躊躇して激減したことがあります。ユーザー登録なしで簡単に誰でも編集できる場であることは、無償の情報提供行為をする上でとても重要だと感じました。

9
名前なし 2023/02/15 (水) 17:49:18 68c4a@a3f6d

一括変換は1万ページの大量破壊行為が安易に出来るため、サブ・パスワードへの解放は反対です。方針にも明らかに反するでしょう。

しかし、改名は1ページ1ページ指定する必要があり大量に行うことが出来ないため、破壊行為が安易に出来るという機能とは少し離れています。(間違っていればご指摘ください)
改名ではバックアップを完全に維持することが出来るというメリットもあります。
そのためそちらは賛成です。万一暴走しても、サブ・パスワードを削除し再改名によって、被害を元に戻すことが出来ます。

なおリクエスト広場はディスカッション形式であり単なる要望通達掲示板ではないので、返信は問題ではないと考えます。
ささいなことで都度返信するようではさすがに問題だと思いますが、そうではないように見えます。

8
koishiba 2023/02/13 (月) 20:15:40 0b3fb@3e4f2 >> 2

ログインユーザーのみ編集可能にできる機能が欲しいのなら、
別にトピックを立てられたら良いと思います。
(確かSeeSaaWikiやatwikiなどではできた筈です。
もっとも、その設定が可能なのは管理ユーザーだけですが)
追加されるかは運営次第ですが、
機能が増える分には誰も異は唱えないと思いますよ。

ページの新規作成に(パスワードによる)制限を掛けるのは現状でも可能です。
サブパスワード所持者でも行えるようです。

ページの削除に関しては、基本的には誰でもできるようにしておかないと、
管理放棄されたwikiに荒らしが悪戯で作成したページが増殖していくことになりかねないので、
運営は応じないだろうと思います。

7
名前なし 2023/02/13 (月) 18:00:45 修正 50f3f@94f39 >> 2

ログインしてないと編集できないようにするというのは、編集するハードルを上げることで荒らしを抑制できるのではないかという意見です。
ログインしないとページの新規作成や削除ができない的なやり方でもいいと思います。

6
名前なし 2023/02/13 (月) 17:55:13 修正 50f3f@94f39 >> 2

説明不足でした。私としては、手動でもできることを管理者権限で制限していることは矛盾していると感じています。手間か手間ではないかの違いで荒らされるリスクは開放しても変わらないと感じています。管理体制云々ではなく、そもそもが矛盾しているでしょって話です。
リネームを制限するのであれば、新規作成や削除も制限されるべきです。

>何を根拠に信頼関係があると主張するのかさっぱりわかりません。
信頼してない人に編集合戦・荒らし対応をお任せしているというのであれば私から言うことは何もありません。

5
koishiba 2023/02/13 (月) 17:52:10 0b3fb@27dcd >> 2

ログインしていないと編集できないようにすることと、
ページリネームの開放要請にどのような関係があるのでしょうか。
ログインメンバーのみ編集可能にする機能が導入されたとしても、
管理ユーザーはあくまで1人であり(他のwikiサービスも同じです)、
ページリネームは管理ユーザーだけの権限と運営が考えている以上、
権限が開放されることはないだろうと思います。

サブパスワード所持者の主たる役割についてはあくまで私見です。
コントロールパネルの解説ページを見ると、デザインや各種設定、高度な操作など、
編集合戦・荒らし対応と無関係なものはサブパスワード所持者には行えず、
サブパスワード所持者が行えるのは、編集差分ログ・規制ルール・編集制限・通報など、
編集合戦・荒らし対応に関連するものだけだからです。

信頼関係云々については、
何を根拠に信頼関係があると主張するのかさっぱりわかりません。
サブパスワード申請を認めてもらったのだから管理ユーザーから信頼されている
→信頼されているのだからページリネームできるようにしてほしい
そういう理屈でしょうか?

4
名前なし 2023/02/13 (月) 17:32:33 修正 50f3f@94f39 >> 3

ページ名変更や一括変換はやり方によっては手動でもできると思いますが、その機能を管理者のみに制限してるにもかかわらず誰でも編集OKとしているのは矛盾しているのかなと感じたのでトピックを作成した次第です。
手間が掛かるか掛からないかの違いで、管理云々は何も関係なく致命的なダメージが与えられるリスクは常にあると感じています。
とりあえず要望を伝える目的でのトピック作成ですので、これ以上のコメントは控えます。

3
アカサカ 2023/02/13 (月) 15:57:52 a0551@119fb

ページ名変更と一括変換機能の二つは利用しているWIKIでも時折、話題になります。私自身も開放してほしいと待ち望んでいる一人です。
ですがWIKIWIKIは運営開始当初から一貫して、1人の管理人が全体を管理することが前提であるシステムとなっています。
運営の方針がWIKIへの致命的ダメージを与えることもある管理権限を複数人で行使することを許容しない限り、なかなか仕様が変更されることはなさそうです。

2
名前なし 2023/02/13 (月) 14:44:29 修正 50f3f@94f39 >> 1

何が的外れなのかは分かりませんが、例えばログインしてないと編集できないようにページ単位で制限するといった機能も荒らし対策の1つになると同時に、誰が編集したのかといった確認もやりやすくなります。

>サブパスワード所持者の主な役割は編集合戦や荒らし対応
こちらはWikiWiki運営が示しているのですか?

>そもそも管理ユーザーとサブパスワード所持者の権限に差が無ければ、
>見ず知らずの他人のサブパスワード申請に応じる管理ユーザーはほとんどいなくなるのではないでしょうか。
信頼関係があってサブパスワード申請に応じるのではないですか?その理論でいうとサブパスワード保持者からしても管理人は見ず知らずの他人です。