件名: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 08 10:33
投稿者: dengen

こんにちは、dengenです。 現在本家で開発が進められている新テーマに相変わらずTableレイアウトが採用されようとしています。 新テーマはprofessional_cssがベースです。 CSSレイアウトを採用したテーマの心臓部をわざわざTableレイアウトにするというのですから、私には滑稽に思えます。 本家がTableレイアウトを採用する理由は、professional_cssではJavaScriptが無効のときにレイアウトが崩れてしまうからだそうです。 professional_cssはJavaScriptでHTML文書に左右のカラムが存在するかどうかを判定し、その情報をbodyタグにクラス名として書き込みます。 そしてその情報をもとにCSSをつかって自在にレイアウトを変更しています。 Geeklogではprofessionalテーマのように3カラムレイアウトのときでも、ページによっては2カラムレイアウトになりますが、professional_cssとJavaScriptオフの組み合わせではセンターカラムの幅調整が行われず、右カラム幅(または左カラム幅)の空白領域ができてしまいます。 Tableレイアウトでは自動的に幅調整されるのでこの問題は発生しません。 しかし、これだけのためにわざわざTableレイアウトに戻すという判断は正しいのでしょうか? レイアウトの崩れを問題でないとは言えませんが、情報の欠落はないし、昨今のHTML5の勢いを考えるとJavaScriptを無効にしているユーザーはかなり少ないと思われることから、それほど深刻な問題でもありません。 それよりもTableレイアウトに戻されたときの代償は非常に大きいと思います。 みなさんはこのことについてどう思われますか?

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 08 14:36
投稿者: Ivy

WordPress, XOOPS Cube でも、CSSレイアウトのレスポンシブWebDesignによるテーマが標準テーマとして採用されているという状況で再び10年も前に、しかたなくはやったテーブルレイアウトに回帰する理由はどこにもありません。 JavaScript無効にして使いたいなら、それ用のテーマを別途提供されていれば解決することであり、標準テーマで対応させる必要はありませんので、すぐ本家MLで、反対を表明しましょう。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 08 15:27
投稿者: Tani_KK

Javascipt-Off時のレイアウトの乱れも無いにこしたことはない。 でも、レスポンシブにできるならしたほうがよい。 とは思います。 で、Tableレイアウトの良し悪しを議論するよりは、Javascript-Off時でも レイアウトの乱れない方法を提案するほうが建設的かと思います。 具体的な妙案はありませんが、例えば &ltnoscript&gt&lt/noscript&gtでtableタグを 出力しておいて、Javascrip-Onなら本来の(Table以外の?)タグを出力させる等の 方法も取れるのではないのでしょうか? 素人案ながら、ひとこと。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 08 18:12
投稿者: dengen

Quote by: Ivy

WordPress, XOOPS Cube でも、CSSレイアウトのレスポンシブWebDesignによるテーマが標準テーマとして採用されているという状況で再び10年も前に、しかたなくはやったテーブルレイアウトに回帰する理由はどこにもありません。 JavaScript無効にして使いたいなら、それ用のテーマを別途提供されていれば解決することであり、標準テーマで対応させる必要はありませんので、すぐ本家MLで、反対を表明しましょう。

WordPress, XOOPS CubeではレスポンシブWebDesignによるテーマを標準採用というのは知りませんでした。 これらのCMSはニーズを的確に把握して対応しているように思います。 それ以前に今時Tableレイアウトのテーマを標準にしているCMSが他にあるんでしょうか。 ユーザーがJavaScript無効にしたときにレイアウトの崩れがないに越したことはないので、本家で反対を表明する場合に代案がほしいところです。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 08 18:41
投稿者: dengen

Quote by: Tani_KK

Javascipt-Off時のレイアウトの乱れも無いにこしたことはない。 でも、レスポンシブにできるならしたほうがよい。

レイアウトの乱れを問題ないとは言えないですね。 レスポンシブデザインが出来るのはCSSレイアウトの柔軟性があってこそなので、CSSレイアウトを捨てることはできないと思います。
Quote by: Tani_KK

