Strict-HTML スレッド 32

StrictなHTMLについて語るスレッド。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 スレッド 31
http://pc8.2ch.net/test/read.cgi/hp/1134838443/

勧告等・その他は http://bell.skr.jp/web/strict/#etc
過去ログは http://bell.skr.jp/web/strict/#past_thread

初心者の質問はこちらへ
Webサイト制作初心者用質問スレ Part 150
http://pc8.2ch.net/test/read.cgi/hp/1134811843/

実装の話は10中8, 9スレ違い。

関連スレは>>2

CSS {スタイルシート質問スレッド:50%;}
http://pc8.2ch.net/test/read.cgi/hp/1134048018/

XML→XHTML
http://pc8.2ch.net/test/read.cgi/hp/1039933755/

@media:all { 真のアクセシビリティ }
http://pc8.2ch.net/test/read.cgi/hp/1034270272/

ユーザビリティ専用スレ　その３
http://pc8.2ch.net/test/read.cgi/hp/1136275352/

【みらくる】XHTML 2.0 (その2)【ドリーム】
http://pc8.2ch.net/test/read.cgi/hp/1098711758/

XML使いのスレ 2.0
http://pc8.2ch.net/test/read.cgi/hp/1057198990/

XSL/XSLT
http://pc8.2ch.net/test/read.cgi/php/999654569/

前スレのあらすじ

26-58
section

29-
お薦めの本

75-
ブログのマークアップ

94-
見出しと定義リスト

114-
別窓

393-
FLASH(object)

419-
strict or valid

442-
target 属性の統計

469-
フォームのマークアップ

510-
見出しのフォントサイズ

前スレのあらすじ 2

537-
ばけらと神崎はどっちが強いの？

563-
まとめ

570-
引用の場合はソースごと引用するものでしょうか？

573-
フォームのマークアップ 2

588-
インラインフレーム

633-
<br />ってどういうところで使ってる？(段落)

736-
StrictorかTransitionalistか

815-
某コテ

856-
大晦日だよ

866-
明けましておめでとう

前スレのあらすじ 3

860-
ASCII内で使われていない文字

895-
某コテ 2

912-
セリフのマークアップ(定義リスト)

949-
「New」はどのようにマークアップするのが適切ですか？

Strict-HTMLの見本サイト
http://web.archive.org/web/20040623225923/http://www20.tok2.com/home/ilovemankonoana/

あおいうえおあお
隣の客はよくガキ作る客だ
バスガス爆発ブスバスガイド

