Strict-HTML スレッド18

ところでさ、<h1>って大見出しだけど、そもそも大見出しって何？

そのページの本当の大見出しは<title>で記述するでしょ？そのうえ<h1>で繰り返しても意味ないよね。
まあ<h1>がページ内に2個以上あるならいいけど、普通ページをわけるから1個しかないよね。

例えばこのページも<title>と<h1>で同じこと言ってるけど、どうして？

>>943は取り下げます。もっと読んでからぐだぐだ言ってみる。

<!ELEMENT UNKO - - (昨日食べたもの) -(UNKO)>
俺は新しくUNKOタグを定義した。
みんなも使ってくれ。

とりあえずStrictについてある程度理解したけど、実行するのは難しいね。ちなみに
<!--コメント-->ってSGMLの関係だったんだね。
<!がSGMLの宣言？なんか違うな。
<!の後にハイフンが二つ続くとそこからはもう一度ハイフンが連続するまではコメントってことね。
そんでStrictではハイフンを2個以上連続させるのは禁止と。

つぎの質問どうぞ

ところで
<!ENTITY % test "a|b|c|d">っていうのはハッシュ変数testの中に4つ入れといて
エレメントの（内容モデル）のとこで参照するてのはわかったけど、

<!ENTITY % coreattrs
"id ID #IMPLIED -- document-wide unique id --
class CDATA #IMPLIED -- space-separated list of classes --
style %StyleSheet; #IMPLIED -- associated style info --
title %Text; #IMPLIED -- advisory title --"
>

これなんかはどういうこと？%coreattrsを内容モデルで指定すると、
<!ELEMENT TEST - - (%coreattrs;)>
<TEST　id="" class="" style="" title="">っていう属性が使えるってことかな？

( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

わかった。
上のやつはあくまでパラメタ定義だから、<!ELEMENT>で使うか<!ATTLIST>で使うか
は別で、上の感じなら、<!ATTLIST>で使えよ、ということか。

>945,947
取りあえずstrictには関係ないので出直しておいで

>942
> HTMLではこのレイアウトはできないっていう制限みたいな感じがいや。
いやならpdf使えバカ

HTML lintにTransitionalとしてかけたら-109点だった。とりあえず今日一日で
全てのページをtransitionalで75点以上になるように書き換えてみる。

>>951
pdfはテーブルレイアウト以上にうざがられる。

>>952
だってHTMLの範疇外のことやりたがって、できないのが不満、ってのなんでしょ？

なんでstrictスレに居付かれたのかな・・

>>954
相手してもらえるからだろ。

スレに有ってれば、最低限その部分だけレスして、
スレ違いの内容は一切無視がよろしいかと。

>>943
h1要素は本文。
title要素はメタ情報。

本で言うなら、扉と奥付の関係かな。

HTML文書の元となる文書を書いたとして、
そこに大見出しがあるならh1要素としてマークアップ。
大見出しがあってもなくても、title要素は必須。

>HTMLではこのレイアウトはできないっていう制限みたいな感じがいや。
それはHTMLではなくCSSの表現能力の問題です。

stricto厨って頭の固い奴ばっかりだな。
おまえら多角的に物を見たりするの苦手だろ。
もっと柔軟な考え方したほうがいいよ。

>>958
えー、そーかー？
アンタの方が硬くない？だって、ここstrictのスレだよ？
みんなその辺のことはわかってて、それでもstrictな道を選んでんだよ？

アンタみたいな人のためにtransitionalだってあるんだからさ。

>>958
だらしないことと柔軟なことってのは違うだろ。

どのレスを見て「頭が固い」と思ったのか。

>>940
楽しいよね。ヘタなジグソーパズルよりずっと良い。
ていうか、楽しいと思えるくらいになれば考えても最善の手段が見つからないことはほとんどなくなるけど。
もうちょっとCSS漬けになってたら何も考えないでも思い通りにできるんだろうか。

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

>HTMLではこのレイアウトはできないっていう制限みたいな感じがいや。

やりにくいレイアウトは見にくいレイアウトだと思えばいい

そもそもHTMLではレイアウトできないしなぁ。

はいまた燃料投下されました

so-demonai

「ジグソーパズル」とか「やりにくいレイアウトは見にくいレイアウト」というのは志低いなぁ。

CSSの仕様が(3でもまだ)不十分な上に現在の実装がそれすら実現できてないことは厳しい現実であり、我々はそれを認めなければならない。
その不備をレイアウトのせいにしたりパズルといって正当化しようとしていてはStrict-HTMLの思想を広めることはできない。
たとえば銃を知らない人に銃を見せて「なんだこの棍棒は。こんなものでおもいきり殴ったら折れてしまう」と言われたとしよう。
そこで「そんな殴り方は悪い殴り方だ」とか「折れないように上手く殴るのがおもしろいんだ」などと言っていては銃の有効性を広めることはできない。

現状ではブラウザ上で表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。
そのことを認めた上でHTMLというのはただデータを表現するためのもので画面に表示するのはあくまで利用方法の1つにすぎないこと、
そしてなぜtableレイアウトが良くなく、たとえ見栄えが劣ったとしてもStrict-HTMLを使うべきなのかを説くべきである。

#そしてPDFやSVG、XSLなどの仕様があるにも係らず、既存のHTMLブラウザと比べて良い実装を作れないプログラマ(私含む)はそれを恥じるべきである。
#また、銃は撃ってみればすぐその有効性を示すことができ、見た人は銃を導入するコストを惜しまないのに対し、Strict-HTMLに対してはそのようなものが少ない。
#Strcit-HTMLならではの利用方法を僅かしか見出せていない状況を我々は恥じるべきである。

>>968
既存のHTMLブラウザと比べて良い実装を頑張って作ってください。

HTMLで自分の足を撃つとどうなるんでしょうか。

>>968 を 3行以下で表現できない限り、Strict が広まることはないな。

あと、オーサリングツールも重要です。

>>971
ぬ
る
ぽ

なんで、有用性が無くちゃstrictにする意味がないの？
いいじゃん、特に意味なんか無くたって。
漏れ（達、っていったら迷惑かな）はきちっと書くのがすきなの！

>>974
いや、有用性がないと（個人の好みは兎に角）規格、仕様として駄目だろ。

strictには十分有用性はあるけど。っていうか、守らなくても
有用性が保持されるフォーマットなどあり得ないのだけれども。

>968
言いたいことはよくわかるんだけど、
> 現状ではブラウザ上で表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。
だけは承服しかねる。

>>973
ｶﾞｯ

>>968
「CSSの仕様及びUAの実装の隙間をくぐり抜け、スタイル指定する事を、
パズルと言う言葉で正当化しようとしている」人が何処かに居ますか。
「志低い」とまで言っていますが。

JIS規格のアクセシビリチって、草案からどれくらいズレてくるのかな。

漏れ製作会社なんだけど、こないだクラの広報部web部門の
主任（毒女、NN4+table大好き）に呼ばれて、
「変なhtml書かないで頂戴！キーッ！」
ってどやされて。漏れがJISの話をして、
「御社のような大きなサイトをお持ちなら、ぜひ今のうちから準備なさった
　ほうがよろしいかと存じます」
って言ったら、突然自分のノートでググりだして。漏れ、自分の鯖に
草案pdfのコピーもってたから、見せてやったら、
「こんな草案通るはずないざます！キーッ！」と。

確かに漏れも、あれが全部規格になるとは信じがたいが、どの変まで
浸透するのかなあ。

藤子漫画の人ですか。

制作側が高齢者や視覚障害者への配慮も必要だけど
むしろWebはこういうものだと教えてやる方が重要だと自分は思う
こういう人たちは結局Webのページの見方や活用法がわかってないから

誰 > 藤子漫画の人

>>982
スネオのお母さんとかそういうのんじゃねえの？

前に、CSS系のどこかのスレで見たのを、ちょっと脚色。


中の良かった外注クリエイタがstrictに走り、
代理店の営業氏は彼と仲たがいをして連絡をとらなくなった。

その営業氏がある日、目に失明級の障害負ったと聞き、クリエイタは、
ユニバーサルアクセスなセッティングのノートPCを贈った。
営業氏は喜び、二人は仲直りした。

その夜、氏は夫人と、過去に手がけたサイトを見る（聞く）ことにした。
しかし、氏が推進していたアンチCSS・tableﾏﾝｾｰなサイトは
どれも意味不明な単語の羅列を読み上げるばかり。

唯一、わかりやすかったのは、営業氏を散々罵倒するそのクリエイタの
サイトだけだった。

>>984
ﾂﾏﾝﾈ

>>984
なんか童話みたいな話だな。
原文のURIきぼんぬ。

>>984
イソップ童話でありそうだな。
俺もURIｷﾎﾞﾝ

>>978
968とは別人だけど、912が"strictなままだと思った通りのレイアウトができない"といっているのに対して>>940, >>962はそれを肯定しているように見える。

>>984
strict-htmlが広まるのとUAが賢くなってtableレイアウトでもちゃんと読み上げられるようになるのどっちが先だろう?
googleは構造化されてない文章でもけっこうちゃんと扱ってるし。もちろんstrictな文章の方がちゃんと扱えるけど。

>>988
そもそもレイアウトとStrictを関連づけて思考している段階で間違い。
>>940は一旦Strict（構造のみの表記）にしてからCSSでレイアウトをするのが
楽しいと言っているのであって、「Strictでレイアウトするとか、出来ないとか」
いう思考そのものを否定している事を認識しる。

>>988
それなりにtableレイアウトに対処する音声UAが出現したとしても
構造と表現が分離してある方が便利なことには違いないよ。
文脈の自動判定なんて誤差がつきものだし(精度が上がれば上がるほど
誤差は誤解・トラブルの温床となるだろう)
スクリーンメディアと音声メディアのためだけのStrictじゃないし。

>988
そのどちらよりも先に、ブログなどの文書格納DBのフォーマットとして
XMLが普及し、XML→XSLTによりHTML+CSSを生成という流れがメジャーになって
「XSLのテンプレいじるよりCSSいじった方が楽だ」という一般人が多数化。

かくて、CSSが普及するも、HTMLを理解出来ない奴が「とりあえずCSSの
セレクタにするだけなら」とXSLにdiv、spanによるclassとidを大量に
埋め込み、tableは淘汰され、div房、span房の天下がやってくる、

…希ガス。

>>988
レス有難う。
>>940は、>>912の"strictなままだと思った通りのレイアウトができない"に対し、
＞Strictで記述して「から」、
＞楽しみだったりするん「だけど」なあ。
と言っていて、私はここから「そもそも、マークアップとスタイル指定は同時に行うべきではない」と言う主張を読んだ。
つまり、940は912の言葉に対して、肯定(「確かに出来ない」)でも否定(「いや、CSSを勉強すれば出来る」)でもなく、
根本的な考え方を指摘(「マークアップとスタイル指定は同時に行うべきではない」)したのだと思う。

>>962に関しても、確かにCSSでのスタイル指定にはパズル的要素があるから、批判される様な発言ではないと思う。
(パズル的要素 = 素のHTML文書のデザインを、自分の頭の中にある正解(理想のデザイン)に、限られたプロパティやその値を使って近付けていく部分)