スキンとCSSの仕様について。†
- ページ: BugTrack2
- 投稿者: JingTakano
- 優先順位: 普通
- 状態: 完了
- カテゴリー: その他
- 投稿日: 2005-06-13 (月) 10:16:34
- バージョン: 1.4.5_1
メッセージ†
せっかく苦労してCSSやデザインをカスタマイズしても、スキンの仕様がバージョンアップの度に変わる為、また１からカスタマイズし直すか、バージョンアップを諦めるしか現状では手がありません。
今回のバージョンアップ(1.4.5_1)ではCSSファイルまでPHP化してしまい、PHPが読めない人ではCSSすらカスタマイズをすることが困難となってしまいました。
カスタマイズする人のことを考えて、もう少しスキンの仕様を標準化し、落ち着いたものにできないでしょうか？
もう一つは、XOOPSやWordPressME1.5.1のように、スキンを機動的に切り替えることの出来るような仕様にしてほしいんです。
CSSなどのファイルをフォルダに一纏めにして、自由に選択できるように。
Skinっていうよりは、themeって言った方がいいのかな？
検討の程、宜しくお願いします。
- 既存の話題とかぶっている感のある問い合わせですが (^^; 、いつもの様に、話題を分解しながら進めましょう。 -- henoheno
- 回答ありがとうございます。一応、開発姿勢の理解はできましたが、納得はできません。
やはり、いくらなんでも敷居が高すぎるので、素直に諦めます。 -- JingTakano
- デフォルトのスキンがどうなっていて今後どうなるのかと、個人がどのような形でどのようにCSSをカスタマイズしたり、オリジナルのCSSを保持するのかは分けてお考え下さい。敷居を低くする方法は下に挙げた通りです。 -- henoheno
- 私もスキンの標準化について賛成です。 -- Yoshii
- こんにちは。Yoshiiさんのイメージされる「標準化」をもう少し教えて下さい。 単に標準化と言うならば、別のページで取り上げられている「プラグインごとのcss idやクラス名に統一のルールを設けよう」というのがあたります。動的なものを静的にする、ということは普通標準化とは言いません (^^; -- henoheno
- お疲れさまです。確かに標準化と動的・静的の話を混同していました。ただ、PukiWikiとしてスキン作者の増加を望むのであればtDiaryのようにcssファイル一つですむような仕様の方が良いと思うんですよね。MVCモデルを当てはめて考えると、CSSはViewなので切り替えなどの発生する機能は他に持って行ってくれた方がデザイナーとしてはうれしいです。 -- Yoshii
- tDiaryスキンを使うという案はいかがでしょうか？ tDialyスキンのCSSファイルは静的な１つのCSSファイルだった気がします。印刷やUA個別対応など柔軟なCSS出力には限界がありますが、「静的CSSを利用した手軽なカスタマイズ」と「PukiWiki本体の修正の影響を受けたくない」というポイントは満たしているかと思います。 -- にぶんのに
スキン内部の機能追加について†
- ここらで真剣にSMARTYとかpatTemplateとかを考えるべきなんでしょうか。 -- Ratbeta
- 今までの話題と、SMARTYのようなモノについてはBugTrack/790で既出です。必要だと思った方が、既存のスキンをSMARTYで作って見ると良いでしょう。実際に前例はあるわけですから、使ってみても良いでしょう。 -- henoheno
- あまりうまく伝わっていない感もありますが、1.4.5_1(1.4.5)は、1.4.4で動くスキンもファイル名を直す程度で動作するはずです。1.4.5ではもう少し融通の利く内部構造を追加しただけで、以前の内部構造を削除したわけではないからです。そのため互換性が無いという意見には誤解があると思います。やって見て、妙な所があったらofficial:質問箱などを活用して下さい。仮に問題があれば修正されるか、他の方がそれを見本にされるでしょう。(成功例も失敗例もほとんど耳に入ってこないので、上手く行っても行かなくても教えていただきたいです :) ) -- henoheno
- 1.4.5から入られた方は、標準のスキンにコードが埋め込まれていますので、少々戸惑いがあるようですね。 -- teanan
CSSの仕様は変化していない / 集約した意義 / 動的になった事による付加価値†
- CSSについて。極端な事を言えば、「俺はPHP化されたCSSが嫌いだから、ブラウザで取り出して普通のCSSにしちゃったぜ」という声が聞こえてこないのはなぜなんでしょうか。その状態を無効にする方法は存在します。*1 -- henoheno
- また、CSSについては構造的な変化がありませんから、以前のデータはそのまま使えます。「俺はカスタマイズしたCSSがあるから、それを今でも使ってるぜ」と言う事は可能です。つまり「使わない」という選択肢もありますよね。 -- henoheno
- そして、PHP化した最大のきっかけは、今までCSSがメディアごとに最低二種類(screen, print)、言語ごとに最低二種類(en,ja)、組み合わせると最低四種類あるという物理的な無駄にあったわけですが、果たしてカスタマイズされたという皆さんは、本当にこの四種類をきっちり改造されたのでしょうか。普通しないですよね。苦痛を感じるか、その前に対象を絞るはずです。実際に自作スキンに添付されているCSSも一種類しかケアしていないものが存在したのですが、それはその作者の方が悪いのではありません。そうした今までの苦痛を検討に入れて下さい。 -- henoheno
- という事で、「使わない」という選択肢は以前からあって、今もある事を考慮いただいて・・・ -- henoheno
- CSSの出力部分が集約されたという(デフォルトのCSSの)話は当分落ち着かないでしょうけれど、わけわからんかと言うとそうでもないでしょう。今BugTrack/789で検討しているのは「多色化」、つまりさらにCSSの内部的な出力バリエーションを増やす方法です。「PHPやCSSは詳しく知らないが、HTMLで色を指定する方法は知っている」方にとってはカスタマイズの余地がある環境になることでしょう。他に、official:質問箱3/100で例があるように、ブラウザの個別対応を盛り込む可能性もあるでしょう。その他も同じです。 -- henoheno
- (・・・メディア, 言語, 色, ブラウザ用の要素がそれぞれ2種類づつだけあったとして、全部静的なファイルで作ったら 2x2x2x2 = 16個必要ですね (^^; -- henoheno
- カスタマイズしたCSSを使う事はできるのですが、本家がPHPにしたので何か意味があるのだろうという事で使うことに躊躇してしまう、と言う理由があります。 -- Yoshii
- Movable Typeのスキンの変更方法になると幸せです。 -- Yoshii
- （４種類について）なぜPukiWikiだけが４種類のスキンが必要になったのかの理解に苦しみます。XOOPSでもMovable Typeでもスキンは一つです。（メインで面倒みるのはデフォルトCSSだけで言いと思うんですけどねぇぇ。。） -- Yoshii
- medeia, 言語で分けられていた当時の状況を掘り下げていただかないと理解いただけないと思います (^^; -- henoheno
- media=printについてPukiWikiが何をやっているのかはお調べになって下さい。そこをご理解いただいていないようでは、「他と違う」事だけをきっかけにしただの独り言になってしまいますよ。 -- henoheno
- media=printが必要ないのであれば、PukiWikiのスキンからのそれを呼ぶ一行を削ることをお薦めします :) でもそのような一サイトの構成に関する話と、デフォルトの機能と(それを維持する、維持しないかを含む)は無関係です。 -- henoheno
- コードもそうですが（まぁ、Printだけなのでそれほどではないですが）拡張子がPHPなのでスタイルシート編集ツールがCSSとして認識しれくれないのですよ。 (^^; -- Yoshii
- どんなツールがあるのか、拡張子だけの問題なのか、上で挙げているようにCSSとして取り出し終わったものを対象にするとどうなのか(問題ないでしょう)等、色々お試し下さい :) -- henoheno
- 横槍失礼します。official:自作スキン/GSではPHP化スキンの機能を活用して作っています。元々のja,en切り替えやmediaの切り替え以外に、pukiwiki_gs2.ini.phpという設定ファイルから設定を読み込んで動的に動作を切り替える（2段組⇔3段組のように）ことが可能になっています。この動作はcssを含めphp化しなければ実現不可能なことのように思います。また、以前のような4つに分かれた状態ではなかなかスキンを作る気にはならないという点にも同意します。 -- yiza
- 最近使い始めたもので、蒸し返すようになりますが。四種のスタイルシートをまとめphp化した、というのは単に解決策の一つ。それより複数のシートを「カスケード」させたほうがスマートだったのでは？共通部分と装置・言語依存部分を分離すれば、改造部分はたいてい一つのファイルにおさまりますし、改造部分を別シートにしておけば移行もデフォルトに戻すのも楽。読み込むスタイルシートを一つにする必要性があるなら別ですが、そうでないならスタイルシートのphp化自体には大きな意義はないでしょう。少なくとも私は魅力を感じません。 --
- こんにちは :) 冗長なcssをまとめたのはメンテナンスの都合で、単なるファイルが欲しかったり、PHPに触りたくないユーザーはいつでも静的なものを取り出す事ができます。複数のcssファイルを読み込ませる(カスケード?)テクニックはこれとは別の話題です。例えばtDiaryスキン用のcssはそれをやっています。また４つなら大丈夫だという視点をお持ちの様ですが、例えばtDiaryスキン用のcssは8種(カラーバリエーションが2つしか用意できていないので、まだ少ない方)のcssを出力します。選択できるギミックや例外処理が増えれば増える程、メンテナンスの負荷は掛け算式に爆発します。この辺の魅力をご理解いただきたい所です。「カスケード」について誤解していたらご指摘下さい。 -- henoheno
- その他「(静的なファイルに比べ)軽くない」事と、「管理者が定めたデザイン以外の組み合わせが出力できてしまう」事があると思います。どちらも、静的なファイルを取り出す対応で簡単に厳守させる事ができるでしょう。前者は、HTTPのetagのような工夫を盛り込むことで軽減できるかもしれません。後者は、外部から引数を受け付けないようにしてしまう事でも実現できるでしょう。 -- henoheno
スキンの動的な切り替えについて†
- 実際に実現している人もいるしその例も探せばあるでしょうし、とても既出なので省略 (^^; -- henoheno
- 効率と「情報を束で扱う」事を考えると、個人的にはWiki一本ごとにデザインを揃える事をお薦めしたいです。（その前提として、必要に応じて複数持つという発想も :) ) -- henoheno
- ここに猛者が。PHP的には動的な切り替えではなく、静的なんでしょうね :) 「こちらはtDiaryテーマの他に、GSとorangeboxとintelテーマの切り替え実験をしています」 http://hirokasa.info/info/ -- henoheno
- 説明ページも何も作ってないんですぅ。tdiary-demogen.shは「require('./pukiwiki.php')」と変更し、実行しました。:p -- hirokasa
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
