アカウント名:
パスワード:
特定バージョンにおいては大規模な変更は行われていないし (CSS2.1 はアレだけど)、HTML のバージョンを宣言している文書において、より新しいバージョンを元に解釈する事自体が誤りなので (HTML 4.0 を HTML 4.01 と完全に同等として解釈すること自体が誤り) 問題ない事ですよ。
そして、これらはエラッタが出るとバージョンが上がります。ですから改訂されない事を前提にして構わないものです。
まともに書かれた HTML の文書なら HTML のバージョンが必ず入っていますから何の問題もありません。
# 変更される可能性がある Draft 版の仕様を元に公開されてるバージョンであれば、その理由で責めていいです。
仕様に沿った HTML 4 または CSS1 の範囲であれば、実はさほど問題がない (HTML 4 については abbr 要素の認識以外では HTML 回りはほぼ完璧で、CSS も CSS1 「のみ」であればやはり問題は起きない) のが実際ですよ。
IE6 は HTML4 + CSS1 までしか謳っておらず、XHTML 1.0/1.1 や CSS2 以降に関しては対応しているとは言ってません。CSS の問題は仕様上 CSS1 から外れる領域 (CSS2 以降) のセレクタの記法等、「未知のセレクタに遭遇したら無視する」という仕様を満たしていないため、CSS 回りにおいて IE hack が発生するというのが現実です。
むしろ IE6 じゃないと困るというのは、IE7 によりセキュリティが強化する目的で行われた仕様変更への追従に関する問題や、JavaScript 回りで厳密にバージョンチェックを行っていた事による (IE4/5.0/5.5/6.0 で処理を細かく振り分け等) IE7 用の分岐路がない、既存動作との互換性保証があるか、という問題とかです。
Firefox や SeaMonkey などでも security fix により 0.0.1 の差で動かなくなるスクリプトが発生するといった事はありますから、メジャーバージョンアップになる IE7 に関して、スクリプト回りを利用している場合の検証コストは常に発生する話です。
JavaScript はまともに仕様と言えるものが現状 ECMA-262 revision 3 程度しかありませんが、これは本当に言語仕様であって「ブラウザ (実装系) がどんなオブジェクトを持っているか」とかの仕様ではないのです。つまり document.write() とかも仕様外。C# の ECMA にある仕様と実際に書かれる .NET Framework を前提とした C# 2.0/3.0 とかみたいな乖離がある、という感じでしょうか。(後者の方は違いがヘビーすぎますが、まぁ極端な例ということで)
そういう世界なので、「このブラウザだとこのオブジェクトがあるから」とかいうのはよくある話ですし、「このプロパティが」「このメソッドが」というのも普通にあるという事でして。
だから、世に溢れる JavaScript 入門系の本などでもメソッド/プロパティ毎に「IE6 で使える」「Firefox で使える」といった記述が踊る事になるのです。
さらに、共通で使えるオブジェクト/メソッド/プロパティなど (さすがに w3m-js なんかは無視されますが……) だけでも実装差異等の問題もあり、処理内容によっては細やかな分岐が必要になったりします。
まぁ、その辺りは結局「Web 標準規格の範囲内」からがっつり外れてしまう物になりますけどね。
Flash 9 で作って携帯じゃ (略) とか、Java Applet にして w3m 憤死とか。
なので、結局アクセシビリティ的な観点からも、Web サービスは最初から HTML のみ、それも画像とかはできるだけ使わずにテキストのみで「そのサービスは実現可能なのか」という点を元に設計する必要があると思いますよ。
Java Applet や Flash、ActiveX といったプラグインを使うコンテンツによるサービス、HTML + JavaScript で構成、HTML のみで構成……と落ちていっても、とりあえず同等の「機能」は提供する (使いやすさは前者ほど高いでしょう) という複合型で。
# アクセシビリティ的再重視では、動画ですら「最終的にテキストに落とせ」という素敵なコンテンツ制作が待ってます。本気でやると泣けますよ。(笑)
"Web のプロ" が本当に Web のプロかどうかが問題であって……未だに W3C なんて見たことも聞いたこともありませんとか、そういうクラスがプロだと言っていたりしますから。
コンテンツにおいてはアクセシビリティでは text/plain 最強。WCAG (Web Contents Acceccibility Guidelines) なんかでは、HTML のコンテンツも最終的にはテキストに落とせ、とする程度にテキストは最強です。
ただ、ソフトウェア的に意味ベースで解釈するにはマークアップがあった方が負荷が低いといった、HTML の方が何かと便利という点から見ると HTML の方が扱いやすい、という程度でしょうね。
JavaScript の場合は、言語的な動作の仕様は当然ながら決まっています。決まっていないのは Web ブラウザ毎に固有となる実装の部分です。C# の仕様に .NET Framework のクラスライブラリが仕様に含まれている訳ではないのが状況として似ている、ということです。
つまり、実際に C#(JavaScript) を使う .NET(Web ブラウザ上) という環境を想定すると、たとえ C#(JavaScript) の仕様だけを知っていても、実際に使う場面となる .NET のクラスライブラリ (Web ブラウザが持っている各種オブジェクト) を理解していないと、事実上使いものにならないということです。
そして、この Web ブラウザが持っている各種オブジェクトに関しては標準化されたものはないし、W3C も UA に関する仕様を定義する組織ではないため、特に標準化しようという動きはありません。いいとこ DOM 程度です。
これらを踏まえた上で、ユーザビリティとアクセシビリティの両立を常に意識している人であれば、AJAX を使いつつアクセシビリティの確保を行うのは、特に大きな問題がある訳でもないですよ。
WCAG 的には、Web サービスを Flash 等で行う事は否定されていませんが、Flash プレーヤがない場合には「同等の Web サービスを HTML ベースで内容として持て」とあります。よくある「最新の Flash プレーヤをインストールしてください」なんてリンクがあるのは最悪のパターンなんですよね。
こうしたことを当たり前のようにやってくれる制作会社だったら「Web のプロ」だと呼んでいいと思いますよ。
ただし、Flash とかを使わないと実現できない機能を持っていて、HTML レベルではどうやっても不可能である場合にユーザを絞って提供することがダメだとは思いません。それは元々ターゲッティングの違いですから。
ユニバーサルサービスを標榜しつつ Flash のみです、なんてのは話になりませんけどね。
アクセシビリティに関しては、発注者側の意識も確かに大切です。が、Web 制作会社側が「そうした点に対する考慮はどうするのか」という確認を行ってくるかどうかというのも、クォリティに対する意識があるかどうかの点で判断基準になるかと思います。
# 幸いにして、以前いた会社では「それが当たり前」でしたが……。
JavaScript に関しては、基本的に昔は Netscape、今は Mozilla Foundation が仕様を作り、それを ECMA に提出という感じで国際規格化されています。ECMA-262 辺りを探してみると見つかります。これで Web アプリ向けのコードを書けたらすごいってレベルです。
Flash などでも、たとえば Flash でムービーを提供 (YouTube やニコニコ動画みたいな?) の場合、同等の情報というのが信じられないほど膨大なテキストになったりする (笑) ため、実はかなり非現実的な話なのですけどね。
装飾程度の位置付けで無くても問題ないというレベルであれば、そこまでの説明等は不要ですが、だったら最初から(ry とか。難しいところです。
皆が～というのは当然望ましい事ですが、金を取ってはいても冗談みたいなレベル (1 ページ数百円とか) で発注している業者とかもありますので、実際の作業者としてはこの単価でそこまで考えろというのは酷でしょうね。
# その業者側の意識が足りない、とは思ってます。
Web 標準に従って HTML 5 が勧告になったとしても XP は 2014 年までサポートされ、IE6 もサポートされ続けるわけです。
Web 業界の中で Netscape Navigator/Communicator 4.x を「もういい加減いいよね」と言われるまでにどれだけ時間がかかったか。未だに「使ってる」なんて言われる場面すらある。そういう状況です。
当然ながら IE6 は HTML 5 で仕様に含まれようとしている canvas 要素等など知りません。HTML 4 の abbr 要素ですら認識しないのです。こんな理由で HTML 5 は結局 2010 年を超えても採用できない、となる可能性は高いです。
こうした状況において「Web 標準に従って」なんて言っても、古い仕様に沿って作る必要があり、もっと効率的に実現可能な新しい仕様があったところで使われない、使えない、となってしまう訳です。
しかしクライアントの要件としては、最新の高機能なブラウザ系でしか使えないような機能を必須とされたりする。こんなのはよくある話なのですが。
# Gmail は w3m で十分に使えるか、でもいいですが……って、Google は別に Web 標準には準拠してませんか。
システム屋に責任があると思います。
ヒント: W3C 等の標準仕様で可能な機能の範囲
要求機能と配布コストの低減といった辺りで「どうせ Windows を導入する」という前提に立てば、その時点での IE で動作する (そして将来的に「セキュリティ面に問題がある」という事で機能が変更されるかもしれない!) アプリケーションを構築することは十分にあり得ます。
困ったことにIE6は多少のバグを含んだHTMLファイルでも、一見すると正しく表示してしまいます。
HTML を使う以上、「ブラウザは HTML が壊れててもなんとか表示する必要がある」と仕様に明記されているためであって、これは IE が悪いという話ではありません。というか、Firefox でもエンドユーザはエラーを見る機会はまずありません。
そして HTML Validator 等は「出力された HTML の妥当性」は確認できても、Web アプリの動作として妥当かは確認できません。現実に動く環境でなければ "Web アプリ" のテストなんてできませんよ。
SGML アプリケーション化された HTML 2.0 以降とその前の HTML では全く仕様が異なり、その前の HTML を前提としたようなブラウザでも十分に動き、Netscape/IE 独自拡張を廃した Web ブラウザでは、そもそも Web アプリケーション自体が成立しません。
フォームすら使えるか分からないのにどうやってデータをサーバに送るのか、JavaScript どころか cookie すら保証されない環境でどのように使うのか。cookie に対応していてもセキュアフラグなんて知りません、なんてのはどうするのか。
こうした辺りを考えると、あらゆる新旧合わせた Web ブラウザに適合する Web アプリなんてものは存在しえず、ある程度の要件を定義する必要があります。最低 HTML 4.0 程度に対応している、とか。(HTML 2.x or HTML 4.0 以降でないと仕様上国際化対応が考えられていません)
まして、ActiveX によるアプリケーションの配布コストの低減を狙って開発されたソフトは、開発ターゲット自体が "Windows 環境で IE 上" であって、"Windows を含む様々な環境" ではありません。前者を基準に設計してくれ、という依頼を受けた場合に後者で動作しないから責めるというのはさすがにおかしいでしょう。
「Web アプリ」の検収条件として IE6 で動けば ok というのは確かにおかしいです。しかし、「Web を利用した Win アプリ」の検収条件としては十分なのです。その辺りを理解せずに文句を言ってるだけにしか見えませんよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
IEでしか動かないってのが (スコア:1, 興味深い)
どっちにしても数年内に企業PCもVistaになるんだから
覚悟きめて標準的なWebアプリを模索すべき。
それにしても、IE6でしか動かないシステムを提案をした
システム屋の責任は問われないのかな？
Re:IEでしか動かないってのが (スコア:4, すばらしい洞察)
>システム屋の責任は問われないのかな？
よくこういう発言を目にしますけど、WWWというサービスが使われ始めて
すでに17年が経ってるわけで、その間いろいろと変わってきました。
「IE6でしか動かない」というよりも、
「その当時に最も使われているブラウザで動く」というものであって、
将来登場するであろうブラウザでの動作も保証することなんて困難です。
CookiesもJavaScriptも使わず、本当に昔のMosaicから最新のIE7や
Firefox2はもちろん、将来登場するはずの見たことも聞いたこともない
ブラウザでも動作する安全なWebアプリケーションを、顧客の要件を
満たして作ることの困難さを考えてみましょう。
システム屋に責任がありそうですか？
Re:IEでしか動かないってのが (スコア:3, すばらしい洞察)
おいおい、HTMLなんてデータベースやXMLなんかと一緒で、
文書をファイルとして保管しておくために存在する形式なんだぜ。
W3Cって団体がHyperText Markup Languageはこう書きましょうねって勧告した文書もちゃんとある。
「IEで小奇麗に見えるページが出来ればそれでいいや」と言いながら仕様書読まずに適当に取り繕ったHTML吐き出しといて、
仕様書通りにちゃんと動くブラウザが登場したら途端に「見れない！崩れちゃう！」というのは筋が違う。
（IE7もW3Cの仕様書通りに動くかと言えばまた別の話だけれども）
つまるところ技術者でHTMLを出力として採用するからには仕様書位読んで欲しい。
IE6も妥当なHTMLを書いておけばかなりのレベルで正しい表示をしてくれるはず。
（IE6の癖やバグなんかもあるから、IE6が発表された当時の技術者を叩いてもしょうがないが）
Re: (スコア:0)
Re: (スコア:0)
でもね、標準だけで出来ることって少ないんだよね。
でなきゃブラウザ等に依存した書法が溢れてる訳が無い。
Re: (スコア:0)
という言い方をすれば当然B案に決まる。
しかし、こんな誘導的な言い方をしなくても、客のやりたいことをヒアリングしていくとたいていB案しか選択できなくなる。これが過去の実態。
今は少しだけマシだけど。
Re: (スコア:0)
で？
その勧告はずっと昔から改定もされていないとでも思ってますか？
将来にわたって変更もされないと思っていますか？
Re:IEでしか動かないってのが (スコア:1)
特定バージョンにおいては大規模な変更は行われていないし (CSS2.1 はアレだけど)、HTML のバージョンを宣言している文書において、より新しいバージョンを元に解釈する事自体が誤りなので (HTML 4.0 を HTML 4.01 と完全に同等として解釈すること自体が誤り) 問題ない事ですよ。
そして、これらはエラッタが出るとバージョンが上がります。ですから改訂されない事を前提にして構わないものです。
まともに書かれた HTML の文書なら HTML のバージョンが必ず入っていますから何の問題もありません。
# 変更される可能性がある Draft 版の仕様を元に公開されてるバージョンであれば、その理由で責めていいです。
Re:IEでしか動かないってのが (スコア:1)
基本的に何でもブラウザ上で完結させようとする姿勢は好きではないのですが、
Googleの戦略やここ数年のweb業界の動向を見るに、「すでにブラウザの目的は
ブラウザではなく、ＯＳになってしまった」と考えれば、納得いくと思います。
例えばMacOS9やWindows98で動くことを目的としていたアプリが、数年後に出る
MacOSXやWindows2000に対応できないのは当たり前のことで。（ClassicModeは別）
Re:IEでしか動かないってのが (スコア:1)
もっともHTMLに対応しているブラウザについての話で、HTML以外の何かにしか対応していないUAについてはなんともいえませんが。
ただ、今までもこれからもHTMLでは見た目は保証されませんので、見た目を保証したい場合はPDFをお勧めします。多分互換性もばっちしです。Flashでもいいかもしれません。
適切なリソースの作成を努力して、結果として完璧ではないというのであれば評価できます。
ですが、たまたま偶然レンダリング結果が意図通りになっただけの無茶苦茶なリソースが、将来的にブラウザの糞なソースを補完する機能の進化などにより、本来持っている無茶苦茶さを取り戻すのはむしろ必然でありますよ。
それをして無茶苦茶なソースを記述することに対して責任が無いとのたまうようなベンダーが在るなら、そのベンダーは恥を知るべきです。
◆IZUMI162i6 [mailto]
Re: (スコア:0)
Re:IEでしか動かないってのが (スコア:1)
仕様に沿った HTML 4 または CSS1 の範囲であれば、実はさほど問題がない (HTML 4 については abbr 要素の認識以外では HTML 回りはほぼ完璧で、CSS も CSS1 「のみ」であればやはり問題は起きない) のが実際ですよ。
IE6 は HTML4 + CSS1 までしか謳っておらず、XHTML 1.0/1.1 や CSS2 以降に関しては対応しているとは言ってません。CSS の問題は仕様上 CSS1 から外れる領域 (CSS2 以降) のセレクタの記法等、「未知のセレクタに遭遇したら無視する」という仕様を満たしていないため、CSS 回りにおいて IE hack が発生するというのが現実です。
むしろ IE6 じゃないと困るというのは、IE7 によりセキュリティが強化する目的で行われた仕様変更への追従に関する問題や、JavaScript 回りで厳密にバージョンチェックを行っていた事による (IE4/5.0/5.5/6.0 で処理を細かく振り分け等) IE7 用の分岐路がない、既存動作との互換性保証があるか、という問題とかです。
Firefox や SeaMonkey などでも security fix により 0.0.1 の差で動かなくなるスクリプトが発生するといった事はありますから、メジャーバージョンアップになる IE7 に関して、スクリプト回りを利用している場合の検証コストは常に発生する話です。
Re:IEでしか動かないってのが (スコア:1)
問題なのは「それっぽく見えるからいいじゃん」とやっつけで仕事をしているようにしか見えない方々で、更に問題なのは「IEで動くからいいじゃん」とか考えてる要件定義者も少なくないってとこなんでしょうか。
Java Scriptについては、そこまでローカルの実装に依存しなければならないようなとこまで使わずになんとかならないんかな？
いや、Java Script使ってないんで全然わかんないんですけどね
定期的に修正を発注させるためにわざとそういう設計をしてんじゃねーか？ってシステムが前の職場にあって萎えたりしてました・・。(^_^;;;
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
JavaScript はまともに仕様と言えるものが現状 ECMA-262 revision 3 程度しかありませんが、これは本当に言語仕様であって「ブラウザ (実装系) がどんなオブジェクトを持っているか」とかの仕様ではないのです。つまり document.write() とかも仕様外。C# の ECMA にある仕様と実際に書かれる .NET Framework を前提とした C# 2.0/3.0 とかみたいな乖離がある、という感じでしょうか。(後者の方は違いがヘビーすぎますが、まぁ極端な例ということで)
そういう世界なので、「このブラウザだとこのオブジェクトがあるから」とかいうのはよくある話ですし、「このプロパティが」「このメソッドが」というのも普通にあるという事でして。
だから、世に溢れる JavaScript 入門系の本などでもメソッド/プロパティ毎に「IE6 で使える」「Firefox で使える」といった記述が踊る事になるのです。
さらに、共通で使えるオブジェクト/メソッド/プロパティなど (さすがに w3m-js なんかは無視されますが……) だけでも実装差異等の問題もあり、処理内容によっては細やかな分岐が必要になったりします。
Re:IEでしか動かないってのが (スコア:1)
というか、標準仕様が存在しないものを仕事で使うっつーのは自分なら絶対に避けたいところ。
フラッシュかJAVAアプレットの方がまだいいんじゃ・・・。
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
まぁ、その辺りは結局「Web 標準規格の範囲内」からがっつり外れてしまう物になりますけどね。
Flash 9 で作って携帯じゃ (略) とか、Java Applet にして w3m 憤死とか。
なので、結局アクセシビリティ的な観点からも、Web サービスは最初から HTML のみ、それも画像とかはできるだけ使わずにテキストのみで「そのサービスは実現可能なのか」という点を元に設計する必要があると思いますよ。
Java Applet や Flash、ActiveX といったプラグインを使うコンテンツによるサービス、HTML + JavaScript で構成、HTML のみで構成……と落ちていっても、とりあえず同等の「機能」は提供する (使いやすさは前者ほど高いでしょう) という複合型で。
# アクセシビリティ的再重視では、動画ですら「最終的にテキストに落とせ」という素敵なコンテンツ制作が待ってます。本気でやると泣けますよ。(笑)
Re:IEでしか動かないってのが (スコア:1)
どうなんだろう？HTMLでの作成であれば当然理念としてアクセシビリティは要求されて当然な気がするんですが(というか、割とHTML自体がそういう言語設計になってるよね)、Webリソースを作成と言った時にHTML以外の選択肢を選ぶならアクセシビリティは捨てていいというかなんというか、そんな気がします。アクセシビリティが要求に入った時点で、HTMLくらいしか要件を満たせないってことの裏返しかもですが。
アクセシビリティを考慮するなら仕様が決まっているものを適切にしか使えない気がするんですよね。動作の仕様が決まっていないらしいJava Scriptでは代替情報の提供も困難でしょう。正確な代替情報を提供するには代替されるものが確実なものとしてある必要があるでしょうし。
なので、実際に仕事としてAjaxとかとアクセシビリティとを両立させようとすると眩暈がしてきますね。自分みたいに趣味で書く人間ならそもそもそうならないようにリソースを書きますが、顧客はそうはいかないでしょうし・・だからこそ自分はそれを仕事にしなかったんですけれども・・。
アクセシビリティというのは端末を選ばない必要がありますから、テキストでの代替、たとえばimg要素のalt属性とかは必須なのがわかりやすい例ですけれども、ぶっちゃけｉモードとかで見ても同じ情報(同じ見た目ではなく)が得られる必要があるというのは、そもそもの文書設計の段階でそういうことを考慮してなけりゃ困難に決まってるんじゃないかと。
そういう意味で、実は理解してる顧客がいないことの方が大きな問題なのかもしれません。解ってないけどJISの8341は満たしたいとかそういうなんつーか、アレなところで。あの辺の旗はそもそものところで企業とかが理念を理解して意識を変えて取り組むためのもののはずなんですが。
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
"Web のプロ" が本当に Web のプロかどうかが問題であって……未だに W3C なんて見たことも聞いたこともありませんとか、そういうクラスがプロだと言っていたりしますから。
コンテンツにおいてはアクセシビリティでは text/plain 最強。WCAG (Web Contents Acceccibility Guidelines) なんかでは、HTML のコンテンツも最終的にはテキストに落とせ、とする程度にテキストは最強です。
ただ、ソフトウェア的に意味ベースで解釈するにはマークアップがあった方が負荷が低いといった、HTML の方が何かと便利という点から見ると HTML の方が扱いやすい、という程度でしょうね。
JavaScript の場合は、言語的な動作の仕様は当然ながら決まっています。決まっていないのは Web ブラウザ毎に固有となる実装の部分です。C# の仕様に .NET Framework のクラスライブラリが仕様に含まれている訳ではないのが状況として似ている、ということです。
つまり、実際に C#(JavaScript) を使う .NET(Web ブラウザ上) という環境を想定すると、たとえ C#(JavaScript) の仕様だけを知っていても、実際に使う場面となる .NET のクラスライブラリ (Web ブラウザが持っている各種オブジェクト) を理解していないと、事実上使いものにならないということです。
そして、この Web ブラウザが持っている各種オブジェクトに関しては標準化されたものはないし、W3C も UA に関する仕様を定義する組織ではないため、特に標準化しようという動きはありません。いいとこ DOM 程度です。
これらを踏まえた上で、ユーザビリティとアクセシビリティの両立を常に意識している人であれば、AJAX を使いつつアクセシビリティの確保を行うのは、特に大きな問題がある訳でもないですよ。
WCAG 的には、Web サービスを Flash 等で行う事は否定されていませんが、Flash プレーヤがない場合には「同等の Web サービスを HTML ベースで内容として持て」とあります。よくある「最新の Flash プレーヤをインストールしてください」なんてリンクがあるのは最悪のパターンなんですよね。
こうしたことを当たり前のようにやってくれる制作会社だったら「Web のプロ」だと呼んでいいと思いますよ。
ただし、Flash とかを使わないと実現できない機能を持っていて、HTML レベルではどうやっても不可能である場合にユーザを絞って提供することがダメだとは思いません。それは元々ターゲッティングの違いですから。
ユニバーサルサービスを標榜しつつ Flash のみです、なんてのは話になりませんけどね。
Re:IEでしか動かないってのが (スコア:1)
JavaScriptにもちゃんと言語仕様はあるんですね。誤解してました。
DOM1くらいしか使えないというのはしょんぼりですが、そもそもそれすらも知らずにトライアンドエラーだけで作ってる製作者も多いんでしょうね。
text/plainはリソース単体でのアクセシビリティは完璧ですが、複数リソースでサイト全体が構成されるとき、リソース同士の関連性などメタ情報が欠落することでサイトとしてみた時に若干アクセシビリティが低下する気がします。
Flashなどの代替の話だと、「同等のサービス」ではなく、「同等の情報へのアクセス性の確保」が重要なので、代替となるHTMLのリソースなんかへのリンクでもOKですよね。
Flashの代替で「Flashを入れろ」とかってのは確かに最悪ですな。noframeで「フレーム対応のブラウザで出直してこい」とか書いてあるのと同じくらい酷い話です。
>こうしたことを当たり前のようにやってくれる制作会社だったら「Web のプロ」だと呼んでいいと思いますよ。
逆に、Webのリソースを作って金を取ってるならその時点でプロなので、皆がそのくらいのレベルであって欲しいと思うんですが。
今の状態ではマレーシア製テレビ以下の信頼性しかないところがほとんどで。
しかし、彼らは顧客が満足するものを作るのが仕事であって顧客のサイトを見る人が満足するかどうかはどうでもいいので、やはりそこは要件定義でしっかりしないと駄目なのかと思われます。
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
アクセシビリティに関しては、発注者側の意識も確かに大切です。が、Web 制作会社側が「そうした点に対する考慮はどうするのか」という確認を行ってくるかどうかというのも、クォリティに対する意識があるかどうかの点で判断基準になるかと思います。
# 幸いにして、以前いた会社では「それが当たり前」でしたが……。
JavaScript に関しては、基本的に昔は Netscape、今は Mozilla Foundation が仕様を作り、それを ECMA に提出という感じで国際規格化されています。ECMA-262 辺りを探してみると見つかります。これで Web アプリ向けのコードを書けたらすごいってレベルです。
Flash などでも、たとえば Flash でムービーを提供 (YouTube やニコニコ動画みたいな?) の場合、同等の情報というのが信じられないほど膨大なテキストになったりする (笑) ため、実はかなり非現実的な話なのですけどね。
装飾程度の位置付けで無くても問題ないというレベルであれば、そこまでの説明等は不要ですが、だったら最初から(ry とか。難しいところです。
皆が～というのは当然望ましい事ですが、金を取ってはいても冗談みたいなレベル (1 ページ数百円とか) で発注している業者とかもありますので、実際の作業者としてはこの単価でそこまで考えろというのは酷でしょうね。
# その業者側の意識が足りない、とは思ってます。
Re: (スコア:0, フレームのもと)
まともなエンジニアなら、IE6で動作する事を検収条件にはしません。
例えシェアは少なくとも、FireFoxなどの第三のブラウザでもチェックし、
IEに強く依存した処理が無い事を確認します。困ったことにIE6は多少の
バグを含んだHTMLファイルでも、一見すると正しく表示してしまいます。
IEでWEBアプリケーションの動作確認を行うなんて、怖くて出来ません。
また何のためにWEBアプリケーションにしたのかって視点も重要です。
クライアント環境に依存せず、特定のアプリケーションをインストールする
必要が無いのが利点の一つだったはずです。WEBアプリケーションに
する利点の一つを潰す様な実装をして、互換性がどうのと文句を言うのは
如何なものかと思います。
Re:IEでしか動かないってのが (スコア:3, すばらしい洞察)
（顧客要件はＩＥで動くこと、だという想定では）
君の言う「まともなエンジニア」というのは顧客要件にもないブラウザで動くことを想定して作るってことだよね。
（逆に顧客要件であるブラウザでの動作確認が「怖くて出来ません」だって。）
自己満足のアートと業務システムを一緒にするなっての。
Re:IEでしか動かないってのが (スコア:3, すばらしい洞察)
これはギャンブルなんですよ。
顧客がIE6のみで動けばいいと言ったとしても、それを突然翻してくる可能性なんていくらでもあるわけです。
真に受けてIE6でしか動かないようなものを作れば、あとで痛い目を見るかもしれないし、そうでないかもしれない。
Web標準に従って主要なブラウザで動くように作れば、あとで修正が少なくて済むかもしれないし、無駄に終わるかもしれない。
どちらを選んでも賭をすることには変わりないんです。
手堅い人なら顧客にこの辺りのリスクを説明して、はじめから費用を確保しておくでしょうね。
でも人間、危険を目の前にしないとなかなか危機感が持てないんだよなぁ。
Re:IEでしか動かないってのが (スコア:1)
Web 標準に従って HTML 5 が勧告になったとしても XP は 2014 年までサポートされ、IE6 もサポートされ続けるわけです。
Web 業界の中で Netscape Navigator/Communicator 4.x を「もういい加減いいよね」と言われるまでにどれだけ時間がかかったか。未だに「使ってる」なんて言われる場面すらある。そういう状況です。
当然ながら IE6 は HTML 5 で仕様に含まれようとしている canvas 要素等など知りません。HTML 4 の abbr 要素ですら認識しないのです。こんな理由で HTML 5 は結局 2010 年を超えても採用できない、となる可能性は高いです。
こうした状況において「Web 標準に従って」なんて言っても、古い仕様に沿って作る必要があり、もっと効率的に実現可能な新しい仕様があったところで使われない、使えない、となってしまう訳です。
しかしクライアントの要件としては、最新の高機能なブラウザ系でしか使えないような機能を必須とされたりする。こんなのはよくある話なのですが。
# Gmail は w3m で十分に使えるか、でもいいですが……って、Google は別に Web 標準には準拠してませんか。
Re: (スコア:0)
ダウト
残念ながら現状ではオッズが違いすぎる
どちらに転ぶかわからんなんてのはむしろ恵まれた状況
Re:IEでしか動かないってのが (スコア:3)
そのときの経緯をコロッと忘れたふりして IE7 対応改修費用をタダにしろ、という不良顧客がウヨウヨいる。
まともなシステム屋だったら不良顧客を増長させるような不用意な発言は慎まなければならないし、
発注側の人間だったら、無理難題を押し付けるようなおのれの業務を少しは恥じて頂きたい。
Re:IEでしか動かないってのが (スコア:2, 参考になる)
ヒント: W3C 等の標準仕様で可能な機能の範囲
要求機能と配布コストの低減といった辺りで「どうせ Windows を導入する」という前提に立てば、その時点での IE で動作する (そして将来的に「セキュリティ面に問題がある」という事で機能が変更されるかもしれない!) アプリケーションを構築することは十分にあり得ます。
HTML を使う以上、「ブラウザは HTML が壊れててもなんとか表示する必要がある」と仕様に明記されているためであって、これは IE が悪いという話ではありません。というか、Firefox でもエンドユーザはエラーを見る機会はまずありません。
そして HTML Validator 等は「出力された HTML の妥当性」は確認できても、Web アプリの動作として妥当かは確認できません。現実に動く環境でなければ "Web アプリ" のテストなんてできませんよ。
SGML アプリケーション化された HTML 2.0 以降とその前の HTML では全く仕様が異なり、その前の HTML を前提としたようなブラウザでも十分に動き、Netscape/IE 独自拡張を廃した Web ブラウザでは、そもそも Web アプリケーション自体が成立しません。
フォームすら使えるか分からないのにどうやってデータをサーバに送るのか、JavaScript どころか cookie すら保証されない環境でどのように使うのか。cookie に対応していてもセキュアフラグなんて知りません、なんてのはどうするのか。
こうした辺りを考えると、あらゆる新旧合わせた Web ブラウザに適合する Web アプリなんてものは存在しえず、ある程度の要件を定義する必要があります。最低 HTML 4.0 程度に対応している、とか。(HTML 2.x or HTML 4.0 以降でないと仕様上国際化対応が考えられていません)
まして、ActiveX によるアプリケーションの配布コストの低減を狙って開発されたソフトは、開発ターゲット自体が "Windows 環境で IE 上" であって、"Windows を含む様々な環境" ではありません。前者を基準に設計してくれ、という依頼を受けた場合に後者で動作しないから責めるというのはさすがにおかしいでしょう。
「Web アプリ」の検収条件として IE6 で動けば ok というのは確かにおかしいです。しかし、「Web を利用した Win アプリ」の検収条件としては十分なのです。その辺りを理解せずに文句を言ってるだけにしか見えませんよ。
Re:IEでしか動かないってのが (スコア:1, すばらしい洞察)
> IEに強く依存した処理が無い事を確認します。
そのチェックにかかるコストは誰が負担するんですか？
そもそもそのコストをかけるだけのメリットがないと。
企業は美学のために活動してるわけではないのですから。
Re: (スコア:0, 余計なもの)
当然お客様も含め、関係するいろいろな人が負担するんじゃないでしょうか。
> そもそもそのコストをかけるだけのメリットがないと。
「メリットがない」などと断じられるものではないでしょう。
あなたがメリットを感じないというだけなら分かりますし、別に良いんじゃないでしょうか。
> 企業は美学のために活動してるわけではないのですから。
そうでしょうね。美学のために活動する企業があってはならないとは思いませんが。
ちょっと視野が狭すぎやしませんか？
自分の回りではそんなことやってらんないんだよ！と言うのならいいんですけど。
Re: (スコア:0)
学生さんでしょうか？
顧客から「IE6対応でよい」と言われても通常にエンジニアであれば「FireFoxなどでの動作保障はしなくてもよろしいですか？」と聞くと思います。
ただ、往々にして顧客側の予算がない or 実際に使用しているユーザがいないなどで結果的にIE6に収束している場合がほとんどです。
顧客から予算が出ない状態で、それでもFireFoxなどに対応したいのであれば、あなたのような考え方の方が毎日サービス残業しまくって、全環境に対応してくれるのが理想ですが、それ
Re: (スコア:0)
受注できたことがないヘタレＳＥとしては
＞ちょっと視野が狭すぎやしませんか？
＞自分の回りではそんなことやってらんないんだよ！と言うのならいいんですけど。
という方に顧客を納得させる上手いセールストークを教えていただきたいものです。
#バージョンアップで動かないと文句言ってくるくせに………
#最初から言っているでしょ、IEだけでしか動かないように作ると
#初期投資は安くすむけどあとで後悔するよって
クレームが来そうなのでAC
ここにもモンスターカスタマーが（笑） (スコア:1, すばらしい洞察)
いまどき予算は削られる事はあっても乗せられる事なんか無いのに、どうして、ユーザの
少ないブラウザの動作確認も義務だみたいな話になるんでしょうか？
リソースは限られてるんですよ。そのくせ、カスタマーの責め立てる声ばかり大きくなっ
てるんですよ。どうしたらいいんですかね？予算が足りないんなら、あとは無償労働を提
供して解決せよ！て事ですか？
ちょっとだけですが、モンスターピアレンツに悩む先生や、モンスターペイシェントに悩
むお医者さんの気持ちが解った今日この頃。
Re:ここにもモンスターカスタマーが（笑） (スコア:1, すばらしい洞察)
現場側から弾が飛ばしてくる事なんですよ。そりゃ、その人は立派な方で「私はそ
うやっています」って言うから、みんなは「それで当然」と思うようになる。
シェアの少ないブラウザに対応しても当然、テストをやって当然…でも、利用者は、
コストが上がって当然とは思わないんですよ。
Re: (スコア:0)
どこの業界でも当たり前のことで、顧客満足が得られないなら叩かれて当然です
これが擁護されるなら、その業界はどこか腐っているものです
逆に叩かれ始めている業界は、顧客のことが本当に考えられ始めている業界であるとの一つの指標になります
これがイヤなら、政治屋や金余りとお友達になってじゃぶじゃぶ金が降って来る様にして、どんどん腐り果てなさい
みんなが揃ってぬるま湯に浸かる方向に向かうより、誰かが抜け駆けする前に自分が抜け駆けしなさい
Re: (スコア:0)
いですけど。
支払いなりのリーズナブルなサービスを提供すれば、提供者の義務は終了です。
最初の段階でIE6のみって条件が入ってる事にお客さんも同意されている筈なんで
すけどね。後から「顧客満足がうんぬん」なんて理屈こねられてもねえ。そういう
人に限って「お客は神に等しいんだから、とにかく言うこと聞け！」みたいな横車
を押そうとするから困ります。
Re: (スコア:0)
扱ってこなかったというところに問題があるかもしれませんな。
端的な例を言えばヤマダのヘルパー販売員ですかね。
顧客にモラルが無いといえばそれまでですけど、それを拒否できなくても泣き入りするしかないという
現状がある限りこういうことは無くならないでしょうね。
Re: (スコア:0)
そういうお前だって、別に死んでもいいよと思ってる業界や業種があるだろう？きっと。
Re: (スコア:0)
資本主義の先進国では日本ぐらいだと思うけどなー、食わせてもらってる側が偉そうにしてる業界がまだまだ多いのは
そりゃガッチリと契約が結ばれる様な所は違うかもしれないけど、たいていのことはなぁなぁで済ませて方々無駄だらけ
本当の顧客第一主義は欧米じゃ当たり前の感覚だぜ
Re: (スコア:0)
まあ「訴訟」という名の「交渉」手段がありますがｗ
Re: (スコア:0)
多分#1292831は分かって書いてるよ。#1292617の書いた「顧客第一主義」は、本当の「顧客第一主義」ではないってこと。
欧米では、人々の満足させる最高のものを作りたいという人はいる。ただ、それに見合う対価も要求する。欧米の「高級」と言われる物は、そんなもの。要求が高ければ、それに見合うものを作ってくるけど、それなりの対価も要求する。
そこで求められる顧客満足度とは、得られた物やサービスが対価に対して十分であったかということ。そこでは求めている以上のサービスをす
Re: (スコア:0)
クライアント環境がほとんどWindowsということであれば、標準でIEが使用できるわけで、
わざわざ Firefox での動作を保証しなければいけないと考える方が不思議です。
(お客がFirefoxでの動作をも希望し、かつ相応のコストを負担するなら別ですが)
業務用の環境では、環境を限定することで、ユーザも管理者も(もちろん作る人も)
皆幸せになれることの方が多いでしょう。
あるアプリがFirefoxで動くの動かないなんてことは、その企業の利益には関係無いどころか
そんなことに関わっていること自体が企業にとって損失で
Re:IEでしか動かないってのが (スコア:1, すばらしい洞察)
「IE7とIE6でレイアウトが崩れるから困った」などという意見は、
理論上存在しないか、存在していることがミスなのかどっちかなのでしょうね。
是非そういう意見の人を黙らせてください。
うちの職場の基幹システムが今になってもWindows NT4でしか動かないのは
こういうメンタルの人が開発してるからなのか、と妙に納得できました。
要するに「業務用の独自仕様のソフトだから低予算で妙な実装してても動けばオッケー」って言いたいんでしょ?
Re: (スコア:0)
こういうメンタルの人が開発してるからなのか、と妙に納得できました。
＃だけなので、AC