はたしてW3Cに準拠することだけが正しいやり方なのか、以前から私は疑問に感じていました。現状でブラウザが完全対応していない以上、ある程度の「裏技」を使うことは常識化しています。W3Cを厳密に守る方にはこうした臨機応変な対応が「汚いコード」として目に映るようです。
W3C準拠派、臨機応変派に分かれて議論をお願い致します。
==========参考リンク==========
『趣味のWebデザイン（備忘録） ――テーブルレイアウト排斥の根拠薄弱について――』
http://deztec.jp/design/05/02/20_table.html
『カナかな団の躁鬱 ――所謂正しい HTML――』
http://www.aboutworks.com/shokodei/diary/2005/2005_01_a.html#PrintNo1
『InternetWatch ――W3C会員サイト、HTML標準に準拠しているのはわずか4.6％
～Webデザイナーが独自調査結果を発表――』
http://internet.watch.impress.co.jp/www/article/2002/0826/marko.htm
『PC Tips ――HTML、CSS、そしてWindows――』
http://members.jcom.home.ne.jp/pctips/
※↑ややプライドが高い雰囲気をにじませる作者。他サイト批判も堂々と行っている。
『ORE.CSS 2nd EDITION』
http://orestyle.hp.infoseek.co.jp/second/check.7.html
59 pt / 500 pt
ツリー表示 | 新着順
ElekiBrain
nipoxてっきり、非推奨のタグだと思って、今まで使ってきませんでした。
あるひ、タグ辞典を見て驚いたものです。
まぁ、CSSのほうが細かく設定できるのでどちらにしてもこっちを使いますけれど。
ElekiBrain<table border="1" cellspacing="5"></table>
とかのことでしょうか？ これをStrictで使えるのはおかしい、という意味で捉えましたが、そういうご意見だったのでしょうか？
そうしたご意見でしたら私もそう思います。確かにこれはCSSで代用できますね。
すみません。文章をよく読むべきでした。
nipoxテーブル自体は、絶対必要です。
なんでStrictなんだ？
といっているのは、border等の属性のことです。
ElekiBrain>廃止予定になっているべき
これはなぜそうお思いでしょうか。テーブルはレイアウトの一環として使う以外に、単なる表としてその価値を持続させてゆくものと私は考えるのですが。
>なんで、Strictなんでしょう。
失礼します。これはどこのことを仰っているのでしょうか。申し訳ありませんが、お聞きしたいのですが。
ElekiBrain>特に、これからblogのカスタマイズなどからWebデザインを勉強する人などは、CSSでコーディングするのが当たり前になってくるんじゃないでしょうか。すると、ブラウザ各社やW3Cにもそういった圧力がいくのではないか、と（素人的な意見で申し訳ありませんが）
私も素人ですので、お気になさらず、ガンガン発言していただいて結構です。
この件に関してですが、もちろんCSSは今後より標準化してゆくものと思われます。しかし、テーブルはレイアウトとは別の側面で、単なる表としての価値を残して残存するのではないか、とするのが私の考えです。
>ただ、IT絡みの専門学校では、まずtable layoutから勉強するみたいなんで、そのへんがどう変わっていくかは疑問ではありますけど。
これ、そうだったんですね。知りませんでした。実際には「ドリームウィーバー」などで表組みを作っておいて、そこから細かなコーディングをやって行く人が多いので、こういった流れになったのかもしれません。
多分、綺麗なコードよりも、金になる技術を優先しているのかもしれません。確かに「ドリームウィーバー」で表をあらかじめ決めておいた方が生産性の一点においては向上しますしね。
ElekiBrainXMLにてbrが出来ない、という事に一部で反論が起こりそうなのでちょっとした訂正を。XSLを介したXMLを表示する際、XSL内で表記したbrは普段どおりに使うことが出来ます。また「XSL+CSS+XML=表示」とする場合、この場合はXSLにbrを書くことが出来ますから、これも可能です。ところが、CSSを介したXML内ではbrは無視されます。CSSで直接見栄えを調整した、やや変化球のXMLも書くことが出来たので、色々と実践してみたのですが、IEとFirefoxの間にすさまじい表記の差異が発生しました。brもそうですが、透過GIFスページングなどもIEは対応しており、Firefoxは対応していないなど（逆だったかな）、他にもかなりの開きが見られました（まあ、スペーシング等といういかにも旧時代のレイアウトを試す必要性は余りないのですが）。
以上全くの余談です。
ElekiBrain>それらのサイトすべてで自動でRSSを配信しろといっても無理な話ですから、HTML自体をXML準拠(ここではXHTML)にすることで、より簡単な情報配信が行えるのではないかな、と思うわけです。
それはそうかもしれません。著作権のことに関しては、YouTubeのように、やや著作権に抵触しているものの、ユーザーのニーズにより後押しされ、順調な成長を遂げていますし、著作権ありきで考える時代ではないかもしれません。最近の傾向として、無料でコンテンツを配布し、そこから発生する広告収入で企業利益を上げる、という形態がメインになってきていることを考えるならば、まず著作権に目くじらを立てることよりも、コンテンツ配信方法としてのXMLがより発展する方向性で考えた方がインフラ全体としての利益に繋がるのかもしれませんね。
>XHTML自体を暗号化するとか、あるいは文章全体を画像にしてしまうなど、コンテンツを保護するための対策は必要であるかと思います。
これは難しい話ですね（否定ではありませんよ）。例えばJavascriptをコンパイルして、中身を暗号化するアプリケーションがMicrosoftから無料配布されていると聞いたことがあります。しかしコンパイルされたJavascriptはIEでしか表示できず、仮に全てのブラウザが対応したとしてもリコンパルするアプリケーションが巷にあふれるでしょうから、余り意味はないことになってしまいます。これは現在のFlashにもいえることです。Flashは近年まで、ダウンロードしようとしても落とせないメディアであり、かつリコンパイルもできないものとされてきました。しかしこの現状は変わりつつあります。最近では簡単にダウンロードできますし、リコンパイルして違法に配信することも簡単に出来てしまう時代です。幸いなことにそれをやる人間がそれほどいないために、問題は表面化していません。XHTML・XMLを暗号化する事に関しては私も前々から興味がありました。これを各社が実装してくれるならば、XHTML・XMLは素晴らしいインフラとして世に定着することでしょう。コンパイルすることによってのコンテンツの高速化も見込めます。ただし、この件に関しても前述したFlashと同様の事態が発生することは間違いなく、こうした著作権保護とコンテンツの利便性は天秤の両端で揺れ動くことになるでしょう。
ユーザーのニーズと企業努力の両方が必要になる、非常に難しい問題です。
blackdocuro層化学会がこれにあたります。
ratbeta>>むしろ、このことが問題になっているような気がしてなりません。コンテンツの著作権とも絡んでいますので、むしろXHTMLを正確に記述することが不利な条件を生んでしまうこともあろうかと思います。
確かにそのとおりです。
他人のページを勝手に加工し表示するのは問題であるという議論は以前からあります。
しかしながら、例えばツールの更新情報を掲載する場合など、
他のページでの表示が行われたい場合というのも少なからずあります。
# はてなアンテナがXMLパーサを搭載したような感じでしょうか。
少なくとも現状では、すべてのサイトがRSSを配信しているわけでも、
あるいは外国で用いられているXML-PADなどの手法を用いているわけでもありません。
個人サイトでは未だに手書きの(ソフトを利用したものも含む)サイトの割合の方が恐らく高いはずです。
それらのサイトすべてで自動でRSSを配信しろといっても無理な話ですから、
HTML自体をXML準拠(ここではXHTML)にすることで、
より簡単な情報配信が行えるのではないかな、と思うわけです。
その手の情報配信/宣伝などは、むしろ個人サイトのほうが必要としていると私は思います。
なお、著作権を必要とするコンテンツについては、
現状でもphpなどを用いて抽出させれば簡単に加工できてしまいますから、
やはりXHTML自体を暗号化するとか、あるいは文章全体を画像にしてしまうなど、
コンテンツを保護するための対策は必要であるかと思います。
ratbeta確かにxmlと書かれていましたね。読み違えていました。
>>今後XHTMLからXMLへと全ての文章が変わってゆくとする極端な人たちの話
XHTML自体がXMLに準拠している以上、XHTML自体がXMLであり、
よほどデータ重視のページでない限りは全体をXMLにすることは難しいでしょうし、
ましてすべてを(XHTMLでない)XMLにするということの必要性も私には分かりかねます。
# 余談ですねorz
ratbeta>>文章を記述するという(X)HTML本来の目的には適合しません。
という表現は、今読み返してみても確かに間違っているような気がします (^^;
まあ、あまり意味が無いですが訂正しておきます。
「意味定義に基づく文書記述を行うXML/XHTMLの目的とは必ずしも適合するとはいえません」
という感じにでもしておきましょうか。
HTML 4.01でもフレームはFramesetという形で規定されていますからね。
その点では特に異論がありません。bとかiとかのように、
HTMLをXHTMLに洗練していく中でフレームも除外されたわけですから。
さて、擬似フレームについてですけれども。勿論方法としてはそれだけでなくて、
仰られるようにxml+xslを使用するとか、いろいろありますけれども、
例えば多少の負荷を気にしない場合には、php/ssiなどを用いて動的に出力するとか、
あるいは、自動編集ソフトなどを用いてコピー/貼り付けの手間を減らすとか、
それ以外にも、TOCのような別の機構を用いるなど、いろいろな表現方法があります。
それはまあ、各個人が一番便利な方法を用いることでしょう。
もしどうしてもというのであれば、フレーム構成を記述したページのみをHTML4.01Framesetとして、実際のページをXHTML1.0にするなどでも良いと思います。
nipoxborder属性や、cellspacingなど、見た目に関するものがたくさんありますが、
半分くらいは、StrictDTDで使えます。
これはどう考えても表のスタイルだから、
廃止予定になっているべきだと思うのですが、
なんで、Strictなんでしょう。
せめて、Transitionalにするべきです。
nipox僕のサイトでは、検索エンジンから来たときに、
反対側のフレームを見失わないように、
JavaScriptを使って、片方のフレームがない場合は、
トップに戻させています。
インラインフレームは画期的ですが、
フレームのようには使いにくいと思います。
nipoxテーブルの中にテーブルというのは、
表の中に表という意味なので、
意味不明になります。
余分に、tr・tdを書くことになり、
DIV以上にファイルサイズも大きくなります。
harumomo2006divの中にdivが多段式で作られるのはわかりますが、tableの中にtableが多段式で書かれてあると収拾付かなくなります。
harumomo2006廃止する前準備としてフレームを切り離したのではないでしょうか。
あらた独学で、Web制作を学んできた人間です。
少し横槍になってしまいますが、独学で学んできた人間にとって、CSSレイアウトが当たり前で、table layoutは逆に一切できません。CSSとXHTMLでvalidなコードを書けるようになってから、table layoutがあるんだってことを知ったくらいですので。
特に、これからblogのカスタマイズなどからWebデザインを勉強する人などは、CSSでコーディングするのが当たり前になってくるんじゃないでしょうか。すると、ブラウザ各社やW3Cにもそういった圧力がいくのではないか、と（素人的な意見で申し訳ありませんが）
ただ、IT絡みの専門学校では、まずtable layoutから勉強するみたいなんで、そのへんがどう変わっていくかは疑問ではありますけど。
ElekiBrain私もフレームそのものを最近は使いません。しかし、闇雲に
＞文章を記述するという(X)HTML本来の目的には適合しません。
とするのはいかがなものでしょうか。それこそブラウザベンダー側の対応そのものであると思います。そんなに間違っているならば、各社がこぞってW3Cの策定に従い、すぐにでも廃止にすべきだと思います。しかしそれは実現しないでしょう。フレームを使ったページも多く存在する現状があるからです。
また、CSSによる擬似フレームに関しては、実装にブラウザの差異が相当あるため、一般的に用いられているのを見たことがありません（少なくとも日本では。ただし、擬似フレームは個人的には好きな方法です）。特にposition:fixed;にIEが対応しないばかりに、overflowを使って代替しなければならないなど、非常に面倒です。
さらに、（私は使ってませんが）フレームの利点もあるとは思います。左側にサイトのナビゲーション（メニュー）を採用している場合には、HTMLごとにコピー＆ペーストでメニューなどを追加する手間が省けます。私はフレームを使わずにこの手法を実践すべく、xmlにてナビゲーション部分をパーツ化し、各種ページ（xsl）に呼び出す実験をしてみたことがありますが、面倒なことこの上なく、生産性が向上する感触はありませんでした。メニューが余程膨大でない限りは実装すべきではない、との感触を得たのです。
そんな時の代用方法として、フレームをやむなく使う方もいらっしゃるかと思います。
ElekiBrain＞ただ、携帯では、tableを認識しないものもあるし、絶対思ったとおりに見せたいとなるとPDFにしろ、とかいうことになりかねないかなあとも思います。
確かにそうですね。tableがダメな場合は別の方法で代用すればいいかな、というぐらいです。私はCSS至上主義でもtable至上主義でもありませんので。ただ、PDFはどうなんでしょう。ここは難しい判断ですよね。『Adobe Reader』の「もっさり」起動でPDFが起動すること自体が嫌な人もいますしね……。
＞デフォルトでの解釈もブラウザによって若干違ったりしませんか？
これは皆さん感じてらっしゃることだ思います。私はブラウザ初期CSSは初期化することにしていますが、この話の流れだと（CSS非対応の話だと）それも無益、ということになりかねませんね。だからこそある程度の妥協は必要なのかもしれません。
＞折角「正しい」HTMLを書いても、やっぱり見られなければ本末転倒のような気がします。
全くその通りだと思います。私はその意見には賛成です。
23
22
AjaxはFlashから使うことも出来ますし、補完関係になりやすいため、どちらが良いか、という意見にはならないと思い、このような形にしました。
しかたがって、議論のルールは「JvavascriptとCSSでDHTMLに動的な仕掛けを作るサイト」vs「全てFlashで形成されたフルFlashサイト」と致します。どちらがどう優れているか、あるいは問題点などを議論してください。例えば、使い方にもよるが、実際の動作・表示面ではどちらが重いか、など（悲しいかな、グラフィカルな表示を多用すればどっちも重いですけどね……）。
下にツリーを連ねていってください。