痔になりやすい生活習慣とは?

HTML5のDOCTYPE宣言が各ブラウザを標準モードにするということは分かりました。

では、なぜW3CはHTML5を標準モードだけで使って欲しかったのですか?

歴史や経緯を併せて説明していただけると分かりやすいかもしれません。

参考
http://stackoverflow.com/questions/5629/any-reas …
http://annevankesteren.nl/2005/07/html5-doctype
http://dev.classmethod.jp/client-side/ie-matome/

このQ&Aに関連する最新のQ&A

A 回答 (4件)

W3Cは「HTML5を標準モードだけで使って欲しい」とはいっていません。


紹介された3つのサイトは全て個人サイトであり、情報の正確性は高くないと思われます。
参考にするなら仕様書もしくは仕様書を策定している団体サイトにしてください。

DOCTYPE宣言とはHTMLのバージョン情報を表すものとして定義されていました。(HTML4.01)
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401 …
HTML Standard(通称HTML5)になってバージョンをなくそうという動きがあり、<!DOCTYPE html> に変化したのです。
(ちなみにHTML5からバージョンが廃止されているのでHTML6になってもHTML7になってもHTML Standardのままです。)
HTML Standard ではDOCTYPE宣言を廃止したかったそうですが、後述のDOCTYPEスイッチを実装したブラウザが普及した影響で見送ったようです。
ただし、HTML(5)+XML(通称XHTML5)ではDOCTYPE宣言が必須ではありません。
http://www.whatwg.org/specs/web-apps/current-wor …
http://www.html5.jp/trans/whatwg_html5faq.html#W …
http://oshiete.goo.ne.jp/qa/7390539.html
http://oshiete.goo.ne.jp/qa/6874033.html

DOCTYPEスイッチは実装(ブラウザ)側の仕様であってHTMLで規定されている仕様にはありません。
当然、実装ごとに仕様が異なります。
http://msdn.microsoft.com/ja-jp/library/cc288325 …
https://developer.mozilla.org/ja/docs/Mozilla's_ …

HTMLでは元々、バージョン情報を明示するためにDOCTYPE宣言が必須でした。
ブラウザはDOCTYPE宣言を正しく入れることで標準準拠モードとして動作し、HTMLの仕様通りに動作することを期待できます。
Web製作者はクロスブラウザを楽にするために、HTML仕様通りの動作を期待するために、標準準拠モードを好んで使いました。
後方互換モードは特定の古いブラウザ向けに作成したサイトを対象ブラウザの新バージョンでも正常に描画できる為の機能でしかありません。
他のブラウザでの正常動作は期待できないのですから敬遠されて当然だと思います。
    • good
    • 0

No1, 2 さん、どちらも歴史の経緯や、元の趣旨からとなっています。



そう、元と言えば、SGMLです。これが基本です。

http://www.ne.jp/asahi/minazuki/bakera/html/sgml …

なんて見ると、個人のご意見ですが、まあ、確かにマニアックかもしれない。

SGMLを勉強してから、このサイトを見ると、著作者の意図がよくわかるかと思います。DOCTPEとはなにに使われているのか、何の意味を持つのか、どんな場面で使うのか?

それらを理解すれば、

>各ブラウザを標準モードにするということは

の質問は本筋ではありません。結果論にすぎません。

http://www.utj.co.jp/xml/beg/sgml/sgml3_3.html

は、無料だが、割りとしっかりしたテキストになっている。このページから見ると、上記の意味がわかるかと。最初から見れば、その歴史がわかるはず。SGMLができたころにマークアップランゲージの基本的な考え方や、構造ができたわけです。

それらをHTMLも書式の上では踏襲しています。

http://ja.wikipedia.org/wiki/Standard_Generalize …

は略歴かもしれませんね。

マークアップランゲージは、このSGMLが生まれた背景が全てです。抜粋:

「電子文書は特定の企業のワープロソフトを用いるとそのソフトのバージョンが上がったり、最悪の場合そのソフトを開発している会社が開発を中止したり、倒産したりしてソフトウェアが無くなった場合は、今まで作成したデータが読」

これらが根底に開発されたのが、マークアップランゲージです。なので、ブラウザの種類、バージョンの違いで見えなくなったり、見え方が変わるのは、本来の目的から、大きくはずれているわけです。

ブラウザの種類、バージョンによって変わるなら、マイクロソフトのWord でもいいし、 一太郎でもいいわけです。

