人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

W3C準拠派 vs 臨機応変派に分かれて議論をお願います。
はたして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

●質問者: ElekiBrain
●カテゴリ:コンピュータ ウェブ制作
✍キーワード:CSS HTML pc TIPS W3C
○ 状態 :終了
└ 回答数 : 45/45件

▽最新の回答へ

[1]テーブルに関する議論はこちらから ElekiBrain

下にツリー連ねていってください。


[2]フレームに関する議論はこちらから ElekiBrain

下にツリー連ねていってください。


[3]XHTML1.1にやがて進むとされているが、そうは思えない。 ElekiBrain

私はせいぜい XHTML1.0 Transitional で打ち止めではないのかと思います。簡単に記述できたからこそHTMLは普及しましたが、厳密な1.1は一般受けしません。こうした流れは

http://deztec.jp/design/05/02/20_table.html

にも見られるように、一部のギーク(マニア)が言っているに過ぎないことだと思います。

各ブラウザの独自拡張を取り入れながら整然と策定し直すならまだしも、まだ使うタグを次々と取り除いてゆくW3Cの姿勢には納得が行きません。

やがて全ての文書表記がxmlになるとする人もいるようですが、<br />もつかえない不便なxml・xslがwebページとして標準化するとは考えにくいと思っています(xml・xslを散々試した結果こうした発言をしています)。


[4]「divの使いすぎは構造的ではない」 vs 「divを大量に使うことがなぜ構造的ではないのか」 ElekiBrain

下にツリー連ねていってください。


[5]「全てCSSで見栄えを調整すべき」 vs 「CSS未対応に考慮すべき」 ElekiBrain

下にツリー連ねていってください。


[6]>2 Frameset DTDを宣言しておけば問題なし TomCat

要するに、基本が分かって書いているかどうかの問題なんだと思いますよ。ちゃんと分かって書いているなら、別にフレーム使ったっていいじゃないですか。

これをStrictにしておきながらフレーム使ってるとか、そういうハズカシイことさえ無ければ、私は何の問題もないと思いますよ(^-^)


[7]>6 ですね ElekiBrain

ブラウザ側ではW3Cが何といおうと対応しているわけですし。

といいつつフレームは使っていませんが(笑)

一応議論の対象となると思い、挙げているのです。

基本的に現在のHTMLは進化の途中ですから、W3C信者さんたちの極論が非常にマニアックに感じるわけです。わたしも「別に使ったっていいじゃないか」と思います。


[8]別に各自でテーマを決めてツリーを作っていっても構いません ElekiBrain

例がないと取っ掛かりにくいかと思い、各テーマを挙げてみました。

私が挙げたツリーのみしか回答できないわけではありません。

議論を自由に展開していってください。


[9]>4 テーブルを乱用するよりはましである nipox

テーブルをレイアウトに使うサイトがものすごい数があります。

テーブルは表のためのたぶですから、

テーブルは使う出来ではない!!

そうなると、divが非常に有用になります。

実際、DIVを何個も使ってみましたが、

テーブルよりもすっきりし、

かえって構造的です。

構造的でないというならば、

何を使えばいいのでしょうか。


[10]>6 しかしなぜW3Cは、フレーム用にDTDを作ったのか nipox

フレームも、Strictの中に入れるべきではないのでしょうか。

フレームは非常に画期的だと思います。

HTMLの意義にも反していないはずです。

SSIでは、サーバーに負担をかけます。


[11]>9 私もdivをよく使います ElekiBrain

そんなわけで、nipoxさんのご意見は分かります。


どうも、一部ではdivを一切使わず<p>等を駆使してレイアウトするのがクールなどという自己満足が蔓延しているようです。もちろん、<p>や<h1>などが有益であることは分かるのですが、そこまでdivを否定する意味はあるのか、と思うのです。

div病などという言葉まで登場する始末で、そんなに文書構造にこだわりたければ扱いずらいxmlでも使っていればいい、と思うのです(やや話が飛躍しますが)。


[12]W3C原理主義 vs W3C福音主義 TomCat

同じ宗教でも、原理主義と福音主義に分かれている所があります。

原理主義者はことあるごとに他の宗教を攻撃します。