やぁ… (´・ω・`)久しぶりですね。
ttp://bell.skr.jp/web/strict/ ←このサイトの管理してる者です。
とりあえず過去ログの保存と更新は忘れないけど、なんかWikiのまとめサイトがあるでは
ないか!?

すげー。

>>前スレ997
野嵜氏の文章引用↓
>一方、意味上の纏まり毎に文章をグループ化するのも屡々有益です。
>「意味段落」を一つのdiv要素(汎用のブロック要素)に纏め、
>それぞれの「意味段落」の意味をid屬性やclass屬性で明示する、
>と云ふやり方も、屡々行はれます。

>>1
乙

前スレのこれは結局、変態なの？アリなの？

　956 名前：Name_Not_Found[sage] 投稿日：2006/01/02(月) 22:56:02 ID:???
　>>955
　　<em class="new">
　　　<span class="title">ほげほげ</span>New!
　　</em>
　って感じ？

変態だよ派、変態じゃないよ派、変態だがそれがいい派

他から取ってきて貼り付けたような感じの部分は広義の引用といえるか。

俺は「脳内の妄想を引用した」と解釈すれば引用といえると思う。

>>11
「ほげほげニュー！」の語感がツボなので、だがそれがいい派。

その前からずっと話題になってたものを
その流れを読まないで脳内と言うほうが恥ずかしいな。
ttp://members.jcom.home.ne.jp/pctips/www/MarkUp.html
ほれここの脳内だろｗｗｗ

その前に
「他から取ってきて貼り付けたような感じの部分」
て何

　　　　　　　　　　　　　　　　　　　　ζ
　　　　　　　　　　　　　　　 ／￣￣￣￣＼
　　　　　　　　　　　　　　 /　　　　　　　　　＼
　　　　　　　　　　　　　　/|||　　⌒　　 ⌒　 ||||
　　　　　　　　　　　　　　|||||　　⌒　　⌒ 　|||||
　　　　　　　　　　　　　　6|----◯⌒○----|9
　　　　　　　　　　　　　　｜／　＿|||||||＿＼｜
　　　　　　　　　　　　　　　＼　　＼＿／　／ 　　　　＿＿＿_
　　　　　　　　　　　　　　　　＼＿＿＿_／　　　　.／　　　　　＼
.　　　　　　　　　　　　　　　　　〉,　　 ﾉ＼.　　　　｜／￣⌒￣＼ ＼
　　　　　　　　　　　　　　__,. ‐'.　', 　 　 　 ヽ､　　／ ⌒　　⌒ 　｜ ＼
　　　　　　　 　 　 　 ,.-‐'　 ￣`‐'　　 'ﾞ￣　　　`｜　(･)　　(･)　　＼ ｜
.　　　　　　　　　　 ノ　　 l　　　`　　　"　 　 ヽ　｜　　⊂　　　　　9） ⌒＼
　　　　　　　　　　/　　-‐　　　　　　　　　　　 　 ｜　 ＿＿＿ ＼　｜　 　）
　　　　　　　　 　 j.　　`i､　　　　　　　　　　　 /ﾞ　＼　＼＿／　　 /−
　　　　　　　　　 /　.／, lヽ､,　_　　　　`　 -‐'ﾞrf^i^Fヽ.＿＿＿_／
.　　　　　　　 　 l ／ ／ ヽ　　　　　　ヽ、　 .r|_|_{,_jノ/ '　　/∧､
　　　　　　　　 ／ ／　　　',　 ,.　　　　　ヽ／ `^','、ﾉ/　　 7/　 ＼
　　　　　　　／ ／　　　 　 l.　l　　　　 ／.　,.ィ" r'.'ﾍﾞ,　 ／〈 r-　 ＼
.　　　　　 ／.／　　　 　 　 l　 }　　j／　 ／　l　 ヽ＿)ﾑ{　,. ゞ,へ　　＼
　　　　 ノ .／　　　　　　　ﾉ　 l r‐ '　／　 l　 ﾞ!　 j　　　`ｰ(/,.　￣￣　 ヽ
　　　 / .／　　 　 　 　 　 !　　 し_,ノ　　 ノ　　l. /　　　　　 Y‐^ﾞﾞ''''ー一'
　　 /　/　　　　　　　　　 ﾄ､,_ﾄ__　　　　_ノ__,..-y　　　, 　 　 l
　 /　/　　　　　　　　　　l`'ｰ､　　￣￣　　,. ィヽ　　　　　 　 l
　l　/.　　　　　　　　　　 l　　　ヽ　　　　／ /　ヾ;､_　　　 ,. -ﾍ
　! |.　　　　　　　　　 　 l　　　　lヾ.　　/ ,　l　　　ヾ'ｰ=イﾞ'　　 !
　| |　　　　　　 　 　 　 |　　　　i　 ﾞrt.'　 l. !　 　 　 ゞ､/.　　　 }
　| |.　　　　　　　 　 　 |　　　　'　　| l　 　 |　　　　 }　|　 　 　 l

前スレ997は、
> この業界ではclassやidを指定しても意味を与えられないというのが定説。
> 例えばyuu氏や野嵜氏がそう言ってたと思う。
と言った。

>9は、それが間違いである旨を、野嵜氏本人の言を引用しつつ言った。

>13は、「9は引用元を示してないけど、9の脳内にあった妄想文章
を引用したなら引用元示せなくても仕方がないよね（藁」のようなことを
言った。

ところでyuu氏ってこれ？
ttp://w3j.org/
狭っちい固定幅で読みにくいな、これの定説を持ってきたんだとしたら（ｒｙ

ところでネタを投下してみる。
ID属性の値は大文字に変換されるから、
Strict的にはID値は書くときも大文字じゃないといけないんだが、
みんなちゃんと守ってる？

守ってないお

それはストリクターじゃねええええ！

俺は守ってるぞ。

守ってる。

それより今日は客と電話がすごい来る。
鬱だ……

>>19
言ってる意味が分からん。

xhtmlだと(ryじゃなかったけか?

＞ID大文字
ここらへんだろ。
前スレでIDはASCII文字とか言ってたのは正しくは間違いは間違い。
ちなみにXHTMLに限ったことではない。
ttp://www.akatsukinishisu.net/itazuragaki/id/id_attr_in_HTML
ttp://kaz.topaz.ne.jp/well/kinkyo/2003e.html#DATE1128_01
ttp://diary.petronius.biz/2003_11b.html

>>17
いや、全然違う。どうやったらそこまで強引に結び付けられるんだ？
ぐぐったら一瞬で分かるのに妄想扱いする奴が存在するわけがない。
確かに言葉足らずではあったから、それは謝るけど。


たとえばShort Communicationとかでやってるようなののことを言いたかった。
実際に引用元が存在しない、例示のようなのを引用と見做せるか、という話。

>>26
少なくとも2人はおまえの言葉を>>17のように受け止めてたぞ。

25の参考URLはありがたいけど、レス内の文章はなんでそんなぐだぐだなん？

要点は、
XHTMLでないHTML文書内のid属性によって定義されるアンカーをURLで示すときに、
SGMLの要求からid属性の値が小文字を大文字に変換した上で評価されることから、
大文字で表記する必要があるってことだな。

HTML文書で次のように書かれていた場合、
　<a id="foo">foo</a>
HTMLでもXHTMLでも、これを示すURLは
　......#FOO
となるわけだ。

XHTML使いで文書全体を示す（#以降が空欄の）URLしか書かない人は無問題だな。
>19も>25も言ってることは間違ってると思う。

>>26
どうやったら別の話題と思えるのか分からん。
別の話題だとしたらスレ違いだろ。

>>28
それも違うぞ。
相手から参照されたときの問題があるから、
こっちもidは大文字で書かなきゃならない。

classの件に言及されてる。

http://aa5.2ch.net/test/read.cgi/nanmin/1134779021/182-186

ていうかそもそもどう意味が与えられるって話なの？
<div class="dramatic">としたら「意味なしブロック」が「ドラマチックなブロック」に変わる、っていう意味？
<div class="dramatic">は結局「意味なしブロック」なんだけど、その中ではドラマチックなもの、っていう意味？

<a href="#FOO">飛べ</a>
<a href="#foo">こっちでも飛べ</a>
<p id="foo">どっちでも飛べちゃう？</a>
これでIEは飛ぶけどFirefoxは飛ばなかった。げいん。

>>29
どうやったら別の話題がスレ違いだと思えるのか分からん。

>>33
>>26に被害妄想をきつく指摘された>>17=>>9がカッとなって自演してるんだろ。

と書いたら俺も自演乙と言はれるだらうか。

>>31
例えば定義リストで会話文をマークアップしたとする。
この場合、会話者（dt）はいかに保証されているか？
保証は「定義語」としてされているが、意味としては定義語じゃないだろ。
divにclassで意味づけしても保証されないというのはそれの逆。
保証はされない、だけど意味づけはされる。

>>34
ちなみに>>9=>>17じゃないぞｗｗ
>>9=27だけど。

>>35
なるほど。俺は「話者も定義語の一種」みたいに拡大解釈してる。そのへん発想の違いか。

CSS で 文書とデザインの分離化とか言ってますが…あのCSSのために
文書には無意味なclassやidを付けるのはどうよ？
効率的にやれば何とかならないこともないんだろうが…

classやidはCSSで使わなくても付けてるぞ。
divやspanのようなものじゃなくても、上の会話文なんかも
それとわかにやすいようにさ。

>>33
別の話題"だから"、じゃなくて別の話題"だとしたら"、な。
前の話題を引っ張っているならここに書き込む意味は分かるけど、
>13の話をStrict-HTMLスレでやるのはスレ違いだろってことだ。

>>30
XHTMLではそもそも大文字小文字区別されるだろ。
HTMLでは、Strictとしては小文字で書いても問題はないが、
実際誤解をまねきやすいからやめたほうがいいってことだろ？
"やめたほうがいい"までは要求されるにしろ、やったからStrictじゃない
というわけじゃなかろ、ということだ。

>>31
dramaticっていうラベルがついた意味を持つ、ってことで、
dramaticってのはただの文字列に過ぎないだろう。
ただ、dramaticっていうラベルがついた意味を持つものに対して周りが処理するだけで。

>39に自己レス。
> 実際誤解をまねきやすいからやめたほうがいいってことだろ？
これに加えてブラウザの実装上の問題もあるか。これはスレ
違いとして考慮外にしていいんだろうか、それとも仕様にからむ
話として考えたほうがいいんだろうか。

>>37
使うあてがなくてもつけときゃいいのさ。
あてができたときのために。

>>39
Strict的ってのは少なくとも最低限仕様には沿ってるべきだろうから、
Strictorとしては「大文字でID値を設定すべき」だろ。
誤解を招きやすい云々じゃない。

>>41
img要素は使っても良いけど
Strictorとしてはobject要素を使うべき
ってことと同じだな。

とは言っても未だにimg要素のほうを使ってる俺。
実装を気にせずobjectのほうを使ってる香具師いるか？

>>41-42
brは使ってもいいけど（ｒｙ
どっかで見た展開。

>>43
text/htmlと同じで実際にサイトを作るときまでStrictorで通す必要は無くね？

>>39
> 別の話題"だから"、じゃなくて別の話題"だとしたら"、な。
「別の話題だとしたらスレ違い」なら「別の話題は別の話題だからスレ違い」じゃね？

> >13の話をStrict-HTMLスレでやるのはスレ違いだろってことだ。
「これはblockquoteといえるか」って話ならスレ違いじゃなくね？

>>30
must じゃなくて、recommend だよ。id="foo" と書いても間違いではない。
ただ、リンクする人が href="...#FOO" と書かなきゃならないことになって、
うっとうしいから、最初から id="FOO" と書くことが推奨される。

>>32
id="foo" に対して正しく href="...#FOO" と書いても、たいていの UA は
うまく動かない。でも、IE はたまたまうまくいくんだよな。

>>41
書いてもStrictの仕様に適合するだろ。
仕様に対する違反と区別つかんから、
>42みたいのはStrictor的って言おうぜ。

>>46
つ【>>42-44】
仕様以上のゲンミツを求めるStrictorにとってはmust

はいはい、このスレはxhtml推奨です。
sgmlは非推奨(obsolute)ですので帰れ。

>>45
> 「別の話題だとしたらスレ違い」なら「別の話題は別の話題だからスレ違い」じゃね？
元レス(>>29)確認すれ。
二行目は、一行目の背理法的な説明になっている。
別の話題だとしたらスレ違いだから、同じ話題だとしか思えん、というわけだ。

>>45
> 「これはblockquoteといえるか」って話ならスレ違いじゃなくね？
じゃね？
ただ、過去にpの似たような議論で泥沼になった覚えがあるが、
あれはなんでだっけな。

>>49
>>>1

>>47
そうだな、だから「Strictorとしては」としたつもりだったんだが、
「仕様側の希望には沿ってるべき」と書くべきだったな、すまん。

Strictor的ってのはW3C信者のことなのか
W3C信者を超える信者がStrictorなのか

W3Cを超えようとしてるから信者じゃないって意見もある罠

それでもW3Cに縛られる罠

信者って天動説しか信じないんだろうな

天丼おいしいからな

>>48
＞仕様以上のゲンミツを求めるStrictorにとってはmust

W3CのＳｔｒｉｃｔ仕様を厳密に守るのがStrictorだろ。
仕様以上の厳密って何に対して厳密なんだ。
定義以上に定義に厳密って事はありえない。

>>58
may,should,recommendの類を全部must扱いするってことだろ。

>>59
それは定義に定められた以上の要求で定義に忠実とは言えないだろうな。

お前ら、
別サイトへの target="_blank" は市民権を得たか
http://pc8.2ch.net/test/read.cgi/hp/1135617734/
スレが微妙に盛り上がってきましたお

この世の果てに存在する究極のHTMLを追求するのが、
信者を超えた狂信者としてあるべき姿なのだろう。
聖典は正典にあらず、彼らの理想の中にそれは在る。

という道を貫くのは自由だけど、このスレ的にはStrict仕様
に適合してればとりあえずいいってとこだろうな。
だけど、今回のid属性の話だとHTML4.01仕様はそれ自体が
SGMLと矛盾してるって話だろうから、HTML4.01は
そもそも従うべき仕様ではないということになるんだろうか？

>>62
＞信者を超えた狂信者としてあるべき姿なのだろう。
＞聖典は正典にあらず、彼らの理想の中にそれは在る。

そういえばこのスレって昔からそういうスレだよね。
<br>を使うなとか。

求道的な人はいたが、それが主流ではなかった気がするな。

>>62
> だけど、今回のid属性の話だとHTML4.01仕様はそれ自体が
> SGMLと矛盾してるって話だろうから、HTML4.01は

矛盾はしてないよ。

<h2 id="foo"> という部分にリンクを張りたければ、
<a href="#FOO"> と書けばいいだけ。
これでSGMLの仕様もHTML4.01の仕様も満たし、何の矛盾もない。
ただ、そのことがHTML4.01の仕様書にいちいち書かれてないだけ。

>>65
HTML4.01ではid属性は大文字小文字を区別しないとなってるけど、
SGMLでは大文字に読み替えなさいってなってるんじゃなかったっけ？

それで小文字すると存在しない識別子になっちゃうわけだから、競合
してるから矛盾してると思うんだけれど。

>>66
全部大文字に変換してしまうのなら、大文字小文字の区別はなくなる訳だが。

SGMLでは、要素名や属性名も大文字に変換してから解釈することとなってる。
つまり、<ul> と書かれていても <UL> と書かれているものと解釈しないと
ならない。この規定のため、どちらで書いても同じ意味になる。これを
「大文字小文字を区別しない」と言っても間違ってる訳じゃないだろ。結果的に
そうなるわけだから。

>>66
ttp://www.w3.org/TR/html401/struct/global.html#adef-id
HTML4.01ではid属性はcase sensitiveだぞ。
つまり id="foo" と id="FOO" とは別物として識別されなければならない。
しかしSGMLは id="foo" を id="FOO" であると評価するように言っているので矛盾してしまう。

HTML 4.01 は SGML の掟を破りつつも、仕様書冒頭で
> HTML 4 is an SGML application conforming to International Standard ISO 8879
とのたまっているわけです。

SGML「お母さんはお前をそんな子に育てた覚えはないわよっ！」

ttp://www1.u-netsurf.ne.jp/~7l1rll/SGMLsec14_0.html#2_1
SGMLアプリケーションとしての適合性から見ても、
現在の HTML 4.01 仕様は適合SGML応用とは名乗れないことになるね。

>>50
ごめん、俺の読解力の限界を超えてるのでパス
「別の話題」に罠が潜んでる臭いんだけども

>>67
間違えた。>68の通り"区別する"。

>>72
別の話題なら、スレ違い
だからこのスレに書かれるはずがないから、同じ話題。

>>74
いや、背理法なのは解ってるんだけど、何で別の話題ならスレ違いなのかがさっぱり。
それで何が何と「別」なのかってのが一致してないんじゃないかと。

俺は「>>13の前半が>>9と別の話ならスレ違いだから>>13の前半は>>9に関する話」と読んだが、
「Short Communicationみたいなblockquoteの是非を問う」か「>>9に言及する」かの二者択一じゃなく
しかも2者以外の選択肢はありえないと>>13だけの条件から断言するのは無理だから、何が何だか。
俺なら>>14とはならずに>>15となると思うんだけども。

あ、俺≠>>13ね。
#ていうかもう寝られねー…。

おかしかった。ねぼけてる。
s/二者択一じゃなくしかも//

>>75
俺は広義の引用とか解釈とか言うから法律論かと思って、
スレ違いだと思ったんだよ。blockquote話につなげるなら
スレ違いじゃないだろって言われたのはその通りなんだけどな。

つまり、これまで説明したように書かれたレスであるわけだが、
論旨自体は妥当じゃないってことだ。>17=26=50だって分かってる
のは俺だけだから、「二者択一じゃなく」ってのは承知してるってことは
俺しか分かりようがなかったな。混乱させてすまんかった。

>>68
矛盾させずに考えることも可能ではあるけどね。
SGML応用文書は、SGMLとして解析された後に、SGML応用(この場合、HTML)
が意味付けを行うわけだから、解析と意味付けは別の処理階層にある。

id="foo" と書かれたものは、まずSGMLとして解析され、大文字化されるので
属性値は「FOO」と解釈される。次に、これに対してHTMLとしての意味付けが
行われ、ユニーク識別子が「FOO」であると解釈される。

仕様書は、この「HTMLとしての意味付け処理」の際に、大文字小文字を区別
して解釈するように言ってるんだと考える。実際は、「SGML解析階層」から
「HTML意味付け階層」に渡ってくる時には既に小文字は存在しなくなっている
が、小文字が存在しない文字列に対して、大文字小文字を区別して処理させる
ことは可能な訳で、多少変なことは言ってるが、矛盾はしないと考えられる。

>>78 のつづき

別の例。rel="contens" と書かれてた場合は、まずSGMLとして解析され、
大文字化は起こらないので属性値は「contents」と解釈される。次に、HTML
として意味付けする訳だが、仕様書に大文字小文字は区別しないとあるので、
この段階で区別をなくし、仕様書にある「Contents」と同じ意味と解釈して、
関係が「目次」であると解釈される。

最終的には、id も rel も、大文字小文字は区別されないことになる。ただ、
どの階層で区別がなくなるかが違っている。......という考え方は出来ないかな。
この考え方なら、SGMLとHTMLのどちらかが区別しない規定になっていれば、
区別されなくなる訳で、両者の書かれていることが違っても矛盾しないんだが。

どちらにしろid属性値を大文字で書けば問題は起こらないんだよなあ・・・
やっぱり直すかな。

>>78-79
よく分かった。
HTMLの仕様は一応SGMLとして正しいんだな。

必須の修正箇所は、HTML文書を示すURLだけだよな。

>>81
いや、でもそうすると小文字IDのリンクに対しての大文字URIが大抵のブラウザで移動できなくなる。
実装を切り捨ててこそStrictorかもしれんが・・・

>>78-79
それは屁理屈だと思う。

>>82
URIが（本来の仕様からみて）間違ってても、文書自体は一応strictかな。
大文字化すると、よそからの（小文字のままの）リンクは機能するんだっけ？

>>83
仕様とその理念は別だから、趣旨が一貫しない仕様ではあるけど、
SGMLとして妥当（無矛盾）だという主張それ自体は正しいと思うが。
（それをもってこの仕様に不備はないと主張するのは屁理屈だろうけど）

>文書自体は一応strictかな。
lintで100点とれればbrやhrを使っていいかってのか、このスレの趣旨とは違うだろ。
>大文字化すると、よそからの（小文字のままの）リンクは機能するんだっけ？
ブラウザによる。

俳句や詩って、ストリクト的に言ったら、pre要素じゃね?

って、ふと思った...

>>86
とっくに既出。
前スレだったかな？
ただ自分で書いた詩の場合マークアップもできるだろうね。

意味を言葉に込める。
わざと曖昧にぼかす。
これはStrictの基本です。

>>88
意味わかんね

まんこ

>>88
何処を縦読み?

字に魂を吹き込む

>>85
> ブラウザによる。
となると修正するしないどっちにしても実装の問題が付きまとうから、
これは（実装との兼ね合いになるから）このスレの範疇からはずす
ほかないんだろうな。

新たにわりふるidの属性値を大文字にするのはOKか。

>>93
むしろ「実装を無視しても大文字にすべき」じゃないか？

http://www.ne.jp/asahi/minazuki/bakera/html/opinion/blockquote
に、
blockquote:before{
content: "以下は引用です。";
voice-family: "Announcer", female;
}
blockquote[cite]:before{
content: "以下は" attr(cite) "からの引用です。";
}
blockquote:after{
content: "引用終了。";
voice-family: "Announcer", female;
}
というのがあるけど、これは不要だろ。
これがなくても読み上げソフトが、引用開始と引用終了を読み上げるだろ。

>>95

|ω・`)じぃー…

>>95
何ですかそれは、それはHTMLですか？

「転載」ってどういう風にマークアップすべきだろ。
blockquoteじゃおかしいよな？

>>98
div

>>98
転載は引用とちがって全体のコピーだから
blockquoteじゃ不適切かも、ってことか。

objectかiframeじゃない？

ちょ、待、iframeってｗｗｗ

>>100
引用でも「全文」の場合もあるから、その区分けはおかしいな。
objectなあ・・・置き換えってのも変な話のような。

そうか、どこかに埋め込み用のリソースが転がってなくて、
ある文章やらなにやらをまとめて転載する場合か。
そうするとobjectとかiframeじゃ使えんよなぁ。

Strictスレでiframeが出てくるとは思わなかった罠

>>103
Web文書が転がってるなら、そもそもそれ全部鯖移動だけでいいんじゃないか？

iframe は strict DTD には定義されていないと、はっきり言ってやるか、あるいは、スレ違いなので放置するか。
中途半端なレスすんな。

class="reprint withoutPermission"

>>106
何様

>>98
include

+

pre

こうして見るとpreってStrict的にはとても有効なんだが
なんでかとても虚しい気がする・・・

pre要素使う場合、適当なところで
改行しないと横スクロールバーが出てｳｻﾞｲ罠。

でも改行も「元々の文に手を加えてる」ことになるから好ましくない
というかpreを使う意味がなくなる罠

横スクロールバーが出ないために、CSSを使えるかな？

>>115
そんなのは簡単だけど、
横スクロールバーの問題でもないというか。

ページの最上部に戻るhref="#HOGE"アンカーや
一つ前のページに戻るhref="history.back()"アンカーは
このスレ的にはどうなんですか？

>>117
少なくとも後者はスレ違い。

>>105
むしろ転がってなくてもdataスキームでおｋ

問題
ins要素,del要素はブロックレベル要素でしょうか？　それともインラインレベル要素でしょうか？
あなたはこの問題を解けるでしょうか？

ヒント：div

>>120
インライン要素でもあり、ブロック要素でもある。
しかし、HTML401のStrict DTDでは%inline;の中にINSとDELは含まれないので、インライン要素として使うことができない。
ブロック要素として使う場合もBODYの直下にしか現れることができない。

これはエラッタにも載っていないのでHTML4.01ではINSとDELをBODYの直下以外に書いてはいけない。

XHTML1.0以降ならインラインとしてもブロックとしても使える。

ちなみに
...
<BODY>
<INS>abc</INS>
</BODY>
...
というのも仕様違反にならない。

「」はCSSで実現したほうがいいでしょうか？

Webサイト制作初心者用質問スレ Part 151
http://pc8.2ch.net/test/read.cgi/hp/1136430362/

>>122
>しかし、HTML401のStrict DTDでは%inline;の中にINSとDELは含まれないので、インライン要素として使うことができない。

それじゃあ、
<p>僕は、<del>12月2月</del><ins>1月2日</ins>に天皇陛下万歳をした。</p>
と言う風には、使えないってこと？

>>124
qの引用符はCSSで。

>>124
qの引用の場合は、
「<q>なんとか</q>」
ではなくて、
<q>なんとか</q>
引用符は、ブラウザが自動的に付ける。

>>126
その使いかたが正しい。

>>124
視覚系ユーザエージェントは、Q要素の内容を、引用符で囲ってレンダリングするようにしなければならない。著者は、Q要素の開始点と終了点に引用符を置かないようにする必要がある。

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/text.html#h-9.2.2

あと、qには「は要らないけど、citeには(は要る。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/text.html#h-9.2.1

qの「」はブラウザが行う。
citeの()は自分で（作者）が行う。

ブログに関してなんですがパーマネントリンクのURLはA要素を使ってリンクさせるべきなんでしょうか？
もしその場合、
<hn><a href="http://パーマネントリンクのURL">エントリ名とか</a></hn>
とするのか
<a href="http://パーマネントリンクのURL">パーマネントリンク</a>
とするのか
<a href="http://パーマネントリンクのURL">http://パーマネントリンクのURL</a>
とするのか
どれがいいんでしょうか？それともこれら以外の別の方法でしょうか？

>>133
<a href="http://パーマネントリンクのURL">エントリ名とか</a>
か、
<a href="http://パーマネントリンクのURL">パーマネントリンク</a>にtitle属性でエントリ名

同じリンク文字？アンカー文字？で複数のページをリンクするのは駄目だから、title属性がいる。

>>118 前者は？

うんこ

>>117
前者はいいよ。
後者はJavaScriptだから、無効にしてたら意味ないから駄目。（ブラウザで）

>>126
仕様書のINSとDELのところを見ると使えるっぽいが、DTDによると使えない。
多分DTDのバグ。XHTML1.0だと修正されてるし。

>>132
なあ、それって<cite>（ＸＸＸ）</cite>なのか？
それとも（<cite>ＸＸＸ</cite>）？
前者だと括弧含めて引用元のようだし、
後者だと（）のテキストとしての意味が引用符と同じになると思うんだが。

>>139
お前、DTDの読み方、分かってないだろ。

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL)>

後ろに、+(INS|DEL) と書かれているのは、BODY要素の子孫要素すべてに
INSとDELが書けるという意味だぞ。つまり、どこにでも書けるってことだ。

<!ELEMENT BODY O O (%block;|SCRIPT|INS|DEL)+>

と勘違いしてないか？　ちなみに、XMLでは、DTDに、こういう添加要素を
書くことを禁止している。だからXHTMLのDTDでは書き方が変わっている
だけだ。その結果、

<ul><del><li>ほげ</li></del><li>ほげ</li></ul>

はHTML4.01ではvalid。XHTML1.0ではnot validとなった。HTML4.01だと
ULとLIの間にさえDELが書けてしまう。

>>136
しかし、ページの一番先頭に戻るってのは、本来はUAの仕事じゃないのか。
たいていのブラウザは、キーボードの [HOME] キーで戻れるぞ。lynxは
Control-A だったかな。いちいちリンクで書くのは変だとは思うけどな。

>>141
HTML4.01でもul直下にはulを一個以上しか置けないだろ。

>>143
HTML4.01では、ulの内容モデルはliが一つ以上と指定されているが、その
祖先要素のbody要素でdelが添加要素と指定されているので、結果、ul直下に
delが書ける。>>141 で書いたように、添加要素は子孫要素のすべてに追加
されるからだ。

ただ、ul直下にdelは書けるが、delの直下にliは書けないので、
>>141 は間違ってた。すまん。

<ul>
<del><p>ほげ</p></del>
<li>ほげ</li>
</ul>

これにしてくれ。これで、HTML4.01でvalid。W3Cのvalidatorも通る。
当然、

ああ、送信されてしまった。当然、XHTMLではnot validな。

DTDにはvalidだけど仕様にはinvalid >>144-145

>>146
でも仕様書では「インラインとして働くins/del内に、ブロック要素を
入れるな」とあるだけで、それ以外の使い方については禁止されてないん
だよな。まあ、想定された使い方ではないとは思うけど「仕様にはinvalid」
と言うだけの根拠はない。グレイゾーンだと思う。

ttp://www1.u-netsurf.ne.jp/~7l1rll/SGMLsec10_0.html#ex138
SGMLではこの辺の話か…。

>>144
祖先要素よりも子孫要素の特殊性のほうが優先されなかったか？

>>149
HTMLにそんな特殊な要素はないと思うが。

つーか実際衝突してんだろ？del/ins

ひとつの文章を消すときは、
<p><del>なんとかかんとか。</del></p>
か、
<del><p>なんとかかんとか。</p></del>
のどっち？

>>144
>delの直下にliは書けないので、
リストのひとつを消すにはどうしたらいい？

<ul>
<li>のびた</li>
<li>スネ夫</li>
</ul>
ののびたをけしたいときは。

>>122
>HTML401のStrict DTDでは%inline;の中にINSとDELは含まれないので、インライン要素として使うことができない

どういう意味？

>>152
p要素の内容全部を消すんなら後者の方がいいと俺は思う

リンクとアンカーってどう違う？

糞仕様なんだから我慢汁

>>153
ulの下にはliしかダメとなってるから、
DTDにバグがあろうと衝突してろうと
<ul>
<li><del>のびた</del></li>
<li>スネ夫</li>
</ul>
だろ。

<li><del>のびた</del></li>
はどういう意味？
のびたが居たこととか間違えたことを残したいという気持ちが強いという表現？
もし、
<del><li>のびた</li></del>
がいけるなら、これは、始めのよりも、残したいという気持ちが弱い表現かな？

しずかちゃんを好きなのは、下の者。
<ul>
<li><del>のびた</del></li>
<li>スネ夫</li>
</ul>

だと、のびたはしずかちゃんを好きではなかったことになるけど、
その場合、上のリストは、
<ul>
<li></li>
<li>スネ夫</li>
</ul>
こういうことになるよね。
画面表示ではなくて、意味の上では。しずかちゃんを好きなのは、スネ夫だけ、ということだから、画面表示ではなくて、意味の上では、
<ul>
<li></li>
<li>スネ夫</li>
</ul>
だよね。

以前好きで、今は好きではない場合は、
<li><del>のびた</del></li>
がいいと思うけど、最初から好きではなかった場合は、
<del><li>のびた</li></del>
がいいよね。

>>159
いけない。
気持ちの問題ではなく、仕様上はulの直下にはdelは置けずliのみ。
だから
<li><del>のびた</del></li>
しかあり得ない。
DTDが間違ってることに気付いたからXHTMLでは修正されている。以上。

ふぅ…
なぜかCSSがうまく適用されなくて
散々ソースとにらめっこすること数時間
やっと原因見つけました

<div calass="…">

カラスって orz

>>163
http://openlab.jp/k16/htmllint/htmllint.html
http://jigsaw.w3.org/css-validator/validator-uri.html
でチェックしたらよかったのに。

あ　そんな追い討ちを

>>151
何も衝突してないよ。
HTML4.01では、ulの子としては、li、ins、delの3つが書ける。仕様では
そうなってる。liは1個以上必要で、insとdelは0個以上だ。

この事実が「ulの子はliしか書けない」ことと衝突しているというのなら、
pの子としてins/delが書けるのは、「pの子はインラインしか書けない」
ことと衝突してるというのか？

>>162
訂正が出てる訳でもないんだから「DTDが間違っている」なんて言う根拠は
ないよ。XHTMLで書き直されたのは、その書き方がXMLでは禁止されている
からだよ。

>>166
インライン要素の中ではins/delはインラインとして振る舞う。
だからpの子としてens/delが出てきても不思議はない。
だがulの直下にins/delが出てくるのは間違い。

てか、またループするの？

そうよいつまでも

　あ┃な┃た┃は┃無┃限┃ル┃ー┃プ┃が┃
　━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛
　好┃き┃で┃す┃か┃？┃…┃…┃
　━┛━┛━┛━┛━┛━┛━┛━┛

日本語としては「ですか？……」よりも「ですか……？」のほうがvalidだと思います。

>>171
日本語としては「？」はいらない

>>172
そうですか……
↑

>>171
ですか？……
が正しい。
理由は、

な　い　。

海外から輸入された「？」を日本語としては必要ないとしたら
ほかにも明治時代などに輸入されて
それに漢字を当てはめて作った多くの単語（「科学」「政府」「選挙」「機械」「社会」などほかにもいっぱい）
も使えなくなりそう

あと
> 一般には、疑問文の最後に、終止符に換えて置かれる。
（「Wikipedia」より）
そして
> 好奇心旺盛な猫の尻尾と肛門がデザインの元になったという説が有力。
（「Wikipedia」より）
ee-!?

ちょ、何その成立ｗｗｗ

今後「？」を使うたびにアナルを想像してしまいそうにゃーん

Strictと何の関係が……？

>>173 疑問文なのか疑問文じゃないのか、DOTCH!?

ＤＯＴＣＨ


？？？？？

「！」は驚いた猫の尻尾と肛門がデザインの元になったという説が有力なのかと思って
興奮しながらWikipediaで調べたら
>>ラテン語のioの、2字を縦に重ねた合字である。
とあってがっかり。

どっちの料理ショー
DOTCH COOKING SHOW

「ラテン語のio」ってなんだろね。

>>184
ラテン語でいうところの猫の尻尾とアナル

納得汁だく

>>167
<ul><del> が駄目というのは、<del><li> が駄目だから。
del, ins は、body の子孫として、どこにでも出現できる可能性はある。

<!ELEMENT UL - - (LI)+>
これはulの下にはli1つ以上のみって意味だろ？

>>188
ループすんなって。>>141, >>148 を読んでからしゃべれよ。

>>188
www.kanzaki.com/docs/html/read-dtd.html
の、例外についての注意、という見出しに続く部分が読みやすいかな。

みんな親切ですね

>>189>>190
ごめん、よくわからない。
その例外規則は知ってるんだけど、
>The INS and DEL elements must not contain block-level content when these elements behave as inline elements.
ってことだから、p>ins>ulが許されないように、
ulの下にはliと定められた規則を、その例外が侵すことは許されないんじゃないのか？
>>190の紹介してくれた神崎さんとこの
>HTMLのルールは、DTDだけでなく仕様書の本文も合わせて規定されているのです。
ttp://www.kanzaki.com/works/2002/pub/wsd05.html
を見て、ずっとそう思ってたんだけど。

>>192
「いちいち書かないけれど、+(INS|DEL) ですから気をつけてください」
ということで。

結局、問題として残るのは、>>147だけ。
一般に、例えば、>>123は正しくないということになっている。
つまり、>>147の言うグレイは全て黒とされている。

一般に黒とされているとは、要するに、簡易判別として、del, ins の開始終了タグを取り除いてもvalidであることが必要。
その上で、del, ins の内容モデルに適合しているかどうかを調べなければならない。
(多くは、簡易判別だけで判定できる。できないのが、例えば、<ul><del><li> という不適合である。)

仕様の 3.1 に書かれているが、まず、SGML宣言。そして、DTD で具体的に定義する。表現できない(し難い)部分を、仕様の文章が詳説する。
しかし、肝心の詳説が <p><ins><div> の例示だけなので、ちょっと困っているわけだ、>>147の言うように。
「一般に」この例示が「ごく自然な形で拡大解釈」されて運用されているから、>>123 は黒だ、ということになるのだろうが、もっと強力な根拠が欲しかったということ。

>>192
君の言うことが正しいとしたら
ins del が例外として body 云々規定されている意味がなくなると思うが

>>193
すまん。よくわからん。

>>194
ああ、なるほど・・・
じゃあDTD/仕様的に、は置いといて、Strictor的にはどうなんだ？

>>195
ブロック要素としての
<del>
<p></p>
<blockquote></blockquote>
</del>
なんてのと、インライン要素としての
<p><del></del><p>
が可能になる、という意義がある。
というかこっちがメインであって、文法的な例外を侵させるための非常手段じゃないだろ？

>>192
> p>ins>ulが許されないように、
これは>>194の簡易判別に該当する。
例えば、<ul><ins><p> は許されない。

>>197
それは知ってる。

>>194
仕様書で禁止されているのは「インラインとして働くins/delの中にブロック
要素を書くこと」だけだから、そのまま解釈すると、「インライン要素しか
含まないins/delはどこに書いても違反ではない」となってしまう。

結局、「ul直下のdel」などは、「仕様には反しないが、Strict的ではない」
という言い方しかできないと思う。「div直下のインライン」とかと同等だ。

>>199
�d。
やっぱりそれでもStrict的ではないんだな。
精進します。

画像掲示板やお絵かき掲示板、また商品検索ページなどにある
<<前へ [1] [2] [3] 次へ>>（場合によっては「<<先頭へ <<前へ [1] [2] [3] 次へ>> 最後尾へ>>」など）
といったナビゲーションはどのようにマークアップすべきなんでしょうか？
単純に
<ul>
　　<li><a>前へ</a></li>
　　<li><a>1</a></li>
　　<li><a>2</a></li>
　　<li><a>3</a></li>
　　<li><a>次へ</a></li>
</ul>
として横並びや「[」・「]」などの記号はstylesheetで出せばいいのかなと思ったのですが
ページが数字順なので
<ul>
　　<li><a>前へ</a></li>
</ul>
<ol>
　　<li><a>1</a></li>
　　<li><a>2</a></li>
　　<li><a>3</a></li>
</ol>
<ul>
　　<li><a>次へ</a></li>
</ul>
としたほうがいいのかなと思い始めたりして混乱してきました。

むしろこうするとか
<ul>
　<li><a>前へ</a></li>
　<li>
　　<ol>
　　　<li><a>1</a></li>
　　　<li><a>2</a></li>
　　　<li><a>3</a></li>
　　</ol>
　</li>
　<li><a>次へ</a></li>
</ul>

>>201
strictではなくユーザビリティの話になっちゃうけど、「前へ」「次へ」よりも「古い方」「新しい方」の方がいい。サイトによって古い方が前だったり新しい方が前だったりして混乱する。

strictの観点から言うと、「前へ」というのは「前へ行く」という動作を表しているからアンカー名としては好ましくない。

ても掲示板の場合だと、古い順新しい順でソートできるの多いから、
そうすると「古い方」「新しい方」ってどっち？になるとオモ。

商品検索の場合も、価格の高い順・安い順、在庫の多い順・少ない順、とか
いろいろだしさらにソートできたりするから「前へ」「次へ」が無難な希ガス

商品検索とかならサーバサイドプログラムを使うんだろうから
ソートしたものにあわせて「より古い」「より新しい」とか「より安い」「より高い」とか書き出すように設楽？
んでマークアップに関しては>>201の上記のやつでいいと思うけど

リンクタイプも指定
<a rel="next" href="...">

strictの信者って何で他人のソースまで見てけなすの？
IEとMozillaで表示できてればいーじゃん。

talk:>>208 Operaを忘れるな。

ハァ？Mozilla？Opera？
パンピーはそんな物知らん。
「青いeのアイコン=いんたーねっと」

つまりIEで表示できてれば、社会的に無問題。

青いeのアイコンがIEだと理解してるのはごく一部のオタ。
MozillaやOperaを知っているなんて、もはやキモオタのレベルに達している。

つまり知っている>>210がキモオタということだな。

すいません。。
Hp作ってるんですが教えてもらいたいことがあるんですがいいですか？

Hpを作っていると全部左よりになっちゃいます。
真ん中にしたいんですけど画像もテーブルも左よりです。

真ん中にするにはどうしたらいいんですか？

どなたか教えてくださいorz

>>212
ここは質問スレじゃないんだが・・・まあいいか。

1.DOCTYPEを公開識別子とシステム識別子にして標準モードにする（これをしないとIEが動かない）
ttp://www.remus.dti.ne.jp/~a-satomi/bunsyorou/Doctype-Switch_situation.html
2.センター寄せしたいブロックにwidth:80%;などと幅を指定する。
3.そのブロックにCSSでmargin:auto;を指定。

おおおおおおおお！！！

すごいですｗｗｗｗ

ありがとうございましたｗｗ
まぢ天才ですねｗｗｗ

後質問スレじゃないのにここに書いてしまってすいませんorz

まぢで助かりましたｗ
ありがとうございましたｗ

1分で>>213を理解して試せた>>214の方が天才だ！

>>215
ほんとだ、たった一分だ。
一分で読んで理解してレス考えてうてるかな？
なんかできすぎ。

僕のこと呼んだ？

>>202に一票

>>206
「より」は不要。

abbrやacronymの中身は小文字で書いて
text-transform:uppercase;などで大文字化するほうがいいんですか？

アホか…。

画像と文章を混在させるときは

１　<p><img src="">Fig.1のように・・・
２　<p><img src=""></p><p>Fig.1のように・・・
３　<div><p><img src=""></p><p>Fig.1のように・・・・

のどれがStrictですか

<a href="...">Fig.1</a>のように……

>>222
そんなのは画像の「意味」によって違う。
一段落内で画像が必要なときはpの中、
段落が分かれると思うならそれぞれpにすれば。
divはまた別の次元なんてセクション化したければ付ければ。

XHTMLではhttp-equivは使用しない方が良いそうですが、HTMLでの
<meta http-equiv="Content-Type" content="text/html">
や
<meta http-equiv="Content-Style-Type" content="text/css">
等はどこに記述すれば良いのでしょうか？

HTTPヘッダ

>>225
Content-Typeはともかく、Content-Style-Typeはそのままmeta要素でいいだろう。

>>227
xhtml basicでは非推奨じゃなくて禁止されていた　と思う

>>228
どこに書いてあるの？ 仕様書を覗いた限りではそれらしき文言はないように見えるけど。

>>229
横からすまんが、これのことじゃないかな。
ttp://www.w3.org/TR/xhtml-media-types/

>>228
SHOULD NOT だから禁止まではされてないな。

というかそもそも「禁止」って表現ってあるの？
非推奨（すべきではない）までしかなくない？

MUST NOTがあるじゃん

>>231
仕様書の「ILLEGAL EXAMPLE」とかは禁止だぞ。

>>232-233
サンクス

application/xhtml+xmlって書くのはxhtml1.1とxhtmlBasicだっけ

>>235
XHTML1.0も原則はapplication/xhtml+xml。XHTML1.0の場合は
仕様書の付録C. HTML Compatibility Guidelinesの事項を守った場合、
text/htmlと名乗ってもよい、というだけの話。

つまり、MINE型が text/html の場合は「XHTMLもどき(書式だけXHTML)」ということ？
「application/xhtml+xml」なら完全なXHTMLなのでしょうか…

>>201-207
この辺をユーザビリティ的な寒天ではなくstrictな寒天でのよりベターな方法が知りたいです。

>>238
prevへのリンク、1ページ目へのリンク、……、最後のページへのリンク、nextへのリンクという順番は構造としてはおかしい。
たしかに画面上ではツールバーと同じ順番になるのでわかりやすいのだが、構造としては相対的なリンクはそれでひとまとめにして、絶対的なリンクはまた別のまとまりにするべきじゃないだろうか。

>>237
strictorの建前としては、前者はHTMLであり、後者はXHTMLでしかありえない。

10000円以上購入でプレゼント！
http://www.bk1.co.jp/contents/campaign/10000p.asp

>>239
たとえばこんな感じ？

<hn>ページ一覧</hn>
<ol>
　　<li><a>1ページ目</a></li>
　　<li><a>2ページ目</a></li>
　　<li><a>3ページ目</a></li>
</ol>
<hn>ページナビゲーション</hn>
<ul>
　　<li><a>前へ</a></li>
　　<li><a>次へ</a></li>
</ul>

>>242
そう、で、表示は適当なスタイルシートがやる。

同じ機能を別々のセクションに分断する構造もおかしい気がする。

じゃあどうすればいいの

じゃあやっぱり>>202かい？

じゃあこれで

<div>
　　<hn>ページナビゲーション</hn>
　　<ol>
　　　　<li><a>1ページ目</a></li>
　　　　<li><a>2ページ目</a></li>
　　　　<li><a>3ページ目</a></li>
　　</ol>
　　<ul>
　　　　<li><a>前へ</a></li>
　　　　<li><a>次へ</a></li>
　　</ul>
</div>

>>245-247
「じゃあ三人衆」

>>245-248
4人衆っす

折角のXHTMLなんだし、classで語彙なんて設定しないで
名前空間切って独自の要素を作ってこうぜ。

どうせXHTML内の語彙だけじゃ外からデータ引っ張ったり出来ないんだしな。

そんでもってよさげなセットが出来たら教えてくれよ。

DTD書くのマンドクサ。

整形式なら書かなくてもいいんじゃなかったっけ？

プルグラムのことはよくわからないんですが
classってプルグラムでは使えないんですか？

まるでIEのカスタムタグだな

>>250
専用スレ立ててくれ

http://www.schemaweb.info/

RDFならあるでよ

>>254
最低限HTMLとして読める分だけ保証してて、かつ
規格に載っとった方法で拡張してくれれば
カスタムタグおおいに結構だと思うんだけどね。

汎用的に定義されてる要素の意味を考えてグダグダやるんだったら
作っちゃった方が早いって。

<html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:2ch="http://pc8.2ch.net/test/read.cgi/hp/1136304961/"
 xml:lang="ja-2ch" >

兄ちゃん、Name生成規則は数字からは始められないと(ry

より正確にはNCNameと

DTDを作らんとXHTMLとは言えない。

おいおい…。

>>261
あなた、どこのボケナスですか？

Dublin Coreみたいなのって普及しないな。
語彙なんざ作っても処理するプログラムがなかったら意味ないわなぁ。
それともあれか？ソース直接読むのか？

そんなことより俺のstrictなulの使い方の話をしようぜ。

>>261
XML Schemaでもいいんじゃなかったっけ?

遠慮しとくよ。
そんなことより俺のstrongなchinkoの使い方の話をしようぜ。

smallな、の間違いだろ？

delな、って間違いだろ？

>>267
smallはXHTMLではinvalidな要素です。

invalidな要素ってお前…。

>>269
お前は世論を敵にした

>>269にはchinkoがある

みなさま、オレのchinkoはsupです。

>>261
XML SchemaよかDTDの方が書くの楽だぞ。

ところで、IE7のdoctypeスイッチはまともになったのかな？
xml宣言書いても大丈夫になった？

実装の話といえば、W3C標準スレ落ちてしまったのよなあ…。

某資格の問題
次の記述が妥当であれば○、間違っていれば×をすること。

「XMLはW3Cから勧告されているが、HTMLはISOで勧告されている。」

>>275

> XMLはW3Cから勧告されているが、HTMLはISOで勧告されている。
だと「が、」の部分の解釈が判断に困るな。
まるで、HTMLはW3Cから勧告されていないみたいだし。

ただ、

> XMLはW3Cから勧告されている
この部分は○

> HTMLはISOで勧告されている
この部分も○
(HTMLはW3Cから勧告されているが、ISOでも勧告されている。）

なので、この問題の答えは「○」でいいんじゃないだろうか。

ISOでも「勧告」なのか。

>>275
なんつー資格？

Web Authoring Statistics
ttp://code.google.com/webstats/index.html

GoogleのWebオーサリングに関する統計。
どんな要素や属性、属性値などがよく使われているのか分かる。結構興味深い。

ちなみにSVGが必要。Firefox1.5では見られたけど、IE6+SVGViewerでは見られなかった。

>>279
class="small"大杉

>>279
GoogleはWeb標準をもうちょっと意識して欲しい。
活動自体は有益だけど、自分のサイトがテーブルレイアウト、DTD無し（あるいは非準拠）、非推奨要素の連発だからなぁ。

だいたい、そのページのDOCTYPE宣言なによ。
<!DOCTYPE HTML>

意味不明。

リンク切れも多いしな
何であんなに適当な作りなんだろう？

talk:>>281 DOCTYPE宣言を書いて文法違反をされるよりは遥かにマシなのだろう。HTMLをきちんと書けないことが最初に分かっていいじゃないか。

それにしても寒いな。

久しぶりな流れ

talk:>>284 お前誰だよ？

>>286,284
お前たち誰だよ？

test

でた！この、パターン！！

おい、数学の課題やったか？

talk:>>290 算数と間違えていないか？

talk:>>291 あひーっ！

talk:>>287,>>289,>>291-292 お前誰だよ？

Re:>>291 まちがえちった

愚鈍GiantLeavesとか

誰が本物？

・sageない
・talk:を使う
・文章が常体でちょい固い

えーと誰が本物かな…

talk:>>297 お前は賢くないな。

>>292はグッグ

なんかつまらん流れだな。

どうせ誰が本物だろうが偽者だろうが読み飛ばすしな。

talk:>>295-296,>>298 お前誰だよ？

talk:>>301 そう言うな。

talk:>>299 あひーっ！

iウエヴのオカゲで、ドトマクがものスゲぇ売れてーるでよ。でも、iウエヴはこのスれてきにはスゲぇHTML(読めねぃ)を、はーくそうでよ。

talk:>>303-304 お前誰だよ？

>>6fN.Sojv5w
おまえが誰かにこだわってんのお前だけだよ！！そろそろだまれよ！！

日本語が変だ

お前らもな

つーかこんなんがおもしろいと思っているバカがいるのか・・・

talk:>>309 お前何様だよ？

>>304
新マク板にグッグのスレがあるでよ。
アプールのサイトは昔はモダンだたけど、今では古くさい感がいなめねぃてすよ。
iウエヴ共々そろそろStrict(読めねぃ)になって欲しいでよ。あひーっ!

もうこのスレの役目は終ったな。

talk:>>306-308,>>310 お前誰だよ？

talk:>>312 そうだな。

talk:>>310,>>313-314 お前誰だよ？

チラシの裏みたいのをpreでマークアップするのってどう？

これは好き
あれは嫌い

明日は晴れるかな
いや、曇りかな

って内容だったら
<p>これは好きあれは嫌い</p>
<p>明日は晴れるかないや、曇りかな</p>
だと前後の文が混ざって意図した意味をマークアップ出来てないし


<p>これは好き</p>
<p>あれは嫌い</p>
<p>明日は晴れるかな</p>
<p>いや、曇りかな</p>
だと全ての段落で一意性のあるもののようにマークアップされてるし

チラシの裏みたいな文章は改行一つと二つに明確な意味はなくても、
何かしらの差を持たせてるんだとおもうから、ありだとおもうんだけど

自分は

<p>これは好き<br>
あれは嫌い</p>

<p>明日は晴れるかな<br>
いや、曇りかな</p>

とするね。

そもそも「、。」の句読点のない文章が日本語としては構造化されてない状態だからなぁ。
ぢからチラシの裏なんだろうが、でもそれでも「改行に意味を持たせたかった」のなら
日本語では形式段落に当たるような気がするがね。

調べてみたけど

http://deztec.jp/lecture/cl/html_p.html

このサイトの説明が一番理が通ってると思う


<p class="新しい段落">これは好き</p>
<p>あれは嫌い</p>
<p class="新しい段落">明日は晴れるかな</p>
<p>いや、曇りかな</p>

ってなんのかな
クラス名が日本語なのはnew_paragraphとかにしちゃうと、もともと <p> が新しいparagraphを示してるのと被っちゃうから

ああ、それ昔読んだ。
pとaddressについてはちょっと特殊だよな。

>>279
cssファイルのファイル名の統計とかはないですか？

Results 1 - 10 of about 474,000 for inurl:style.css. (0.29 seconds)
Results 1 - 10 of about 10,700 for inurl:default.css. (0.18 seconds)

main.css の検索結果 約 242,000 件中 1 - 10 件目 (0.26 秒)

stylesheet.css の検索結果 約 242,000 件中 1 - 10 件目 (0.22 秒)

style.css の検索結果 約 1,680,000 件中 1 - 10 件目 (0.29 秒)

filetype:使えばいいのに

なぁ、俺たちは電話線でつながっているんじゃない！
心でつながっているんだよ。
それと、俺たちは今、他人だね・・・。出会ってもいない。
世界は広いよね。

>>327
もっとStrictに

inurl:style filetype:css の検索結果 約 2,250 件中 1 - 10 件目 (0.84 秒)

これ読んで、勝手にネームスペース切って変な要素切っても
あんまり意味ないなと悟った。

やっぱいくらStrictだろうと処理する何かがなければ
ただのオナニーなんだよな…。
まあ、気持ちいいからやれられないんだが。

ttp://po3a.blogspot.com/2006/01/xml.html

やれられないならしょうがないな

気持ちよすぎてろれつ回らなくなっちゃったんだな

ローカルのものまでStrictにするのはもう病気だと思う。

いや、ローカルこそStrictだろ？
だってマークアップ簡単じゃん。
自分用だったらCSSも要らないし、どっかのユーザCSS被せてもいいし。

>>334
それはあるが、自分が見るだけだったら
別に素のテキストでもいいような気がしないでもないが。

文章の一部強調したりとかわりとどうでもいい。
h1とpとulとliとaとまあblockquoteあたりがあればそれでいいや。

あとで見直すときに、どういう意図で書いたか忘れることが多いから
emやqなんかはプレーンテキストでも付けてるな。参考文献に無意味なa hrefとかｗｗ

あー、emとかは相手が分かりそうならメールでもたまに使うなぁ。

プレーンテキストだったらWikiの記法レベルでいいんでないの？

俺が書き殴った文章に対して、
俺のクセにあわせて正確に意味を読み取って適切なマークアップをして
validでstrictな(strictなってなんだ？)HTMLを吐きだしてくれる
プログラムがほしい。

だからWikiってそこらじゅうに俺様記法なクローンが転がってるんだろうけど。

HTMLエディタに形態素解析器をつけないと。

emとstrongの使いわけに拘るのはどうかと思うよ。

wiki使ったことない俺にはちんぷんかんぷん

>>340
実際strong廃止されるらしいな。
まぁそれでも個人的にはem>emを使うけど。

>>339
日本人を雇うってのもありかもな。
そこらの高い業務用の買うより安上りかもしれん。

TXT形式だと

-------------------------------------------

↑

途中送信してしまった。
言わんとしている事はなんとなく感じてくれ。

ネタ狙いの強調はem、真面目な文での強調はstrongと、使い分けてるし使い分けたい。

どんなツールで書き込みしようとしてたら途中送信なんて起こるんだろう？

個人的にはemをinlineにしてstrongをblockにすればいいのにと思う

>>341
行頭ハイフンでリストとか、
*で囲んだ文字列は強調とか、
改行が二個続くとパラグラフ切り替えとか。

みんなで書けるとか、リンクが簡単に張れるとかよか
適当な文章をちゃんとしたHTMLに変換してくれるのが一番助かる。

一度自分でHTMLのテンプレっていうか、
こういうときはこう書くってルールができたら
直でHTML書くより自分用の変換ツール作って
そいつに掃き出させたほうが効率がいい。
てかそうでないとやってられん。

プレーンなら強調なんか「　　　」でいいじゃない

>>348
それよりcodeのblock版がホスィ・・・

>>349
�d。
でも覚えるのがメモリ4byteの俺にはムリポ・・・
もう覚えてる要素のがいいや。

>>347
ＩＥやrep2、p2なんかだと、タブキーを押してスペース押すと書き込み。

>>348
それいいな。
この文節を強調したい!みたいな？

しかし、addressってなんかやだなぁ。
emとかstrongって*強調*なわけで、何で強調してるかは
他で意味付けしたりとかするわけじゃん？
プリミティブでいいよね!

それに対してaddressは。
住所かよ。なんかレイヤが違くないか？
codeとかもなんかやなんだよなぁ。

意味付けならadress要素あるくらいならnavi要素が欲しい。
グローバルナビとかページナビ（next, prev）とかパン屑につかうよーなの。

まあでもさ、要素を手書きしてると、手段と目的とっちがえてるような
気がしてこない？
WWWにacronymとか使ってる奴とか特に。

>>351
だから、みんな覚えるのが面倒だってなって
自分で勝手記法作ってしまうわけやね。

以外と結構簡単に作れるうえに
なんかこのままいけば時代の先端じゃん？Web2.0越えちゃうじゃん？
みたいな錯覚を覚えるから雨後の竹の子のように似たのがあふれる。

なんか今夜は盛り上がっとるな。

酒だぁ！酒を持って来い！

>>354
link rel="prev" とかは？topとかprevとかindexとかappendixとかもあるでよ。
IEは拾ってくれないけど。ってFirefoxも拾ってくれないのかよ。
Mozillaの頃はちゃんとナビゲーションバー出してくれてたのにな。

>>353>>354
addressは意味的にナビ用に用いてもいいと思うがな。
ブロック要素が入れられないというのが痛いが、objectで・・・これも何だかな。

>>355
もはや<abbr title="Cascading Style Sheets">CSS</abbr>とか
ATOKに単語登録してあるのがプレーンテキストで出てくると（ｒｙ

勝手表記作るってーとXMLの似たような問題を思い出すな。
それくらいだったら長いこと大勢で議論されて考えられた（不備はあるにしろ）
従来のHTMLの要素を意味づけに使ったほうが個人的には好ましい。

>>355
面倒なのはxhtmlが悪いんでなくてxmlが長ったらしいから
lispもどきの構文にすればええ

>>359
addressみたいなのって結局そうやって書き手によって微妙に
使われかたがぶれてるのがやだ。

ちゃんと規格にそってるよっていっても
なんかこう間違いを併発しそうな感じもやだ。

にしても、ウェブアプリとかの、画面を文章というよりかは
UIとして見做すような案件ってマークアップ大変だよね。

バグばっかでしかも完全に自由自在じゃないcssなんかで段組するよか、
tableのレンダリングをそのまま使えるhtmlとは別の名前空間の
レイアウト用のセットが欲しいよ。

>>362
自然言語が曖昧である以上、
それをマークアップする規格だって当然緩やかであらざるを得ない。
addressどころかpでさえ人によって使われ方が違う件。

>>362
ていうかレイアウトと意味づけは関係なかろ

>>358
んー、特にページナビゲーション関係は一応rel属性でprevとかnextはつけてるけど、
こう、属性じゃなくて要素としてナビゲーション関係のモノをガッとくくってしまいたいというか……。
webページでナビゲーションリンクがないページってほとんどないだろうから、
あってもいいんじゃないかと思ってしまう。

>>361
一覧表みたいなのにするんだったらYAMLとかってのもあるらしいな。
まあ文章書くのには使えんのだけど。

lispでもたいしてかわらなくないか、って言おうと思ったけど
書いてみたらちょっとキモかった。

(h1 lispでHTML)
(p 誰かがすでに考えてるであろう (em lisp風HTML) はキモかった)

・・・・うん、それはビミョ・・・

>>358
スマン、link要素の方のことね。
あれはあくまでもwebページのメタデータであって、
webページに表現されてる（？ body要素内）ナビゲーションは別に必要だと漏れは思ってる。
現実問題としてメジャーブラウザで使えないってのもあるし。

>>364
HTMLのtableをレイアウトに使えっていってるわけじゃないのよ。

HTMLとはセットを換えてるのよ。
firefoxのXULみたいなやつね。。
HTMLは文章構造をマークアップするけど
そっちの言語はレイアウトをマークアップするわけね。

UIにとっちゃレイアウトもれっきとした"意味"。

>>368
確かに。
その要素使っておけば、はやりすたりにあわせてUAが勝手に
パン屑リストとかプルダウンとかマウスホイールで切り替えたりとか
その時々の旬な方法で表現してくれるとなおいいな。

>>366
まとめサイト?のwiki構文とかは?
ttp://www4.pf-x.net/~nazodane/cgi-bin/index.cgi/Strict%20HTML%E3%82%B9%E3%83%AC%E3%81%AE%E3%81%BE%E3%81%A8%E3%82%81%E3%82%B5%E3%82%A4%E3%83%88?mode=source

おまえら月曜の夜中から暇そうだな。

>>371
リンク切れてない？

>>372
中二病なんだよ。ほっとけ。

>>373
一様繋がってるけど(更新はされてないみたいね)

一様・・・

Firefoxじゃないと繋がらなかったぞ。いやがらせか。

>>371
これって >>366 のやつと括弧の種類しかかわらんじゃん。
キンモー☆ミ

>>378
区切りがカンマってだけでもましだけど

すまん、どこで訊いていいかわからないがここが適切のような気がしたんで質問させてくれ。
blockquoteのcite属性で、値にISBNを用いたいとき、
ググってみたんだがどうも解説によって違うので、どれがStrict的にValidなんだろう？

１．urn:ISBN:4003272110
２．urn:isbn:4003272110
３．urn:ISBN:4-0032-7211-0
４．urn:isbn:4-0032-7211-0
５．ISBN:4003272110
６．isbn:4003272110
７．ISBN:4-0032-7211-0
８．isbn:4-0032-7211-0
９．4003272110
１０．4-0032-7211-0
１１．これ以外

>>380
http://www.ietf.org/rfc/rfc2288.txt

全部大文字なのか！
ありがとう。

blockquote要素のcite属性ってURIしか書いちゃダメなんじゃなかったっけ？

urn

あ、そっか

スラドのWikiの文法の標準化のあたりみてたら
今夜WikiWikiさわいでるやつは2年間ぐらいループしてることが
よくわかった。

ｳｨｷｳｨｷ騒いでます。

>>330
独自要素を作るのとclassを使うのとどう違うのか。
あとリストはAtomというのも無理があるんじゃ。せめてRDFとか。

ウェブ上の文章等を引用する際に、
マークアップもそのままのかたちで引用すべきなんですか？
それともストリクトになるように手を加えてもいいんですか？
個人的には手を加えたいんですが、
というか手を加えないとそのHTMLファイル自体がインバリッドになってしまって困るんですが、
たとえマークアップ部分であっても
手を加えることによって「引用」としての要件を満たさなくなるなど問題が出たりしますか？

>>355
abbr要素だと、IEでツールチップが出ないので
acronym要素使う人もいるそうな…

>>376
それ最近の流行らしいよ。

>>389
マークアップに手を加えても問題ない。
一番気になるのは、cite属性だけに記述して本当にいいのだろうか、ということ。
ま、ループするからやめよ。

>>388
閲覧 と 観覧 みたいになｗ

JSでabbrもcite属性も、再生成してやりゃ問題ないな。

>>388
classはあくまで属性値だからな。
属性値に属性値は付けられないし、新しい属性値を付けたい場合も
独自にネームスペースきってほにゃららするしかなかろ。

あ、もちろん規約にそってだぞ？かみつくなよ。

誘導されてきた者です。
質問させてください。

1
<ul>
<li>ほげほげ</li>
<li>ふげふげ</li>
</ul>

2
<ul>
<li><p>ほげほげ</p></li>
<li><p>ふげふげ</p></li>
</ul>

1と2どちらのほうがXHTML1.0 Strict的に正しいと言えますか？
2は間違っていると言えますか？

>>394
「ほげほげ」の部分が段落なのかどうかによると思う。

語句を並べたリストなら 1 の方、文章を並べたリストなら 2 の方で
いいんじゃないの？

段落をリスト化するというのも変な話のような気がして*気持ち悪い*ｗ

そうですね。
ありがとうございました。
divにします。

・・・・・・・・・・は？>>397

<ul>にもCSSを適用していて、<li>にも適用していて、その中の文字にもブロック要素でCSSを適用したかったわけです。

・・・・・・・・・・・・装飾のためにHTMLを書き換えるのはちっともStrictじゃないよ明智君・・・

>>399
CSS3の::outside使え

li の内容は %flow なわけで当然ブロック要素だって置ける。
何故そうしないのか。

置けるが、置いて意味があるかどうかはまた別の話。
装飾のためだなんてスレ違いもいいとこ。

逆にPの中にULとかは？
<p>禿げの兆候は一般的に
<ul>
<li>抜け毛が激しい</li>
<li>毛がスリムになっている</li>
<li>逃避が常に油脂でコーティングされている</li>
</ul>
などが挙げられる。</p>
問題ないよね？

>>404
inva

<p>のなかにブロック要素は含められない。

<p>禿げの兆候は一般的に
<object><ul>
<li>抜け毛が激しい</li>
<li>毛がスリムになっている</li>
<li>逃避が常に油脂でコーティングされている</li>
</ul></object>
などが挙げられる。</p>

……美しくない。

漏れは泣く思いで一回p要素閉じてるけど、きもちわるいよなぁ。

>>406
文章中にリスト挿入してるんだからそれで自然な気がする。

<p>禿げの兆候は一般的に以下のものが挙げられる。</p>
<ul>
<li>抜け毛が激しい</li>
<li>毛がスリムになっている</li>
<li>逃避が常に油脂でコーティングされている</li>
</ul>

段落とリストを区切って上のようにやる方が文書の構成としては自然かも。
そういう話はスレ違いだろうけど。

>>408
装飾のためにhtmlを改変するな！じゃないけど、
マークアップのために元文章を改変するな！って思ってしまった。
自分の書く文章ならやっぱりマークアップのために元文章を工夫すべきかああああ・・・・

<div class="pph">禿げの兆候は一般的に
<ul>
<li>抜け毛が激しい</li>
<li>毛がスリムになっている</li>
<li>逃避が常に油脂でコーティングされている</li>
</ul>
などが挙げられる。</div class="pph">

まあ「さとみかん」周辺で議論してる話題だな。

<div class="pph">禿げの兆候は一般的に
<ul>
<li>抜け毛が激しい</li>
<li>毛がスリムになっている</li>
<li>逃避が常に油脂でコーティングされている</li>
</ul>
などが挙げられる。</div>

<div class="pph">禿げの兆候は一般的に
<ul>
<li>抜け毛が激しい</li>
<li>毛がスリムになっている</li>
<li>逃避が常に油脂でコーティングされている</li>
</ul>
などが挙げられる。</div class="pph">

流れぶった切ってごめんなさい。相談しにきました。

5:25　トイレに行く。
5:30　外の様子を見に行く。
5:40　明日について考える。

上のように、時間と行動を書きたいのですが、
dt、ddを使ったほうがいいのか、テーブルで書いたほうが良いのか悩んでます。
どう書くのがストリクトですか？

ulはpの中に置きたかったよな。
曖昧なわりに細かいところで納得いかないことがあってやだわぁ。

>>414
そういうのはテーブルだろ。

dt/ddだと、"5:25" とか "トイレに行く" ってのが
何を意味してるのかわからんから、
tableのthで"予定時刻"とか"行動"とか意味付けしてやれ。

dt/ddなんてそんな無理に使いどころ見つけなくてもいいと思うよ。

>>494
個人的にはそれを「表」とは思えないので、定義リストないし順序リストにspan。

>>415
そうか？
pやaddressはそれだけで「ブロック」としてはmin-heightである
という主張が見えて納得できたんだが。

>>416
>dt/ddだと、"5:25" とか "トイレに行く" ってのが
>何を意味してるのかわからんから、
リストを意味してるんだろうが。
テーブルのほうがずっと何を意味してるかが分からなくなると思われ。

>>416
でも会話は
<dl>
<dt>少年Ａ</dt><dd>やっちまおうぜ、根こそぎ！</dd>
<dt>少年Ｂ</dt><dd>おう、バーコードなんて未練がましいよな！</dd>
</dl>
ってな感じで「登場人物」「会話文」なんてtableをつかってthで指定しなくても
定義リストでいいよってサンプルがあった気が

>>418
リストとかそういうまえに
何を意味してるか人間がわかるようにしろよ。

>>420
>>420
>>420

そういうなよ。
ストリクターの第一歩は
table完全否定からはじめなきゃいけないからな。
意味なんてまやかしさ。

>>409
マークアップすることを目的に文章書くなんてことをやめれば、
「文章が変ならマークアップ結果も変」っつー当たりまえのことが
理解できるようになると思うよ。

表ならtableを使うべきだが、
日時と内容、話者と会話文みたいな関係は
表とは意味づけにくいというだけの話だ。
テーブル全否定してどうするよ。

でもなあ。htmlって欧米のスタイル主体だからな。
日本語の文章の書き方と必ずしもあうとは限らない場面もあると思うよ。

>>424
たぶん>>416=>>420=>>422

会話はいいと思うけど、時系列でなにかしてるやつとかは
横にデータを繋げやすいテーブルの方が再利用性が高いと思うんだが…

久々にわかりやすい自演だな。

>>427
時系列に意味があるんなら序列リストでないかね。
tableは縦方向の並びに意味があることを保証はしてくれんだろ？

文書書いた本人が「行動リストだ」って言ってんだから
それにあうマークアップ考えりゃいいと思うんだけど。

とか思いつつgoo辞書引いたら表の説明にリストとか書いてあるよ。
リストの項には表って書いてあるし。表もリストも同種のものなのか。

つーことで、表でもリストでも意味づけとしてはおｋだと思う。
見方次第でdlでもliでもtableでもいいと思う。
dlにきっちりはまるからdlがちょうどいいと思うけどな、俺は。
まあその辺は手間とか他の箇所との統一性とか考えて
自分にあったの選べばいいと思うよ。

>>427
「行動」なんて項目名ふっちゃって、
あとで行動以外のこと（出来事とか）その項目に書きたくなったら
再利用性なんてないぞ。というか再利用性ってどう再利用するの？

ちょっと話はずれるけど、

>>429
会話も前後の関係が重要なんだから、olが妥当な気がしてきた。
dlだと並びの意味は保証されないもんな。
olの中のliにdlを入れるのがいいのかな。

ところで三次元の表はどうやってマークアップしてますか？

「表として意味がある」というのは、
「縦と横のthがぶつかった地点のtd」ということに意味があるときだと思われ。
ttp://hp.vector.co.jp/authors/VA022006/css/corrbrwser/visualren.html
こういうやつな。
それ以外で特に「縦に意味がある」場合は序列リスト、
特に「横に意味がある」場合は定義リストではなかろうか。

>>431
その時はthを書き換えりゃいいんじゃね？

>>434
そのサイトの、カーソルに追随して色が反転する仕組みはマジでパクろうかと思った。
けどうちにはこんな大規模な表を書く機会がないことに気付いた。

>>434に一票。

>>432
文章なんだし、上から下に流れていくって解釈は
デフォルトで用意されてると思っていいんじゃないかなぁ。
olはあくまで順序付けされた"リスト"なんだし。

どうでもいいがIE7インスコして自サイト見てみた？
対応表みてたら気になってきた。
また変なCSSの解釈してたらやだなぁ。

にしても、企業のサイトとかって
未だにtableレイアウトから脱却しないよな。

tableでレイアウトは本来の意味から離れてる!って主張する人が
デザイン会社に一人もいないとは思えないんだが
やっぱりコストとかが理由でCSSで段組とかははじかれちゃうのだろうか。

コスト最優先

逸般人しかFirefoxなんてインストールしないもんねえ。

strictにするという手段を目的と見誤っていませんか

ちょっと目的を整理しようぜ。
なんでStrictにするんだっけ？

>>437
入れようとしたら2000なんでインスコ自体弾かれたorz

>>438
いや、きっとCSSの方が時間もコストも削減できるはず。
が、クライアントに説明するのが一苦労だ。

クラが「どんなブラウザからでも同じに見えるように汁」っていうから
仕方なく…。結局メリットなんて分かってもらえるはずはないｗ

>>432
>>434のうちの「特に横に意味がある」場合だから、会話文は定義リストのが自然な希ガス。
あとは文章として通常フローだし。

>>441・442
一番の理由はStrict+CSSだとサイト改装が楽（ストリクターらしからぬ意志かな…）。
また、他人の規格を使わせてもらってる以上はそれに従うし、
気に入らないんだったらDTDから自分で書く仕組みも用意されてるんだし、とも思う。

まあStrictにするメリットっていうよりか
規格に逸脱した書き方してないってだけだよな。
だからこれが+-0地点。

dtがdefinition termの略だから、

<dt>Aさん</dt>
<dd>「腹へった」</dd>

これは変じゃね？

<dt>Aさんの発言</dt>
<dd>「腹へった」</dd>

これが正しくね？

ほら例のサイト出してあげて

>>447
HTMLじゃない芝居の台本もそれを言ったら
Aさんの発言：「うんちゃらかんちゃら」
が正しい。しかし慣例として「の発言」を省いても意味が通るのが自然言語だ。
だからもし使用してる言語以上にStrictにしたかったら
<dt title="Aさんの発言">Aさん</dt><dd>うんちゃらかんちゃら</dd>
となるだろう。

>>449
titleとコンテンツ逆じゃないの？

>>448
ぺるそねる？

>>450
逆にしたら「テキストありきでマークアップ」が崩れるぞ。

>>434
縦と横に関してのデータならtableを第一に考えるとしても、「横のみなら定義リスト、縦のみなら序列リスト」という線引きはちょっと微妙だと思う。
例えば横のみだとしても一対多の関係なら縦横拡張可能なtableの方がよい場合もあるんじゃないか。

>>454
よく嫁、「のみ」なんて言ってないぞ。

>>453
なんで定義リストが拡張可能じゃないんだ？

>>455
定義リストって拡張可能なの？

仕様書に多対多の定義リストの例も載っている件

>>457
多対多でもあくまでdtグループ対ddグループであって各々が個別に対になっているわけじゃなくなくない？

各々が個別に対になってるなら一対一の定義リストでいいじゃん

それってせいぜいnとmもXです、とか
nはXとYです程度のやつでしょ？
tableでいってる縦横への拡張性とはまた別の次元の話では？

ていうか「拡張したら」ってのはマークアップの原則に外れてるような。
まず「テキストがあるから」そこに意味づけを行うんであって、
テキストが変わるなら当然「意味づけも変わる」わけで、
修正のことを考えるのは間違ってないか？

いわばdlは1に対して1足していく一次元的なもので、tableは1に対してn足していく二次元的なものなんじゃなかろうか

ところで三次元の表はどうやってマークアップしてますか？

>>462
二次元的だからテーブルとして意味づけが行えるんであって、
「いずれ二次元になる」からと、
今一次元的なものを無理に二次元的に無理に意味づけするのは本末転倒。

>>463
三次元の意味がわからない。
正確に言えば縦横のあるテーブルは三次元。

>>463
<dl>
　　<dt>シート１</dt>
　　<dd>
　　　　<table>省略</table>
　　</dd>
　　<dt>シート２</dt>
　　<dd>
　　　　<table>省略</table>
　　</dd>
　　<dt>シート３</dt>
　　<dd>
　　　　<table>省略</table>
　　</dd>
</dl>

>>461
だから人によってぶれるわけだよね。
書いた本人じゃないとどのマークアップがただしいかなんて
わかりっこない。

>>463
軸3つになるような表なんてつかったことないな。
2次元の表ですらろくにつかわないのに。

>>465
>縦横のあるテーブルは三次元
>縦横のあるテーブルは三次元
>縦横のあるテーブルは三次元
x座標とy座標だけで三次元をあらわせるもんなら

>>464
背景にある意味が二次元だったら
テキストが一次元だったとしても
二次元でかいてもいいんじゃないの？

1個しかない場合でもulつかうことあるだろ？

縦と横が二次元ならば三次元には奥行きがあるのだろうか・・・

>>486
一次元：点
二次元：線
三次元：面

・・・Strictの話題から外れてってるような気が

>>471
何か勘違いしていないか？

>>469
一次元だから二次元だからということではなく
「リストだから」一個でもulなわけで。
おまいさんが何をやりたいんだかわからんが（三次元？）
おまいさんの書いたそれは表なのかね？リストなのかね？

3D = three dimensions = 三次元
平べったい3Dグラフィックなんていやだ

さんじげん 3 【三次元】 - goo 辞書
ttp://dictionary.goo.ne.jp/search.php?MT=%BB%B0%BC%A1%B8%B5&kind=jn&mode=0&base=1&row=0

>>467
結局本人が「表だ」と言い切ればtableだし
「リストだ」と言い切るならul/ol/dlなんだよな。

>>470と>>471はただのアホな子

>>465の「正確に言えば」はもっと詳しく解説してほしい

>>475
時間軸が4次元か5次元か
なんて議論は昔からあるし
それも本人がそうと言えば（ｒｙ

4次元以降はSF作家などによる造語でしょ
3次元まではコモンセンスじゃない？

それぞれ好きに解釈しろってことでFA。

タイムスケジュールなんて表形式でもリスト形式でも
あながち間違いじゃないから、UAがとんでもない解釈する惧れもないしな。

Strictの話題に戻そうぜみんな(；´д｀)

Strictな次元の話を語り合ってるんだよ。

三次元の表は>>466でFAってことで。定義リストじゃなくてほかのリストでもいいけど

>>480
あまり好きに解釈しすぎると、テーブルレイアウトは
「画像の表です！」と言われそうな悪寒

>>483
>>466のは俺には二次元に見えるんだが。
二次元のネスト。

結論：テーブルはむつかしい

>>483
てか、無理にHTMLで表現しようとしないで別のobjectで表現したほうがよさそうね。

あ、colspanとかrowspanでグルーピングするって手もあるよ。

<tr><th></th><th colspan="2">上半期</th><th colspan="2">下半期</th></tr>
<tr><th></th><th>4〜6</th><th>7〜9</th><th>10〜12</th><th>1〜3</th></tr>
<tr><th>富士通</th>.....
<tr><th>DELL</th>....

みたいな。

・・・ここまで読んでも三次元の表ってのがどんなのかわからんかった・・・

>>487
上半期、下半期が第三の軸ね。

>>489
それってネストとはどう違うの？
すまんがネストと三次元の区別がつかない俺。

HTMLのさまざまな疑問・問題点を「次元」という観点から議論していくスレです。

>>489
それはちょっと違うだろ。
その例で三次元テーブルを説明するなら
年度、四半期、商品を軸にするべきだ。

>>490
dlでネストとかしちゃうと
最初のddと次のddのthの中身が同じである保証がとれない。
厳密にいくなら別のデータ形式の方がいいのかもね。

>>492
年度、四半期、商品じゃダメでしょ。
四半期、会社、商品ならともかく。

>>490
三次元の表を立方体でつくるのはイメージできるな？
ブロックの３＊３＊３の集合とか。
で、それを二次元の表をネストさせて表現するということだ。
３＊３＊３の表は、３＊３の表を３枚並べれば表現できるだろ？
断面を、奥行き方向にならべるか平面方向に並べるか、
これがお前の言うネストと三次元の違いだ。どっちも三次元。

PhotoshpなどについているRGBのカラーテーブルが三次元テーブルじゃない？
Z軸が横にスライドバーとして配置されているけど

>>493
そうか？
異なる年度を重ねて売上の推移の分析とかすること考えると
年度を別軸にするのも間違ってないと思うが。

>>495
そうか！3DなHTMLに足りないのはslidebar要素だったんだね！

三次元テーブルを無理やり二次元で表現したものの画像は検索したらヒットした
ttp://www.trimill.com/TriLookup/Examples_03.htm
HTMLも三次元テーブルはこういった表現しかできないけど
それをどうマークアップするか、は、やっぱり>>466が近いと思うんだけど

>>492
>最初のddと次のddのthの中身が同じである保証がとれない。
すまん詳しく。

>>494
いやだから三次元の立方体は存在したとしても
奥行きの必要のある*table*ってどんな場合？というのがわからない。
>>492の例でも、上半期の中の月、月の中の会社、
という二次元に見えるだ・・・

>>492
classで共通性を意味づけしとけばいいんじゃ。
同じclass属性値を持つってことが保証できるぞ。

厳密な意味での保証を言い出せば、マークアップが
ただしくない可能性まであるわけできりがない。
実際に統一されてればそれで無問題だろ。

>>499

>>466の方法だと、
シート1のddで
<tr><th>商品</th><th>価格</th></tr>
とかやってたとしても、
シート2のddにいくと
<tr><th>名前</th><th>性別</th><th>趣味</th></tr>
なんて感じの全然別のテーブルになってる可能性もあるわけで。

>>501
それって二次元三次元の問題じゃなく、
そもそも内容（テキスト）が間違ってるって話にならない？

三次元の表、やっと見つけた。
ttp://www.heart-color.com/books/books_images/books_4_jiten.jpg
これ、一応三次元の表だよね？

>>500
マークアップが正しくない場合は問題外だろ。
invalidなHTMLってことなんだろ？

classとかXHTMLで拡張した要素で共通化は概ね賛成。
そこまで厳密にやったところでそれをすいだすプログラムもないし。
大抵表になるようなデータは生データが後に控えてるから
XHTML3ぐらいになってこれぞ3D！なんて表現方法ができたとしたら
そんときに変換してやればいいしな。

>>499
各国の輸出高ベスト５の年次変化をまとめた表とか。
それは、
　「『各国の輸出高ベスト５』の年次変化」
ともとれるし、
　「各国の『輸出高ベスト５の年次変化』」
ともとれる。
このように、見方の自由度があるものについては、
三次元のまま表を提供することで閲覧者の読み取り方に
制約を課さないことができる。

>>503
slidbarな表ですね。

Stricter って、本当に table 要素のことを知らんな。

仕様書の table 要素の axis 属性の部分を読み返してみろよ。
HTML は3次元以上のデータ構造も書けるようになっている。

ttp://www.glhome.co.jp/bestyle/plan/plan_g/03_g/colorscale.jpg
そしてこの画像。
彩度がX軸、明度がY軸、そして色相がZ軸で、
本当はZ軸は画面の手前や奥に配置されないといけないんだけど
平面なディスプレイ上で表現するために便宜上スライドバーという表現手法を取っている。

>>505
Excelのピボットテーブルみたいなことが出来るわけか。

tableってさ、リッチなUA環境だったらソートとか
フィルタリングとか出来てもいいわけだよな。
表って意味付けされてるわけだし。

>>507
ほんまや…
出直してきます。はずかしい…

ttp://www.cohsei.co.jp/PRODUCTS%20PAGE/taos/230evm_05.jpg
これは
X軸に色相
Y軸に彩度
Z軸に明度
だと思う。

う、うーん、何となくわかってきた・・・かもしれんが自分では使わなさそうだな・・・

>>509
CSSで表示非表示（抽出）くらいは簡単にできそうだね。

html table axis で検索すると、結構3次元の表のサンプルでてくるね。

>>507 だけど、
axis 属性は table 要素じゃなくて、th/td 要素だった。
あっ、ちなみに、仕様書の 11.4.2 章な。

ttp://www.tg.rim.or.jp/~hexane/ach/stht/stht09.htm
ここイラスト付きでわかりやすいね

>>515のサイトいいね。あとで読む。
よかった。今日はちょっとためになる終りかただった。
おやすみなさい。

タグを取っ払った状態で意味が通じなければならないって
聞いたんだけど、
rubyとか、table(純粋な表の)とかはタグ取っ払ったら意味わかりません。
使うべきでないということでしょうか？

>>517
rubyはタグを取っても意味が通じるでそ

というか
> タグを取っ払った状態で意味が通じなければならないって
> 聞いたんだけど、
なんてそんな適当で希薄な根拠だったら
「おれはタグを取った状態なら意味が通じなくても問題ないって聞いたよ」
で話が平行線になると思う
釣りは餌が大事

>>517
それ俺も聞いたことあるあるｗｗｗｗｗ

ねーよｗｗｗｗｗｗ
てかタグを全部取っ払ったら改行すら入らなくね？バカじゃね？
ってな漏れのような雑魚しか釣れない

タグを取り払った状態で意味が通じるべきってのは
HTMLがマークアップ言語であることから来る自然な主張だと思うが

タグを取ったってプレーンテキストとして意味が通じるだろ。
テーブルだってタブやカンマ区切りの表になるし、
ルビや改行は言うに及ばず。

タグを取り払った伝々ってMime-Typeがtext/*だったからでは?

言葉通りに解釈してるからいけないんだよな。

意味が通じる通じないってどの範囲を指すの？
たとえばemでマークアップされた単語からem取り去ったら、
この単語は強調されている、という意味は失われるけど
文章として破綻していなかったらＯＫってこと？

>>526
そこにemがなくたって*書いた本人は意味がわかってる*だろうが。
そこにemをマークアップするのは「他人（機械）にもわからせるため」。
emに限らず素のテキストじゃ「ここが段落」「ソースコード」とわかるのは本人だけ、
それを*意味に沿ってマークアップする*ものだろ？

全ての余分な改行と空白が取り払われたHTML文書からタグを取り除くと、
全ての文字が一行に繋がって見出しも段落も区別がつかなくなる。
表データも区切りがないので区別できない。
imgは代替テキストすら残されずに消え去る。
などなど。

http://www.aboutworks.com/shokodei/diary/doc/OBJECT/not_object.html
キモスｗｗｗｗ各種ValidatorでValidだとか100点だとかキモスｗｗｗ

>>528
逆だっての。
テキスト→imgは、意味の通るテキストがあるところをわかりやすくするために画像にして
その画像のaltにそれまであったテキストを入れるということ。

>>530
いずれにせよマークアップを消せばalt属性も消えるから意味を伝えられなくなるんじゃないの？違うの？

>>530
何を勝手なことを言ってるんだ。
仕様書のどこにそんなことが書いてあるんだよｗ

>>531
マークアップを消すという意味を間違えてるよ。
作った本人しかプレーンテキストにマークアップできないように、
逆にマークアップした文章をプレーンテキストに戻すことができるのも本人だけ。
自分が「そこの文章をalt属性に入れた」とわかっていれば
プレーンテキストに戻すときもaltをテキストに戻せる。
というか「代替」とはそういうこと。

どんなに意味不明な文章でも自分で書いたものなら理解できる

すみません、前提として「内容が通じる」の対象は
マークアップした制作者なのでしょうか？
それとも閲覧者など他の人もその「通じる」の対象となるのでしょうか？
前者なら>>534みたいな考え方もできるかな、という疑問が出てきて

>>534
それなら、タグを取り払った時に理解できない文章というのは存在しないのだから、
タグを取り払っても意味が通じなければならないという議論自体が不要になるぞ。
それとも、意味が通じる != 理解できる とかいう言葉遊びか？

自分が作った文書でも、時間がたてば忘れることもあるでしょう。
また、表などの数値データが、マークアップを取り払うことで連結されてしまったら、
暗記していない限り元の意味を取り出せないよ。

それ以前にさ、理解不可能な文書をHTMLでマークアップする必要なんかないよ。

>>535
自然言語としてなら、「正しくマークアップされていれば基本的には」意味の通った文章に他人でもできる。
たとえばpで囲まれてるが次のpとの間に改行がない場合、
それでも自然言語的にマークアップを外したら、そこに「段落行」を入れるでしょう。
imgは「代替」なんだから、alt（titleではない）属性値をテキストに戻すでしょう。
そういう「適切な」タグの取り除きをすれば、
基本的には他人にも意味の通じるようにしなきゃならない。
だから意味のある画像でaltなしはいけないとされているし、
見出しをhnでなくマークアップするとそのテキストを見出しに戻せないというのがある。
「タグを取り払う」というのは「マークアップの手順を逆に意味に沿って取り払う」ということ、
そしてそれを取れば、たとえばemをプレーンテキストで「自分は」**で囲みたいと思えばそれができる、
ということ。マークアップと除マークアップは一対。
だから正しくマークアップしなきゃならない。

じゃあ「意味が通じる」というのは他人も含めてってこと？

>>540
「ある程度は」ね。
むろんこの上で出てきたように、dlとtableは曖昧で
本人が言い切らなきゃどっちとも付かないようなケースもあるし、
この前の闇黒日記とねこめし日記のように、マークアップに慣れた人でも
他人のマークアップの意図を読み違えて（？）しまうこともある。
それは国語のテストで全員が100点を取れないのと同じ。

>>541
> 闇黒日記とねこめし日記
情報学を全く学んだことの無い素人の日記など何の権威にもならんわな。
> 国語のテスト
どんな喩えだ(笑) 詭弁のつもりか(笑)

闇黒日記読んでいるとイライラしてくる。
お前は何時の時代に生まれたんだよ、と言いたくなる。

先カンブリア時代

ウェブ上ではよく見られるような、
最初の出所がわからないようなコピペというか定型区の場合は
q要素やblockquote要素でマークアップする際に
cite属性は端折っても問題ないですか？
それともそのとき参照したものがあれば、
元ネタの知らない孫引きになってしまったとしても
とりあえずそのURLを書いたほうがいいですか？

>>545
孫引きでもq/blockquoteとciteは入れておくべき。
まあうったえられることはないに等しいだろうけど、Strictなマナー的には。

>>546
たとえば気に入ったコピペをローカルのテキストファイル等に保存していて
URLがわからなくなっている場合は、cite属性を書かないよりは
適当な含まれるフレーズで検索してヒットしたサイトを引用元としたほうがいいですか？

>>547
気に入って保存したくらいなら、
そのヒットしたサイトを落としたかどうかかくらいはわかるんじゃ・・・。
もしわからないんだったら相手に問い合わせてからのがいいんじゃまいか？

>>548
コピペのあった場所が某巨大掲示板のどこかの板のどこかのスレとか・・・

HTMLのことしか語ってないblogとかって
本末転倒だわ。

>>542
あいつら何か勘違いしてる。

>>549
だったらぴろゆきにｗｗｗ

ひろゆさに本来の引用元を聞くといいよ

そういうコピペの引用元はcite="http://www.2ch.net"でよし！

>>553でいいな。

>>550
言語を用いて言語学の勉強しちゃいかんの？

>>553-554
い、いいのか！？

>>553
<q cite="http://www.2ch.net">そういうコピペの引用元はcite=＆quot；http://www.2ch.net＆quot；でよし！</q>
って<cite>２ちゃんねる</cite>に書いてあった！！

うわ・・・信憑性ねえ・・・

>>55
吹いた。

>>555
言語学って…

それにHTMLは言語学なんて高尚なものじゃない。
必死で勉強しないと使い熟せないフォーマットなんて
普及するはずがない。
あなたはコンピュータに使われる人か？

>必死で勉強しないと使い熟せないフォーマットなんて
>普及するはずがない。
ある程度でも正しいマークアップがちっとも普及してない件。
まあそれなりに議論になる程度には難しいものだと思うよ。

じゃあそこから導き出される結論は、
正しいマークアップなんて必要なかったってことだろ。
誰か困ってるの？

仕様に対してvalidじゃないのはどうかと思うがな。

自サイトで云々語ってるけどフィードバックしないしね。

>>561
正しいマークアップを覚えないと結局難しいことをやろうとして背伸びして失敗して
初心者スレとかに来るわけで。

>>550
timbl's blogとか?

>>559
何だか対応関係がおかしいけど、
HTMLはLanguageだぞ。

それとコンピュータを真に使いこなすには
必死に勉強しなければならないと思うが・・・。

おいおい、まさかJapaneseとHTMLを同列には扱ってはいないよな。

複雑度が同列なわけないだろ。

>HTMLのことしか語ってないblogとかって
>本末転倒だわ。

これが筋違いだって言ってるの。
だいたいそれ言ったらおよそ価値のあるblogというものが
あるのかって話になる。

今日も今日とて雑談の花が咲く

そもそもこのスレが32代存続していることこそ
HTML語る人がいてもおかしくないって証明なんじゃないか

スレ違いかも知れませんが、
cssから参照する画像ファイルのファイル名は物理的（？）な名前でもいいんですよね？

画像ファイル名に物理名と論理名があるとは知らなんだ

右向き矢印の画像ファイル名が arrow_right.jpg だが
主に IE 独自拡張のフィルタをかけて左右反転を意図したので
表示の上では arrow_*right*.jpg ではなくなるから notice.jpg にする……とか？

>>572
単純に右向き矢印の画像ファイルなんだからarrow_rightでいいんでは？

ところでcssファイルやそこから画像を呼び出すときは拡張子取っ払って
コンテント・ネゴシエーションしたほうがいいのかな。

hrefやsrcの記述方法ですが、同じサーバ内のファイルを指定する際の書き方として最も正しいものは以下のどれですか？

1
href="http://www.huge.com/images/back.gif"

2
href="./images/back.gif"

3
href="images/back.gif"


また、css内での書き方はどうですか？

1
url(.http://www.huge.com/images/back.gif)

2
url(./images/back.gif)

3
url(images/back.gif)

正しいも何も相対パスと絶対パスであって・・・

>>569
頭悪い人が多いって証明だろ。

>>567
>>だいたいそれ言ったらおよそ価値のあるblogというものが
>>あるのかって話になる。
個人サイトの9割はゴミ。これはガチ。

>>576みたいなのがいるんじゃなァ

相対パスのほうが好ましいと思う。

>>565
真に使いこなす人向けのフォーマットかね。HTMLって。

コンテントネゴシックスされたらファイルタイプが一目でわからんから不安だす。
Javascriptでステータスバーの表示を消すやり方を髣髴とさせるだす。

各種グラフ（棒グラフ線グラフ円グラフ・・・）の画像のalt属性ってなんて書いてますか？
それともグラフを貼る場合はobject要素を使って
代替としてtableなどを埋め込んだりするほうがいいんですか？

代替としてのtableはよさげだね。

それよか音楽とかflashとか
それがメインのコンテンツの場合の代替になやむ。
代替テキストがあっても意味ないみたいな。

>>583
代替にHTMLページへのリンクでよさげ。
もしくはノーフレームのようにコンテンツページそのままとか。

>>583
コンテンツのURLでも書いておけば、
クソなブラウザの人でもダウンロードして
専用ビューアや別マシンで鑑賞することが出来る。

参考程度の写真とかスクリーンショットとかの画像のaltもいつも悩む。
そしていつも続けてキャプションつけちゃってるからなおさら……。

>>575
RFC3986くらい読めよ。Web制作の範囲だから。>>574に絶対パスは無い。
変な喩えだが、要素をタグと言うくらい酷いぞ、おまえ。

>>587
同じサーバにあること＝同じドメインを使用していることではない件。

まあ絶対パスではないな

三回までOK

>>588
？

>>591
別のドメインで同じサーバの別ディレクトリを参照させたりってのができたと思う。

example.com => 127.0.0.1
example.jp => 127.0.0.1/jp

RFC3986には絶対パスや相対パスという用語はない罠

>>593
"relative-path reference"と"absolute-path reference"
という語句が4.2節にあるわけだが、どうしたものか。

>>587の言ってることがわからなかったので誰か教えてください
httpスキームから始まるのが絶対パスではないんですか？

>>594
ハイフンが付いてたのね。失礼

>>595
こちらへどうぞ。
Webサイト制作初心者用質問スレ Part 153
http://pc8.2ch.net/test/read.cgi/hp/1138784251/

>>595
それはabsolute URIっていう用語であらわされる。
"http://example.com/hoge/hoge.html"っていうabsolute URI表記に対して、
"/hoge/hoge.html"というようなabsolute-path referenceや
"./hoge.html"というようなrelative-path referenceには
relative referenceっていう用語が当てられてる。

……と読んでみた感じこうだと思ったけど、あってるかどうかは知らん。

>>592
なぜヴァーチャルホストの話してんだ？関係ないだろヴォケ。

まあ、あれだ。
出来るだけ短かめに抽象的なこと言っておけば
なんかすごい事言ってるように見えるもんだ。

>>599
横からすまんが、>>574 は「同じサーバ内」と書いているので、
>>588=>>592 は「ヴァーチャルホストを設定していたら同じサーバ内でも
違うホスト名になるので、相対表記が使えるとは限らん」という屁理屈を
唱えてるんだと思う。

>>595 それは「絶対URL」または「絶対URI」。
"/images/back.gif" が「絶対パス」で "./images/back.gif" や "images/back.gif"
が「相対パス」。でも、どちらもURLとしては「相対URL」と見なされる。
"http:" から始まると「絶対URL」。

>>601
>>588=>>592じゃないぞｗｗｗ
ちなみに別ドメインであっても相対表記も使える。
ただ違うドメインを設定してる場合は絶対指定のほうが自然だと思うがな。

>>602
おお、別人だったか。で、別ドメインを相対URLでってのは、
href="//www.example.com"
こういうやつだな。でも、そこまで書くのなら "http:" を付けろよと
言いたくなるので、あまり使わないけどな。

>>603
いや、エイリアスの設定によるんだけど
/www/aaa/←aaa.com
/www/aaa/bbb/←bbb.com
これで/www/aaa/bbb/index.htmlに対して
/www/aaa/x.htmlからは./bbb/でもアクセスできるし、逆もそう。

>>582-586の流れでの、音楽ファイル動画ファイルFLASHファイルなどの代替は
ファイル直リンクでダウンロード用のアンカーを用意しとけばおｋってことですか？

>>605
それでいいんじゃね？
モノは渡すからあとは自分でどうにかしてくれってのが
最終手段だな。

ところで、longdesc 属性って使ってます？
イマイチ使い方が分かんないんだけど。

>>607
http://www.faireal.net/articles/4/12/#d11223_2

ほお。
てか、視覚に問題がある人じゃなくても音声UAって結構使えるんじゃない？
なにかしながらラジオ感覚でサイト閲覧。

あのロボロボした喋りは気にいらんけど、RSSとかの台頭で
文章が利用しやすい形で流れてくるようになったし。

>>609
ソフトウェア板の「テキスト読み上げソフトで〜」スレで
２チャンネルのスレを読み上げてもらう方法が語られているよ。

2chのスレ読み上げって……
「テラワロスダブリューダブリュー（ｒｙ」とか流れるのか

>>611
そういう処理をうまくする方法が語られているよ。
当然、板やスレによっては読みにくいところや工夫が必要なところもあるだろうけど

アスキーアートをきまじめに解説してくれたら笑える。NHKのニュースか何かみたいに。

休みに入ったらためしてみる。
視覚に障害がある人でも…とかいわれてもなかなか想像しずらいし。
自分で使ってわかる部分もあるよね。
マークアップの仕方だけじゃなく文章の書き方も変りそうだ。

>>614
とりあえず「変わりそうだ」な。

>>615
ありがとう。一つ賢くなれました…

>>616
もう一つ言うなら「想像しずらい」じゃなくて「想像しづらい」な。

>>615
本則ではそうだけど別にいいんでね？まあ、今、学校では本則しか教えないと思うけど

StrictなHTMLの前にStrictな日本語を……ってのは難しいな

音声ブラウザは本則以外だと発音どうなるんかね？

東横インのオヤジも、これを機会にストリクトにしてほしいな

HTML以前に学ばなくてはいけないことは多そうだ。

ダディクールのAAがあると「ダディクール」って読み上げてくれるとかなら面白いのになぁ。
<aa title="ダディクール">（略 : ダディクールAA）</aa>
って感じかなぁ。それじゃあ普通か……。
せっかくwebページなんだからweb独特の文化でもあるAAのマークアップがあってもいいかもね。
欧米とかでも:-Pとかあるんだし。

AA は abbr でいいじゃん派

abbrやacronymは日本語の略語や接頭語でもおｋ？
<abbr title="だってさいたまなんだもの">ださい</abbr>
<acronym title="やめておしりはいたいから">やおい</acronym>
とか
注：上記略語・接頭語の正式名称が正しいのかどうかはわかりません

・・・・そういう略だったのか・・・！！

abbrはdfnとも言い難い微妙な略語に使ってる。

dfnの使う場所がわからない。
同じ単語なのにマークアップするのは最初に出現したものだけとか
神経質な漏れにとってはなんか気持ち悪いです。
しかもこれtitle属性に「これは〜のこと」とか書かずにただ単にマークアップするだけでしょ？
必要性がよくわかんないんだけど、機械とかが解釈する際に何かいいことでもあるの？

一回だけなんてことはないぞ。
ttp://www.kanzaki.com/works/2002/pub/wsd05.htmls#3-1
しかしこのページ、ソース見ると
俺だったらcodeでマークアップしたいところを、dfnを多用してるな。

それよりもabbrとacronymの違いが不明。
XHTMLがacronymにはなり得ないabbrってのはわかるんだけど、
WWWってWorldWideWebの略だろ？どうして頭字語じゃないの？
ttp://www.w3.org/TR/html401/struct/text.html#edef-ABBR

>>628
acronymは発音も変化する略語じゃなかったっけ？
UFOをユーエフオーと読まずユーフォーと読む場合はacronym、とか。
ねこめしにっき参照。

>>629
そう説明してるところも多いけど、
だったら例に出てるF.B.I..なんてエフビーアイじゃないの？

>>630
http://www.kanzaki.com/works/2002/pub/wsd05#s4

発音を基準に考えても、"F.B.I."がacronymで"WWW"がabbrであるという違いについては依然よく分かりません（それに発音をどうするかは、基本的にはスタイルシートに委ねるべきでしょう）。

いや、それ読んだけど、だから「どう使い分けるか」ってのかせ問題なんだが・・・
使い分けなくていいか？
どこかでいずれacronymは廃止されるって記事を読んだ記憶があるんだが、
ソースが見付からなくて。

XHTML 1.1では廃止されてなかったか

>>633
まだある。

あ、でも2.0の草案では出てないね。

開いて読むのか、略したままを語として読むか、ってことだろうな。

WWWなんかは、ダブリューダブリューダブリューという単語としてよむ
人もいるだろうけど、どうマークアップするかは書き手の意図次第でよいと思う。

認知されている語として使うつもりで名称の補足を書きたい場合はacronym、
認知されているとは限らないと思った語（（なにかしらの）正式なものでは
ない略称だとか）に正式名称を付加したい場合はabbr、って感じじゃないかな。

文書内定義された語を示したい場合のdfnとはまた別だな。

>>636
正式なものではない略語って何？
Incやetcも正式ではない？

文書内定義とは言っても学術書の特殊用語もすぐに一般語になるしな・・・

ストリクタってアニヲタが多いって聞いたんですが本当ですか？

>>637
一段落目読んで。
三段落目は二段落目で書いた例外の補足。

あと、文書内定義されているか否かでどう迷うんだ。

dfnって索引を作るためにあるんじゃないだろうか。

>>635
ということはもうabbrにまとめていいんじゃない？
悩みに悩んでマークアップしてもそれでもやっぱり違うかなーとか迷ったら、夢に出てきそう

>>640
なるほど

そもそもなんでabbrとacronymの二種類が用意されているんですか？

>>639
いや読んだけど、非認知≒非正式だと思ったので。
それこそIncやetcは充分認知されてる語だろ。

＞あと、文書内定義されているか否かでどう迷うんだ。
すまん意味がわからない。俺が悩んでるのはabbrとacronym。

>>644
>636の最後の行は読んだまんまdfnについてだよ。
俺のほうこそ>637の最後の行の意味が分からんぞ。

あと、まだ話が通じてないようだが、>636は
　第一段落：原則
　第二段落：原則から外れる例外の例
　第三段落：例外に対する補則
　第四段落：dfnってぜんぜん違うよね
原則で判別できるなら例外の話は関係ないよっつーこと。

索引ページで<a href="#〜">ほげ</a>で飛べるように
sfnにはidを振ったほうがいいってことかい？

>>645
だから「原則から外れる例外の例」がabbrになるというのが納得できないんだよ。
原則が「認知されている語」だからな。
abbrにもacronymにも同等程度に認知されているだろう有名な語が例として挙がっている。

>>646
むしろ抽出のためとかじゃないか？

>>647
なあ、一行目には「開いて読むのか、略したままを語として読むか」
と書いてあって、認知云々は例外規則の方に書いてあるんだが、
なんで混同してるんだ？

WWWは、書き手の意図次第って書いてある通り、書き手があくまでも
World Wide Webと書くのを略しただけだとするならabbr、WWWという
単語のつもりで使うことを意図したなら、そのacronymで補足を書いても
よいと思うよ。
それを読み手側を考えてみれば、略語の認知度が指針になるだろうって話だ。

>>648
ああ、一段落目ってそっちのことね。すまん。
「意図次第でよいと思う。」までは、悪いが繋がりがよく見えなかったから。
「開いて読む」のがどれか、「略したままを語として読む」のがどれか、をまず
>>636は定義してないんだよ。
どっちでも読まれる単語が仕様書には例が出ている、*だから*混乱している
という話の途中なのにもかかわらず、だ。

それに制作者が「WWWという単語です」と言い張ろうが何だろうが、
（知らないでマークアップできないというのはともかく）
WWWがWorldWideWebの略語である事実は消えない。
もし制作者の意図で単語の意味を変えることが許されてしまうんだとしたら、
詩はpreでマークアップすべきなどという話も出ないだろう。
いや、仕様的には許されることかもしれないが、Strict的には許されてはならないことだろう。

ストリクタってアニヲタが多いって聞いたんですが本当ですか？

>>649
とりあえず>636は通じたようでよかったよかった。

意図を変えるも何も、もともとその文書ではそういう
意図で使ってるんだから、その意図どおりにマーク
アップするしかないだろ。

文書がある単語を一般的な意味や歴史的経緯を無視して
使っているからといって、その文書の是非を論じるのはスレ
違いだと思うぞ。

詩の整形を無視しようが生かそうが、それは文書作成者の
意図の問題で、マークアップの問題じゃない。詩を出来る限り
生かそうという意図がはっきりしていて、それには整形を無視
できないね、ということになれば、それをどうマークアップする
かってのはこのスレの話題だろうけどな。

アニョータ

abbrに統一すればいいじゃん。

>>651
「文書がある単語を一般的な意味や歴史的経緯を無視して」るんだとしたら、
そもそも自分の中に存在する「意味」をねじ曲げてマークアップするということになるだろう。
「知らずに」それが一単語と信じて使うのとはわけが違う。
自分で「意味違いだ」とわかっていてhnをdivにするのと同列の問題だと思うがな。

あなた達二人、一時的でいいのでID表示かトリップつけて

>>655
二人じゃないしｗｗ

長ったらしい文章を書いているのはサシで言い合っているのかと思ったゴメン

>>654
a.文書の意味とマークアップが合ってない
b.一般の意味と文書の意味が合ってない

ただあぼんワード登録したいだけなんです

Strictスレで議論をアボンしたら何が残るんだろう

>>636に関連するレスはほぼ一対一じゃない？

参加してやれ

使い分けの話に戻っていいよ。

そもそもなんで>>643ですか？
ふたつあるからけんかするんだ！

>>635とのことなのでおまいらみんな先取りしてアクロン捨てなさい

全部sbbrでいいんじゃないか。
頭字語も結局略語の一部だしな。
その「頭字語」さえ仕様書内でも統一されてない始末なんだからさ。

>>636
Western languages make extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.",
as well as abbreviations like "M.", "Inc.", "et al.", "etc.".

どっちも略したまま読む語じゃん。

>>667
たしかにet al.あたりは字面そのままだねえ。
そしたら、便宜上の省略に過ぎないのか頭文字をとった造語なのか
で区別かなあ。これも明確じゃないけど。

>666が正解だと思うから、明確にacronymだと思ったものはacronym
迷ったらabbrにしておけばおｋかな。

IEはabbrを解釈しないんだっけ？

>>669
IE7は直ってる。
IE6でもJSでabbrを認識させるスクリプトがあちこちにある。

>>668
つーか
>明確にacronymだと思ったものはacronym
この明確な単語と思われる
>WWWってWorldWideWebの略だろ？どうして頭字語じゃないの？
が発端なんだろ。どこに明確があるんだ。

All... abbr!!

きっとこういう議論が積み重なって
XHTML2.0ではabbrに統一されたんだろうな…

>>669
我々にUAの実装を気にしている暇はない。

っていうか、HTML4.0 の時点で abbr に統一しようと思ったら、IE が
acronym を先行実装してしまったので仕様に残したという説がある。

先行実装したら、今度はabbr無視か・・・流石だなM$

>>671
そんで、その話から続いた一連のレスの中で、
そのまま読めないとかWWWというのは単語じゃないとか、
明確じゃないと思われる要因がいろいろでてきたわけだ。

明確な単語じゃないってことが分かってよかったな。
なにも明確じゃないと思ったら全部abbrにすりゃいい。

規格無視するのは問題外だが、
実装無視してなんのためのマークアップだよ。
おまえはいちいちソースを直接読むのかよ。

そのうちどっかのステキなプログラムが
abbrとacronymを区別してステキなことしてくれるといいね。

ところで、<abbr title="World Wide Web">WWW</abbr>なんて
わざわざ毎回やってるの？
スクリプトで生成してるから関係ないね？

WWWが何の略かなんて、わざわざ書く必要なんてあるのか…？
まあ、ここでは議論用として出してるだけなんだろうけど、
どれぐらいの単語からabbrを使うのか気になったんで、ヤボを承知で。

漏れはそのページで初出の単語だけだなぁ。
CDは付けないSVGは付けるWWWは……つけないかなぁ。
想定してる読者とかページの内容とかにもよるんじゃない？
web系の略語で、
もビルダー使ってた初心者に正しい使用にそったHTMLを教えるページなのか、
ひたすらそれ系の話題をダラダラやってるサイトなのか、
メインは違うジャンルだけどStrict-HTMLの硬派な話もたまに書くblogなのかとか
それぞれで変わってくると思う。

s/web系の話で、¥nも/web系の話でも、¥n/

>678-681
おちつけ

>>680
そうだよね。
ここで極論吐いてる人も普段は結構常識的なバランスで
文章書いてると信じてる。

とりあえず、略語だラッキーabbrのチャンス!って奴は
頭変だってことでFA

>>678
ここはStrictスレ

>>684
だから…なんのためにStrictにしてるの？

>>685
言いたいことは判るけど、
みんな判った上で拘ってるんだよ。
それをここで言うのは無粋。

>>630
<abbr ..>FBI</abbr>
<acronym ..>F.B.I.</acronym>

>>682
読み直してみたら気持ちは分かったが、>>679までは別の人だ。

>>683
つーかここでバランスとる必要は無いんだよ。
Strictっつーひとつの見方を練って、
それを各々いろんな見方と併せて使うんだから。

つまり>679はスレ違いだっつーことだ。まあそこまで
スレ違いスレ違い言って追い出すこともないけどな。
多少の脱線は次の話題の種にもなるから無益じゃないし。

トリノオリンピック - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%83%8E%E3%82%AA%E3%83%AA%E3%83%B3%E3%83%94%E3%83%83%E3%82%AF

真ん中くらいにある表ですが、
このように塗りつぶして使うのはストリクター的にはどうなんですか？
ソース見たところ、CSSを使って色を付けてるみたいですが、
構造的に見たら全くわけわかめですよね？中身は空っぽですし。

たまに異端が入ってこないと
もりあがらないし。
でもTABLEでレイアウトうんぬんいうやつは
さすがに出なくなった気がする。

>>690
そうだね。
あれじゃただの空っぽテーブルだ。
○でもいれとけばいいのに。
ってことで、○入れといた。

どうしてもあの見た目にしたいなら、
CSSでinvisibleにして色付けかな。

>invisible

if i was invisible〜♪

ぱんくずリストをStrictに書きたい場合どうすればいいでしょうか？

前スレ見たけど必要・不要論で終わっちゃってて

>>695
linkをJSで書き出し。
スキルがないのなら、個人的には順序リスト。＞も無論素じゃなくてCSSで書き出し。

>>696
おｋ　�dｸｽ

JSで書き出せばStrictになるとおもってるのはおかしい

プログラミングにまったく無知なんですが
プログラムによって書き出したものはマークアップしないでも表示できるんですか？

>>696
> スキル
誰でも探してコピペできそうですが、どんなスキルでしょうか。
> 個人的には順序リスト
何をキーにして順序が決まるのでしょうか。

漏れは
<ul>
　　<li><a>第一階層</a>
　　　　<ul>
　　　　　　<li><a>第二階層</a>
　　　　　　　　<ul>
　　　　　　　　　　<li>第三階層</li>
　　　　　　　　</ul>
　　　　　　</li>
　　　　</ul>
　　</li>
</ul>
ってやってるＹＯ！
だけどこれでいいのか不安です！ダメならダメって指摘してください＞＜

>>700 の、何をキーにして、という疑問ですが、JSで自動化するという >>696 の前提あっての物です。
パンくずリストは、必ずしも、URIの "/" の数で順序が決まるわけではありませんが、そういう例外をJSに含めるのもかったるいですし、そういう例外が生じないようURIの形に制限を設けるというのも本末転倒でしょうから。

A1
B1
　B2a
　B2b
　　B3a
　B2c
C1
とかやるつもりならそれでいいと思うけど、
普通は素直にパンくず置いた順に
場所1
場所2
場所3
でいいと思うよ。
その場所がたまたま階層と対応することもあるだろうけど。

>>703
パンくずリストとは 【topic path】　─　意味・解説 ： IT用語辞典 e-Words
ttp://e-words.jp/w/E38391E383B3E3818FE3819AE383AAE382B9E38388.html
> Webサイトの中のそのページの位置を、階層構造の上位ページへのリンクのリストで簡潔に記述したもの。
だからパンくずリストは「たまたま階層と対応することもある」んじゃなくて
「階層と対応していないといけない」んじゃないの？

パンくずリストは縦のつながりをあらわすものであって、
横のつながりをあらわすのはgoogleの検索結果とかにみられるようなページナビゲーション。
縦のつながりと横のつながりが混在するナビゲーションを一行にまとめたら
操作性が落ちるだけでユーザビリティ的にマイナスだと思う。
縦のつながりと横のつながりを同時にあらわすなら
普通のメインメニューとかリストでツリー表示したサイトマップがあるじゃんぬ。

>>704
Xに行く経路が
a->B->Xとc->E->Xなど二種類以上ある場合に、
パンくずが別の表示になるのを見たことがあるよ。

実際URLが違いました、なんてオチではないことは
そのとき確かめたと思ったが、詳細は覚えてない。

>>701ですけど、各ulの中はli一個だけです。
レンダリングするときはcssで一列にしたりしています。

>>705
A,"B",C -> B1,B2,"B3" -> <B3a>,B3b,B3c
（"",<>以外は縮小表示）
みたいのはありかなあとか思いながら書いた。

>>706
それはそもそもサイトの構成がよくないとか、そんなことはなくて？
home > categories > html&css > 記事ほげ
と
home > archives > 2006 > 02 > 08 > 記事ほげ
の参照している「記事ほげ」と「記事ほげ」が同じ場合とか？

>>708
そんな大掛かりなのもやっぱりパンくずリスト？
なんかパンを丸ごと・・・・というか
オカズとかも一緒に落としているヘンゼルとグレーテルを連想してしまう・・・・

ヘンゼルとグレーテルのことは思い出さなくてもいいよ

>>709
そうそんな感じ。

日記コンテンツとコラムコンテンツがあって、
コラムのインデックスから日記の特定日にリンク張られてたり、
とかもありうるかな。

>>710
パンくずというには大掛かりだと俺も思うけど、リストを入れ子に
するってのはそういう意味あいだと思うんだよなぁ。
じゃなきゃ入れ子にしない順序リストでいいと思う。

>>708
e-Wordsに
パンくずリストは垂直方向のナビゲーションであるため、「この階層には他にどんなカテゴリがあるか」といった水平方向のナビゲーションを表現することはできない。
って書いてあった

てか、全ツリーを展開させてあるメインメニューを使いまわして、現在位置とその親を
他と区別するスタイルが適用されたものを置けばいいんじゃない？

ホーム☆（☆になっているけど太字にするとか色を変えるとか下線を引くとかなど）
　ページ１
　　ページ１−１
　　ページ１−２
　　ページ１−３
　ページ２☆
　　ページ２−１
　　ページ２−２★
　ページ３
　　ページ３−１
　　ページ３−２
　　ページ３−３

こんな風にメインメニューに目印をつけたらパンくずナビなんていらないじゃん。
ページ数が少ないことが前提だけど。。

>>713
スタイルシート切ってたら意味ないから、その方法なら
<em>ホーム</em>
　ページ１
　　（中略）
　<em>ページ２</em>
　　（中略）
　　<strong>ページ２−２</strong>
　（後略）
などとしないといけないような

head要素内のものをスタイルシートで画面上に表示させているサイトが
以前このスレで紹介されていたと思うのですがurlを知っている方がいましたら
教えていただけないでしょうか

おまえの頭ン中を見たいよ。

著者が勝手に要素とか属性とか定義しちゃいけないって仕様書に書いてあったと思うんだけど、どこだっけ。
SGMLほとんど知らないから何て言って良いか解らないんだけど、DOCTYPE宣言のへんでごにょごにょするやつ。

>>717
？？
そりゃDTDに定義してない要素を勝手に使ったらいけないけど
DTD書き換えたり別名前空間使ったりして独自要素・独自属性を定義するのは
何の問題もないよ？

もっともDTD書き換えしたらHTMLとは別物になっちゃうからUAのサポート対象外だけど。
別名前空間の方がオススメ

パンくずリストについてだが、そもそもWebの特長は関係するリソースが自由に、有機
的に結びつき、自由に情報を取り出せることにある。これはティム博士も言ってる。
で、パンくずリストは階層的で、元から非Web的じゃないかと。
つまり、元から非Web的で紙媒体でもあまり使われていなかったパンくずリストは過渡
的な存在で、当然の如く正しいマークアップなんぞ存在しない気がする。

違うだろ、自由に結びついた中に
関連性があるから階層構造になるんだろ。
たとえパン屑リストがなかったとしても
文書の前後左右？という関係性は存在する。

Strict-HTML スレッド 31のログが見られる場所があったらおしえていただけないでしょうか・
http://bell.skr.jp/web/strict/にはまだ31がないみたいで

>>721
にくちゃんねる

こーゆー書き方は許されますか？

<dl>
<dt>リストのキャプション</dt>
<dd>
<ul>
<li>うんこ</li>
<li>うこん</li>
<li>こんう</li>
</ul>
</dd>
</dl>

<ul>
 <li>ウルトラ</li>
 <li>マンコ</li>
 <li>スモス</li>
</ul>
<ul>
 <li>リンゴが</li>
 <li>いちまんこ</li>
 <li>ありました。</li>
</ul>

ul > li {
 list-style: none;
 display: inline;
}

<ol>
 <li>本当に</li>
 <li>ありがとう</li>
 <li>ございました</li>
</ol>

>>718
良かったっけ。仕様書にやらないように書いてあったような気がしたんだけど、勘違いだったかも。サンクス。

>>726
もちろん、その文章がXHTML(HTMLでもいい)なら、タグをとっぱらったときに
読めない文章になってるのは望ましくない。

UAのデフォルトの動作として認識出来ない要素を見つけたら
タグだけ無視していいってルールがあるから。
＃あるから…ていうか、あるよね…たしか？

実際、勝手要素より勝手属性の方が扱いが楽。

XHTMLがメインじゃない場合はその限りじゃない。
何かのXMLデータの中でハイパーテキスト使いたいからXHTML組み込んでる場合とかは、
その外側のXMLデータの部分がHTML用のUAにどう認識されようがしったこっちゃない。

XHTMLMODでなくてそういうレベルの話なのかい…。

どういうレベルだろうと、
人によってその規定を選ぶ理由さえしっかりしてりゃ問題ないでしょ。

>>728
XHTMLMODも名前空間切っての勝手要素も
UAにとっちゃたいした違いはないんじゃね？
どっちも未知の要素し。

つConformance Definition

target="_blank"って非推奨らしいけど、どういう代替方法取ればいい？

>>732
こちらで質問するのがおすすめ

Webサイト制作初心者用質問スレ Part 153
http://pc8.2ch.net/test/read.cgi/hp/1138784251/

>>732
使わないかJSで選択できるようにする。

>>733
そっちと迷ったんだけど、こっちの方がより堅実or裏技的な答えが貰えるかと思って。
一応調べはしたけど見つからなかったよ。

>>734
それは考えたんだが、JavascriptはOFFの人も結構多いし、
わざわざtarget="_blank"を使わない意味がないなと思ったんだよね。
で、代替が無いのに非推奨ってどういう事？って感じで。

>>735
さて、CUI や音声ブラウザでは 『新しいウィンドウ』 は一体なんでしょうか。
知っての通り、そんなものはありません。

非推奨だろうがなんだろうが、使いたきゃ使えばいいのに。

>>735
使わなきゃいいだけ。
非推奨どころかものによっては完全禁止。
代替はいずれCSSで出るがないままでも全く問題なし。
以上。

表示のされ方についてはスレ違いですので

>>737
折角意識してやったんだからやれる所までやりたいなと。
覚えておいて損はないだろうし。

>>738
>代替はいずれCSSで出るがないままでも全く問題なし。

ってことは普及するまではかなり時間かかりそうだね。
現実的に考えて代替手段が無いなら諦めるしかないかぁ。

>>740
裏技でいいならbecss(Trident)とxbl(Gecko)を使えば何とかなるはず。
http://www.w3.org/TR/becss/
http://www.w3.org/TR/xbl/
Operaは-o-linkや-o-link-sourceを拡張してるもののtarget属性と同等の機能は無い模様。

becssのurlミスった
http://www.w3.org/TR/becss

floatって回り込みの設定なんですよね？
ということはfloatを使っての段組はまずいのでしょうか。

あっちこっちに釣りが出てるが同じ人物なのか？

>>742
IE5以降での○○behaviorと同じだな

>>741-742
THX。
こんな方法もあったのね。参考にします。
ただ、Operaで使えないのがちょっとネックで残念ながら使えないかも。
メインがOperaどころか、Opera系のサイトなので。

ていうか非推奨じゃなくても別窓はウザイという意見が多いのに・・・

別サイトへの target="_blank" は優しいか
http://pc8.2ch.net/test/read.cgi/hp/1136738511/

普通に一般人に聞いたら違った答えになるんじゃないの？
コンテンツによっては、説明見ながら他のサイトでDLしてきたりとかみたいに、
状況次第でベストはどうとでも変わるし

strictであることと別の問題だな

>>748
そういうのも全部「統計で」出てるんだから
非推奨を使うつもりなら前スレから全部読んで恋

スレ違いなんだから誘導されたスレにいい加減池

というか誘導しようとしてるやつだけが持ち込んでるんだがw

大漁だな

あっちもこっちも釣りばかり。

リンクを

サイトマップ|検索|ヘルプ

のように"|"で区切って並べたいのだが。

この"|"はHTMLに直書きしてもOK？
それともCSSを使って付加すべき？

>>754
私は、borderを使っている。

>>754
直書きは好ましくない。
してもいいということだったらフォントイジリだって（ｒｙ

>>754
CSSでコンテンツ追加も出来るけど、
IEの実装がしょぼいからおすすめしない。

>>755 みたいにborderを入れるのがいいんじゃない？

でも ">" みたいなのとか画像を入れたい場合は
直書きするか、IE切り捨てしかないんだが。

...なんだかんだいってIEが実装してくれないと絵に書いた
モチな機能って多いよな。
Geckoで見れるっていってもシェア少なすぎてオナニー止まりになってまう。
IE7もいまひとつって話だし、なんだか悲しいなぁ…。

う〜ん、例えば"|"じゃなくて

サイトマップ、検索、ヘルプ。

とした場合も"、"や"。"をCSSで付加するべきなのかな…。

>>757
ウチのサイトFirefoxのシェアが7割行ってるが。
閲覧者に勧めてみたらどうだ。

>>758
それが「文章」なら直書きだろ。

"サイトマップ、検索、ヘルプ。"が伝えたいんなら
そのまま書けばいいと思うけど、
"サイトマップ"と"検索"と"ヘルプ"が伝えたいんだったら
コンテンツに書く必要はないんじゃね？

あんまり厳密にやると、記号による文書構造の記述は
やっちゃだめ!ってなっちゃうから程度問題だとは思うけど。

シャープ使ってコメント風に余談を挟むとか、括弧書きで余談を挟むとかは
UAがそれを余談と認識出来ないから適切ななにかでマークアップすべきだ!みたいな。
ルビなんかは複雑な要素だっただけに浸透しなかったしね。結構有用なはずだったのに。

>>759
閲覧者にするめる、というのは
いわゆる「このサイトはFirefoxで最適化〜、解像度は〜」とかいう方法で？
それとも自サイトの馴れ合い掲示板で「Firefoxいいっすよ！おたくもぜひ！」とか？
・・・じゃないとしても、
どんな書き方をしても閲覧者にあまりいい印象を与えない気が。

>>761
ブログ等で
> IEの実装は最悪、IEなんて使っている人は今すぐFirefox(Opera)へ
なんてエントリを見るとIE使ってなくても感じ悪い

>>759
どんなサイトかはしらないけど、
それは結構特殊な例だと思うぞ。
FireFox使ってる人はいまだ逸般人だけだと思うよ。

便利な機能が沢山あるんだけど、なんていうか
開発者のおもちゃ的な便利さになっていて
環境設定するのが苦じゃない人じゃないと勧め辛い。

Greasemonkeyとかしこしこ設定しているうちのオカンなんて
絶対想像出来ん。

はいはいスレ違いスレ違い

>>764
いいじゃん。たまにはパンくずリストの書き方とか
dlがいいかulがいいかとか以外の話もさせてくれよ。

>>761
そんなことしなくてもバナーという便利な（ｒｙ
それはさておき、シェア率の低い日本でさえも1割行ってるデータあるんだし欧米じゃもっとなんだから
別にオナニーじゃないと思われ。
というかそれ言ったらデザイン自体がオナニー。

dlで思い出したけどdt要素のデフォルトスタイルがlist-itemじゃないのが気に食わない。

Strictというオナニーネタを扱っているスレとは思えない発言だなｗ

>>766
1割はマイノリティーじゃないのか…？

デザイン自体がオナニーは同意。
Atomで記事読むようになってからはデザインなんて見なくなったよ。
ていうか記事だけ読むから配信元サイトすらいかね。

>>768
理由を述べよ。

firefoxのバナー貼ってるだけで多くの訪問者が
クリックしてダウンロードしてインストールしてくれるなんてうらやましすぎ。
コンテンツ内にfirefoxを宣伝する記事とかなしで？

Googleのアフィでも入れとけや。

>>769
10人の閲覧者の1割は1人。
100人の閲覧者の1割は10人。
1000人の閲覧者の1割は100人。
．．．．．．

>>768
Strictはオナニーというより合理性のため。
はっきりいってテーブルタグ満載のソースなんてあとで見返しても自分で理解できん。

ビルダとか使ってるなら無問題

プロも使っているドリームウィーバー使っているから無問題

>>766
本当にバナー貼ってるだけであなたのサイトにアクセスしてくる人のFirefoxユーザ率急増なの？
そのカリスマ的影響力、金になるよ！

>>769
http://www.iajapan.org/iwp/
>日本のインターネット人口は2005年2月調査時点で7,007万2千人になりました。
の1割だとすると700万人だな。

ぶっちゃけタグ打ちを手書きでやる必要なんて全然無いしね。
ガチガチに意味付けしてたら文章本体がタグで細切れになってて
どのみちぱっと見理解出来ないものになるよ。

市販のHTMLエディタを使いもせずに気に入らないというなら
そこらへんのWikiのフォーマットエンジンだけ引っこ抜いてきて
自前の平文フォーマッタでも作るのがお勧め。

手書きだと間違いがおきる可能性があるからvalidatorでチェック
しなきゃいけないけど、ツールで書けばバグが無いかぎり
validであることは保証されるし。

>>773
10人に1人を多いと見るか、少ないと見るかは
人に依るのかな。

でも仕様通りに作ってるんだから…を強行して
9人がまともに見れないサイトを作っちゃうのは
アタマ悪いと思う。
まあ誰もそんなこと言ってないだろうけどさ。

>>779の言いたいことがよくわからないんだけど、
WYSIWYGだけで作っていたら合理性とか関係ないよね、って流れじゃない？
タグ直打ちしろとまでは言ってない気が。

>>744
どうだろね。

HTMLとしてvalidである部分は合意がとられてるけど
Strictってなると結構人によってゆらぎがあるからなぁ。
1年前の自分の書いたHTMLが今の自分にとって納得のいく
マークアップになってるかは微妙だ。

見られないを見れないと書く>>780がアタマ悪いと思う。

>>781
ごめん。
HTMLエディタを反射的に擁護しようとしちゃったんだよ…

>>783

ttp://academy4.2ch.net/test/read.cgi/gengo/1138765997/
ここのテンプレ興味深いよ

>>783
いつもおつかれさまです。

言葉の仕様書は後付けだもんね

HTMLの仕様書もな

>>757
>でも ">" みたいなのとか画像を入れたい場合は
>直書きするか、IE切り捨てしかないんだが。

backgroundでも何でも使え。頭柔らかくしろ。

>>789
なんかさ、HTMLはStrictなのに
CSSはもうなんでもあり的なのってどうなのかなと。
バッドノウハウ満載なかんじですごくいや。

contentで画像を呼び出せ！！対応してるしてないは関係なし！！

しかし、直接'|'だの画像だの書くことによる
デメリットってなにがあるんだ…？

それはデザインじゃなくてコンテンツなんだ…って
自分を説得して直接書いちゃったほうがぜんぜん良いよな。
そこがその文章の本質でもないし、そんなんのために
cssでごにょごにょしたり色々なブラウザで見たりするのも
面倒すぎ。

そもそも">"は何を表現したいの？階層？"|"はセパレータ？

>>790
あれができないこれができない、でもこの方法は気持ち悪いから嫌、か。
CSS2.1完全準拠のレンダリングエンジン開発&普及させてみれば？

質問主じゃないと判らんよな。
俺の主観だと、
見た目から受けるイメージとしては > は階層、
| は列挙のセパレータかね。

しかしIE7にならんと
素のULに対して "a | b | c" をCSSで実現することは
不可能なのね…

いっそ>>791みたいに割り切っちゃうのがいいんだろか。

>>794
きたこれ。
はいはい。OSでも言語でもなんでもつくりまっせ。
そうじゃなきゃ文句の一つも言えないしな。

>>792
音声ブラウザはそれをどう解釈していいんだ？
|をセパレータと見なせるのは人間の視覚だけのような。

>>771
バナー貼って、IE用でも見られるようにするけど
細かな部分でFxその他じゃないとカコヨクないサイトに自然となってたら、
お客さんもそうなったる

>>797
正直、リンクの羅列の中の'|'を読み飛ばせないような
音声ブラウザなんて、今のWebの現状を鑑みれば使い物にならないと
思うんだが…。
言いたいことは判るし、私もそう思うけどね。

>>798
知らないで|を使うならともかく、知ってるなら|を直書きはできないな。
別に|がなかったとしてもマージンが入ってれば人間の目なんて便利なもので
それだけで区分けされてると認識できるし。
ulのインライン化がStrict的には好ましい希ガス。

とりあえず、>>799の言ってる
「知らないで|を使うならともかく、知ってるなら|を直書きはできないな。」
で終りにしとけよ。

これ読んでるおまえらは知っちゃったんだから'|'の直書き禁止な。

じゃあ一休み。

ttp://abcdane.net/blog/archives/0602/deka_rabbit1.jpg

ところで、偉そうに語ってる人がいるけど実際にそこまでやってるの？
ここで語りながら実際は面倒だからいいやで終わらしてそうなんだけど。

>>797とか
つかこの手のでいつも思うんだけどそれはFx以外のお客さんが逃げて行ったんだろーね。
# たとえばblogでいつもFxのplug-inの話とか書いてたらFxよりになるとか、
# Strictの話ばっかりしてたら逸般人ばっか来るとか
漏れのサイトはSafari優先でCSSとか組んでるけどMacとかwebデザの話が多いからSafari人口多いし。
Windowsユーザが読んでもあんまり面白くないんだろう。
バナーは関係ないよ。おそらく。

>>802
具体的にどのレス？というかここstrict-htmlスレだしなあ。

>>802
やってるよ。
Strictにすること自体はそんなに面倒じゃないから。
一度テンプレ作って、自分の中でルール決めとけばそれでOK。

>>779みたいにWikiのフォーマットエンジンみたいなので
決まりきった部分は自動で書き出させてるから
HTMLエディタで書いてるのと遜色ないと自分では思ってる。

凝ったデザインとかしようとするとやりづらいけど。
CSS方面は弱いのよね。

<!-- HTML -->
<ul>
  <li><a href="/">ホーム</a></li>
  <li><a href="./">目次</a></li>
</ul>

/* CSS */
ul li {
  margin: 0;
  padding: 0;
  list-style-type: none;
  display: inline;
}

ul li + li:before {
  content: " | ";
}

*texでhtmlファイルを書き出してる人いる？

>>806
IE6じゃ無理。
せめてmarginなりpaddingなり付けといてくれないと
くっついちゃってユーザビリティ最悪。

>>807
latex2htmlとか？
正直texの文法は好きになれん。
数式のとこだけは好きだけど。

研究職で常にtex書きまくりで慣れてるとか
たまった論文をとりあえずwebに載せたいなんてことがないかぎりは
一からtexで書いてhtmlで出すことはないだろうな…

>>800
ていうか区切りに|使わないなんて当たり前なんでわざわざ煽らんでも。

>>803
減った人がいたととしても、PV/dayむしろ増えてるからどうでもいいや。
ブログも日記もないサイトなんだがな。

>>808
IEじゃ無理だから、というのには同意しかねるが、
margin使わずcontentで書き出したテキストの半角スペース使うのはナンセンスだな。

>>810
それじゃ結局IEからFxへの改宗への貢献は出来てないってことなのね。
てかもともとそんなつもりなんて微塵もないだろうけど。

個人レベルの統計なんて所詮そんなもんだよね。

strictであることとデザインは別だからな
結構見づらいのが多くて萎える事も多い

>>812
Firefoxの統計が1割から国によっては3割ってのは個人統計じゃないんだがｗ

strictでないこととデザインは別だからな
とっても見づらいどころか読めさえしないのが多くて萎える事も多い

>>814
>>759の7割がFxってのに対して言ったんだよ。

そだね。
ここはStrict語るところだから
見やすいデザインは別のとこで要修行ってことで。
問題のレイヤが違うよ。

>>812
なんでそんなことわかるんだ？
既存の閲覧者がFxに乗り換えたのかもしれないじゃないか。
入れ替わっただけと言える根拠もない。

母体数がわからない以上、どっちとも取れるからなぁ。
なんとなくFx利用者は増えてるっぽい、ぐらいに捉える材料ぐらいにしか
ならんだろ。

何となく増えてる、だったらWeb全体で何となくIE以外が増えてきてるからなぁ。
IE7で結局正式版でもcontentもサポートしないままだったら本当にどうなることやら。

cssのcontentプロパティがブラウザシェアを左右するとは思えんけどな。
home|rss|linkを直書きしようがしまいが、
利用者側からはほとんど何も変らないと言いきれる。

そんなことより、今年度最大のBuzzワードたるAjaxと、
StrictマークアップなXHTMLの共存を考えようぜ。

ボタンを押したらなにかが挿入される予定のdivとか
ページ全体を暗くしてダイアログ出すためだけのdivとか
見ためはcoolだけどhtmlグチャグチャだよ…

>>821
contentだけじゃ変わらないかもしれないが
そういう小さな積み重ねがIEを落として来たわけで。

しかしそれで書き出されたHTMLはStrictじゃないから語る余地がない。

innerHTML使おうとしたらspanが空だって怒られた俺がきましたよ

ところでよ、この記事はマジ？釣り？
http://internet.watch.impress.co.jp/cda/news/2006/01/23/10575.html

>>821
> ボタンを押したらなにかが挿入される予定のdivとか
> ページ全体を暗くしてダイアログ出すためだけのdivとか
> 見ためはcoolだけどhtmlグチャグチャだよ…
これはajaxについての話？

>>824
統計の取り方は英語のページにかかれているの？
妥当な方法だったかわかんないからなんとも。

2006年1月だとこっちもかな。
ttp://japan.cnet.com/news/tech/story/0,2000047674,20094642,00.htm

>>823
innerHTMLは標準じゃなかった気ガス
取り敢えずDOM3のパーサー系APIとappendChild使っとけ

>>828
そうなんだ
ただ、Javascriptはかじった程度だから書き換えが大変なんだよね
しかもperlで一部異なった出力してる感じなのでややこしいというおまけ付き
現段階で殆どのブラウザで使えてるっぽいんで、流石にメンドイからこのままかも

次に組むことになったら、がんばってそっち使ってみるわ

>>829
ああ、なんとなくわかるわ。
プログラム言語と組み合わせる場合って、
無駄な要素を加えて管理しやすさや見易さを取る場合があるからな。
strictであることや、無駄な要素を加えないだけの事ならそれ程難しくは無いが、
それだけではないというか。

cite要素って書籍などのタイトルだけじゃなくて
音楽の曲名や詩のタイトルやテレビの番組名をマークアップするのに使っても問題ないですか？
その内容（の一部）に言及している場合とかで。
あとサイト名も、

<q 省略>標準的なブラウザでは、斜体で表示されます。</q>って
<cite>XHTMLリファレンス</cite>に書いてあった。

みたいな使い方ができますか？
その場合、

<cite><a href="省略">XHTMLリファレンス</a></cite>

ってマークアップすべきですか？



（あと、q要素のtitle属性とcite要素の中身、
またq要素のcite属性とcite要素内のa要素のhref属性が重複しますが問題ありですか？）

>>831
問題ない。
リンクは任意だが、そんなに気になるんなら
<cite>うんちゃら</cite>（<a href="うんちゃら">URL</a>）
とかでどうだ。

>>831
>cite要素って書籍などのタイトルだけじゃなくて
>>音楽の曲名や詩のタイトルやテレビの番組名をマークアップするのに使っても問題ないですか？
>その内容（の一部）に言及している場合とかで。
全然問題ないかと。
isbnみたいにurnが定義されてるならそれを書いておくのもいいかもしれない。
そのうちだれかが拾って使ってくれるかもしれないし。

>（あと、q要素のtitle属性とcite要素の中身、
>またq要素のcite属性とcite要素内のa要素のhref属性が重複しますが問題ありですか？）
両方でいいんじゃね？
要素だけで見ると、qとciteの関連性が記述出来ないから。
メタ情報は多すぎて困るってことはない。


そこらへんになってくると、要素付けすることによって何が嬉しいかとか
考えながら書くといいのかもね。

http://www.w3.org/も|を区切りに使ってんじゃん？
どうなのよ。この辺り。

StrictorがW3C信者だと思ってるあたりでもうダメだよ。

まあ、衝撃的な事実ってことで。

strictは手段なのに、目的になってしまってる人が居るだけだから。

Strictって、別窓を禁止してるのがおかしい。
ほかはいいんだけど、これだけがどうも。
構造的にも、同じ窓と別窓のリンクは使い分ける意味があると思う。
単純に_blankとしなくても、直接参照と参考参照とか、なにか別のものがあっても良かっただろうに。

プラグインのダウンロード先のリンクなんかは、別のほうが良いんじゃないだろうか。
このあたりの議論が、規格化までのあいだにW3Cででなかったのだろうか。
別窓リンクがを使う奴がいるということは、それなりの用途があるってことだ。
それを無視してるのがどうもなあ。

>>838
>>733-742

別窓指定なんてこの世からなくなればいいのに。

>>839
環境依存度が高すぎて使えない。

別窓強制する奴は毎度のこと行儀が悪いな。
おとなしく隔離されてろ。

別サイトへの target="_blank" は優しいか
http://pc8.2ch.net/test/read.cgi/hp/1136738511/

<a href="uri" target="_blank">アンカー文字例</a>

こうした場合、GUI以外の環境だとどうなるの？

GUIかどうかは関係ないだろ。
lynxなら普通のリンクと同じ。
w3mは設定すればタブで開ける。

>>838
>別窓リンクがを使う奴がいるということは、それなりの用途があるってことだ。
>それを無視してるのがどうもなあ。
そのためのTransitionalです。

別窓なんてそもそも特定の環境でしか実現しないし、特定の人しか喜ばない。
特定の環境の特定の人が90%を占めるかもしれないが、だったらJavaScriptでやれば良い。
あんたのサイトの利用者の85%はJavaScriptが有効だから。
JavaScriptが効かないようなマニアックな環境の奴は別窓も嫌がる。
それに、別窓で開かないのは不便かもしれないが全然不幸じゃない。

window.onload = function (){
var a = document.getElementsByTagName("a");
for (i = 0; a[i]; i++) if (a[i].getAttribute("className") == "toAnotherSite") {
a[i].setAttribute("target", "_blank");
a[i].appendChild(document.createTextNode(" (別窓) "));
}
}

俺はツンデレだから、超スレ違いだが特別に書いてやった。
これをhead要素内に突っ込んで、target="_blank" を class="toAnotherSite" に置換すれば良い。
そしたらIEだけ別窓で開くようになる。Invalidになるけど、IE限定だから絶対問題起きないっていうかIEとかどうでも良いし。

あー、くれぐれもOperaでも効くように改造したりしないように。俺たちOperaユーザの90%は簡単に別窓開けるから。
こういう便利な機能の発達を邪魔するからHTMLで操作系に干渉するのは良くないんだよ。

これで解決しただろ？ 今後もう二度と別窓別窓言ってこのスレを荒らさないように。

>>845
在庫を抱えすぎ。必要も無いのにload時の仕事が多すぎる。
DOM-CoreやDOM-HTMLを使わずにDOM-Event使え。

というか、getAttribute('className') は、IE独自仕様だから(笑)

ついでに、スレに即したことを言っておこう。
J(ava)Scriptの作法ではキャメル表記だが、CSSやHTMLでは、ふつう、ハイフンを使う。
toAnotherSiteという文字列値は、HTMLの属性値としては今一。class属性は、CSSの手垢にまみれた属性だから、尚更。

あ、
> IE限定
と書いてるよ>>845。
何なんだ、そのニートな書き方は。そういうことは、離すものじゃないよ。コードにコメントとして書け。
そもそも、IE限定なら、条件コンパイル使えよ。たとえるなら、CSSハックみたいな非ストリクトなことだろ、getAttribute('className') で弾くのは。

あと、class属性はスペースで区切る、と、HTML仕様にあるから、
\btoAnotherSite\b みたいな正規表現で保険かけとくべきだな。

>>846-847
突込みどころは多いが相手にするのもアレなのでこちらにどうぞ。

別サイトへの target="_blank" は優しいか
http://pc8.2ch.net/test/read.cgi/hp/1136738511/
Webサイト制作初心者用質問スレ Part 153
http://pc8.2ch.net/test/read.cgi/hp/1138784251/
+ JavaScript の質問用スレッド vol.45 +
http://pc8.2ch.net/test/read.cgi/hp/1138691397/

XHTML 1.0で以下のような記述をしてもStrictでしょうか？

<script type="text/javascript" src="./script.cgi"></script>

すみません。追加です。
XHTML 1.0で以下のような記述をしてもStrictでしょうか？

<img src="./script.cgi" alt="hoge" width="100" height="50" />

だからJSで書き出せばStrictになると思ってるヤツはおめでたい

だからStrictでJSを使ってはいけないと思ってるヤツはおめでたい

だからStrictでJSを使ってはいけないという主張だと思ってるヤツはおめでたい

>>851
どういう意味ですか？

もちろんW3C勧告に則った形でJavaScriptを利用するつもりなのですが。
cgiで記述したtext/javascriptやimg/gifをsrcで指定してもいいのかを聞いております。

Webサイト制作初心者用質問スレ Part 153
http://pc8.2ch.net/test/read.cgi/hp/1138784251/

>>856
誘導ありがとうございました。

>>856
あんなに面白い人材を下げ渡ししないでくれｗｗ

あちらには分かる方がいらっしゃらないということでしたので戻ってきました。
ストリクタの方が賢そうなので、よろしくお願いします。

いつもの釣り人？

いえ、私はアングラではありません。

<include type="text/html" src="./hoge.cgi" />
こんなタグがほしいなということです。

質問なのですが、aタグのtarget属性はだめらしいんですが、宣伝をクリックして同じウィンドウで開いて宣伝先のページがしょぼくて、
そのまま閉じられてしまったらどうするんですか？
他のページも見てほしいのに。

>>863
そんなあなたに最適のスレをご紹介します。
>>848からどうぞ。

talk:>>862 クライアントに都合の悪いことだな。

>>865
そんなことはないです。
テキストカウンタで使うという例は分かりやすいと思います。

改変不可の広告を掲載した時点でストリクトじゃなくなるという現実を、ストリクタの皆さんはどうお考えですか？

SSIつかえば？

<あぼーん>849</あぼーん>
こんなタグがほしいなということです。

世の中には広告挿入必須の無料レンタル鯖しかないような発言

>>868
CGIやPHP、そしてSSIを使うと、検索エンジンに少しでも嫌われる可能性があるのです。
それを避けたい。どうしてもです。
検索エンジンが、ああでなければ私はCGIやPHP、そしてSSIを喜んで使うでしょう。

849のサイトなんか嫌われてください＞＜

>>869
ヒント：NGワード

>>872
便利なサイトですよ。
そしてHTMLをインクルード出来ればもっと便利になります。

>>871
「検索エンジンが、ああで」あるというのはどこに書いてありますか？
各検索エンジンが「CGIやPHP、そしてSSIを使うと、嫌います」って書いてあったり？
興味あるのでよかったらソースとかお願いします。

>>873
単なるイヤミだよｗｗ

>>875
cgi seoとかphp seoとかshtml seoとかで検索してみると出てきますよ。
時間がないので自分で試した訳ではないのですが。

PHPやCGIからテンプレートを読み込んだりして表示している
くだらないBlogたちも嫌ってほしい　＞各種サーチエンジンさん

SEOなんて幻想とWeb業界の新しい商売道具に過ぎないよな・・・
StrictにするのがSEO対策とか言って馬鹿か。

それでもやっぱり上位表示されたいね

結局内容が目を惹いてみんなに利用されてリンクされないと上位は難しいな。

うん

>>877
cgiやphpそのものが検索エンジンの機嫌を損ねるなんてどこに書いてある？
ずばりそのサイトを提示して。

うん

>>883
動的ページがキャッシュされにくいというのは前々から常識的に言われていることだが・・・

>>883
【SEO】検索エンジン総合スレ15【雑談】
http://pc8.2ch.net/test/read.cgi/hp/1133992211/

cgiやphpそのものではなく使い方による

引数が無ければいいのかな？

いいかげんスレ違いは移動汁

849の主張は何なんだ・・・
まとめるとカウンターやアクセスログをストリクトに呼び出しつつSEO対策したいってこと？

あ、アクセスログじゃなくてアクセス解析とかアクセスアナライザって言いたかったんです
すまんです

>>890
はい。

SEOを語るのはスレ違い

SEOを語るのは反則

うんこ

質問です。
Strictでサイトマップを作る場合、どのように組むのが一般的ですか？

title属性ってどの要素につけてる？
qとblockquoteとabbrとacronymにつけてるけど
inputなどのformアイテムやa要素にもつけたほうがいい？

>>888
そういうことなんだけど、誤解してる奴が多いよねｗ

>>896
一般的かどうかは知らないが、
俺はリストだと思うからulでマークアップしてる。

>>897
formはツールチップがウザイという意見を見たので付けていない。
代わりにフォーカスを当てたら消える説明文をvalueで入力部分に入れてる。
aはあったほうが個人的には嬉しい。
ま、自分がついてたら嬉しいところにつけたら良いんじゃないかな。

>>898
>>>886

>>899
> 俺はリストだと思うからulでマークアップしてる。
だね。

> 代わりにフォーカスを当てたら消える説明文をvalueで入力部分に入れてる。
javascript等で？

>>899
>>900
ありがとうございます。
ulでマークアップする際なんですが、CSSでmargin: 0; padding: 0; list-style-type: noneにして下のように書いても問題ありませんか？

<ul>
<li>
トップページ
<ul>
<li>┣会社概要</li>
<li>
┣商品説明
<ul>
<li>┃┣商品1</li>
<li>┃┣商品1</li>
<li>┃┗商品1</li>
</ul>
</li>
<li>┗お問い合わせ</li>
</ul>
</li>
</ul>

あ、問題ありまくりですね。
自己解決しました。

>>900
うん、JS。
サイトによるだろうが、うちは調べたら9割以上ONにしてたからまあいいか、と。
OFFでも使えないわけじゃないしな。

talk:>>867 文法を守って挿入してくれればstrictになるはずなんだが。
talk:>>874 だったら、scriptのソースをさらすぐらいのことはしろ。そうでないと、scriptとActive Xを分ける意味が無い。

>>904
なんだおまえそれｗ

あひーっ！

talk:>>906 お前誰だよ？

ジャイアンだよ

>>862
それはやめたほうがいい。
例えばFRAMESET…

あれってHTML文書というより、埋め込むためのファイルって感じがする。
だから include要素ってのは何かヤダ。

>>909
ssiのインクルードなら埋め込むって感じしないよ？