Tableレイアウトの良し悪しを議論するよりは、Javascript-Off時でも レイアウトの乱れない方法を提案するほうが建設的かと思います。

はい。実はこの話題を立ち上げたのは、この提案を導き出すことを意図していました。
Quote by: Tani_KK

具体的な妙案はありませんが、例えば <noscript></noscript>でtableタグを 出力しておいて、Javascrip-Onなら本来の(Table以外の?)タグを出力させる等の 方法も取れるのではないのでしょうか?

あまり現実的ではないように思います。仮になんとかできてもかなり無理をすることになりそう。 HTMLコードもかなり読みづらくなるので、テーマ開発者には敬遠されるでしょう。 そもそもTableレイアウトを取り入れている事自体、本家の対応と大差が無くなってしまいます。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 08 20:39
投稿者: mistgrass

こんばんは、ミストグラスです。 いつもすばらしいテーマを提供いただきありがとうございます。 テーマをいじらせていただく場合、テーブルレイアウトは個人的に大変いじりにくく感じます。 また、美しくない。 また、dengenさんもおっしゃっているように、現在JavaScript オフの環境はそうそうでないのではないかと思いますので、そこに重点を置くことに疑問を感じます。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 09 03:02
投稿者: dengen

ミストグラスさん、ありがとうございます。自分と同じ意見をいただけると勇気が湧いてきます。 本家はJavaScriptオフ時にレイアウトが乱れることのほかに、既存サイトがスムーズにアップグレードできるように互換性を重視しているのでしょう。 実は互換性を損ねても良いなら、解決方法があります。 professional_cssのJavaScriptコードで行なっていることを、サーバーサイドつまりPHPで行えば解決します。 ここで、GeeklogのCOM_siteHeader関数とCOM_siteFooter関数が問題になります。 HTMLを生成する際、bodyタグにレイアウト情報を含めたクラス名を与える処理を、COM_siteHeader関数内で記述すれば良いのですが、COM_siteFooter関数の計算結果を見ないとレイアウトの(2カラムか3カラムかの)判定ができないというジレンマが存在してうまく行かないのです。 Tableレイアウト時代においては、COM_siteHeaderとCOM_siteFooterには何も問題は無かったのですが、現在のCSSレイアウト時代においては不都合が生じているという状況です。 COM_siteHeaderとCOM_siteFooterを統合してしまえば問題は解決します。でもそうするとCOM_siteHeaderとCOM_siteFooter使っているコードを全部書き換える必要がでてくるので大変な影響があります^^; しかし、私もいろいろ考えてみたのですが、COM_siteHeaderとCOM_siteFooterの統合しか解決方法はないだろうと思っています。 実は先程まで作業をして、GeeklogのCOM_siteHeaderとCOM_siteFooterを新たに作成した統合関数で全て書き換えてみました。 これでJavaScriptをオフにしてもレイアウトは崩れません。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 09 10:18
投稿者: kitani

デザイン・レイアウトについては素人なのですが、
JavaScript OFFの時には、携帯テーマが出るなど、箇条書きしかでないようにしてしまえばいいのではないかなーと思います。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 09 12:01
投稿者: Tani_KK

Quote by: dengen

本家はJavaScriptオフ時にレイアウトが乱れることのほかに、既存サイトがスムーズにアップグレードできるように互換性を重視しているのでしょう。 実は互換性を損ねても良いなら、解決方法があります。 (省略) 実は先程まで作業をして、GeeklogのCOM_siteHeaderとCOM_siteFooterを新たに作成した統合関数で全て書き換えてみました。 これでJavaScriptをオフにしてもレイアウトは崩れません。

この書き換えが、COM_siteHeaderとCOM_siteFooterの中身だけを書き換えている という話ならば、後方互換を維持した状態で十分修正可能と思います。 もともと[theme]_siteHeaderと[theme]_siteFooterは用意されていますが、これだと名前を変える毎にfunctions.phpの関数名も変えないといけないので標準としては不向き。 ならば、ひとつフラグを立てて、Tabale_siteHeader/CSS_siteHeaderなどの切り替えをlib-commonに仕込んでやればいいのではないでしょうか? functions.phpでCSSレイアウトならフラグをセットし、そのフラグがtrueならばCSS_site... を使用、そうでなければTable_site... を 使用等です。 いかがでしょう?

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 09 20:47
投稿者: dengen

