DOCTYPE and Comment (Re: HTML Editer)
Masayasu Ishikawa
石川＠weblint-victimsです。
Subjectを変えて、fj.net.infosystems.www.authoringの方にフります。
私の記憶が確かならば、JST時間1996年11月11日(月) 20時28分03秒頃、
fj.net.infosystems.wwwの<5672k3$c...@newsgate.so-net.or.jp>の記事において
kn...@da2.so-net.or.jp (Takatsugu Nokubi)さんは書きました。
>>> DOCTYPE宣言は、HTMLエディタこそ付けてもらいたいと思いますが…。
>
> そうですね。あと、どのような PUBLIC ID を選択できるようにするべきか、
>という問題がありますが、特にこれらのような Windows 環境のエディタの場
>合、HTML2.0, Internet Explorer 拡張, Netscape 拡張 などを考慮にいれて
>おけば、とりあえずよさそうな気がします。
まあ、 あとはHTML 3.2(Wilbur)のdraft位ですかね。私だったらi18n拡張も入
れますけど。Cougarまでは必要ないでしょう。
>Internet Explorer 2.0
> -> "-//Microsoft//DTD Internet Explorer 2.0 HTML//EN"
>
>＃IE3.0 でもこの宣言でいいんだろうか ...
マズイでしょう(^_^;。何故いまだにIE 2.0のものかというと、Microsoftが公
式に公開しているDTDが今のところこれしかないからです。しかも"Beta
version: 0.9"のままで、 所々に"-- Not supported by IE2 --"と書かれたも
のが定義されているというアヤシイ代物ですが…。
それでも、「公式に」DTDを公開しているという点では、私はMicrosoftの姿勢
を高く評価しています。 Microsoftが本当にオープンにやる気があるかどうか
は、IE 3.0以降もきちんとDTDを公開するかにかかっていると言えるでしょう。
とりあえずIE 3.0のサポートタグ一覧は公表していますので、公開する気はあ
るのかな…という気はしていますが。
> でいいとして、Netscape 拡張を含めた HTML に対してはどのような宣言を
>するのがもっとも妥当でしょうか。
できない、というのが妥当な解ではないかと(^_^;;;。 で、宣言できないよう
な拡張は使わないのが良識ある対応というものでしょう。 これはきちんとDTD
を公開しないNetscape Communications社が悪いです。
＃最近私は、DTDに定義されていない、まともなDOCTYPEも宣言できないタグを
＃HTMLドキュメントに用いるのはあまりにもジャアクである、という、当然と
＃いえば当然な結論に達しました。
> 石川さんのページで紹介されている WebTechs の DTD に対応した DOCTYPE
>宣言をする、というのはあまり正しい気がしませんし、
まあ、あれはofficialなDTDがないので、WebTechsのHTML Validation Service
(これはSGMLパーザがベースなので、 DTDがないとチェックできません)で使え
るように、 仕方なく実装からリバースエンジニアリングしてDTDをでっち上げ
た代物ですから、一般に使うようなものではないでしょう。
もちろん、 苦労してDTDにまとめ上げた努力には敬意を表しますし、他者が文
句を付ける筋合いではないのですが、作成者自身が
>But there are some Netscape extensions which deviate from the SGML philosophy
>which I cannot specify correctly in my version of the Mozilla DTD.
と断わっていますから、もとよりNetscape拡張を網羅してはいません。まとも
にDTDに表現できないような拡張を加える方がどうかしていると思いますが…。
詳しくは、http://www.webtechs.com/html/mozilla.html でご確認ください。
Spyglass HTML 2.0 Extended DTDも、同社のSpyglass HTML Validator(これも
基本的にSGMLパーザがベースです)で使うために、 Mozilla/MSIE 2.0相当のタ
グを盛り込んでいますが、 これもFRAME関連がなかったりで、妥当とは思えま
せん。
現時点でMozilla 3.x相当の仕様まで盛り込んだDTDというと私の知る限りHTML
Pro DTD位ですが、 これは何しろ既存の仕様を全て統合してしまおうというと
んでもない代物なので、 Chimeraというか鵺というか…闇鍋状態です。この仕
様を完全にサポートするuser agentなど現時点では1つもないでしょう:-)。興
味のある方は、http://www.arbornet.org/~silmaril/dtds/html/htmlpro.html
をご覧ください。
ともあれ、混乱の元凶はNetscape Communications社がDTDを公開していないこ
とです。 Netscape拡張は使いたいが正しいHTMLを書きたい、良識あるMozilla
の正規ユーザは、Netscape Communications社にDTDを公開するよう要求すべき
でしょう。 少なくとも私はもはや、DTDもないような拡張をサポートする気は
失せています。
>あるいは、Wilburで規定されているタグだけに限定すればよいのかもしれませんが ...
まあ、 MozillaだろうがMSIEだろうがLynxだろうが、Wilburに規定されたタグ
のみを使うのであれば、DOCTYPEでそう宣言して何の問題もないでしょう。 も
ともとDOCTYPEはDTDに応じて決まるものであって、ブラウザによって決まるも
のではありませんから。
>>> ＃でも、コメントは <!-- ... --> だ、という説明は必ずしも正しくないんで
>>> ＃すよね…。weblint-victims MLでもコメントの扱いは最近議論になってまし
>>> ＃て…。もちろん <!- ... -> が間違いには違いないんですが。
>
> え、そうなんですか。それは知りませんでした。差し支えなければ、どのよ
>うな議論がなされているか教えていただけませんか?
つまり、SGML的に正しいコメントは -- と -- で囲まれたものである、という
ことです。
＃Message-ID: <E0M3q...@vega.aichi-u.ac.jp> の記事に添付したcatalog
＃のコメントの書式は、そうなってましたよね?
ですから <!-- ... --> も -- と -- で囲まれていることに違いはないので間
違いではないのですが、この中に何を書いても無視される、というわけではあ
りません。例えば、
<!-- part 1 -- part 2 -- part 3 -->
のように書いてあったとすると、"part 1"と"part 3"は -- と -- で囲まれて
いるのでコメントですが、"part 2"はコメントではない、ということになるの
です。ですからSGML的に正しい解釈をするuser agentでは、"part 2"に書いた
部分が表示されてしまうかもしれません。ほとんどのuser agentはこの様な厳
密な解釈をしないので、途中の -- の有無に関係なく"part 2"を表示しません
が、 Lynx 2.5FMは"part 2"を表示することがweblint-victimsで報告されてい
ます。
より厄介な問題が、 -- の対応がアンバランスな場合です。例えば
<!-- This comment is unterminated. -- -->
の様に書かれていたとすると、2つめのコメントの終了を表す -- がないので、
正しく解釈すると、これ以降の記述は全てコメントとして扱われて表示されな
いことになってしまいます。このようなunterminatedなコメントを警告すべき
ではないか、というのがweblint-victimsで議論になっているわけです。
まあ、チェックできるに越した事はないのでしょうが、ここまでくるとSGMLパ
ーザの仕事かなぁ…という気もします。どうしたものでしょうか…。
--
``If I like a program I must share it with other people who like it.''
-- Richard Stallman
愛知大学大学院法学研究科 石川 雅康 / E-mail: mim...@aichi-u.ac.jp
jweblint Home Page: http://www.aichi-u.ac.jp/~mimasa/jweblint/
Takatsugu Nokubi
野首です。
<E0rn3...@vega.aichi-u.ac.jp>の記事において
mim...@vega.aichi-u.ac.jpさんは書きました。
>> Subjectを変えて、fj.net.infosystems.www.authoringの方にフります。
了解です。
>> >Internet Explorer 2.0
>> > -> "-//Microsoft//DTD Internet Explorer 2.0 HTML//EN"
>> >
>> >＃IE3.0 でもこの宣言でいいんだろうか ...
>>
>> マズイでしょう(^_^;。
やっぱりそうですか。ひょっとしたら、IE 2.0 も 3.0 もサポートするタグ
はいっしょなのかなあ、と思ってしまったので。
＃IE はあんまり触っていないんです ^^;
>> それでも、「公式に」DTDを公開しているという点では、私はMicrosoftの姿勢
>> を高く評価しています。 Microsoftが本当にオープンにやる気があるかどうか
>> は、IE 3.0以降もきちんとDTDを公開するかにかかっていると言えるでしょう。
>> とりあえずIE 3.0のサポートタグ一覧は公表していますので、公開する気はあ
>> るのかな…という気はしていますが。
これは、MSKK に要望を出すのがよさそうですね。
>> > でいいとして、Netscape 拡張を含めた HTML に対してはどのような宣言を
>> >するのがもっとも妥当でしょうか。
>>
>> できない、というのが妥当な解ではないかと(^_^;;;。
うう、やっぱり --;
>> で、宣言できないよう
>> な拡張は使わないのが良識ある対応というものでしょう。 これはきちんとDTD
>> を公開しないNetscape Communications社が悪いです。
確かにそうですね。きっとたくさんの DTD 公開の要望があるのではないか
と思うのですが、Netscape Communications はそれに答えないのでしょうか。
>> ＃最近私は、DTDに定義されていない、まともなDOCTYPEも宣言できないタグを
>> ＃HTMLドキュメントに用いるのはあまりにもジャアクである、という、当然と
>> ＃いえば当然な結論に達しました。
御意。でも、仕事で要求されることがあって、なかなか思うようには ... ;_;
>> まとも
>> にDTDに表現できないような拡張を加える方がどうかしていると思いますが…。
そうですよね。その線で説得するしかないかな。
>> まあ、 MozillaだろうがMSIEだろうがLynxだろうが、Wilburに規定されたタグ
>> のみを使うのであれば、DOCTYPEでそう宣言して何の問題もないでしょう。 も
>> ともとDOCTYPEはDTDに応じて決まるものであって、ブラウザによって決まるも
>> のではありませんから。
御意。
＃それにしても、HTML エディタの作者たちにはずいぶん厳しい注文をするこ
＃とになりそう ...
>> つまり、SGML的に正しいコメントは -- と -- で囲まれたものである、という
>> ことです。
うーん、「はじめての SGML」を一通り読んだのに記憶にないなあ。改めて
コメントに関する説明を読んでみると、
(p.53)
: DTD の各宣言は "<!" で始まり、(中略) ">" で終わります。また "<!--"
: と "-->" でテキストを挟むことによりコメント文も書くことができます。
とあり、とてもそのようには読めません。しかしさらに調べると、
(p.262)
: コメント
: DTD の宣言や文書内で、"--" と "--" にはさんで書く部分。この部分はパー
: サに無視される。このようにして、どんな場所にも注釈をいれることがで
: きる。
という説明が付録の用語集に書いてありました。私の読み方が悪かったよう
です (_o_)
＃用語集はよんでなかったなあ ...
つまり、一般的に言われているコメントというのは、「DTD 宣言内にかかれ
たコメント」というわけですね。
＃p.262 の説明だと、通常の文章中の -- -- もコメントであるように読める
＃けど、そういう解釈でいいのかなあ ...
>> <!-- This comment is unterminated. -- -->
＜略＞
>> いことになってしまいます。このようなunterminatedなコメントを警告すべき
>> ではないか、というのがweblint-victimsで議論になっているわけです。
>>
>> まあ、チェックできるに越した事はないのでしょうが、ここまでくるとSGMLパ
>> ーザの仕事かなぁ…という気もします。どうしたものでしょうか…。
チェックしてしまって構わないのではないでしょうか。j?weblint の良いと
ころは、バージョンがあがるごとに新しいチェック機能が追加されて、そのた
びに「ああ、こういう問題があるのか」ということを認識出来るところにある
のでは、と個人的に思っています。
こうやって News などで議論してゆくことで広く知らしめるのも良いのです
が、そういった問題を具体的に警告してくれるツールが実在する、ということ
はとても重要なことではないかと思います。SGML パーサよりずっとお手軽で
あることも見逃せません。
そういうわけで、kitchen sink と言われようとも ^^; 新たなチェック機能
をどんどん追加してゆき、世に問い掛けて行って欲しいと思います。あんまり
特殊なチェックはデフォルトにしなければいいんだし。
まあ、これはあくまで個人的な意見ですけどね。納得出来る反論があればい
つでも取り下げます ^^;;;
---
野首 貴嗣
E-mail:kn...@da2.so-net.or.jp
URL:http://ux01.so-net.or.jp/~knok/
Takuya ASADA
石川さん>
なのですが…
> Lynx 2.5FMは"part 2"を表示することがweblint-victimsで報告されています。
この場合 "<!part2>" のように書かれているのと、基本的には同じコトに
なると思いますので、Lynx も『表示』はしないんじゃないかと思うです。
そう認識するのは確かなのですが…。
> より厄介な問題が、 -- の対応がアンバランスな場合です。
そうですねぇ…アリガチなのが、
<!------------------------------------------>
みたいに書いた場合ですね。実際コレのために『全然表示されない』と
アワテた報告が、私の入っている ML でありましたです。
先の記事にも書きましたですが、サスガにこの仕様はキビシすぎるためか、
通常デフォルトでは OFF になっていて、-minimal オプションを付けるか、
『`』キーによって切り替わるようになっています。
あさだ たくや
Tetsuji Isoo / 磯尾 哲司
磯尾と申します。
# 素人ですので勘違いしてるかも知れません。
# その際にはご指摘下さい。
> 石川＠weblint-victimsです。
> >>> DOCTYPE宣言は、HTMLエディタこそ付けてもらいたいと思いますが…。
> > そうですね。あと、どのような PUBLIC ID を選択できるようにするべきか、
> >という問題がありますが、特にこれらのような Windows 環境のエディタの場
> >合、HTML2.0, Internet Explorer 拡張, Netscape 拡張 などを考慮にいれて
> >おけば、とりあえずよさそうな気がします。
マック環境ならCyberDogも、ですね。
# DTDあるのかな？
でも結局、どのメジャーブラウザも正確なDTDを出していなくて、メーカー非依存の
公開DTDが英語DTDしか無いんであれば「日本語ページではどんなDOCTYPE付けても結
局間違い」なような気がしてきました。
<蛇足>
ファイルメーカーProのおまけに、「ホームページ作成テンプレート」というHTMLエ
ディタ＆ファイル構成管理データベースがありました。
DOCTYPEなし、IMGにALTなし、属性値は""で囲まない、でした。
まぁ、すべてカスタマイズ可能ではありますが…。
</蛇足>
> >>> ＃でも、コメントは <!-- ... --> だ、という説明は必ずしも正しくないんで
> >>> ＃すよね…。weblint-victims MLでもコメントの扱いは最近議論になってまし
> >>> ＃て…。もちろん <!- ... -> が間違いには違いないんですが。
> つまり、SGML的に正しいコメントは -- と -- で囲まれたものである、という
> ことです。
本文(?)中に--が現れるのもSGML的にはまずいわけですね。
> ですから <!-- ... --> も -- と -- で囲まれていることに違いはないので間
> 違いではないのですが、この中に何を書いても無視される、というわけではあ
> りません。例えば、
> <!-- part 1 -- part 2 -- part 3 -->
え゛っ。私はよく、
<HR><!-- -- -- -- -- -- -- -- -- -->
って感じのモノを使ってますけど、モロまずいですね。--の数はその日の気分次第だし。
<HR><!----------------------------->
のような場合はどうなんでしょう。やっぱり、--の数が正しくないとおかしな事に
なるんでしょうか？
人に聞かれたら「HTMLとSGMLはもう別物です」と答えようかナ。
インスタンスがゴリラとチンパンジーぐらい違う気がする。
--
Tetsuji Isoo / 磯尾 哲司
CAE Group, MMC Computer Research Ltd.
E-Mail: is...@mcor.co.jp http://www.mcor.co.jp/
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月13日(水) 22時01分27秒頃、
fj.net.infosystems.www.authoringの<56cgr7$h...@newsgate.so-net.or.jp>の
記事においてkn...@da2.so-net.or.jp (Takatsugu Nokubi)さんは書きました。
> やっぱりそうですか。ひょっとしたら、IE 2.0 も 3.0 もサポートするタグ
>はいっしょなのかなあ、と思ってしまったので。
まあ、率直に言って*全然*違いますね。 どの位違うかは…jweblint v0.142と
v0.142cとで、 $msElementsや%msAttributesがどの位変わっているかを比べて
いただければおわかりいただけるかと(^_^;。
>＃IE はあんまり触っていないんです ^^;
まあ、私も評価用に一匹飼ってるだけなので、ろくに使ってませんけど:-)。
＃むしろ、共用マシンに勝手にIEがインストールされてると抹殺して回るのが
＃仕事だったりします :-p
> これは、MSKK に要望を出すのがよさそうですね。
うーん…こう言っては何ですが、M$KKには期待するだけ無駄ではないかと(^_^;;。
そもそも散々探しまわってみたものの、M$KKのWebサイトにはDTDはおろか、ま
ともなサポートタグ一覧すら見当たりませんでした。 M$ Corp.のWebサイトを
見に行けば、 http://www.microsoft.com/workshop/author/ref/ie2dtd-f.htm
からちゃんと公式にDTDが入手できるんですが。せめてM$ Corp.のWebサイトで
公開されている資料位、翻訳するなりして公開してもらいたいものです。
もっとも、その翻訳もアヤしくて、まだIE 3.0がβ版だった頃に、M$ Corp.の
http://www.microsoft.com/ie/htmlext/default.htmというWebページを翻訳し
た、http://www.microsoft.co.jp/ie/htmlext/default.htm というページがあ
ったのですが(今もあるのかな?)、 大筋はまあまともな訳だったのですが、フ
レーム機能の説明のところでとんでもないウソがあって、M$ Corp.のページで
>Enhanced Frame Support
>Supports commonly used frame extensions that enable you divide a Web page
>into several pages, or frames. ...
と書いてあるのに、何故か
>拡張フレーム機能のサポート
>Webページを複数のページに分割したり、フレームに分割できる HTML 3.2 の
>フレーム拡張機能をサポートしています。... ~~~~~~~~~~~
となっていたのです(-_-#)。 いつの間にやらHTML 3.2 (Wilbur) はW3Cの
Proposed Recommendationになってますが、 今もってフレーム機能は仕様に盛
り込まれていません。一時期雑誌等で「IE 3.0では『HTML 3.2の』フレーム機
能をサポートしている」という誤った説明がいくつも見受けられたので、一体
どこがそんな間違った情報を流しているのだろう、 と思っていたのですが、
M$KK自身が諸悪の根源だったわけです。私の知る限り、M$ Corp.の方でそのよ
うなウソの説明を見た記憶はありません。
大分話が逸れましたが、そんな訳で私はM$KKから有益な情報が得られるとは期
待していません。要望を出すならM$ Corp.の方がよろしいのではないかと。
>>> な拡張は使わないのが良識ある対応というものでしょう。 これはきちんとDTD
>>> を公開しないNetscape Communications社が悪いです。
>
> 確かにそうですね。きっとたくさんの DTD 公開の要望があるのではないか
>と思うのですが、Netscape Communications はそれに答えないのでしょうか。
私はそもそもDTDを作ってないのではないかという強い疑いを抱いています。
＃DTDを作ってるならあんな変な仕様にはならないと思う…
>＃それにしても、HTML エディタの作者たちにはずいぶん厳しい注文をするこ
>＃とになりそう ...
うーん、 特にDOCTYPEについては、難しい問題ですね。MozillaのDTDがないの
は、HTMLエディタの作者の方々に責任がある訳じゃありませんし…。
さて…
>>> <!-- This comment is unterminated. -- -->
> ＜略＞
>>> いことになってしまいます。このようなunterminatedなコメントを警告すべき
>>> ではないか、というのがweblint-victimsで議論になっているわけです。
>>>
>>> まあ、チェックできるに越した事はないのでしょうが、ここまでくるとSGMLパ
>>> ーザの仕事かなぁ…という気もします。どうしたものでしょうか…。
>
> チェックしてしまって構わないのではないでしょうか。
うーむ、そうですか。
> こうやって News などで議論してゆくことで広く知らしめるのも良いのです
>が、そういった問題を具体的に警告してくれるツールが実在する、ということ
>はとても重要なことではないかと思います。SGML パーサよりずっとお手軽で
>あることも見逃せません。
SGMLパーザよりずっといい加減、という話もありますが(^_^;。 まあ守備範囲
が違うので、可能ならば併用するのが吉ですね。
> まあ、これはあくまで個人的な意見ですけどね。納得出来る反論があればい
>つでも取り下げます ^^;;;
私の作業が大変だ、というのでは納得してはいただけないでしょうか(^^;)。
…というジョーダンはさておき、本気で「正しい」コメントの解釈を実装しよ
うとすると`unclosed-comment'とか`markup-in-comment'とかも再検討しない
といけないのですが、とりあえず`--'の対応がおかしかったら警告する機能を
追加するパッチを作ってみました。ホントに間に合わせで作ったので、かなり
いい加減ですけど…。 jweblint v0.142c [05-Nov-96] 用です。漢字コードを
ちゃんと変換してやれば、EUC版でもSJIS版でもイケるはずです。
一応チェックはうまく行ってると思うんですが、例を挙げると…
・正しいコメントの例(これらは警告されない)
<!-- this is a comment -->
<!-- this is a comment -- -- this is also a comment -->
<!-- comment 1 --
-- comment 2 --
-- comment 3 -->
<!---->
<!------------>
<!-- -- -- -- -- -- -- -- -- -- -- -->
・正しくないコメントの例(これらは警告される)
<!-- this comment is unterminated. -- -->
<!-- this is a comment ---- this is also a comment ---->
<!-- comment 1 --
-- comment 2 --
-- comment 3 --
-->
<!-- -- -->
<!-------------->
<!-- -- -- -- -- -- -- -- -- -- -- -- -- -- -->
まあ興味のある方はお試しください。この程度でお役に立つでしょうか?
--
``If I like a program I must share it with other people who like it.''
-- Richard Stallman
愛知大学大学院法学研究科 石川 雅康 / E-mail: mim...@aichi-u.ac.jp
jweblint Home Page: http://www.aichi-u.ac.jp/~mimasa/jweblint/
--- jweblint.orig Tue Nov 05 00:14:02 1996
+++ jweblint Fri Nov 15 00:14:02 1996
@@ -502,6 +502,10 @@
# markup embedded in comment can confuse some (most? :-) browsers
&whine($., 'markup-in-comment') if $comment =~ /<\s*[^>]+>/o;
+
+ $comments = ($comment =~ s/--//go);
+ &whine($., 'unterminated-comment') if $comments % 2 == 1;
+
next;
}
undef $commentline;
@@ -1574,3 +1578,6 @@
bad-entity
ENABLE
"$argv[0]" は不明な実体参照です.
+unterminated-comment
+ DISABLE
+ コメント宣言中の `--' の対応が不正です.
Hiroshi KISE
>>>>> In article <E0vFu...@vega.aichi-u.ac.jp>,
> mim...@vega.aichi-u.ac.jp (Masayasu Ishikawa) writes:
mimasa> いつの間にやらHTML 3.2 (Wilbur) は
mimasa> W3CのProposed Recommendationになってますが、
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
すみません、これって、どういう位置付けになるのでしょうか？
はよ3.2が固まってくれないと、HTML3.2ローラ本の日本語版が
出ないじゃない、と嘘を並べてみる。
--
喜瀬“冬猫”浩＠南国沖縄
Takatsugu Nokubi
野首です。
<E0vFu...@vega.aichi-u.ac.jp>の記事において
mim...@vega.aichi-u.ac.jpさんは書きました。
>> > やっぱりそうですか。ひょっとしたら、IE 2.0 も 3.0 もサポートするタグ
>> >はいっしょなのかなあ、と思ってしまったので。
>>
>> まあ、率直に言って*全然*違いますね。 どの位違うかは…jweblint v0.142と
>> v0.142cとで、 $msElementsや%msAttributesがどの位変わっているかを比べて
>> いただければおわかりいただけるかと(^_^;。
なるほど、それなら DTD がなくても把握できますね ^^
＜略＞
>> 大分話が逸れましたが、そんな訳で私はM$KKから有益な情報が得られるとは期
>> 待していません。要望を出すならM$ Corp.の方がよろしいのではないかと。
ずいぶんひどい話ですね。確かに、MS Corp. の方がよさそう ... とはいえ、
まったく問題を知らせないのもまずいですし、一応両方に要望を出してみます。
>> > 確かにそうですね。きっとたくさんの DTD 公開の要望があるのではないか
>> >と思うのですが、Netscape Communications はそれに答えないのでしょうか。
>>
>> 私はそもそもDTDを作ってないのではないかという強い疑いを抱いています。
>>
>> ＃DTDを作ってるならあんな変な仕様にはならないと思う…
そうですね。http://www.webtechs.com/html/mozilla.html を見て、私もそ
う思うようになりました。
>> >＃それにしても、HTML エディタの作者たちにはずいぶん厳しい注文をするこ
>> >＃とになりそう ...
>>
>> うーん、 特にDOCTYPEについては、難しい問題ですね。MozillaのDTDがないの
>> は、HTMLエディタの作者の方々に責任がある訳じゃありませんし…。
そうですよね。それに、大半のエディタは FRAME をサポートしているんで
すよね ... 彼らに FRAME のサポートをやめてまで DOCTYPE を必ず付けるよ
うになんていえないし、要望したとしても受け入れられないでしょう。
とりあえず、
・できるだけ SGML 的に正しいタグを生成する。
・DOCTYPE はできるなら付けてもらう。さらに、DOCTYPE に適合したタグのみ
が入力出来るとなお良い。対応してもらいたいのは HTML2.0, Wilbur,
IE2.0。できれば、Cougar, i18n も。
・FRAME を使うなら DOCTYPE はつけない。
ぐらいで受け入れてもらえれば御の字でしょうかね。
>> > こうやって News などで議論してゆくことで広く知らしめるのも良いのです
>> >が、そういった問題を具体的に警告してくれるツールが実在する、ということ
>> >はとても重要なことではないかと思います。SGML パーサよりずっとお手軽で
>> >あることも見逃せません。
>>
>> SGMLパーザよりずっといい加減、という話もありますが(^_^;。 まあ守備範囲
>> が違うので、可能ならば併用するのが吉ですね。
j?weblint と同じくらいお手軽な SGML パーサがあるといいんですけどね。
とりあえず、時間ができたら SP を試してみたいとは思っています。
>> > まあ、これはあくまで個人的な意見ですけどね。納得出来る反論があればい
>> >つでも取り下げます ^^;;;
>>
>> 私の作業が大変だ、というのでは納得してはいただけないでしょうか(^^;)。
もちろん、それは理解してます (_o_) 私は実際に作業をしていないので、
実装にかかる労力に見合った仕様であるのかどうかはわかりませんから、その
辺りの判断はお任せしますし、決定には従うつもりです。
＃話を聞いていただけるだけでも光栄ですから ... ^^
>> …というジョーダンはさておき、本気で「正しい」コメントの解釈を実装しよ
>> うとすると`unclosed-comment'とか`markup-in-comment'とかも再検討しない
>> といけないのですが、とりあえず`--'の対応がおかしかったら警告する機能を
>> 追加するパッチを作ってみました。ホントに間に合わせで作ったので、かなり
<略>
>> まあ興味のある方はお試しください。この程度でお役に立つでしょうか?
どうもありがとうございます (_o_) 他の記事で書いた Java Script の例で
試してみましたが、ちゃんと動作しています。
Takatsugu Nokubi
野首です。
<56do67$6...@sunsp.sunsp.mcor.co.jp>の記事において
is...@mcor.co.jpさんは書きました。
>> でも結局、どのメジャーブラウザも正確なDTDを出していなくて、メーカー非依存の
>> 公開DTDが英語DTDしか無いんであれば「日本語ページではどんなDOCTYPE付けても結
>> 局間違い」なような気がしてきました。
「どんな DOCTYPE 付けても」はさすがに言い過ぎのような ... ^^; それは
ともかく、DTD の無い Netscape 拡張などを使う場合には「つけない」ほうが
マシな気がします。
＃本当は「そんなものは絶対に使わない」という態度で臨みたいところですが、
＃なかなかそうも言っていられない ... ;_;
>> > >>> ＃でも、コメントは <!-- ... --> だ、という説明は必ずしも正しくないんで
>> > >>> ＃すよね…。weblint-victims MLでもコメントの扱いは最近議論になってまし
>> > >>> ＃て…。もちろん <!- ... -> が間違いには違いないんですが。
>> > つまり、SGML的に正しいコメントは -- と -- で囲まれたものである、という
>> > ことです。
>>
>> 本文(?)中に--が現れるのもSGML的にはまずいわけですね。
最初、石川さんの文章を「(宣言内の) -- と -- で囲まれたものである」と
読んだのですが、それは私の読み間違いでしょうか?
＃「はじめての SGML」の解説もそんな感じになってるし ... 例が載っていな
＃いのでいまいち不安。
ところで最近 Java Script を使うはめになったのですが、これも場合によっ
てはかなりまずいことになりそうですね。SCRIPT タグを認識しない古いブラ
ウザで SCRIPT が文章として表示されるのを防ぐためにコメントで囲むように
することが推奨されているのですが、たとえば
<script language="JavaScript">
<!--
function hoge(a, b) {
x = -- a + b;
return x;
}
-->
</script>
のような '--' 演算子があるとコメントが閉じていないことになったり、コ
メントに含まれない部分が出たりすることになってしまいます。
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月15日(金) 16時07分48秒頃、
fj.net.infosystems.www.authoringの<KISE.96No...@ns.imicom.or.jp>の
記事においてki...@imicom.or.jp (Hiroshi KISE)さんは書きました。
>mimasa> いつの間にやらHTML 3.2 (Wilbur) は
>mimasa> W3CのProposed Recommendationになってますが、
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>すみません、これって、どういう位置付けになるのでしょうか？
http://www.w3.org/pub/WWW/Consortium/Process/Recommendation によると、
W3CのRecommendation Processは概略以下のようになっているようです。
＃私はW3Cとは縁もゆかりもないので、 勘違いしているかもしれません。正確
＃なところは上記Webページでご確認ください。
"W3C Recommendation"とは、その規格が使用に適している、という一般的な合
意がW3Cのメンバー間で得られた状態を指します。いわば、これが「W3C標準」
です(Internet標準、というわけではありません)。
ある規格が"W3C Recommendation"となるには、以下のようなプロセスをたどり
ます。
第一段階: W3C Working Draft (WD)
この段階では、まだ仕様は策定段階で、随時変更されます。WDとして提案
されたものが後にRecommendationになる保証は全くありません。あくまで
draftです。
第二段階: Proposed Recommendation (PR)
WDがW3Cのdirectorによって次の段階に進められると、Proposed
Recommendation(PR)になります。現在HTML 3.2の規格はこの段階です。PR
になると、 一定の期限を定めてPRに対するコメントをW3Cのメンバー及び
一般から求めます。HTML 3.2は11月5日にPRになり、review periodは12月
15日に終了することになっています。
第三段階: Disposition
PRのreview periodが終了すると、directorの裁量によって、その規格は
1. Recommendationとして発行される
2. 若干の修正の後発行される
3. Working Draftの段階に差し戻される
4. 破棄されてW3Cの議題からは取り除かれる(要するにボツ)
のいずれかの処分がなされます。
最終段階: W3C Recommendation
Dispositionの結果Recommendationとなった場合、W3Cから他の標準化団体
に対して承認のため提出されたりすることになります(例えばRFCとして承
認するよう求める、など)。
…ということらしいです。HTML 3.2の場合、 12月15日のreview period終了後
14日以内にDispositionの結果がアナウンスされることになっているようです。
その結果W3C Recommendationになるかもしれませんし、 Working Draftに逆戻
りするかもしれませんし、標準化なんて諦めて放棄されてしまうかもしれませ
ん。 つまり、draftよりは一歩前進しましたが、まだ現段階では標準規格とな
るかどうかは断言できないのです。
＃詳しくは、http://www.w3.org/pub/WWW/MarkUp/Wilbur/#pr-review あたり
＃を参照してください。
まあ、上記の通りなら、年内には何らかの結論が出そうです。どこかで賭けの
対象になってるかもしれませんね:-)
＃私の予想ですか? とりあえず「ノーコメント」ということにしておいてくだ
＃さい(^_^;。
>はよ3.2が固まってくれないと、HTML3.2ローラ本の日本語版が
>出ないじゃない、と嘘を並べてみる。
万一ボツなんてことになると、永遠にオクラ入りかもしれません…。
ところで、仮にHTML 3.2がW3C Recommendationになったとして、すでにIETFで
proposed standardとして承認されたdraft-ieft-html-i18nがもし"Category:
Standards Track"なRFCになったとしたら、 一体どっちがHTMLの標準なんでし
ょうね。方向性が全然違うんですけど…。
Hiroshi KISE
>>>>> In article <E0x2x...@vega.aichi-u.ac.jp>,
> mim...@vega.aichi-u.ac.jp (Masayasu Ishikawa) writes:
mimasa> いつの間にやらHTML 3.2 (Wilbur) は
mimasa> W3CのProposed Recommendationになってますが、
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> すみません、これって、どういう位置付けになるのでしょうか？
mimasa> 第一段階: W3C Working Draft (WD)
3.0はこの段階でお亡くなりになったのですよね？
mimasa> 第二段階: Proposed Recommendation (PR)
3.2はいまここで、
mimasa> 第三段階: Disposition
審判の日:-)を待って、
mimasa> 最終段階: W3C Recommendation
ここで、完全に仕様が固まったとみていいんですよね。この次がRFC、と。
mimasa> ＃詳しくは、http://www.w3.org/pub/WWW/MarkUp/Wilbur/#pr-review あたり
mimasa> ＃を参照してください。
石川さん、さんきゅうです。結局、まだ本決まりではない、ってことですね。
mimasa> ところで、仮にHTML 3.2がW3C Recommendationになったとして、すでにIETFで
mimasa> proposed standardとして承認されたdraft-ieft-html-i18nがもし"Category:
mimasa> Standards Track"なRFCになったとしたら、 一体どっちがHTMLの標準なんでし
mimasa> ょうね。方向性が全然違うんですけど…。
えっと、両方並立、ってわけにはいかないのでしょうか？ でも不便だな…。
とにかく、どちらかがRFCになった時点で、HTML2.0は引退ってことに
なるんでしょうか？
--
喜瀬“冬猫”浩＠南国沖縄
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月13日(水) 01時28分20秒頃、
fj.net.infosystems.www,fj.net.infosystems.www.authoringの
<E0rn3...@vega.aichi-u.ac.jp>の記事において私は書きました。
>それでも、「公式に」DTDを公開しているという点では、私はMicrosoftの姿勢
>を高く評価しています。 Microsoftが本当にオープンにやる気があるかどうか
>は、IE 3.0以降もきちんとDTDを公開するかにかかっていると言えるでしょう。
>とりあえずIE 3.0のサポートタグ一覧は公表していますので、公開する気はあ
>るのかな…という気はしていますが。
とか何とか言ってたら、 MicrosoftのWebサイトでIE 3.0のDTDが公開されまし
た。http://www.microsoft.com/workshop/author/ref/ie3dtd-f.htm から入手
できます。エライぞMicrosoft!
＃マイクロソフトの方は確認してませんが、公開してくれるんでしょうかね…
IE 3.0の拡張を使う場合は、DOCTYPE宣言で
<!DOCTYPE HTML PUBLIC "-//Microsoft//DTD Internet Explorer 3.0 HTML//EN">
と書けば良いようです。IE拡張の是非はともかく、これでIE 3.0の拡張を使っ
ても、HTML(SGML)的に正しく書くことはできますね。
＃でも、Form-based File Uploadをサポートしてないのに、INPUT タグの
＃TYPE属性の属性値に"FILE"が定義されてるのはちょっとサギな気もする(^^;)
別にMicrosoftの肩を持つつもりはありませんが、独自に拡張を加えるならDTD
で仕様を明らかにするのは、最低限の義務だと思います。Netscape Comm.社を
はじめとする他のWebブラウザベンダも見習って欲しいものです。
＃MicrosoftがDTDを公開してくれる限り、 j?weblintでもIE拡張をサポートで
＃きると思いますが、 DTDを公開してくれない拡張を今後もサポートするかは
＃わかりません。少なくとも私はやりたくない…。
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月15日(金) 21時30分02秒頃、
fj.net.infosystems.www.authoringの<56hnoa$d...@newsgate.so-net.or.jp>の
記事においてkn...@da2.so-net.or.jp (Takatsugu Nokubi)さんは書きました。
>磯尾さん>
>> でも結局、どのメジャーブラウザも正確なDTDを出していなくて、メーカー非依存の
>> 公開DTDが英語DTDしか無いんであれば「日本語ページではどんなDOCTYPE付けても結
>> 局間違い」なような気がしてきました。
野首さん>
> 「どんな DOCTYPE 付けても」はさすがに言い過ぎのような ... ^^;
そんなあなたに、<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN"> を
お勧めします(^^)。私は最近敢えて実験的にこう書くことにしました。Latin-
1に収まらない言語をまともに扱いたいなら、 今のところこれが一番妥当なん
じゃないかと思います。もうすぐRFCになるはずですし…。
>それはともかく、DTD の無い Netscape 拡張などを使う場合には「つけない」
>ほうがマシな気がします。
ところが、RFC 1866に
> NOTE - If the body of a `text/html' message entity does not begin
> with a document type declaration, an HTML user agent should infer
> the above document type declaration.
とあるので、RFC 1866に正しく準拠したuser agentであれば、「つけない」と
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> と宣言したのと同じ
ことになってしまうのでした(^^;)。いっそ`text/html'で送るのを止めて、
`text/x-pseudo-html'とかで送るといいかもしれません:-)。
>> 本文(?)中に--が現れるのもSGML的にはまずいわけですね。
>
> 最初、石川さんの文章を「(宣言内の) -- と -- で囲まれたものである」と
>読んだのですが、それは私の読み間違いでしょうか?
まあSGML的に厳密な話は詳しい方にお任せするとして、「HTMLの」コメントの
書式は、RFC 1866によれば
> 3.2.5. Comments
>
> To include comments in an HTML document, use a comment declaration. A
> comment declaration consists of `<!' followed by zero or more
> comments followed by `>'. Each comment starts with `--' and includes
> all text up to and including the next occurrence of `--'. In a
> comment declaration, white space is allowed after each comment, but
> not before the first comment. The entire comment declaration is
> ignored.
ということになってます。SGML的には最初のコメントの前に空白文字が入って
も構わない気もしますが、「HTMLの」コメントとしては許さないようです。
"The entire comment declaration is ignored."ってことは、comment
declaration中に`--'で囲まれていないものがあっても、 無視しちゃって構わ
ないんでしょうか。うーむ…。
>>人に聞かれたら「HTMLとSGMLはもう別物です」と答えようかナ。
そういう気がしますねぇ。
>>インスタンスがゴリラとチンパンジーぐらい違う気がする。
私はインスタンスがゴジラとモジラぐらい違う気がします(意味不明)。
)
磯尾です。私担当のページにはDOCTYPEいません。m(_._)m
In article <56hnoa$d...@newsgate.so-net.or.jp>, kn...@da2.so-net.or.jp
(Takatsugu Nokubi) wrote:
> 野首です。
> >> でも結局、どのメジャーブラウザも正確なDTDを出していなくて、メーカー非依存の
> >> 公開DTDが英語DTDしか無いんであれば「日本語ページではどんなDOCTYPE付けても結
> >> 局間違い」なような気がしてきました。
>
> 「どんな DOCTYPE 付けても」はさすがに言い過ぎのような ... ^^; それは
> ともかく、DTD の無い Netscape 拡張などを使う場合には「つけない」ほうが
> マシな気がします。
なるほど、付いてなくて間違いではなかったのか、よかったよかった。(^_^;
# すべてのページにFRAME使えばDOCTYPEいらないな（本末転倒）。
# いや、その、DOCTYPE嫌いじゃないんですけど…。
> ＃本当は「そんなものは絶対に使わない」という態度で臨みたいところですが、
> ＃なかなかそうも言っていられない ... ;_;
で、結局最大公倍数(!)なページになったりする。＞自分
)
磯尾@MMCコンピュータリサーチです。
> 石川＠weblint-victimsです。
> >磯尾さん>
> >> でも結局、どのメジャーブラウザも正確なDTDを出していなくて、メーカー非依存の
> >> 公開DTDが英語DTDしか無いんであれば「日本語ページではどんなDOCTYPE付けても結
> >> 局間違い」なような気がしてきました。
> そんなあなたに、<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN"> を
> お勧めします(^^)。 （以下略）
なるほど。参考にさせていただきたいと思います。
でもネスケ拡張とかも使った気がするなぁ…。
> とあるので、RFC 1866に正しく準拠したuser agentであれば、「つけない」と
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> と宣言したのと同じ
> ことになってしまうのでした(^^;)。いっそ`text/html'で送るのを止めて、
> `text/x-pseudo-html'とかで送るといいかもしれません:-)。
あるいはtest/x-netscape-301-htmlとか。(-_-)
> >> 本文(?)中に--が現れるのもSGML的にはまずいわけですね。
> まあSGML的に厳密な話は詳しい方にお任せするとして、「HTMLの」コメントの
> 書式は、RFC 1866によれば
（さくっ）
> "The entire comment declaration is ignored."ってことは、comment
> declaration中に`--'で囲まれていないものがあっても、 無視しちゃって構わ
> ないんでしょうか。うーむ…。
正しく書かれていれば、コメントとみなして無視する。
間違っていれば「Bad HTML」と表示するなり「Syntax error」と表示して終了する
なり…という方面ではないかと。(^_^;;
# 「<!>」もコメントとして正しいとは気が付かなんだ。
--
Tetsuji Isoo / 磯尾 哲司
CAE Group, MMC Computer Research Ltd.
E-Mail: is...@mcor.co.jp
http://www.mcor.co.jp/goods/fft/fft.html（DOCTYPEいません(-_-;）
Ito Hiroki
伊東@森林総研関西と申します。
In article <E0vFu...@vega.aichi-u.ac.jp> mim...@vega.aichi-u.ac.jp
(Masayasu Ishikawa) writes:
>となっていたのです(-_-#)。 いつの間にやらHTML 3.2 (Wilbur) はW3Cの
>Proposed Recommendationになってますが、 今もってフレーム機能は仕様に盛
>り込まれていません。一時期雑誌等で「IE 3.0では『HTML 3.2の』フレーム機
>能をサポートしている」という誤った説明がいくつも見受けられたので、一体
>どこがそんな間違った情報を流しているのだろう、 と思っていたのですが、
>M$KK自身が諸悪の根源だったわけです。私の知る限り、M$ Corp.の方でそのよ
>うなウソの説明を見た記憶はありません。
逸れた話にフォローして恐縮ですが、スタイルシートや<OBJECT>タグを
HTML3.2の仕様と書いてある雑誌記事がときどきあったりします(Internet
Magagine 12月号とかMacWorld11月号)。ところが、HTML3.2のDTDには、
ID, CLASS and STYLE attributes are not included in this version
of HTML.
The next version of HTML after Wilbur is code named Cougar and
will add support for <OBJECT>, client-side scripting, style
sheets, and extensions to fill-out forms.
と書いてあります。
このあたり誤解(?)の原因は何なんでしょう?
#ちなみにMacWorld11月号の記事では、<I>や<B>をNetscape拡張HTMLなどと言っ
#ております。(-_-#)
--
/* ／＼／＼ 森林総合研究所関西支所育林部造林研究室 *
* ／ 大 ＼ ＼ 伊東宏樹 *
* ／ hir...@fsm.affrc.go.jp */
Takatsugu Nokubi
野首です。
<E125t...@vega.aichi-u.ac.jp>の記事において
mim...@vega.aichi-u.ac.jpさんは書きました。
>> とか何とか言ってたら、 MicrosoftのWebサイトでIE 3.0のDTDが公開されまし
>> た。http://www.microsoft.com/workshop/author/ref/ie3dtd-f.htm から入手
>> できます。エライぞMicrosoft!
しまった、知らずに公開要求を出してしまった ^^;
>> ＃マイクロソフトの方は確認してませんが、公開してくれるんでしょうかね…
まあ、こちらにも要求は出したので、これで公開してくれない時には堂々と
批判しましょう :-)
>> IE 3.0の拡張を使う場合は、DOCTYPE宣言で
>>
>> <!DOCTYPE HTML PUBLIC "-//Microsoft//DTD Internet Explorer 3.0 HTML//EN">
>>
>> と書けば良いようです。IE拡張の是非はともかく、これでIE 3.0の拡張を使っ
>> ても、HTML(SGML)的に正しく書くことはできますね。
これで FRAME を使った HTML も心置きなく書けます ^^
>> ＃でも、Form-based File Uploadをサポートしてないのに、INPUT タグの
>> ＃TYPE属性の属性値に"FILE"が定義されてるのはちょっとサギな気もする(^^;)
同じ DTD が Netscape にも流用できますから、そういう意味では便利です;p
>> ＃MicrosoftがDTDを公開してくれる限り、 j?weblintでもIE拡張をサポートで
>> ＃きると思いますが、 DTDを公開してくれない拡張を今後もサポートするかは
>> ＃わかりません。少なくとも私はやりたくない…。
やはり、わざとサポートをしないことで世に問い掛けるというのがよろしい
のではないかと ^^
---
野首 貴嗣
kn...@da2.so-net.or.jp
Takatsugu Nokubi
野首です。
<E125z...@vega.aichi-u.ac.jp>の記事において
mim...@vega.aichi-u.ac.jpさんは書きました。
>> >> でも結局、どのメジャーブラウザも正確なDTDを出していなくて、メーカー非依存の
>> >> 公開DTDが英語DTDしか無いんであれば「日本語ページではどんなDOCTYPE付けても結
>> >> 局間違い」なような気がしてきました。
>>
>> そんなあなたに、<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN"> を
>> お勧めします(^^)。私は最近敢えて実験的にこう書くことにしました。Latin-
>> 1に収まらない言語をまともに扱いたいなら、 今のところこれが一番妥当なん
>> じゃないかと思います。もうすぐRFCになるはずですし…。
日本語を使いたい && Wilbur/Cougar なタグを使いたい、という場合はどう
すべきなんでしょうか ... 言語をとるべきか、タグをとるべきか、悩ましい
ところです。
>> >それはともかく、DTD の無い Netscape 拡張などを使う場合には「つけない」
>> >ほうがマシな気がします。
>>
>> ところが、RFC 1866に
>>
>> > NOTE - If the body of a `text/html' message entity does not begin
>> > with a document type declaration, an HTML user agent should infer
>> > the above document type declaration.
>>
>> とあるので、RFC 1866に正しく準拠したuser agentであれば、「つけない」と
>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> と宣言したのと同じ
>> ことになってしまうのでした(^^;)。
そうなんですよねえ。まあ、もじらは RFC 1866 に対応してない、って話も
ありますが、規格をきちんと守った user agent から見れば迷惑な話ですよね。
>> いっそ`text/html'で送るのを止めて、
>> `text/x-pseudo-html'とかで送るといいかもしれません:-)。
^^^^^^^^^^^^^^^^^^
これいいですね。実際に送ったら見れないでしょうけど ^^;
>> まあSGML的に厳密な話は詳しい方にお任せするとして、「HTMLの」コメントの
>> 書式は、RFC 1866によれば
>>
>> > 3.2.5. Comments
>> >
>> > To include comments in an HTML document, use a comment declaration. A
>> > comment declaration consists of `<!' followed by zero or more
>> > comments followed by `>'. Each comment starts with `--' and includes
>> > all text up to and including the next occurrence of `--'. In a
>> > comment declaration, white space is allowed after each comment, but
>> > not before the first comment. The entire comment declaration is
>> > ignored.
>>
>> ということになってます。SGML的には最初のコメントの前に空白文字が入って
>> も構わない気もしますが、「HTMLの」コメントとしては許さないようです。
>> "The entire comment declaration is ignored."ってことは、comment
>> declaration中に`--'で囲まれていないものがあっても、 無視しちゃって構わ
>> ないんでしょうか。うーむ…。
ここでいう "The entire comment declaration" は、「"<!" の後にゼロ以
上のコメント(comments)が続いて ">" で終わるもの」の全体を指し、さらに
その "comments" は、「"--" で始まって "--" で終わるもの」を指している
のだと思います。よって、この場合は間違った(というか、コメントの間の)部
分については特に言及していないとみて良いのではと思うのですが、なかなか
断言しにくい書き方ですね。
ところで、これを読むと "<!>" と書いたものも "comment declaration" と
して扱って良いようですけど、これは SGML 的にどうなんでしょうか。
＃やっぱりもっと詳しい本を買うべきかなあ。
>> >>人に聞かれたら「HTMLとSGMLはもう別物です」と答えようかナ。
>>
>> そういう気がしますねぇ。
私もです。かといって、それを根拠に見栄えを定義するタグを拡張されるの
も困りますけどね。いや、むしろ拡張された結果別物になったというべきか。
>> >>インスタンスがゴリラとチンパンジーぐらい違う気がする。
>>
>> 私はインスタンスがゴジラとモジラぐらい違う気がします(意味不明)。
ゴジラとメカゴジラぐらい違う、ってのはダメですか? ^^;
ha...@astec.co.jp
はないです。
いきなり話題を変えてしまって恐縮なんですが…
＃ なので、他のとこにもフッてます。
石川センセイ:
>＃でも、Form-based File Uploadをサポートしてないのに、INPUT タグの
>＃TYPE属性の属性値に"FILE"が定義されてるのはちょっとサギな気もする(^^;)
これ、RFC1867(Category: Experimental) で定義してあるヤツですよね。
これをサポートしているブラウザって、ねすけ以外にありますでしょうか?
＃ ねすけのどのヴァージョンからサポートしてるのかはよく知りません。
＃ 3.?(β版も含む) くらいからかな?
あ、それと、サポートしているサーバも知りたかったりします。
＃ PHP/FI を使うっていう方法以外にです ;-)
>別にMicrosoftの肩を持つつもりはありませんが、独自に拡張を加えるならDTD
>で仕様を明らかにするのは、最低限の義務だと思います。Netscape Comm.社を
>はじめとする他のWebブラウザベンダも見習って欲しいものです。
みんなで、要求しましょう!
-----はない
ha...@astec.co.jp
わたし:
>いきなり話題を変えてしまって恐縮なんですが…
>＃ なので、他のとこにもフッてます。
ががーん、servers と browsers を server と browser にしてました。
もっかいふりなおします。
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月20日(水) 10時13分06秒頃、
fj.net.infosystems.www.authoringの<56tlv2$1...@colias.tutics.tut.ac.jp>の記事に
おいてwata...@protenor.dsl.tutics.tut.ac.jp. (Iwao Watanabe)さんは書きました。
>> そんなあなたに、<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN"> を
>> お勧めします(^^)。私は最近敢えて実験的にこう書くことにしました。Latin-
>> 1に収まらない言語をまともに扱いたいなら、 今のところこれが一番妥当なん
>> じゃないかと思います。もうすぐRFCになるはずですし…。
>
>上記の!DOCTYPEの最後の要素のENがEnglishつまり英語を
>表していたと思いますが、日本語を表すのなら、
>JA(それともJP？) でないとおかしいのでは？
いえ、私の draft-ietf-html-i18n-05.txt の読み方が間違っていなければ、
DOCTYPE宣言としては"EN"でいいと思います。 どの言語を使うかは、各タグの
LANG属性で表すべき問題かと思います。そうでないと複数の言語を混在させた
いときに困るのではないでしょうか。HTML 2.xはinternationalizationのため
のもので、Japanizationに特化したものではありませんから。文書全体を日本
語で書きたいなら、<HTML>や<BODY>タグのLANG属性でそう指定すればいいです
ね。
＃現在jweblint Home Pageはそういう理解で書いてるんですけど、おかしいで
＃すかねぇ…
Iwao Watanabe
このスレッドは途中からしか読んでないので
もしかしたら見当違いかもしれませんが…
On Mon, 18 Nov 1996 05:52 JST
mim...@vega.aichi-u.ac.jp said:
>> 石川＠weblint-victimsです。
>>
>> 私の記憶が確かならば、JST時間1996年11月15日(金) 21時30分02秒頃、
>> fj.net.infosystems.www.authoringの<56hnoa$d...@newsgate.so-net.or.jp>の
>> 記事においてkn...@da2.so-net.or.jp (Takatsugu Nokubi)さんは書きました。
>>
>> >磯尾さん>
>> >> でも結局、どのメジャーブラウザも正確なDTDを出していなくて、
>> >> メーカー非依存の公開DTDが英語DTDしか無いんであれば
>> >> 「日本語ページではどんなDOCTYPE付けても結局間違い」なような
>> >> 気がしてきました。
>>
>> 野首さん>
>> > 「どんな DOCTYPE 付けても」はさすがに言い過ぎのような ... ^^;
>>
>> そんなあなたに、<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN"> を
>> お勧めします(^^)。私は最近敢えて実験的にこう書くことにしました。Latin-
>> 1に収まらない言語をまともに扱いたいなら、 今のところこれが一番妥当なん
>> じゃないかと思います。もうすぐRFCになるはずですし…。
上記の!DOCTYPEの最後の要素のENがEnglishつまり英語を
表していたと思いますが、日本語を表すのなら、
JA(それともJP？) でないとおかしいのでは？
ENかJAこだわるなら、例えば
<!DOCTYPE HTML PUBLIC "-//Microsoft//DTD Internet Explorer 3.0 HTML//JA">
などが公開されれば 日本語版 IE3.0のDOCTYPEという
意味になると思うのですけど いかがでしょう。
Masayasu Ishikawa
石川＠愛知大学です。
私の記憶が確かならば、JST時間1996年11月19日(火) 15時43分39秒頃、
fj.net.infosystems.www.authoring,fj.net.infosystems.www.browsers,
fj.net.infosystems.www.serversの<E13uo...@astec.co.jp>の記事において
ha...@astec.co.jpさんは書きました。
はない老師>
>ががーん、servers と browsers を server と browser にしてました。
>もっかいふりなおします。
あ、 そういうことでしたか、それでauthoringにしか記事が来なかったのです
ね。
＃んでも、こーゆー場合はsupersedes: なされば済んだのでは…
>これ、RFC1867(Category: Experimental) で定義してあるヤツですよね。
そうです。HTML 2.xでもHTML 3.2でもサポートされてますので、今後はこれを
サポートしてないブラウザは時代遅れになってしまうかもしれません…。
＃Lynxでサポートしてくれないかなぁ…
>これをサポートしているブラウザって、ねすけ以外にありますでしょうか?
私も知りたいのですが、今のところMozilla位しか知りません。Amayaとかはど
うなんでしょう。これをサポートしてなきゃHTML 3.2準拠は名乗れないと思う
んですけど。
>＃ ねすけのどのヴァージョンからサポートしてるのかはよく知りません。
>＃ 3.?(β版も含む) くらいからかな?
少なくとも2.0βの頃からサポートしていたようです。 『続・HTML入門』にも
解説がありますし:-)。Mozilla 2.0が出た頃にできた
http://home.netscape.com/assist/net_sites/html_extensions_3.html に解
説があることから考えても、 Version 2からサポートしてたのは間違いないと
思います。全てのOS上のヴァージョンでそうだったかまではわかりませんが…。
>>別にMicrosoftの肩を持つつもりはありませんが、独自に拡張を加えるならDTD
>>で仕様を明らかにするのは、最低限の義務だと思います。Netscape Comm.社を
>>はじめとする他のWebブラウザベンダも見習って欲しいものです。
>
>みんなで、要求しましょう!
というわけで、「DTDを公開しよう」キャンペーン再び実施中なのでした。
Takatsugu Nokubi
野首です。
<56oa05$l...@sunsp.sunsp.mcor.co.jp>の記事において
is...@mcor.co.jpさんは書きました。
>> 磯尾です。私担当のページにはDOCTYPEいません。m(_._)m
私も今のところそうですが、これから付ける予定です。
＃私個人のページは HTML 2.0 の範疇なので、付けなくても問題ないんですけ
＃どね ^^ これから "-//IETF//DTD HTML i18n//EN" を付けるつもりはありま
＃すけど。
>> > 「どんな DOCTYPE 付けても」はさすがに言い過ぎのような ... ^^; それは
>> > ともかく、DTD の無い Netscape 拡張などを使う場合には「つけない」ほうが
>> > マシな気がします。
>>
>> なるほど、付いてなくて間違いではなかったのか、よかったよかった。(^_^;
ちょ、ちょっと待ってください。これはあくまで個人的な感想ですから、そ
れをもって「間違いない」と考えるのは止めておいた方がいいですよ。別記事
<E125z...@vega.aichi-u.ac.jp> で石川さんが書かれているように、「RFC
1866 準拠であれば DOCTYPE 宣言がないものは HTML 2.0 Level 2 として扱わ
れる」ことになりますから。
Netscape Navigator は DOCTYPE をぜんぜん見ていないので、それならまだ
書かない方が良いかな、と個人的に思っただけなのです。これ以外に、
Netscape Navigator Gold で作成した HTML に付けられる DOCTYPE 宣言
"-//IETF//DTD HTML 3.2//EN" でも良いかなと思ったこともあります。
で、いろいろ考えた挙げ句、どちらも正しく DOCTYPE 宣言を扱う実装にとっ
ては同様に迷惑だ、というごく当たり前な結論にたどり着きました。
幸いなことに IE3.0 の DTD が公開されましたから、これを指定し適合しな
いタグは使わない、という選択がとれるのでいいですけどね。
＃主に仕事で使うブラウザも IE に変えようかな ...
>> > ＃本当は「そんなものは絶対に使わない」という態度で臨みたいところですが、
>> > ＃なかなかそうも言っていられない ... ;_;
>>
>> で、結局最大公倍数(!)なページになったりする。＞自分
見栄えタグ + CSS なページを書く予定はあったりします ^^;
---
野首 貴嗣
kn...@da2.so-net.or.jp
K.Oguchi
小口と申します。
於 <E13Lo...@astec.co.jp>
ha...@astec.co.jp 文中述及:
>>＃でも、Form-based File Uploadをサポートしてないのに、INPUT タグの
>>＃TYPE属性の属性値に"FILE"が定義されてるのはちょっとサギな気もする(^^;)
>
>これ、RFC1867(Category: Experimental) で定義してあるヤツですよね。
>これをサポートしているブラウザって、ねすけ以外にありますでしょうか?
>＃ ねすけのどのヴァージョンからサポートしてるのかはよく知りません。
>＃ 3.?(β版も含む) くらいからかな?
ねすけは2.?の頃にはサポートしてましたね。
詳しくいつからかはわかりませんが、
少なくとも今年の4月の時点ではサポートしていました。
(自作の処理プログラムの日付より ^_^)
Lynxはサポートしていないです。
chimeraはファイル名だけ送ってくれるが、これは何か勘違いしているみたい。
multipartぢゃないし。
Lynxはサポートしてくれないのかなぁ?
TYPE="text"と同じ入力方式のところに絶対パスでファイル名書く、
というような感じでいいから。
セパレータなんかは、固定(いつも同じ)でいいから。
# そういう改造が出来ないかな、
# 要は、サーバに渡すデータの処理するところに、
# echo (ヘッダ); echo (セパレータ); cat (ファイル); echo (セパレータ)
# てな具合のを入れりゃいいんでしょ、
# などという安易な考えでソース見たりするのだけど
# 基礎(Cの知識等)が全くないものだから...
>あ、それと、サポートしているサーバも知りたかったりします。
>＃ PHP/FI を使うっていう方法以外にです ;-)
POST(標準入力)で飛んでくるだけなので、
サーバは関係ないような気がしますが。
そもそも、サーバの方で
CERNのcgiparse(やPHP/FI)のようなことまでしてくれる
サーバ、てあります?
_________________________________________
/| SEIKO EPSON CO. Watch Design Dept. |\ /|
/@|<] Keiichiro Oguchi | X |
`>_|__oguchi....@senet.ha.epson.co.jp_|/ \|
Iwao Watanabe
On Wed, 20 Nov 1996 11:57 JST
mim...@vega.aichi-u.ac.jp said:
>> いえ、私の draft-ietf-html-i18n-05.txt の読み方が間違っていなければ、
>> DOCTYPE宣言としては"EN"でいいと思います。 どの言語を使うかは、各タグの
>> LANG属性で表すべき問題かと思います。そうでないと複数の言語を混在させた
>> いときに困るのではないでしょうか。HTML 2.xはinternationalizationのため
>> のもので、Japanizationに特化したものではありませんから。文書全体を日本
>> 語で書きたいなら、<HTML>や<BODY>タグのLANG属性でそう指定すればいいです
>> ね。
<html>タグや<body>タグはファイルにつき一つしか許されないと
認識しているのですが、
それなら複数の言語を混在などできないのではないでしょうか？
!DOCTYPEのJA宣言となんら効果に違いはないような気がします。
そもそも本当にi18nなるDTDが用意できるのなら、
宣言のところでわざわざENと断る必要も無いでしょう。
!DOCTYPEにおけるJA宣言はISO-2022-JP-2を許すというようにDTDが
定義されていれば、少なくとも そこに含まれている文字セットが
表示できるようになり、当面 日本人の要求に対しては
よい解決策になるような気がします。
ha...@astec.co.jp
>はない老師>
ううむ…
老師と呼ばれるほど修行は積んでおらんです。
牢死くらいがワタクシにはちょうどいいんではないかと思います。
…というのはどうでもよくて!
>＃んでも、こーゆー場合はsupersedes: なされば済んだのでは…
あぁ! そうですね。今度からは気をつけます _o_
>>これ、RFC1867(Category: Experimental) で定義してあるヤツですよね。
>
>そうです。HTML 2.xでもHTML 3.2でもサポートされてますので、今後はこれを
>サポートしてないブラウザは時代遅れになってしまうかもしれません…。
そうですねぇ。受け取る側でそれなりに注意を払わんと非常にキケンなこと
にもなりかねませんが…
＃ わりと便利な時もありますね。
>＃Lynxでサポートしてくれないかなぁ…
一緒に五反田の方を見つめましょう!
>説があることから考えても、 Version 2からサポートしてたのは間違いないと
>思います。全てのOS上のヴァージョンでそうだったかまではわかりませんが…。
あ、そうなのれすか (@@)
そういえば、2 の頃のはほとんど使ってないんでした。
>>みんなで、要求しましょう!
>
>というわけで、「DTDを公開しよう」キャンペーン再び実施中なのでした。
署名を集めるとかして、Netscape Communications Corporation に要求しませんか?
-----はない
ha...@astec.co.jp
>>あ、それと、サポートしているサーバも知りたかったりします。
>>＃ PHP/FI を使うっていう方法以外にです ;-)
>
>POST(標準入力)で飛んでくるだけなので、
>サーバは関係ないような気がしますが。
そうですね。ちょっとこれは自分でもよくわけのわからんことを書いておりました。
「やってきたファイルを、PHP/FI くらい簡単に扱えるサーバ」という感じです。
＃ PHP/FI は、僕が扱いやすいと思ってるだけですなのですけど。
>そもそも、サーバの方で
>CERNのcgiparse(やPHP/FI)のようなことまでしてくれる
>サーバ、てあります?
んー、ちょと違うかもしれませんが、metahtml のサーバとか、WebObjects とか
web.sql ... なんかは、それに近いと言ってもいいんじゃないかと思うのですが…
-----はない
OA2 Nagaya Toshikazu
長家＠シャープです．
コメントの件です．
In article <56s5jd$h...@newsgate.so-net.or.jp>,
kn...@da2.so-net.or.jp wrote:
-> >> まあSGML的に厳密な話は詳しい方にお任せするとして、「HTMLの」コメントの
-> >> 書式は、RFC 1866によれば
-> >>
-> >> > 3.2.5. Comments
-> >> >
-> >> > To include comments in an HTML document, use a comment declaration. A
-> >> > comment declaration consists of `<!' followed by zero or more
-> >> > comments followed by `>'. Each comment starts with `--' and includes
-> >> > all text up to and including the next occurrence of `--'. In a
-> >> > comment declaration, white space is allowed after each comment, but
-> >> > not before the first comment. The entire comment declaration is
-> >> > ignored.
-> >>
-> >> ということになってます。SGML的には最初のコメントの前に空白文字が入って
-> >> も構わない気もしますが、「HTMLの」コメントとしては許さないようです。
-> >> "The entire comment declaration is ignored."ってことは、comment
-> >> declaration中に`--'で囲まれていないものがあっても、 無視しちゃって構わ
-> >> ないんでしょうか。うーむ…。
->
-> ここでいう "The entire comment declaration" は、「"<!" の後にゼロ以
-> 上のコメント(comments)が続いて ">" で終わるもの」の全体を指し、さらに
-> その "comments" は、「"--" で始まって "--" で終わるもの」を指している
-> のだと思います。よって、この場合は間違った(というか、コメントの間の)部
-> 分については特に言及していないとみて良いのではと思うのですが、なかなか
-> 断言しにくい書き方ですね。
間違ったものには言及していません．
「（正しく書かれた）コメント宣言全体は無視される」
「（正しい）コメント宣言とは"<!"で始まってコメントが０以上あって
">"で終わるものである」
「コメントとは"--"ではじまって"--"で終わるものである」
「コメント宣言の中には各コメントのうしろに空白が許される」
ということだけが書いてあって，コメント宣言が不正な記述であった場合
（厳密には既にそれはコメント宣言ではないのですが）に，どうするかは
書かれていません．
タグとしても宣言としても不正なので，無視するのが一般的なのでは
ないかと思いますが，結果としてコメントと同じ効果になるのですね．
（文法チェッカが必要なひとつの事例でしょうか）
"<!"の直後（最初のコメントの前）に空白が許されないのは
SGMLの規定です．（なぜこんなふうになっているかは，なんとなく
わかるようで，反面なんとなく納得でませんが．
<!-- comment -- >なんてアンバランスだと思いません？）
-> ところで、これを読むと "<!>" と書いたものも "comment declaration" と
-> して扱って良いようですけど、これは SGML 的にどうなんでしょうか。
SGMLの最小のコメントは"<!>"です．（どういうふうに使うのかな）
-> >> >>人に聞かれたら「HTMLとSGMLはもう別物です」と答えようかナ。
想像ですが，
HTMLのそもそもの最初にSGMLとの関係は「記法をまねた」くらいの
ものではなかったんじゃないでしょうか．
あとからSGMLで規定しようと追いかけた．
でもHTMLのほうが足が速い．
こんな感じではないでしょうか．
私も別物だと思っています．（別物にしても，れっきとした
規格にはなって欲しい．SGMLをはなれてもいいから）
--
長 家 利 和 シャープ(株)
nag...@oa.sharp.co.jp
Takuya ASADA
わたなべさん>
> 認識しているのですが、
> それなら複数の言語を混在などできないのではないでしょうか？
draft-ietf-html-i18n-*.txt や Cougar DTD を読みましたか？
HTML や BODY ダケでなく、ほとんどのタグに LANG 属性が付く
ようになっていますし、言語の切替えダケのためには SPAN など
のタグが用意されているです。
多言語の混在すは、SPAN でスパンスパンと切ってやればイイと
いう訳ですな（あぁ、しょーもない）。
> !DOCTYPEのJA宣言となんら効果に違いはないような気がします。
コレなんですけど、色々しらべていると、そういう使い方をするモノ
ではないように見えますねぇ。例えば
http://www.sgmlopen.org/sgml/docs/japan.htm
では SGML OPEN の Extended Reference Concrete Syntax という
ヤツが、いろいろとサンプルを提供してくれていますが、中に
"-//SGML Open:TR95xx//SYNTAX Extended (JIS X 0208:1990 repertoire//EN"
なんていう PUBLIC ENTITY もあったですし…。
詳しくは、このへんをゴソゴソとあたってみるとイイです。
> !DOCTYPEにおけるJA宣言はISO-2022-JP-2を許すというようにDTDが
> 定義されていれば、
えーと…この html-i18n のお話で出てくる LANG 属性というのは、
アクマでも RFC1766 で規定されている『言語』を書くモノでして、
『CHARSET』のお話は、また別の次元になってしまいます。
ちなみに、WWW 関係で CHARSET のお話が出てくるのは、RFC1945
HTTP/1.0 あたりになるみたいですね。
いやはや、なかなかヤヤコシいモノです。
あさだ たくや
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月20日(水) 23時01分22秒頃、
fj.net.infosystems.www.authoringの<56v2vi$8...@colias.tutics.tut.ac.jp>の記事に
おいてwata...@protenor.dsl.tutics.tut.ac.jp. (Iwao Watanabe)さんは書きました。
><html>タグや<body>タグはファイルにつき一つしか許されないと
>認識しているのですが、
ですから、「文書全体を日本語で書きたいなら」です。
>それなら複数の言語を混在などできないのではないでしょうか？
こういう場合は、「どの言語を使うかは、各タグのLANG属性で表すべき問題」
です。 例えば段落ごとに言語を変えたいなら、<P>タグのLANG属性で指定すれ
ば良いでしょう。HTML 2.xでは、ほとんどのタグでLANG属性が使えます。
>そもそも本当にi18nなるDTDが用意できるのなら、
>宣言のところでわざわざENと断る必要も無いでしょう。
draft-ietf-html-i18n-05.txt をご覧ください。
Yoshihisa Nakagawa 中川好久
| ＃私個人のページは HTML 2.0 の範疇なので、付けなくても問題ないんですけ
| ＃どね ^^ これから "-//IETF//DTD HTML i18n//EN" を付けるつもりはありま
| ＃すけど。
HTML I18N のドラフトって、コードには Unicode を規定していた
ように思ったんですが、まずくないですか？
＃どうしてこうも Unicode が好きなんだろう…。やだやだ。
--
--
日本電気株式会社 ネットワーキング技術研究所 インタネット技術部
中川 好久 y-na...@ccs.mt.nec.co.jp
jj3...@eatell.msr.prug.or.jp
Iwao Watanabe
豊橋技術科学大学のわたなべです。
以前の記事は切り返しかたがまずかったようで。
誤解を与えてしまったかも知れません。
私が参照したのはdraft-ietf-html-i18n-05.txtです。
（流し読みした程度です）
draft-ietf-html-i18n-05.txtではISO-8879のSGMLを利用していると
記述していますが、私はJISハンドブックのSGMLを参照しただけなので、
これらの違いによる判断ミスがあれば この記事で述べていることは
すべて意味を持たないので無視してください。
また今 手元にハンドブックがあるわけではないので、
１年くらい昔の記憶をたよりに記述していることもここに述べておきます。
上記のhtmlのドラフトでは、
!DOCTYPEの"-//IETF//DTD HTML i18n//EN"の宣言で
HTMLファイルのエンコーディングがISO-8859-1であることを決定し、
それぞれのタグのアトリビュートのLANGでそれがどこ国の言語として
使用していることを明示していると理解していました。
ISO-8859-1のフォント グリフを利用するとすると
英語、米語、ドイツ語、フランス語等を表現することができます。
記述された文章を人が見ると、使われている単語の具合い等で
どの国の言語を表記しているかがそれなりにわかりますが、
コンピュータにはそれはわかりません。
それをLANG属性で補うということです。
すると、コンピュータに文書処理をやらせるときに、
例えば検索するときに対象は英語だけにしてほしいというときに、
このLANG属性を参照して検索対象をしぼることに利用できます。
一連の記事を拝見していると、
「LANG属性で例えばjapanとしたら、今までISO-8859-1で書かれているHTML
文書をそのタグから対応する閉じタグまでは
ISO-2022-JPあるいはJapanese-EUCで記述することを意味することだ」と
いうように読めました。これは言い方を変えると、
タグを境に文字エンコーディングが変わるということですね。
ファイルのエンコーディングが途中で変わるという性格を持った
ファイルの解析はそれを扱うプログラムが非常に複雑になるので、
一般にはそれはあまり好ましくないとされていると思います。
htmlにそれを採用するのもよくないでしょう。
また、日本語で使われているISO-2022-JPやJapanese-EUC,Shift-JISは
ローマ字のところがISO-8859-1と一致しているからこういった芸当が
できますが、そうでない文字コードセットを用いている言語系では
この仕組みでは、タグによるエンコーディングの変更は不可能です。
draft-ietf-html-i18n-05.txtで表記しているDTDはまさしく
ISO-8859-1を対象としていると明記されています。
欧米の人たちはISO-8859-1がサポートされていればi18nだと
思っている人が多い(すくなくともX Window System関連の資料は
そのように取れる物が多いと感じています。)ので、
このドラフトもそのパターンでi18nがついているのかなと思いました。
SGMLにおいては、本当は使われるエンコーディングに応じて
DTDは変更されるべきなのですが、日本語の正しいDTDを制定する
権限をもった団体が存在していないのか、
仕事がはかどっていないのかわかりませんが、
規格は定まっていません。
＃最近、注意して調べていないので、
＃私の目に触れていないだけかも知れませんが。
さて、あさださんが述べられている
"-//SGML Open:TR95xx//SYNTAX Extended (JIS X 0208:1990 repertoire//EN"
に関してですが、まだそれを参照できていないので、
以下は類推であることを述べておきます。
私に読ませるとこれはJIS X 0208で英語を表現するためのDTDになります。
たしかにJIS X 0208のフォント グリフには英語のアルファベットが
含まれているから、このコードだけで英語は表現できます。
きっとこれに対して
"-//SGML Open:TR95xx//SYNTAX Extended (JIS X 0208:1990 repertoire//JA"
があって、そちらでJIS X 0208で日本語を表現することができるのでしょう。
もし前者のDTDのみが存在し、それが日本語を表現するようなものならば、
（意図的にENとしているのならば制定した人には失礼ですが、）
SGMLとエンコーディングの理解がきちんと理解できていない、
あるいはSGMLにおけるDTDの（DOCTYPEの）命名規則がきちんと
理解できていない人が制定したDTDではないかと思います。
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月22日(金) 10時16分53秒頃、
fj.net.infosystems.www.authoringの<572uu5$o...@colias.tutics.tut.ac.jp>の記事に
おいてwata...@protenor.dsl.tutics.tut.ac.jp. (Iwao Watanabe)さんは書きました。
>draft-ietf-html-i18n-05.txtで表記しているDTDはまさしく
>ISO-8859-1を対象としていると明記されています。
どこにでしょう? draft-ietf-html-i18n-05.txtの"1. Introduction"を読む
と、
> The Hypertext Markup Language (HTML) is a markup language used to
> create hypertext documents that are platform independent. Initially,
> the application of HTML on the World Wide Web was seriously
> restricted by its reliance on the ISO-8859-1 coded character set,
> which is appropriate only for Western European languages. Despite
> this restriction, HTML has been widely used with other languages,
> using other coded character sets or character encodings, through var-
> ious ad hoc extensions to the language [TAKADA].
>
> This document is meant to address the issue of the internationaliza-
> tion of HTML by extending the specification of HTML and giving addi-
> tional recommendations for proper internationalization support. It
> is in good part based on a paper by one of the authors on
> multilingualism on the WWW [NICOL]. A foremost consideration is to
> make sure that HTML remains a valid application of SGML, while
> enabling its use with all languages of the world.
のように書かれています。現状ISO-8859-1 coded character setに制限されて
いるHTMLのi18nを目指して書かれたこのdraftがISO-8859-1を対象としていた
ら、存在自体意味不明です。
HTML 2.xのSGML宣言では、
> CHARSET
> BASESET "ISO Registration Number 177//CHARSET
> ISO/IEC 10646-1:1993 UCS-4 with
> implementation level 3//ESC 2/5 2/15 4/6"
:
となっています。ISO-8859-1ではありません。
＃あさださんがおっしゃっているように、encodingの問題はまた別になります
＃が…
現実にどう実装するかは、 『マルチリンガル環境の実現 X Window/Wnn/Mule/
WWWブラウザでの多言語環境』(プレンティスホール出版) の中の、「第5章 国
際化WWWブラウザ Arena i18n の提案」が大いに参考になると思います。
Takatsugu Nokubi
野首です。
<E175t...@oa.sharp.co.jp>の記事において
nag...@oa.sharp.co.jpさんは書きました。
>> "<!"の直後（最初のコメントの前）に空白が許されないのは
>> SGMLの規定です．（なぜこんなふうになっているかは，なんとなく
>> わかるようで，反面なんとなく納得でませんが．
>> <!-- comment -- >なんてアンバランスだと思いません？）
確かにアンバランスな気はしますけど、<a href="hogehoeg" > が許される
ことを思えば納得できなくもないです。
>> -> ところで、これを読むと "<!>" と書いたものも "comment declaration" と
>> -> して扱って良いようですけど、これは SGML 的にどうなんでしょうか。
>>
>> SGMLの最小のコメントは"<!>"です．（どういうふうに使うのかな）
C でいう /**/ みたいなものとして捉えればよいのでしょうね。
>> -> >> >>人に聞かれたら「HTMLとSGMLはもう別物です」と答えようかナ。
>>
>> 想像ですが，
>> HTMLのそもそもの最初にSGMLとの関係は「記法をまねた」くらいの
>> ものではなかったんじゃないでしょうか．
>> あとからSGMLで規定しようと追いかけた．
>> でもHTMLのほうが足が速い．
>> こんな感じではないでしょうか．
Netscape Navigator の実装のされかたをみると、確かにそのような感じが
しますね。でも、もしかしたら Navigator だけの話なのかもしれません。IE
は DTD がありますし。
＃IE 2.0 以前にも DTD はあったのだろうか ...
>> 私も別物だと思っています．（別物にしても，れっきとした
>> 規格にはなって欲しい．SGMLをはなれてもいいから）
そうですね、今の混乱が早くなくなって欲しいものです。
Iwao Watanabe
On Fri, 22 Nov 1996 00:52 JST
mim...@vega.aichi-u.ac.jp said:
>> >draft-ietf-html-i18n-05.txtで表記しているDTDはまさしく
>> >ISO-8859-1を対象としていると明記されています。
>>
>> どこにでしょう? draft-ietf-html-i18n-05.txtの
>> "1. Introduction"を読むと、
draft-ietf-html-i18n-05.txtのDTDがISO-8859-1を
対象としているというのは私の勘違いでした。
HTMLは西欧の言語の多くを表現できるISO-8859-1だけを
対象として言語定義されているけど、実際には他のいろいろな
コードセットで用いられている。これをまとめるために
国際化ということで文書化したものをここに示します。
といったところですね。
でも、
> CHARSET
> BASESET "ISO Registration Number 177//CHARSET
> ISO/IEC 10646-1:1993 UCS-4 with
> implementation level 3//ESC 2/5 2/15 4/6"
であれば、現状のようにJapanese-EUCとかISO-2022-JPなど使ったら
だめになるのではないですか？
それに、SGMLはエンコードも定義するものだと思いますが、
-> see: draftの7.3. ISO Latin 1 entity set
HTMLになったとたんに、この関係は無視されるのですか？
それとも私のこの主張そのものが勘違いなのでしょうか？
>> 現実にどう実装するかは、 『マルチリンガル環境の実現 X Window/Wnn/Mule/
>> WWWブラウザでの多言語環境』(プレンティスホール出版) の中の、「第5章 国
>> 際化WWWブラウザ Arena i18n の提案」が大いに参考になると思います。
これは、またきれいに読み直してみることにします。
ka...@dais.is.tohoku.ac.jp
かべ＠東北大学です。私もいまいち確信が持てないんですが、
<56tlv2$1...@colias.tutics.tut.ac.jp>の記事において
wata...@protenor.dsl.tutics.tut.ac.jp.さんは書きました。
>> 上記の!DOCTYPEの最後の要素のENがEnglishつまり英語を
>> 表していたと思いますが、日本語を表すのなら、
>> JA(それともJP？) でないとおかしいのでは？
http://www.geocities.com/Athens/2694/sgml.html では、
"EN"はDTDの書かれている言語
ということなんで、(ここから推測)HTML DTD自体が英語で書かれている以上
ENなのではないか…(へんだな)
ただ、「英語の文書用(本文用)に書かれた」だとすると"JA"が正解でしょうね。
この場合は日本語本文用のDTDを別途用意して、カタログに追加
しなければならないでしょう。普通は "EN" しかないから。
Public Identifier の文法はなかなか資料が見つからないらしく、
このページの筆者も「よーわからん」と言っています。
------------------------------------------------------------------------------
かべ@dais.is.tohoku.ac.jp ＶＥＧＡ Ｓｙｓｔｅｍｓ MCMXCI
「自分はレーサーだっていうのかい？ たいしたことないじゃないか。」
------------------------------------------------------------------------------
K.Oguchi
小口と申します。
於 <E15ts...@astec.co.jp>
ha...@astec.co.jp 文中述及:
>>>これ、RFC1867(Category: Experimental) で定義してあるヤツですよね。
>>
>>そうです。HTML 2.xでもHTML 3.2でもサポートされてますので、今後はこれを
>>サポートしてないブラウザは時代遅れになってしまうかもしれません…。
>
>そうですねぇ。受け取る側でそれなりに注意を払わんと非常にキケンなこと
>にもなりかねませんが…
>＃ わりと便利な時もありますね。
>
>>＃Lynxでサポートしてくれないかなぁ…
>
>一緒に五反田の方を見つめましょう!
みんなの願いが届いたのか、サポートの気配が...
11/21版のCHANGESには
| 11-21-96
| * Added handling of forms with ENCTYPE="multipart/form-data". Note that
| we still don't support INPUTs with TYPE="file" or TYPE="range", and
| thus still set the DISABLED attribute for all fields in the form if
| either of those two TYPEs are present in it. - FM
で、GridText.cに
| StrAllocCopy(doc->post_content_type,
| "multipart/form-data; boundary=");
| StrAllocCat(doc->post_content_type, Boundary);
なんて行が出てきた ^_^
別に私は構わないっす、
| Boundary = "xnyLAaB03X";
でも。
だから、早くサポートしてほしい。
Makoto MATSUSHITA
> CHARSET
> BASESET "ISO Registration Number 177//CHARSET
> ISO/IEC 10646-1:1993 UCS-4 with
> implementation level 3//ESC 2/5 2/15 4/6"
watanabe> であれば、現状のようにJapanese-EUCとかISO-2022-JPなど使ったら
watanabe> だめになるのではないですか？
私もこの点がひっかかっているのですが‥‥ちゃんと i-d 読め，という話が
あるのですが(というのでわかる通り私はちゃんと読んでません _o_)，「どの
時点」で 10646-1 になっている必要があるのでしょうか?
# 「どの時点」という単語に相当すると考えられそうなもの:
# 文章を書いた人間が disk 上に file として作った時点
# 文書が http で送られる時点
# browser が入手した文書を parse する時点
> 現実にどう実装するかは、 『マルチリンガル環境の実現 X Window/Wnn/Mule/
> WWWブラウザでの多言語環境』(プレンティスホール出版) の中の、「第5章 国
> 際化WWWブラウザ Arena i18n の提案」が大いに参考になると思います。
watanabe> これは、またきれいに読み直してみることにします。
とりあえず
<URL:http://www.wg.omron.co.jp/~shin/Arena-jwwwc-95/>
<URL:http://www.wg.omron.co.jp/~shin/Arena-beta1d-CJK-doc/>
は参考になると思います．
-- -
Makoto `MAR_kun' MATSUSHITA
Yoshihisa Nakagawa 中川好久
中川＠ＮＥＣです。
In article <572uu5$o...@colias.tutics.tut.ac.jp> wata...@protenor.dsl.tutics.tut.ac.jp. (Iwao Watanabe) writes:
| draft-ietf-html-i18n-05.txtで表記しているDTDはまさしく
| ISO-8859-1を対象としていると明記されています。
| 欧米の人たちはISO-8859-1がサポートされていればi18nだと
| 思っている人が多い(すくなくともX Window System関連の資料は
| そのように取れる物が多いと感じています。)ので、
| このドラフトもそのパターンでi18nがついているのかなと思いました。
このドラフトでは、
2.2. The document character set
The document character set, in the SGML sense, is the Universal Char-
acter Set (UCS) of ISO 10646:1993 [ISO-10646], as amended. Cur-
rently, this is code-by-code identical with the Unicode standard,
version 1.1 [UNICODE].
と書かれていますから、Unicode じゃないんでしょうか？
（Unicode != ISO-8859-1 ですよ。）
＃それとも、私の読み方が悪い？間違ってたら、英語弱いんでごめ
＃んして…。
もちろん、Unicode だからいいかというと、むしろ非常に問題が多
いと思っています。
Masayasu Ishikawa
石川＠weblint-victimsです。
話題がずれてきたので、Subject を変えました。
若干引用が前後してますが、ご容赦をm(_ _)m。
>わたなべさん>
>>それに、SGMLはエンコードも定義するものだと思いますが、
>>-> see: draftの7.3. ISO Latin 1 entity set
>>HTMLになったとたんに、この関係は無視されるのですか？
そういうものでもないようです。draft-ietf-html-i18n-05.txt の
"2.1. Reference processing model" の項には…
> Because there are various widely differing encodings of text, SGML
> does not directly address how the sequence of characters that consti-
> tutes an SGML document in the abstract sense are encoded by means of
> a sequence of octets (or occasionally bit groups of another length
> than 8) in a concrete realization of the document such as a computer
> file. ...
(snip)
> HTML, as an application of SGML, does not directly address the ques-
> tion of the external character encoding. This is deferred to
> mechanisms external to HTML, such as MIME as used by the HTTP proto-
> col or by electronic mail.
と書いてあります。なんか逃げてるような気もしますが、ともあれエンコード
の問題はHTML自体ではなく、HTTPで扱うMIME等の問題だとされてるようです。
>>> CHARSET
>>> BASESET "ISO Registration Number 177//CHARSET
>>> ISO/IEC 10646-1:1993 UCS-4 with
>>> implementation level 3//ESC 2/5 2/15 4/6"
>わたなべさん>
>>であれば、現状のようにJapanese-EUCとかISO-2022-JPなど使ったら
>>だめになるのではないですか？
MATSUSHITAさん>
>私もこの点がひっかかっているのですが‥‥ちゃんと i-d 読め，という話が
>あるのですが(というのでわかる通り私はちゃんと読んでません _o_)，「どの
>時点」で 10646-1 になっている必要があるのでしょうか?
うーん…皆さんcharacter set(文字集合)とcharacter encoding scheme(文字
符号化方式)の話を混同してませんか? draft-ietf-html-i18n-05.txt では、
>2.2. The document character set
>
> The document character set, in the SGML sense, is the Universal Char-
> acter Set (UCS) of ISO 10646:1993 [ISO-10646], as amended. Cur-
> rently, this is code-by-code identical with the Unicode standard,
> version 1.1 [UNICODE].
のように、"character set"としてISO-10646を採用すると書いてあるだけです。
"character encoding scheme"の話は、また別の次元の話になります。まあ、
encodingはMIMEで指定するとか言っておいて、 そのMIMEでは"charset"パラメ
ータでencodingを指定するなんて紛らわしいことをやってるので、混同するの
も無理からぬ気はしますが…私も時々ワケがわからなくなりますし(^_^;)。だ
からこそ、 ""Character Set" Considered Harmful" なんてInternet Draftが
書かれたりするのかもしれません(See: draft-ietf-html-charset-harmful-00.
txt)。
＃ところで、上記のdraftは"Expires November, 1995"となってますが、 次の
＃は出てるんでしょうか?
で、HTML 2.xでencodingとして例えばISO-2022-JPを使うのは問題ないです。
そもそも draft-ietf-html-i18n-05.txt でencodingの例として引き合いに出
されているのは、以下のようにISO-2022-JPです(^_^;)。
> For the HTTP protocol [RFC1945], the external character encoding is
> indicated by the "charset" parameter of the "Content-Type" field of
> the header of an HTTP response. For example, to indicate that the
> transmitted document is encoded in the "JUNET" encoding of Japanese
> [RFC1468], the header will contain the following line:
>
> Content-Type: text/html; charset=ISO-2022-JP
RFC 1866でも、「encodingに」ISO-2022-JPを使っても良い、とは書いてあり
ますね。
問題は、多言語混在のドキュメントの場合ですけど…Arena i18nの提案でも述
べられていたように、 ISO-2022系(ISO-2022-INT1とか?)かUnicode、というこ
とになるんでしょうかねぇ…。 Unicodeを使う場合は、byte orderは上位byte
を先にするように、ということになってるようですが。
このあたりは私も詳しくないので、詳しい方のご教示をいただきたいところで
Masayasu Ishikawa
石川＠weblint-victimsです。
＃えらく遅れて元記事がこちらのサイトに記事が届きました。何だか最近配送
＃がムチャクチャですねぇ…(-_-;)。
私の記憶が確かならば、JST時間1996年11月19日(火) 20時27分41秒頃、
fj.net.infosystems.www.authoringの<56s5jd$h...@newsgate.so-net.or.jp>の記事に
おいてkn...@da2.so-net.or.jp (Takatsugu Nokubi)さんは書きました。
> 日本語を使いたい && Wilbur/Cougar なタグを使いたい、という場合はどう
>すべきなんでしょうか ... 言語をとるべきか、タグをとるべきか、悩ましい
>ところです。
Cougarまでイっちゃっていいのなら、
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Experimental 19960712//EN">
でイイのではないでしょうか。CougarのDTDを見ていただければわかりますが、
Cougarはi18n拡張を含んでいますので、HTML 2.x同様、LANG属性やDIR属性、
<SPAN>や<BDO>といったタグが使えます。もちろん、Webブラウザがそれらをサ
ポートしているか、は別問題ですけど…。
＃Lynxで早くLANGとかDIR属性をきっちり処理できるようになりませんかね…。
＃Cougar対応では一番進んでると思うんですけど…。
ところで、 どなたかCougarのSGML宣言見たことありません? DTDだけじゃイマ
イチ情報不足です…。
Takatsugu Nokubi
野首です。
<E1ELt...@vega.aichi-u.ac.jp>の記事において
mim...@vega.aichi-u.ac.jpさんは書きました。
>> > 日本語を使いたい && Wilbur/Cougar なタグを使いたい、という場合はどう
>> >すべきなんでしょうか ... 言語をとるべきか、タグをとるべきか、悩ましい
>> >ところです。
>>
>> Cougarまでイっちゃっていいのなら、
>>
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Experimental 19960712//EN">
>>
>> でイイのではないでしょうか。CougarのDTDを見ていただければわかりますが、
>> Cougarはi18n拡張を含んでいますので、HTML 2.x同様、LANG属性やDIR属性、
>> <SPAN>や<BDO>といったタグが使えます。
... よく読んで見たら、そのとおりでした --; すいません、私の理解がた
りなかったようです。
＃やっぱりナナメ読みはいかんなあ ...
結局最近は IE3.0 の DOCTYPE を付けているのですが、DTD をよくみるとこ
れもLANG 属性をサポートしていますね。
>> もちろん、Webブラウザがそれらをサ
>> ポートしているか、は別問題ですけど…。
IE3.0 は実際のところどうなんでしょう。試してみたいけど、I18N な HTML
なんて書けない ...
>> ところで、 どなたかCougarのSGML宣言見たことありません? DTDだけじゃイマ
>> イチ情報不足です…。
私も見たこと無いです。http://www.w3.org/(途中失念)/Cougar の下には
html.dtd しかないようですし。
＃W3 以外のところにあるのかな ...
Masayasu Ishikawa
石川＠weblint-victimsです。
＃Subjectを変えました。
私の記憶が確かならば、JST時間1996年11月19日(火) 20時05分22秒頃、
fj.net.infosystems.www.authoringの<HIROKI.96N...@ss.fsm.affrc.go.jp>の
記事においてhir...@fsm.affrc.go.jp (Ito Hiroki)さんは書きました。
>>り込まれていません。一時期雑誌等で「IE 3.0では『HTML 3.2の』フレーム機
>>能をサポートしている」という誤った説明がいくつも見受けられたので、一体
>>どこがそんな間違った情報を流しているのだろう、 と思っていたのですが、
>>M$KK自身が諸悪の根源だったわけです。私の知る限り、M$ Corp.の方でそのよ
>>うなウソの説明を見た記憶はありません。
伊東@森林総研関西さん>
>逸れた話にフォローして恐縮ですが、スタイルシートや<OBJECT>タグを
>HTML3.2の仕様と書いてある雑誌記事がときどきあったりします(Internet
>Magagine 12月号とかMacWorld11月号)。ところが、HTML3.2のDTDには、
>
> ID, CLASS and STYLE attributes are not included in this version
> of HTML.
>
> The next version of HTML after Wilbur is code named Cougar and
> will add support for <OBJECT>, client-side scripting, style
> sheets, and extensions to fill-out forms.
>
>と書いてあります。
>
>このあたり誤解(?)の原因は何なんでしょう?
うーん…思うに、Cougarの位置付けがイマイチ曖昧なのが一因ではないかと思
います。CougarのDTDには、
> This is an EXPERIMENTAL version of HTML (code named Cougar) that
> extends HTML 3.2 to add support for work by the HTML ERB, including
> style sheets, scripting, the object tag, internationalization and
> some extensions to forms. ...
のように書いてあります。 HTML 3.2 (Wilbur)を実験的に拡張したもの、とい
うことはわかるのですが、Cougar自身のversion numberは(まだ)ないので、こ
れがHTML 3.2の1バリエーションなのか(実際weblint-victims MLなどでもそう
思っていた人はいました)、HTML 3.3 ? 位のものなのか、あるいはHTML 4.0 ?
にでもなるようなものなのか、よくわからないのです。何しろ一般に公開され
た資料は今のところDTDしかないので…。
また、<OBJECT>タグが現在のところWilburの仕様にはなく、Cougarではサポー
トされている、というのはまあ確かなのですが、スタイルシートがWilburでサ
ポートされているか? というのは少々判断が難しいところです。以下のように、
形だけとはいえ、一応Wilburにも<STYLE>タグは定義されているからです。
<!-- SCRIPT/STYLE are place holders for transition to next version of HTML -->
<!ELEMENT STYLE - - (#PCDATA)* -(%head.misc) -- style info -->
さらにワケがわからないのは、 現在W3C Proposed Recommendationになってい
る"HTML 3.2 Reference Specification"(<URL:http://www.w3.org/pub/WWW/TR
/PR-html32-961105>)では、 Specificationの末尾に添付されている18-Sep-96
現在のdraft DTDでは確かに上記のように定義されているのに、 本文中の説明
では
<!ELEMENT STYLE - - CDATA -- placeholder for style info -->
~~~~~
となっていて、しっかり
>These elements are defined with CDATA as the content type. As a
>result they may contain only SGML characters. ...
なんて解説があったりします。 #PCDATA と CDATA ではSGML的に扱いが異なる
ので、一体どっちなんだ～! とか思ってしまいます。まあ、CDATA として扱う
方が妥当でしょうが…同じドキュメントの中でさえ矛盾しているなんてのは勘
弁して欲しいです。
これがCougarになると
<!ELEMENT STYLE - - CDATA -- style info -->
<!ATTLIST STYLE
%i18n; -- lang, dir for use with title string --
type CDATA #REQUIRED -- Internet media type for style notation --
title CDATA #IMPLIED -- advisory title for this style --
>
ということで、 もう少し具体的になりますが…。多くのタグでSTYLE属性も使
えますし。まあWilburでは「予約」されているだけで、具体的なサポートにつ
いてはCougarで、というのが妥当な解釈かなぁ、という気はします。
>#ちなみにMacWorld11月号の記事では、<I>や<B>をNetscape拡張HTMLなどと言っ
>#ております。(-_-#)
それはまた…別の意味でスゴイですねぇ(-_-;)。まあ、確かにphysical font
markupは論理的な記述を旨とする人にはあまり好まれませんし、私も使わない
ようにしていますが…。HTML 2.0のDTDを見ると、
<!ENTITY % font " TT | B | I ">
<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
のように、font markupとphrase markupは定義上も区別しているようですね。
最近雑誌等を読んでいると、「頼むからHTMLの記事を書く前にRFC 1866くらい
読んでくれ」と言いたくなるような記事が多くてアタマ抱えてます…。
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年11月27日(水) 07時02分18秒頃、
fj.net.infosystems.www.authoringの<57fpda$2...@newsgate.so-net.or.jp>の
記事においてkn...@da2.so-net.or.jp (Takatsugu Nokubi)さんは書きました。
> 結局最近は IE3.0 の DOCTYPE を付けているのですが、DTD をよくみるとこ
>れもLANG 属性をサポートしていますね。
>
>>> もちろん、Webブラウザがそれらをサ
>>> ポートしているか、は別問題ですけど…。
>
> IE3.0 は実際のところどうなんでしょう。試してみたいけど、I18N な HTML
>なんて書けない ...
http://www.microsoft.com/workshop/author/ref/ie3dtd-f.htm を読むと、
> Caveats
>
> The DTD contains some Netscape extensions that Internet Explorer does not
> support, as well as some table markup attributes that appear in the IETF
> HTML 3 Tables DTD, but that Internet Explorer does not support. Because
> we do not want HTML containing such markup to be rejected by a validating
> parser, we have included them in the DTD. These attributes are commented
> on in the DTD.
なんて書いてあります。まあ、IE 3.0のDTDによれば
<!ENTITY % attrs -- common attributes. Taken from the HTML 3 DTD --
'id ID #IMPLIED -- as target for hrefs (link ends) --
lang CDATA "en.us" -- ISO language, country code --
class NAMES #IMPLIED -- for subclassing elements --
style CDATA #IMPLIED'>
ということですから、 単にHTML 3.0のDTDから適当に持ってきただけ、という
気もします(^^;)。
しかし、じゃあIE 3.0はLANG属性を全然サポートしていないのか、というとど
うもそうでもないようで、 IEのHTML Reference(こちらはおそらく実装ベース
の解説だと思います)をよく読むと、<DIV>タグのところにはちゃんとLANG属性
の説明があります。
というわけで状況はなかなかヤヤコシイのですが、ちなみにjweblint v0.142c
[26-Nov-96] ではどうしたかというと、
> Because we do not want HTML containing such markup to be rejected by
> a validating parser, we have included them in the DTD.
というMicrosoftの見解を尊重して、DTD通りにLANG属性を定義しました。
＃ある意味では、「さっさとDTD通りにLANG属性をサポートせんかい、オラァ!」
＃という無言のプレッシャーでもあります:-)。
>> ところで、 どなたかCougarのSGML宣言見たことありません? DTDだけじゃイマ
>> イチ情報不足です…。
>
> 私も見たこと無いです。http://www.w3.org/(途中失念)/Cougar の下には
>html.dtd しかないようですし。
ちなみに正確なURLは、http://www.w3.org/pub/WWW/MarkUp/Cougar/HTML.dtd
ですね。
>＃W3 以外のところにあるのかな ...
W3Cメンバーオンリーならそういう情報もあるのかもしれませんね。私はW3Cと
は何の関係もないので知りようもないですけど。
＃コッソリ慶應の人に聞いてみるとか;-)
Takatsugu Nokubi
野首です。
<56v0f7$i...@epsongw.epson.co.jp>の記事において
oguchi.k...@senet.ha.epson.co.jpさんは書きました。
>> ねすけは2.?の頃にはサポートしてましたね。
>> 詳しくいつからかはわかりませんが、
>> 少なくとも今年の4月の時点ではサポートしていました。
>> (自作の処理プログラムの日付より ^_^)
ちょっと前に仕事で Form-based File Upload を行う羽目になってしまった
のですが、その時に変な現象を見つけてしまいました。Win32 版 Netscape
3.0 と Mac 版 Netscape 3.0 とで動作が違うのです。
具体的には、送られてくるファイル名が Win32 ではドライブレターを含む
フルパス、Mac ではパスのないファイル名のみという動作でした。
＃rfc1867 には path を含むとも含まないともかいてないので、どちらの実装
＃が妥当なのかわからない ... 例を見る限りは path は含まれないけど ... ?
K.Oguchi
小口です。
於 <57vgmd$l...@newsgate.so-net.or.jp>
kn...@da2.so-net.or.jp 文中述及:
> ちょっと前に仕事で Form-based File Upload を行う羽目になってしまった
>のですが、その時に変な現象を見つけてしまいました。Win32 版 Netscape
>3.0 と Mac 版 Netscape 3.0 とで動作が違うのです。
> 具体的には、送られてくるファイル名が Win32 ではドライブレターを含む
>フルパス、Mac ではパスのないファイル名のみという動作でした。
私もunixとwindowsで同様の現象を経験しています。
unixでは、Macと同様にパスのないファイル名でした。
自作のプログラムでは、
カレントディレクトリーに元のファイル名でファイルを
セーブするようにしているのですが
unixだけで試した後、PCのNetscapeから実行したら、
C:\HOGE\HOGEHOGE.DAT
なんていう名のファイルがカレントに出来てしまって (-_-#)
>＃rfc1867 には path を含むとも含まないともかいてないので、どちらの実装
>＃が妥当なのかわからない ... 例を見る限りは path は含まれないけど ... ?
う～ん、でもフルパスは意味無いと思うのです。
Takatsugu Nokubi
野首です。
<E1JJ5...@vega.aichi-u.ac.jp>の記事において
mim...@vega.aichi-u.ac.jpさんは書きました。
>> しかし、じゃあIE 3.0はLANG属性を全然サポートしていないのか、というとど
>> うもそうでもないようで、 IEのHTML Reference(こちらはおそらく実装ベース
>> の解説だと思います)をよく読むと、<DIV>タグのところにはちゃんとLANG属性
>> の説明があります。
ActiveX SDK についている "Microsoft Internet Explorer 3.0 HTML
Reference" には LANG 属性のことはまったく書かれていませんでした。そこ
で、MS の WWW を漁ってみたのですが、確かに IE 3.01 の Reference には書
いてありますね。charset の説明も増えていました。
というわけで、正確には IE 3.01 から LANG をサポートしているというこ
とのようです。
＃ところで、これらのページの DOCTYPE もいいかげんですね。FRAME を使っ
＃ているのに<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> になってい
＃ます。
>> ちなみに正確なURLは、http://www.w3.org/pub/WWW/MarkUp/Cougar/HTML.dtd
>> ですね。
補足をありがとうございます。
＃普段ネットワークが手軽に使えるところにいないもので ... ^^; 最近 ISDN
＃が導入されて、かなり改善されましたけど。
---
野首 貴嗣
kn...@da2.so-net.or.jp
Ito Hiroki
伊東@森林総研関西と申します。
In article <E1JJ3...@vega.aichi-u.ac.jp> mim...@vega.aichi-u.ac.jp
(Masayasu Ishikawa) writes:
>うーん…思うに、Cougarの位置付けがイマイチ曖昧なのが一因ではないかと思
>います。CougarのDTDには、
>
>> This is an EXPERIMENTAL version of HTML (code named Cougar) that
>> extends HTML 3.2 to add support for work by the HTML ERB, including
>> style sheets, scripting, the object tag, internationalization and
>> some extensions to forms. ...
>
>のように書いてあります。 HTML 3.2 (Wilbur)を実験的に拡張したもの、とい
>うことはわかるのですが、Cougar自身のversion numberは(まだ)ないので、こ
>れがHTML 3.2の1バリエーションなのか(実際weblint-victims MLなどでもそう
>思っていた人はいました)、HTML 3.3 ? 位のものなのか、あるいはHTML 4.0 ?
>にでもなるようなものなのか、よくわからないのです。何しろ一般に公開され
>た資料は今のところDTDしかないので…。
ううむ。ということは、HTML3.2でCougarなタグが実装されている(べき)と思う
人がいても止むをえないということなのでありましょうか?うーむ。
>>#ちなみにMacWorld11月号の記事では、<I>や<B>をNetscape拡張HTMLなどと言っ
>>#ております。(-_-#)
>
>それはまた…別の意味でスゴイですねぇ(-_-;)。まあ、確かにphysical font
>markupは論理的な記述を旨とする人にはあまり好まれませんし、私も使わない
>ようにしていますが…。HTML 2.0のDTDを見ると、
>
><!ENTITY % font " TT | B | I ">
>
><!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
>
>のように、font markupとphrase markupは定義上も区別しているようですね。
私の属している生物学な業界では学名はイタリックで、さもなければアンダー
ラインを引くということになっていたりするのですが、このあたりは物理的な
タグでもしょうがないのでしょうか。それ専用のタグがあったりすると便利な
のですがねえ。うーむ。
>最近雑誌等を読んでいると、「頼むからHTMLの記事を書く前にRFC 1866くらい
>読んでくれ」と言いたくなるような記事が多くてアタマ抱えてます…。
このあたりは同感だったりするのです。はい。
--
/* ／＼／＼ 森林総合研究所関西支所育林部造林研究室 *
* ／ 大 ＼ ＼ 伊東宏樹 *
* ／ hir...@fsm.affrc.go.jp */
ka...@dais.is.tohoku.ac.jp
かべ＠東北大学です。
<HIROKI.96...@ss.fsm.affrc.go.jp>の記事において
hir...@fsm.affrc.go.jpさんは書きました。
>> 私の属している生物学な業界では学名はイタリックで、さもなければアンダー
>> ラインを引くということになっていたりするのですが、このあたりは物理的な
>> タグでもしょうがないのでしょうか。それ専用のタグがあったりすると便利な
>> のですがねえ。うーむ。
似たような要求は方々からあるでしょうね。
まじめにDTD書いて、HTMLへのトランスレータを作るのが本筋ですが、
むりやりHTMLで書くなら
<HEAD>
...
<STYLE>
SPAN.sn {font:italic}
</STYLE>
</HEAD>
<BODY>
...
<SPAN class="sn">homo sapiens</SPAN>
が、たぶん今のところ一番すっきりした解決法でしょう。単に<I>とするより
大幅にバイト数が増えるのが欠点ですか。
＃手近にはMSIE 3.0しかこれに対応してないんですが
Masayasu Ishikawa
石川＠weblint-victimsです。
私の記憶が確かならば、JST時間1996年12月04日(水) 22時00分15秒頃、
fj.net.infosystems.www.authoringの<HIROKI.96...@ss.fsm.affrc.go.jp>の
記事においてhir...@fsm.affrc.go.jp (Ito Hiroki)さんは書きました。
>ううむ。ということは、HTML3.2でCougarなタグが実装されている(べき)と思う
>人がいても止むをえないということなのでありましょうか?うーむ。
うーむ、どうなんでしょう。 何しろDTD一つだけでは、部外者の私には何とも
判断のしようがないです。
＃慶應の方、コッソリ教えてくれません? (最近こればっか:-)
>>それはまた…別の意味でスゴイですねぇ(-_-;)。まあ、確かにphysical font
>>markupは論理的な記述を旨とする人にはあまり好まれませんし、私も使わない
>>ようにしていますが…。
(中略)
>私の属している生物学な業界では学名はイタリックで、さもなければアンダー
>ラインを引くということになっていたりするのですが、このあたりは物理的な
>タグでもしょうがないのでしょうか。
いやぁ、私の属している法学な世界では、"Uniform System of Citation(通称
Blue Book)"なる本に事細かに引用のルールが決められていて、 例えば書籍を
引用するときは、 著者名と書名はSmall Capital体でないといけなかったりし
ます。すでにこの時点でHTML 2.0のレベルでは対応しようがないですね(--;)。
＃私は以前に文献をイタリック体で引用して、指導教授にオコられました(^_^;)。
＃でもHTMLで<CITE>...</CITE>とすると、大体イタリック体になるんですよね…。
>それ専用のタグがあったりすると便利なのですがねえ。うーむ。
確かに私も、 例えば <LEGALCITE> とかいうタグがあって、これを使えばルー
ル通りの形式になってくれたりすると便利かもしれないなぁ、とか思うことが
あるのですが、そもそも書体で論理構造を表そう、という発想がもはや時代遅
れではないかと常々思っています。今やplain textの形で数多くの論文がネッ
トワーク上で公開されてたりしますが、plain textでどうやって書体を表現し
ろというんでしょう。SGMLとかHTMLのようなマークアップ言語では、論理構造
は論理構造としてそのまま書き込むべきなんじゃないかと思います。
Cougarあたりまで視野に入れてこのあたりの解決策を考えてみると、 CLASS属
性で分類するのが妥当ではないかなぁ、と思います。例えば
<CITE CLASS="jurisprudence">...</CITE>
<CITE CLASS="biology">...</CITE>
とか何とかクラス分けして、スタイルシートで CITE.jurisprudence と
CITE.biology にはそれぞれの引用ルールに従った書式指定、例えば
CITE.jurisprudence { font-style: small-caps }
CITE.biology { font-style: italic }
とか何とかしておけば、結構幸せになれそうな気がします。まあ、実際には
<CITE CLASS="jurisprudence.book">...</CITE>
<CITE CLASS="jurisprudence.article">...</CITE>
<CITE CLASS="jurisprudence.case">...</CITE>
とか、もっと細かく分けて、さらにゴチャゴチャ指定せにゃならんでしょうけ
ど。それでも、ワケのわからん書体指定を本文中にゴチャゴチャ書き込むより
マシな気はします。
＃そのうち学会ごとにスタイルシートを定義したりするかもしれません:-)
＃＃でもその前に、 400字詰原稿用紙に縦書き、ってのはいい加減何とかして
＃＃くれ、とゆー話もあります…(-_-;)。
>>最近雑誌等を読んでいると、「頼むからHTMLの記事を書く前にRFC 1866くらい
>>読んでくれ」と言いたくなるような記事が多くてアタマ抱えてます…。
>
>このあたりは同感だったりするのです。はい。
何かオススメの解説書はありませんかね…。最近初心者な方に「全然知らない
んですけど、 手始めに何か良い解説書はありませんか?」とか聞かれたりする
のですが、間違いがあることがわかっている本は、自力でウソとホントが見分
けられるレベルの人以外には勧めにくいです。新版が出た『新・HTML & CGI入
門』とか、『インターネット ホームページデザイン エクステンション』あた
りも、いまだにNOFRAME病に罹ってたりしますし。
＃ある程度わかっている人向けには、どちらも悪くないと思いますけど。特に
＃『インターネット ホームページデザイン エクステンション』の方は、ざっ
＃と眺めただけでも、 各種のdraftに目を通した上で書いてあるのがはっきり
＃わかります。DOCTYPE宣言の解説があるのもポイント高いですね(^_^;)。
実際、『最新HTMLタグ辞典』とかを片手に <LI TYPE=DISK> とか書いて、「す
いません、黒丸にならないんですけど…」なんて相談を受けたことがあるので、
その度に「正しくは"DISC"です、この本の記述は間違ってます」とか言わなき
ゃならないのはお互い不幸な状況です。今月の「DOS/V POWER REPORT」の付録
小冊子とか、『HTML & CGI入門』でも"DISK"になってましたし…『新・HTML &
CGI入門』では直ってましたけど。 しょうがないので最近は、相手がHTMLの初
心者ではあっても英語の初心者ではないのなら、まずはRFC 1866あたりを読む
よう勧めてたりします。
うーむ…「間違った記述がない」という意味で、初心者にもオススメの解説書
って、何かありますか?
Yoshihisa Nakagawa 中川好久
中川＠ＮＥＣです。
さらっと読んだだけだったので、まだ私の読み方が甘かったようですね。
In article <E1wBu...@vega.aichi-u.ac.jp> mim...@vega.aichi-u.ac.jp (Masayasu Ishikawa) writes:
| ＃authorは、T. Berners-Lee氏と共にRFC 1866を書いた、D. Connolly氏です。
| 要するに、JIS X 0208だろうがGB 2312だろうがKS C 5601だろうが、文字集合
| としてはISO-10646のsubsetと考えられるので、それで事足りる限りは、
| encodingとしてISO-2022-JPやISO-2022-CNやISO-2022-KRを使っても差し支え
| ない、 ただし、encodingの如何に関らず、numeric character reference (例
| えば ঀ) は、 正しくISO-10646のコードポイントを指していると解釈さ
| れねばならない、 ということのようです。というわけで、このDOCTYPEを宣言
| したからといって、 必ずしもUnicodeを使わねばならない訳ではないので、ご
| 安心を:-)。
うーん、ISO-2022-JP って ISO-10646 の subset じゃないと思う
んですけど…。私には似て非なるもの、同じ（ような）ものに対し
て全く別々に独立してコードを割り当てたもの、としか思えないん
ですが…。
＃subset なのなら、unify するなよー。
なんかこれ書いた人たちって、とっても勘違いをしているんではな
いでしょうか。
まぁ、ISO-2022-JP が完全否定されたわけではないので、最悪の事
態は避けられそうですが、これに従うということは browser を作
る側としては積極的に ISO-10646 をサポートしなければならない
ことであり、ISO-10646 を使用することは間違いであると思ってい
る私にとっては、あまりうれしくないことにはかわりありません。
＃L10N+ ももう潮時かぁー。ISO-10646 のサポートなんて、金もら
＃わなきゃとてもじゃないけどやる気にならんし。趣味のために信
＃念を曲げる気にはなれん。