あなたのWebサイトをW3C準拠に 177
ストーリー by Oliver
内容も忘れずに 部門より
内容も忘れずに 部門より
Silphire 曰く、 "株式会社ミツエーリンクスが、WebサイトをW3Cが勧告した仕様に則ってHTMLやCSSを構成し直すサービスを開始した、とITmediaが報じている。勧告への準拠は、Webブラウザを含む多くのパーザが正しく文書を解析出来るようになり、またSEOにも有効な手段と成りうるなど、多くのメリットがある。しかし一方、世の中に溢れるパーザには勧告に準拠せずに独自の解析を行う物も多い。結果として、勧告に準拠するよりも、世界最大シェアを誇るInternet Explorerできちんとレンダリングされるように作られるサイトが多いだろう。今回のプレスリリースには
視覚表現を完全にCSSで制御する場合、閲覧環境のCSSへの準拠の度合い等によっては、意図した視覚表現を再現できない場合がありますので、あらかじめご了承ください。
とある。果たしてどの程度ブラウザ上でのレンダリングを考慮してくれるのかが気になる所である。ちなみに、ミツエーリンクスのホームページはHTML 4.01 Transitionalに準拠しているようだ。"
さすがです (スコア:3, 興味深い)
それにひきかえうち [pokton.com]といったら…。(^_^;)
負荷をかけてごめんなさい (スコア:3, 参考になる)
OSDL Japan [osdn.co.jp]-34点
Red Hat Japan [redhat.com]-152点
アップルコンピュータ [apple.co.jp]-327点
マイクロソフト [microsoft.com]-237点
そして我らが/.は!!!
Slashdot.jp [srad.jp]-14点
ぢつはW3C準拠って誰も気にしていないのでは…。
# ちなみにもじら組トップページは99点でした。流石です。
Re:負荷をかけてごめんなさい (スコア:3, おもしろおかしい)
惜しい、もう一息。
# 世の中こんなもん。
1を聞いて0を知れ!
日本のアップルとアメリカのApple (スコア:2, おもしろおかしい)
167個のエラーがありました。このHTMLは -39点です。タグが 23種類 190組使われています。
http://www.apple.co.jp/
179個のエラーがありました。このHTMLは -327点です。タグが 23種類 219組使われています。
日本のアップルのへたれぶりに乾杯…。
アメリカのほうのBODYの開始がないってのは笑ったけど。
Re:さすがです (スコア:3, 参考になる)
(a) 文句なしの100点。顔文字\(^o^)/祝福バージョン
(b) 減点 0 点のエラーがある100点。
ミツエーリンクスは顔文字バージョンですね。
頑張ってるなあ。
*-----------------------*
-- ウソ八百検索エンジン --
えぇっ?これで100点満点? (スコア:1, 興味深い)
たまたま、FreeSBIEのテストしていたときにこれ見たんだけど、
下のTopixのところで日付と文字が重なっている (T_T)
で、Windowsで表示してみたらちゃんと表示されるので、なんで?って調べたら…
CSSが全部ピクセル指定だった _| ̄| ミ○
誰かCSS-Lint作ってくれないかなぁ。 (^_^;
Re:えぇっ?これで100点満点? (スコア:2, 参考になる)
Re:さすがです (スコア:2, すばらしい洞察)
W3CなHTML作成ソフトが少ない(無い?)ことも問題なのかもしれませんね。
Re:さすがです (スコア:1)
Re:さすがです (スコア:2, 興味深い)
http://homepage1.nifty.com/VET06031/web/lint100.html [nifty.com]
W3C準拠でもエラーでるのはどうしてよ? (スコア:1)
Re:さすがです (スコア:1)
http://openlab.ring.gr.jp/k16/htmllint/explain.html#near-bgcolor
こんなところまで文句言われるとむしろその正当性に疑問を感じます。
その見解は微妙に浅くはないですか。 (スコア:3, 興味深い)
例えば、HTTPレスポンスヘッダでMIME-TYPEの指定及びcharsetの指定をする設定を施しているならば
上記のようなHTTPレスポンスヘッダの代替機能としての記述はしなくても良い。
因みに、meta http-equiv="Content-Type"な記述がないと100点にはならないはずですが、それでも技術者としては100点が当たり前なんでしょうか。
良くわかってHTMLを記述している人ほど、何らかの正当な(或いは妥当)な理由で100として採点される文書にはなっていないと思います。もっとも、それらの文書は単純に100点な文書よりも考慮されている点が多いと思いますが。
Yggdraさんが#540267 [srad.jp]で紹介なさっているように、単純に「HTML-lintで100点なら良い」わけではないと私は考えます。lintの採点を追求した記述よりも、仕様と照らし合わせた思想的に合致する記述法のほうが好ましいのではないかと。lintの採点は一定以上の水準にしてくれるだけであって、全てのケースでその採点が妥当であるとは限らないのではないでしょうか。
--労使曰く、ひとごとを尽くして神頼み--
Re:その見解は微妙に浅くはないですか。 (スコア:2, 興味深い)
賛成です。
そうやってデ・ファクトが出来上がってゆくのです。
昔からそうやってきたんですから。
好むと好まざるとに関わらず。
---
もちろん形成過程は哀しいかなパワーゲーム
面白いと思います。 (スコア:3, 参考になる)
# ただ規格違反ではないのですが、li要素の終了タグは省略しない方がいいのでは。
# あとは「JIS規格」(JIS…日本工業規格)やJIS X 0208の方のスラッシュ・括弧も止めた方がいいかも。
あとは「W3C準拠」をどうブランディングしていくかということでしょうか。
Re:面白いと思います。 (スコア:4, 参考になる)
ご存じない方のために書いておくと、IEは6.0からHTML文書にDOCTYPE宣言がついていると、それまでのいかれた解釈をやめて標準準拠に近い振る舞いをします。ところが、DOCTYPE宣言より前に空白文字以外の文字があると、DOCTYPE宣言が無効になってしまいます。よってXML宣言が強く奨励(UTF-{8,16}以外は必須)であるXHTMLだと、IE6ではDOCTYPEスイッチが有効になりません。
あとはXHTML 1.1準拠の文書ではメディアタイプに"application/xhtml+xml"を使うべきなのですが、これもまたIE6は理解出来ません。「ファイルのダウンロード」になってしまいます。
Re:面白いと思います。 (スコア:2, 参考になる)
もじら組 Web標準普及プロジェクト (スコア:2, 興味深い)
mozillaで閲覧すると見るにたえないページを報告すると、対処法を含め開設者に連絡してくれます。
ただし、開設者もない袖は振れないので結局は修正されない事が多いようです。
Mozillaな人とOperaな人が共同で、標準化のプロジェクトをでっち上げると
聞いたのですが、進捗状況はどうなっているのかしらん。
Re:もじら組 Web標準普及プロジェクト (スコア:1, 興味深い)
なにより強力な推進力になると思うがなぁ。
筆頭株主のご意向しだいかな。嬉しくもあり悲しくもあり。
Re:もじら組 Web標準普及プロジェクト (スコア:3, 興味深い)
うちの会社のような零細サイトでも、Web標準化(というより適切なマークアップかな)を施すだけで、劇的にGoogleのページランクが上がりました。
たいしてコストもかからないしね。
Re:もじら組 Web標準普及プロジェクト (スコア:1, 興味深い)
SCO -> Google様にお伺いを立てる
web標準化 -> W3C様にお伺いを立てる
「たまたま」Googleがw3cの作った標準を軸にサイトの重みづけを使っているだけで、Google様が反応してくれるありがたい独自タグみたいのがあれば、web標準もクソもないのです。
W3C準拠にする意味って何? (スコア:2, 興味深い)
何か、合理的な理由ってあるんでしょうか?
より多くの人に、より多くの環境で読めるようにでしょうか?
それなら、IE第一に考えるのが当然でしょうし、
古いブラウザのために、多少W3C標準から外れていた方が良い
ケースもあるのではないでしょうか。
HTMLが「美しい」ことに自己満足以外の何の意味があるんでしょうか?
#「標準」なんだから従え、という思考停止は抜きで。
# 自分でもきれいなHTMLを書きたいとは思っているけど、
# ソースを見てニヤリとしてもらうこと以外に、
# その目的はよくわかりません。
Re:W3C準拠にする意味って何? (スコア:4, すばらしい洞察)
ユーザビリティの向上。IE第一にしても、別にW3C準拠にはできるし。読み上げ式ブラウザとかへの対応を唱えば、企業としては、弱者配慮の姿勢を示すことが出来る。もちろんマイナーブラウザユーザへのアピールも
>HTMLが「美しい」ことに自己満足以外の何の意味があるんでしょうか?
ソースの管理のしやすさ。テーブルタグだらけのソースはメンテがしにくい。
それと上でも書いてありますが、SEOの効果。適切にマークアップされたソースは検索エンジンにも解釈されやすい。
>古いブラウザのために、多少W3C標準から外れていた方が良い
ケースもあるのではないでしょうか。
逆にW3C標準に徹底すれば、古いブラウザ対策はほとんど済んだとも言えますが。問題になるのはNetscape4.XあたりのCSSの解釈だと思いますが、そこはそれ、無視するか(うちはそう)、JavaScriptなりでそれ用のソースに飛ばすとか。
>わざわざコストかけて
最初からそう作っておけば別にコストはかからないよ。
以上、W3Cにある程度準拠した企業サイトを数年間構築運営した上での、とりあえず思いついた回答。納得いただけるかどうかわかりませんが。
Re:W3C準拠にする意味って何? (スコア:1, 興味深い)
W3C準拠することでアクセシビリティの高いページになることは事実です。
蹴るか蹴らないかではなく、文書を適切に解釈してくれるかどうかです。
テキスト情報だけ読めればいいという意味では?
HTMLは元々レイアウトを指定するためのものではないから、CSSに対応していない・対応が不十分なブラウザでは素のHTMLだけを読ませればいい。
字と画像の羅列だけで大抵の情報は伝達できます。
凝ったレイアウトは付加的な要素であって、必ずしも必要なものではない。
どうせIEの各バージョンで表示をチェックするんでしょ?
lintが一つ増えたくらいで何を言ってるのか…
それに元の人は最初から作っておけばって言ってるじゃない。
最初から標準準拠したらイニシャルコストなんて高くならない。
Re:W3C準拠にする意味って何? (スコア:1)
>のはわかりますが、W3C準拠でなくても、ユーザービリティ、
>アクセシビリティの高いページは書けるはずです。
W3C準拠で対応が容易なのに「わざわざ」W3Cを外れて自分規格なものを作る理由ってなんなのでしょうか?
>これは的外れですね。W3C準拠のTableネストだらけのHTMLだって書けるし、
>W3Cに準拠しないメンテナンス性の高いHTMLだってあります。
TableネストだらけのHTMLは、たとえHTMLのDTDには沿っていても、文書構造の記述として、正しくないでしょう。
W3C準拠を推している人はDTDに厳格に沿うことではなく、文書構造を正しく記述することによるメリットを考えていると思います。
採点マシーンで100点とれてもダメなHTMLはダメだと思います。
それから、あえてW3C準拠を外れることによって実現できるメンテナンス性の向上方法って何でしょうか?
>W3C準拠のHTMLを書くのと、そうでなくても良いHTML書くのとであれば、
>前者のコストの方が低くなることはありません。
ここで考え方の相違が出るのは、そもそもHTMLは手で書く物だと考えているか、ツールに自動生成させるものと考えているかによるのだと思います。
前者は、HTMLは文書を記述していって(そもそも文書だからツールで作成するとは考えない)、後からデザインはCSSでつけてねって捕らえているので、初期コストが高くなるとは考えません。
後者だと、現在の自動生成ツールだと泣けてくる作業が待っているに違いないでしょう。
>W3C準拠自体を目的とする一部の風潮に疑問を感じるわけです。
一部の風潮なのかどうかわかりませんが、HTMLに限らず我流なソースコードって引継ぎたくないのが普通かと。
せっかく普通なやりかたがあるなら、それに従っておいてくれると後の人が楽です。
Re:W3C準拠にする意味って何? (スコア:3, すばらしい洞察)
しかし将来の事も考慮に入れて、「もしブラウザのシェアが変動したら」という可能性に配慮するならば、W3C準拠は充分に合理的な根拠と言えるのではないでしょうか。例えば「Windowsのシェア、2007年には58%に? [itmedia.co.jp]」などという予想もあります。もしそんなことになれば、ブラウザのシェア変動は避けられません。
また、たとえ今後も Windows がシェアの寡占を維持したとしても、それに搭載される IE の動作が現在と同じという保証はありません。IE7.0 などというものにバージョンアップして、レンダリングなどが IE6.0 とは変わってしまう、という可能性もあるわけです。
そういった可能性を考えた場合、ブラウザの挙動に合わせてソースを変更しなければならない時に、最小限の変更で対応できるようにしておくほうが良いでしょう。そして「どうすれば最小限の変更で済むか」という対策の1つとして、W3C への準拠という方法があると思います。
特に、IE に特化した HTML を書いている場合、ブラウザシェアが変わるとそれまでの機能が使えなくなる可能性もあります。(JavaScript などでは、IE では動作するが Mozilla では動作しない、というのがよくありますね)
まあ、将来への保険、みたいな位置づけですね。
*-----------------------*
-- ウソ八百検索エンジン --
Re:W3C準拠にする意味って何? (スコア:1, 興味深い)
一番真剣に考えるのはどこかってことを慮ったとき、ひょっとしたらそれは
W3C よりも Microsoft かもしれないっていう結論もありだと思うな。
Re: W3C よりも Microsoft かもしれない (スコア:2, すばらしい洞察)
Re:W3C準拠にする意味って何? (スコア:3, 興味深い)
「単純にW3Cの勧告している文法に準拠にするだけ」なのなら、もったいないなぁ。コストは殆ど変わらないのに出来上がるものには違いがある。
文書内の「ある文字列/ある部品の役割とは何か」に注目しなければ、W3Cの勧告に準拠したところで「ただ見える」だけです。HTMLがもつ付加的な恩恵はハイパーリンク以外受けようがありません。「意味を伝える」という機能を無視しています。それと同時に様々な環境で内容が明確に伝わる可能性を狭めています。
HTMLとは文書の構造を、もっと端的に言って文書の「ある部品の意味を示すこと」に一つの大きな特徴があるのです。それが欠けていると、HTMLとしては少し損をしているのではないかなぁ。
「より多くの環境で」という言葉の意味が、私と#540202のACさんとでは違うと思いますので、それについて触れておきましょう。
ACさんが意図している「より多くの環境で」は「シェアの量的に、より多くの環境で」だと思います。故に「IE第一に考える」と述べているのでしょう。 私が「より多くの環境で」と言う場合は、「より多種多様なプラットフォームで」という言葉と等価な意味で用いているつもりです。
それは1面の真かもしれません。しかし、それを実行することは正しく解釈する他のUserAgentに対する不親切を伴わねばいけません。──そうしなければ、製作者が伝えたい情報というのは伝わらないものなのでしょうか?
W3CとHTMLという仕様自体は後方互換性に随分配慮した形をとっています。もちろん元ACさんが意図したいのはレンダリングに関することなのでしょうが、レンダリングの差異で作者の大まかな意図が通じない文書であれば、再考の余地があるのではないでしょうか。
HTMLを成す思想の基幹には2つあると思います。一つはハイパーリンクによる文書相互間の関連付け。もう一つは意味の伝達です。この二つがそろって利便性があり、HTMLとしては本来想定した機能を果たしているのではいかと思います。(HTMLにおいては、伝達と表現とは同義ではないと考える。)
--労使曰く、ひとごとを尽くして神頼み--
補足?その1 (スコア:2, 興味深い)
補足というか、頭に沸いてきたことをどこに返信したらよいかわからないのでここに書きます。
まず、我々の自然言語の文書を電子的に扱うことの弱点についてです。
電子的に文字を扱うことは、どうしてもレイアウト情報と文字を分離する形をとるか、文字情報とレイアウト情報を融合させて新しいフォーマットを用いるかを選択することとなります。前者を採ったのがプレーンテキストやHTMLで、後者を採ったのがPDFです。結果としてカジュアルに使われるようになったのはHTMLです。(後述)
我々の自然言語の文書は、少し色が使えなかったり、違うレイアウトで見えてしまったりするだけで、意図が通じなくなることがあるのです。例えば引用なんてのがそうなると思います。製作者はある文字列に特別な意味と区別を持たせたいのに、単なる文字列はその程度のことすら明確に伝えることはできません。
HTMLとPDFはそれぞれの特徴を生かしたアプローチでこれを解決しています。PDFはPostscript系のレイアウトを生成するための仕様ゆえに、あらゆる環境で同じレイアウトを再現しようとします。これによってDTP的に自然言語の文書とその意図を再現しています。
一方HTMLは、UserAgentで比較的容易に処理できるように決められたText形式のフォーマットで、処理を容易にするためにレンダリングなどをUserAgentに(悪く言えば)丸投げしています。そのため、予め意味を定めた記号を用いてレンダリング時(ユーザに伝える実装。音声などの場合もある)に参考になる意味を伝える方法で文書再現を支援しています。というより、文書再現を支援するための情報をUserAgentに伝えることこそがHTMLの目的なのだと思います。
ともかく、レンダリング情報をHTMLは保有しないわけですから、部品の意味を伝える以外に直接の再生支援をできませんし、それ以上のことは──画像レンダリングの高速化のためのサイズ指定などの良識ある便宜的な例外を除いて──してはならないと思います。
余談ですが、HTMLとPDFでなぜHTMLが多く使われるようなったかといえ、処理が容易で負荷が少ないからアプリケーションの製作が比較的容易で、実行環境でも割とストレスなく使用できるからでしょう。仮に負荷が変わらないのであれば、人間の感覚的に文書を再現しているPDFの方がユーザは好んで用いたかもしれません。
上記のようなことから、私はHTMLに求められているのは抽象性であると思っています。「HTMLは環境を限定しない。特定環境に合わせない。依存しない。」ということが求められていると思います。その性質上、特定環境に最適化すればHTMLとしては不十分になり、良くも悪くもどっちつかずがHTMLのスタンスであるべきだと思います。
--労使曰く、ひとごとを尽くして神頼み--
Re:W3C準拠にする意味って何? (スコア:2, 参考になる)
ディスプレイに表示されているWebページはHTML文書とUserAgentのスタイルシートとの融合物であるということを考えていただきたい。見栄えはUserAgentが用いるスタイルシートによるものであるから、見栄えを制御したい方々は対象が間違いであろう。(この場合のスタイルシートはCSSのみならず広義のスタイルシート)
仮に見栄え制御こそが重要であるということを真としても、論理構造の表現を全て否定する合理的な理由がわかりません。また論理構造の明示こそが「HTMLはあらゆる環境で利用できる」という目的を実現させているのですが。(そんなものがあるとすれば)論理構造重視派はCSSをもって論理構造と見栄えの共存を図っています。見栄え至上では、排他的になるのですか?
また、策定されることのなかったHTML3.0を省みてほしい。 HTML3.0はHTMLが持っている可能性のうち、見栄え制御言語への道を実現するための仕様になるはずだった。結果的に言えばそれは否定され、1995年9月の3.0の破綻から、一年少々経った1997年1月にその場しのぎ的なHTML3.2が勧告された。1997年12月にはHTML4.0が勧告されるに至っている。(1996年12月にはCSS Level1が勧告)
HTML4は仕様書に記述されているように、見栄えと構造の分離を目指した言語である。
なぜHTML3.0は破綻したのか。見栄え制御は意味構造の明示よりも社会的に優先されるものではないのか。そもそも同一のハード上で利用されることが限定できないWebという環境を想定した場合、Webの共通語たるべき仕様が採るべきスタンスとは何だろうか。──そういう迷走と理想の追求があって現在のHTMLが存在しているのではないか。
文書に関して、一体どれほどの人間が構造を意識できるだろうか。意味上の論理構造を見出せない人間が多いことにもかなりの問題がある。しかし、言われてみればそういう人たちも論理構造というものをどこかで知っており、普段は無意識的に見栄えから解釈している。もちろん閲覧者としてはそれが正しい。問題はHTML文書の記述者が論理構造に対して無知であるということである。
また、HTMLは意味上の構造は全てを表現することは不可能だが、HTMLは汎用的で強力な意味をもつ幾つかの基本的な意味構造を表現できれば良く、HTMLが全ての構造を表現する必要はないと思われる。そもそも意味上の構造全てというが、それほど多彩かつ明確な意味を持つ構造を内包した文書というのが、社会的にどれほどあるのかは疑問がある。加えて、HTMLではHTMLで表現できない構造のためにDIV、SPANなどを提供している。今後ユーザーがHTMLで表現されない微妙なニュアンスの構造を表現する場合、それらを用いてスタイルをもって直接閲覧者に働きかけることとなるだろう。(もっとも、意味を明示するという立場に基づいては、あまり多く発生しないと思うが)
今をもってもWebとHTMLは過渡期にある。過渡期の一時の混乱によって生じたデファクトスタンダードに拘泥することは今後の発展と利便性を阻害するのではないか。
「時既に遅しの感があり」。それはブラウザベンダに言って上げて下さい。だからもっと早く実装しろと。ブラウザの実装が拙くなければ、Webデザイナの先生方も我々一般人も楽ができるし、見栄え論争などしなくてもよくなる。
--労使曰く、ひとごとを尽くして神頼み--
Re:W3C準拠にする意味って何? (スコア:2, すばらしい洞察)
また人間でない(クローラや読み上げプログラムのような)ものがアクセスする際にも、ある程度標準に準拠しておいたほうがページが伝えたいものがはっきりします。
自治体のように誰でもアクセスしやすいようになっていないと困るようなところ向けではありますが。
というより、まず「より多くの環境で読めるように」→「ならIE第一で」っていうのはおかしいでしょう。(MozillaがありNetscape4があり、OperaがありSafariがw3mが……)
Re:W3C準拠にする意味って何? (スコア:2, おもしろおかしい)
1を聞いて0を知れ!
Re:W3C準拠にする意味って何? (スコア:1)
Re:W3C準拠にする意味って何? (スコア:1)
ソース=仕様ではいかんということ。
Re:W3C準拠にする意味って何? (スコア:1)
そう思うなら、他のブラウザの事も考えるでしょう。
IE の他に Netscape、Mozilla、Opera、その他多くのブラウザがあるのをご存知でしょうか。
一つのものさしに従えば、それに準拠したブラウザも作りやすくなるでしょう。
ユーザの立場なら面倒な規則に従うのは面倒かもしれませんが、
今後さまざまな環境を体験すると、その重要さが分かるかと思います。
☆IE を基準に作ったサイトを他のブラウザで表示したら、見れたもんじゃなかった☆
特にMozillaやOperaなどはユーザも増えてきています。
一度ご自分で確認してみては如何でしょう。
サービスありき (スコア:2, 興味深い)
他の方も書いていますが、現在サイトがない状態もしくは、完全リニューアルが決まっている状態であれば、何に準拠(W3C準拠だろうが俺様準拠だろうが)するのであっても、コストのブレはそれほど大きくありません。もちろんW3C準拠という名目で見積もりを上乗せできる可能性はありますけど。
しかし、既にサイトがあり、それを全面リニューアルする計画がなく、サイトの規模もある程度(100P以上)の場合、それをW3C準拠にするためだけに、まとまったコストを企業が負担するとは思えません。
さらに、完全リニューアルするならデザインも合わせて変更してしまおうと提案営業されて、金額がさらに膨らむ可能性大ですね。
現時点で残り数%以下のシェアのブラウザのために、何百万円(予想・・・)も掛ける企業は少ないでしょう。
もちろん例外として、
・トラフィックが莫大であるため、わずか1%シェアのブラウザであっても、かなりの数のアクセスとなる
・トラフィックが莫大であるため、CSSを利用してHTMLファイルの転送量が減らせるメリットも大きくなる
という場合がありますかね。そんなトラフィックを集めるサイトは超有名企業や超有名サービスのサイトだけくらいでしょうけど。そういうサイトにコンサル込みで1000万単位で売るという手はありそうですね。
中小企業はW3C準拠よりも先に、プライバシーマークですか。
Re:サービスありき (スコア:2, 興味深い)
運用面で有利 (スコア:2, 参考になる)
ウェブサイトの製作作業における、ちょっとしたプラクティスというか、ガイドラインを下記のページに書いてます。
Web Publisher が想定している使われ方
http://webpub.narucy.com/whitepapers/designing_on_webpub.html
ビックリするほど綺麗 (スコア:1)
HTMLの自動生成ツールの類もこういうHTML吐き出すといいのになぁ。
事業の内容は興味ないですが(笑)、HTMLとCSSの書き方の参考にするページとして、とても良いように思います。
Re:ビックリするほど綺麗 (スコア:3, すばらしい洞察)
スラドでは「綺麗なHTMLを書け」という方が多いように思いますが、実際問題デザイナが使用しているのはドリでありゴーライブであるわけで。HTMLを意識してページを作っているデザイナというのは、かなり少数派だと思います。
# CSSでレイアウトするぞーと意気込んで、IEとMozillaの表示の違いに愕然とし、結局テーブルレイアウトに逃げ込んだヘタレな私。
ん? 俺、今何か言った?
Re:ビックリするほど綺麗 (スコア:1)
そしてCSSでのレイアウト情報はノウハウが蓄積されてない、実現が難しい、実装が追い付いてない等々の理由で、非常に難しい状況です。
そういうわけなので、そもそもHTMLに視覚的デザインを要求することが無理なんだと考えています。
どうしても視覚的なデザインをしたければ、PDFなりFlashなりで作ればいいわけで、規格外のHTMLを書く必要は無いわけですよね。PDFもFlashも、HTMLと違ってちゃんとしたデータを吐いてくれるツールがありますし。
むしろ規格をはずれてまでHTMLで書こうとする理由が知りたいところです。
多分 (スコア:1)
# マジレスのつもり
yp
Re:多分 (スコア:1)
Flashプラグインはわかりませんが、インストールなんてOKボタンを2回ばかり押すだけですよね。
ユーザーにとってお手軽かという点では、HTMLに負けてないと思うのですが。
HTMLのソースはともかく (スコア:1)
Webデザイナーが好まないか市場は好まないか (スコア:2, すばらしい洞察)
サイズ固定ではないので、設定で大きくすれば大きく出来るだけマシかな。画像化されたテキストは、それなりに小さいけど。
スラドのように、(1)画像化テキストはサイトロゴなど最小限、(2)小さいサイズのテキストは、内容的にマイナーなコンテンツ(注)等に限定、という方針のサイトが、ウェブアクセシビリティの点では好ましいけど、(残念ながら)そういうサイトはめずらしい。
というか、デザインがださくなりがちなので、「Webデザイナー」は好まない。
#多分、市場が好まないという答えが帰ってくる。
Re:Webデザイナーが好まないか市場は好まないか (スコア:5, すばらしい洞察)
という気がします。
正しく凝るには複数の知識が必要で、もしかして案外敷居が高い物だったりして。
HTMLは、素直に書けば自動的にトラッドなレイアウトに仕上がる、良く考えられたお手軽ページ記述言語だと思うんですけどね。そしてそれの見た目に手をつけるのがcssだというのが、W3Cの意思だと思います。んで、HTMLの利点を殺してまで奇を衒う努力をするのがプロアマ問わずのwebデザイナーかな。
そもそもHTML lintを通してエラーが出なかったからOKだなんて、まるでコンパイラがwarningを出さなかったからバグがないって言ってるのと同じだと思うんですよね~。これって原理主義?
ソースを見ると (スコア:1, すばらしい洞察)
web屋としては、ソースの中に、
MM(MacroMediaDreamWeaver)のJavaScriptが
ガシガシかいてあるのは、どうだかなぁ
って感が。。。
横幅固定、フォントサイズ固定 (スコア:1, 参考になる)
横幅が固定されている。フォントサイズも大きくできない。
文法が正しかろうが、アクセサビリティの最も基本部分に理解が無い。
お話にならない業者ですな。
Re:横幅固定、フォントサイズ固定 (スコア:2, 興味深い)
富士通がwebサイトの制作基準発表 [srad.jp]というストーリーがありましたが、
同社はアクセシビリティをチェックするツール群
Fujitsu Accessibility Assistance [fujitsu.com]を無償で公開しています。
その中のWebInspectorで同社トップページを検証してみると、
area要素にalt属性が無い、行間・文字サイズが固定されている等の警告がありました。
テキストブラウザや音声ブラウザでの閲覧にはほぼ問題ないですが
IEやMozilla等で弱視の方が見るには辛いかもしれませんね。
#Macで見るとSafari/Firefox共にトピックスの日付の末尾と項目名の先頭が重複していました。
#文法が正しかろうが、マカーに理解がない。