Quote by: kitani

デザイン・レイアウトについては素人なのですが、 JavaScript OFFの時には、携帯テーマが出るなど、箇条書きしかでないようにしてしまえばいいのではないかなーと思います。

kitaniさん、コメントありがとうございます。 でもごめんなさい。「携帯テーマ」や「箇条書きしかでないように」の意味がよく分かりませんでした。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 09 20:50
投稿者: dengen

Quote by: Tani_KK

この書き換えが、COM_siteHeaderとCOM_siteFooterの中身だけを書き換えている という話ならば、後方互換を維持した状態で十分修正可能と思います。

中身を書き換えるだけではだめでした。 COM_siteHeaderとCOM_siteFooterを足しあわせたようなCOM_createHTMLDocumentという関数を作成しました。
Quote by: Tani_KK

functions.phpでCSSレイアウトならフラグをセットし、そのフラグがtrueならばCSS_site... を使用、そうでなければTable_site... を 使用等です。 いかがでしょう?

はい。同じような方法で切り替えができるようにしました。 つまり、テーマのfunctions.phpでフラグを立てて、それにより処理を分岐させる方法です。 COM_createHTMLDocument関数内でフラグをチェックし、古いテーマであれば、従来のCOM_siteHeaderとCOM_siteFooterをコールします。 後方互換性を確保するため、しばらくはCOM_siteHeaderとCOM_siteFooterは併存させます。 当面の問題は、CSSレイアウトの新テーマとCOM_createHTMLDocument関数に対応していないプラグインの組み合わせでは、当然のことながらレイアウトが崩れること。センターブロックだけのレイアウトになります。 でも、これはプラグイン開発者に対応版を出してもらえれば、次第に解決していくと考えています。 このシナリオを本家がのんでくれないかなぁ。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 10 10:04
投稿者: mistgrass

Quote by: dengen はい。同じような方法で切り替えができるようにしました。 つまり、テーマのfunctions.phpでフラグを立てて、それにより処理を分岐させる方法です。 COM_createHTMLDocument関数内でフラグをチェックし、古いテーマであれば、従来のCOM_siteHeaderとCOM_siteFooterをコールします。 後方互換性を確保するため、しばらくはCOM_siteHeaderとCOM_siteFooterは併存させます。 当面の問題は、CSSレイアウトの新テーマとCOM_createHTMLDocument関数に対応していないプラグインの組み合わせでは、当然のことながらレイアウトが崩れること。センターブロックだけのレイアウトになります。 でも、これはプラグイン開発者に対応版を出してもらえれば、次第に解決していくと考えています。 このシナリオを本家がのんでくれないかなぁ。[/p]
動作の軽さ等にも関係するかと思いますが、すばらしい提案だと思いますので、本家が受け入れてくれることを大いに期待します!

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 10 12:19
投稿者: keithr

皆さん、こんにちわ。 dengenさん、あのテーマとこのプラグイン、それにあれもこれも、いつも本当にお世話になっています。 私には本家を説得する妙案がないのですが、この問題が提起されてから英語でこの問題はどのように議論されているのかを検索してtable擁護派の記事を探しては読んでいます。英語の世界でも圧倒的にcss擁護派が優勢ですが、table擁護派はそれなりに強固な意思を持っているのが分かります。 AmazonやGoogle shoppingが今でもtable使っていることが結構彼らの支えになっているようです。 http://stackoverflow.com/questions/83073/why-not-use-tables-for-layout-in-html http://www.rhyous.com/2012/02/01/table-layouts-still-win-over-css-layouts-in-2012/ 環境を超えて最も正しく表示できるのは今でもtableなんだ、cross browser問題も少ないし、ってことなんですね。 私もdengenさんの取り組み、Geeklog Japaneseがcustom_cssでずいぶん前から脱tableレイアウトを推進してきたことを感謝し支持する一人です。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 10 21:21
投稿者: dengen

Quote by: mistgrass

