> 今後の、Sitedev+ATの方向性というか、目指すものとしていかがでしょう?
最近、またよけいな事に首を突っ込んでいます。
Sitedev+AT 関連の機能追加は、もう一息ついたら行いたいと思っております。
アイデアがありましたら、ぜひ、お知らせください。
> また、このたび、上記のように、メニュー側にcontentsxを設置するために、別途contentsxmなるものをつくり、デザインできるように、
> cssファイルを専用に作りました。(もともともcontentsxでは、味気なかったので・・)。
ぜひ、公開してください。
> #naviとか#topicpathとか、いろんなプラグインがありますが、デザインの幅ができるようにcss部分を別途cssファイルで指定するよう
> になったら良いかなあと感じました。
> cssの知識が必要になって初心者向きでなくなるとの懸念もあるでしょうが、別途cssファイルを操作するプラグインなどを考えれば、そういったことも
> 軽減されると思います。
プラグインのインストールパッケージという構想を以前考えていました。
pukiwikiのプラグインの場合、プラグインフォルダーに入れるだけの簡単仕様で便利なんですが
CSSや、ジャバスクリプトの追加が伴うと、いきなり面倒になります。
そこで、必要なファイルを、適切なフォルダーに自動で入れてしまうものです。
ただ、これを考えていた時、pukiwikiとあまり離れるのは拙いと思って、途中まで作って
放り出していました。
現在のsitedev+ATでは、pukiwikiにできないことを、だいぶ入れてしまっています
たとえば、CSSの追加行やジャバスクリプトの追加はプラグイン内で行えます。
なので、新方式を考えても良いかもしれません。
CSSの切り替えは、実際にメニュープラグインで実装している方式で出来ると思います。
現在の、CSSを後書き優先で変更している部分をメインのCSSに反映できれば動作的にも
良いと思います。
> それと、ページ作成画面で、ページ全体のheader部分は良いとして、navi部分、menu1部分、main部分、などが、一度に見える形で編集窓
> が出るという案はいかがでしょう。
> サイドメニューとMAIN画面と行ったり来たりの編集がわかりづらく感じたことで、こんなことを考えてしまいました。
> でも、なかなかいい案ではないかと思ったものですから、ご提案?したく存じます。
これは、けっこう難しいと思います。編集のインターフェース部分は結構複雑になっているためです。
今年もがんばりますので、いろいろなアイデアを御願いいたします