TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
とにかく掲示板に書きこみが欲しいなら・・
CSS・sass・less・stylus 初心者スレッド=15th=
+ jQuery 質問用スレッド vol.7 +
おまえらのアクセスアップ必殺技を教えてくれ。だめか?
HP作成に使用している無料ソフト教えて
カウンター総合スレTotal l0l0l0l0l2l Hit
┣━━携帯サイト用ランキング討論会━第11弾┫
SOHOやフリーで本当に細々と食ってる奴の121人目
GIF関連特許が6月20日(日本は来年)で期限切れ
何処までが"参考"で何処からが"パクリ"か

Strict-HTML スレッド 43


1 :2009/03/31 〜 最終レス :2018/05/01
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 スレッド 42
http://pc11.2ch.sc/test/read.cgi/hp/1208023080/
暫定まとめサイト: http://wiki.fdiary.net/StrictHTML/
初心者の質問はこちらへ
Webサイト制作初心者用質問スレ Part 207
http://pc11.2ch.sc/test/read.cgi/hp/1235589794/
実装の話は10中8, 9スレ違い。
関連スレは>>2

2 :
/* CSS・スタイルシート質問スレ 上級者用【71th】
http://pc11.2ch.sc/test/read.cgi/hp/1205680031/
XML→XHTML
http://pc11.2ch.sc/test/read.cgi/hp/1039933755/
ユーザビリティ専用スレ その3
http://pc11.2ch.sc/test/read.cgi/hp/1136275352/
【みらくる】XHTML 2.0 (その2)【ドリーム】
http://pc11.2ch.sc/test/read.cgi/hp/1098711758/
XML使いのスレ 2.0
http://pc11.2ch.sc/test/read.cgi/hp/1057198990/

3 :
次スレとかいらねーよ

>>1 乙 (*‘ω‘*)

4 :
次スレとか必要ねーし
>>1

5 :
なんで新スレなんて作っちゃうわけ?
>>1

6 :
あーあ、折角やっと終ったのに作っちゃったのかよ
>>1

7 :
乙乙うっせーよ

8 :
乙ぐらい書かせてくれよ

9 :
甲カワイソウス

10 :
| HTMLの要素・汎用のブロック要素(div)
| ttp://members.jcom.home.ne.jp/pctips/www/Element/div.html

> しかし、現状のHTMLは、olやdl/dt/ddのやうに、出現する順番が意義を持つてゐる場合が屡々あります。
って書いてあるけど「dl/dt/dd」の部分の情報源はわかりますか
| Lists in HTML documents
| http://www.w3.org/TR/html401/struct/lists.html#h-10.3
> Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.
の「会話文にも利用できる」というのが情報源なのかな
発言集じゃなくて会話は話される順番に意味があるわけだから出現順に意味があるってことなのかな
| li要素にdl要素を入れてみる | d-spica
| ttp://blog.d-spica.com/entry/070527li-dl.html
にあるようなこと(ここではスタイルとか見た目の話もしているけど)をしようとしてたけど
olと入れ子にしなくてもdlだけで順番に意味を持たせられるということですか
| dl要素の仕様についての疑問 - Webtech Walker
| ttp://webtech-walker.com/archive/2009/01/30091816.html
にもあるようにdlはなんか不備がありまくりな気がするけど

11 :
そこでいう「順番」は、単に dd の内容を指すキーは直前の dt だ、ってだけなんじゃないかな
それとも、そもそもそういう順番についての話?
とりあえず、旧かな使いの人のページは読みにくくて困るw

12 :
> そこでいう「順番」は、単に dd の内容を指すキーは直前の dt だ、ってだけなんじゃないかな
DTDだけ見ればこれも約束されたルールじゃないんすよね・・・
> それとも、そもそもそういう順番についての話?
や、改行の後の最後の三行はオマケですややこしくてすみません
ol内のliは出現順に意味がある
的な感じでdl内のdt&dd(便宜上これを一対とみなす)も出現順に意味があるのかなと
> li要素にdl要素を入れてみる | d-spica
> ttp://blog.d-spica.com/entry/070527li-dl.html

まさに
> 1. 手順1
> 手順1についてちょっとした説明。
> 2. 手順2
> 手順2についてちょっとした説明。
> 3. 手順3
> 手順3についてちょっとした説明。
みたいなことをやりたかったんですが
順番に意味を持たせるには
<dl>
<dt>手順1</dt><dd>手順1についてちょっとした説明。</dd>
<dt>手順2</dt><dd>手順2についてちょっとした説明。</dd>
<dt>手順3</dt><dd>手順3についてちょっとした説明。</dd>
</dl>
じゃなくて
<ol>
<li><dl><dt>手順1</dt><dd>手順1についてちょっとした説明。</dd></dl></li>
<li><dl><dt>手順2</dt><dd>手順2についてちょっとした説明。</dd></dl></li>
<li><dl><dt>手順3</dt><dd>手順3についてちょっとした説明。</dd></dl></li>
</ol>
ってしないといけないのかなと思ったり
それって冗長だなと思ったり

13 :
確かに冗長だし、手順1〜3の関係性がdlの外に出ることでバラバラになっちゃってるよね。


14 :
>>12
基本的に ul-li のリストと同じ感覚で順不同だと思う。
でも「手順1」ってわざわざ term 部分に番号明記するなら、前者の例で十分だと思うけどね。
番号なかったら、後者の例にするしかないかねえ・・・

15 :
関連性のある内容のdt/dd、liが別々のブロックレベル要素の下にはいるのって
なんか気持ち悪いけどそれしか方法ないのか・・・


16 :
>>14
「手順1」等の部分はその手順名が入ります番号は付かないっす
<ol>
<li><dfn>手順1</dfn>手順1についてちょっとした説明。</li>
<li><dfn>手順2</dfn>手順2についてちょっとした説明。</li>
<li><dfn>手順3</dfn>手順3についてちょっとした説明。</li>
</ol>
とかもありかなと思ったのですが
そのままでは文章として意味が通らないし意味が通るような文章に書き直すと
それはそれで冗長になって視認性に欠くというか
簡潔な箇条書きにしたいからこそのリストなのに
それに
dfn内の文字列とそれより右の文字列がdt、ddの関係とはまた違うな
と思ったり

17 :

<li><dfn id="hoge">手順1</dfn><a href="#hoge">手順1についてちょっとした説明。</a></li>
ってすれば明示的に紐付けることができるのかな
文章としてはいびつなままだけど・・・

18 :
なんかおら<p>で普通に文章ならべてそれでおわりでいいんじゃね?って気もしてきたぞ
手順1とかが具体的な「手順名」ならdfnでid振るのはいい感じだと思うけど
単に「その1」「その2」みたいなのならそもそも書く必要すらなさそうな。
<div class="process">
XXXする手順
<ol>
<li>手順1の内容</li>
<li>手順2の内容</li>
<li>手順3の内容</li>
</ol>
....
みたいな。

19 :
>>18
div直下は論外

20 :
またdtとddの一意性か
一意性はないよ

21 :
論点は「順序付けるには」

22 :
論外なのに論点なんぞあるかこのばかたれ
いつのまにやらDLからOLにすり替えやがって

23 :
>>10
というより文章が上から下に流れることに意味があるというのは
HTML以前の問題として言葉の基本だろうが
このレスを下から読んでも意味がないように

24 :
<h3>検索サービス</h3>
<h3>先進的なサービス</h3>
<h3>コミュニケーションと共有</h3>
<h3>モバイル サービス</h3>
<h3>パソコンをより快適に</h3>
と順に並んでいても出現順に意味がなかったりするしなあ(例は「Google サービス一覧」)
章立てじゃない塊の羅列を、その出現順に意味はないよという意味付けを与えるには
どうすればいいんだという疑問が逆に生まれる

25 :
というより現時点でのHTMLでは特に指定されてなければ
上から順に順序付けされると思っておいた方がいいと思うけどね。
>>24の例に拘ってたら何も書けんし、出回ってる文章まともに利用出来なくなる。
もしdt/dd利用するクライアント自分で作るとしたら登場順保持するでしょ?
ソート機能つけたとしても登場順に戻す機能は付けるだろし。

26 :
>>19
なんで?

27 :
HTML文書における要素の出現順序について
Orderedが初期値だとすると
Unorderedであることを明示するための手段が必要となる
リストの場合はそれが初期値であるOL要素に対するUL要素にあたる
すると他の要素にもUnrderedであることを明示するための手段が必要となる
逆に
Unorderedが初期値だとすると
Orderedであることを明示するための手段が必要となる
リストの場合はそれが初期値であるUL要素に対するOL要素にあたる
すると他の要素にもOrderedであることを明示するための手段が必要となる

リストだけulとかolとか要素を分けずに
すべての要素に対して
type="ordered"
type="unordered"
等と付けるようにすればいいのに
初期値はorderedであるとか決めておいて
ってそれだと
すべての要素にグルーピングするための親要素が必要となるのかな
divの出番だ

28 :
普通にかいてりゃなんかしらの親要素あるし
トップレベルにbodyさんがいてくれるし
事実上全てに>>27でいうtype="ordered"が指定されてるようなもんでしょ、現状は。
ulをunorderedな使い方してるクライアントもみたことないしな。
つかはよHTML5でてくりゃれ
今わざわざdivでせこせこクラス付けしてるのがどばっと要素に採用されるし
要素に格上げになったらブラウザ側でごにょごにょするのも増えるだろし

29 :
> 事実上全てに>>27でいうtype="ordered"が指定されてるようなもんでしょ、現状は。
それを一部だけunorderedにしたいとなると範囲指定のための親要素がいるんじゃない?
ulで囲んだ範囲内だけunorderedなように
今あるもので如何においしく料理するかがこのスレの趣旨であって
ないものねだりは場違いだけど
やっぱり物足りない

30 :
>>27>>28もごもっとも
しかしそのあたりのユルさはわざとの仕様のような気がする。

31 :
たぶんそれが欲しくなる局面なんてul使うときぐらいじゃない?
あと精々dlぐらいか。
>>24の例なんかもunorderedって指定したくなるかもだけど
あえて指定する理由も無いと思うんだよね
各要素を独立したものとしたけりゃidでも付けりゃいいんだし。
しかし架空の属性で会話するのもなんかキモいなw

32 :
ulって順序について「意味は無い」んじゃなくて「*深い*意味は無い」ぐらいなんだろな。

33 :
なんかみんなまったりだね
新スレでまだ手垢が付いてないから扱いが丁寧なのかな

34 :
そのうちまたlang="en"いちいちするとかwwwみたいな流れがもどってくるよ

35 :
>>32
ばーか

36 :
>>35
うっせ、このちんこやろう

37 :
>>12
DTD上書けるということと、日本語として正しい、正しい日本語とマークアップが対応しているということは別
dd抜きでdtだけの定義リストを書いてもそれはそもそもマークアップがおかしいだけで(ulでやれ)
寧ろdt:語、dd:説明という日本語が出てくるから定義リストになるだけ
お前は思考の手順がそもそも逆なんだよ
ついでにその人は文章が上から下へ流れる出現順にはテーブルレイアウトでも拘れと言及してたことがあるし
順序がないという意味をマークアップではなく言語そのものにまで敷衍させるのは間違いだろうよ
読めば単にdt→ddという順番のことを指していると普通は思う

38 :
元の日本語がおかしいのはマークアップ以前の話しである
見本は>>37

39 :
いいね、この意味もなく噛み付くスタンスこそこのスレに相応わしい。

40 :
うん、>>37 みたいに最後の 1行を言いたいだけなのに、余計な話いれたりするのはstrictらしい
HTMLは簡潔にしたいのに、論理は冗長というギャップ萌え
中には「ばか」「アホ」「初心者」「論外」とかだけしか言えない人も居るけどね

41 :
>>40
初心者乙

42 :
ヽ(#`Д´)ノ

43 :
>>40
最後の一行を言いたいわけではない

44 :
リンクを貼るときに相対パスで書く場合で同じ階層の場合
<a href="./44.html">

<a href="44.html">
との
2通りがあるのですが、どちらがより仕様書寄りな書き方なのですか?

45 :
どっちも変わらんだろ
ttp://www.faqs.org/rfcs/rfc1808.html

46 :
なんていうかさ、
仕様書読んでから仕様書寄りかどうか悩むようにしようぜって思うわ。

47 :
>>46
その仕様書寄りって曖昧な基準が俺様ルール

48 :
和訳も出てるのに仕様書も読んでないとか
とんだすとりくた(笑)だな

49 :
htmlファイル自体が別の場所にコピーされてもリンクが切れないようにhttpから書くのがよいかと

50 :
>>49
逆に文章全体を移動させる時は相対の方が便利なんだよな。
明らかに別の文章ってわけじゃないなら相対派。

51 :
普通はbase要素使う

52 :
はいはい

53 :
URLを変更するとかstrictスレ的にはどうなのよ

54 :
全く好ましくない

55 :
>>46
寄りってなんだよwww寄りってのはよーwwwwww

56 :
URL絡みの仕様はここの連中の専門外だろ。
役にたったら負けなんだから。

57 :
初心者質問スレ行きですよねー

58 :
ストリクターは数学者につうづるところがある。

59 :
宗教家の間違いだろ

60 :
>>59
わかってないね

61 :
誰もが幼少の頃に一度は通るはしかのようなもの。
XML+XSL あたりを覚えりゃ最終出力の HTML なんてプレゼン要件だけ
満たせりゃどうでも良いゴミみたいなもんだと気付く。

62 :
・公理で示されている範囲だけで演繹する数学
 公理の範囲外の事項を扱う場合は新たに公理を作る
・教典に書いていない事項を解決するために教典の行間を読む宗教
このスレでやってることは後者に近いと思うんだが

63 :
まあ趣味でやってるわけなんだしそうけちつけることもなかろ。
仕事で使う場合でも最終出力のHTMLにブレがなければ
別に深淵な配慮があろうがValidなだけだろうがなんだっていいし。
というより仕事で使う場合はどのブラウザでも同じに見えることに
四苦八苦する時間の方が長くとられそうだけどな。
ということでここはある意味憩いの場なんだよ。

64 :
ここの人たち的にはThe Web KANZAKIの中の人はどういう評価なんだろう
あのサイト見てからだと
このスレってhtmlだけで頑張ってセマンティックを実現しようと
それぞれがばらばらに勝手なことしてるってイメージだなあ
標準化って大事だよね

65 :
>>64
それはおまえの読解力がない

66 :
このスレったっていろんな人いるしな。
雰囲気に酔ってるだけの人もいるし、横の協調性はどうでもいい!な人もいるし、
意地でもHTML内の要素でセマンティックたろうとする人もいるし
HTMLで出来ないことはXMLで、でも出来る限りは・・・な人もいるし。

67 :
XUL最強伝説

68 :
さすがにHTMLだけでなんでもかんでもな夢見がちなロートルは
もう流石にいないっしょ。

69 :
夢なんか見ない。

70 :
市場じゃどっちかといえばUI記述言語としての存在を期待されてるよ

71 :
>>70
XMLだろ

72 :
>>68
ロートルじゃなくて厨二病にありがちな手段と目的の取り違えでしょ。
んで一通り Strict のルールを習得したある日、Strict であること自体にはオナニー以外に
何の意味もない事に気付いて大人の階段を一歩上る。
>>70
UI 記述言語として広めるならタブやスプレッドシート、ツリーなんかの
コントロール系の汎用コンポーネントを増やさないと厳しい。まぁそこらへんは
XML 使ったスタンダードなスキーマと各言語での実装が出れば良い (そんなメドは
ないけど)。

73 :
XForms を忘れないでくだしあ

74 :
ガジェットとかHTMLで記述してるのは多いけど
JSでインターフェース1から組まなきゃいけなかったりでいろいろ面倒臭そう
UI記述言語はXULとかXAMLとかあるけど標準化とかされないのかな
こっちのがHTML5よりもよっぽどweb application 書きやすい気もするけど

75 :
理想と現実は違うのよ

76 :
>>74
標準的なコントロールですらだもんね。
なんかもっと良い再利用の仕組みでもないともったいない。

77 :
というかスレチはそろそろ納めてくだしあ
ここはオナニースレなんだが

78 :
大変若い方々のオナヌーは生暖かく見守り、時に手を添えてやるのが大人の対応というもの。

79 :
手なんか添えるな
わかってねぇな

80 :
>>77
さっさとこけよ

さすがにオナニーが馬鹿らしくなって
人減ったんだろか。
HTML4が出たころは結構盛り上ってたのにな、このスレ。

81 :
人によって解釈変わってくるのに、どうやったらStrictなHTMLが書けるの?

82 :
>>81
後1年このスレにいればわかるようになるよ、ぼうや。

83 :
オレオレ Strict

84 :
<div class="kiji">
<h2>記事見出し</h2>
<img src="img.png" alt="" style="float:left;" />
<p>本文……………………</p>
<br style="clear:left;" />
</div>
今こんな風に書いてしまっています。
imgがインライン要素なので×、フロート解除の為の<br />も良くないんだと
思いますが、なるべく記述量少なくシンプルにかつ不足なく構造を記述する
他のいい書き方ありますでしょうか?

85 :
>>84
<h2>記事見出し</h2>
<p><img /></p>
<p>本文</p>

86 :
>>85みたいなのにする人もいるし
imgだけをpに入れるのは気持ち悪いだかで
<h2>記事見出し</h2>
<ul>
<li><img /></li>
</ul>
<p>本文</p>
とする人もいるし
<h2>記事見出し</h2>
<p><img />本文</p>
とする人もいるし
なんかいろいろいる

87 :
imgがなんなのかによるけど、
挿絵なら私は説明入れて、
<h2>記事見出し</h2>
<dl>
<dt><img /></dt>
<dd>写真の説明</dd>
</dl>
<p>本文</p>
だな。
あと、フロート解除は<h2>要素で。
一番下は何も無ければそのままだし、フッタとかあればそこでも。

88 :
語りたいんだね

89 :
文脈次第なのに、あれもあるこれもあると延々と語るわけだ

90 :
有り得るけどULは唐突だわ

91 :
86:Name_Not_Found :2009/05/08(金) 08:01:20 ID:??? [sage]
>>85みたいなのにする人もいるし
>imgだけをpに入れるのは気持ち悪いだかで
>imgだけをpに入れるのは気持ち悪いだかで
>imgだけをpに入れるのは気持ち悪いだかで
>imgだけをpに入れるのは気持ち悪いだかで
なにそれwww

92 :
ほんとお前らって dl だの ul だの好きだよな。
無理矢理登場させてるようにしか思えない。

93 :
これが絶対だ唯一無二だといったものがないんだから本人が適切だと思った方法を取ればいいんでない

94 :
そもそも>>84がスレ違い

95 :
そろそろdiv厨登場


96 :
HTML5を先取りして
こうだね♪
<div class="figure">
<span class="legend"></span>
<img />
</div>

97 :
>>92
HTMLでは、文章<P>じゃないのだから、リスト<ul><dl>しか妥当なものがないということもあるが、
それを差し引いても、仮に一つの記事に二つ写真を入れたとすると、写真のリストと言える。
だからこの<img>が記事に関する写真や挿絵的な物なら、普通にリストだと思うよ。

98 :
二つならリストってことはない。

99 :
>>98
否定するなら何故かを書け

100 :
>>91
<p><img/></p> は気持ち悪い。
気持ち悪いというか、img要素だけをボンと置かれても意味がわからない。
p要素はその内容が一つの段落をなしてないといけないので、
「この絵だけで一つの段落なのだ」という文学的な効果を狙っている場合以外は変。
小説の挿絵的なイメージならリスト要素が妥当かと。
ただし、img要素が文章の中のその段落に対して重要な物なら、
<p><img/>この写真はなんたらかんたらで‥‥</p>
と、文章内に取り込んでしまう事はかまわないと思う。

101 :
めんどくせ
複数なら即リストとは限らない
わからんの?

102 :
>>100
パラグラフだから良いのだ

103 :
>>101
わからんから、理由を聞いてるのだが。
というか、>>98さん?
だったら、言い回しを変えただけで言ってることほとんど同じだし、
結局、理由が書けてないよ。

104 :
>>97
ふたつのパラグラフかもしれないでしょ?
片方が単数項目のリストでもう片方がパラグラフかもしれない

105 :
パラグラフが並んでても列挙とか言い出しそうだなw
やっぱここの住民は勝手解釈で遊んでるだけにしか見えん。

106 :
>>100
>p要素はその内容が一つの段落をなしてないといけないので、
「この絵だけで一つの段落なのだ」という文学的な効果を狙っている場合以外は変。

div厨がよく言う
>小説の挿絵的なイメージならリスト要素が妥当かと。

尚更変
>ただし、img要素が文章の中のその段落に対して重要な物なら、
><p><img/>この写真はなんたらかんたらで‥‥</p>
>と、文章内に取り込んでしまう事はかまわないと思う。

そこはdlって言わないんだw

107 :
仕様上divに直接imgを入れることは何の問題もないのだから、
普通に<div><img src="hoge.jpg" alt="hoge"></div>で仕様に適合したHTMLになる。
divに直接インライン要素を入れるのは駄目とかいうdivフォビアがよく沸いてくるが、
そんな俺様ストリクタは放っておけばおk。

108 :
>>107
まずStrictスレを理解しような

109 :
そういや普通にpreでマークアップすりゃいいのにdivでマークアップして、
そのdivをCSSでwhite-space:preしてるサイトを見たことがあるよ。
あれはSEOでも狙ってるんか?

110 :
一つでもリストだ
というか画像(写真や図)は表と同じように本文中にあるのではなく脇にあって参照するようなものだと思うんすよね
表は文中に現れないよね(そもそもp要素の中に置くとinvalidなわけだけど)
img要素のalt属性やtitle属性の文字列が文脈として意味があるからp要素の中で問題ないんだ
ってんなら最初からimgである必要はなくその文字列を地の文に書けばいいわけで
divかulかdlかいずれが妥当かは置いておいて
少なくとも写真や図がp要素中にあるのは意味がわからない

111 :
小説における挿絵も、挿絵がないと文脈がわからないってわけじゃないよね
挿絵はあくまで補助的であって
だから挿絵は文中に含めるんじゃなくて脇に置くかCSSあたりで表示するもんだと思う
絵本のように絵そのものが主である場合はまた別だけど、絵本の場合は
「ページ=絵」の配下にパラグラフがあるようなケース(以下のような)
ページ=絵
├段落
├段落
└段落
だからこれまた絵を文中に含めるのは変だ
だからもし絵本をHTMLで表現するなら上記のような構造を保ったマークアップが適切だと思う
たいてい絵本には文字の配置にも意味があるだろうから絵と文を分離させてマークアップというのは
無理があるのかもしれないけど
ただ漫画の1コマを文中に使いたい場合
たとえば<p>まさに「ウホッ!いい男…」って感じでした。</p>
の「ウホッ!いい男…」の部分に例の漫画の1コマを使うような場合は
p要素中にimg要素があっても不適切ではないと思う
(引用だからimg要素をq要素で囲めとかそういうのは本題ではないので割愛)
そんなわけで
ケースバイケースではあると思うけどp要素中にimg要素というのはかなり限られた場合なんじゃないか

112 :
あいかわらずキモい論理展開ですね

113 :
初めてかここは?力抜けよ

114 :
何一つ自己の論を展開できない人はただただ他者の論をキモイとだけ言う
<p>今日は<img src="smiley-**.png" alt="あえて言葉で表現するなら“しあわせ”" />な気分でした♪</p>
といったスイーツの日記サイトのような使い方がほとんどだって人にとっては
img要素をp要素に入れるほうが普通なのかもしれない

115 :
ここの精神を知らない連中が増えてきたなぁ・・・
strict は人生みたいなもんなんだよ。
一朝一夕で悟れるもんじゃない。

116 :
>>110
>というか画像(写真や図)は表と同じように本文中にあるのではなく脇にあって参照するようなものだと思うんすよね
しらんがな

117 :
>>109
たぶんケータイ向け

118 :
>>116
どうしてそう言うレスになるのか意味がわからねぇ
かみ合ってないのか、考える力がないのか。
もし、どうでもいいと思ってるのなら何故ここにいるのか。

119 :
言い返せないけど何か言い返したいんだよ

120 :
リストは脇にあって参照する構造だそうですw

121 :
脇にあって参照するものにP要素は使えなくなりましたWWW

122 :
画像がパラグラフ中に発生することって>>114以外に思いつかない

123 :
ストリクタは基地外だけど、>>110はただの低脳

124 :
>>114の状況がまったく想像つかないwww

125 :
124は童貞だな。
メールの受信フォルダとか見なくてもわかる。

126 :
受信フォルダwww

127 :
ストリクタは本当に俺俺ルールが好きだよね。

128 :
初心者が全否定されて涙目で逃走という日常のひとコマでした

129 :
ストリクトとは何なのかと勉強してから出直してきな、坊や

130 :
満点取って舞い上がったんだろう

131 :
lint 100点とかスタート地点ですらないからな。

132 :
スタート地点は国語マスター

133 :
>>84です、色々レスありがとうございました。
記事内の画像のフロートとその解除をするのに一番簡潔なソースで
かつ構造もちゃんと記述するのにどうしたもんかと考えてましたが
色々参考になりました。

134 :
列に曜日(日、月、…)、行に週(第一週、第二週、…)、セルに日付け
のカレンダーはよくありますが
セルにメモ(燃えないゴミの日、給料日、定休日、誕生日、等々)を併記したい場合は
どうするのが妥当ですか?
週の行をさらに日付けの行とメモの行に分けるのが普通?

135 :
ああ、なんかクラクラしてきた

136 :
>>134
妥当の範囲でいいなら初心者スレへ

137 :
>>134
適切なscope属性、headers属性、axis属性を付加してやれば
それでいいんでない
テーブルとアクセシビリティ -- ごく簡単なHTMLの説明
http://www.kanzaki.com/docs/html/tbl-access.html
ただ行側の見出し(th要素)を省略してしまうと意味が伝わらないから見出しは必要

138 :
三次元テーブルは混乱してくるのでつい避けてしまう

139 :
「日付け」セルはデータセルじゃなくてヘッダセルになるんじゃないか?

140 :
どうもですm(_ _)m
今まで単純な表しか作ってなかったのでscope属性とかは使ったことがなかったです
テーブルはややこしいですね

141 :
月ごとにテーブルを分けているのなら一つのテーブルに盛り込むんだ
ますますややこしくなるけど機械からはデータの参照がしやすくなる・・・はず

142 :
テーブルはあきらかに機械処理を意識した作りになってるよな。

143 :
idとかclass名の命名は
1. 形容詞(英語)+名詞(英語) :普通の英語
2. 名詞(英語)+形容詞(英語) :後置修飾的英語
3. 日本語ローマ字フル表記
4. 形容詞(英語)+名詞(日本語ローマ字表記)
のどれを使えばいいの?

144 :
自由だああああぁぁぁあぁあっっ!!!!!!!

145 :
英語と日本語ローマ字表記の組み合わせは気持ち悪い

146 :
サイト内で統一されてればなんだっていいのでは。
個人的にはローマ字はきもいから嫌だけど。
草の根だけど命名規則をある程度揃えようって話はちょくちょく出るよね。

147 :
strictスレで「なんだっていい」w

148 :
ランダム文字列でいいだろ

149 :
その発想はなかった

150 :
なにいってんだ
unique identifierの一番単純な解だろ

151 :
>>146
というかそういうのを揃えようって人達はそもそもストリクタじゃないから
不必要なIDやCLASSが多すぎるんだけどな

152 :
不必要なIDやCLASSって具体的にどんなのよ

153 :
不必要?
なに言ってんだこいつは

154 :
eRDF使えば自ずとclass属性値なんざ決まるだろうが。

と、買ったばかりの神崎先生新刊本を読みながら偉そうにカキコ。

155 :
先月出てたのか
さっそくamazonでポチってきた

156 :
strictor的にはidもclassも全部いらんが正解

157 :
ぼうや、ストリクタを騙って軽々しく正解なんて言葉を口にするんじゃないよ

158 :
id属性class属性はむしろ全要素に付けたい勢いなんだけど

159 :
>>158
煽り抜きでここ向いてないんじゃね
全IDを付けていいのはhnだけ

160 :
>>159
うん。確かに君は向いてない。

161 :
ここは俺々ストリクターの集うスレだからな。

162 :
>>160-161
とりあえず文体くらい変えたら?

163 :
「何でもいい」も駄目、「俺ストリクト」も駄目
どうしろと

164 :
どうしようもない

165 :
StrictなHTMLは理想郷。
現実には存在しない。

166 :
ここの事情も考慮せず「全部これが正しい」なんて言うから偽ストリクタ認定される
正確な物言いを心がけよう

167 :
>>166
お前が正しくないことだけは正しい

168 :
ほんとストリクトのなんたるかもわからんような
雑魚ばっかりになっちゃったな、このスレも・・・

169 :
そう自虐的になるなよ

170 :
お前は今までよく頑張ったよ
もう休んでいいんだよ

171 :
俺たちに休みはない

172 :
自宅警備で忙しい

173 :
あのさ、strictなことと原理主義なことって別だよな。
ここって一緒くたにされてるよな。
スレタイに【原理主義専用】とか入れろよ。
でないと純粋にstrictを語れなくなるぜ。

174 :
多分strictと原理主義の違いがどこにあるかで
お前と他人は違うから揉めるだろうな

175 :
strict:
仕様書にも誤りはある
無論、誤っている部分は正してゆくべき
原理主義:
仕様書に誤りなどない
誤りのように見えてもそれは常に正しい

176 :
何という俺定義
ストリクトは仕様書に則って語られるべき

177 :
strict:
>>175にも誤りはある
無論、誤っている部分は正してゆくべき
原理主義:
>>175に誤りなどない
誤りのように見えてもそれは常に正しい

178 :
>>175様が間違えるなんてことあるはずないです!><

179 :
とりあえず、class名に関しては、他のマークアップ言語の要素名から拝借できるものは
拝借するというのはどうだろう。
XULリファレンス
https://developer.mozilla.org/ja/XUL_Reference
DocBook
http://www.docbook.org/tdg/en/html/docbook.html
例えばWebアプリでおなじみの、画面最下部に設置された「登録」ボタンなんかも
DocBookのguibutton要素を借りて
<div class="guiButton">
  <input type="button" value="登録">
  <input type="button" value="戻る">
</div>
としてみるとか。
でも、ありきたりな名称ばかりだから、ブログとか日記の本文の一部で特別な意味を付与するというよりも
登録画面みたいなWebアプリでdiv厨並にdivに付与しまくるという、タグの追加みたいな
使い方になってしましそうだが。

180 :
>>179
なんかそれ以前なんスけろ

181 :
仕様書に誤りあるから正していこうとか・・・
なんかやっぱここは俺々ストリクターの集るスレなんだな。

182 :
>>179
とりあえず安易にclassを使いたがる奴は消えていい
特にヘッダフッタメインコンテンツあたり

183 :
>>182
>特にヘッダフッタメインコンテンツあたり
なにを言ってるんだ・・・

184 :
classとかidって出来るだけあらかじめつけておくのが基本じゃないのは何故?
記号的に取り扱われるけど、
その要素でマークアップされた文章の意味の属性みたいな感じでわかるから、
機械的な処理に反映させやすいって意味では必要だと思うんだけど。
パラグラフだってその文書で何に属するパラグラフかという意味で色々あるしな。

185 :
このスレ的には>>182が消えるべきじゃね?
たまに居るよね、class/idまったく付けないことこそがstrictだって
勘違いしちゃう人。

186 :
>>185
お前は正体割れてるんだからいいかげんにしとけ

187 :
俺々ストリクターで何が悪いのかと

188 :
>>184
機械的に処理できる意味づけならマークアップの時点でできている
idやclassは個人によって変わるから機械的処理の反対に位置している
わかりやすい例として、divにidやclassで意味づけをできないという議論は
過去に何度も繰り返されてきたので、過去ログでも読んできてくれ

189 :
ぶっちゃけ過去ログ見てた方がもう勉強になるよな・・・
というかWeb制作板そのものが衰退期に入ってる
まあしょうがないとは思うけど

190 :
>>188
つ GRDDL

191 :
ggrks

192 :
>>188
microformats

193 :
機械処理できるかどうかという話なら、
意味付けというのは結局合意の問題だからね。
オレオレidやclassでも、例えば何かしらの外部仕様として定義されて
大勢に支持されれば、機械処理というレベルでは実用的になる。
それで今は、microformatsにせよRDFaにせよ、
HTMLの基本的な枠組みと、外部語彙(Dublin Coreとか)を組み合わせて、
「実用的な機械処理のための」細やかな表現力を実現しようとしているところ
なんじゃないのか。どの程度現実的かはさておき。
まあこのスレはHTMLに閉じた世界の話をするところだから
それはそれってことだが、そりゃ話題も尽きるしループするわな。

194 :
神崎先生の新刊にあやかってセマンティックHTMLスレとかにすればその辺の議論もできそうなんだがなw

195 :
>>188
半端なものとしてしか出来てないと思うけどねぇ。
idはまだしも、個人によってclass名が変わったとしても、
そのclassのグルーピングは意味を持たないと仮定しても機械的にわかるものだから。
そのグルーピングが何の意味を持つかを読み取れるかどうかはまた別問題としてね。
divなんかじゃ飛び飛びで出てくるものに分類なんかできないし、
その情報があるのと無いのでは大きく違う。
classが機械的に処理できる意味づけを持たないのであるなら、
それはツリー状での階層化しか表現出来ないhtmlの限界ともいえると思う。

196 :
はいはい。えらいえらい。移動してね。

197 :
>>194
その手の話題を扱うスレは別にある
そして過疎っている
このスレは答えのないものに対してそれぞれが持論を展開して
結局万人が納得するような答えは出ないけどその話し合いの中でそれぞれが
当初の自分の考えをより強固なものにしたり他人の考えを採用したりして
個々人の中で自分なりの答えが見つかる
それでいいんすよ

198 :
>>197
なるほど。
そうだよね。規格で決ってる部分以上は
結局個人の裁量にまかされてるわけだしな。
過疎ってるのは答え出したりそれどころじゃなくなったりした人が増えたからだろう。
持論展開するんだとしてもブログでやったほうがもうちょっと有意義な感じがするし。

199 :
>>195
そもそも機械は意味がわからないということを忘れているお前に未来はない。
お前の日本語が他人には理解できないものだということも忘れている(ry

200 :
妄想

不可能

「htmlの限界」
何様かと
ゆとり様である

201 :
若い子ほどルールを守らない俺様カコイイをやりたがるからな

202 :
俺、九才だけどそんなことないよ。

203 :
>>202
いいから正体割れてるお前は消えろ

204 :
基地外が沸いてるな

205 :
>>203
お父さん?
今どこにいるの?

206 :
×基地外が沸いてるな
◯基地外しかいないな

207 :
>>204
沸くじゃなくて湧くな

208 :
いつかの涙目初心者だろう

209 :
いや、勝手に脳内確定して得意な様を「沸いてる」としてみたのだが

210 :
>>209
そうだね、お前は正しいよ

211 :
>>209
ああそれならわかる
>>173>>193>>195のあたり

212 :
ロマンチックが止まらないようです

213 :
ていうかそれ全部一人の馬鹿だろ

214 :
>>195
あとはそのclassのグルーピングのやり方を共有できれば、
有意な分類ができると思うのになかなか広まらないよね。
HTMLの問題というよりは制作環境の問題な気がするんだが。

215 :
ロマンチックが....

216 :
止まれ

217 :
そういうのはclass/idでやるより
おとなしく名前空間を分けたやつを導入すりゃいいんじゃないかと。
せっかくXMLなんだし。

218 :
>>214
共通化一般化されたマークアップがあるんだから
それ以上ほしいという我が儘同志がぶつかって共有があるはずないだろ

219 :
w3cとかそれなりに権威があるところが主導すりゃ広まるんだろうけど、
やんないってことはあんまり必要とされてないってことなんじゃね

220 :
>>217
それはスキーマのおかげで頓挫してるんだよ。
NVDLなんて一般人が使うもんじゃないし。

221 :
W3Cは巨大化しすぎて身動き取れないんじゃ
といって他に有力なところがあるのかは知らないが…

222 :
多くの人が欲しがっているものは
HTML5で取り入れられているんじゃないの?

223 :
HTML5はカス
W3Cは方向性を間違った

224 :
カスとまでは言わないが
まあ迷走してる過渡期の代物だとは思う…

225 :
>>223
HTML5 は元々 WHATWG が初出だから、W3C は関係ないだろ
まあ W3C も HTML5 を取り込んだが……
ある意味 XHTML2 涙目

226 :
HTML5よりはXHTML2の方がマシだから
涙目も何もないな、方向性も違うし

227 :
HTML5のどの変が気に入らないのよ?

228 :
s/どの変/どの辺/

229 :
>>227が気に入っている所が気に入らないよ

230 :
気に入る気に入らないの話だと思ってる時点でもうダメポ

231 :
俺は別に気に入ってるわけでもないし。

232 :
>>229が気に入っていないから、HTML5は普及するだろうね

233 :
ないわ

234 :
ないね

235 :
あるね

236 :
ないよ

237 :
あるわ

238 :
ないあるよ

239 :
というかMSが実装 = 普及

240 :
canvasとかは普及しないな

241 :
MSはWHAT WGは加入拒否したんだよね。
HTML5がW3Cに移管されてからは参加しているようだけども、
果たして大所帯のW3Cで仕様は完成するのやら。
そういやXHTML 2.0も本当に勧告になるんだろうか。
ロードマップで2010年3月ってなってるけど、1stドラフトからはや7年…。

242 :
きっと10年越しの勧告

243 :
http://www.computerworld.jp/topics/browser/154169.html
MAJIDEKA

244 :
>>241
鋭かったね

245 :
まじか・・・ちょっと萎えてきた

246 :
>>241
やこぶさん?

247 :
うおお、なんか切ない……

248 :
完全にMSのせいだよな。
application/xhtml+xmlに対応しないからさ。

249 :
またリッチでファットになってゆくのでしょうか

250 :
今後の展開の予測
HTML5をW3CだけでなくWHATWGでも並行策定(牛歩なW3Cへの牽制)

W3Cで取りまとめ失敗してWHATWGのみで勧告の勇み足

MicrosoftはWHATWGに参加していないのでIEでサポートせず

        *'``・* 。
        |     `*。
       ,。∩      *    
      + (´・ω・`) *。+゚
      `*。 ヽ、  つ *゚*
       `・+。*・' ゚⊃ +゚
       ☆   ∪~ 。*゚
        `・+。*・ ゚

251 :
IEはいまだにXHTMLサポートしてないじゃん。
勧告なんて関係ね―べ。

252 :
そういえばFirefox開発版にHTML5パーサが入った

253 :
>>252
html5.enable オプションか

254 :
HTML5は実装ありきで進むらしいからな。

255 :
そうなのか・・・
まあ今迄も魅力的だけど誰も実装してないから書くだけ無駄な仕様沢山あったもんな。

256 :
IE全盛期もIEに実装されていた機能がそれだけすばらしかったってことだっただろうし。

257 :
それはないない
ていうかお前何でここにいるんだって感じだな

258 :
いや、普通に皮肉書いただけに見えるが・・・

259 :
HTML5ではプレーンテキストの文章をマークアップして意味・役割を伝えるというよりも、
ブログのようなWebアプリケーションの構造を指示することが目的になるんでしょ。
表示さえ上手くいけばよくて、もう「Strict」かどうかなんて関係なくね?

260 :
>>259
元々HTML5は、WHATWGで議論してたときは
Web Applicationsっていう名前だったもんね。
「表示さえ上手くいけば」っていうのが、「Strict」なHTMLなんじゃない?
表示が上手くいってなかったら、そのコーディングがStrictによるものだったらブラウザ側の使用の問題だし。
HTML5ってStrictとか聞かないけど、XHTML1.1みたいに元々Strict的な姿勢があるのかな?

261 :
「表示さえ上手くいけば」ってのはこのスレ的にはvalidまでを指すと思うんだが。
とりあえずスレを頭からもういっかい読んでみるといいよ。c

262 :
>>259
まぁTransitional(ってHTML5にあったっけ?)でも何でもいいが、
validじゃなければ正しいHTMLではないよ。
(って「catじゃなければ猫じゃない」くらいに馬鹿馬鹿しい当たり前さだけど)
正しくないHTML書いて表示がされるのはブラウザのエラー処理に依存しているってことだ。
それはつまり、将来のバージョンのブラウザではちゃんと表示が保証されないってこと。

263 :
>>261
>>260が言っているのは、>>259を受けて「表示さえ上手くいけば」がHTML5の目的だとするならば
それに厳格に従った(strictな)HTML5文書とは、「表示が上手くいく」文書であるという意味かと。
つまり今までのHTMLとはstrictの示すものが違うという話。
>>262
>>259の言う「表示さえ上手くいけば」は、仕様に反してもいいって話ではない。
HTML5では論理的構造じゃなくてWebアプリの構造を示すものなんだから
従来のHTML的strict=論理的であるかなんて関係ないよねと言っている。

264 :
>まぁTransitional(ってHTML5にあったっけ?)でも何でもいいが
この時点で何でスレにいるの?って感じだな
仕様としてstrictであることと思想としてstrictであることは違う

265 :
個人的には
思想としてのstrict ⊇ 仕様としての strict
って思ってたんだけど >>264 の言う思想としてのstrictって何?
基本的に仕様書原理主義じゃないの?ストリクタって

266 :
仕様書以上のことで勝手議論してるだけだよ。

267 :
>>265
過去ログ読んでこい。
何百度目の質問だ。

268 :
ある意味このスレの役目は終った気がするね

269 :
そうだね
バイバイ

270 :
>>268
言われなくても書き込み量が物語ってる。

271 :
http://googlejapan.blogspot.com/2009/07/html5.html
なんだかな

272 :
>>271
どしたの?

273 :
読みゃわかるだろw

274 :
素でわからんのだが

275 :
マジレスすると少し前のログから読んでこい

276 :
q要素で画像を引用(img要素を使う)してもいいと思いますか?

277 :
著作権の問題がクリアされているのなら

278 :
引用と言ってるんだから著作権の問題はクリアしてるんだろ

279 :
クリアされてない転載を引用という厨も多いからな

280 :
質問者はマークアップ如何じゃなくて画像を引用することの是非を聞いてるってこと?
それもこのスレの範疇?

281 :
マークアップは今更問うべきところか?
ネタだろ

282 :
>>280
そんな質問ならスレどころか板違い
法律相談板に池

283 :
<・> <・> だからネタだろ?

284 :
>>279
そりゃつまり引用じゃないんだろ。
引用の場合が前提の話で、引用でないものを引用だと言い張る人の話をしてどうする。
お前頭おかしいんじゃないのか?

285 :
>>284
つまりお前が引用じゃないものを引用と言い張ってるわけだな?

286 :

 ┌─────────┐
 │               .|
 │  キチガイ警報!  │
 │               .|
 └―――──――――┘
      ヽ(´ー`)ノ
         (  へ)
          く

287 :
マークアップの話にだけ終始すればいい

288 :
>>285
なにカオスなこと言ってんだw

289 :
>>284
頭おかしいと煽る奴って頭おかしいんじゃないの?

290 :
結局>>276は釣りかネタか

291 :
このスレ自体頭おかしいののすくつですから

292 :
>>289
お前は小学生かw

293 :
>>292=>>284だとしたら小学生は・・・

294 :
なんかネタをネタと見抜けない奴が増えてるな
>>286とか>>292とか
そもそも質問自体がネタだとしたら俺も見抜けてないがw

295 :
ネタスレじゃねぇんだから

296 :
むしろ全部ネタでいいと思う
ネタにマジになるから硬派Strictorは楽しい

297 :
熱くなるのはいいけどスレ違いな話題は適切なスレに誘導
さてこのスレに沿った話題をどうぞ↓

298 :
>>296
VIPでも池

299 :
Strictって全部ネタみたいなもんだろJK

300 :
そう思うなら何故このスレにわざわざ来る?

301 :
きっと頭がおかしいんだよ

302 :
実用的じゃないけど趣味でどこまでも拘りたいってとこだろ
というか前々からよく言われてる意見だと思うが

303 :
実用的でない?
そりゃ使えない馬鹿が多いだけだろが

304 :
>>301
本当に小学生だな

305 :
>>303
仕様書的Stricterと思想的Stricterは違うってことを理解してからおいで

306 :
俺俺思想は標準でもなんでもないぞ

307 :
標準と言っているのがお前一人な件

308 :
は?頭おかしいんじゃないのか?

309 :
> 俺俺思想は標準でもなんでもないぞ
ってつまりvalidであればそれ以上は考えるなということか
なんたるスレの全否定
なぜここにいる
ここは仕様をこえた領域についての自論をぶつけ合う場!
思考停止したものはこのスレに不要!
・・・みたいなことが暫定まとめサイトに書いてありました
> 単にvalidであるにとどまらない、よりstrictなマークアップとは何かといった議論が行われています。

310 :
>>309
なんという言いがかり
より正しさを求めるのは大事なことだぞ

311 :
>>310
こいつずっと「頭おかしい」と言ってる小学生だろwww
スレを荒らしたいだけだったんだな

312 :
涙拭けよ

313 :
出たよ被害妄想

314 :
Strictスレらしい流れでほっとした

315 :
物理的にも論理的にも正しいマークアップをしてそれをCSSでちゃんとクライアント要求のデザインに揃えてこそだろ。
実用にならんなどと言うのはそれこそ趣味レベルのアマチュア。
実用のために妥協入れなきゃ作れないのは作業員であって職人ではない。

316 :
そんなサイト見たことがないな
サンプルくれよ
10コぐらいでいいから

317 :
>>315
うるさいよ小学生
正しいマークアップなんて前提でしかないというスレでお前は存在からしてスレ違い

318 :
またお前か。

319 :
>>317
は?何言ってんの?
そもそも前提なんなら当然実用にもなるだろ。

320 :
>>318-319
またお前かなのはお前
いいから宿題に戻れ

321 :
構ってる人もそろそろ自重

322 :
なんなんだよもう

323 :
論理的に正しいのはいいんだけど
strictorの論理観がバラバラなのが問題

324 :
論理観・・・・・・・・・・・・・・・・・・・・・・・

325 :
なあ、原文が箇条書きなのに番号が付いてる場合ってどうマークアップしてる?
-------------------
(1) ほげほげ
(2) ふがふが
(3) ぴよぴよ
(4) (3)以外の場合、ぬるぽ
-------------------
UL にして番号つけるのかな?
OL にして 「(3) 以外うんぬん」 って書くのはアレだし…、
DL にするほど数字に意味がある (憲法条文の第○項とか) とまでは思えないし…うーん

326 :
pre「いいのよ」

327 :
>>325
自分的には、規約とかちょっとおカタい文書の時はp。でなければol。

328 :
DLでいいんじゃね?
ついでにidつけておけ

329 :
うーん、統一見解なんてないとは思っていたけど、結構分かれるものなのねー

330 :
俺ならolかpreだな

331 :
若いうちのOLはいいんだけど
逝き遅れると産業廃棄物だからなあ

332 :
<ol>
<li id="no1">ほげほげ</li>
<li id="no2">ふがふが</li>
<li id="no3">ぴよぴよ</li>
<li id="no4"><a href="#no3">3</a>以外の場合、ぬるぽ</li>
</ol>
できたよー\(^o^)/

333 :
>>332
3ってなんだよ

334 :
>>333
知りたければクリックするんだ!

335 :
OLの場合、「上から3番目」 とか 「3項目目」 とかならわかるけど、
通常表示される「3」の部分はCSS等で書き換え可能だから、
「3」 だけだとソース内に記載されてない分、3ってどこ指してるのよ? ってなっちゃうんだよな。
それを許すのか許さないのかがなんとも
>>331
女性は産む機会ですか><

336 :
<a href="#no3" title="このリストの三番目">3</a>
これで解決だな

337 :
俺なら数字も入れる
<ol style="list-style-type:none">
<li id="no1">(1) ほげほげ</li>
<li id="no2">(2) ふがふが</li>
<li id="no3">(3) ぴよぴよ</li>
<li id="no4">(4) <a href="#no3">(3)</a>以外の場合、ぬるぽ</li>
</ol>

338 :
>>336
<a href="#no3"><abbr title="このリストの3番目">3</abbr></a>
こうじゃね?

339 :
ほぼこの方向で答えは固まったね
めでたしめでたし

340 :
産業廃棄物の処分方法がまだ確定していない

341 :
そもそも順番にたいした意味がなくてもOL使っていいのかという
1. 起床
2. 洗顔
3. 歯磨き
4. 朝ごはん
5. 新聞を読む
6. 身支度
日によっては2〜5は順不同になったりするから、厳格にするならOLなんか使えない!・・・とかなんとか

342 :
お題が違えば答えも違う

343 :
普通は飯食った後に歯磨きだろ。
先に歯を磨くと歯磨き粉の味とご飯の味が混ざって不味くならないか?

344 :
うんこが抜けてる!
通勤中にもよおしたら大変だ

345 :
>>343
そういう問題じゃねーだろwww
>>344
そいつは大問題だ。

346 :
俺は起床の前に朝ごはんと新聞を読む

347 :
朝ごはんは読まないだろ

348 :
おきぬけの口内はうんこ一口分の雑菌が繁殖してるから
歯磨きしてから御飯食べた方が良いって偉い人がいってた

349 :
歯磨きは歯垢の除去と歯茎のマッサージが目的
口内の殺菌が目的ならうがい薬などを使うべし

350 :
箇条書きであること=数字がついてること、じゃないんだが。
別にolでいいと思う、アレの意味がわからん、
というか数字に意味があるならむしろolだろ、
数字に意味がないと思うのならulにして数字は自分で付けろ。
dlはこの場合全く関係ない

351 :
数字に意味がある=順番に意味がある
なのか
数字に意味がある=数字も地の文
なのか
olは上のケースの時だけじゃん?
地の文の内容がCSSで変更出来たり
UA次第で内容変ったりするのはおかしい

352 :
社内文書とか報告書とかレポートとかだと、
明らかに順番に意味のない箇条書きリストなのにも関わらず、番号振ってることが多いでしょう。
これは誰かに説明するときに 「3ページのA欄の2についてですけど……」 と説明しやすかったり、
項目がいくつあるか分かりやすくする意図や意味があったりするんだが、
その場合、順番に意味はなくても数字に多少の意味があることになる……かもしれない。
この場合、数字にもともと意味がないからって数字もとっちゃって単にULにするか、
数字に意味はないけど何かの意図があるからとOLにするか、
順不同だからULだけど、作者が数字振ってるからLIの中に直接数字入れちゃうか、
……頭良さげに書こうとしたけどもうだめぽぉ

353 :
なんか>>10-あたりの話とごっちゃになる

354 :
とくに>>27以降かな

355 :
どうでもいいけど>>10
>「dl/dt/dd」の部分の情報源はわかりますか
っていうのは、元の文だと「dt→dd」の順番に意味があるって意味じゃないか
dt同士の順番も、まあhtmlは上から下の流れが重要だから順番に意味はできるけど
ulだって順不同リストとは言っても言語の性質上
上の文章がないと成り立たない順番ってものが存在する場合は多々あるし
>>352も前述の〜〜と後述のliの中で出てくるなら順番が必須になるしな

356 :
>>355
> っていうのは、元の文だと「dt→dd」の順番に意味があるって意味じゃないか
>>10の最後のリンク先にもあるけどDTDじゃdt、ddの順に出現するなんて決められていない
というか>>10以降を見ればだいたい話がまとまっているのでまた掘り返す必要もなさそうな

357 :
すいません初心者なんですが、質問です
ある事象の、それぞれ異なる性質・側面に記述したパラグラフA, B, Cがあったとします
普通は、
<h1>タイトルA</h1>
<p>本文A</p>
<h1>タイトルB</h1>
<p>本文B</p>
<h1>タイトルC</h1>
<p>本文C</p>
(見出しレベルは適当に調整)
ってやると思うんですが(違ったらすみません)、これを、
<ul>
<li><h1>タイトルA</h1>
<p>本文A</p>
</li>
<li><h1>タイトルB</h1>
<p>本文B</p>
</li>
<li><h1>タイトルC</h1>
<p>本文C</p>
</li>
</ul>
とするのとではどちらが良いんでしょうか?
具体的に想定しているのは、ブログのサイドバーみたいなのです。
管理者プロフィール、最新記事、最新コメントetcありますが、上記例後者のように、サイドバー全体を一つのulにするのはありなんでしょうか。
また、それ以外の一般の場合に関しても、どう使い分ければいいのか知りたいです
それこそ普通の文章でも、段落毎にliにしてolなりにつっこむのはありなんですか?

358 :
上のほうがいいと思うけど。
リストにするのは、冗長になるだけじゃないかと思うけど、
サイドバーのアイテムリストという意味ならいいんじゃない?

359 :
ありがとうございます
書いてから気付いたんですが、サイドバーで前者を使う場合は結局全体をdivで囲む事になるんで、
それだったら後者の方がいいのかなあと思いました
普通の文書だと、確かに前者で意味付けはしっかり伝わるので後者は無駄に冗長っぽいですね

360 :
エサがデカ過ぎだろ

361 :
昔はこの手のにたくさん食いついてたのにね。
人減ったよね、この板自体。

362 :
別にネタのつもりで書いたわけではないんですが……
リストとして扱うべきものとそれ以外の違いが気になったもので。
ついでに、ブログのマークアップの例として、下記のものはokでしょうか
bodyの内容として
<h1>太郎の日記</h1>
<ul id="sidebar">
<li><h2>プロフィール</h2>
<dl>
<dt>太郎</dt>
<dd>大学生です。</dd>
</dl></li>
<li><h2>最新記事</h2>
<ul>
<li><a href="0923.html">9月23日 テスト</a></li>
<li><a href="0923.html">9月22日 びろ〜ん</a></li>
</ul></li>
</ul>
<ul id="main">
<li><h2>9月23日 テスト</h2>
<p>学校でテストがあった。</p>
</li>
<li><h2>9月22日 びろ〜ん</h2>
<p>暇な一日だった。</p>
</li>
</ul>
初心者なんで、もしかしたら頓珍漢なことしてるかもしれませんが……

363 :
hnをリストに入れる必要性はない
入れても間違いではないが、このスレ向きではない

364 :
>363
またオマエか。
もう出てくんな。

365 :
出たよ認定厨
そういう煽りがしたけりゃ他へ行けよ

366 :
>>364
むしろまたお前か

367 :
別に煽りたいわけじゃないが。
根拠のない断定は、押し付け以外の何物でもないんでな。
このスレ向きじゃない訳を聞かせて欲しいものだが。

368 :
>根拠のない断定

>またオマエか
頭悪いな=断定

369 :
確かにwww

370 :
揚げ足取りはどうでもいいから、早くこのスレ向きじゃない理由を答えろよ。
このスレは何を話せばいいんだ?
こういう時に使って申し訳ないが、>>357>>362はStrictな話題じゃないのか?

371 :
このスレ向きの話題ってのは>>363以降の流れを言う。

372 :
>>363
とするとどのようにすればいいんでしょうか
やっぱりリストにすること自体に問題ありますかね

373 :
>>372
サイドバー的なものならリストで良いと思う
hnが絡むからおかしな議論になるわけで、、、

374 :
ストリクタにとってのサイドバー的なものってなんぞや?

375 :
サイドバー自体がストリクトじゃない

376 :
サイドバーって言ったって、結局はナビゲーションを横に持ってきたというだけだから、
サイドバーだろうとヘッダーだろうと論理構造上違いはない

377 :
サイドバーがストリクトじゃないって考え方がストリクトじゃないだろ
だってサイドバーって視覚上の区分であってそんなのはマークアップでなくCSSで制御する事
だからサイドバーであるからといってストリクトであるかないかは無関係。

378 :
"サイド"ってなんだよ
上とか下にあっちゃだめなのかよ

379 :
>>327
うん、リストは必要ない
hnで構造化された時点で、意味合いとしてはリスト構造のように階層化されるから

380 :
サイドバーって言葉がストリクトじゃないってことだろな。

381 :
サイドバー「的」だろ
「的」
簡単なナビってことだ

382 :
>>378
じゃサイドじゃだめなのかよと。
そういう視覚上の問題はそもそもマークアップと無関係だから。

383 :
ありがとうございます
じゃあリスト使うかhn使うかの二択ってことですよね
本文の方はhnで良いとして、
そもそもサイドバーというナビゲーション要素にhnを使うことは問題ありますかね
hnから目次を作るような場合を考えれば、ナビゲーションは含めるべきではないですし
ということはやっぱりサイドバーにはhn使わずにul使った方がいいんでしょうか

384 :
>>379
もしくはhnなしのリストのみかだな
確かh1のみで残り全部dlでhnの代わりっていうdl厨サイトがあったなw

385 :
>>383
書いてたら
階層にもよるけど、自分だったら
h1 ページタイトル
 h2 ナビゲーション(タイトル)
  ul ナビゲーション本体
 h2 本文サブタイトル

map
 div(仕様上必要なだけ)
  ul ナビゲーション本体
h1 ページタイトル
 h2 本文サブタイトル
か、だな

386 :
それはナビゲーションがページに対するナビなのか、サイトに対するナビなのかで変わるな
上がページナビ、下がサイトナビ

387 :
HTML5使え

388 :
ナビが前方ってのは無い

389 :
こういうくだらない議論に終止符を打つのがXHTMLだと信じてた時期が
僕にもありました

390 :
>>388
前方ではなくh1以降だとどこに属することになるのか
って討論はもう過去ログ見てきてください
前方ってのがある程度のFAだったんです

391 :
ある程度のFAってなんだよw

392 :
前方ってのがある程度のFAだったんです キリッ

393 :
HTML5とはなんだったのか

394 :
何故過去形。
これから実装が増えてくと思われるが。

395 :
第一章「もくじ」

396 :
>>395
序章でいい。

397 :
はとむるクインテッド

398 :
以下のような文書があったとして、
○○の特徴には以下の3つがあります。
1.うんたら
2.かんたら
3.ぽんたら
それぞれが他にはないユニークなうんたらかんたら。
ここでそれぞれを詳しく見てみましょう。
1.うんたら
うんたらはうんたらうんたらです
2.かんたら
かんたらはかんたらかんたらです
3.ぽんたら
ぽんたらはぽんたらぽんたらです

この文書で、上のリストの各項目と下のリストが実質的に同一であることを明示したい場合、どうすればいいんでしょうか。
それぞれの対応する項目をaで結ぶ? その場合、どっち方向のリンクが適切ですか

399 :
それ明示する必要があるの?
明示して喜ぶのは誰?(書き手?読者?表示用UA?自動処理UA?)

400 :
ページ内に含まれるデータ構造として、実質的にはただ一つのリストが含まれるだけなのに、
そのままでは二つのリスト状データが含まれているように判断されてしまうじゃないですか
データ構造的に微妙ではないでしょうか

401 :
>そのままでは二つのリスト状データが含まれているように判断されてしまう
だから誰がそう判断するの?
ブラウザが同じリストだと判断しないと何かまずいの?
それとも読んでる人が上のリストと下のリストが別だと勘違いすることを危ぶんでるの?

402 :
具体的に書いてくれないとうんたらとかぽんたらだけで説明されても無理がある
ほぼ同じ内容の補足説明ならtitle属性値にすればいいんでないの

403 :
> ○○の特徴には以下の3つがあります。
> 1.うんたら
> ここでそれぞれを詳しく見てみましょう。
> 1.うんたら
> うんたらは〜
と同じフレーズをこんなにしつこく使うのはSEO対策だとかデザイン優先とかかね?だとしたら

404 :
abstract要素欲しいなあ

405 :
俺はたぶんよくあるオナニーだと思った。

406 :
閲覧者的に、下の説明文が長い場合はページ内リンクが欲しいかもしれんぞ。
そしたら上はolで下はhn。olからhnにページ内リンク。
つうかそれってマークアップよりUIの問題じゃね?

407 :
>>398
idやAでアンカー張ればどう?
<p>○○の特徴には以下の3つがあります。 </p>
<ul>
<li id="index-untara"><a href="#untara">1.うんたら</a></li>
(略)
<p>ここでそれぞれを詳しく見てみましょう。 </p>
<dt>
<dt id="untara">1.うんたら</dt>
<dd>うんたらはうんたらうんたらです</dd>
(略)
リスト要素とかは適当。

408 :
うんたらうんたら何度もしつこく言って何が悪い!シンゴー!シンゴー!

409 :
TeXのrefみたいなものがあればいいんだな
XLinkにそんなのないの?

410 :
ちょい質問。
<div>
<h1>hoge</h1>
<p>hogehoge</p>
<p>hogehoge</p>
</div>


<h1>hogehoge</h1>
<div>
<p>hogehoge</p>
<p>hogehoge</p>
</div>
ってどっちにしてる? ちょと迷ったんで聞いてみた。

411 :
>>410
divはそもそも意味づけを持たない要素。
使わないで済むのが一番だから、せざるを得ない方で。
validator的にはどっちも通る。

412 :
>>410
用途によるんじゃね?
divで纏める理由なんて人それぞれ、処理内容依存だし。

413 :
>>410
XHTML2.0(涙)的には前者、ISO-HTML的には後者
個人的には前者の方がhnとの繋がりが感じられるし機械もまあdivが包括してると見なすだろう

414 :
>>411-413
すまないありがとう。
なんか気持ち悪くなったから頑張って最適化してみる。

415 :
ぶっちゃけサイト内でぶれてなきゃ
divの使い方なんてどうだっていいんじゃね?
文句つける人も俺々ルールで文句つけてくるだけだし。
まあ最近はその手の人も絶滅気味な気がするが。

416 :
divには意味がないから、divが無くても成立する文章を書きましょうとはいうけれど、
pのように文章化されてもいなく、ulのようにリスト化されてもない、
単なる(突発的な)情報表示とか、フォームのボタンが単体で置いてあるのを入れるとしたら
divぐらいしかないような気がする。
で、そうなるとdivは意味を持たないというのとジレンマが発生すると。
意味を持たないdivの他に、「何かを示す」という意味を持たせた<indication></indication>
(または略して<ind></ind>か?)みたいな要素を4.01の時に作ってくれてたら、
そこんところが結構楽になったのになあと思う。

417 :
DIV要素は意味を持たないwww


418 :
×DIV要素は意味を持たない
◯DIV要素の意味がわからない

419 :
はいはい反論は具体的にね。

420 :
>>416
フォーム単体ならリスト1つというのは昔からよくある手
labelと合わせてdtもよくある

421 :
グルーピングっていうのが厄介だなって思った

422 :
全体のリード文を入れるとして、下の3つのどれが適切?ですか?
<h1>タイトル</h1>
 <p>リード文</p>
 <h2>サブタイトルA</h2>
  <p>本文A</p>
 <h2>サブタイトルB</h2>
  <p>本文B</p>

<h1>タイトル</h1>
 <h2>リード文タイトル</h2>
  <p>リード文</p>
 <h2>サブタイトルA</h2>
  <p>本文A</p>
 <h2>サブタイトルB</h2>
  <p>本文B</p>

<h1>タイトル</h1>
 <h2>リード文タイトル</h2>
  <p>リード文</p>
 <h2>本文タイトル</h2>
  <h3>サブタイトルA</h3>
   <p>本文A</p>
  <h3>サブタイトルB</h3>
   <p>本文B</p>
二個目はリード文と本文の区別がつかないことが気になるが、三個目は冗長?
ちなみにリード文で想定してるのは、新聞の一面記事についてるみたいなやつね。

423 :
>>422
<hn>タイトル
<p class="sub">リード文</p></hn>
もしくは一番上

424 :
これはひどいw

425 :
まえがきを章にするかどうかって話?
書籍だと
章にはなってないけど目次には載っている
「まえがき」という言葉が見出しっぽい扱いになっている
って感じだけどHTMLだとどうなんだろうね
もむしろ問題はあとがきで、
422の一番目のようにすると最終章の本文とあとがきが区別付かなくなる
過去スレだとDIVでのグルーピングで最終章とあとがきを分けるのは意味がないという話だったような
どういう結論に至ったんだっけ

426 :
普通に<hn>あとがき</hn>でも入れて章立てすりゃいいじゃん。

427 :
リード文は前書きでも後書きでもなく、長めのサブタイトルのようなものだろ

428 :
仮で良いから「リード文」とやらを明確にしてくれよ

429 :
一貫してりゃなんでもいいよ
ここでコメントする連中だって脳内ソースで喋ってるだけだし

430 :
>>428
それはさすがにググれ

431 :
>>430
じゃあ「内容による」でFA

432 :
俺なら
<h1>記事タイトル</h1>
 <h2>前書き<h2>
 <p>前書き本文</p>
 <h2>一章</h2>
 <p>一章本文</p>
 <h2>後書き</h2>
 <p>後書き本文</p>
ってなるから迷わない。迷いようがない。

433 :
前書きじゃないって言われてるのに

434 :
>>427
まあ、そういうわけなんだが、>>422は一番上で良いだろって事で。
>>423はhn要素の中にp要素ぶちこんじゃまずいけど。

435 :
>>423をspanにが個人的には一番いい

436 :
>>422
全部マークアップ的に適切だが編集さん的にどれがいいのかの問題な気がする。
あえて言えば一番目がきれいだと思う。
それ以外は冗長と言えなくない。

437 :
>>435
それは駄目だろう。
タイトルとリード文がインラインで隣接しているのは間違っている。

438 :
別に間違っちゃないだろ
リード分はタイトルの一部と考える人もいるんだから

439 :
>>438
サブタイトルじゃなくて、リード文の話だぜ。
>>422の言い方をすれば「新聞の一面記事についてるみたいなやつ」。
例えば
http://tadashi-inuzuka.jp/media/1/TokyoNews072708.jpg
だったら、「国際連帯税 導入を検討」がタイトル(というか見出し)で、
「政府は二十七日、為替取引や海外への航空券に課税し…」がリード文。
それを
<hn>国際連帯税 導入を検討<span class="sub">政府は二十七日、為替取引や海外への航空券に課税し…</span></hn>
とマークアップするのかい?

440 :
>>439
それでいいんじゃね?
誰もサブタイトルって話もしてないのに、まあ

441 :
「政府は二十七日、為替取引や海外への航空券に課税し…」はpだろ、常識的に考えて

442 :
常識的に考えれば、過去に消費した42スレの中で既に一定の結論が出てるはずだ

443 :
42 Name_Not_Found 2009/04/03(金) 05:19:08 ??? mailto:sage
ヽ(#`Д´)ノ

444 :
それは42レス目だろ。

445 :
ネタry

446 :
さびれたなぁ
主流じゃなくなっちゃったしな

447 :
お前らどうした

448 :
HTML5で色々諦めた。

449 :
お前らどうせXHTML5で書くんだろ?
ついにIE6とお別れだな

450 :
IE7と8ともお別れだろ

451 :
XHTML5ってなんだ?

452 :
ggrks

453 :
XHTML5はhttpレスポンスヘッダの送出するMIMEタイプがxmlうんたらとかが必須になっちゃったから…
いろいろ自由になる環境でしか使えない罠

454 :
>>453
だったら今までのXHTMLみたいに、text/htmlで運用すれば?
記法的な問題(<br />と<br>みたいな)は、どちらもtext/htmlで利用できる
application/xhtml+xmlなどのMIMEで運用必須なコンテンツがある場合は別だけど

455 :
>>454
XHTML1はtext/htmlにするのが、望ましくないがダメでもなかった。
でもXHTML5はMIMEタイプをxmlにするのが必須だぞ。

456 :
HTML5 でいいやん。
XHTML5 の必要そんなにある?

457 :
必要かどうかは別にして存在する。
そして、もし使う場合はという話だ。
まぁ>>453みたいな事情で廃れそうだけどね。

458 :
HTML5 は形式ばったのは不要、おもしろそうなのは採用!な流れに見える・・・

459 :
>>456
ウチではサイト全体をXSLTで生成してるから、XHTMLの方が楽。

460 :
xslt 使ってる人まだいたんだな

461 :
うちはwmlだぜ

462 :
>>460
というと、もっといい方法があるとでも言うわけ?

463 :
なんかもう strict html は終わったってかんじだねえ。
HTML5 はこのスレが昔目指してたものと全然違う方向に進んでるし。

464 :
どの辺りが?

465 :
>>463
つ XHTML5

466 :
>>465
実質一緒じゃん!
しかしここも寂れたな。sectionとか導入されちゃったからあんまり語ることなくなってきたってのもあるが。

467 :
>実質一緒じゃん!
XMLとしての体裁が求められますが?

468 :
だから、「実質」一緒じゃん。

469 :
文書のフォーマットの話じゃないのか?
フォーマットが違うだけで実質一緒、とな?

470 :
ここは言葉遊びスレじゃねーよ

471 :
HTML5は物理要素作りまくりだからってことか?
そりゃその部分は気に食わないが、XHTML5として残ってくれるのは有り難いよね。

472 :
XML じゃないと RDFa とか hCard が使い難いじゃんね。

473 :
i だの b だの hr だのが普通に復活している HTML5 が嫌いだ。

474 :
>>473
意味付け要素に昇格したんだから良いじゃん。

475 :
footer 要素を css で上に持ってったらだめなん?

476 :
www.w3.org/TR/html5/semantics.html#the-footer-element
例を見ると
そもそもマークアップの時点で下じゃなくてもいいみたいよ

477 :
>>476
なるほど、最後にあらわれなくても良い、って書いてありますね。
header だから上とか footer だから下とか名前でひっぱられる必要はないんですな。

478 :
ブログで
記事の題名はh1として
コメントの扱いはどうしてますか
ここから以下がコメントであることを示す文言や各コメントの題名等のマークアップ

479 :
pre

480 :
見出し要素を使うのかといった疑問です
ここから以下がコメントであることを示す「コメント」という見出し的なものに記事の章のように見出し要素を使うのか
また各コメントの題名にも見出し要素を使うのか、といった・・・
脚注、関連項目、参考文献、外部リンクといったものにも章と同じように見出し要素を使うのか、的な・・・
HTML5になると見出し要素の使い方はかなり自由になりそうなので小さなことで悩むのも馬鹿らしくなりそうだけど

481 :
好きにしろとしか。

482 :
そうですね
このスレに書き込みが減ったのも
もう好きなようにやってるからなんだろうなあ

483 :
Hnの後ろにDL

484 :
>>482
ケースによるだろうし人それぞれの考え方も出ちゃうだろうし自己満足とも言えるし。
SEO 的にどうよ?とか microformat みたいな機械処理目的のだったら
こうすべきっていうあるていどの同意はあるんだろうけどさ。
俺はコメントタイトルも h 付けてるよ。コメントヘッダが h4 とか h5 ぐらいになってて
コメント一個一個のタイトルはそれより一個レベル下のにしてることが多い。
タイトル付けない一行コメントレベルの場合は dl 使うかもねえ。


485 :
strictとSEOが一致しないのはあやかしと思う

486 :
ブログのコメントはdl

487 :
RDFa とか microformat とか microdata はどう思うよ?
あきらかに HTML じゃ語彙少なすぎるし納得の仕様だと思うんだが。

488 :
凡例ってどうやってマークアップする?
この記号は○○を意味しています、みたいなやつ

489 :
a で凡例の説明のところにリンクはりゃいいんじゃないの?

490 :
お前はなにを言ってるんだ

491 :
DLだろ

492 :
dl か table 以外になにがあるんだろう

493 :
掲示板のスレッド文章を<h*></h>で囲み、
投稿日や投稿者の名前を<ul></ul>でまとめた後<dd></dd>に格納。
コメントは<dt></dt>に格納してるんですがこれで使い方は合ってるのでしょうか?
それとももう少し適切な方法があるのでしょうか?
ご教授いただければ幸いです。

494 :
掲示板のスレッド文章を<h*></h>で囲み、

掲示板のスレッドタイトルを<h*></h>で囲み、

495 :
>>493
初心者は初心者スレ

496 :
<dl>で囲むのはもちろんなんですが
これはごく初歩的な事なんでしょうか?
html4自体、他者の投稿など動的なタグを意識してるような
タグはほとんど無いと思っておりまして検索しながら
色々模索してるのですが。

497 :
>>496
はっきりいって HTML4 は W3C も細かいケースについてはたいして記述してないから
勝手に拡大解釈するしかないんだけどね。
だからスレのマークアップの正しいやり方なんてないよ。
あと dl 絡みはよくわからんのなら別に無理して使う必要ない。
class だの id だのでスレタイとか投稿日とかを一意に抜きだせるようにしといたほうが
よっぽど有用。

498 :
ありがとうございました、
w3cの勧告書見て解釈してみます。
その一言ですっきりしました。
<table>も有用そうなんで検討してみます。

499 :
>>497
Strictスレでなに言ってんの?

500 :
>>499
お前こそ何言ってんの?
過去ログひっくりかえして一から出直してこい。

501 :
>>497
まず「正しい」を語ってみそw

502 :
>>498
実際tableはかなり有用。属性沢山あるし関連する要素もたくさんあるから
よく調べてから使ってね。

503 :
HTML5のおかげでこのスレもう用無しだよね。

504 :
>>463に戻る

505 :
Strictな(X)HTML5について語ってもいいじゃない

506 :
何か語ることあるわけ?
過疎っぷりが回答なわけだけど。

507 :
お前らどうした

508 :
どうしようもないほどネタが無い。

509 :
HTML5 の方向性がアレすぎるからなぁ。

510 :
もうこのスレは必要ないのか?

511 :
HTML5を語の質問もここでいいのかな?
HTML5で擬似フレーム(左メニュー、右メイン)をしたいのだが
HTML5で解説してるサイトあれば教えてください。

512 :
age

513 :
HTML5のheader要素が大嫌い

514 :
>>513
詳細

515 :
HTML5 はもう b とか i にむりやり意味付けたりしてるあたりでもう
駄目だと思った。

516 :
ダグラスのおじさんに出てきてもらってHTML5を作り直してもらわないと

517 :
>>515
WHATWGとW3CのHTML WGにフィードバックすりゃいいじゃないか

518 :
>>517
されてるし、却下されてる

519 :
>>513
h1でサイト名をマークアップしてる脳足りんよりはマシだろ

520 :
糞スレ

521 :
糞スレ

522 :
ttp://hato.2ch.sc/test/read.cgi/news/1292334758/

523 :
HTML1.0→HTML2.0┬→HTML4.01→xhtml1.0→(xhtml2.0)
                └→HTML3.2→HTML5

524 :
xhtml5はどこに入るの?

525 :
すっかり過疎ったなここ。
みんな何処行ったの?

526 :
>>525
http://hibari.2ch.sc/test/read.cgi/hp/1254235548/

527 :
誤爆かと思ったらそういうことか。ワラタw
【おまえら】W3C、HTML5ロゴを発表【大変だ!】
http://toki.2ch.sc/test/read.cgi/watch/1295456102/

528 :
Oh...

529 :
HTML4.01→xhtml1.0→(xhtml2.0)
コレ違くね?
結局HTML4.01だけが主流として残留生存って意味で最後ならわかるが
4.01からXHTMLってのは色んな意味で違う。

530 :
>>529
じゃあどう書けば納得するんだ?

531 :
前はチェッカーで100点取るためだけにdivとspanを多用してたなあ
今はそんなこともなくなったけど

532 :
XHTML1.1 は昨年2版が登場したばかり
XHTML+RDFa の更新も続いている
まだだ
まだ終わらんよ!

533 :
strict宣言なんて単なる自己満足

534 :
HTML4.01→XHTML1.0→XHTML1.1→(X)HTML5

535 :
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R
創価R 
創価R
創価R
創価R
創価R
創価R

536 :
みんな元気かな

537 :
1年経ってるね

538 :
みんなどこ行ったんだよ
たくさんいた気がするけど固定メンバーだったのか?

539 :
俺、まだいるよ

540 :
お前らみたいな暗い奴らが人の悪口言いまくってんのマジでうぜえ
俺中1だけどナメんなよ?
兄貴極道だしバイク乗ってるから、お前ら見てて超イライラすんだよ
無理だと思うけどお前らかかってこいよ。ケンカ なら負けねえよ?
やりてえ奴は言え。住所書いてやるよ。
まあ実際にやったとしたらケンカ開始5秒後には
お前ら全員返り血に染まってるわけだがな。

541 :
Strictは一時期盛り上がったんだけどなあ
今の人に説明しても「で?」って言われそう

542 :
>>540
もっとストリクトに生きろよ。

543 :
理想に走りすぎて運用側のニーズ無視した結果だよ
設計思想がもはや時代遅れ

544 :
俺のサイトはずっと XHTML 1.1 だ。
どうも HTML5 の簡略化されたやり方に馴染めなくて……。

545 :
XHTML1.1なら、DTDを変更するだけでXHTML5になるんじゃね
やる価値があるかどうかはともかく

546 :
それはない
いくつか要素の置き換えが必要

547 :
ruby以外で1.1から変更しなきゃいけない点ってなんかあるの?

548 :
XHTML1.1 の本気を見るのです!

549 :
>>547
div祭り

550 :
2ch
sc
のhtmlの<dt>おかしくね?

551 :
ホームページで友達が稼げるようになった情報とか

⇒ http://asaswq3wq.sblo.jp/article/181819223.html

興味がある人だけ見てください。

91T5ZZOOBL

552 :
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

553 :2018/05/01
誰でもできる在宅ワーク儲かる方法
少しでも多くの方の役に立ちたいです
グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』

7Z1UW

【yahoo】パクリはどこまで許されるか【Livedoor】
まとめサイト運営してる人 Part3
ID for WebLiFEでフラッシュHPを作ろう☆
Flashは求められる技術が多すぎ!!
CSS・sass・less・stylus 初心者スレッド=15th=
Web制作者が愚痴るスレ 49クレーム目
携帯SEO iMenu 「goo」を攻略するスレ
◆熱く盛り上がれweb制作板◆
サイト運営で嬉しい事があった管理人の憩いの場。2
JavaScript Tips コレクション
--------------------
マリドン2【マリオ板GAYN雑談BBS住人専】
AndroidはなぜiPhoneに勝利したのか920勝目
友達をやめるとき134
■■自衛隊ニュース速報&雑談スレ■■299
日本全国遠征ガサ
【芸能】「綺麗で大人っぽい」「目の感じ似てますね」 アルピニスト・野口健の15歳娘が広告デビュー
豆柴の大群 21匹目
【話題】驚き!北海道では「庭や車庫における焼き肉やジンギスカン」は普通のコトだった★3
中国の世界最大のダム 三峡ダムが最近崩壊する 5億人死ぬ 大量の難民が日本に来る [659060378]
ガミジン馬鹿にされたので嵐マース
【矢吹健太朗】ダーリン・イン・ザ・フランキス part2
【輪廻開放】東北の某祈祷師様【カルマ清算】14番目
犬、猫好きの俺のために画像を貼っていくスレ
大谷中学校・高等学校(京都府)Part2
TENVI テンビ part55
【NMB48のグラビアクイーン】「48史上最強ボディ」横野すみれ(19)、水着姿でたわわバスト&圧巻スタイル大胆披露!
スーパー買い占め 売り切れ
超速報!東京、千葉、埼玉、神奈川、大阪、兵庫、福岡、『緊急事態宣言』へ
【高等家庭】癌闘病ブログ144【玄関開けたら2分で虞犯】
あえて名無しを選ぶスレ
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