いろんなプラットホーム(マシンの種類=>スパコン、ワークステーション、銀行などで使う汎用大型)や、OSでも、同じように読めるようにすることが、もっとも大事で、使命なんですよね。


その裏で、各メーカーの覇権争いが激化し、特にマイクロソフト vs Netscape社 では社内でも二分(派閥)するくらいのものです。それが今ではアップル、Google など多種多様なメーカーが出てきたので、さらに消費者には意味不明なものになっただけです。

その争いの中で、いいものも確かにでてきました。それがクライアントサイドでアクティブに動作する方法をHTMLに取りいれることです。これにより、格段にGUIが進歩しました。

まあ、これが、iPhone、iPad などのGUIや操作性に大きく影響させたわけです。

そうなると、Webアプリと言う分野ができるわけです。

単なる文書構造だったのが、多用な操作ができるアプリケーションとしてHTML、XMLを使用して、インタラクティブで未来的な操作ができるようになった。これはSGMLを元にXMLが考えられた時に、そうなるように機能を強化して標準化したので加速したわけです。

それらを、標準化チームとしては、どのように取り込んで再フォーマットするのかは、苦労したようですが、本来の姿はうしなうことはなかったようです。
    • good
    • 0

元々、バーナーズリーがウェブを発明したときの目的の一部がこちらにあります。


 ⇒よいウェブページを書こうとする人のためのヒント ( http://www.sal.tohoku.ac.jp/~gothit/webauthoring … )
 誰かが作成したものを誰もが共有できるよう・・・これがウェブの目的でしたし、HTMLはその主役でした。
【引用】____________ここから
HTMLは、どんな環境からもWebの情報を利用できるようにすべきだという方針の下に開発されている。例えば、様々な解像度や色深度のグラフィックディスプレイを持つPCや、携帯電話、モバイル機器、音声入出力機器、帯域が広いコンピュータや狭いコンピュータ、等の環境である。
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ここまで[HTML4.01strict/2.2.1 HTMLの略歴( http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html4 … )]より

 第一次ブラウザ戦争の後、IEはその独自の仕様でユーザーの取り込みを図りました。それは、バーナーズリーが想定していた「誰でも・・」からかけ離れていきました。ページ製作者も、プレゼンテーションのために、本来の意味とは異なるマークアップに走りました。
 それに危機感を持ったリーをはじめとする人たちは、W3Cを立ち上げ、本来の姿に戻そうと・・そしてHTML4.01が勧告されました。
 しかし、ご存知のようにIEは頑なに独自仕様にこだわっていました。なぜなら、他社のブラウザを蹴落とすために、取り入れた独自仕様が足かせになり、ウェブ標準に舵を切ることができなかったのです。それは、独自仕様に基づいて作られたサイトを裏切ることになるから・・・。もちろんIEは新しいブラウザも出してきませんでした。
 その間に、HTML4.01strictなどウエブ標準に基づいたブラウザが次々と登場し、ついにIEもウェブ標準を標準にすることを決断しました。
 それが意味するのは、
【引用】____________ここから
私はWebを技術的な おもちゃではなく、人々の共同作業の手助けとなるような社会的効果を生むものとして 設計した。Webの最終目標は、世界中に散らばっている私たちが織りなしている 網の目のような存在を支援し、改善することである。
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ここまで[よいウェブページを書こうとする人のためのヒント( http://www.sal.tohoku.ac.jp/~gothit/webauthoring … )]より
の再来なのです。

 これは、HTML4.01が策定されたときからの規定路線でもあるのです。
「HTML文書を作る場合には、この仕様における、他のDTDセットではなく strict DTD に適合する文書を作るよう推奨する。 ( http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html4 … )」
「推奨しない要素は、HTMLの将来のバージョンでは廃止になる可能性がある。 ( http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html4 … )」

 HTML4.01が勧告されて以来12年経ちますが、HTML5になって、初めてすべてがウェブ標準となり、ブラウザの制約がなくなるのです。

 HTML5では、canvasやvideoなど新しい要素が加わりますが、それ以上にセマンティックウェブが重視されます。

「では、なぜW3CはHTML5を標準モードだけで使って欲しかったのですか?」
それは違います。
 HTML4.01も標準モードだけで使って欲しかったのですよ。

 使わなかったのは製作者です。

この回答への補足

いろいろと参考になる経緯や引用ありがとうございます。

>HTML4.01も標準モードだけで使って欲しかった
では、なぜHTML4には標準モードと互換モードがあって
HTML5には標準モードしかないのでしょうか?

補足日時:2013/02/19 00:19
    • good
    • 0

質問の意図がわからないのですが、



ブラウザは、DOCTYPE宣言が無いか、自分の解釈できないDOCTYPE宣言であったときに、Quirksモードになり、そうでないとき(ブラウザがDOCTYPEからHTMLの規格の種類が判断できるとき)に、標準モードになります。したがって、HTML5という時点で標準モードしかあり得ない。

どのブラウザがどんなDOCTYPE宣言を解釈できるかは、歴史的経緯でしょうが、詳細はわかりません。一部のIEがXML宣言を理解できないのもそうですね。
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QdoGetとdoPostの違い

それぞれブラウザからのリクエストの種類に対応する
メソッドがdoGet,doPost。
doGetはブラウザからGETでそのサーブレットに
リクエストがあった時に、処理が始まるメソッド、
doPostは同じようにPOSTを受け取った時に動き出す

・・・・・ということなのですが、
doGetもdoPostも、中身のコーディングの仕方としては
同様でいいのでしょうか?
いま、doGetでリクエストに対応する処理をうけつけて
いるのですが、255バイトまでなのでdoPostのほうが
いいということがかかれていました。

これは、ブラウザ:Servletのメソッドで対応してれば
いいだけで、結局は送信量の違いだけですか?
そのへんがよくわかってないので教えてください。

ちなみに、doGetでやってる処理は、

public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {

//Bean(workBean)のインスタンス作成
wk = new work_Bean();
//Bean処理実行
wk.Work();





//BeanをJSPに渡すためにHttpServletRequestオブジェクトにセット
request.setAttribute("wk",wk) ;

//ViewであるJSPを呼び出す
RequestDispatcher rDispatcher =
request.getRequestDispatcher("/kanri_JSP.jsp");
rDispatcher.forward(request,response);

こんなかんじでしてます。
あとは、ネットで、人のサンプルとかみると
doGetメソッドに処理をかいており、doPostでは
doGet(request,response);として
doGetをよんでたりするんですが、
これは、PostでもGetと同様の処理ができると
いうことですか?
基本的な質問過ぎるかとおもいますがおしえてください。

それぞれブラウザからのリクエストの種類に対応する
メソッドがdoGet,doPost。
doGetはブラウザからGETでそのサーブレットに
リクエストがあった時に、処理が始まるメソッド、
doPostは同じようにPOSTを受け取った時に動き出す

・・・・・ということなのですが、
doGetもdoPostも、中身のコーディングの仕方としては
同様でいいのでしょうか?
いま、doGetでリクエストに対応する処理をうけつけて
いるのですが、255バイトまでなのでdoPostのほうが
いいということがかかれていました。

これは、ブ...続きを読む

Aベストアンサー

GET と POST では、パラメータをプログラムに渡す仕組みが全く違います。
仕組みが違うので渡せるパラメータの大きさが違う、等の違いが出てきます。

ですが、Servlet では、その違いを request オブジェクトが全部隠してくれて
いるので、気にしなくて良いです。つまり、同じことができて、呼出され方が
違う、と。

普通は、html や JSP の方も、Servlet を意識して書くでしょうから、
どちらかだけの実装で良いのですが、汎用的(呼ぶ人を特定しない)な Servlet
を書こうと思ったら、両方を実装しておく、と理解しておけば良いです。


ちなみに、GET で渡せるパラメータの大きさは 255 バイトと決っているわけでは
ないし、POST で渡せるパラメータの大きさに制限が無い、というわけでもあり
ません。

GET の制限は、どちらかというとブラウザ側の実装によって決ってくることで、
POST に制限があるとしたらサーバ側(例えば、Servlet コンテナ)の実装に
よってきます。

Q文字列から数字を取り出す方法

質問があります。
例えば、テキストファイルから文章を一行ずつ読み込み、それをString型の変数に格納していきます。
その文から数字(整数で、何桁かはわからない。)を取り出し(ちなみにその数字の前後には特定の文字がついています)、変数に格納するというプログラムを作りたいのですが、具体的な方法がわかりません。
よろしければ是非教えてください!

Aベストアンサー

こんな感じですか?
数値以外を除きそのまま代入させます

String str = "ABCDABCD1234512345abcd";
int ret = Integer.parseInt(str.replaceAll("[^0-9]",""));
System.out.println(ret); //結果表示


人気Q&Aランキング