Strict-HTML スレッド19

Strict な HTML について語るスレッド ver.19
W3C 信者もそうじゃない人も投稿歓迎。 でもHTMLの基礎知識は欲しいね。
sage進行推奨。

* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
* XHTML 1.1, XHTML 2.0, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。

Strict-HTML スレッド18
http://pc5.2ch.net/test/read.cgi/hp/1076693129/

過去ログ・関連スレ >>2
勧告等・その他 >>3

■過去ログ
HTML1.0 http://pc.2ch.net/hp/kako/992/992708594.html
HTML2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
HTML3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
HTML3.2 http://pc.2ch.net/hp/kako/1018/10187/1018719800.html
HTML4.0 http://pc3.2ch.net/hp/kako/1022/10227/1022751972.html
HTML4.01 http://pc3.2ch.net/hp/kako/1028/10289/1028963710.html
XHTML1.0 http://pc3.2ch.net/hp/kako/1033/10332/1033282702.html
XHTML1.0 SE http://pc3.2ch.net/hp/kako/1037/10375/1037577389.html
Strict-HTML スレッド ver.9 http://pc2.2ch.net/hp/kako/1039/10399/1039974316.html
Strict-HTML スレッド 10 http://pc5.2ch.net/hp/kako/1045/10454/1045493217.html
Strict-HTML スレッド11 http://pc5.2ch.net/hp/kako/1048/10485/1048570237.html
Strict-HTML スレッド12 http://pc5.2ch.net/hp/kako/1048/10488/1048867117.html
Strict-HTML スレッド13 http://pc5.2ch.net/hp/kako/1050/10505/1050581113.html
Strict-HTML スレッド14 http://pc5.2ch.net/hp/kako/1055/10551/1055148679.html
Strict-HTML スレッド15 http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html
Strict-HTML スレッド16 http://pc5.2ch.net/hp/kako/1064/10640/1064061327.html
Strict-HTML スレッド17 http://pc2.2ch.net/test/read.cgi/hp/1068907834/ (pc2サーバが消えたせいで消滅？)
Strict-HTML スレッド18 http://pc5.2ch.net/test/read.cgi/hp/1076693129/

■関連スレ
/* CSS･スタイルシート質問スレッド【31】 */ http://pc5.2ch.net/test/read.cgi/hp/1085400294/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html
W3C信者にサイトを正しい記述に直して貰うスレ3 http://pc5.2ch.net/test/read.cgi/hp/1061741473/

■勧告等
HTML 4.01 ttp://www.w3.org/TR/html401/
XHTML 1.0 ttp://www.w3.org/TR/xhtml1/
XHTML Basic ttp://www.w3.org/TR/xhtml-basic/
XHTML 1.1 ttp://www.w3.org/TR/xhtml11/
XHTML 2.0 W3C (Working Draft) ttp://www.w3.org/TR/2003/WD-xhtml2-20030506/
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/

■その他
W3C ttp://www.w3.org/
HTML Working Group Roadmap ttp://www.w3.org/MarkUp/xhtml-roadmap/
Another HTML-lint ttp://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service ttp://validator.w3.org/
ごく簡単なHTMLの説明 ttp://kanzaki.com/docs/htminfo.html

おｔ

ゴミスレわざわざ保守すたのもおまえ?

>>1
(　・∀・)つ <em>旦</em> ｵﾁｬﾄﾞｿﾞー
em{ temperture: suited;}

おれおれ

スレッド17はどこ逝っちゃったんだろうね

お疲れ

>>1
乙。

>>1
偉いよー

>995 ：Name_Not_Found ：04/06/01 17:24 ID:???
>>>976
>＞やはり理想的には構造に従ってhtmlを作って、そこから楽しむ暇も無いぐらい
>＞簡単に思ったとおりのレイアウトができることで、複雑なパズルを解かなければならず、
>＞それでも理想の100%を表現できない状況は楽しむべきことではなく悲しむか、怒るかなどの否定すべきことだと思います。
>HTMLを表示するのはケータイから見るかも知れないし、パソコンかも知れないし、そのパソコンが白黒かも、固定ピッチフォントかも知れない。
>
>だから、そもそもからして「理想の100%を表現できない」のはHTMLの特性上当たり前なのであって、
>そこでイライラする事自体がまちがっているのでは？
>
>そういう用途なら無理矢理HTML+CSSだのテーブルレイアウトだのと「最終的にはユーザースタイルシートで
>全部無効化可能な仕様」なんかに頼らずにPDFを使えばよろしいかと。

何も1つのスタイルですべてのデバイスで表示使用なんて考えてませんよ。
さまざまな解像度でさまざまなデバイスでそれぞれ適切なスタイルが用意できるのが理想では？
そのための仕組みはhtmlの中にあるんですから。

>>12はデザインしやすいCSSを望んでるのか、
デザインしやすいHTMLを望んでるのか。

多分前者だろうから、ここからはCSSスレの話題な気もするが、
「HTML使うならデザインを意識するな」というHTML側からの意見もあるからややこしいな。

（div,span,class,idを多用しなくても）思い通りにデザインできる
驚愕スタイルシートが策定されればそれにこしたことはないけど、
論理構造から出発してる以上は限界があるだろうし、
仮にできてもどこまで実装するのかって問題もある。
右の方にお花を三つレンダリングするプロパティとか作られても困るし。

だから、えーと、あれ？俺は何が言いたいんだっけ。

＞現状ではブラウザ上で表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。
　↓
＞今のCSSの実装でできなくてtableでできることいいますと、CSS3にあるような画像を使ったボーダーとかが思いつきます。div厨になればできそうですけど。

なんか主張がスケールダウンしてない？
画像を使ったボーダーが無理＝テーブルレイアウトの方が優れている
というのはさすがに無茶苦茶かと。

つーかさ、

>現状ではブラウザ上で表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。

ブラウザって言っちゃうからわけわかんなくなるんじゃないの？

>InternetExplorerで表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。

>NetscapeNavigatorで表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。

>Lynxで表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。

>京ぽんで表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。

>Googleで検索した場合Strict-HTMLの検索結果はtableレイアウトのHTMLのものと比べて良くない。

>>15
そういう問題かな？

>>14の引用文の前者は暗に「実装状況が良くない」と言っていて、
後者は具体例として「画像をボーダーにできない」と言ってるんだよな。

CSSで出来ないことを一つ取り上げてテーブルマンセーってのはどうか、って思うわけだ。

>>12
HTML+CSSでは、未来に新しく現れる環境でも適合させるために
デバイスを限定していない。

＞何も1つのスタイルですべてのデバイスで表示使用なんて考えてませんよ。
だから、ここからすでにHTML的な思考をしてない。
デバイスは無制限、つまり、無限にあるし、全てのデバイスを想定する事が
そもそも不可能な事を前提にして仕様が作られている。

正直レイアウトに拘るならpdfだと思うぞ。煽りじゃなくて心底マジレスで。

Strict の仕様は過去の HTML と異なる設計思想で作られているので、
俺はたとえば table レイアウトにできて Strict にできないことがあったとしても
特に驚きを感じないし、そのことが不利だとも思わない。
そもそも目指すところが違うのだから、「これと同じことができないから CSS はダメ」ってのはちょっと違うと思うぞ。

とりあえず両方できるようになっておくのがいい。

>>前スレ974
Strict-HTMLは一人だけが使っても効果は少ない。
理想としては全ての文章がStrict-HTML、もしくはそれ以上もので記述されていればいろいろと便利なことができるようになる。
そのためにはStrcit-HTMLが既存のHTMLと比べてあらゆる点で勝っていなければらない。
たとえ些細な1点であってもtableレイアウトや不思議マークアップの文章と比べて劣っている点があってはならない。

確にHTMLの主目的は文章を構造化してデータベースとして記述することであり、それを人間の目に見える形で表示することは利用法の1つでしかない。
しかし、それも立派な１つの利用法であり、決して軽視してはならない。
それに対する答として、W3Cはスタイルシートの概念を採用し、また、XHTMLによって必要な情報を安全にHTMLに付加できるようにした。
これはHTML側としてはおそらく最適な解である。

しかし、現状では周辺の仕様・実装の未熟さにより、特定の見栄えや特定の書き方によってはStrict-HTMLはtableレイアウトや不思議マークアップに劣る点もある。
そのような見栄えや書き方の方を非難することは時には必要であろう。
しかし本当に必要なのはそのような要求にも、少なくともtableレイアウトや不思議マークアップよりは、良く答えられる仕様・実装である。

残念がら見栄えを良くしたい、簡単に便利にHTMLを書きたい/移行したいという要求に対して我々はすぐに答えることができない。
しかしそれに答えられるようになるまで、我々は見栄えも重要であるがもっと重要なのは構造化であることを広めていかなければならない。

#もちろんこれらが1年や2年で実現することはないだろう。もしかすれば永遠に実現しないかもしれない。
#しかしこのスレの住民であればどこか志としてこのような考えを持っているべきである。

#>>19の「とりあえず両方できるように」というのはよくこの考えをまとめている。

>>前スレ994
>やはり理想的には構造に従ってhtmlを作って、そこから楽しむ暇も無いぐらい簡単に思ったとおりのレイアウトができることで、
いや、先に構造を作るというのは推奨すべき良い方法であるが、そうでない書き方も許容すべきだ。もちろん結果はStrict-HTML+適当なスタイルシートになるように。
書く順番を規定するのは良くない。

>>14
2つ目の引用は前スレ988氏のものであるが画像を使ったボーダーに限らずtableレイアウトを利用して美しい、ただし特定の環境のみな上にユーザビリティは悪い、ページというのは多くある。
もちろんStrcit-HTML+CSSの方が美しいページはあるが、たとえ些細な1点であってもtableレイアウトや不思議マークアップの文章と比べて劣っている点があってはならない。

>>17
それはCSSの思想であり、HTMLの思想ではない。
HTMLでは複数のスタイルをデバイスによって使い分けることを可能としているし、スタイルシートに対しては何も規定していない。
多くのデバイスをそれなりにカバーするスタイルシートも存在し得るし、ある特定のデバイスに特化した最高品質のスタイルシートも存在し得る。
実際現在でもCSSは画面を中心に音声、印刷に対してUAに負荷をかけずにそれなりの品質を得るような仕様だし、
XSLはどちらかというと印刷の方に力を入れてCSSよりは良い品質を得るような仕様となっている。
そして将来pdfのレンダリングモデルを使ったものや、既存のtableレイアウトのHTMLを利用した移行しやすいイルシートが出てくるかもしれない。
実際XSLTやプログラマブルなスタイルシートを使ってPDFの出力を得るようなことも将来十分考え得る。
そのようなプログラマブルなスタイルシートであれば「右の方にお花を三つレンダリング」することも可能だろう。
#そういった意味ではJavaScriptスタイルシートはアイデアは良かった……。

誰か上の長文読んだ人がいたら、10文字以内でまとめて

読んでくれて有り難う (10文字)

>>21
正直３回読んでみて意味がわからない。根本的にHTML+CSSによるレイアウトを
理解出来ていないとしか思えない。

＞HTMLでは複数のスタイルをデバイスによって使い分けることを可能としているし
まずこの段階で意味がわからん。HTML-FOとかTransitionalの話題？

Strict な HTMLは見栄えに関して規定がない。だから、使い分けなんて有り得ない。

HTMLは出力するデバイスごとに「デバイス側の出力設定」で出力が可能な訳で、
そのデバイスがＣＳＳに対応している場合、今度は「ＣＳＳの設定」でデバイスが
出力してくれますよ、と言うだけの話。

だからそもそもＨＴＭＬ＋ＣＳＳで見栄えをどうこう、と言う発想そのものが間違い。
レイアウトに拘るならpdf。どうしてもＨＴＭＬによるレイアウトに拘るなら
特定のＵＡの出力にターゲットを絞る事になるが、前者、後者ともにスレ違い。

>>24
link要素やxml-stylesheet命令にmedia属性があるって意味だと思います。
http://www.w3.org/TR/html401/present/styles.html#h-14.1
Media dependencies
(中略)
Style sheets, by contrast, apply to specific media or media groups. A style sheet intended for screen use may be applicable when printing, but is of little use for speech-based browsers.
This specification allows you to define the broad categories of media a given style sheet is applicable to. This allows user agents to avoid retrieving inappropriate style sheets.
Style sheet languages may include features for describing media dependencies within the same style sheet.
Alternate styles
Authors may wish to offer readers several ways to view a document. For instance, a style sheet for rendering compact documents with small fonts, or one that specifies larger fonts for increased legibility.
This specification allows authors to specify a preferred style sheet as well as alternates that target specific users or media.
User agents should give users the opportunity to select from among alternate style sheets or to switch off style sheets altogether.

>>17 >>24
全ての人、環境に思った通りの見栄えを強制したいわけではありません。
ただ、望む人には最高の見栄えを提供したいのです。
そして望む人には簡素な見栄えを。
そして全ての人に便利な構造を。
なのでpdfは×。

音声ブラウザやテキストブラウザ、非人間UAのことを考えるのは重要です。それは最低限必要な当り前のことです。
でもそのために視覚ブラウザユーザーが不利益を得るのは(優先度は低いとはいえ)良い事ではないと思います。

>>21
>いや、先に構造を作るというのは推奨すべき良い方法であるが、そうでない書き方も許容すべきだ。
HTMLは文章ありきのなので構造は先に作らないといけないのでは。

どういたしまして

結論：見栄えはスレ違い

こんなん見つけた。

:after、:before セレクタと content でブロック発生させてブロック要素に
影っぽいエフェクトかけたりする程度ならHTML-CSS2でも可能な模様。
ttp://www.netlaputa.ne.jp/~robaq/frozenDocument/box-shadow.html

独自仕様なしで角を丸くできたらtableイラネ、となりそう。

あにょ、もし？

>>24
http://www.faireal.net/articles/7/21/#d30617
「PDFファイルはプラットフォームに依存しない」 ‌というのは嘘である、 ‌ということを繰り返し強調しておく。
‌「ASCII文字と画像だけ」 ‌でない限り、 ‌ユーザはPDFファイルを作成・配布すべきでない。
‌ 「ASCII文字と画像だけ」 ‌なら通常、 ‌HTMLで充分だ。

>>30
そんなしょぼいサイトを引き合いに出して何を熱くなってんのさ？
そいつはそうこじつけたいだけだろ。

>>31
そういうことがあると示しただけですが。

>>28
それ使って、before擬似要素・position:relative;で擬似text-shadowしてみようかな
と思ったけどムリだった・・