でも福音主義者は、あらゆる人々に福音を、やんわりと良き知らせとして伝えて、広げていくことを重視します。

W3Cに適しているのは、後者じゃないですかね。たとえばテーブルを利用してレイアウトしている人には、こうすればソースが見やすくなるし、レイアウトの変更にも柔軟に対応できるし、といった利点を教えてあげるだけでいいと。そういうことです。

W3C原理主義者は、原理主義者同士でも論争します。ブログのサイドバーの付け方ひとつでも論争します。それはとてもハズカシイことだと思いますw


[13]>12 上記リンク先もそうですが、宗教論争に近い感じがあります ElekiBrain

W3Cをユーザーが勝手に経典化しているところがあり、洋の東西を問わず火種になっているようです。比較的リベラル(アバウト?)なコードの書き方をする私にとって、なぜそんなに目くじらを立てるのかが分からなかったわけです。実際の表示はさておき、

「文書構造が間違っているからすぐに直せ!」

とヒステリックにがなりたてる方々を見て、

「しゅ、宗教だ」

と思ったのは言うまでもありません。

まあ、結局ブラウザ各社が決めることじゃないか、なんて思ったりします。マーケティング的な側面から言えば、W3C自体がブラウザ戦争の歯止めになれば良いだけですし。


[14]>10 たしかに画期的ですが ElekiBrain

SEO対策には不都合らしく、かつ、検索エンジンから入ってきた人がトップページを見失うなどの問題もあるようです。私個人フレームを使用しませんので、そうした現象にぶち当たったことはないのですが。

W3CではDTDを作った割には非推奨としているのが、わけが分からない印象を生んでいる一因であると思います。


SSIに関してはまた議論が枝分かれするでしょう。SSIでも負担を軽減することはできる、とする人たちも存在するからです。その代わりにインラインフレームを用いることになるわけですが、これはこれで火種になっています。私個人は、フレームそのものはともかく、インラインフレームは許容してますので、なぜそんなに嫌悪されるのかが不思議です。反対派の意見もそれほど究極的にダメである理由ではないものばかり。


そんなわけで、インラインフレームが画期的だとする意見は私も同感です。


[15]>13 あるカルト教団のサイトで TomCat