動作の軽さ等にも関係するかと思いますが、すばらしい提案だと思いますので、本家が受け入れてくれることを大いに期待します!

ありがとうございます。 動作の軽さについては、lib-common.phpが肥大化しますが、今のところ体感できるほどの変化はありません。 COM_siteHeaderやCOM_siteFooterをlib-common.phpの外に置き、必要に応じてインクルードするなど最適化すると良いかもしれません。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 10 21:22
投稿者: dengen

Quote by: keithr

私には本家を説得する妙案がないのですが、この問題が提起されてから英語でこの問題はどのように議論されているのかを検索してtable擁護派の記事を探しては読んでいます。英語の世界でも圧倒的にcss擁護派が優勢ですが、table擁護派はそれなりに強固な意思を持っているのが分かります。

keithrさん、情報ありがとうございます。 個人的にCSSとTableは比較の対象でさえなくて、table擁護派の主張を追う気にはなれませんが^^; ただ、professionalのように左右のサイドバーがフッターにきっちりくっついているスタイルはHTML4以前ではTableレイアウトでしか実現できないです。(多分) これもHTML5のレイアウト関連タグでは可能なので、いよいよTableをレイアウト用に使う理由はなくなるでしょう。 Tableは表形式のデータを扱うためのもので、視覚効果のために用いるのは間違いです。 私はよくサイトのソースコードを確認しますが、もうTableレイアウトに遭遇することはほとんどなくなりました。 AmazonやGoogle shoppingも一見するとTableレイアウトではないようですが・・・?

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 11 14:50
投稿者: aiger

皆さんの意見を読んで、 技術的には特段言及できることはないのですが、 1点あげるとすれば、 今後Geeklogの開発者を増やす、裾野を広げるという 観点では、 TABLEレイアウトのような 時代遅れの仕組みだと、がっかり感で、 新しく使ってみたいという人も増えていかないと思います。 Geeklog普及のためにも、 CSSにあわせていったほうが良いと思ってます。 オープンソースのCMS比較一覧表なんかで、 GeeklogはTABLEレイアウトとか、もし書かれると 他と比較しても印象がよくないですよね・・・。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 12 08:44
投稿者: mistgrass

Quote by: dengen

ただ、professionalのように左右のサイドバーがフッターにきっちりくっついているスタイルはHTML4以前ではTableレイアウトでしか実現できないです。(多分) これもHTML5のレイアウト関連タグでは可能なので、いよいよTableをレイアウト用に使う理由はなくなるでしょう。 Tableは表形式のデータを扱うためのもので、視覚効果のために用いるのは間違いです。

Tableレイアウトより、HTML5レイアウトのテンプレートを増やしていく方がいいと思えます。 未対応のブラウザ、プラグインへの問題等いろいろあるかもしれませんが…。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 15 15:02
投稿者: augebang

ご無沙汰しております、Augebangです。 代案が思いつかなかったので書き込みを躊躇しましたが意思表示として明記します。 I'm against back to Table layout. professional_cssをベースとしGeeklog2.0の新デフォルトテーマを作られることは非常にうれしい話です。しかしJavaScriptが無効の際の挙動のためにTableレイアウトを採用する事には強く反対します。 反対理由はdengenさんをはじめ多くの方が書かれている通りで 1)「JavaScriptが無効の場合」が昨今の時流を考えたら考えにくい。 2)そもそもTableレイアウトを採用するのであればprofessional_cssをベースにする必要は無い。 3)「JavaScriptが無効の場合」を強く考えるのは親切設計ではあるが、そうであればTableレイアウトに戻さず代案を考えるべき。 だと私は考えます。 代案については以前1.4.1の頃JavaScriptが無効の場合の対策は無いのか質問した際、PHPで制御できるともお聞きしました。自分なりに探ってみましたが解決策が見つからず今に至っています。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 16 22:23
投稿者: dengen

mistgrassさん、 HTML5とモダンブラウザ(IEなら9以降?)が当たり前の時代が早く来れば良いですよね。IEを無視すればもう来ている?w aigerさん、ご意見ありがとうございます。
Quote by: aiger