なんでこの流れでSVGが出てこないんだろう……(;_;。

HTMLじゃないから。（でもpdfはでてきてるな）

>>21
> Strict-HTML+適当なスタイルシートになるように。
> 書く順番を規定するのは良くない。
それはオーサリングツールが著者へのユーザビリティとして考えることだ。
HTMLの仕様は人間に対するソースの可読性を考慮しているとは思うが
人間がちまちまエディタで書くことを最優先に考えてはいないだろう。

先に特定デバイス向けの見栄えを作れるというUIがあってもいいと俺は思うが
著者に構造の存在を強く意識させなければ
「どこでも配置モード」の失敗を繰り返すことになるだろう。

>>36
どこでも配置モードの失敗は絶対値なのか相対値なのかを区別できなかったツールばかりだったのが大きいと思う。
それを区別した上で、プレビューウインドウがうねうねサイズやフォントが変わるようにできてればいやでも意識せざるを得ないからだいぶましなものになったかもね。
その上でウイザードみたいなものが立ち上がって「見出しはどこですか？」とか「ここの部分はどういう意図ですか？」といった風にやっていけばそこそこのものができそう。
実際あったらうっとうしそうだけど。

まあそれはそれとして置いておいて、個人的には後から構造化するより書きながら構造化するほうが楽だな。グラフィカルなツールでも直打ちでも。
後からだとどういう意図だったかもう一度思い出さなきゃなんないし構造化し忘れがあったりするし。
でも新聞を作るような人だと結構レイアウトありきだったりするんだろうか。新聞がStrict-HTMLで書かれてたりするとそのままWeb配信できてアレゲなんだけど。

#スレ違いのようなそうでないような、少なくともネタが無いよりはたまにはこういう話も面白い。

>>34
Strict-HTMLをXSLTでSVGに変換とか強そう。
むしろネームスペースを使って混在か。

おれにしてみれば、HTMLは文字"データ"なので、見栄えを意識する、
と言う感覚自体がよくわからん。

DBに名前を登録するとき、見栄えを考えて「木　村　　太　郎」みたいに
文字間にスペースを入れたりは決してしない、そんな事考えもしない、そんな感じ。

>>39
漏れ達の「ふつう」ではそんなこと思いつきもしないけど、
漏れのクラにはそういうおっさんが腐るほどいる、

という現実！（バキ風に。）

いや、実際総務のおっさんに「はがきに印刷したときの事を考えて」
何遍言ってもACCESSに上記のような登録をする人がいて、
仕方がないから登録時にはtrimかけといて、印刷するときは均等割付
して対応してるんだけど、時々テーブル直接開いて編集した上に
印刷がおかしくなったって怒るんだよね。

HTMLとは全く関係ないただの愚痴だけど…。

名刺も謎マークアップの時代ですか。

>>37
新聞みたいなものはレイアウトのメソッドが固まっているので、
むしろレイアウト言語を分離しやすいんではないかと。
しかし Web の場合はニュースごとにページを分割するのが普通なので、
ちょっと例として適切なのかわからん。

>>41
そういうおっさんでも、紙でマス目に
「氏名は左詰で書いてください。姓と名の間は一マス開けてください」等と
記入例つきで書かせると大抵ちゃんと書けるんだよね。

いっそのこと、見栄え制御用のスタイルコンテナ名前空間を作って、
そこに従来のdivとspanとtable相当の要素つくればいいんじゃない？

XHTMLの名前空間と属する要素を一切汚さずにdiv、span房+tableレイアウトが
可能になる（tableレイアウトの見栄え保障はSVGと同レベルで行う）。

XSLでXHTMLの名前空間の要素だけ抜き出せば簡単にクリーンなXHTML文書も
作れるし。

>>39
そんなことはこのスレのだれも考えてないよ。
考えてるのは印刷フォームの方。
より正確にはDBと印刷フォームをつなぐ部分。

>>46
>>39 は見栄えのためにデータの間にスペース入れるのと、
見栄えのためにデータの間にtableタグをいれるのとは一緒だから、
そもそも「印刷フォームに繋ぐ部分のCSS」と「データ部分HTMLのtable」を
同列に扱うのがおかしい、っつってるんかないのか。

って意味だと「比較している奴が居る段階」でそんな事を考えてる奴が
このスレには居る事にならんか。

関係ないけどみんな何歳？俺は22歳。
ここにいる人で集まって一個のサイト趣味的に作ったら面白いよね。

別に会わなくてもどっかのレンサバ借りて、みんなにIDとパスを渡して5人位かな。
そんでみんなで一つのサイトをいじっていく。って無理か。

それをいじりながらStrictな話をしていっても面白いかなと。
http://ドメイン/strict/
っていうのと
http://ドメイン/table/
ていうディレクトリにわけたりして

青臭いことを・・・

というか気持ち悪い。

やっぱStrictは年齢層高いの？

年齢どうこうじゃなくて群れたがるのがガキっぽいな

蒸れたい。

基準にする平均的年齢層を述べよ。

>>48
ぼくちゃんと一緒にみんなでやろーよ

と言うスレはこの板にいくつもあるから全部読んで好きなところでやれ

>>49-55
そっか。ごめんよ。

前スレで「一旦原稿用紙に書かせたものをマークアップする」
http://pc5.2ch.net/test/read.cgi/hp/1076693129/832-836
というのが出てたけど、そういうものを実践してみるとか、
まとめサイト的なものがあっても良いかも知れない。

>>48が草案作って、それが良かったら協力者も現れるはず。

plain text→HTML なら http://www.asahi-net.or.jp/~sd5a-ucd/www/ で少しやってる

うん。ｶﾞｲｼｭﾂ感ありまくり。

>>57
マークアップする人ごとに癖が出そうだな。

こうこうこういうときにStrictとしてはどうするべきか。
ってのがよく質問されるからFAQまとめてもいいと思うけどな。
Wikiでやってみる？

>>61
Wikiに関する知識は無いので意味わかんないこと言っていたらｽﾏｿが、
StrictなHTMLをWikiでも実現できる？
（Strict-HTMLスレのまとめサイトがinvalidだったら死ぬしかない）

このスレで議論されているのは｢WEBサイト｣ではなく｢HTML｣だと考えたほうが良いのでしょうか。
過去ログ読めば読むほどトヨタや日産のようなサイトはどのようにマークアップすれば良いか混乱してしまいます。
あのようなサイトでDTDを4.01strictで記述しているところがあれば紹介してもらえないでしょうか。

>>62
うちのWikiは1.1でStrictですが、デフォはテーブルレイアウトなんでちと骨が折れるよ。
もしやるなら〜のかけらって方もいい鴨ね。

HTMLが構造のみを定義っていうけど<Hn>は構造＋見栄えになってるよね。なんで<Hn>は
只の見だしっていう意味なのになんでUAは勝手に物理ともとれる仕様にしたのかな。

実は<Hn>が使われない理由はそれもあるんだと思う。俺は勝手に文字の大きさをかえられたり
マージンが他と違う設定になってるのが嫌。

それをわざわざCSSでっていうのがいや。気持ち面倒。実際はもっと面倒なことを面倒がらずにやってるから
1行で済む<hn>のCSSは：＠あおｊが￥おｊがお

もういい！

>>65
>構造＋見栄えになってるよね
なってない。
>UAは勝手に物理ともとれる仕様にしたのかな
デフォルト表示で構造が読み手に見て取れるようにしたかったのでは？
＞俺は勝手に文字の大きさをかえられたりマージンが他と違う設定になってるのが嫌
Lynx使え。文字の大きさもマージンもへったくれもないから。

と、釣られてみる。

原稿用紙→マークアップを言い出した者だけど、
要するに原稿用紙なら空白による均等割付もどきとか見出しに「☆☆☆〜〜☆☆☆」とか、
装飾のためにテキストのほうをいじる人が減るんじゃないかと思ったわけです。
それで「やりたいならスタイルシートでやろう」と言えば理解してもらえるんじゃないかと。

普通のテキストエディタに書かせたら段落とか考えないで句読点ごとに改行して、
まぁ改行すること自体は良いのだけど、それでどこが段落がさっぱり分からなくなって、
見出しとかもまぜまぜで、我々でもマークアップしようがなかったり。

原稿用紙なら初めから「タイトルは最初の行に2〜3字下げて」とか「段落は改行して1字下げて」とかやってくれるから、
「見出しとは何か」「段落とは何か」ということを考えさせる必要がない。
そういうのを無視して書いたら「原稿用紙にそういうふうには書かないでしょ」と言えば分かってくれる。

教科書どおりに原稿用紙に書いて後から飾りをいじるっていうののほうが生産性が高いというか楽なのは
一度やってみさせれば痛感してくれるはず。

補足しておくと、普通の人に「見出し」というのを理解してもらうのが意外と大変なのです。
昔教えたときに>>58のを教材にしたことがあるんだけど、
口には出さなくても
「何で見出しとかにするんだ？　別にスタイル変えようとは思ってないんだけど」
って思ってるのがよく分かった。
説明してもそのメリットはいまいち理解してもらえない。
その人はあんまり賢くなかったし、自分の説明がいまいちだったのもこの文章を読んでもらえれば見当がつくと思うけど、
それを差し引いても感触はやっぱり悪かった。
意味がよくわからないことをやるのは抵抗がある。

それに対して原稿用紙に書けば「何で原稿用紙に書くの？」っていう疑問は出てくるけど、
そこはHTMLと全然関係がないから分からないままでも良い。
原稿用紙に文章を書くのは知ってることだから拒絶反応はまずないし、
しかるべき場所にもって行けばそれが本に変身することを考えればスタイルシートの概念も理解しやすそう。

そうやって実際に完成させてみてから「どうして見出しや段落を区別するのか」を説明すれば
いきなりマークアップさせるのに比べてはるかに分かりやすくなるんじゃないかと思ったわけです。


長文すまそ。

>>66
>＞俺は勝手に文字の大きさをかえられたりマージンが他と違う設定になってるのが嫌
>Lynx使え。文字の大きさもマージンもへったくれもないから。
製作するときに嫌なのさ。

制作するときに文字の大きさなんか関係ないんじゃ

それこそツールの問題だよなぁ。

だから見栄えを意識するユーザを対象としたstrictの話なら兎に角、
strictで見栄えをどうこうするという話題はスレ違いなんだって。

>>67-68
製本過程とオーバーラップさせるのは面白いかも。
HTMLは原稿（＝データ）である、と。

あとは、スタイルをあらかじめ何種類か用意しておいて、
原稿がいろいろな形で表現されるということを示すと良い
かな。

原稿用紙に書いた作文は、文集として製本されることも
あれば、読み上げて発表することもある。いろいろな用途
に利用される元データがHTMLだよ、という感じで。

>>67
見出しから目次を自動生成するツールとか見せてあげると結構理解してくれるのでは。
Wikiではそういう機能を持ったものが多いのですが「こういう風に書いておくと勝手に目次作ってるれるよ」と説明すると結構簡単に理解してくれます。
HTMLの他の要素でも実際に有効利用するデモを見せるのが初心者には手っ取り早いかと。

>>62
VikiWikiというのを使っていますがデフォルトでもそこそこのソースを吐いてくれますし、他のWikiでは難しいブロック要素のネストも書けます。
さらにその記法自体を比較的簡単なソースの変更で変えられるのでおもしろいかと。
ただ、問題はrubyで書かれているので環境が限られることですね。
PerlならFreeStyleWikiでしょうか。

>>64,74
なるほど。安心しました。
Strict Wikiについての丁寧な説明ｻﾝｸｽ。

初心者にStrictHTMLがどれほど素晴らしいかを見せるのはいいことだと思うが、
あまり視覚的なことに比重がかかりすぎないようにしたほうがいいかもしれないね。
変に「自分解釈」を加えて勝手に不思議マークアップを始めてしまうのが初心者だから、
あくまでも構造を保つ（構築する）ことこそが重要だと伝えらければならないと思う。
そうしないと、結局>>65のような意味不明な解釈をしてくるﾔｼが生まれてしまう。

スルーでつか？

>>76
見出しはhn、リストの所はli要素でマークアップ……などなど、別に変わったことはない。
「あのような」と言われても、典型的なテーブルレイアウトをしていますね、としか答えられない。

車種紹介欄は<div id="advertisement">にでもしとけば、くらいかな。

>>76
スルー以前に自分の書き込んでるスレのタイトル読めないのか？

>>63
> 過去ログ読めば読むほどトヨタや日産のようなサイトはどのようにマークアップすれば良いか混乱してしまいます。
知りたいのはむしろ「どのようにCSSを指定するか」じゃないの？

>>63
どうでもいいけどDJしてる人？
トヨタと言えば知り合いだったりして

>>63
カスイケで見かけた大手企業
むろんstrictではないが、それっぽい。

http://konicaminolta.jp/
http://saiyo.jr-central.co.jp/
http://www.siemens-mobile.com/
http://www.taiyakan.co.jp/

XHTMLでUTF-8以外を使うときはXMLバージョン宣言を入れろと言うことですが
その宣言を入れたが為にIEでStrictモードが動作せずmarginなどの指定が
崩れてしまいます。事情によりShift_JISを使いたいので
宣言をはずして且つShft_JISで作ってますが、うまい解決方法があったら教えてください。

どうせ過去の遺産を引きずってるとかそんなところだと思うので事情のほうを何とかしろ。
UTF-8/16で書け

SSIとかPHPでIEだけにはxml宣言を吐かないとか。

それってスレ的にはダメじゃないの

>>62
主旨同意なのだが、その手のプロジェクトは「走りながら修正する」のがよいと思う。
「Strict をどうやって教えようか」ということについて案を持ち寄ることが最優先だし、
それ以前の段階で足踏みすると書き手の意欲が鈍るからね。
というか、Wiki で最終形とせずに、静的ドキュメントをまとめる作業だけ Wiki でやれば委員出羽？


ところで XREA なら Ruby が使えるわけだが。
誰も出さないなら俺のアカウントを提供してもいいぞ。
実は似たようなことをやりたいと以前から思っていたので、渡りに船なのだ。

>83
82ではないが、私の場合は携帯で来る人もけっこう多いからやっぱshift_jisだな
標準／互換モードの違いはCSSいじれば何とでもなるし。
あとはIEが何とかしてくれるのを待つのみ。

そういえばFOMAってUTF-8扱えるんだっけ…？

>>82
HTTPヘッダがコードを明言していれば、Shift-JISでもxml宣言書かなくて
大丈夫よ。

>>82
> Such a declaration is required when the character encoding
> of the document is other than the default UTF-8 or UTF-16
> and no encoding was determined by a higher-level protocol.

文書の文字コードが UTF-8 でも UTF-16 でもなく、かつ上位
プロトコルで文字コードが指定されてもいないという場合は、
XML宣言は必須です。

つまり、文書が Shift_JIS などで書かれてあっても、上位プロトコル
(HTTPのヘッダなど)で charset=Shift_JIS と指定されているのなら、
XML宣言は、強い推奨ではありますが必須ではありません。
この部分の仕様は Second Edition で緩和されました。

なお、この場合の charset は <meta> 要素ではなく、HTTP の
ヘッダで指定されている必要があります。

>>86
面白そうなんだけど自分は参加できないんだよなぁ…

話題が無限ループするスレだから話をまとめるのは良いと思うよ。

>>92
げ、それじゃこのスレが続かなくなっちゃうじゃん。

>>91
差し支えなくば、理由をお聞かせ願えまいか。

文字コードのレスありがとうございます。
「根本的な解決はIEが変わらない限り無理だが、そこまで気にすることもない」という事にします。
スタイルシートで対応するにはスペーサー的な指定をすると言うことでしょうか
IEは内側の要素が外側より大きいと勝手に広げちゃいますしね。
>>83　cgiの日本語変換ライブラリjcode.plがutf-8に対応していないので・・私には作れないし。

>>94
jcode.pm の方を使おうよ‥

Jcode.pmの方が良くないか?

>>96
大変申し訳ない。

もしかしたら「○○」のほうがいいよというレスが来るのを期待してたのだが
本当に返ってきたので早速取り入れてみようと思います。(≧▽≦)ｳﾋｮｰ。
もうShift_JISで動いちゃってるんですけどね。自分、その不器用ですから。

不器用≠不勉強

PerlでUTF-8ってことで ぐぐれば3秒レベルだと思うのだが。
perl5.8ならEncodeってことも。

ていうかHTML 4.01じゃだめですか。そうですか。

>>100
valid なら全然OKですよ

>>101
strictでvalidなHTML4.01なら、もし100％XMLの時代が来ても、
機械的にXHTML1.0に変換出来る。（つーかその為のXHTML1.0だ）
そしていったんXMLベースに成っちゃえば、後はXSLTで他のXML文書に
変換出来るから最終的に手間はかかるが問題ない。

そういう意味では、validでさえあればHTML2でも3.2でも他のSGMLでもそれなりにOK。

>>103
> そういう意味では、validでさえあればHTML2でも3.2でも他のSGMLでもそれなりにOK。

間違っちゃいないけど
今2や3.2を使う必然性があるかどうかは疑問だね。

HTML4.01Strictは別に必要条件ではない、という意味なので。
HTML2/3.2を含めて、その必然性は結局状況次第でしょ。
必要な場合も不要な場合もあるだろうさ。傍から疑問に思うのは勝手だが。

>>104 は、「それとは別に」今2や3.2はレガシィだ、と展開すべきだったのでは?
HTMLそのものもレガシィだけど、4.01は十分現役な訳で。

というよりHTML2は破棄されたんじゃなかったっけ。

破棄というかobsolete

Shift_JISのJISって何の略ですか？
acronymのタイトル指定が出来なくて困ってます。

>>109
ttp://e-words.jp/w/JIS.html
違うかな？

Japanese Industrial Sex

>109
acronym より abbr

<meta <abbr title="HyperText Transfer Protocol">http</abbr>-equiv="Content-Type"
content="text/<abbr title="HyperText Markup Language">html</abbr>;
charset=Shift_<abbr title="Japan Industrial Standard">JIS</abbr>">


<<abbr title="Abbreviation">abbr</abbr> title="Abbreviation">abbr</<abbr title="Abbreviation">abbr</abbr>>

>>113
笑った。やりすぎ

>>110-111
有難う御座いました。

>>112
シフトジスって発音するようなのでacronymで良いのでは無いでしょうか？

>>115
過去スレに何度か出てるけど、
acronymとabbrは使い分ける必要は無い、
abbrだけで十分って話に落ち着いてるみたいよ。

>>116
そうなんですか。知りませんでした。

>>117
参考までに
http://www.alib.jp/diary/diary_200111.html#diary20011129c

>>117
そこらへん非常に曖昧なのよ。
ただまぁ、当然ながらacronymで間違いではない、と言うか正しいから
acronymでも問題なしです。

ちなみに、最終的にどうなるかしらないけど、XHTML2.0はabbrに一本化
しようか、と言う話があるっぽい。

「Shift_JIS」というのは「Shift_JIS」という形で固定化された名称で、
「Shift Japanese Industrial Standard」の略じゃないから、
このJISをabbrとするとは不自然だと思うのだが。

>120
え、Shift_JIS そのものをってことだったのか。それなら > 113

>>120
>>109 を10回位音読してみれば？

>>122
おまえもな

>>123
必死だなｗ

>>122=124
「JISって何の略かなー。ああでもみんな知らないといけないから、"Shift_JIS の JIS" って言わなきゃ。」
「"Shift_JIS" をマークアップしたい。この中の "JIS" って何の略かな？」

前者で解釈したということですか？

仮にShift_JISというコードの名称であっても、JISの部分が
Japanese Industrial Standardの略である事には間違いない。

>>126
「スーパーファミコン」は完結した商標であって
「スーパーファミリーコンピュータ」の略ではない。

これと同じように考えても不自然はないのでは？
どっちにしろ細かい話だが。

もぉ細かい話はやめましょうよぉ

必死になるからね。

>>127
商標登録は「スーパーファミコン」であって、「スーパーファミリーコンピューター」の
略ではないが、スーパーファミコンの「ファミコン」の部分の語源は
「ファミリーコンピューター」には違いない訳だが。

つーか、商標と言葉の語源いう全く異なるものを同じレベルで語っても
意味ないと思うんだが。

もぉ細かい話はやめましょうよぉ

なんだよマリオ世代かよ。マリオが1-1でソッコー穴に落ちて流れる音楽を思い出したぞ。

みんな議論すきだなあ…
ろくに大学逝ってない証拠だよ
こりゃ

だって２ちゃんだし・・・

どっちでもいいよ、勝手に悩んで屁理屈こいてろってカンジー。
あまりに生産性がなさすぎる。

同意はするが、2chで生産性とか言ってもなぁ…

結局、Strict-HTMLまとめサイトって作るの？

>>137
仕様で十分じゃね？　自明な場合は勿論、見解の相違が有る場合でも
結局仕様のソース示して終りだし。

つかStrictスレで議論や細かい話を否定してどうするんだよ

具体的な例を書くと、細かい話は止めろと言われるのか。

>>130
語源かどうか、って語源すらもマーク付けできる要素だったのかー

とりあえずくだらない議論はここですればよいわね。
わざわざWikiとかで作らなくても。

>>141
マジレスすると、現在の言葉が語源を略した物であるなら、
abbrは略する前の語源をマーク付けできる要素だな。

くだらない論議はそれと解るように書け。初心者を惑わすような揚げ足取りはすんな。
単なる駄レスを超えて有害だから。

>>143
いやいや、揚げ足とかじゃないし。

造語は略語じゃねえだろ、って話だ。

下らない議論よりも根拠のない
＞abbrは略する前の語源をマーク付けできる要素だな。
こそ初心者を惑わすような有害だから。

それで、
Shift_JISをShift_<abbr title="Japan Industrial Standard">JIS</abbr>
とマークアップするのは適切なんですか？

>>144
＞abbrは略する前の語源をマーク付けできる要素だな。
いやいや、「略する前の語源」をマーク付けできるだろ。

造語だろうが、新語だろうが、現在の言葉が語源を略した物であるなら、
それは略語の一種。略語である以上、abbrは略する前の語源をマーク付けできる。

>>145
どっちでもいい。文脈に依存。

>>118
IE専用のブラクラ

>>148
むぅ。sleipnirで開いて強制終了したよ。Operaなら大丈夫だた。
なんでIEは落ちるんだろう？
IEはxhtml非対応なの？xhtmlじゃなくてhtml4.01使っているからその辺は分からん

どうやってるのか教えてよ。IE蹴りてえ…。ﾅﾝﾁｯﾃ

>>150
解析ぐらい自分でしろよ。

コレが原因かどうかは知らんが、176行目に
,/h3>
つー、typoがあるな。仮にコレで落ちてるならIE脆弱杉、と思うが。

>>146
>>127
127は断定しているわけじゃないことにも注意な

>>145
文脈次第ではいいんだろうけど、どんな文脈かはまったく思いつかない。
JIS の部分を略語として説明する必要があるなら、abbr なんかじゃなくて本文中でどうにか処理した方がよさげ。

まあ、abbrつけるときは文脈にも依存するんだが、
同じ略語が存在して区別が機械的に不可能な時って感じか。

IE forMac 5.2.3 では落ちないなあ。残念。

サイトのトップや掲示板の入り口に注意事項を書いているWebページは多いけど、Webの性質から言ってこれって無意味な上に危険じゃね？
自分の場合はルール破る前に気づいたからいいようなものの「ルールも読めない厨」の何割かはブックマークや直リンから生まれてそう。

#ユーザビリティスレと迷ったけどこっちに。

いや、こっちに来ないでくれ。

そうだな。リソース自体に書くべきだ。
もしくは、それ自体にそういう事柄をまとめたリソースへのリンクをつけるべきだ。

しかしルールも読めない厨はそもそもそんなことしても見ないのだ。
あいつらの視界に入らなければ終わりなのだ。慎重さがないからな。

>>157
どっちも違う

あえて行くなら｢こんな管理人は嫌だ｣スレかな

abbrの話をぶりかえして悪いんだけど。

<abbr title="小泉純一郎">純</abbr>ちゃん

こういう本名を略した愛称につかうのってあり？

いいよ。どちらにしろabbreviationだから。
でも、純ちゃん全体にやってもいいと思うよ。

>>163
ありがとう。今まで省略だろうが、省略じゃなかろうが、
spanとtitleで書いてたから、省略の奴に関しては書き換えるわ。

ちなみに、これはabbrにしたら、駄目？

<abbr title="小泉内閣総理大臣">小泉</abbr>
或いは
小泉<abbr title="内閣総理大臣" />

一応肩書きを略しているのだけれど、略した大量が丸ごと消えている、
と言うパターン。

×略した大量が
○略した対象が

orz

>>164
それはやっちゃ駄目ッスYO！！
もはや略語じゃないッス！！

やっぱり駄目すか。全部消えちゃったら略「語」じゃないしね。

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

<abbr title="小泉内閣総理大臣">小泉総理</abbr>

<abbr title="管と管と管">未納三兄弟</abbr>

>>169
こういうのって有りなの？　少なくとも略語ではないから
<span title="管と管と管">未納三兄弟</span>
にすべきなのでは？

>>170
本人が略語と判断したら略語なのかな？

<abbr title="超悪代・管・最悪政治・民主の恥・民主自体が恥・うんこ屑野郎（冗談ですｗ）">
管
</abbr>
こういうのは同思う？

遊んでるなー、と思う。

>>170
ttp://dictionary.goo.ne.jp/search.php?MT=%CE%AC%B8%EC&kind=jn
＞りゃくご 0 【略語】
＞ もとの語形の一部分を省略して簡略にした語。

と言うことだから、
＞本人が略語と判断したら略語なのかな？
ってことは無いと思う。

ただし、国語の問題として略語かどうかはおいといて、
WAIで「顔文字はabbrに」という話があるから、
「略語ではないがそれに準ずるもの」と言うことでabbrでマーク付けするのは
"有る程度" 許容されるとは思う。

ちなみに >>170 はもうabbrじゃなくてspanだとおもう。
省略じゃなくてただの駄洒落だし。

<var>1</var> ：<span class="name">Name_Not_Found</span> ：<span class="date">04/05/31 19:50</span> <dl><dt>ID:</dt><dd><var>???</var></dd></dl>

>>174
：は飾りなのでHTMLソースには書かないでください。

<var>1</var><span class="name">Name_Not_Found</span><span class="date">04/05/31 19:50</span><dl><dt class="ID">ID</dt><dd><var>???</var></dd></dl>

var:after { content:':'; }
span.name:after { content:':'; }
dt.ID { content:':'; }

こうか？

× dt.ID { content:':'; }
○ dt.ID:after { content:':'; }

『04/05/31』も『04-05-31』とか

>>178
『2004-05-31』

スラとかハイフンはアクセシビリチ的に、やさしくない罠。

音声ブラウザの進化を待つ。

なんでナンバリングが<var>なのをだれもつっこまないの？
プログラミングコードの一部で、関数とかクラスに値を渡してるのか？

>>180
年月日表示の国際標準規格か何かが>179の書式を採用していた気がする。

>>182
varはこの場合正しくないよね。
あとIDの定義型リストもよろしくないような。

<span class="host-id">???</span>
span.host-id:before { content: 'ID:'; }

この方が良いと思う。

>>183
このへんか。
「日付の表記に関するノート」 http://www.kanzaki.com/docs/html/dtf.html

>>183
うちのサイトもその書式だ。

MySQLもW3Cの推奨も日付書式はハイフンだ。

テーブルにcaption要素は必ず入れないといけないのでしょうか？

DTDによろしく。

名前とName Not Foundは対になっている。投稿日、IDもまたそう。
だからdt-ddかtableを使え。

たいていの場合キャプションつくだろ

\begin{table}
\caption{hogehoge}
\begin{tabular}
hogehoge
\end{tabular}
\end[table}

LaTeXかよ！

>>187
任意。


あくまで英単語としての話だけど、 "acronym" はある程度単語として成立してるもので、
"abbreviation" は正式なものとは言えない「略記」「略称」に近いものだと思う。
というか、だからこそ(一応)共存したんじゃないか。

>>192
？

> "acronym" はある程度単語として成立してる
ある程度も何も、"頭文字"を意味する英単語に他ならない。
個人的な感想ですか？

> "abbreviation" は正式なものとは言えない「略記」「略称」に近いものだと思う。
無根拠。個人的な感想ですか？

>というか、だからこそ(一応)共存したんじゃないか。
何ですかその荒唐無稽な結論は？

>>193
俺は192じゃないが使い分けの話をしてるんじゃないかな。

つまりacronymが存在することを根拠に
役割分化としてabbrの拡大解釈を認めるべき、と？

>>195
本人じゃないので確信はないが・・・
XHTML2.0では統一されるらしいというのを根拠に
二つを大差ないものとして解釈する人もいれば、
現規格で両立する以上何か差があるはずだと
色々考える人もいるということではないかね。

なるほど。

>>196
> 現規格で両立する以上何か差があるはずだと
> 色々考える人もいるということではないかね。

これについて補足すると、二つとも入っているのは単に歴史的事情による。
しかしせっかく二つあるんだから、使い分けをしようと努力しているのが現状。

結局の所、W3Cの仕様呼んでそこから読み取れる事以上の事は
全部憶測になる。
せいぜいワーキンググループメンバーの発言とか。

拡大解釈を認めるべき、べきではないとソースもなしに論議しても無意味。

>>193
英英辞典から抜粋してみると、

acronym
A word formed from the initial letters of a name or
by combining initial letters or parts of a series of words.

abbreviation
A shortened form of a word or phrase used chiefly in writing
to represent the complete form, such as Mass.

acronymはword(単語)でありabbreviationはshortened form(省略形)であると
書いてあるようだから、192の言い方もそれほど間違っていないような。
少なくとも、
>"頭文字"を意味する英単語に他ならない。
これは端折りすぎというか間違いだろ。

どこで線を引くかが難しいのは確かだが、両者に一応違いはある。

それゆえにここはくだらない論議スレなわけで。

>>200
解釈論議をやる分には、辞書を調べるのはよいアイディアだと思うけど、
仕様書がアレ（定義リストの使い方など）な以上、あまり辞書的定義に依存するのも危険かもね。

もちろん分かってるとは思うけど。

よく考えたら>>202のレスはあまり意味がないので撤回。

過去ログ的には、
abbrもacronymも同義としても問題なし。
IE対策でacronymにする人もいるが、今後を考えるとabbrで統一。

結局のところ、両方入ってるのは歴史的事情なんだよ。具体的はWebブラウザの実装の追認。
abbrとacronymの違いなんて猛烈に細かい。
この程度の違いで要素を分けるなら、もっと他に入れるべき要素はあるだろう。
だからXHTML 2.0で統一されるのは俺は歓迎。

あと「細かい」といえば、code, var, kbd, sampあたりも何とかならんのかと思う。

>>206
訂正。s/具体的は/具体的には/
そして補遺。

だから、「二つあるのだから使い分けるべきである」と「abbrのみを使うべきである」は
どちらも真っ当な意見。どちらにも正当な理由があるのだから議論してもしょうがない。

議論の余地があるとすれば、「使い分けるなら、どういう風に使い分けるか」という点ではないか。

>>206
歴史的事情のソースキボン。せめて「過去にこんな感じのメールが
ワーキングのメーリングリストに流れた」でも。

ソースなしで「両方入ってるのは歴史的事情なんだよ」という分には
（他の誰かが脳内理論で）「両方入ってるのはちゃんと意味があるんだよ」
と言ってるのと、第三者には区別がつかない。

blockcodeなんて要素は新設しないでほしいな
それだとblocksampもなきゃおかしいし

<code>
　<pre>
　</pre>
</code>

ってことになればいいのだが

歴史的事情ってずいぶん有名な気もするけど…。

>>209
ins, del式？

>>208
君ね、自分で調べなさいよ。検索すりゃいくらでも出てくるでしょ。
http://www.parkcity.ne.jp/~chaichan/src/htmabbr.htm
http://members.jcom.home.ne.jp/pctips/www/Element/acronym.html

>>208
>>118、関係者談らしい

>211
うん

ていうかソースコードMLっつうの作って別xml名前空間にした方がいい気もする
でもやっぱ規格作ってる人たちってそういうの仕事にしてるからXHTML空間にしておきたいのかも

ああ、その程度の話なら、知ってるよ。申し訳ないが。

つまり、「関係者に聞いた」程度の話であってなんの意味もないじゃん。

だって、仕様そのものが、関係者というかエディターによって書かれていて
いま2つの属性があるのだから「関係者が言うには〜」程度の
（しかも、関係者成る人物が自分のWebSiteで語っている訳ではなく、
それを更に聞いた人がいる、と言う話だ）ものでは
「でも仕様には２つあるよね」と言う話を覆せない。

もちろん、話の元がデマとは言わない。確かなソースなんだろう。
しかし、どう考えても仕様の方が圧倒的に上位であって、
仕様に2つ書いてあるものを「本当は1つで良かったんだ」と言ってしまえるほど
のものではない。

>>215
それじゃ、君の書き込みの

> 歴史的事情のソースキボン。せめて「過去にこんな感じのメールが
> ワーキングのメーリングリストに流れた」でも。

はどうかと思うよ。「口頭で聞いた」と「MLに流れた」の差は決定的な差か?
「規格に書いてある」と比べれば、どちらも大差ないわけで。

>>215
言ってる事は解るが、その「仕様」がえらくいい加減だからなぁ。

W3Cのソースだけを信じて生きていきたいなら、
XHTML2.0の動向でも生暖かく見守るが吉。

そろそろどっかで強力なマークアップ言語作ったりしないのかな？
それ使ってXHTML2.0に変換したひ

>>218のマークアップ言語というのは間違いで、
XHTMLに変わるような言語ということです。

>>216
文章が公開された場に後まで残る（更にメーリングリストの場合
前後にまつわる論議もあるはずでそれも記録として残る）と、
どっかで立ち話して口頭でききました、はずいぶん違うと思うが…。

しかし、どっちも仕様を上書きするほどのものではない、という点には同意。

>>218-219
どういう用途に対して「強力な」言語なのかによるとは思うが、
少なくともスレ違いだ。

>>218
文学用途ならTEIオススメ。

>>218
SmartDocとか?

Strictな通販サイトって存在する？
あったら教えて。

>>221
ごめんなさい。もうしません。

>>222
ちょっとボクには敷居高そうです…

>>223
これはよさそうですね！適当にパクらせてもらいます！

HTMLは論文みたいなもんなんだから云々〜と何度か言われましたが、
通販サイトも論文なのでしょうか？

「論文みたい」が何を言いたいかによる

>>226
なにが言いたいのかよく分からんが、「通販サイトとまともなHTMLの相性」について書いてみる。
別に通販サイトに限った話でもないので「WebアプリケーションとまともなHTMLの相性」にしよう。

まず、まっとうなHTMLで書くには内容を構造化する必要があるわけだが、
これはWebアプリケーションの場合、

・ロジックが簡単化することが多いので、開発者にとってはバグの混入が減る。
・内容が整理されるので、ユーザにとっては使いやすくなる。

という副次効果がある。みんな幸せになるわけだから相性は良いと言ってだろう。

また、form関係の要素は結構至れり尽くせりなので、そのへんをきちんと活用すると
HTML文書自体が分かりやすくなり、謎div, 謎spanが大量に出てくるということが無くなる。

具体的にいうと、fieldset(legend)、labelを活用してあげてくれということ。

　業務でHTML書いてる（通販じゃないけど）印象からすると、
通販サイトの顧客としては、主婦層、特にブラウザやＯＳを全く意識していない
人々が想定される。従ってWin98の、買ってそのまま（下手すらUpdateすら行ってない）
IEあたりでも崩れずに表示されることがクライアント側から要求される。

　更にその上に、商品を「派手」に「見栄え良く」見せることも要求されるため、
様々なUAへのバグ対応などからStrictよりもTransitionalが選択されることがおおい。

　ちなみに、上記の様な事情はあくまで事情であって、Strictな通販サイトが
出来ない訳でも、Strictが通販サイトに適していない訳でもない。

# しかし、古い環境でも見栄え良く表示されるサイトを作る時、Strict+CSSと
Transitional+Tableレイアウト+一部CSSとどっちが楽ですか、と聞かれれば、後者。
　ただし、運用コストに劣るったり、ユニバーサル性にかけるなど、いわゆるStrictでは
ないことのデメリットがかなり顕著に成ったりもする。
　最終的にはクライアントがそう言うことを総合的に考えて「儲かりそうな方」を
選ぶことになる（商売やってるんだから、正しくても儲からなければ首を縦に振らない）。

検索エンジンへの適性なんかを考えるとStrictのメリットがさらに強調されるよね。
特にクライアントへの説得力は大きいんじゃないか？

>>230
yahoo が新しく採用した（元に戻した？）自前のエンジンがどういう所を見てるかによるかも。
個人的には google があれば yahoo なんざいらんけど、
商売の人はそういう訳にもいくまい。

業務でコード書いてるけど、NN4について説得できたクラに対しては
Transitional - tableレイアウト + 全部CSS でやってます。
tableレイアウト + 一部CSS とどっちが楽か、はトントンかと。
どっちに慣れているか、の問題じゃん。

業務でやる = 広告・広報な性質が強いし、大抵の場合代理店が挟まる。
で、大抵の代理店（最大手も）では技術的なことは制作会社に実質丸投げで、
コードが strict になることで google ランクが上がったとしても、
それは代理店の手柄ではないので、あまりメリットとは考えていないかも。

クラにとってはもちろんメリットなんだけどね。

あれ?書き込めてない…

>>209>>211
ins,delはXHTML2でedit属性化されるから、codeも属性化すればいいのでは

insやdelは「要素の状態」を指定しているのに対して、
codeを属性化すると「内容の性質」を指定することになるので話が違うのでは？

俺としては、XHTML2のp要素の様な内容モデルになってもらって、
必要に応じて code に xml:space="preserve" を設定するのが良いと思うのだが。

// つーかxml:space="preserve"があるんだから pre 要素こそイラネ。

質問だけど<HR>のCOLORやSIZE属性ってCSSでのcolorやsizeで代用できるの？
NOSHADEはCSSでは無理だと思うけど。
<HR>自体Strictとして非推奨なのかもしれんけど・・・

ごめん、自分で試してみた。
colorはいけたけどやっぱりsizeは無理みたいね。

>>234
問題はブロック要素とインライン要素を二つ作ることだと思います。
同じ意味の物を表示の為に二つ作るのはXHTML的ではないと

#要素の状態と内容の性質だったらxml:langとかsrcだとかhrefだとかはどうなるのだろうとか言ってみたり

>>236
windthやheightで上手くいきませんか?

>>232
＞tableレイアウト + 全部CSS
HTML にレイアウトを記述してる時点で「全部CSS」っていうのはありえないのでは。

>>238
heightか・・・できたできた、ども

>>237
話がちがう、と言っているだけで反対はなしてないよ。
つまり、問題解決の「手段としての」codeの属性化はどうだろう、と言うこと。

＞#要素の状態と内容の性質だったらxml:langとかsrcだとかhrefだとかはどうなるのだろうとか言ってみたり
ああ、ごめん。でも例えばhoge要素にxml:lang="xx"で言語を設定しても、xx語の「hoge要素」だし、
ins/delも追加された/消された「hoge 要素」、hrefもハイパリンクを持った「hoge 要素」と、hoge要素の部分は揺るがない。

codeを属性にすると、codeの段落とか、codeの見出しとかなっちゃって、おかしくないかなぁ、と。
うまく言えないんだけれども。

>>234
code属性をグローバル化させないとか。(divかspanのみ)

>>232
> 業務でコード書いてるけど、NN4について説得できたクラに対しては
> Transitional - tableレイアウト + 全部CSS でやってます。

このスレッドでよく「Traditional + CSSを使ってる」という話があるのだけれど、
Traditionalを使って嬉しいことってあったっけ?
「Framesetを使ってる」という話ならまだ分かるんだけど。

>>243
おっと。
s/Traditional/Transitional/

>>243
スレ違いだけど、糞IEへの対応が楽

より正確には
s/Traditional/Transitional/g;

>>245
なるほど。thx。

>>243
バグ対応以外で「新規に」Transitionalな文書を作成する意義は見いだせないが、
既存のHTML3.2をXML文書に機械的に変換する時に XHTML1.0 Transitionalの存在は凄い重要。

大量にある文章のfont要素とかを一々これは強調で、これは見栄えで、とか人間が評価出来ないし、
しかし、HTML3.2であるというだけでXPathもなにもかも使えません、というはそれはそれで痛い。

（古スレに誤爆したのをコピペさせていただきます。）
最近Strictを意識し始めた者です。
“100の質問”のような形式のマークアップを考えていて、以下のようになったのですが、
<ol>
　<li>
　　<dl>
　　　<dt>質問</dt>
　　　<dd>
　　　　<p>答え</p>
　　　</dd>
　　</dl>
　</li>
　<li>
　　<dl>
　　　：
これで良いのか悪いのか解りません。
先輩方から見てこれはどうなんでしょうか。

駄目杉

<dl>
<dt>膣モン1</dt>
<dd>A.はやくいれてぇぇ(p要素はあってもなくても)</dd>

<dt>膣モン2</dt>
<dd>A.もっともっといっぱいかけて(p要素はあってもなくても)</dd>

：
：
</dl>

>>249
その質問に順序があるわけじゃなし、 ol は違うっしょ。
>>250で十分なきがする。

>>243
漏れが業務で触るようなコードは大抵企業サイトだったり、
何かのサービスをやっている商売サイトだったりします。

えてして、そういうサイトは複数人・複数グループがいじる（更新とか追加）
事になって、（悲しいことだが）世の中の商業web制作者全てが
strict にコードを書けるわけじゃない、です。
target="_blank" が良くない理由やその代替方法を知らない人の方が
多かったりもします。

なので、漏れが最初にコードを構築する時には例え strict でも
transitional としています。

>>251
順番の有無は質問によるんじゃない？

例えば
問４「問３で『はい』と答えた方は〜」
なんて場合もある訳で。

しかし、その場合でも>>250で良い様に思われる。

# リスト状で順番がある場合もあるだろうが、ナンバーを特定する表記が
ある場合にはdtの内容としてナンバーが書き込まれる事になるし、
olじゃなくても順番は保持される。

「100の質問」のマークアップに関する議論リンク集
http://www.akatsukinishisu.net/itazuragaki/100qa_markup.html

>>252
>target="_blank" が良くない理由やその代替方法を知らない人の方が
>多かったりもします。

恐縮ですが教えて欲しいです。確かにlintとかにかけると言われますが、理由はあんまり
たいした事かいてなかった気がします。でも、代替法があるならそれやりたいです。

代替方法：ユーザに新しく開かせる（IEならShift+クリック）

a:after{content:"(別窓でお開き下さい)";}

…こんな文章表示したら、ユーザーから「余計なお世話だ！好きにさせろ！」
ってクレームが来そうな気がするだろ？　全くその通りなんだよ。

a:after{content:"(←を別窓で開かないのは負け組み)";}

でも結局blankなんてフレームがらみでしか使わないし、フレームからみだとblank以外には
無理だし・・・・

結局無駄なblankをなくせばそれで十分ですね。

いい加減ウィンドウという概念がないUAもあることを知るべきです。

ところでマイコンピュータとかでフォルダを開くとき別窓で開いてる? それとも同じウインドウに開いてる?

マイコンピュータって何ですか?

>>255
strict に target 属性はなかったと思われ。

タブのあるブラウザを使っていると特に、_blank は邪魔くさく
感じることが多いです。

ただ広告屋さんの意見としては、別サイトにリンクしている場合、
自サイトがデスクトップ上から消えてしまうのは辛抱ならん、とのこと。
気持ちはわかるけど。えごいすちっく、だなと思う。
広告屋さんは往々にして、対マスに優越感を持っているので、
そういったエゴは他にもいろいろ出てきますね。

--

ｳｨｿだとエクスプローラを常に使うので、コピーするときくらいしか
別窓は開かんです。

理屈的にはtarget属性がダメなのは分かるけど
代替可能なCSSがあれば助かったんだけどな。一カ所指定すればあとはOKみたいな。
俺も今XHTML1.1でシコシコやってるけど全部のリンクにwindow.open();がつく(外部だが)。

漏れは最近、class="blank" と書いて、JavaScript に拾ってもらっています。
いちいち window.open の引数を書くのが面倒なので。

class振るなら、ather-site-linkとかの方がいい気がする。
blankは空白って意味だし、そのリンク先が真っ白なわけじゃないしね。

>>264-266
いろいろ考えがあってやってるんだろうが、
なんでそもそもtarget要素がXHTML1.1やstrictで使えないのか考えてみ？

仮に、それでも本当に必要なら素直にTransitional使えばいいじゃん。
スクリプトなんか動かしてユーザー側UAに負荷を掛けるより余程誠実だ。

>>267
俺に関してはただの趣味の範疇。必要性はないな。
言うだけ無駄なのは分かっている。高尚な場所で雑談すんなってならそれまでだが。

IEがTransitionalを変に解釈しなければStrictをやろうとはしなかっただろうな。
現状HTML 4 transitional+テーブル+フォント周りのスタイルシートが
もっとも普及・かつ安定してるわけだしそれ以外をやるってなったら無駄でも何か言いたくなるさ。

「高尚な場所」だとは思ってないよ。単にスレ違いと言うだけの話。

Strictにおいて「技術的な理由」で実現出来ない問題をどのような
代行手段で実現するか、という話は非常に有意義だけど、
Strictにおいて「理念に反するから」削除された属性をスクリプトなどで
無理矢理復活させるのは非Strict的で、スレ的には肯定出来ない、と言うだけの事。

> なんでそもそもtarget要素がXHTML1.1やstrictで使えないのか考えてみ？
お前は知ってるの？

>>260

target属性って今のところはXHTML2にも残る方向だったと思うが。
理念に反するならXFramesなんて話出てこないだろうし。

>>272
つまりXFramesによって既存のフレームのデメリットが解消されたら
Strict的に問題が無くなるって話じゃないの？

「フレームという概念」が問題だとはだれもいってないし。

「Webブラウザのウィンドウ」は、DOMに入ってるんだから十分JavaScript(など)の守備範囲だろう。
もちろんHTMLの守備範囲ではない。
だからJavaScriptで制御した方が真っ当だと思う。

>>274
だから、そのスクリプトの話をStrictスレでするのがスレ違いだっての。

>>274
ウィンドウはDOMでは標準化されてないよ。

>>273
技術的なデメリットの存在は
Strictにおいて理念に反する問題だと捉えられてるわけね？
で、現状においてtarget属性はデメリットがあると。

>>276
> ウィンドウはDOMでは標準化されてないよ。

確かにその通りだ。274は嘘。

そもそもaはその内容と、あるリソースを結び付けているという意味に過ぎないはず。
その前提の元でtargetとは何かと考えればtargetがHTMLの範囲内でないことは明らかなはず。
#同様にaccesskeyやnavindexも本来不要。

その上でスタイルシートやスクリプトの補助のためにclassを使うようにXFramesの補助として定めようって言う風に読める>XHTML2.0

そしてXLinkが叩かれるわけですよ

まぁ、実際叩かれてるけどね。

しかし、名前空間的にXHTMLの部分がStrictなら、他の名前空間の要素や属性まで
Strictで有る必要はないけどね。

例えば XHTML 1.1 + SVG なんか、SVGの部分が見栄えに関して色々定義してあるけど、
XHTML 1.1 の Strict さは独立して保証されてるから Strict 的には問題ない、みたいな。

要するに表示側ということですから、accesskey,navindex,target辺りは全て表示なのでCSSであるべきなのでは?
aのhref属性もa{link:attr(href)}のようにするべきと。
titleのツールチップもか。

accesskey,navindex,targetはインタフェースではあっても、
スタイルシートではないんじゃない？　CSSで解決すると言うのにはちょっと違和感を感じる。

ツールチップをCSSに任せるべきと言うのは禿胴

こんな感じ？

E[title]:tooltip{
content:attr(title);
color:black;
background-color:yellow;
border:solid 1 black;
padding:0.2em;
}

擬似要素になるので、E[title]::tooltipとなるはず。
xhtml2のsrcとかも表示かな。
src:url("*.png");type:"image/*"ってとこか。

accesskey,navindex,targetはインターフェイスか…
少し考えてみる。

OperaでのCSS拡張に-o-link-sourceとか-o-linkとかある。
SVG1.1にもイベント制御のがある。
ttp://is.vis.ne.jp/old-dict/svg11_interact/pointer-events.xhtml

CSS拡張のaccesskeyの例とかﾊｹｰﾝ
-wap-accesskey

>>285
いや、イベント系制御をCSSと同じ書式で書く事自体はぜんぜん問題ないと思う。
でも、それはイベント系制御であって、スタイルシートではないよね？　と言うこと。

セレクタが状態を指定する（onMouseの時色が変わるとか）のはCSSの範疇だけど、
accesskey みたいに 特定のキー操作で行われるアクションを指定する、と言うのは
CSSじゃないと思うんだ。

W3C的にスタイルはヴィジュアルな物だけではない。ということを忘れてはならないと思う。

CSS3でﾊｹｰﾝ
てかスゴ
http://www.w3.org/TR/becss

おお。そうだったのか。それは失礼。
俺の感覚の方がずれてた。

nav-index は CSS3 Basic UI (CR) で提案中。key-equivalent は削除されたみたいだが。
http://www.w3.org/TR/2004/CR-css3-ui-20040511/

speak プロパティといい、CSS はどんどん *Style* だけに留まらなくなっているな。
良い傾向なのやらどうなのやら。

speakは音の「スタイル」ということか？
って事はイベントもイベントの「スタイル」？

…speakの仕様をみたときは違和感なかったんだけど、
スタイルの意味がわからなくなってきた。

俺みたいに盲目の人が見ることを一切考慮してない人には関係ない

イベントってスクリプトでやればいいと思うんだけどね。
JavaScriptからDOMがちゃんと操れれば、クラスやIDでノード取り出して、
そのノードにイベント追加してonClick=open()とかしてやりゃいいわけで。

>>295
同意。イベントがスタイルかどうかは別にして、
DOMが3まで完成した今、CSSでこれからやる意義が良く解らない。
（既にあるあら、複数の手段から選べます、と言う事で問題はないけど）

現状のDOMでは特定のクラスを取り出すなんて
全ての要素のノード集合からループ回してちまちま検索するしかないからね。
DOM3XPathはHTMLに対しては使えないし、
何にせよ文書ツリーからノードを取得する方法は読み込み完了後でないと動作させられない。
CSSのように先行指定で文書ツリー構築時に逐一
指定条件にマッチする要素にイベントを追加したいという要望があるのは頷けるけどな。

DOM3XPath みたいに DOM3CSSSelecterを作っちゃうとか。

擬似要素などにイベントを割り当てたいときに必要。

さらにCSSでない一般のスタイルシートを想定すると見栄えと操作体系には不可分な部分があることがわかる。

>>299
確かにそうだな。
MVCモデル考えるとHTMLがModelで、スタイルシートはViewだが、ViewとControlが不可分なのは明らかだもんな。
そうなるとCSSにControl関係の機能が付くのも否めないと。

それよりブラクラ怖くてJavaScriptをOnにできない俺はどうなるのかと

俺は饅頭が怖いよ

>>301
おみとろん使ってないの？

>>303
スレイブ（レイプ）ぬるぽだよ。

そろそろFirefoxに移行を考えてる。
#なぜなら俺のサイトがアルファチャンネル付きpngとMathMLを使うことになりそうだから

しかし、CCS2の頃から「訪問済みのハイパーリンクをフォーカスした時」
なんて指定が存在し、広く使われていた訳で、今更騒ぐ話題じゃないな。

CardCaptorSakura

>>306
また懐かしいネタを・・・

>307
再放送してるし。

現実問題として、Control をスタイル記述に含んでしまうとスタイルファイルが肥大化するんじゃなかろうか。
このスレ的には Strict であればよい、ということになってしまうのだが、
よほどスマートに策定しないと理解が難しくなって一般に広まらない悪寒。

javascriptでfor文使ってイベント付加するのに比べれば
処理は軽くなるよ

CSSの内部処理がどうなってるかによるけどな。
極論UAがCSSセレクタをJSで実装してたら同じな訳で。

スタイルシート切り替えでjsを切り替えられるようになったり、ユーザースタイルシートでjsを使えるようになったり。(・∀・)ｲｲ!!

>>311
極論UAがCSSセレクタをJSと同様の方法で実装(つまり文書ツリー構築後に
全要素を走査して各セレクタとマッチング)してたとしても
スタイル適用と同時にイベント適用もやってくれれば
ループを1回減らせるので随分違うかと。

>>313
つまり、CSSを使わずにJSでDOMCSSを使えば同じな訳ね？

>>308
CSSスレに書き込むネタとして…

>>314
DOM2CSSってのはCSS2を操作するオブジェクトモデルなわけで
「CSSを使わずに」はありえないんだけど。

CCSに反応とか、なんか新しく人が入ってきたって事だよな。
とりあえず、過去ログを検索くらいはしておく、これマジお勧め。

>>317
37の質問にもあったから、懐かしいな、と。
再放送されてたことは知ってるけど。

あ、＋αの方だったっけ？

>>317
6ヶ月ぶりの帰還ですが何か？

1ヶ月休むと1年戻るって言葉、知ってる？

つまり6時間ねると3日戻るのか。人生とは大変だな。

俺は子供のころにもどりたいよ

>>321
仕事では常にStrictでしたが何か？
忙しくてスレ覗いてなかっただけで。

>>324
いや、ネタの古さの話なんだから、ぶっちゃけStrict関係なくてスレ覗いてたどうかの話だろｗ

(´･ω･`)ｼｮﾎﾞｰﾝ

>323
計算して寝まくれ。おやすみ。

1日休むと3日戻るっていうのはよく聞くけど、つまり8時間寝ると1日戻るのか。
最初に気づいた>>322はえろい。
既知のネタ？

余所で見た事はないが、だれでも思いつかないか？

ちなみに、1日休むと3日戻り、休まなかった日の訓練時間を8時間とすると、
1時間やると9時間進むと言う事に。

徹夜で仕事すると道理で老ける訳だよ、ママン。

水前寺清子スレはここですか

なんか<b>とか<i>、<font size="+2">とかの物理マークってロボット型検索エンジン
では結構な高得点なんだけど、使ったほうがいいの？あまり使いたくないんだけど。

正しいここのみんなの意見を聞かせてくれ。

ロボット型検索エンジンで高得点な事と、Strictな事は無関係。

>>332
でも高得点を狙うとStrictになれないんだけど・・・・

どうしてそういえるの?

>>333
何を相談したいの？
＞高得点を狙うとStrictになれない
けど、Strictで高得点にしたいの？　言ってる事が矛盾してない？

>>331
<b>や<i>で点数が上がるなら、<em>や<strong>でもあがると思う。

もしあがらないなら、そんなクソ検索エンジンは誰も使っていない……はず。

はっきり言える事は、Strictでは b、i は極力使わない方が良く、
font は使ってはならない（使えない）と言う事だ。

>>335
作ってるのは通販サイトなんだけど、なるべくStrictに近い形で書きながら高得点が欲しい。

>>336-337
<b>は<strong>でいいけど、<font>をCSSでやると検索エンジンは理解しないでしょ？
で、通販サイトは結構<font>を使ってる所があるみたいで、どっちにするべきか悩んでる。

後<h1>のサイズを変えるとスパムと認定される場合があるっていうのを読んだことあるけど、
CSSで変えれば検索エンジンは理解できないから大丈夫だよね？もちろんそれを乱用するわけじゃないけど。

ついでに<h1>画像１（文字）、画像２（ライン）</h1>っていう見出しは検索エンジン的にはどうなの？Strict的には
あまりよくないよね？

SEO対策とstrictは無関係。



というのがｽﾚ的見解。

>>339
<font>の強弱をうまくつけると高得点になるんだから、無関係ではないのでは？

フォントサイズで文字列の重要度を測る
不思議マークアップ解析ロボットがいるっつーことなんだろうな。

検索エンジンなんて無数にあるUAの一つでしかないしねぇ。

>>340
<font>って何？

自分書いたHTMLがvalidであるかないかを検査してくれるサイトってないんですか？
lintは知ってますけど、あれはvalidかどうかは調べられませんよね？

>>341
不思議マークアップが横行した結果みたいよ。多分<strong>とかと同じ様にとらえるんでしょ。
googleとかもそうじゃかったっけ？

>343
>>3

lintで100点取っとけばvalid・・・とは限らんか。
がんじがらめのtableでもsummary属性入れとけばエラー吐かないかもしれないし。

>>345-346
やっぱり日本語のページはないんですね。翻訳にかけて使うしかないですか？

正直さして難しい英文とも思わないよ。
とりあえず急がば回れ。lintで吐かれるエラーを1つ1つ潰して行き、なぜエラーと
されるのかという知識を地道に蓄えるのがよいかと思われる。

＞<font>をCSSでやると検索エンジンは理解しないでしょ？
単なるスタイルの指定なんだからフォントに"意味"はない。
意味がないんだから理解出来ない。

意味があるなら、その意味に対応した要素（例えば強調ならstrong）を使えばいい。
何の問題もない。

>ついでに<h1>画像１（文字）、画像２（ライン）</h1>っていう見出しは検索エンジン的にはどうなの？
スレ違いなので該当スレで聞いてくれ。
どんな検索エンジンかすら指定せず漠然と聞かれても答えられる奴は居ないと思うが。

>Strict的にはあまりよくないよね？
具体的にどんなコードなの？ h1の内容が画像と言うこと自体は全く問題ない。
この場合、画像に指定されたalt属性がどうなってるかが重要。

>>347
> やっぱり日本語のページはないんですね。翻訳にかけて使うしかないですか？

このバカ野郎。ちゃんとリンク先みろよ。
「Another HTML-lint」 http://openlab.ring.gr.jp/k16/htmllint/htmllint.html

>>350
煽るわけではないが、>>343は既にlintを知っており、その上でValidか
否かを調べるサイトを探している。

> lintは知ってますけど、あれはvalidかどうかは調べられませんよね？

「lint」が何を指すのか知らんが、「Another HTML-lint」だとしたら存在は知っているのか。
「Another HTML-lint」は「規格としてvalid」かどうかのチェックはしてくれる。
「HTMLの考え方としてvalid」かどうかを機械的に確認してくれるものはないだろう。
自分で考えるしかない。

なんかいってることおかしいね…俺。
>><font>をCSSでやると検索エンジンは理解しないでしょ？
>単なるスタイルの指定なんだからフォントに"意味"はない。
>意味がないんだから理解出来ない。
>意味があるなら、その意味に対応した要素（例えば強調ならstrong）を使えばいい。

本来、fontも単なるスタイル指定なんだから、意味はない。
検索エンジンはそこから「何か」を読み取ってくれるかも知れないけれど、
意味があるならの意味に対応した要素（例えば強調ならstrong）を使えばいい。

と差し替えさせてくだちぃ。

>>348
lintで100点は出ますけど、それはlintの100点を目指して、lintの点数の付けかたを
正しいとした結果なので、あまり実際のHTMLとしてはイマイチなんです；

>>352
そうですよね。

みなさんありがとうございました。やはり何がvalidで何故strictなのかの基礎を
勉強することにします。

>>349
<h1>内が画像でもaltがしっかりしてればいいのね。俺も>>354を見習ってもっと勉強するよ。

>>354>>355
応援してるよん

簡単なaltのチェックとしては、まず一旦画像を外し、
「画像の代理」としてではなく、そこにテキストを（今回の場合h1の内容を）入れる。

そして、次に画像を差し込み、「その画像が入った事によって要らなくなったテキスト」を
画像のaltに設定する。
この時、画像を入れても要らなくなるテキストがない場合、その画像は装飾的な物で有る可能性が
高いので、とりあえず alt="" とした上で、CSSによる実現も検討する。

最後に「画像によって要らなくは成らないがどうにも余ってしまって『表示されると見栄えが良くない』
テキスト」があるなら CSS で display:none 等して消す事を検討する。

ただし、CSS on 画像 off の場合、CSS off 画像 on の場合でも、意味が通じるように
配慮する必要があるので、その点にも注意する。


以上をやれば、完璧とは言わないまでも余り酷い事には成らない。

>>357
ありがとう！

ところで、初心者スレとCSSスレとここのテンプレにあるサイトはある程度見たけど、
さらりとしか見てないからこれからちゃんと熟読しようと思うけど、作ってるのが通販サイト
で、一番変えなきゃと思うのが、テーブルの排除と<hn>の正しい挿入、メニューバーの
の正しい書き方辺りなんだけど、どこのサイトが一番お勧め？

特にメニューバーを正しく書きかえるのが難しそう・・・なんか質問スレでもないのに質問ばかりでごめん。

>>358
おすすめなんて答えたら自薦めでてーな、ってなるから教えない。

>>359
そっか；とりあえずStrictの説明してるサイト見てるよ。

<hn>って一応歯抜け、逆行はよくないって
http://www.parkcity.ne.jp/~chaichan/src/htmlmain.htm
このサイトにあるけど、言ってるこのサイトが<h4>の後に<h3>に一度戻ったりしてるけど
それはいいの？今ここ見ながら、自分のサイト完全に作りなおしてる。

<h3>から<h2>に戻るのがありなら結構楽だけど、それはおかしいよね？

>>360
いや、全くおかしくない。

例えば小説で

h1 小説のタイトル
　h2 1章
　　h3 1章1節
　　h3 1章2節
　h2 2章　←ここ
　　h3 2章1節

と言う風に h3 から h2 に戻る文章が存在するが、これはごく当たり前の事だろ？

逆にこういう構造がありえない
h1 小説のタイトル
　h2 1章
　　h3 1章1節
　　h3 1章2節
　　h3 2章1節　← 第2章が無くていきなり1節が始まる。

これだと、まるで「2章1節」は1章の第3節のようになってしまう。

もし見出しのレベルで混乱したら、このように、見出しを書き出してみて、
目次を作ってみるといい。

追記
　>>360 で書いたとおり、逆行は問題ない訳だが、歯抜けは問題有る。
　例えば
h1 タイトル
　　h3 1章1節
　　h3 1章2節

と言うのは有り得ない。この場合、「h2 1章」というのを入れなければならない。
　また、以下の文章は一見歯抜けしていないようだが、
h1 小説のタイトル
　h2 1章1節
　h2 1章2節
　h2 2章1節
「章レベル」の見出しが抜けているため、1章と2章の節が真っ平らに並んでしまっている。
この場合、「h2は実はh3」で、「h2抜けていた」と解釈される。

ただし、このような歯抜けは問題ない。
h1 タイトル
　h2 1章
　　h3 1章1節
　　　h4 1章1節1項
　h2 2章

この場合、h4の次にh2が現れているがこの「h2 2章」は「h2 1章」と並んで
「h1 タイトル」の次のレベルの見出しなので、きちんとh1→h2と並んでいると
見なされる。

>>360
逆行が駄目ってのは
h2 タイトル
　h1 1章
みたいのじゃないか？

当然NG。

ていうか、やっぱりこのスレによる「Strict HTML 入門サイト」はあったほうが良いんじゃない？
このスレで質問されること自体は全然構わないんだけど、
このスレで出る回答でStrict初心者にどこまで解ってもらえるのか疑問。

>>331,333
そもそもある程度のStrictで書けば高得点になるんじゃないの？
ぐぐるとときどき「実力」以上に上のほうに出てくるサイトがあるけど、
そういうのはStrict(風)が多いような気がする。

>>338
><b>は<strong>でいいけど、<font>をCSSでやると検索エンジンは理解しないでしょ？
emとstrongの2種類の強調があるんだから、例えば太字はemにして大きい字はstrongにするとかすれば良い。
それなら検索エンジンに評価してもらえるしStrictだし、一石二鳥。
というかStrict的には「emを太字にしてstrongを大きくする」っていうのが正しい考え方だけど。

とりあえずは見出しと強調を丁寧にやってればロボットにも人間にも読んでもらえるよ。

> というかStrict的には「emを太字にしてstrongを大きくする」っていうのが正しい考え方だけど。
…禿しく誤解を招きかねない表現に思うので撤回または修正きぼんぬ。

>>364
＞一行目
神崎さんとかその辺でいいんじゃない？

>>361から>>366
おお！スレ違いな発言にここまで親切にしてくれるとは！

見出しの疑問は>>361-362さんの説明でよくわかったよ。なんか通販サイトをいきなり
Strictにするってのは難しいね。テーブルで固める事で成り立ってる見栄えの上に、
今まで<hn>が一つもなく完全にTransitionalに甘えきっていたから、会社のロゴとかを
一体何でマークアップすればいいかさえ微妙なとこだよ。

アダルトサイトをStrictでやったんですけど
結局ダメになりました。不採用というか実用に耐えないって。
相互リンクにおいて別ウインドウが開けないのはダメだそうです。
まあそういうジャンルもあるんですなぁ・・
ということでJavascriptなしにウインドウが開ける方法がXHTMLで生まれないかと思う。

>>368
不採用にした人もバカだねえ。
そんなアダルトサイトなら信用するのに(笑)

バカみたいな質問で申し訳ない。

フレーム指定でサイトを制作したのだが
３フレームです。１はtop ２はleft ３はright としましょう

１は常に表示されている状態です。２はメニューです。２のメニューで選択すると、３にそのリンクが表示される仕組みです。

本題
２をいじくりまわして、３の状態がいろいろなリンク先変化している時、ブラウザの更新ボタンを押すと　『何もしてないとき』（初めてページを開いた状態）に戻すには
どのようなタグを使うのですか？

>>370
で、それのどこがstrictなんでしょうか

>>370
スレタイ読めないと、何もできないぞ。
とりあえず初心者質問スレにでもいってきなよ。ここは一応議論スレで、質問は
Strictについてだけ。

まあ質問は初心者スレでして、無効からこっちにいけといわれたときだけ来なさい。

>>371
>>372
失礼しました。

結局ドキュメントの構造化ってのは作り手と見る方にとってどのようなメリットがあるかってことでしょ？
メリットなけりゃやっても意味ないしね。
更新のしやすさ、ファイルの軽量化、デザインと内容の分離による見栄えの変更の容易さ。
だれがそのドキュメントを管理するにしても構造が解りやすい。
ページランキングが結果的に上がるってなとこ？

>>374
わかってるやん

>>374
あとは、現在メジャーでパブリックな規格が「構造化」の方向に走っているので、
それに乗っかると新しく自身で規格を作る必要がない、というのもある。

# 作り手が一定のメリットを受ける（目的）為に、構造化以外の手段も
あり得るかも知れないが、その場合は自分で規格整備などして受け手に
ビュワーを配る所までやらないと行けないので、個人レベルではほぼ不可能。
　企業レベルではアドビのpdfなどが本当に自分で作った具体例。

>>374
それに加えて見る方としては構造されてた方がいろいろとやりやすい。
あるリンク集サイトの新規登録されたページだけ抜き出してキーワードにマッチする順に並び変えて表示するようなスクリプトを書いたのだが、RSSなんて便利なものはなく、ページ自体もぐちゃぐちゃなHTMLで書かれてたから正規表現で試行錯誤して苦労したよ。
せめて整形式のXHTMLならXSLT使えたのに……。

すみませんが質問です。
テーブルレイアウトで角丸枠を使って上部のラインを短くして見だしを書いていたんですが、
ちゃんと<Hn>を次の更新では使いたいんですが、テーブルの中にあるものに<h>を付けるのは
おかしいですか？

僕的にもおかしいとは思うんですが、テーブル使わないと角丸枠をつくれなくて・・・

>>378
わかってるだろけど、そもそもテーブルでないところにテーブルでマークづけるトコがそもそもおかしい。
CSSをある程度いじれるならhttp://www.code-404.net/archives/2004/05/31_237.shtmlでがんがれ

>>378
余計なお世話だけど、テーブルでできることをCSSで再現したい、という考えではなく、
CSSでできることでかっこよくやろう、と思えば開眼すると思うよ。

魚を無理して肉料理風に仕上げなくても、魚として美味く食う方法などいくらでもあるってこと。

あれから一人で頑張ってたらできました。上と下を一枚の画像にして、上は画像（見だしとライン）
のaltを見だし名にすることで、<hn>に対応させました。
下はdivでそのままで、真中は同じ色のボーダー使いました。IE用に画像にvertical-alignとかに気づくのに
時間が掛かりましたが、とりあえず、完全にこの部分のテーブルを排除に成功です。

>>379
後で、そのサイトも見てみます。
>>379-380
基本的にはテーブルレイアウトでやったものを対応させるより、一からやったほうが早いんでしょうけど、
まだ未熟なので、とりあえず、テーブルレイウトをCSSで実現させることでCSSの使いかた？（変な）を
覚えて、その後に作るサイトでは初めから、正しいマークアップでやろうと思います。

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

ねーねーやっぱりテンプレサイト作らない？
こういうのも「テンプレ読め」で終わるし。

作りたいなら自分で作る。これ最強。

>>380
だから信者のサイトはダサいのばかりなのか。

>>384
あなたの感性がおかしいだけでしょう。

>>385
(　´д)ﾋｿ(´д｀)ﾋｿ(д｀ )

>>386
きちんと説明出来ないので、そうやって誤魔化すしかないんですね。
かわいそうな人だ。

>>380
問題は肉を食いたいのに魚を出されて、魚の良さをくどくど聞かせられるような感じかな。

>>384
それは違うと思うよ。Strictでもいいサイトは一杯ある。カスイケにでも行っておいで。
第一Strictとデザインの良し悪しは別。

っていうかテーブルでできることは当たり前だが、CSSでもできる。できないことがあると思うなら
挙げてみてよ。

>>388
「主流派」だの「良識派」だのでわいわい騒いでるやんちゃな子達が
こっちに流れ込んできたら面倒だから、
カスイケの話あんまりふらないでﾎｽｨ…。

スクリーンメディアだけを対象にしているサイトと、未知のUAまで対象にしているサイトとを、
スクリーンメディアにおける表示だけを根拠にして比較すること自体がナンセンスな訳だが。

例えば、テキストブラウザで見た時の見栄えだと、状況は逆転する。
スクリーンメディアに関しても、ユーザスタイルシートを使った場合、
テーブルレイアウトは見るに耐えない状態になる。
当然、データとしての安定性も損なわれる。

汎用性を犠牲にしてまで、見栄えに拘る必要はないと考えるから、
CSSでできる範囲でやればいいということになる。

そしてｓｔｒｉｃｔと見栄えは何の関係もない。

正直、洋サイトでxhtml+cssのカコイイサイトは良く見るが
和サイトではあまり見ないのはなんでだろ？

やっぱり、自分が巡回しているサイトの問題なんだろうなァ

>xhtml+cssのカコイイサイト

スレ違い。ここはStrictスレ。

格好良かろうが、悪かろうが、和サイトに有ろうがなかろうが、Strictならよい。
後はどうでも良い。

関係ないとか言いながらここまで反応してしまうのは
痛い所突かれたんだろうね。

とりあえずStrictな通販サイトを教えてくれ。
通販以外の趣味サイト運営者がぐだぐだいってもね。

まあStrictは正しいが、文法やHTMLが正しい事が正しいわけでもない。

>>394
>392≠>393ならその論理は成り立たないと思うが。

>>395
自己矛盾してるよ。

>>396
イコールでも成り立たないだろ。

>>395
省略しすぎてよくわからん

新参がおかしな発言するのは諦めるしかない
雑談スレと勘違いしてる住人が気をつけるべし

よくわからんが、どうしてもStrictな通販サイトで買い物したくて
必死な人がいるってのだけ解った。

>>400
Strictな通販サイト作りたいらしいが。

つーかCSSはクソだからもっとちゃんとしたスタイルシートの規格&実装作ってくれ。
せめてSVGとかXSL-FOとかちゃんと実装してくれ。
そうすればもっと楽にStrict-HTMLが広められる。

Strictでかつ見栄えの良いサイトが作りたい。

http://www.cssvault.com/

現状ここまでできるし、SVGがブラウザサポート云々はStrictHTMLと一切関係ない。

っていうか、そもそもなんでStrictなHTMLを否定しておいて、
グラフィカルで格好いいのを求めているのになんでHTMLに固執するのかが解らん。

全編フラッシュでつくりゃあいいじゃねぇか。

スレ違いだっつーの。阿呆住人ら。

>402
CSSが糞なんじゃねぇ
IEが糞なんだよ！
あとお前が

>>403
いいねそのサイト。多分今までで一番いい。なにより見やすさがgood！
俺も頑張ろうっと。

>>403程度のdivならdiv厨とは言われないのか？

「どれくらい使ってるか？」ではなくて、「使うべきところに使われているか？」だろう。

あと定義もあやふやだな。
本来別の要素でマークアップするべきものを div でマークアップしてたら div 厨、だと思ってたんだが。

テンプレサイトを作るのであれば、
いつも延々とループする話題を収めるだけでいい気がする。

見た目を意識したdivも悩みどころだ
あとで理由はいくらでも付けれるわけだが

最初に元のを書いて、それからデザインできれば良いと思うし、俺はそう。
まあ、それだと限界がありすぎて悲しいわけだが。
だから、CSSは今のままじゃいけないと思うし、もっと強力なのを望む。

2chをstrictにしたら転送量軽減とか何か効果あるかな

2chのHTMLって本当に無駄が多いよな。

まあ、Strictに移行というよりは、奨めているのは2chブラウザだし。

ここで言うことじゃないかもしれないけど、上でなんか言ってる人いたから少し。
通販サイトがCSSレイアウトしないのは、通販サイトってのは店なんだよね。
商品をどこに配置するかを決めるのはオーナーであって、客じゃない。

対象は完全に視覚系ブラウザだし。ある意味じゃPDFの方が向いているんだけど、
HTMLを間違った使いかたするほうが商売になる。

とりあえず、通販サイトでCSSレイアウトは冒険だね。
・・・・・・・・我ながらおかしな理屈だな。駄目だこりゃ

まあビジネス的にいえば、ばりばり非標準的デザインの方がウケる。

だからビジネスが絡むと面白くない。

そういえば、ティムたんが
http://www.w3.org/
http://www.w3.org/News/2004#item93
Tim Berners-Lee Receives Millennium Technology Prize in Helsinki

らしいよage

>>416
決めるのは間接的に客。
客の多数決　or　金払いの良さで来まる。
だから、
strict信者の使う金額＞どんなサイトでもいい奴の使う金額
になれば企業サイトはstrictになる。

ありえなさそう……。

>416
>417
>419
「制作を頼む人」が決定権を握ってるだけで、
strictである方が検索に有利、とかを知らしめることが出来れば、
出来れば変わるような気もする。

それだけの労力を払う気はどのデザイナもない、ってのが現状だけど。

>>413
今のread.cgiは
<dl>...<dt>4 ：<a href="mailto:sage"><b>Name_Not_Found</b></a> ：04/05/31 20:01 ID:???<dd>おｔ<br><br>
という感じのコード。
これをStrict-HTMLで書くと
<ol>
...
<li>
<dl>
<dt>名前</dt><dd>Name_Not_Found</dd>
<dt>mail</dt><dd>sage</dd>
<dt>日付</dt><dd>04/05/31 20:01</dd>

<dt>id</dt><dd> ???</dd>
<dt>本文</dt><dd class="text"> おｔ </dd>
</dl>
</li>
とかもしくは表と捉えてtableを使う形になる。
おそらく転送量は減らないかと。

そもそも構造化は文章に対してさまざまな意味を明示していくものだから情報量は増えるはず。
上手くいけば圧縮できるけど。

> 表と捉えてtableを使う

物凄い強引な解釈だな。

>2chをstrictにしたら転送量軽減とか何か効果あるかな
転送量軽減という意味ではそもそもマークアップ言語そのものが向いてない。
2chみたいな固定順で固定項目が出現する書式なら、そもそも要素名で内容をしる
意味が全くない。CSVで十分。

2chがHTML風のを利用している意味はひとえに「既存ブラウザ」との互換性のため。
（仮に100%2chブラウザ専用の掲示板になったらHTML風の記述そのものが無くなるはず）

Strictにすれば、一般的なStrictの恩恵は受けられるが、2chがその恩恵を
必要としているかどうか疑問だし、独自に2ch専用のDTDが書かれるなら
そもそもStrictで有る必要もない。

>>423
それって2ch以外の多くのサイトにも当てはまるよね。

>>424
　そう思う。例えば一部のブログやWikiなどは、サーバ内部のデータとしては
MySQLなどのDBとして文章を保存しておいて、リクエストに応じて
テンプレートにデータを流し込みHTMLを生成している。
　この場合、直接DBに直接SQL投げてデータを受け取る形式のビュワーがあれば、
途中でHTML形式に加工する意味がない。

　しかし、そうなった場合、「○○系Wikiブラウザ」「××系Blogブラウザ」
など専用のブラウザを複数使い回し、更に、異なる書式の文書に飛ぶ場合は
別ブラウザを一々立ち上げる、インストールされないと見られない、という
状態が発生する事になる。

　解決策は「フレキシブルなデータの出現順や意味付けに対応した統一的な
文書フォーマット」を（個々のケースでは不合理な部分があっても）採用する事。

　さらっと書いたが「『既存ブラウザ』との互換性」というがほかのデメリットを
帳消しにするほどのメリットを与えてくれる。

音楽CDが他のに取って代わられるのとHTMLがよりstrictな方向へ変わるのと
どっちが早いだろうか。

>>422
そうか？
<tr><th>名前</th><th>mail</th>日付<th>ID</th><th>本文</th></tr>
<tr><td>Name Not Found</td><td>sage</td><td>04/05/31 20:01</td><td>???</td><td>おｔ</td></tr>
...

ってな感じのほうが421のリストよりもわかりやすいと思うが。冗長なdtをなくせるし。

>>426
音楽CDの滅亡のほうが早いと思われ。

だいたい、移行期間6年くらいたつのに
新しくできるページですら、まだinvalidだったりloose.dtdだったりするんだから。

音楽CDがDVDになるのとか、MP3で聞くとかいうのは
もう始まっているし、来年からCD輸入禁止だから、確実に音楽CDの滅亡が先だな。

番号や日付や名前などを発言者に対する情報とみなして、
レスを定義とみなせば、

<dl>
<dt>1:<a href="mailto:sage">名前</a> :04/12/12 24:00 ID:???</dt>
<dd>レス内容</dd>
：
：
</dl>

として（現時点のマークアップと変わらない）、
上部で<style type="text/css">dt a{font-weight:bold;}</style>
としてあげればいい感じ。っていうより背景色以外スタイル捨ててもいいかも。

CDの次に来るのはEF、間違いない

>>426
>よりstrict
「より」ってどれくらいの「より」を考えてる？
blogとかWikiがはやる事によって、出鱈目なHTMLがよりstrictに成る事自体は
現在も進行中。あくまで「よりstrict」だけど。

世の中Strictに近づいていく人間もいれば、
全く進歩しない人間もいる。

>>429
でも同一IDの発言を抜き出すとかやりたいからもう少し構造化されてた方が使いやすいなぁ。

>>432
Strictになることは進歩なんですか？なんか不思議ですね。

>>434
ここはStrictの思想を「是」としているスレだから、
それに近づく事は単なる変化ではなく進歩と考えて良いかと。

>>435
そういうことじゃ無いと思うんだがなぁ。。。

>>434
（私にしたら）進歩ですよ。font要素とbr要素とimg要素とa要素さえあれば
満足してしまう人、それ以上を追求して広い概念や技術を知る人、色々いるのです。
Strictになるのは多くの人にとって、その人自身の個人的な進歩だと思います。
＃自らメリットを感じて取り入れる変化なので。

>>433
そうなると、em要素でクラス付けとか。単にem要素入れるとか。
構造化するとどうしてもファイルサイズデカくなるから、
構造化した情報欲しい場合は直接dat覗くとかしかないね。
よく言えばXML書き出しモードが欲しいところだけど（いらないかな？）。

＞よく言えばXML書き出しモードが欲しいところだけど
寧ろ基本的にXMLで出力して貰って、これを各2chブラウザがそれぞれの用途に
見合った変換をかけた方が便利な気が。

XMLマンセーしそうに毒されすぎ？

>>438
そうすると転送量が…

>>439
既存のHTMLでDlや、Table使うよりは転送量は多分下がるよ。

XML故整形済みにする必要があってその分転送量は増えるけど（終了タグの省略が出来ないなど）
例えば、要素名を全部1byteにしちゃうとかすれば最終的には転送量は軽減されるはず。
少なくともtable要素使うよりも絶対に軽くなる。

その上でXSLのファイルは基本的に固定しておいて、既存のブラウザでは
初回以外キャッシュを使って貰い、専用ブラウザでは内蔵して貰う方向にすればなんとか。
少なくとも負担になる程増加はしないはず。

Strictな人たちって、どういう系なんですか？ん？変な問いかけですね・・・

みなさんは、プログラマ系ですか？ん？変だ・・・

みなさんが使える言語とか教えて下さい。

？ん？変だ・・・

統計取った事無いけど、俺脳内では哺乳類が多いと思うよ。
魚類や鳥類でStrictな奴とか見たことないし。

え、マジ？

俺のずんどこべろんちょはStrictだよ。

>>441
C, C++, Java, Pascal, Perl, PHP, IA32 アセンブリ言語, sed & awk
あまり使えない。

>>440
よくXMLアプリケーション書くんだけど、XMLの問題はドキュメント要素を1つだけ必ず作らなきゃならないところ。
そうじゃなければただ単に追加モードでファイル開けば要素の追加できるし、HTTPでも範囲指定が簡単にできる。
ドキュメント要素の閉じタグの位置にシークしようとしても、閉じタグの後に空白やコメントが入り得るから結局ファイルをスキャンしないと閉じタグの位置がわからない。

>>441
確かにHTMLをメモ帳とかで書いてブラウザで見てるだけの人よりスクリプト使ってXHTML生成したりフィルタリングしたりしている人の方がStrict-HTMLの意義は理解しやすそう。

>>445
ずんどこべろんちょって何よ？とおもってググってみた。
ttp://images.google.com/images?q=%E3%81%9A%E3%82%93%E3%81%A9%E3%81%93%E3%81%B9%E3%82%8D%E3%82%93%E3%81%A1%E3%82%87&hl=ja&lr=&ie=UTF-8&sa=N&tab=wi
なんだかよく解らんが職場で吹いた。

>>447
えと、それが「現状に比べて」どんな欠点になるの？
現状だって、HTMLは(XMLよりもややこしい形で)パースされているし、
完全な独自フォーマットによる問題は >>425 が書いているし。

それにそもそも今の話題はデータの出力の話であって、
データのサーバ内での書式はXMLで有る必要性全然ないんでは？

こういうリクエストが過多なサイトの内部データにXMLは非常に怖いからヤメテクレ

僕は最近（ほんの3ヶ月前）HTMLを初めて知って、やっとPERLをオブジェクト思考チック
にモジュール化できるようにまでなりました。

それで、HTML,CSS,JavaScript,Perl,MySQLの順番で（結構デタラメですけど；）勉強して
Perlをはじめた頃（2ヶ月前くらい）に思ったのはHTMLって悩む必要のない簡単なもんだなーと
タカをくくっていたら、どうやら、そうでもないらしく、結構プログラミング言語とかと
共通？通じる部分があるみたいで（X系とか）、ここにいる人たちは他のスレのHTML製作者と違って
結構プログラミング系に強い人なのかなーと思って聞いてみました。

色々勉強することと、実践にいかす為の練習に時間が掛かって、まだX系への移行はできてませんので
中途半端な素人の中途半端な感想ですけど；

ところで、みなさんはデザイン学校とかで勉強されたんですか？僕はweb上のサイトでただですませましたけど。

>>451
俺も同じだよｗ
一番自分の中で詳しいはずのHTMLのくせに
本一冊も買ってないわ（XMLはニ、三冊買ったが）

XMLは本当に楽だから移行してみ。
あとその状態だとJavaも楽にできると思う。

>>451
なんというか、あなたは文章の書き方の勉強をしたほうが良いのではないかと。

>>451
俺は間違ったHTML本全盛の頃に、間違った本読んで２年くらい
レイアウト指定言語だと思いこんで間違えてた。
（それこそ、Hnは段落単位で文字を大きくできます。sizeと数字が逆なのが
統一感無くて不便です、レベルのトンデモ系）

ある時サイトのリニューアルをしようとおもって一念発起してCSS憶える事に
して勉強始めたら、（当時俺脳内では）HTMLのレイアウト拡張規格の筈なのに
理屈が合わない部分があまりにも多い。

これは一体どういう事だ、これじゃまるでレイアウト指定言語としてのHTMLを
否定してるじゃないか！　と思って（その通りなんだが…）、調べ始めて、
仕様にたどり着いて（ヘタレなので邦訳サイトで読んだが）Strictな概念にふれた。
あとはひたすら仕様を読むのみ。んで今に至る。

ちなみにこれから勉強するなら「今すぐ」XHTMLに移行しちゃう事をお薦めする。
「名前空間」のところでつまづくと止まっちゃいそうだが、とりあえず解らなければ、
仕様に従って呪文みたいに書いておけば間違いには成らないから。

>>449
私と440さんの間で話が少しずれていたようです。
440さんはHTML(read.cgiの出力)とXMLを比較しているのに対して私はdatファイルとXMLを比較してました。
また、私が2chに限った話をしていたのに対し440さんは一般のサイトについて話しているようです。

一般のサイトについて言えばHTML以外のXMLを使うのは確かに有効で、実際RSSなどが使われています。
そしてXMLを使えば独自フォーマットのものと比べてブラウザで直接見られる、その他XMLを扱うアプリケーションが使えるという利点があります。
IEやMozillaでも使うことを考えればXMLは十分良い解と言えます。

>>441
文系。C, Perlを少々。
少なくとも、StrictなHTMLだけなら誰でもできると思う。

>>454
名前空間ってのは
「鈴木さんちのhtml要素」「佐藤さんちのhtml要素」「W3Cのhtml要素」
ってのを区別するためだよNE。

初心者だと間違った思想のサイトに免疫ないからひっかかるよね。
俺はよくHotwiredのWebMonkeyを見て色々覚えたよ。

ウホ、乗り遅れた。
知らない香具師多いのかな。
以前転送量の問題で2chが危機に陥ったとき、
エロい人たちが色々試行錯誤してできたのが今の2chのHTMLなんだ。

ま、スタイルを維持した上での削減だからこそ、このスレ民にとっては無駄が多いと思えるのかもしれんが。

2chがstrictになるのは現実的でないよね。
運営側（特に管理人）が面倒くさがるから。

>>455
＞440さんはHTML(read.cgiの出力)とXMLを比較しているのに対して私はdatファイルとXMLを比較してました。
これはその通りなんだが。

＞また、私が2chに限った話をしていたのに対し440さんは一般のサイトについて話しているようです。
ハァ？

>>458
転送量に関しては既に >>438-440 で書かれている通り。

>>460
2chブラウザはCTV形式のファイルを直接読んでるよ。

よくしらいないんだけど、CSVじゃなくてCTV? って規格があるの?

俺は今のところは一介の個人サイトがXHTMLを使うメリットはない
（未対応のブラウザがある等のデメリットはありそう）と思ってるんだけど、
みんなはどんなきっかけでHTML(4.01 Strict)からXHTMLに移った？

>>463
XSLT使いたかった。

>>463
お約束の回答としては、終了タグの書き方がかっこいいから。

<ins>空要素の</ins>

>>463
ruby が使えるというのが個人的にいいなと思ったので、
これから書く文書は XHTML1.1 にしようかなぁと検討中。

今現在はすべて HTML4.01 です。

漏れは 間違いだらけのHTML辞典が始まり。
その後、CSSを勉強する時に、strictを理解した。
ついでにJavaScriptも勉強して、Perl,C/C++,Java...と勉強したので
strictである恩恵は、ただHTML書くだけの人よりは受けているな。

>>458
当時から2ch住人だから当然知っている。
そのときから かちゅ〜しゃ一筋でここまでやってきた。
スキンカスタマイズのおかげで、 2chもstrictですが何か？

>>463
XMLから変換するときXTでhtmlもーどだと
文字がすべて文字参照に…。それも原因だが、
俺が古いUAに対して冷酷な人間なのもあるかもしれない。
あとXMLの方がルールがはっきりしているし、
他の操作したいとき（しもしないが）、便利だから。
それに最新でｒｕｂｙも使えるとくりゃＸＨＴＭＬ１．１使います。

>>468
そのStrictなスキン興味ある。
漏れも一応Valid気味なスキンにはしてるけど飽きてきたので。

ついでに私のStrictなれそめはHTML勉強中にZSPCとか見つけたからかな。

更新情報のタグは<dl>の定義リストと<ol>の順不動リストとどちらがよいですか？

もうちょっと勉強することをお勧めする。

>>471
順不動リストってなんですか……。
普通は順序付きリストです。

>>473
逆順に出来ないということを皮肉っている、というのは考えすぎかな

>>474
おお、なるほど。
確かにHTMLの順序付きリストは融通が利かない。

更新履歴とかもそうだけど、新しいものが上にくるリストを作るときに、
olにそういう属性があればな、って思うよ。

俺は
<dl>日付（2222-2-22）</dl>
<dd>更新内容</dd>
派

あ、バカなことかいた
<dl> ⇒ <dt>ね。
もちろん二つの要素の親はdlね

すいません。順序付きリストでしたね。
更新情報の日付とその内容をマークアップするにはどちらが正しいのですか？

定義リストって基本的にその用語の意味を相手に教えるとか、辞書みたいな感じで
使うんですよね？これは上とはまた別の話ですが、例えばリンクa,b,cがあって、
それに対する説明を訪問者にしたい場合などは（アンカータグ省略します）
<h1>リンク</h1>
<h2>a</h2>
<p>ここはなんたらかんたらのページです</p>
....以下繰り返し....

というのと
<h1>リンク</h1>
<dl><dt>a</dt><dd>なんたらかんたらのページです。</dd>...以下繰り返し...

ではどちらが正しいのでしょうか？

>>476
逆順って、

<ol order="desc">
<li>hogehoge</li>
...
</ol>

みたいな感じか。

>>479
アンカー省略するとわかりづらいですね；
<h2>-</h2>|<dt>-</dt>
の部分にアンカータグを挿入です。

>>479
どっちも正しいよ。

ちなみに
dtに名前
ddにセリフ
とかもありなんだよ。

見だしってのは基本的には、
<h1>順不同リスト</h1>
<p>ここで順不同リストがこの文の見だしでおかしくないような文面を書く。</p>
だから、<hn>がリンクであること自体おかしいと思う。

見出しの後の文面は見出しを説明するんじゃなくて、どっちかというとそれに関連する
話をする部分だからね。

>>482
え？そうなのか？見出しにアンカーはありえないだろ？っていうか見出しは後の文面を
一言で要約したようなもんなだから、見だしがあって文面があるんじゃ変じゃないか？

>>483
難しいところだな。
見出しは、本文に対しての見出しであって、
見出しの説明が本文なのではない、ってことか。

ここら辺、って解釈が微妙な気がしなくもないな。

>>484
すまん。
見出し　−　本文
の関係を
dt　−　dd
に置き換えられるか、って質問だと誤読してた。

>>485
うん。そんな感じ。
とりあえず、見だしにアンカー振るのはまずいと思う。

>>471
俺としては、リンク先のことを相手に教えるなら
<dl><dt>リンク<dd>説明
だね。

そんで更新とかの部分は逆に日付を見だしで、以下その内容でも、
<li>でやってもいいと思うよ。

>>487の
> とりあえず、見だしにアンカー振るのはまずいと思う。
はちょっと語弊があると思うから補足な。
見出しをアンカーとして使うのはまずいが、見出しの語句にアンカーを振ること自体は問題ない。

関係ないけど、脱テーブルレイアウタでｽﾄﾘｸﾀﾝになった漏れは、div厨にならずdl厨になってしまった。
汎用性高すぎる気もするなぁ。

漏れが初めて html 書いたときにはまだ大学生協に、html について書かれた
本がなかった覚えがある。駅前の本屋にはあったよ、なんて。

hn+p と dt+dd では順序が違うんだよな。
p を要約したのが hn であり、dt を説明したのが dd であり。みたいな。

<abbr title="朝シャンプーする">朝シャン</abbr>
朝<abbr title="シャンプー">シャンプー</abbr>
どっちが正しいんでしょうか。

>>489
そうか・・・・・？
HTMLと本は微妙に違うからあれだけど、
ちょっと本で言ってみる。
まずHTMLのアンカーは本では目次とかで
なんｔかの話・・・・・・？？ページ
かんたらの話・・・・・・？？ページ
となってる部分で、ページ数が振ってあるとこにあたると思う。

で、見出しはあくまで本文に対する見だしだから、例えば
なんたらの話・・・・・？？ページ
 うんたらかんたらについて語っています。
の場合は「なんたらの話」っていう部分は見だしではなくて、リスト的なものだと思う。

とか考えてると、見出しの語句にもアンカーはよくない気がする。

>>494
<h3>僕と<a href="kondou.html" title="近藤君のプロフィール">近藤君</a>の21日の食事</h3>
<p>その日、僕と近藤君は〜

こういうアンカーなら問題ないでしょ？
＃例が稚拙ですまん。

「hn要素にa要素が内包できない」という誤読を避けるために書いただけ。

>>493
<abbr title="シャンプーを朝に行うこと">朝シャン</abbr>
じゃないか？

>>496
シャンだけで独立してないから、やっぱりそっちですよね。
つか、徹マンとかカキコとかにabbr要素を振るのは異常かな？

商業web制作（企業サイトとか）でストリクたい！って頑張ると、
ほとんど箇条書き形式のプレゼンテーションみたいなモノなので、
必然とリスト厨になっちゃいました。

<abbr title="ちゃんと">ちゃん</abbr>・<abbr title="リン（ｒｙ

＞ワタシはチンコおったてながら<abbr title="朝シャンプー">朝シャン</abbr>した
これでいい気が。

>>497
文脈から判断できない場合、その略語を知らない人に知ってもらいたい場合、
何らかの理由でコンピュータに判断させたい場合にabbr用いるといいかも。

>>498
企業だとコンテンツのほとんどが説明だの箇条書きだのになるよなぁ。
正しく書いてるつもりなんだけど、リスト厨なのかな、ってふと疑問が浮かぶよね。

俺のとこも異様にdl要素。

なんというかCSSとかStrictとか始めるようになってから
table要素が消えてdl要素やリストが増えた。
まあ、tableはわかりにくいからいいか…

>>500
そうなんだよなぁ。必要なものにつけれ、ってことなんだろうけど、
偏執狂なんで、つけるとなると略語全部に！とか異様な愛情を示してしまう自分がいるので怖い。

>>495
>「hn要素にa要素が内包できない」という誤読を避けるために書いただけ。

そうだよね、よく考えたら一応W3Cは<hn>要素にa要素を内包することを認めてるんだよね。
そのW3Cの考え方からすると、見だしに丸々アンカー振るのも別に悪くないよね。

Strict自体がW3Cの考え方なんだから、W3Cが認めてるならオールokって事になるね。
あまり本とかで考えないで、素直にW3Cの考えを教科書にするべきだね。

>>504
そしてw3c信者になっていくか・・・・・・

>>504
いやいや、そうじゃなくてだな
タイトル　−　説明
を
hn　−　p
にしていいってわけじゃなくて（その部分については>>483の意見に同意）

「hnにｱﾝｶｰは含められないのか」と新参（最近多いみたいだし）が勘違いしちゃダメだとおもっただけなんだよ。

＃さっきの例文は、見出し以下の文章は「近藤について」じゃないし、>>483の理論には反してないと思うんだけど。

音声ブラウザで考えてみたら？
<hn><a>Strictについて</a></hn>
これじゃあ変な感じに聞こえるでしょ。
基本的に音声ブラウザで考えて聞きやすいならそれは正しいマークアップなのかもよ。

>>507
これは誰に言ってるんだろう。

＞これじゃあ変な感じに聞こえるでしょ。
別に。

>>506
><h3>僕と<a href="kondou.html" title="近藤君のプロフィール">近藤君</a>の21日の食事</h3>

近藤君にアンカーつけるとなると、そこに注釈でページ数を振るみたいな感じか。
・・・ていうか近藤君についてのアンカーは見出しでやらなくてもいいよね。
まあ近藤君は例だからそんなこと言っても意味ないけど、他に見出しの一部にアンカーを振りたい状況ってあるかな？

>>508
本文がScrictについてなのに一体どこに飛ぶつもりだよ！って思った

>>509
<hn><a>私が変態と巨大掲示板群で名指しで言われたこと</a>についてのあらまし</hn>

似たようななもんか

>>511
うん。見出しでアンカーにする必要性が見つからない。
ていうか、俺の意見は一体どっちなんだろう・・・・

>>509
<h3><a href="foo.html">電磁波についての考察</a>への反論</h3>

ダメかな。

>511
うお、タイピングに梃子摺ってたらかぶった

>>514＝>>513です。
>>511すまそ

>>511
ワラタw
何をして変態って呼ばれたの？

リンクの説明についてだけど、<a>要素で括る文字列がそのまま説明であるのが理想だけど
サイトメニューとかではどうしても一言になっちゃうから、<a>にtitleでも付ければいいけど、
それって音声ブラウザには有効だけど、視覚系ブラウザにはイマイチなんだよね。パッと見で理解できない
っていう。

で、トップページとかサイトマップページとかで、リンクの先について説明したりするんだけど、
そのときに<h>じゃなく<dl>を使うべき。って上で誰かが言ってたことを繰り返してるだけぽ・・・

>>516
あのね。その話は決着ついてると思うの。

今話してるのは、
「Hnにa要素を内包させる」のはどうか、って話。

>>512
<a href="公式サイト">本のタイトル</a>の感想
とかは？

>>513
う〜ん。かなり良いほうだけど，本文で
<p>
何やら最近の体の調子が悪いなぁなんて思っていると産経新聞の片隅に
東京大学理学部1年生近藤君が書いた<a href="hoge.html">電磁波についての考察</a>
という論文の一部分が載っていました。なにやら電磁波が人体に与える影響を
うんたｒかんたら・・・
</p>

みたいに本文で初めに出てきたときにアンカーするほうが自然じゃないかな？

>>497
読み手が100%その略語を、略語のまま理解出来るならabbr無くても困らない。
ちなみに、読み手には翻訳サービスのエンジンとかも含まれるので注意。

また、今のHTMLを解析するUA（検索ボットとか）のレベルを考えると、
文脈判断も期待出来ないので、（人間が）「読めば解るだろう」と言うのも
期待出来ない場合がある。

正直殆ど日本語解らない外国人が辞書を片手にどうにかなるかどうか、
あたりが理想的な判断の基準点な訳だが…俺自身のサイトは
略語以前にスラング、2ch語バリバリなので何とも。

一応理想だけ偉そうに語る方向で。

どっちでも構わん

>>517
結局見出しに出る単語は通常は本文でもでるから、本文でその単語なりなんなりに<a>を振るのが
いいと思う・・・・

朝からシャンプー

なんだこの伸びは

>>521
ただ問題は検索ボットの中には<hn>に高得点をつけるものがあるということだよね。

俺なら両方アンカーさせるなあ…

今日はやけに流れが速いな。

XHTML1.1までのセマンティクスだとHnはセクションの開始だからセクション全体とリソースを関連付けたいときには見出しからリンク張るしかないんじゃない？
<h1><a href="..." rel="alternate">○○</a></h1>
とか。

というか何で>>483はそんなに見出しにアンカー付けることを拒んでるんだ？
新しいスタンダードでも確立したいのか？

実はアンカーって<hn>に関わらず正しい使い方をしようと思ったら結構難しいのかも

>>527
どうするのが一番正しいマークアップなのかなって話。

MovableTypeなんかだとデフォルトでhnに各記事へのリンク貼ってたりするな。

>>518
見出しにそのリンクがあったほうが辿りやすい。
自分の場合は時系列で読むから、早い段階で元の話題に辿り着けるのはありがたい。

<dl>
<dt>メニュー</dt>
<dd>a</dd>
<dd>b</dd>
<dd>c</dd>
</dl>

こういうことやってるサイトがあったんですがありなんですか？
Strict宣言してるサイトです。

>>532
アリアリ

ねーだからテンプレサイトを。

俺はこうしちゃう。

<dl>
<dt>メニュー</dt>
　<dd>
　　<dl>
　　　<dt>a</dt>
　　　<dt>b</dt>
　　　<dt>c</dt>
　　</dl>
　</dd>
</dl>

dl使い杉……。

<nl xmlns="http://www.w3.org/2002/06/xhtml2">
<li>a</li>
<li>b</li>
<li>c</li>
</nl>

>>535
素直に無視するかhn使いなさい。

>>535
え、dtに対するddが出てこなくてもいいの？

漏れはこうするけど。

<dl>
<dt>メニュー</dt>
<dd>
<ul>
<li>a</li>
<li>b</li>
<li>c</li>
</ul>
</dd>
</dl>

<h2>メニュー</h2>
<ul>
<li>a</li>
<li>b</li>
<li>c</li>
</ul>

<ul id="MENU">
<li></li>
<li></li>
<li></li>
</ul>

<h2>The menu list</h2>
<h3>The first item of menu list</h3>
<p>a</p>
<h3>The second item of menu list</h3>
<p>b</p>
<h3>The third item of menu list</h3>
<p>c</p>

Wikiっぽいもの作ってみました。
http://eseinaka.s59.xrea.com/w2c/ez-markup/ez-markup.cgi

マークアップの規則は
http://eseinaka.s59.xrea.com/w2c/ez-markup/rule.html
をご覧ください。意味不明だったらごめんなさい。

>542
とりあえず文字コードを。

こうしてまた規則が増えるのであった。

>521
アンカーのために本文を書き換えるのは本末転倒じゃまいか。

>>531
正しいマークアップと利用者の使い勝手は一緒なのかなぁ？

いつからそれが正しいマークアップになったんだ。

つい昨日。

>>542
全角スペースで始まったらpと言うのは原稿用紙の書き方に慣れ親しんだ
日本人としては直感的でわかりやすいが、見出しを"＜"のネストで表現するのは
どうだろう。

というか、h1とかh2を解ってる奴なら直接タグを書いた方が早そうだし、
解ってない奴だと"＜"をなんでこんなに沢山書かなきゃいけないかも
やっぱりわからんのでは無いだろうか。

>542
その独自マークアップの仕方覚える労力で、HTMLのマークアップ覚えられそう

どのように書けばマークアップできるか、じゃなくて、
どうマークアップするか、なんだよな。

>>551
マークアップランゲージであって、データ構造表現ではないということですな。

使いづらいね。
使わないからいいけど。

>>542
「マークアップの規則」、ひどすぎる。文字コードについてもうちょっと勉強してきてくれ。
「全角スペース」(和字間隔のことか?)とか ｢￥｣ とか、そもそもJIS X 0208の方を
例示してるのは意味があるのかとか、ツッコミどころが多すぎる。

と書いたが、>>554 の意味も理解できないだろうから、別スレッドで
聞いてくれ。
http://pc5.2ch.net/test/read.cgi/unix/1012333862/

>>554
浮世離れし過ぎだよ。
「和字間隔」より「全角スペース」ほうがずっと分かりやすい。

>>556
そんな変な言葉使ってて、よくStrictがどうこう言えるなぁ。

>>557
これからそのスレ読んでみるよ。勉強する機会をくれてありがとう。
でも、「和字間隔」のことを「全角スペース」と呼ぶ人が多いことくらい
あなたも知ってたほうが良いよ。

>>558
> でも、「和字間隔」のことを「全角スペース」と呼ぶ人が多いことくらい
> あなたも知ってたほうが良いよ。

多いかどうかなんてどうでもいいよ。
「HTML文書なんて適当に書いてるやつの方が多い」って言ってるのと同じ。

と言ったところで、周りは今後も全角スペースと言いつづけるでしょう。

>>560
もう言い訳はいいから。あっちのスレッドで分からないことを聞いてくれ。

>>561
使ってる人が多いから文句言うな、と言うつもりはないですよ。
よく使われる言い方に関心がないなら、それで良いです。

以降 100 レスくらい、多数決をとるスレとなりました。

「全角スペース」派 -> ○
「和字感覚」派 -----> ●

名前欄でどうぞ。

●使えなかったらどうしよう… orz

以上で集計終わりです。
それでは、いつものくだらない議論をどうぞ。

>>563
和字感覚派は一人もいません。

>>562
この馬鹿は >>559 で書いたことも理解出来ないのか。

「fontやbigなどの要素は使わない方がいい」
「でも使ってる人はたくさんいる」

っていうのと同じくらい話がずれてるんだよ。

>>565
以上も何もスレ全域が(以下略)。

英文の最後に打つのはピリオドだけど、
それだけを取り出して、「ドット」と呼んでも差し支えはない。
「英文の最後にドットを入れる」は「ドット」というものを挿入ことを示している。
ただ、
「英文の最後に入っているのはドット」というと名称を間違えているのでダメ。

同様に
「和文の段落の文頭にあるのは全角スペース」というと語弊があるが、
「和文の段落の文頭に全角スペースを入れる」は問題ない。

と思うんですがどうか？

308 名前：Name_Not_Found[] 投稿日：04/06/18 15:01 ID:25OstAbM
おい、信者ども、
ストリクトでもフレーム使えるじゃないか！！

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang='ja'>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=Shift_JIS'>
<title>タイトル</title>
</head>
<frameset rows="64px,*" frameborder="0">
<frame title="タイトル" name="bar" marginheight=0 marginwidth=0 noresize src="title.html">
<frameset cols="*,530px" title="" frameborder="1">
<frame title="メニュー" name="menu" marginheight=0 marginwidth=0 frameborder="1" src="menu.html">
<frame title="メイン" name="main" src="main.html" marginheight="0" marginwidth="0" frameborder="1">
</frameset>
<noframes>
<body>
フレーム対応ブラウザで閲覧して下さい。
</body>
</noframes>
</frameset>
</html>

これはＩＥで動く、ネスケでも動く、OperaでもMozillaでも動く。
動く以上は正しいんだよ。それに勝るものは無し。
俺はだれが何と言おとうと、この素晴らしいストリクトなフレームを使い続けるね。
おまけに「ストリクトなフレームのホームページ」を作る方法の解説ページ
も作ろうと思っている。もちろん、解説ページもストリクトなフレームの
ホームページだ。

ﾜﾗﾀ

>>570
動けばいいってのは勝てば官軍に通ずる思想だね。

>>567
>この馬鹿は >>559 で書いたことも理解出来ないのか。
頭いいのに幼稚だね。自分の言うことを理解してもらえないと、カッっとして相手を
侮辱する。「こいつ馬鹿」とかは心の中で思っていなよ。

>>569
馬鹿じゃねえのおまえ！なんだよ
>「英文の最後にドットを入れる」
って！アフォ？ドットはURIとかグラフィック分野の言葉だろ。

>>569
話を変えて、別の方面にしたか。
あんなメタ議論(議論でさえないが)は不毛だから、賢明ではある。
続きはこちらで。
http://pc5.2ch.net/test/read.cgi/unix/1012333862/

>>567
うん、話がずれてるみたいですね。

私は、
あなたが「和字間隔」は知ってるのに、「全角スペース」は知らない
ということを問題にしてるよ。

あなたは？

>>572
「馬鹿」という言葉を使うと過剰反応する人がいるね。
馬鹿を馬鹿と呼んで何が悪いんだか。

>>574
そういう思考停止はみっともないからやめてくれ。

>>570
のどっかのスレの308は恥ずかしい思いをしてるんだろうね。
そもそもDTDがなんであるかなんて関係ないのにね。

>>575
誰に悪いって言われたの？

>572
> って！アフォ？ドットはURIとかグラフィック分野の言葉だろ。
いや、「名称」について、で御座いますよ。

>573
> 話を変えて、別の方面にしたか。
いや、僕、さっき起きたばっかりなので、今参加したばっかりですよ。
確かに独自の仕様についてここで話すのはあれですね。

>>577
W3C信者に怒られそうなことを書くスレ
http://pc5.2ch.net/test/read.cgi/hp/1071673655/308

ネタだろ。笑ったけど。

>>580
なるほどあそこか。
あそこはある程度の知識がないと良レスたりえないから難しいよ。

つか、スレ違い。

文字をHTML/XHTMLでどう扱うかはスレ範疇だが、特定の文字コードの
名称がどうであるかはこのスレ的にどうでもいい。

勿論、言葉が通じないんじゃ話に成らんが、「全角スペースって和字間隔の
事だよね」と合意が取れれば、それ以上のいらん。

っていうか和字感覚厨はカエレ

お互いに同じものを指してるってことは話が通じるってことだろ。
「俺の方がより一般的な言い方をしてるんだ」とか、あまつさえ「それに従え」ってのはどうなのよ？

>>579
> いや、僕、さっき起きたばっかりなので、今参加したばっかりですよ。
> 確かに独自の仕様についてここで話すのはあれですね。

あぁ、別の人か。そもそもスレッドが違うんだよな。
「独自の仕様」を公開して意見を聞きたいなら、Wikiスレッドあたりで聞くべきだし、
「文字コード」の話をきちんとやりたいなら、文字コードのスレッドで聞くべきだ。
だいたい、ここは「Strict-HTML スレッド」なのに、loose.dtdを使ってるのはどういうこと
なんだ。おちょくってるのか?

フレームセットの名前空間を呼び出すとか本末転倒なことしたら
ストリクトでフレーム使えるのかな？

>>586
そもそも名前空間にstrictもフレームセットもないのでDTDとその挙動を定めた
仕様依存。

で、今のところstrictでフレームセット使えるメジャー仕様ってのは無いはず。

ルート要素が XHTML2 の名前空間の時に、現行のXHTMLの名前空間のフレーム使うと…どうなるんだろう？
憶測で書くが、多分XHML2 の Body 要素の表示が優先される…のかなぁ。

>585
> あぁ、別の人か。そもそもスレッドが違うんだよな。
すまん。一応、>>579で
> 確かに独自の仕様についてここで話すのはあれですね。
とスレ違いを認めたんですけどね。

>>588
元々の >>569 は「文字コード」の話なので文字コードのスレッドへ。

> > 確かに独自の仕様についてここで話すのはあれですね。
> とスレ違いを認めたんですけどね。

「独自の仕様」はWikiあたりのスレッドへ。
どうもごっちゃになってるみたいだからきちんと分けて書いたんだけどね。

p要素にlang属性与えて、title属性で訳を書こうと思ったんだけど、
lamg属性と、title属性の言語指定が違う、と言われちゃうんです。
どういうマーク付けが正しいんですかね？


>>589
じゃなくて、
「よく考えずに書き込んだ。ごめん」
ってだけだよ。

>>590
文章や、訳を書く理由によると思うんだが、 (langやtitleなど属性の事は考えずに)
p要素の内容として両方とも書いてから、それぞれの言語の範囲にspanでlang属性
つけるんじゃだめ？

>>591
やっぱそれしかないですね。

漢文書いてるんですが、「テキストが日本語」とか言われるんで文字コードスレ行って来ます。

>>590
要素の内容及び各属性間で言語がまちまちである場合
lang/xml:lang属性の機能はそれに全く対応できない。
漏れだったら原文と訳文にそれぞれ一続きのリソースを用意して
(別に同一HTML文書であってもいいと思う)
対応する段落どうしをリンクさせるとかで良しとするかな。
# できないことは正しくしようがないので。

>>593
ありがとう。なんとなく理解できてきた気がするので引き続き勉強します。

つか、文字コードスレない気がするんだが……

あー、えっと念のためにいっとくとlangとコードは
「全く無関係」だぞ。以下はそれぞれ正しい。
<p lang="en">マイ ネーム イズ ジュンイチロー　コイズミ。</p>
<p lang="ja">Watashi no namae ha Koizumi Junichiro desu.</p>
使ってる言語が問題なんだ。表記しているコードは関係ないんだ。

>>595
うん。多分混同してる。
というか、
＞LANG 属性は `zh` ですが、テキストが日本語のようです。
はどう対応すればいいのか、さっぱり。

＞ここでは日本語の指定 LANG="ja" や LANG="ja-JP" 以外が指定してあるときに、テキストに日本語が含まれているかどうかを調べています。
ttp://openlab.ring.gr.jp/k16/htmllint/explain.html#lang-pcdata

漢字で書いてるのに「テキストが日本語のよう」と言われても、と。

その説明文の下の方に
＞本来、言語の指定と文字コードは無関係なのですが、
＞Another HTML-lint は主に日本語で書かれたHTMLを対象にしているので、
＞このように文字コードによる判定を行なっています。
ってかいてあるっしょ。

なので、langコードに従った、正しい"言語"をつかっているなら、
警告が出ても問題ない。

スレ勢い33.22だってよ
こんな過疎スレには珍しいことだ

投稿する前に自分の書いた文章を一度読み直せ、な、お願いだから

>>597
理解できました。どうもです。

>>598
？
なにその数字。どこに出てるの？

>>600
脳内にはじき出された数値だろ。気にすんな。

>>600
新着レスの数が関係している気がする。

日あたりのレス数のことでないかね。一部の専ブラで見れるはず。

はっきりって、スレが早かろうが遅かろうが、どうでも良い。

しかし、
＞投稿する前に自分の書いた文章を一度読み直せ
には同意する。

ただ、萎縮して質問せず、結局変なマークアップ憶えるよりは
質問者、回答者お互いのために質問はして欲しい。

聞くは一時の恥聞かぬは一生の恥というしな。
聞いたら末代までの恥って事もあるが。

>>543
言わんとしていることがわかりません。言葉を補ってもらえると助かります。

>>550
HTMLを覚えるのを怠けるのが目的ではなく、簡単にHTML文書を作るのが目的です。

>>549
> 見出しを"＜"のネストで表現するのはどうだろう。

分かりやすくありませんか？よくある*よりは分かりやすいと思います。

> というか、h1とかh2を解ってる奴なら直接タグを書いた方が早そうだし、
解ってない奴だと"＜"をなんでこんなに沢山書かなきゃいけないかも
やっぱりわからんのでは無いだろうか。

それを言ったらWikiを否定してしまうと思います。

>>585
> 「独自の仕様」を公開して意見を聞きたいなら、Wikiスレッドあたりで聞くべきだし、

このスレの前の方でWikiに関する話が出ていたので公開してみました。

> だいたい、ここは「Strict-HTML スレッド」なのに、loose.dtdを使ってるのはどういうこと

HTML 4.01 Strictを宣言するようにしました。

>>605
スレ違いだし、他人の意見聞く気も無いようだし、ここで何がやりたいんだ？
うざいから出て行け。
ついでに、現在の使い方はXREAの規約違反のはずだぞ。

>>605
> 言わんとしていることがわかりません。

エンコード明記せよって話じゃないのかね。

> HTMLを覚えるのを怠けるのが目的ではなく、簡単にHTML文書を作るのが目的です。

それでも覚える労力は必要だろうし、補完機能のあるエディタ使えばいいではないか。
そもそも本来のマークアップを覚えているのに別の方法を覚えるメリットは？
簡便さでは従来のテキストエディタには太刀打ちできんと思うが。

> 分かりやすくありませんか？よくある*よりは分かりやすいと思います。

主観的過ぎ。

お前もともと Strict スレの住人じゃないだろ？開いた口が塞がらないレベルだ。

他人に使ってもらうという態度じゃないよね。

別に態度はどうでもいいんじゃ

>それを言ったらWikiを否定してしまうと思います。
ええと、なんか知らない前提があるみたいなんだけど、
「Wikiを否定したらあかんの？」

>>610
Wikiを否定じゃなくて、Wikiのシステムを否定といいたかったのだろう。
まあ、でも＜＜＜＜って書いた分閉じなきゃいけないのは面倒。
初心者用に作ってあるのか、それとも簡単なHTML文書作成のためなのか、
はっきりしていない気がする。

>>606
> 現在の使い方はXREAの規約違反のはずだぞ。

確かにそうでした。指摘ありがとうございます。
トップページがなかったので作りました。
また、広告の貼り方が間違ってましたので直しました。よってStrictなHTML文書ではなくなりました。

>>607
> エンコード明記せよって話じゃないのかね。

スクリプトが吐くHTML文書の文字符号化方式はHTTPヘッダで指定しています。

> > 分かりやすくありませんか？よくある*よりは分かりやすいと思います。
>
> 主観的過ぎ。

主観でした。

>>611
> まあ、でも＜＜＜＜って書いた分閉じなきゃいけないのは面倒。

なるほど。閉じても閉じなくてもいいようにすればより良いですね。
指摘ありがとうございます。

そして都合の良くない指摘はスルー、と

>>604
お前そんな事言ってて恥ずかしくないの？

lpolun

>>615
ガッ！

>>615
> lpolun
さっきからなんて読むのか気になってしかたがないのだが。
もし良かったら教えてくれまいか。

どうでも良いが、「和字間隔」って何だ、と。
勿論例外はいくらでもあるが、四字の熟語は言ってみれば余所行きの言葉であって、
外来語言い換え何とかにも同じことを言いたかったんだが、
本気で漢語の熟語を作って普及させたいなら二字にするべきだ。
二字なら普及するというわけでもないが、少なくとも四字じゃ望みは無いに等しい。
「和白」とか「和間」とか、思いつかなかったのか？＞誰

>>618
とはいえ、今や固有名詞だからなぁ。

>>618
略した呼び方を広めれば（そしてそれが広まれば）それはそれで定着するかと。

>>618
どうでもいいなら、すれ違いのネタをいつまでも引っ張るな、と。

オレモナー

とりあえず、ここまで読み飛ばしたと。

>617
dir="rtl"

>>623
余計にわからん

ぬろぷるだろ？

nullpoか？

>>542の考え方を否定するつもりはないが、
WikiってのはHTML4.01のマークアップ済文書をそのままで書けないものなの？
もしもWikiの技術仕様としてその使い方が不可能であれば仕方が無いが、
既にStrict-HTMLを使える人間が集まっているのに、
「初心者向けのマークアップ手法」を用いているのは厳しい。

つうか、誰のための何のためのシステム？
このスレで公表することに何の意義があんの？

>>612
いや、HTTPヘッダーでも指定されてないよ。

>>628
システムを公表する、という意味ではなく初心者向けまとめサイトを作ろうって話じゃなかったっけ？

とりあえず全角記号は打ちづらい。SKKでもMS-IMEでもローマ字カスタマイズすれば大丈夫かもしれんが。

誰でも編集できるようにするのなら、
アップローダかanonymousFTPでも良いかも。

まとめサイト作る前に Wiki の Strict 化ですか。
お前ら何年かけてまとめるつもりだｗ
あのにFTP でもいいけど、バックアップとれるシステムじゃないと怖いね。

このスレをまとめただけでは Tips にしかならないので、
初心者にたどり着いてもらいやすいリソースになるか不安。
俺は Wiki でいいと思うけどなあ。
リソースそのものを編集するんじゃなくて、原稿を集めるだけの話なんだし。
原稿が推敲されたら、それをマークアップし直すのなんてここの住人には屁でもないでしょ。

っていうか、「まとめサイト」作るって話だったの？
単にWikiつくってみましたー、って奴が変な仕様をさらしただけじゃないの？

仮にまとめサイト作るって事なら、この板があるのに、わざわざWikiが必要な
理由がわからん。
原稿はこのスレに書き込んで、まとめサイトを作る奴が編集人として、
自己の責任で勝手に編集してまとめればいい。

同じStrictでも過去の例を見るまでもなく正解が一つではない事があり
論争も起こったりする。Wikiなんか作った所で、このスレ以上でも以下でもない
場所が出来るだけ。リソースが分散するだけ初心者をとまどわせるから
やらない方が良い。

既にあるみたい……。
ttp://suika.fam.cx/~wakaba/-temp/wiki/wiki?Strict%2F%2FFAQ

誤解を招くかも知れないと思ったので、自己レス補足

Strictの解説、手引きはWikiなんかでやるもんじゃない！
と言ってるんじゃなくて、
2chのスレのまとめサイトはWikiなんかでやるもんじゃない！
と言うのが俺の主張。

Strictの手引きサイトが唯一のこすれだけであれ、
なんて思ってないし、Wiki自体にも反対じゃあない。

てゆーか、初心者向けの情報提供の場として、どういうチャンネルが適切かって話だろ？
どんな手段でも一長一短あると思うので、Wiki だけじゃなくいろんな手段を考えていけばいいと思うが。

「誰が文章を書くのか」ということを考えた場合、集団執筆を前提とするなら Wiki はメリットが多い。当然デメリットもある。
誰か一人が中心人物としてがんがる、というのなら、未完成原稿のページに掲示板を置いて他者の意見を募ればよい。

んで、意見交換ならこのスレでいいじゃないかという話になるのだが、
初心者がこのスレを発見しても、このスレだけで Strict を理解できるとは考えにくいので、
結局外部に何らかのリソースが必要だと思うぞ。

＞てゆーか、初心者向けの情報提供の場として、どういうチャンネルが適切かって話だろ？
最近の流れで、お前以外がその話をしているソースキボン。

そんで考えたのだが、どこかで FTP アカウントを自由に切れる鯖があれば、と思う。
やってみようと思ったやつが、FTP アカウントをもらって勝手にやる。
手段は何を使ってもよい。Wiki だろうが何だろうが。

こうすると、スレ住人それぞれが考えた「ベターだと思う手段」が一カ所に集まって比較が容易。
で、書く側は他の FTP アカウントにある文章を自由に取り込めることにすればいい。
これなら自分で全部の文章を用意しないといけないという負担が軽減される。
ま、頭数が揃わないと難しいけどな。

俺が借りてる有料共用鯖は、俺のドメイン領域内で自由に FTP が切れる。
データベースへのアクセスに俺の ID とパスワードが必要だから、Wiki などの導入には一手間いることになるが、
こういう案はどうでしょうかお前ら。

>>636
というよりも、俺が勝手にそっちに流れを持って行きたいのだと告白しておく。
以下は勝手に姉妹リンク。
　初心者が好むHTML解説サイトって？
　http://pc5.2ch.net/test/read.cgi/hp/1086682230/l50

別にまとめサイトでもいいんだけど、それは俺があんまり萌えないだけ。

やりたい奴が勝手にやればいいんじゃないの。
やりたがっている人が多数いるように見えないけど。

ここですら他人の話を聞かず、流れを誘導出来ない奴が、
Wikiを立ち上げて一体何をしようと言うのだ。

このスレの流れと無関係にお前が勝手にやりたければ、
このスレとは無関係にお前が勝手にやれ。

禿げ同

っていうかここでやってもいいような…

http://wikibooks.org/wiki/Main_Page:日本語

まとめは各自でということで終了

まとめたい奴がが勝手にまとめるのは構わん。
ということで次の話題↓。

話題を戻すけれども、まとめたいやつが勝手にこのスレをまとめたら
既に存在するどこかのサイトのバックアップみたいなことになってしまう。
だから(やるとしたら)このスレみんなで相談してまとめていかなきゃいけない。

>>645
なってしまって結構です。
関係ありませんから。

何故こんなに可哀想な流れなんだ？

じゃあ初心者の質問にはその都度断片的に答えていくということでOK?

つーか必要ならテンプレに軽く入れたら良いだけだろ。

すとりくたん(;´Д｀)ﾊｧﾊｧ

そろそろ隔離スレ立てようか？

ﾌﾟ
http://pc5.2ch.net/test/read.cgi/hp/1067082048/299

どうでもいいけど、バカばっかり増えたな。

近年まれに見る糞スレだ

こんなスレに書き込む奴の頭の中を見てみたいもんだな。

我ながら反発されっぷりに笑ってしまった。
反応を探りたかっただけなので、準備中の解説サイトを書き進めることにするわ。
スレ汚し須磨。

>>655
>>655

あーあ、このスレはネタ切れの閑古鳥の鳴いている感じが好きだったんだが、
ついこないだhp板にきたような連中が増えたせいで大分ひどくなったもんだ。
まぁstrict人口が増えることは良いことだが

Strictな考え方。
１．まずそのページに書きたい文章を用意。
２．画面の事を100%全く考えず、意識もしないで論理的にマークアップ。
３．headに<link rel="stylesheet" type="text/css" href="hoge.css">をいれる。
４．その後は絶対にHTML側をいじることなく、CSSファイルだけさわってレイアウトする。
（タグにクラス、IDをつけたりはアリだけど新しいタグを入れるのは絶対に禁止）

↑基本だけど、これできる人ここにいる？後からdivとか追加してない？
ブラウザの実装を考えて"CSSレイアウトのため"に何か新しいタグを追加してない？

っていうか追加しないとできないんだけど、それは何故？
１．俺がしょぼい
２．W3C|CSS|UAがショボイ
３．その他
その他の場合は詳細も教えて下さいな。

>>659
明らかに２だろ。

＞４．その後は絶対にHTML側をいじることなく、CSSファイルだけさわってレイアウトする。
どんなレイアウトにしたいのかによって1にも2にもなる。

マークアップで明示した部位にしかスタイルを適用できないという構造的な制限でしょうか。

スクリプトでツリーを弄る前と後でValidでなければなければならないというのは良く言われるけど、XSLTに関してはそういうの聞かないねぇ。
数スレ前にも確か出てたけど特に議論れてなかったし。

>>659
XSLTでやるから、気にしないでマークアップと同時に文章書きなぐる。

すべて一からやるときは、まずXML書いてXSLT書いて、変換した後、
CSSでスタイル付けしていく。そのとき、許せる範囲ならいじってしまう。

CSSで駄目だとわかったら将来に期待しつつ諦めて別の道を探す。

UAもしょぼいが、CSSもしょぼい。

まずCSSはショボイ。
データの構造をそのまま見栄えの構造に流用している。
そしてUAもショボイ。
もうちょっとちゃんとSVGとかサポートしろやゴルァ。

そして>>659もショボイ。
XSLTを使う手がある。XSLTでXSL-FOを生成じゃなくてXSLTでXML+CSSを生成ならcss1でも大分いろいろできる。

>>659
3だと思う。特定のレイアウトのためのCSSを考えるんじゃなくて、
要素ごとに適切なスタイルを指定するという方向でやってみたら？

XSLTのことなんだけど、
結局XSLTで変換した文書のなかに
CSSでレイアウトするための構造が入ってるんでないの？

XSLTつかってテーブルレイアウトにしてたりして。。

それはこのスレ的にいえば、抹殺だな。
XSLTは変換などのコストを考えなければとてもいい手段。

っていうかXSLTとか一括して扱える開発環境みたいなのこの世にあるのかな？無料ならほしい。

>>665
見栄えの構造からデータの構造が理解できないと駄目じゃない？
両者が食い違っても良い例を出してみてほしい。

ごめんStrictっていってもHTML4.01Strictだけでの話ね。まだXは知らないから。

とすれば答は>>665の第2段落の1行目か。

>>659
2だと思う。

とりあえず、CSSに区間を表すセレクタがあれば、要らないdivを
かなり排除出来るはず。例えば、

#a - #b { border: 1px solid }

とかで、その区間を表すとか。

CSSに新しいプロパティの指定対象みたいなのを作れる機能と、
あと背景をレイヤー状にしたりとか、
サイズ指定で計算できたりとか変数作れたりとか（まあ、初期コンセプトから言って
あまりプログラミングのような形にならないだろうが）、
スケーラブルなCGを指定できたりとか…

スレ違い雑談厨に乗っ取られ

でも変なHTMLが流行るのはCSSが貧弱なのも一役買ってるのは間違いない罠。

>>659 の質問自体がスレ違い。CSSの表現力が貧弱だろうが、
実用的でなかろうが、関係ない。

ちなみに
＞（タグにクラス、IDをつけたりはアリだけど新しいタグを入れるのは絶対に禁止）
場合によるが表示のための追加ならClassもIDもStrictではない。

>>676
そう思うならCSSかUAの板でスレ主張しろ。
Strictスレで「CSSが貧弱だ」と主張して一体何を望んでいるのだ。

>>678
別にそこまで何も望んでいませんよ。二行目は削りすぎぬるぽ。

>>677
IDは別にいいと思うが。要素の区別付けるぐらいしか目的がないし。

>>679
id="left-table"
なんて記述は実際大量に存在する訳だが。

>>680
いいんでない？と俺は思う。
まあ、id="ilovemankonoana"の方が好意的。
更にid="TableOfContents"の方がパッと見わかりやすくていいな。

まあ、しかし、強制すべきことではない。

>>681
釣りにしても初心者に誤った認識を与えるような事を書くな。

強制すべき事ではないと言うならStrictやHTMLを使用する事ですらそうだ。
しかし、Strictと言う観点から言うなら「id="TableOfContents"」なら
有りだが（このtableは物理的な意味ではないので）、「id="left-table"」は
明らかに「やってはならない」行為だ。

>>659
> ↑基本だけど、これできる人ここにいる？後からdivとか追加してない？
divはstyle containerなんだから、レイアウトのために追加する時点でinvalidになるわけではないと思うんだが。

>>680
存在するから、なんなのだ？

>>682
いやいや。別にこれは信条未満の問題。
left-tableなら、時代とともにそのアンカーとはお別れを告げる時代が
来るかもしれないという期待を抱くだろうが、意味はない。
（別の時代が来て、right-windowになったからといって
left-table使い続けることもあるかもしれない。なんせ
文書中の別要素と被らなきゃいいだけの識別子だから。
間違いといえる間違いじゃない。設計としては汚いだろう。）

ilovemankonoanaは適当にそれらを抜け出した表現。
TableOfContentsはどちらかというとclass寄りかな？

>>683
Validかinvalidかいう論議をするなら全ての段落をpではなくdivで
マークアップしてもValidだ。

そしてdivを「style containe」として使う行為はValidであるが、
"Style" なのだから明らかにStrictではない。

釣りにしても初心者に対して誤解を与えすぎるし、
本気で言っているならアホすぎる。

いつから「100点ならいいじゃん」スレになったんだ？ここ

>>685
信者なりたての子かな。

＞"Style" なのだから明らかにStrictではない。
釣りにしても初心者に対して誤解を与えすぎるし、
本気で言っているならアホすぎる。

>>685
> Validかinvalidかいう論議をするなら全ての段落をpではなくdivで
> マークアップしてもValidだ。
validを「lintで100点」という意味で使ってる、と勝手に解釈しないでね。

validの意味をしらんのか…。

classの名前に関しては
http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html
の902以降を参照。ガイシュツ

>>687
アンチ信者の大きいお友達かな？

>>688
ﾌﾟ

どうやら荒らしたい大人の人がいるようだな。
物事を決め付けたり、具体的な内容を書かない人は悪い人だよ、とママが言ってました。

このスレは
「lintで100点 スレッド19」
になりました。

念のために言っておくとDTDとの合致が "Valid"。
従ってbodyの内容が全部divだけでも確かにValid。

さらに「段落にはp要素」などを全部守って「仕様との一致」
（従って仕様違反のValidな文書も存在する）

さらに見栄え的な要素を無くし文書の構造表記のみに分離したのがStrict。

lintはそれらを機械的に採点するプログラム。Validは自動採点可能だが、
100点でも仕様違反や非Strictな文章もありえる。

>>689
読んできたけど、結局「物理的でもかまわん」と「物理的はよろしくない」と両方出ててFAしてなかったよ。

>>1
>W3C 信者もそうじゃない人も投稿歓迎。 でもHTMLの基礎知識は欲しいね。

>>693 みたいな内容を書く必要がでるようじゃあ、このスレも終わりだな。

>>693
そうなのか。
StrictってのはDTDの種類だと思ってたよ。

>>693 みたいな内容を書くやつがでるようじゃあ、このスレも終わりだな。

なるほどValidの意味を履き違えてたみたいだね。

じゃ訂正
divはstyle containerなんだから、「レイアウトのために追加」がstrictじゃない、ってことじゃないのではないかな。

>>696
DTDじゃなくて仕様だろ。DTDは仕様に定められたUA向けの宣言にすぎない。

>>699
Strictってのは仕様の種類だと思ってたよ。

>>698
>divはstyle containerなんだから、「レイアウトのために追加」がstrictじゃない、ってことじゃないのではないかな。
かな？　じゃなくて、最初からそういうはなしなんじゃネーノ？
>>685
>そしてdivを「style containe」として使う行為はValidであるが、
>"Style" なのだから明らかにStrictではない。

>>698
>なるほどValidの意味を履き違えてたみたいだね。

この一言で自分の過ちは全部スルー出来るのか、凄いな。

>>702
訂正したあとに何を求めてるの？
許してください、と懇願すりゃ気が済むか？

>>701
んじゃ、div自体が「好ましくない」ってことかな？
フォントスタイルエレメントみたいなもんか。

>704
＞divを「style containe」として使う行為は
…そうか、日本語読めなかったのか。ごめんね。

>>705
仕様書に、
＞generic language/style container
ttp://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#edef-DIV
ってあるんだけど。
divそのものがgeneric language/style containerなんだよね。
style containerを否定
style container＝div
divを否定
ではないの？

それとも「漏れは仕様書に定められたdivとは違う解釈で使うからstrictなのだ」ってことかな？

みんな黙っちゃったよ……。どうしよう……。

>>685
> "Style" なのだから明らかにStrictではない。
>authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.
このthese elementsというのはdivとspanだよね？

今までの自分の投稿を読み直すべし
そして、投稿する前に投稿予定の内容を今一度読み直すべし

駄ﾚｽが大杉

>>709
ああ、人がいた。君でいいや。

> "Style" なのだから明らかにStrictではない。
って正しいの？仕様書を読む限り、「自分好みにするためにdivとかspanとか使ってデザインしる」と読めるんだけど。
＞ to tailor HTML to their own needs and tastes.

> no other presentational idioms on the content.
のpresentational idiomsがわからん。
何が存在しないと言われてるんだ？これ

みんな黙っちゃったよ……。どうしよう……。

みんな黙っちゃったよ……。どうしよう……。←これ流行ってるの？これから流行るの？

>>657
ﾊｹﾞﾜﾗ

みんなホントに黙っちゃったよ……。ホントにどうしよう……。

>685と>701と>705は説明してくれないのかな？

>>705
…そうか、英語読めなかったのか。ごめんね。

沈黙で自分の過ちは全部スルー出来るのか、凄いな。

斜め読みだがレスしたいと思う香具師はおらんだろうな　俺も含め

>>719
そりゃそうだろうな。
これだけ大口叩いてて間違ってたんだから(ﾌﾟｹﾞﾗｵｽ

>>710
> って正しいの？仕様書を読む限り、「自分好みにするためにdivとかspanとか使ってデザインしる」と読めるんだけど。
ﾏｼﾞﾚｽするがそうは読めない

念のためageときますね。

>>721
ああ、人がいた。君でいいや。

> "Style" なのだから明らかにStrictではない。
って正しいの？

不憫だから訳しておいてやるか。

>authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.
制作者はこれら（訳注：div要素とspan要素）にスタイルシートとかlang属性とかを使って、HTML自身をおまえの必要とか好みとかに仕立てることができるyo!

needsってのは当該要素がない場合、とかだよな。
tastesってなんだ？　って話だよな。

結局、
・div要素を使ってはいけない
・div要素は使ってもいいが、スタイルコンテナとしては使ってはいけない
どっちなの？

＞use these elements in conjunction with style sheets, the lang attribute
から考えると、
generic language/style container
っつーのは、「言語指定」とか「スタイル指定」用の汎用コンテナと解釈したほうがよいのかね？

みんな黙っちゃったよ……。どうしよう……。

>>685 >>701 >>705　待ち

なんか一杯進んでるね。俺としてはHTMLで文書構造を、CSSでその先をっていうStrictに
対してそれありえないんじゃない？って。

第一HTMLでは文書構造のみ。っていうこと自体HTMLの解釈・役割を後から変えようとしてる
わけだから、その行為こそStrictじゃないんだよね。

とりあえずHTMLはもともと文書構造を示すだけのものではないってことだよね。

で？ってゆう

>>728
>>723についてはどう思われまするか？

>>728
> なんか一杯進んでるね。俺としてはHTMLで文書構造を、CSSでその先をっていうStrictに
> 対してそれありえないんじゃない？って。

＞ to tailor HTML to their own needs and tastes.

仕様書に対して唾するのね。やだ、男らしい。

もし該当要素がなければdivにはクラスを伴い意味を持たせて要素のように使えと。
そういう事だと思いたい。

初めはdivを全く使わないで書いた。
でも、CSSを書く段階になって、(HTMLを書く段階では気づかなかった) 文書の論理的構造に気づいた。
例えば、「あ、ここは文書の概要がまとまってるな」みたいに。
で、HTMLに戻って <div class="abstract"> みたいなものを追加した。

俺は、それはそれでアリなんじゃないかと思う。

でも、追加するのが <div class="left-bar"> とかじゃダメだよね。(論理的構造じゃない)

section h が普通に使えるようになれば便利なことか
長く使う規格はじっくり練ってから世に送り出すべきだな

あたしゃDIVなんか使いません。文書構造ならhnだけで十分じゃん。

>731
＞もし該当要素がなければdivにはクラスを伴い意味を持たせて要素のように使えと。
>>723で書いたけど、
それは「needs」って部分だよね。
「tastes」って部分が何を指してるか、がこれの答えになるんじゃないかな。

>732
＞でも、追加するのが <div class="left-bar"> とかじゃダメだよね。(論理的構造じゃない)
>>689でも示されてるスレッドでは、

> 理論的な名前をつける「べき」では別にないけれど、そうする方が普通は便利。

とか、

（前略）
> 「メニューリストを段組で左側に表示するCSS」を書く場合には、
> 「そのCSSからみたセレクタ」としては「class名: menu」でも「class名: leftTable」でも
> 変わりはないように思われる。

（中略）

> なお、絶対、一生CSSは変更しない、このHTMLとCSSは一体なのだ! と言う事なら
> べつに「class名: leftTable」でも良いわけだが、だったら STYLE 属性でCSSを
> 直書きする事を推奨する。

（後略）

とか。

問題ない、という意見が出てる。

>>734
<body>
<h1>今日はうどんを買いに行きました〜

〜</h1>
<h2>その時僕はこう叫んだのです。〜

〜</h2>
</body>

>>736
今度から文脈を読むようにしようね。

>>735
まあガイシュツだろうが後半の「意見」は妥当ではないな。
もっとも現行のHTMLの限界を示しているとは言えるかもしれない。

>>737
hn要素だけでいいって言うから……。

あ、そうか。

<hn id="menu">
<ul>
<li>〜</li>
<li>〜</li>
<li>〜</li>
</ul>
</hn>
<hn id="contents">
<p>〜</p>
</hn>

こういうことか。ごめんごめん。

>>738
> もっとも現行のHTMLの限界を示しているとは言えるかもしれない。
ごめん。想像力が乏しいので、どこをどう指摘してるかちょっとわかんない。
説明してくれないかな？

>>739
ネタは一度だけにしておけ。737が無粋だったのは確かだが。

>>740

>>735
>>「そのCSSからみたセレクタ」
>>絶対、一生CSSは変更しない、このHTMLとCSSは一体なのだ!

このあたり、「CSSを作成するのは制作者だけ」という誤解があると思った。
しかし、規格外の要素を特に指定したいときのクラス名指定は、
もとの文書の作成者の裁量に委ねられているため、現行の仕様において、
論理的な名前をつけるメリットを感じにくいのは認めざるをえないかもな、
とも思った。

>>741
つかマジで>>734の主張したことが見えない。
見出しと本文をまとめる、とかすらも否定しちゃってるわけだよね？
それって、装飾はするけど、（floatなどで）配置はしない、とかなのかな。
それか、全てのhn、pなどを絶対配置するから問題ない、ってことかな。

>>743
strictスレでfloatなんて関係ないよ。

>>742
META要素なんか、4.01の仕様書では
＞本仕様は、当該属性の正当な値集合を列挙しない。
となってるけど、パターンも確立されてるし、それを実装してるOperaとかあるわけじゃん（これは蛇足）。

識別子に共通のものがあればいいんじゃないか、とかは思うな。

>>744
そもそもこの流れは、「div要素はスタイルコンテナ」というところから始まってる。
スタイルだからダメ、ってのならdiv要素はlang属性用にしか使えない、ということになる。
＃汎用言語/スタイルコンテナだから。

だから、div要素の運用、ってのは関係あるんだよ。

>>746
ん？lang属性用？？
langは各要素に記述したらよいのでは？

語弊があるな。

div要素の使用を認めている仕様書の観点からすると、
見栄えのためのdiv要素を容認している、ということになる。

フォントスタイルエレメントなどと同様に、
仕様書では非推奨にはなっていないけれど、（lang属性以外で）使わない方がいい、と考えるべきかどうか。

>>747
>>708、>>723
div要素の説明ね。

>>748
>見栄えのためのdiv要素を容認
これは拡大解釈では？
要素をグループ化し、文書に構造を付加するのがDIVやSPANの役割だよな？

誰か>>711について、教えてくれまいか。
あの部分だけがひっかかる。

ちなみにあたしとしては、スタイルのためのDIVは否定しないよ。
自分は不要だから使わないけど。
スタイル(langも含めて)のためでないDIVをマークする意義は理解できないけど。

>>751
邦訳も読めよ。仕様はブロック要素かインライン要素かは指定するが、
（仕様的な）プレゼンテーション上の要請はしない、という意味ではないか？

>>750
だよな？　って仕様書読めばわかるだろ。

＞generic language/style container
汎用の、「lang属性」指定、「スタイル」指定のコンテナ

てことは、
「グループ化」と「lang属性」指定は正しいけど、
style containerとして使うことはおかしい、ということかな。style containerなのに。

>>753
マジですまん。
> （仕様的な）プレゼンテーション上の要請はしない、という意味ではないか？

＞プレゼンテーション的語彙
がわかんなかったんで。
あなたの説明でよく理解できた。

>>752
＞スタイル(langも含めて)のためでないDIVをマークする意義は理解できないけど。
あんたが使う使わない、なんてことは主題じゃない。
「スタイルのための要素」は
＞"Style" なのだから明らかにStrictではない。
と>>685が言ってることについて、なんだよ。

だとしたら、>>754で書いたように、「グループ化」と「lang属性」指定のみで使うべき、ということになるよな？って話。

>>754
全体の文脈から読むと、構造化付加のために使え、
その結果として（Thus）、スタイルシートと併用することでスタイル指定のコンテナにもなる、でしょ？

>>754
あーごめん勘違いしてるのかも。
今みんなが話してるのは、strictの是認できる下限のはなしなのかな？

あたしゃ、ベストなら不要
単にDTDマッチレベルならOKと思ってる。

グループ化、ってのは共通の何かがあって、それをまとめる、ってことだよね？
言語コンテナとして考えれば、
この見出しとこの段落とこの段落とは「この言語指定です」って風に。

スタイルコンテナとして考えれば、
こことこことこことここは「同じスタイルです」でも「共通事項」になるわけじゃないの？

DIVで構造化というけど、構造化目的なら不要。Hnがしっかりしてるならその時点で構造化が図れるからね。
DIVを使わないと構造化が図れないのはそもそも文書がおかしい。

一応div関連の流れは、

発端
>>659　が、文書作成→CSS作成の蔡に、
＞４．その後は絶対にHTML側をいじることなく、CSSファイルだけさわってレイアウトする。
ができるのか？
と発言。

>>683　が、
> ↑基本だけど、これできる人ここにいる？後からdivとか追加してない？
に対し、
＞divはstyle containerなんだから、
スタイルのために追加してもいい、と主張。

から、だね。

>>759
いや、構造化じゃなくて、グループ化。

>>760
>＞divはstyle containerなんだから、
これは俺の読み方とは違うな。仕様は前段でDIVの使い方を解説し、
後半ではそれによって何が可能になるかを例示しているのだと思う。

>>761
だとしたらなお更。なんのためにグループ化？
具体的にはどんなユースケース？

>>763
よく言われるのがセクショニングだろうね。
hnとその支配下の要素をグループ化する。
それによって、例えば
-h1
--p
--h2
---p
--p

最後のpで改めてhnを設定しなくてよくなる、とか。

あと、DTDじゃなくて仕様書からというけど、
仕様書なんて読み手によって解釈は幾通りにもなる。
#だから、ここでこんな議論になっている
DTDのように機械的に誰もが間違いなく判断できる物以外は議論しても埒があかないとおもうよ。

>>759
div要素においてのみだとそうだね。
span要素も含めてくれないかな。
span要素も「lang属性」「スタイル」のコンテナなんだし、divが「スタイルのために追加」が否定されるならspan要素もそうなるだろうし。

>>762
＞generic language/style container
この名称はどう解釈すればいいんだ？

>>764
>hnを設定しなくてよくなる
とかだと、所詮省略形だからフォーマルとは言えないと思うけど。
省略であるなら、HTMLにはhnをちゃんとマークして、cssで非表示にするのが正しい。

>>766
>756のように解釈している。一ヶ所だけで取り出さないで文章全体で読んでる。

>>767
最初からないなら省略じゃないでしょ。
DIVがないと、ないように書いたものをわざわざ書かなきゃいけない。
それがもともとHTMLで記述できないものだった、と考えてもいいけど、
DIVを認めると記述できるものとなる。

>>759
見出し-本文 の構造化がdivなしで実現できているのはその通りだけど、
さらに構造化を推し進めるという意味でdivを使うんじゃないのかな。
divを使わないと構造化できないというわけではない。

もちろん、divなんて本来必要ないし、書く必要なんてどこにもない。
見出し-本文の構造をさらに一歩進めた構造化を行いたい
(それは2次的にはCSSのためかもしれない。JavaScriptで使われるかもしれないし、
 もしかするとどこからも利用されないかもしれない)
と思う人だけclass属性付きのdivを使えばよい。

>>763
書いてから気付いた。
慣習に従って、hnの順番を正しくしておけば、どれがどのグループかは判別できるね。確かにそうだ。

ここからは蛇足だけど、
「h3から次のh3まで」でグループと認識させられるならh3にid振るだけでh3以下のグループのidが用意できるよな。
h3#MENU:group　とかでCSSで使えるとか。
そうせずにgeneric language/style containerという要素を入れたのはW3Cの手落ちかなぁ。

>>771
グループ判別に失敗することがある。例>>764

>765
> DTDのように機械的に誰もが間違いなく判断できる物以外は議論しても埒があかないとおもうよ。
埒があかないもの、以外だと「仕様書嫁」で終わるしなぁ。
ここは質問スレじゃないから、解決させることが目的ってわけでもないでしょ。

>>766
あーspanかぁ..
確かにあたしもlangのみに使用してる。
あとはemにあたらない、なんらか文章内の意味の違う部分でもつかっちゃってる。

>>772
最後のp要素は、その前のh2以下じゃないんでしょ？
じゃあ、h2で区切ればいい、というか、「そういう構造にすべき」だったら、div要素は追加されなくてもよかったような、って話。

<h2 lang="en">
は、次のh2か、body終了タグまでがenだ、とか。

#妄想に過ぎないけどね。

>>774
なんかあんただけ仕様書読まずに書いてないか？

> あとはemにあたらない、なんらか文章内の意味の違う部分でもつかっちゃってる。
＞HTMLには「顧客名」「電話番号」「メールアドレス」などを識別する要素は存在しないから、望ましい構造やプレゼンテーション効果を得るために、DIV要素とSPAN要素を用いている。
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#edef-DIV

仕様書の例文にすら存在してる使い方だぞ。

ISO-HTMLだとhnはdivに入れられないんだよねー。

ああ、全然言いたいことが言えてないな。
>>772
つまり、段落には必ず見出しが必要、という仕様だったら可能だったよね、っていう蛇足。

>764はかなり有名な例だと思ったが初見の人が多いのか？

>>742
その元の書き込みは更にこう続くんだよ。
http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html の908
＞例えば
＞e=mc<span style="display:none">^</span><span style="vertical-align:super;">2</span>
＞のような場合。

要するに >>735 が自分の都合の良い所だけ抜き出した醜悪な引用をしただけ。
最近の流れを読むと解るが、アフォは引用だけして、ソースを示さない。
元の文章の前後の文脈を読んで欲しくないのだ

>>779
所見かどうか関係あるのかな？

h1があって本文があって、h2があって本文があって、いずれにも属さない段落がぽっとそこにある、ってのはあってる間違ってるとか抜きで気持ち悪いなぁ。俺は。

>>776
するどいね。確かに今は読んでない。以前一通りは読んでるけど。
だって、仕様書書いた人達より、ここの人たちのほうが神経質なんだもの。
特にWAIの仕様書なんか読むと、HTMLきちっとしてれば、こんな項目いらないのにみたいな矛盾がたくさん出てくる。

埋め込みかよ。確かにそれなら話はちょっと違うな。

>>781
いずれにも属さないのではない。最初のh1に属している。

>>780
style containerがそれだな。

>>780
それは誤解。
引用文を残した箇所と、それ以降は別の話だ。

＞べつに「class名: leftTable」でも良いわけだが
を非難も肯定もするつもりはなく、その主張を挙げる必要があっただけ。

＃そもそもそれ以降の部分は、「物理的なクラス名（あるいはID）は是か非か」と無関係だからね。

>>780 の引用の例の場合、MathMLとか使わずにHTMLだけで解決しようとすると
ある程度しょうがないな、とは感じる。

数式、化学式など、たしかに見栄えと論理的な意味が分離不可能な例は存在する。

>>784
感覚の問題で、仕様で認められてるから批判はしないけれど、
だったらそれにも見出しつければいいのにな、って思う、ってレベルの話。

「おかしい」と言ってるならわかるんだけど、
そうすれば構造化のdiv不要だよね、ってだけの妄想だしね。

>>786の補足
「埋め込みの方がよりよい」と言ってるけど、「class名: leftTable」を肯定してることは変わらんでしょ？
＃バカな例、として挙げたわけじゃあないんだよ。

そのときにも指摘されてたけど、
sup使え、はバカげた解決策ですか？

>>789
そうでもない。それでいいと思うよ。

>>790
＞例えばフランス語など、多くの用字系では適切なレンダリングのために上つき文字や下つき文字が必要である。こうしたテキストをマーク付けする場合に、 SUB要素やSUP要素を用いる必要があろう。

むしろ、そういう使い方用の要素、だよな。

＞HTMLには「顧客名」「電話番号」「メールアドレス」などを識別する要素は存在しないから、望ましい構造やプレゼンテーション効果を得るために、DIV要素とSPAN要素を用いている。

既存の要素に存在するのに、spanでやる、ってのは<span style="font-style: bold">を強調に使うようなもんか。

さて。擁護のつもりで得意になって罵倒していた>>780が、
結局>>908のミスリードを露呈してしまったわけだが。

http://pc5.2ch.net/test/read.cgi/hp/1084711216/

↑から来ました。
DIVを大量に使う、通称DIV厨と呼ばれる行為は何がいけないのでしょうか？
柔軟なレイアウトが出来るなどのメリットはあってもデメリットは無いと思うのですが。

>>780
> 最近の流れを読むと解るが、アフォは引用だけして、ソースを示さない。
> 元の文章の前後の文脈を読んで欲しくないのだ

＞>>689でも示されてるスレッドでは、
ソース示したつもりだったんだけどな。手抜きゴメンね。

あと、それ以外の引用は全部4.01の仕様書から。手抜き、ほんとゴメンね。
そういう悪意の解釈をされるとは予想だにしなかったです。

>>793
もと来たスレの>>925を呼んでください。
それを答える前にその根幹を話してるので、これの一応の答えが出ない限りどっちにでも転ぶぞ。

で、「div要素をスタイルのために追加する」は好ましくないのか問題ないのか、ってのはどうなのかな？
あと、「クラス名は物理的でもよい」も。

ここら辺漠然と「divはグループ化のためならいいんじゃない？」「物理的なクラス名は見栄えとの分離がなされてないからダメ」とか言われてて宙ぶらりんな気もするな。
俺的にはどっちの意見も正論に見えてきて正直混乱してる。
どっち側の意見も出せないのが実情なんで、せめてヒントになるような意見だけでも欲しいです。

だからさ究極的にはないほうが良い。
使ったって間違いじゃない。
これが結論。

仕様考えたチームはそんなに神経質に考えてないだろう。

>>796
divについては大きく分けて三派。

スタイルに使用
・スタイルのために使える
拡張に使用
・構造化やグループ化のためにも使う
・非定義の要素を表現するためにも使う
否定
・極力使うべきでない

個人的にstrictと言われてきたのは後者２つだろうと思う。
また、最初のは物理的クラス名を容認する傾向があり、
後者２つは否定する傾向があると考える。

ちょっと誤解があるな。
拡張に使用する人は、スタイルのためだけには使用しない。

まじで、こんなに真剣に考えてるのは世界でもここぐらいじゃない。
例えばコンパクトHTMLなんかaccessで作ったけど、提出日の前の晩に、「やべ、明日期限だ！」
とかいって、副社長が一晩でつくったりしてるんだぜ。

とりあえず、過去ログ嫁って話だよな。

あと匿名DIVの問題もあったな。
DIVタグだけを全部取り去ったあと、文書がなおValidかつstrictであることを要請するか否か。
>798の「拡張に使用」でいうと、前者だけか後者も含むか。

>>801
読みにくいからまとめサイトつくろうって話もあったよな。

>>797
> 仕様考えたチームはそんなに神経質に考えてないだろう。
俺もそう思う。
後から「見栄えに関するものは非推奨（あるいは廃止）」とかやるくらいだしな。

strictHTMLに「描画」は無関係、というけど、結果こういう問題が浮上する辺り、やっぱり切っても切れない関係なんではないか、って思うなぁ。
blockquote要素にcite属性があるのに、わざわざcite要素で出典を明示したりするのはやっぱブラウザの実装に起因してるわけだし。
＃そんなのはブラウザの都合だ、cite属性を指定してるならcite要素で明示するのはくどい、というのはあまり聞かないよな。

>>802
divのコンテントが、ins|delみたくフロウだったらその問題も消えるのにね。

<dl>
<div>
　<dt>
　<dd>
</div>
<div>
　<dt>
　<dd>
</div>
</dl>

こういう使い方できないのがツライな。
まあ、ここらへんも「実装の問題」で解決するはずだからstrict-HTMLには無関係な話だけどな。

間違えた。
×ins|delみたくフロウだったら
○ins|delみたいなフロウだったら

訂正
という話を聞いた。
言ったそいつが嘘ついてるかもしんないし、あたしが聞き違えた可能性も高いかも。
accessさん訴えないでくださいね。

>>807
ごめん。悪いけど君の雑談には興味がない。

>>800
はじめから信じてないし。

誰もレスしてないのに自意識過剰な方ですね。

>734

>752

>774

>782

>800

>807

そろそろコテハンになってくださいネ&heart

誰にも気にかけられていないことに気付かないことが特徴

こんなことで一体感を得るスレ住人。
なんかここのところギスギスしてたもんなぁ。

>>798
> 個人的にstrictと言われてきたのは後者２つだろうと思う。
> また、最初のは物理的クラス名を容認する傾向があり、
> 後者２つは否定する傾向があると考える。

普通にマーク付け。
なんやかんや装飾。
配置。
「お、メニューは左に置きたいな」
メニューの見出しとulのリストを一括でdiv id="MENU"とする。

後からスタイルのために追加する例だけど、
これだと、後者二つを否定していない、と思えるんだけど。

ただ、スタンスとしてはどうか、というのでいうと「こじつけだな」とは思う。

divで構造化しないと
http://foo.com/hoge.html#bar
の「#bar」が指す部分が曖昧になるんだよな。

>>814
Strictならメニューがある時点でダメという説が。

>>815
＞の「#bar」が指す部分が曖昧になるんだよな。
なぜそうなるの？どこにID指定しても、その要素が文頭にくるだけでしょ？


どういうメニューを想定してるかわからないけど、

ttp://www.w3.org/
で言うと、
60行目の
＞<div class="navBlock">
辺りみたいなのなんだけど、ダメなのか？

説が、とか言わず説明してくださいよ。

>>814
実体としてそういう人が多いと思う。
再利用可能性を考えるといいんじゃないかな。
たとえばリヌの度にクラス変えているようじゃダメ、とか。

>>815はひょっとすると全然見当違いのことを言ってるんじゃないだろうか。
もしかするとstrictな考え方とか以前にHTMLを理解できていないんじゃないだろうか。

そう思わないと言ってる事が理解できないと思いました。

>「#bar」が指す部分が曖昧になるんだよな。

#bar で指し示したい部分がどこからどこまでなのか、
が曖昧になるのだと言いたいんじゃなかろうかと補完

>>818
815ではないが・・・
#なしの普通のアンカーだと文書全体との結びつきになる。
ということは、#のリンクでも、要素一つだけでなく、文書の大きさをもつ「部分」と関連付けたい。
ということは、見出しではなく、見出し直下のパラグラフ等を含むところにアンカーを投げたい、
ということかな？

>>817
苦し紛れのクラス名とかつけてしまいそうになる自分に勝たなければいけないよね。

＞たとえばリヌの度にクラス変えているようじゃダメ、とか。
変えるのはダメというか、不適切なクラス名を与えていた、ってことだよね？
追加する分はどうだろう？
「このコンテナとこのコンテナは左に縦に置きたい」となると、二つのdivを括るdivが必要になるし。
＃そうしないと、後続のフロートが後者の右に来てしまうから、とかそんな理由で。

まさしく「スタイルのためにdivを追加する」の例になるけど。

>819
そのIDが与えられている要素の開始タグから終了タグまで、だろ。

>820
そういう理由ならわからないでもないが、
＞曖昧
ではないだろ。上記のように明確になってる。

>>821
それはやっぱスタイルのためのdivになってる気がする。
逆にCSSでノータッチのdivがあってもいいよくらいに徹底的に構造化しておけば？
やっぱ中途半端なのがいくないと思う。

>>822
だからもっと広い範囲でID与えたい場合に何の要素使うんだって話なんだろが。

<div class="section1">
…
</div>
<div class="section2">
…
</div>

こういう風にしておいて、あとでXSLTで1章だけ2章だけ抜き出そう言うIDが
スタイルのためのDIVというなら、そうかも知れん。

その場合、まず、スタイルとは何か話し合わねばならないのだが、残念ながら
そこまでする気は毛頭無い。

あ、divに付与する属性はclassじゃなくてID…orz

>823
そう。
だから、「スタイルのためのdivの追加」が肯定されるものなのか、という問いで、
>>798の、
> また、最初のは物理的クラス名を容認する傾向があり、
> 後者２つは否定する傾向があると考える。
という部分がクリアされてたらどうなのか、と問題提起したわけなんだよ。

>824
じゃあ、「曖昧」じゃなくて、「この範囲を指定したいときに使う」と言えばいい、と言ってるわけ。
範囲を指摘されてることはわかってるよ。
＞divで構造化しないと
＞曖昧になるんだよな。
はおかしい、と言いたいだけで。
「divで構造化」しなくても「曖昧に」ならない、と。

「divでグループ化しないと、idのアンカーの範囲を明示できない」ならそう解釈できるよね。
でもまあ、それの頭のhnに指定すれば、「それ以下を指している」とわかるとは思うんだけど。

まあ、>>815本人じゃないと、どういう意味で「曖昧」と言ったのかはわかんないんだけどな。

>>825
それはスタイルじゃなくて、構造化でしょ。
「スタイルのため」ってのは砕けて言うと、「ここからここまでのボックス（仕様書に出てくる用語のボックスに非ず）を作りたいの」っていうような感じかと。

>>816
そういうメニューもあるな、そういえば。
俺が言いたかったのは
「メニューではなくてlink要素でマークアップすべきだ」
ってことだったのよ。
トップページみたいにメニューそれ自体が内容な場合は話が変わってくるな。
ハッキリ書かなくてすまん。

IDの件だが、「文頭に来る」事自体はUAがたまたまする動作の一種でしかない。
たとえば、XSLTのdocument()関数で
document("http://hoge.com/foo.xhtml#bar")
ってフラグメントIDを指定した場合、#barで指定されたフラグメントにアクセスできるのだけど
これを見出しにのみID属性を指定すると、そのまま見出しだけが選択されちゃうわけ。

ID属性は「フラグメント」を指定するための属性で、
hnへ直接この属性をつけてしまうと本来意図されたその見出しが管轄する部分全体が
指定されない。

「hnから次のhnまでがブロックである」っていうのは「何となく」そんな感じがするけど、
ISO-HTMLならまだわかるけど、XHTMLでは明言されているの？

凄い伸びだね。
とりあえず、視覚系ブラウザでみることも聴覚系ブラウザで聞くことも絶対にない
文章をHTMLで構造マークアップをする。要は自分で書いた論文を自分の為にメモ帳
の中だけで構造だけを明確にする。メモ帳でしか見ないからそれで終わり。

↑の作業が終わったときに
・DIVがあった人は、習慣的にDIVを構造化目的で使っている。
・上の作業ではDIVがなかったのに、現実にサイトを作る時にDIVが出てくる人はDIVを
構造とは違う目的で使ったりする。（構造的な理由を後付けする人はいるが、上の作業で
いらなかったものは、本来いらないもの。構造化は上の作業で完結している。）

で、Strictが好きなこのスレ住人でも多くは後者なわけで、
HTMLで構造を、その先をCSSでということを実践できてないことになる。
ここの住人ができないんだから、HTMLで構造、その先はCSSっていうのは現実性を欠いた
W3Cのオママゴトって話かな？

とりあえずHTML自体は構造だけの為に作られたわけじゃなくて、そのHTMLを勝手に変えようと
してるW3Cが作るものは規格じゃなくて、こんな感じで標準化しませんか？という呼びかけ。
今はその呼びかけに中途半端に各社、各サイト製作者が反応している。

で？ってゆう

>>830
漏れ後者だった・・・・＿｜〜｜○

>>827
曖昧って言葉は良くなかったね、ごめん。
明示できない、が正しい。

セクションの明示のために
<div class="section">
とか。

>>830
ほう。試しに>>830の文章をマークアップしてみた。
<h1>凄い伸びだね</h1>
<p>〜</p>
<h2>↑の作業が終わったときに</h2>
<p>〜</p>
以下こんな感じ。

divは出ないな。俺も後者か・・・・；

あ、classじゃなくてIDか・・・・orz

>829
なるほどな。
純粋に「ID参照」で、参照される「対象は」idの与えられてる要素の開始タグから終了タグってそう考えると不便だね。
見出しにID振って、それを呼び出して「見出し」が出てこられても間違った挙動ではないし、でも目的に沿ってない。

#　「5月1日の日記」とだけ参照されても仕方ないもんね。

んじゃ、id振って、「この考察を参照するには〜」ってのをやる場合は、div要素で括ってる方がより正しいのかな、という疑問が。


>830
> とりあえずHTML自体は構造だけの為に作られたわけじゃなくて、そのHTMLを勝手に変えようと
> してるW3Cが作るものは規格じゃなくて、こんな感じで標準化しませんか？という呼びかけ。
>>797　>>804にもあるように、取り繕ってる部分とかも否定できないよな。
「もっと完璧な仕様を作れ」とか子どもみたいな無茶を言う気はないけど、あやふやな部分があったり後方互換で残ったり、ブラウザメーカーの作った要素を取り込んだり捨てたりとか、なんだかそこら辺がややこしくしてるような気もするな。

> で？ってゆう
これ、何？　なんか不快感が残るんだけど。

>>835
> で？ってゆう

上は自分に対して問いかけてるだけだから気にしないでちょ

>>833
俺も、「見栄え」で必要性が生じなければdiv入れないな。
それが似非ｽﾄﾘｸﾀﾝだとは思わないけどなぁ。
スタイルコンテナをスタイルのためにぶち込んで何にが悪い、と考えてしまうよ。

俺的には「見栄えは分離すべき、だけど、ねぇ。仕方ないし」って感じで生き残ってる要素なんじゃないか、とか邪推してる。

>>836
２ちゃんねるでこんなこと言うのもなんだけど、
最後まで読んで自虐的なそんな文字列があるとなんか萎えるよ。

もっと自分の意見に自信持てよ。
自分の中で曖昧な部分があるけど発言、なんて誰でもあるし。

>>830
divもclassも全く使ってない。
自分用のメモをそのまま公開してる。

個人的には、divを取り去った時にstrictであれば、
デメリットは生じないと思うから、そこまで神経質になる必要はないと思うけど。

＞HTMLで構造を、その先をCSSで
というのはちょっと引っかかる。CSSは必須ではないし。
構造と見栄えの分離が重要なのではなくて、論理マークアップをすることが
重要なのだと思う。その先は、単にデータとして扱われるかも知れないし、
ブラウザがデフォルトスタイルで表示するかも知れない。

例えばだけど、百科事典のような膨大な文書の、ありとあらゆる項目をひとつのHTML
として記述する場合、<h7>が欲しくなるかも知れない。
そんな時<div class="h7">という記述になるかもね。

>>835
そう、そういう状況になるとDIVで括らない限り参照できなくなっちゃうんだよね。

a要素で「ジャンプする」っていうのはUAの動作の一種類であって
たとえば
「リンク部分にポインタをもってくとそのリンク先の内容がポップアップする、クリックしてジャンプ」
とかでもいいわけよ、こういう場合、hn要素に直接ID要素が付いてると
「5月1日の日記」だけがポップアップして「は？」って事に
なってしまう。

XHTML2.0のsection要素に期待だな。


自分は<div class="section" id="d2004-hoge">以外はなんとしてもDIVを排除してる。
スタイルのためにDIVで括るぐらいなら内容の要素にclass付けてがんばる方針。
で、CSSでつまずいて毎回「CSS2 is crap」と叫んでるな。

>>839
> というのはちょっと引っかかる。CSSは必須ではないし。
そういう意味じゃなくて、「結局、理想論どまり、と言われる所以」ということじゃないかな。
HTML文書ってのは「環境に依存しない」ってのが強みだよな？
でも、依存しない、って言ってるくせに表現力がしょぼい、となると「じゃあ、環境に依存してもいいからテーブルで」とか本末転倒な方向性が生まれてしまう、ってこと。

まあ、デザインのみならdiv使わなくてもいけるな。
しかし、レイアウト、となると使わないとちょっとキツイ。

>>840
昔、その話題あったなぁ。
そういう場合は、分けるのが順当じゃないか、みたいな感じで終わったけど。

h4以下のh5をulでリストメニューにする、とか。
そうすりゃh5が繰り上がる、と。