米国著作権局がIE依存サービスの是非を意見募集 149
ストーリー by yoosee
そこまで考えてくれるだけましだよね 部門より
そこまで考えてくれるだけましだよね 部門より
CNET Japan の記事によると、米国の著作権局にて現在構築中の Web サービスが
IE5.0 以降のみ対応になる可能性があるため、こうしたサービスが特定のブラウザのみ対応としていいのか意見を募集しているそうです。
これはシステムで利用している現行の Siebel7.7 の問題で、将来的には Firefox や Mozilla にも対応する予定としていますが、Opera, Safari などに関しては言及が無いようです。
詳しくは、CNET英語の記事や、US著作権局の告知を参照してください。
意見は6部用意して郵送あるいは手渡しで8月22日必着です。
UPS や Fedex 経由では受け付けていないとのことです。
日本からアメリカの著作権情報を扱う技術者の皆様ご注意あれ。
あえて「いいかも知れない」と言ってみる (スコア:5, すばらしい洞察)
Transitional準拠で作ってますよ。その上で。 このサービスを稼働させるにあたって、IE依存で構わないか
どうか?という問いに対して脊髄以外の大脳とかその辺もちょっと
使って考えてみて、「IE依存でも構わない」という解もありえる
んではないでしょうか。
ないということはないだろう
一日数回、といった頻度では利用しないだろう
思われる)に、「しゃあねえなあ」っていいながら利用する時だけ
IEを使ってもらってもそれほど大きな問題ではないだろう
それほどインセンティブがない
これらの理由から、このシステムを実現するのにSiebelが必要で、
そのSiebelがIE依存にならざるを得ない(標準準拠するにはかなり
のコストがかかる)のなら、そんなに頑張らなくてもいいんじゃ
ないか、という結論を導いてみます。思考実験として。
Re:あえて「いいかも知れない」と言ってみる (スコア:1)
というのは置いておいて、いつ潰れるかわからない会社の製品をいまさらつかうのは選択として今一だと感じます。だいたい、Siebel の先行きがあぶないのは数年前からわかってたんだしね。
life is too short to hate each other.
Re:あえて「いいかも知れない」と言ってみる (スコア:1)
クライアントソフトウェアを絞るという解決策も仕方のない
場面というのはあるでしょう。一律に「規格に沿え!ブラウザ
を限定するな!」と叫んでも、そもそもほとんど縁のないサー
ビスの話だし、意味がない。見合うだけのメリットがあれ
ば、顧客も納得できるはず。それが納得できるかどうか、
ちゃんと顧客を向いて聞くという姿勢も大変良いと思います。
ブラウザに依存しないで (スコア:4, すばらしい洞察)
ブラウザに依存しないでください。
HTML4.01やらISO-HTMLやらメジャーなものなら何でもいいですけど、少なくとも規格に依存してください。
「このブラウザは対応してます」とか「このブラウザで確認しました」ということをしないでください。
結局困るのは作者と使用者と業界です。
何業界かしらんけど。
Re:ブラウザに依存しないで (スコア:3, 参考になる)
アップした瞬間に書き換える腐った鯖も結構あるんですよ。
Ver違いなHTMLに書き直されたり不明とみなされた部分を
ごっそり消されたり酷い場合は間違ったタグに入れ替えられたり。
#
#バックアップは必ず用意しておきましょう
#
#状況はいつも最悪、でもそれが当たり前
Re:ブラウザに依存しないで (スコア:2, 興味深い)
これをしてはいけない理由が解らないのですが、教えていただけますでしょうか?
自分はサイトを作るときは、HTMLやXHTMLの規格に合うように記述し、
かつ、ブラウザでの確認もしているのですが。
ブラウザが規格に合っていない以上、ブラウザでの確認はしないといけないことが多いと思います。
#人間がブラウザで読まないページは除く
もちろん、ブラウザでの確認はしなくて済めばその方が良いというのは解ります。
しかし、確認を禁止する必要、確認しない方が全体が有利になる理由が解りません。
御教えいただけますか?
Re:ブラウザに依存しないで (スコア:1)
これは試験したくないという、作り手側のエゴでしか無いのでは?
> しかし、確認を禁止する必要、確認しない方が全体が有利になる理由が解りません。
別に禁止したコメントではないと思います。わざわざ「対応してます」「確認しました」と書くなといってるだけかと
もっとも、私はこの手のコメントはケースバイケースだと思ってます。
標準規格であっても、各ブラウザの実装状況に差がある部分に依存しまくるぺージを作るなら対応状況書くのは止むを得ませんよね。
独自規格ならなおさらです。
(そのようなページを作る必然性はおいて置きます。)
後、枯れた標準規格で実現可能なページに「このブラウザに対応」とか書かれると頂けない(し少し痛い)ですが、
個人サイト、趣味サイトだったら私はアリだと思います。
Re:ブラウザに依存しないで (スコア:1)
敢えて私から言わずに火種になってレスが付くかなとも思ってたのですが、直接聞かれちゃったのと、今日は暇だったのでレスってみちゃいます。
まず、この意味を考えてください。ブラウザで確認したからこのブラウザはOKですと公認する訳です。そこでHTMLの意味がなくなっちゃうと思う訳ですわ。
HTMLは文書を電子化するためにある訳です。今はその本意が失われつつありますが、そこが「ダメ」だと思ってます。
文書を電子化するということは、ただ単に0や1にデジタル化するだけではなく文や単語に意味を持たせるところに意味がある訳で、それが検索に使われたり整理するために使われたり色々使い勝手があると思います。これがHTMLの本望だと思ってますし。
コンピュータ自体が文章自体の「意味」を理解し、それを人間に提供するために一番スマートな方法を規格として提示していると思う。
デザインや操作を含めてHTMLを提供しようとしてる人が多いが、HTMLにそんな機能自体がほぼない。
それをこのブラウザなら出来るとか、その手法を裏技と呼んでみたり、すでにHTMLの文法に沿ってなくなっている事が多い。
HTMLは意味を持たせるのが本望であるだけなはずだ。
だからこそ、CSSでデザインは分けなさいと。(たぶんこれはW3Cが後でそう決めたんだろうが)
利便性や見た目を考えて作者は非HTML準拠なHTMLを作る事が多いが、その杞憂が使用者を苦にして、作者も苦にしてるのではないか。
で、質問に対しての回答だが、
ブラウザで確認する事こそ意味がないと思う。それをするからこそそれはそのブラウザでの見ただけにしかならないと思う。規格に沿っているかどうではでなく、ブラウザに沿ってるからだけだからだ。
せめてHTML-lintとかととでも遊んで欲しい。
ブラウザ=IEという意味が分からない。(←これは偏見だが)
Re:ブラウザに依存しないで (スコア:1, 興味深い)
大半の利用者にとって、HTML規格云々はどうでもいいことだと思いますよ。
どのブラウザのどのバージョンだと正しくサービスを受けることができるのか、
それが利用者にとって重要なことなんじゃないでしょうか?
そして、その情報を案内として表示することに意味があるとは思いませんか?
Re:ブラウザに依存しないで (スコア:1, すばらしい洞察)
「こら、URLをそのまま書くな! ちゃんとURLであることをマークアップしろ!」
「改行記号を見た目の整形のために使うんじゃない! これじゃあどこからどこまでが段落なのか効率よく抽出できないじゃないか!」
などなど。期待してますよー
ツッコミ (-1: オフトピック) (スコア:1)
プレーンテキストのファイルでも、電子化していることには変わりありません。HTML という意味付けを行う形式を敢えて選択しているからには、仕様に沿って意味付けを元にマークアップしましょう、という方が正しいでしょう。ただ、HTML は一つの手段でしかなく、一番スマートな方法だとはとても思えません。(規格化中の XHTML 2.0 では、かなりスマートになっていってる感じはありますが)
CSS によりデザインを分離せよ、と言うことを明確に打ち出したのは HTML 4.0 においてですが、かなり早い段階から想定していることは間違いありません。
例えば、HTML 2.0 Spec. [ietf.org] において LINK 要素の説明中でスタイルシートについて言及しています。(HTML 2.0 はまともに規格化された最初の HTML Spec. です)
また、ストーリー本来の話から見た場合、HTML で本来想定している自然言語で記述された文章に対して意味付けしていくマークアップではなく、申請書などの、一応自然言語では記述されているが、文章の体裁を取っていないものに対しての話、つまり Web を利用したサービス、Web アプリケーションを一切無視しているように思われます。
XForms 使えよ、という話がない訳ではないですが、現実的に XForms が利用できる UA を考えたら、それは非現実的な話です。そうすると、HTML のフォームを利用するのが現実解と言えるでしょう。
この場合、意味付けによるマークアップだけではなく、提供されるサービスに関して実際に利用可能かどうか、使いやすいかどうかのチェックを行う上でも、UA による確認は必須です。
また、自然言語で記述されている文章の HTML であっても、複数種類の UA によりテストすることは無駄ではありません。マークアップ的にアクセシビリティが確保されていることが明白であっても、その Web サイト、コンテンツに対するユーザビリティについては、実際に UA を利用して試してみないとわかりにくい部分も多々あります。
また、自然言語で記述されているテキストであっても、通常エンドユーザに対して提供されるのは文書だけではなく、スタイルシートの指定を反映したレンダリング結果です。となれば、各種 UA でのレンダリング結果も当然 UA を利用して確認する事となるでしょう。(視覚/聴覚含む)
これらを一切無視して、UA での確認は不要と言い切るのは妄想であるとしか思えません。
Re:ブラウザに依存しないで (スコア:1, すばらしい洞察)
#最近は知らないが昔は酷かった
Re:ブラウザに依存しないで (スコア:1)
そうそう、これがまた微妙な気がしますね。
本人が意識してないからタチが悪いっすよね。
IEやfirefoxでばっちり動きますとか言われてもやっぱり腹が立ちます。
結局、間違ったHTMLが流通しすぎてそれが規格以上の立場になってしまってるとも感じてます。
Re:ブラウザに依存しないで (スコア:1)
スタイルシート何種類もつくって、javascriptで振り分けて・・・
とおもうとjavascript使えないブラウザはどうすんだ、かorz
Re:ブラウザに依存しないで (スコア:1)
Re:ブラウザに依存しないで (スコア:1)
ふつー素直に SSI/CGI で出せばいいだけ。
あとは CSS Hack (バグを利用して特定 UA のみ解釈させる/させないなど) とか。
Re:ブラウザに依存しないで (スコア:1)
Re:ブラウザに依存しないで (スコア:1)
それは逆。
-moz-* プロパティとかを利用する、とかいう話ではなく、特定 UA ではこのプロパティを指定するとバグを誘発してひどいことになるから、特定のプロパティを無視させる/補正を行うためにやるのです。
現実的に、負荷を考慮すると SSI/CGI を利用できない場合などもありえますので、そういった場合に 1 つの CSS で WinIE5/5.5/6、Gecko ~1.3/1.3~、Opera 6/7/8、Konqueror、Safari、さらには携帯まで、印象を変えずにそれぞれに適した表示を得ようとすると、そういう世界になってしまうものですよ。
Re:ブラウザに依存しないで (スコア:1, 参考になる)
> バグ抱えてるからIEでしか動かないと思った方がいいと思うん
> だけどどうよ?
クライアント(依頼主の方)がIEしか使ってなくて、それで製作側
がIEのバグやらヘンな挙動に対応すると他のブラウザでの動作を
確認してるヒマがなくなる。
っていうのは良くある。
確認できなくなるというより、IE以外のブラウザでひどく使い勝手
が悪くなってしまったりとかだけど。
SSL接続状態でヒストリバックするとフォームの内容をキャッシュ
しないのはいいとして、リロード時に必要なパラメータ送らないの
はどうなのよ。それでセッション外れたりするので、未だにSSL
&フォームのサイトでJSで戻る/進む/リロードを表示しない別
ウィンドウを開いて使わせるサイトが多いのはIEのせい。
# クッキーにすると複数ウィンドウ開かれたときメンドイので。
HTTPヘッダの送り順でちゃんと解釈したりしなかったり、ついでに
IISだったりすると勝手にヘッダ削除しやがったりと、さらに
ひどいことになる。
# 疲れててまともな文章かけないのでAC
Re:ブラウザに依存しないで (スコア:1)
ということは、input[type=hidden]なんかでセッションを特定するキーをやりとりしてるのだと思いますが、これだけをCookieに移せば済む話ではないかという気がしますが、
とあるので、そこにセッションの状態も特定するキーか、情報そのものが保存されているのでしょうね。
ということは、POSTするデータをちょっといじれば、色々とできそうなので、Webアプリの作り方の方として問題があると思うのですが。
lint (スコア:1)
半自動的にってのがポイントで、毎日あるいは、受け入れ試験時に走らせるだけで少なくともなんらかの規格に準拠した文書かどうかのチェックはできる気がします。
Re:lint (スコア:2, 参考になる)
それなら素直に W3C HTML Validator [w3.org] を呼んだほうが間違いなくいいと思う。
Another HTML lint はあくまで一個人が作成したアプリケーションに過ぎないけど、W3C HTML Validator ならそもそもの Spec. を書いているところで提供しているサービスなのだから。
しかし、本格的に定時自動チェックとかやるなら、Another HTML lint などもそうだけど、ローカルに落としてきて動かさないと迷惑すぎ。
Re:lint (スコア:1)
Re:ブラウザに依存しないで (スコア:2, 興味深い)
http://www2.alc.co.jp/ejr/index.php?word_in=site&word_in2=%82%A0%82%A2%82%A4%82%A6%82%A8&word_in3=PVawEWi72JXCKoa0Je
http://dictionary.goo.ne.jp/search.php?MT=%A5%B5%A5%A4%A5%C8&kind=&kwassist=0&mode=0&jn.x=29&jn.y=19
Re:ブラウザに依存しないで (スコア:1)
「作り手の意図通りのHTML文書が出来た事」ってのは見た目の話ですか?
固有のブラウザで「確認」して「OK」を出しちゃうのが問題だと思います。それって結局コンパイルが通ってない訳で、実行ファイルは生成されない訳ですよ。
文章が意味を持つと、コンピュータが即座に判断し、ユーザが簡単に検索したりして楽にできる機能なわけだと信じてますが、これ自体が作用できてないのは見た目だけにこだわってるそこに問題があるんだと。
Re:ブラウザに依存しないで (スコア:1)
それと、「サイト作成側」ってウェブページ作成に携わっている人のこと?それともサイトを通してサービスなり商品なりを提供している人のこと?
ここらへんをごっちゃにしていると話が空回りするばかりなんだな。
大人なんだからさあ (スコア:3, おもしろおかしい)
IE以外のブラウザがIEに準拠すればいいのじゃなかろうか。
Re:大人なんだからさあ (スコア:2, 参考になる)
とか、今回のストーリーにはそれなりの事情があるわけだが
とりあえず親コメントに「アホかいな」くらいは言ってもバチはあたらんだろうな。
と思いつつぶっちゃけてみるのだが
HTMLというのは「文書構造を示すための」規格で、それ以外の部分は非推薦になったりと
標準であるがゆえ、枝葉をとっぱらって作られているという印象がある。
ところが現場にとってHTMLとは文書構造とか以前に「Webサイトを記述するための」ものでしかないってところに
W3C側と利用者側の目線のちがいがあるんだよな。
実際独自拡張はIEの専売特許ではなく、mozillaベースになった今は知らんけど
Netscapeにも結構あったわけで。
ドキュメントサイトみたいな構造のはっきりしたものならともかく
画面じゅうにリンクやボタンが敷き詰められたオンラインショップなんかで
文書構造なんて考え方はかえって不自然。そういう点、とにかく機能をと発展してきたIEのHTMLは
とても正しい拡張だったと言えなくもない。
標準だから倣うべき、ではもうダメだな、という実感はあるよ。
いたずらにIE依存のサイトを作る連中の神経は疑うが、
それとこれとは全くの別問題。
IEのUserAgentの値 (スコア:2, 興味深い)
ご存知でしょうか。
かつてはMozillaでしか表示できないウェブサイトが多く、IEでは
味気の無いデザインで表示されたり、最悪、弾かれて見れないことも。
そこでMSはMozilla(compatible)を名乗ることで、Mozilla向けサイトを
表示していたわけです。
IEがシェアを広げることができたのは、Windowsに標準装備したと
いうこともあるでしょうけど、当時のブラウザのシェアを寡占する
Mozilla(Netscape)向けのサイトも表示できるようにしたことも
重要な理由です。
IEのほうがMozillaに擦り寄って合わせていた時期があったわけです。
気がつけばMozilla4.0よりもIEのほうが圧倒多数になってしまった
わけではありますが。
Re:IEのUserAgentの値 (スコア:2, 興味深い)
歴史的経緯。Web サイト向けではなく、プラグイン向けです。
Netscape 用のプラグインが Mozilla/x.y で始まっていない UA では動作しなかったため、これらを利用できるようにするために Mozilla/x.y compatible を名乗りました。
Mozilla/2.0 や Mozilla/3.0 compatible の時代ですね。
IE2.0 (初期の Windows 95 Plus! インターネット接続キットとかに含まれる) か 3.0 辺りで名乗り始めていたように記憶しています。
Re:大人なんだからさあ (スコア:2)
準拠されない標準よりも、圧倒的シェアを持つ非標準に準拠した方がいいって、
誰でも考えますよねえ。
Re:大人なんだからさあ (スコア:1)
とかいいつつ、
> 準拠されない標準よりも、圧倒的シェアを持つ非標準に準拠した方がいいって、誰でも考えますよねえ。
非標準だって認めてるんじゃ、議論にもなりゃしないのでは。
#世の中にはIEやFirefoxだけではなく、クローラや検索エンジンといったものもあることをお忘れなく
Re:大人なんだからさあ (スコア:1)
キミの脳内と現実をいっしょにしない方がいい。
目の前のマシンで動かすだけならキミの言う通りでも間違いない。
しかしメンテの事や数年先を考えたら、結局標準規格に準拠する方が楽なんだよ。
それに最近は、小さい商用サイトでも標準依存を求められる事は結構ある。
サイトにもよるがアクセス解析すると、だいたい十人にひとりかそれ以上はIEじゃない。千人なら百人前後かそれ以上。
一割にも及ぼうというお客さまをまったく無視できるわけがないでしょう?当然、全部は無理でもある程度は対応しなくちゃね。
で、その基準として「標準規格」の存在はうってつけなんですよ。
207 条への対応は大丈夫なのか (スコア:3, 参考になる)
アメリカでは、公共機関の Web サイトに関してはリハビリテーション法 508 条 [section508.gov] (簡単に言うと W3C WAI WCAG 1.0 [w3.org] A クラス/一部 AA や AAA クラスを含む) への対応が必須のはずなのだけど、その点からは見ると大問題に思えるのですが。
一応、特定 UA 依存の機能やスクリプト言語を必須にすることなどはこの辺りからもできないはずなのだけど。
正直、この辺りから突っ込めば比較的容易に IE 専用という辺りは潰せる様に思えます。この辺りを根拠に、lynx で申請できないぞ! なんてつっこむのもアリかと。
# 政府機関に納入する機器が Web インタフェースを持っていると 508 条に対応するのが必須だったりする位なのに……。
みんなSiebelがいけないのか (スコア:2, 参考になる)
#SiebelはSafariには非対応ですか。そうだとしたら残念です。
Re:みんなSiebelがいけないのか (スコア:1, 参考になる)
Webインタフェースに関して、既存のどのHTML規約にも準拠していない点を指摘したところ、「仕様です」と返答されました。
どうやら今後もHTML規約に準拠する気はないようで。
技術屋の良心からお客様にンなものを提案出来るワケもなく…
# ヘタレなコン猿だからAC
アンケート取るだけ偉いよね (スコア:2, すばらしい洞察)
そんなこと夢にも思わない組織だって多いでしょうに。
本家記事 (スコア:1)
コメントが少ないのが意外です。もっとフレームになりそうなものですが……。
/.configure;oddmake;oddmake install
IE x.x 以上って (スコア:1)
例えばIE5以上に対応していると謳っているサイトの言う「IE5以上」って、どこまでを指すんでしょうね。
一番ありそう。バージョンが上ならIE5で表示できるページは表示できるだろうと安易に期待している。
最新ってIE6だっけ?途中のマイナーバージョンはどうするんだろう。
本当にそんなこと言っていいの?将来、IEのレンダラが大幅に変更されるかもよ?
不可能。仮にIE100とかもし出るとしたら、もはやHTMLなんて対応してないと思うけど。
Re:IE x.x 以上って (スコア:2, おもしろおかしい)
というか2は実現がすごく困難、マイナーバージョンだけでなく、修正の有無やOS,.Net,DirectX等の順列組み合わせで
それこそ自作PCの構成の如く無数のパターンがある。
3と4はタイムマシンが無い限り検証できないから確認不能でしょう。
まあ、規格は守るべきだけど、現状の最良策は
IE5/6、FireFox、Opera、Safari、NetFront全てOKでHTML4.01に9割方準拠しているページを目指す事でしょうか
見た目では味気ないページになりがちですが。
#
#そして変な鯖や無茶なクライアントに関わらない(無理
#
#状況はいつも最悪、でもそれが当たり前
Re:IE x.x 以上って (スコア:1)
まぁ、実際のところ IE5/5.5/6 かと。
混在させちゃうとエンジン自体は新しくて互換モードとかで動くとか、微妙に挙動が違うので、仮想マシンにそれぞれの環境を用意してテストするのが普通です。
IE5 以降っていう表記の微妙なところは、MacIE5 の存在な訳ですが。
さいきんはあんまりみないけど (スコア:1)
ものによっては、IEじゃなくてもそこそこ見れたりするんだけど。
ブラウザ側で偽装するのもアホらしいし。
Re:さいきんはあんまりみないけど (スコア:1)
Re:すでに (スコア:2, 参考になる)
ビューアに関しては特定のシステムに独占されているわけではないと思うのですが。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
著作権予約システム (スコア:2, 参考になる)
さて、それより、
違法コピーされた場合の著作権関係の証明が可能になるという目的からすると、著作権局からだだ漏れになったりすると大変なことになりそうな気がする。
作品名と製作者と発表(予定)年次の登録だけではなさそうだし。 x
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:すでに (スコア:1, 興味深い)
規格化されたものであれば、ある程度はしょうがないかなと思っています。
あるだけマシ(なのか?) (スコア:1)
Re:何のための規格なんだか (スコア:2, 参考になる)
お尻 p ですか。:)
別に新しい版を使ってもまったく問題ないはずですが。ただし Strict で。
Frameset/Transitional だと色々ゴテゴテと付いたりするので、シンプルにする上でも Strict でいいかと思う。普通に書けば、Transitional じゃないと困る、なんてことはそうそうないですし。
スクリプトの利用は、補助的に利用しやすくする上では重要な技術なので、一概にスクリプト = 悪と決め付けるのは短慮。必須なシステムとするのが悪なだけ。
Re:何のための規格なんだか (スコア:1, すばらしい洞察)
#Ajaxを苦々しく見守っているのでAC
Re:何のための規格なんだか (スコア:2, 興味深い)
そもそも、その性質上 Ajax は JavaScript 必須な訳で、その時点でアクセシビリティの観点から見た場合、Ajax だけでサービスが提供されているなら悪な訳ですが。
アクセシビリティにまともに配慮されたコンテンツの場合には、当然スクリプトが有効だろうと無効だろうと、同等のサービスが提供されることが基本です。従って、無効であれば無効なりに困らないようにされている筈なのです。
この辺りは JIS X 8341 ファミリ (Web コンテンツアクセシビリティガイドライン) の辺りから突っ込んで対応させるのが、国内のサイトであれば比較的簡単でしょう。
# いかに自己責任の範疇とはいえ、実行ファイルを起点としたセキュリティの綻びが (略) なんて思った訳ですが。