TABLEレイアウトのような時代遅れの仕組みだと、がっかり感で、 新しく使ってみたいという人も増えていかないと思います。

全く同感です。印象がどのように伝わるかががとても大事なんです。 augebangさん、ご意見ありがとうございます。 急遽作成した代案を本家のメーリングリストに投げてみました。そして、Tableレイアウトの廃止を訴えました。 すると、昨夜から良い兆しが! 本家で開発が進められている新テーマの開発者Rouslanさんから、CSSレイアウトに戻したという旨のレスが返ってきました! 今後の動向に注目していきたいと思います。 なお、同メーリングリストへTani_KKさんから投稿されたメッセージが提案の一つのきっかけになりました。 Tani_KKさん、ありがとうございました。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 17 18:43
投稿者: Tani_KK

Quote by: dengen

mistgrassさん、 HTML5とモダンブラウザ(IEなら9以降?)が当たり前の時代が早く来れば良いですよね。IEを無視すればもう来ている?w

自分の勤めている会社、未だにIE6縛りなのですが。。。 Cry
Quote by: dengen

なお、同メーリングリストへTani_KKさんから投稿されたメッセージが提案の一つのきっかけになりました。 Tani_KKさん、ありがとうございました。

いえいえ、単に思ったことを投げたまでです。ビッグマウスの道化師っぽくやってみたかった Cool けど、英語の能力足らなかったようです。 Cry なにはともあれ、よい方向へ向かいつつあるようで良かったですね。

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 17 20:26
投稿者: Ivy

Tableレイアウトのまま踏みとどまるようなら多くのユーザから見放されることは必至でした。 Geeklog Japanese として、もしそうなるのなら、残念ながらForkするしかないという決意をMLで表明しました。 その後、テーブルがリポジトリから消され、積極的なdengenさんからの働きかけてTableレイアウト以外の数々の問題が議論されているところです。 今が正念場ですから、がんばりましょう Smile

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 19 03:08
投稿者: Ivy

新2.0では、新テーマNewproのスタイルシートにstyle.css.phpが使われるようになりました。ブラウザの要素確認機能で、スタイルのファイル名がすべてstyle.css.phpになってしまい、要素確認が直感的でなくなってしまうのでテーマ開発に支障がでるのではないかと、dengenさんから問題が提起されていました。 そこで、style.css.phpの性能を確認するため、最新のバージョンをインストールして新旧2サイトを比較。さらに最新のバージョンの3テーマを比較したところ、2.0になって、サイトが速く表示されるようになっていますが、style.css.phpによる高速化の効果は出ていないようです。 【1】 2.0開発最新版(Geeklog-ede42628dc11)をテストインストール: ログアウト時のトップページの表示:Created this page in 0.08 seconds 3テーマによる表示スピード変化なし (Newproのみstyle.css.php 他のテーマは通常。Professional_cssは通常のCSS構成) 【2】 1.8.1 demoサイト http://demo.geeklog.jp/ コアプラグインのみ有効に。他はアンインストール。 ログアウト時のトップページの表示:Created this page in 0.11 seconds

書込: 次期Geeklog2.0のTableレイアウトの新テーマについて

投稿日: 24 04:38
投稿者: Ivy

style.css.phpの効果は、下に表示された時間の後、表示するスピードに関係するので、計測結果はまちがっていることがわかりました。style.css.phpの効果はおそらくあるのでしょう。 さて、テーブル組みのテーマに対して強力に反対を訴えた結果テーブル組みが消え、また、DengenさんのGeeklog2.0でのレシポンシブウェブデザインDenimの開発から、Dengenさんがコアの開発者に迎えられて、DengenさんのレスポンシブウェブデザインのテーマDenimを含む開発の成果がGeeklog 2.0に取り込まれることになりました。 DengenさんのがんばりとDirkさんの調整と応援していただいたみなさんに感謝。 これでGeeklogは、レスポンシブウェブデザインがデフォルトのテーマとなって、Geeklog 2.0が来月から再来月にかけてお目見えすることになる予定です Exclaimation

Geeklog Japan - 掲示板
https://www.geeklog.jp/forum/viewtopic.php?showtopic=17526