問題タブ [web-standards]

私は最近、主要な Web サイトのほとんどがW3C のマークアップおよび CSS 検証テストに合格していないことを知りました。では、Web 標準に従うことは本当に重要なのでしょうか?

Web 標準に対応する必要がある非常に大規模な ASP.NET プロジェクトがあります。アプリケーションには次の 2 つの部分があります。1.) ユーザーがサイトを「構築」できるようにする管理部分 2.) ユーザーを構成するフロント エンドサイト (多くの Web コントロール、マスター ページ、ユーザー コントロールなど...その多くは単なるコードです)

このプロジェクトで Web 標準を利用するための推奨事項は何ですか? MVCをもっと調べるべきですか？私は MVC で何もしていませんが、デフォルトでわかりやすい URL をサポートしているようです。

既存の大規模な ASP.NET アプリケーション/サイトでこれを行った人はいますか?

前もって感謝します ：-）

IE 6+、FF 2+、および Safari の Quirks モードと Standards モードの両方で動作する必要がある、再利用可能な ASP.net サーバー コントロールを開発しています。

コントロールは、高さと幅の 2 つのユーザー定義可能なプロパティを公開します。これらの属性は両方とも、パーセンテージまたはピクセル値として定義できます。

コントロール内には、ナビゲーション バーとコントロール コンテンツを含む 2 つの列 Div があります。コンテンツがコンテナーよりも大きい場合、オーバーフロー スタイルを利用するには、列を Div にする必要があります。以下のプロトタイプ コードの例を参照してください。

私が遭遇する問題は、パーセントベースの高さを使用する場合の標準モードで、期待どおりの div がそのコンテンツと同じ大きさしかレンダリングされないことです。この問題を解決するには、JavaScript を使用するしかないようです。

これにより、コントロールが AJAX を使用して非同期に再レンダリングでき、高さが同期しなくなるという問題が発生します。

私が達成しようとしていることは不可能ですか、それとも間違った場所を探していますか?

日中はフロントエンドの Web 開発者ですが、オフの時間は C、Objective-C、Python などの他の言語に手を出しています。最初に Web 開発を始めたとき、Web アプリケーションのアイデアはまだ始まったばかりでした。

それ以来、SproutIt の SproutCore と 280 North の Cappuccino (+Objective-J) という 2 つの素晴らしいフレームワークが登場しました。SproutCore は、Apple の MobileMe アプリケーションと 280 North がリリースした 280 Slides に使用されています。これらのアプリケーションはどちらも素晴らしく、Web で何が可能かを証明しています。そのため、勢いが変化しています。デスクトップ アプリケーションのように見え、動作する Web アプリケーション。

私の質問は次のとおりです。Web ベースのアプリケーションは、マークアップ (コンテンツ)、プレゼンテーション (デザイン)、動作 (機能) の分離という Web 標準に従うべきですか、それとも従わないべきですか?

ソースコードを見ていないので、SproutCore についてはわかりませんが、280slides.com にアクセスして JavaScript をオフにすると、基本的にすべてが消えてしまうことはわかっています。意味のない言葉がいくつか残っています。

はっきりさせておきますが、280 Slides などの Web ベースのアプリケーションは JavaScript をオンにすることを意図しており、JavaScript なしで機能することを意図していないことを理解していますが、私の日常の仕事では、クリーンなマークアップを作成し、コンテンツ、プレゼンテーション、および動作を分離して、私たちのサイトとアプリケーションは、できるだけ多くの人が使用できます。

W3のEXI（効率的なXML交換）が標準化される予定です。それは「最後のバイナリ標準」であると主張しています。

これは、処理と保存用に最適化されたXMLデータを格納するための標準であり、XMLスキーマにバンドルされています（データを強く型付けし、強く構造化する）。さて、主張されている利点はたくさんあります。私は、処理とメモリ効率の測定に最も感銘を受けました。

確立されたすべてのXMLAPIはどうなるのでしょうか？

私の質問に関連するこの段落があります：

4.2既存のXML処理API

EXIはXMLインフォセットのエンコーディングであるため、EXI実装はXML処理に一般的に使用されるXML APIのいずれかをサポートできます。したがって、EXIは既存のXMLAPIにすぐには影響しません。ただし、既存のXML APIを使用するには、EXIドキュメントに表示されるすべての名前とテキストを文字列に変換する必要もあります。将来的には、上位層がこれらのデータをEXIドキュメントに表示される型付きの値として直接使用できるようになれば、より効率的になる可能性があります。たとえば、上位層で型付きデータが必要な場合、文字列形式を使用するとパフォーマンスが低下する可能性があるため、型付きデータを直接サポートする拡張APIを使用すると、EXIで使用した場合のパフォーマンスが向上する可能性があります。

差出人：http ：//www.w3.org/TR/exi-impacts/

「既存のAPIでEXIを使用しますか？パフォーマンスは向上しません！（すべてを書き直さない限り）」と理解しています。

例としてJavaエコシステムを取り上げましょう。

最新のJDK6にはたくさんのXMLAPIがあります（主要なJDKリリースごとに、ますます多くのXML APIが追加されています）。私が判断できる限り、それらのほとんど（すべてではないにしても）はメモリ内のDOMツリーを使用しています。または、XMLデータを変換/処理/検証/ ...するためのシリアル化された（「テキスト」）表現。

EXIの導入により、これらのAPIはどうなると思いますか？

ご意見ありがとうございました。

EXIを知らない人のために：http ：//www.w3.org/XML/EXI/

私は自動的にhtmlメールを作成しようとしており、標準があるかどうか、メールにどの属性が機能し、どれが存在しなければならないかを理解しようとしています。必要ですか？そして、もしなければ、体がなければなりませんか？使用しているDoctypeを指定する必要がありますか？

私は彼らの例でZendFrameworkを使用していますが、「スタイリング」コードhttp://framework.zend.com/manual/de/zend.mail.html-mails.htmlのコンテンツ以外は何も設定していません。

なぜ私がHTMLを必要とするのかご存知でしょう。これはばかげているように見えますが、当社はサポートソフトウェアを作成しており、ベータテスターの重要な「バグ」または機能要求の1つは基本的なHTMLでした。そのため、重要な単語を太く、斜体にしたり、下線を引いたりして強調表示できます。

すべてのURLがURIであると何度も説明されてきましたが、すべてのURIがURLであるとは限りません。誰かがURIであるがURLではない何かの例をあげることができますか？

さまざまなブラウザーが独自の好みの方法で CSS をレンダリングすることを選択しているため、標準を持つ意味は何ですか?

すべてのブラウザーで機能する流動的な 3 列のレイアウトを作成するなどの単純なことは、フラストレーションの経験になる可能性があります。これにどのように対処しますか、またはクロスブラウザー互換性のある開発をそれほど苦痛にならないようにしますか?