やたらW3Cにこだわりまくっていたのを見たことがあります。で、宗教を妄信する体質の人はW3Cに対してもそうなのかー、と妙に納得してしまいました(^-^;

ま、W3Cは大切です。一人一人は、それをよく理解していく必要があります。でも、理解することとそれに従うことはまた別問題なんですよね。知ってて敢えて従わないというのもあるわけで、それは第三者に干渉される筋合いのものではありません。

ていうか、コンテンツの内容に凝れよ。何のためのサイトだよ、ってことの方が、正しい原理主義のあり方じゃないでしょうかねえ。と思うんですけどねえ。どんなもんでしょ(^-^;


[16]>15 W3Cはは、過剰でなければ学ぶ必要性がありますね ElekiBrain

>あるカルト教団のサイトで、やたらW3Cにこだわりまくっていたのを見たことがあります。で、宗教を妄信する体質の人はW3Cに対してもそうなのかー、と妙に納得してしまいました(^-^;

そうだったんですか。知らなかったです(笑)。生真面目なんでしょうね、きっと。


>知ってて敢えて従わないというのもあるわけで、

ここなんですよ、まさに。非推奨のタグや属性を盲目的に使うべきでないとする考えが非常に気になったんですね。


>ていうか、コンテンツの内容に凝れよ。何のためのサイトだよ、ってことの方が、正しい原理主義のあり方じゃないでしょうかねえ。と思うんですけどねえ。どんなもんでしょ(^-^;

多いんですよね。コンテンツの充実・レイアウトの華麗さを差し置いて厳格さを求める人たちが。なんか愚痴っぽくなってしまいましたが、なんだかデザイナーとコーダーの対立もここに集約されているような気がします。


[17]>5 うーん? yotaro

見栄えはともかく情報がきちんととれることを重視することが、見栄えをCSSで調整する(テーブルとか、spacer gifなんか使わない)ということだから、CSSで見栄えを調整=CSS未対応に(も)考慮とはならないですか?

テーブルとかで見栄えを調整されると携帯(SCOPEなど)やlynxなんかで見たときに見づらいことがあります。


[18]>13 準拠派として意見を ratbeta

例えば、タグを閉じ忘れたところで、HTMLでは大した問題は発生しませんし、

むしろHTMLではbrやimgなどのタグでいわば"閉じない"のが規定されていました。

HTMLでは私は別にそれで良いと思うんですが、XHTMLではそういうわけにもいきません。

XHTMLはHTMLであるというだけでなくXMLとしても成立しなければなりません。

XMLでタグ(という表現は適切でないですが)を閉じ忘れると文法違反であり、

巷に溢れるXMLパーサはすべてが読めないとエラーを返してきます。

XHTMLも同様に、閉じ忘れが許されませんから、文法違反はいけないだろう、と思うわけです。

もちろん、果たしてXHTMLをXMLパーサで解釈することなどあるのか、

ということを仰る方も居られるでしょうが、他の方が作成されたXHTMLから、

必要な情報を抜き出して自分のサイトに表示できるとしたら、

これは便利なことであると思われる方も居られるのではないでしょうか。


[19]>17 テーブル+CSS ElekiBrain

position:absolute;

position:relative;

などを使っている場合は非対応ではアウトだと思うのですが、いかがでしょう(この例はやや穿った見方かもしれませんが)。


テーブルを絶対ダメだという方がいるのはやや行き過ぎである感覚があるのです。特に携帯ではテーブルはまだまだ必要であると思います。CSS非対応の携帯ではレイアウトが崩れることも多く、それ以前に閲覧不可能であったりします。

私は何もCSSを否定しているわけではありません。むしろ、CSSの使い勝手には満足しています。しかし、それと同時にtableの便利さも知っています。特にWYSIWYGで簡単なテーブルを作成して後でHTMLエディタで整形する方法は今でも有効であると思いますし、CSS + tableの組み合わせもよく使います。生産性を考慮するならば、tableは排斥すべきものではない、と思うのです。また、近年のマシンスピードを考慮するならば、tableは問題ないとも思います。見づらさに関してもCSS側でテーブルを初期化すれば問題なく表示されるでしょう。


さすがにスペーサーに関しては私もあまり使いません。ただ、どうしてもline-heightやpadingでうまく行かない場合は簡単に出来る手法として採用しています。文書構造に極端にこだわらなければ別に構わないと思うのですが。


[20]>2 あれば便利ではあるけれども ratbeta

はっきり言って不要です。

単に目次とコンテンツを上下/左右に分けたいだけであれば、CSSを使えば代用可能です。

それ以上のことが必要である例を私は見た事がありません。例があれば私に教えてください。

少なくともフレームは、文章を記述するという(X)HTML本来の目的には適合しません。

HTML4.0Frameset以前の、フレームが規定されているバージョンならさておき、

XHTMLでフレームをどうしても使いたいならXFrames(http://www.w3.org/TR/xframes/)の普及などを待つべきです。

もちろん、ブラウザベンダー側も率先して対応すべきであると思いますが。


[21]>5 CSS未対応ブラウザ対策に対応していないブラウザを考慮すべき ratbeta

携帯電話であったりテキストブラウザではyotaroさんが仰るようにむしろ邪魔になります。

また、CSS対応ブラウザはこれから確実に減るでしょうが、

CSS未対応ブラウザ対策に対応するブラウザがこれから増加していくとは思えません。

先々にまで通用する文書を作りたいならば、CSSを用いるべきであると思います。


[22]>3 むしろ一般受けしないべきかも ratbeta

一般受けはしなくとも、blog作成スクリプトやCMSなどがXHTML1.1の出力に対応していれば良い話です。

もちろん、これからも手作りでXHTMLを書いていく人はいるかと思いますが、おそらくその数はこれから減っていくのではないでしょうか。

はてなでも用いられているようなワープロライクな操作で文書を編集し、XHTML自体は隠蔽されていく傾向が進むと思われます。

なお、XHTML1.1ではbrタグは使用可能です。

XHTML2.0で、lタグに代替される可能性があるようですが、それもスクリプト側で対応すればさほど難しいことではないと思われます。


[23]>18 xmlに関してですが ElekiBrain

>他の方が作成されたXHTMLから、必要な情報を抜き出して自分のサイトに表示できるとしたら、これは便利なことであると思われる方も居られるのではないでしょうか。

むしろ、このことが問題になっているような気がしてなりません。コンテンツの著作権とも絡んでいますので、むしろXHTMLを正確に記述することが不利な条件を生んでしまうこともあろうかと思います。


なお、私はxml・xslも何度もテストしたことがあるので分かるのですが、xmlは厳格すぎて、<br />などのちょっとした改行すらも許可してくれません(xmlをxslでなく、cssを通して解釈させた場合ですが)。今はxslを通してサイトを構築するという目的よりも、RSS等で自サイトを参照する程度のものが主流であり、xmlとxslを使ってサイト構築をする人は今後も少数であろうと思われます。それにRSSにしたところで、フレームワークやCGIなどを使ってコードを自動で吐き出させているものが殆どです。手書きで記述する人は殆どいないでしょう。

私が準拠に関してアバウトなのは、「個人サイトの範囲で準拠度を高くしても意味がない」からです。


[24]>19 ビジュアル重視かテキスト重視か yotaro

結局、私の場合は、レイアウト的なものをそれほど重視していなくて、テキストの内容を重視しているので、Markupの方が重要なのですが、意図した見栄えに拘るのであれば、tableもありなのかもしれません。ただ、携帯では、tableを認識しないものもあるし、絶対思ったとおりに見せたいとなるとPDFにしろ、とかいうことになりかねないかなあとも思います。

デフォルトでの解釈もブラウザによって若干違ったりしませんか?

割り切って、MSIEとmozillaやfirefoxやoperaあたりで見られればいいや、というのもそれはそれでありじゃないかと思います。仮にW3Cでvalidなサイトを作っても携帯だと文字コードが通らないということもあるので、折角「正しい」HTMLを書いても、やっぱり見られなければ本末転倒のような気がします。

まとまりなくてすみません。


[25]>22 大まかな意見に賛成です ElekiBrain

>なお、XHTML1.1ではbrタグは使用可能です。

ここだけちょっと補足。文章をよく読んでいただけてればご理解できるかと思われますが、XHTMLでなくXMLの例を挙げているのです。XHTMLではもちろんbrは可能です。今後XHTMLからXMLへと全ての文章が変わってゆくとする極端な人たちの話に対する反論です。


>はてなでも用いられているようなワープロライクな操作で文書を編集し、XHTML自体は隠蔽されていく傾向が進むと思われます。

そう思います。今後はローカルHTML編集にしても、直感的なアプリケーションによる開発が定着して行くと私も感じております。こういったマニアックな議論はだんだんとされなくなって行くかもしれません。


[26]>24 やはり臨機応変が適当なような気がしますね ElekiBrain

>ただ、携帯では、tableを認識しないものもあるし、絶対思ったとおりに見せたいとなるとPDFにしろ、とかいうことになりかねないかなあとも思います。

確かにそうですね。tableがダメな場合は別の方法で代用すればいいかな、というぐらいです。私はCSS至上主義でもtable至上主義でもありませんので。ただ、PDFはどうなんでしょう。ここは難しい判断ですよね。『Adobe Reader』の「もっさり」起動でPDFが起動すること自体が嫌な人もいますしね……。


>デフォルトでの解釈もブラウザによって若干違ったりしませんか?

これは皆さん感じてらっしゃることだ思います。私はブラウザ初期CSSは初期化することにしていますが、この話の流れだと(CSS非対応の話だと)それも無益、ということになりかねませんね。だからこそある程度の妥協は必要なのかもしれません。


>折角「正しい」HTMLを書いても、やっぱり見られなければ本末転倒のような気がします。

全くその通りだと思います。私はその意見には賛成です。


[27]>20 CSSで代用可能なのは存じています ElekiBrain

私もフレームそのものを最近は使いません。しかし、闇雲に

>文章を記述するという(X)HTML本来の目的には適合しません。

とするのはいかがなものでしょうか。それこそブラウザベンダー側の対応そのものであると思います。そんなに間違っているならば、各社がこぞってW3Cの策定に従い、すぐにでも廃止にすべきだと思います。しかしそれは実現しないでしょう。フレームを使ったページも多く存在する現状があるからです。


また、CSSによる擬似フレームに関しては、実装にブラウザの差異が相当あるため、一般的に用いられているのを見たことがありません(少なくとも日本では。ただし、擬似フレームは個人的には好きな方法です)。特にposition:fixed;にIEが対応しないばかりに、overflowを使って代替しなければならないなど、非常に面倒です。

さらに、(私は使ってませんが)フレームの利点もあるとは思います。左側にサイトのナビゲーション(メニュー)を採用している場合には、HTMLごとにコピー&ペーストでメニューなどを追加する手間が省けます。私はフレームを使わずにこの手法を実践すべく、xmlにてナビゲーション部分をパーツ化し、各種ページ(xsl)に呼び出す実験をしてみたことがありますが、面倒なことこの上なく、生産性が向上する感触はありませんでした。メニューが余程膨大でない限りは実装すべきではない、との感触を得たのです。

そんな時の代用方法として、フレームをやむなく使う方もいらっしゃるかと思います。


[28]>26 若い世代は、もうtabel layoutは使えない人も増えてくるんじゃないでしょうか。 aratako0

独学で、Web制作を学んできた人間です。


少し横槍になってしまいますが、独学で学んできた人間にとって、CSSレイアウトが当たり前で、table layoutは逆に一切できません。CSSとXHTMLでvalidなコードを書けるようになってから、table layoutがあるんだってことを知ったくらいですので。


特に、これからblogのカスタマイズなどからWebデザインを勉強する人などは、CSSでコーディングするのが当たり前になってくるんじゃないでしょうか。すると、ブラウザ各社やW3Cにもそういった圧力がいくのではないか、と(素人的な意見で申し訳ありませんが)


ただ、IT絡みの専門学校では、まずtable layoutから勉強するみたいなんで、そのへんがどう変わっていくかは疑問ではありますけど。


[29]>10 フレームは廃止予定だったような harumomo2006

廃止する前準備としてフレームを切り離したのではないでしょうか。


[30]>9 乱用に関しては同意 harumomo2006

divの中にdivが多段式で作られるのはわかりますが、tableの中にtableが多段式で書かれてあると収拾付かなくなります。


[31]>30 第一・・・ nipox

テーブルの中にテーブルというのは、

表の中に表という意味なので、

意味不明になります。

余分に、tr・tdを書くことになり、

DIV以上にファイルサイズも大きくなります。


[32]>14 検索対策 nipox

僕のサイトでは、検索エンジンから来たときに、

反対側のフレームを見失わないように、

JavaScriptを使って、片方のフレームがない場合は、

トップに戻させています。

インラインフレームは画期的ですが、

フレームのようには使いにくいと思います。


[33]>1 テーブルの属性は、見た目に関するものが多いのでは? nipox

border属性や、cellspacingなど、見た目に関するものがたくさんありますが、

半分くらいは、StrictDTDで使えます。

これはどう考えても表のスタイルだから、

廃止予定になっているべきだと思うのですが、

なんで、Strictなんでしょう。

せめて、Transitionalにするべきです。


[34]>27 そうですね。 ratbeta

>>文章を記述するという(X)HTML本来の目的には適合しません。

という表現は、今読み返してみても確かに間違っているような気がします (^^;

まあ、あまり意味が無いですが訂正しておきます。

「意味定義に基づく文書記述を行うXML/XHTMLの目的とは必ずしも適合するとはいえません」

という感じにでもしておきましょうか。

HTML 4.01でもフレームはFramesetという形で規定されていますからね。

その点では特に異論がありません。bとかiとかのように、

HTMLをXHTMLに洗練していく中でフレームも除外されたわけですから。

さて、擬似フレームについてですけれども。勿論方法としてはそれだけでなくて、

仰られるようにxml+xslを使用するとか、いろいろありますけれども、

例えば多少の負荷を気にしない場合には、php/ssiなどを用いて動的に出力するとか、

あるいは、自動編集ソフトなどを用いてコピー/貼り付けの手間を減らすとか、

それ以外にも、TOCのような別の機構を用いるなど、いろいろな表現方法があります。

それはまあ、各個人が一番便利な方法を用いることでしょう。

もしどうしてもというのであれば、フレーム構成を記述したページのみをHTML4.01Framesetとして、実際のページをXHTML1.0にするなどでも良いと思います。


[35]>25 言われたとおりです ratbeta

確かにxmlと書かれていましたね。読み違えていました。

>>今後XHTMLからXMLへと全ての文章が変わってゆくとする極端な人たちの話

XHTML自体がXMLに準拠している以上、XHTML自体がXMLであり、

よほどデータ重視のページでない限りは全体をXMLにすることは難しいでしょうし、

ましてすべてを(XHTMLでない)XMLにするということの必要性も私には分かりかねます。

# 余談ですねorz


[36]>23 コンテンツの著作権 ratbeta

>>むしろ、このことが問題になっているような気がしてなりません。コンテンツの著作権とも絡んでいますので、むしろXHTMLを正確に記述することが不利な条件を生んでしまうこともあろうかと思います。

確かにそのとおりです。

他人のページを勝手に加工し表示するのは問題であるという議論は以前からあります。

しかしながら、例えばツールの更新情報を掲載する場合など、

他のページでの表示が行われたい場合というのも少なからずあります。

# はてなアンテナがXMLパーサを搭載したような感じでしょうか。

少なくとも現状では、すべてのサイトがRSSを配信しているわけでも、

あるいは外国で用いられているXML-PADなどの手法を用いているわけでもありません。

個人サイトでは未だに手書きの(ソフトを利用したものも含む)サイトの割合の方が恐らく高いはずです。

それらのサイトすべてで自動でRSSを配信しろといっても無理な話ですから、

HTML自体をXML準拠(ここではXHTML)にすることで、

より簡単な情報配信が行えるのではないかな、と思うわけです。

その手の情報配信/宣伝などは、むしろ個人サイトのほうが必要としていると私は思います。

なお、著作権を必要とするコンテンツについては、

現状でもphpなどを用いて抽出させれば簡単に加工できてしまいますから、

やはりXHTML自体を暗号化するとか、あるいは文章全体を画像にしてしまうなど、

コンテンツを保護するための対策は必要であるかと思います。


[37]>12 原理主義者=発展亡き者 blackdocuro

層化学会がこれにあたります。


[38]>36 シームレスな配信方法として定着する必要性は感じますね ElekiBrain

>それらのサイトすべてで自動でRSSを配信しろといっても無理な話ですから、HTML自体をXML準拠(ここではXHTML)にすることで、より簡単な情報配信が行えるのではないかな、と思うわけです。

それはそうかもしれません。著作権のことに関しては、YouTubeのように、やや著作権に抵触しているものの、ユーザーのニーズにより後押しされ、順調な成長を遂げていますし、著作権ありきで考える時代ではないかもしれません。最近の傾向として、無料でコンテンツを配布し、そこから発生する広告収入で企業利益を上げる、という形態がメインになってきていることを考えるならば、まず著作権に目くじらを立てることよりも、コンテンツ配信方法としてのXMLがより発展する方向性で考えた方がインフラ全体としての利益に繋がるのかもしれませんね。


>XHTML自体を暗号化するとか、あるいは文章全体を画像にしてしまうなど、コンテンツを保護するための対策は必要であるかと思います。

これは難しい話ですね(否定ではありませんよ)。例えばJavascriptをコンパイルして、中身を暗号化するアプリケーションがMicrosoftから無料配布されていると聞いたことがあります。しかしコンパイルされたJavascriptはIEでしか表示できず、仮に全てのブラウザが対応したとしてもリコンパルするアプリケーションが巷にあふれるでしょうから、余り意味はないことになってしまいます。これは現在のFlashにもいえることです。Flashは近年まで、ダウンロードしようとしても落とせないメディアであり、かつリコンパイルもできないものとされてきました。しかしこの現状は変わりつつあります。最近では簡単にダウンロードできますし、リコンパイルして違法に配信することも簡単に出来てしまう時代です。幸いなことにそれをやる人間がそれほどいないために、問題は表面化していません。XHTML・XMLを暗号化する事に関しては私も前々から興味がありました。これを各社が実装してくれるならば、XHTML・XMLは素晴らしいインフラとして世に定着することでしょう。コンパイルすることによってのコンテンツの高速化も見込めます。ただし、この件に関しても前述したFlashと同様の事態が発生することは間違いなく、こうした著作権保護とコンテンツの利便性は天秤の両端で揺れ動くことになるでしょう。

ユーザーのニーズと企業努力の両方が必要になる、非常に難しい問題です。


[39]>35 私も余談を少々 ElekiBrain

XMLにてbrが出来ない、という事に一部で反論が起こりそうなのでちょっとした訂正を。XSLを介したXMLを表示する際、XSL内で表記したbrは普段どおりに使うことが出来ます。また「XSL+CSS+XML=表示」とする場合、この場合はXSLにbrを書くことが出来ますから、これも可能です。ところが、CSSを介したXML内ではbrは無視されます。CSSで直接見栄えを調整した、やや変化球のXMLも書くことが出来たので、色々と実践してみたのですが、IEとFirefoxの間にすさまじい表記の差異が発生しました。brもそうですが、透過GIFスページングなどもIEは対応しており、Firefoxは対応していないなど(逆だったかな)、他にもかなりの開きが見られました(まあ、スペーシング等といういかにも旧時代のレイアウトを試す必要性は余りないのですが)。


以上全くの余談です。


[40]>28 横槍OKですよ。少なくとも私個人は ElekiBrain

>特に、これからblogのカスタマイズなどからWebデザインを勉強する人などは、CSSでコーディングするのが当たり前になってくるんじゃないでしょうか。すると、ブラウザ各社やW3Cにもそういった圧力がいくのではないか、と(素人的な意見で申し訳ありませんが)

私も素人ですので、お気になさらず、ガンガン発言していただいて結構です。

この件に関してですが、もちろんCSSは今後より標準化してゆくものと思われます。しかし、テーブルはレイアウトとは別の側面で、単なる表としての価値を残して残存するのではないか、とするのが私の考えです。


>ただ、IT絡みの専門学校では、まずtable layoutから勉強するみたいなんで、そのへんがどう変わっていくかは疑問ではありますけど。

これ、そうだったんですね。知りませんでした。実際には「ドリームウィーバー」などで表組みを作っておいて、そこから細かなコーディングをやって行く人が多いので、こういった流れになったのかもしれません。

多分、綺麗なコードよりも、金になる技術を優先しているのかもしれません。確かに「ドリームウィーバー」で表をあらかじめ決めておいた方が生産性の一点においては向上しますしね。


[41]>33 私はテーブルはテーブルで価値を認めます ElekiBrain

>廃止予定になっているべき

これはなぜそうお思いでしょうか。テーブルはレイアウトの一環として使う以外に、単なる表としてその価値を持続させてゆくものと私は考えるのですが。


>なんで、Strictなんでしょう。

失礼します。これはどこのことを仰っているのでしょうか。申し訳ありませんが、お聞きしたいのですが。


[42]>41 属性です。 nipox

テーブル自体は、絶対必要です。

なんでStrictなんだ?

といっているのは、border等の属性のことです。


[43]>42 それはつまり・・・・・・ ElekiBrain
<table border="1" cellspacing="5"></table>

とかのことでしょうか? これをStrictで使えるのはおかしい、という意味で捉えましたが、そういうご意見だったのでしょうか?

そうしたご意見でしたら私もそう思います。確かにこれはCSSで代用できますね。

すみません。文章をよく読むべきでした。


[44]>43 はい。僕なんかてっきり nipox

てっきり、非推奨のタグだと思って、今まで使ってきませんでした。

あるひ、タグ辞典を見て驚いたものです。

まぁ、CSSのほうが細かく設定できるのでどちらにしてもこっちを使いますけれど。


[45]沈静化してきたので新たなテーマを。「動的なJavasciript+CSSサイト vs フルFlashサイト」 ElekiBrain

AjaxはFlashから使うことも出来ますし、補完関係になりやすいため、どちらが良いか、という意見にはならないと思い、このような形にしました。

しかたがって、議論のルールは「JvavascriptとCSSでDHTMLに動的な仕掛けを作るサイト」vs「全てFlashで形成されたフルFlashサイト」と致します。どちらがどう優れているか、あるいは問題点などを議論してください。例えば、使い方にもよるが、実際の動作・表示面ではどちらが重いか、など(悲しいかな、グラフィカルな表示を多用すればどっちも重いですけどね……)。


下にツリーを連ねていってください。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