Strict-HTML スレッド 32

煽りじゃなくて徹底してるなってだけなんだけどねw

＞少なくとも、この使い方をする限りにおいては、矛盾は無い。

それ以外の場合はどうなんだっていう話

ところでみなさん、DTDは読めますか？
または書けますか？

>>951
数字にすればいいんじゃない？数字はダメだっけ？

すべてのフォームコントロールと a 要素に accesskey と tabindex を付けてみたけど
自分でも収拾がつかなくなったのでやめた。

アクススキーもグローバルルールが有れば普及すると思うけど、現時点では駄目だろ

accesskeyは物理的なキーの文字ではなくて
論理的なロール名とかにしておくべきだったな。

>>955
Firefoxのタブでバッティングする…

アクセスキーこそ、W3Cで勧告すればいいじゃマイカ？

accesskeyって逆にアクセシビリティを低下させるの？流れがこれだからこのスレで聞いちゃうけど

各自で勝手に設定できるしバッティングもするから、
アクセシビリティ低下といえば低下かもしれない。

>>944,950
明示的に指定しなくても、HTML仕様書にタブ移動順位が明記してある。
その順序を変更する必要がなければ、わざわざtabindexをつけなくてもよい。

accesskey属性とかtabindexとか属性title属性とか、
一般属性はどの要素につけるべきなのか迷う。

可能な限り全部。

俺は>>958の意見に賛成だな。

しかし、フォームのボタン配置とかって、
OS毎にポリシーが違ってたりするんだけど、
そういうところも吸収してくれるとユーザビリティとか
アクセシビリティ的には嬉しいんだけどね。

この流れだからついでに言うが、この前link要素にaccesskey指定すれば良いじゃんと思ったが、
WinIEどころかOperaも反応してくれなくてへこんだが、
link要素のaccesskeyはUAが設定すれば十分だと思ったが、
そうなるといよいよaccesskeyをどこに指定すれば良いかわからないと思った。

>>958
それいいな。

>>954
読むだけならなんとか。書くのは無理。

>>948,952
お前brとか使ってるのかよｗ

>>846-847
むしゃくしゃしてやった。IE向けのスクリプトくらい動けばそれで良いと思った。
DOMとかJavaScriptとか知らない。今は反省している。
でもclassName属性があればと仮定してるだけなので非Strictではないと思った。
CSSで nazoelement{ ... } と書いても問題ないように。

>>967
>お前brとか使ってるのかよｗ

address要素…

brは別に悪かないと思うんだがなぁ。
definition listを会話ととらえるだけの想像力があるなら
brが収まるポジションぐらい考えつきそうなものだが。

>>968
addressならOKってのもなんか逃げてるみたいでやだね。

インラインしか含む事ができないって要素もあるよなあ。
<br />を使うのは別に悪い事じゃない。

だからってbrを入れればその２行が２段落になるわけじゃない。
それが２段落だと思うのなら
<p><address>うんちゃら</address></p>
<p><address>かんちゃら</address></p>
だよな。俺はリストのがいいと思うが。

>>967
勿論使ってるぜ。

>>934

仕様書を久しぶりに見直してみました

以下引用
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

複数の用語と記述とを組み合わせる例を、次に示す。
<DL>
<DT>Center センター
<DT>Centre センター
<DD> A point equidistant from all points
on the surface of a sphere.
球体において、表面のあらゆる点から等距離にある点。
<DD> In some field sports, the player who
holds the middle position on the field, court,
or forward line.
フィールド競技で、フィールドの中央、コートの中程、
フォワードの中心等に位置するプレイヤー。
</DL>

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

> 関心の無いスレに書き込むなよ。

ご忠告痛み入ります

>>973
やっぱこれを会話にも使えって時点でどうかしてるよ…

そんな曖昧な意味付けしたところでUA側でどう役立てればいいのだろ。
音声ブラウザがdlに直面したらどう扱えばいいの？
用語の定義と会話の羅列じゃ結局途中途中に間を置くぐらいしか想像出来ないし。

晴眼向けのブラウザでも所詮cssのエントリポイントにしかならんし。
意味の幅が広すぎてそれだけ見たら定義なんだか会話なんだかわからんから
UAだけの判断じゃとりあえずレンダリングする以上のことは出来ない。

もっと要素の種類増えないかな…。

要素はずっと減る方向になってたんだよ。
曖昧じゃないと多言語に適応できないからな、
自然言語は厳密に仕様を定義すればするほど世界では使えなくなる。

・・・・・のに、XHTML2.0はどうんることやら・・・・・・

>>974
研究・学術文書を意識して作成されたという
歴史的経緯が現状にそぐわないけど、
かといって代案となる文書全般をUAに対して
効果的に表現できるフォーマットもない、
という状況なんでしょう、たぶん。

このまま仕様を増改築してもいびつになっていく
だけのような気がするけど、"文書全般"ってのが
列挙できれば、それをカバーする仕様というのも
作られる余地があるかもしれないね。

>>975
というわけで、減らすだけじゃなく、会話文とかも
考慮に入れることも必要性があることだと思う。

＞会話文とかも考慮に入れることも必要性がある
ねーよ、そんなレアケースにまで対応してったら収集つかなくなる。
「似たような」dlで代用できるんだったらそれでいい。
代用できないもののためにdivやspanが用意されてることだし。

>>977
>974
> そんな曖昧な意味付けしたところでUA側でどう役立てればいいのだろ。

つーか、divとspanで別に困らんよね。StrictのためのStrictってのも
もったいない話だし、>640みたいな活用の余地があるようにあり方
を考えたほうがいいと思うよ。
dt,ddを会話で使ったりしてたら、そういう機械処理の邪魔になって
しょうがないだろ。レアケースというほど対話文ってのがレアなわけ
じゃないし（インタビューとか小説とか）。
（とはいえdt,ddで会話文ってのは仕様で例示されてて解釈の問題じゃ
ないけど……）

収拾つかなくなるって言うけど、実際収拾つかないほどバリエーション
ってあるかな？ここでいますぐ列挙して見せろといって網羅できる
程度じゃないとは思うけど、ひとつの仕様には収まりそうとなんとなく思う。

>978
>ここでいますぐ列挙して見せろといって網羅できる
>程度じゃないとは思うけど、ひとつの仕様には収まりそうとなんとなく思う。

要素を増やしてもベンダーが対応しないかもよ？
利用頻度の低いものなんかは無視されそうだし、そうすると不思議マークアップが蔓延りそう。

とゆーわけで、要素は抽象化して属性値で具体化するのが現実的だと思う。
例えば、meansっていう属性値を用意して、取ることのできる値を定めておく。
基本的に一般的なUAはそれを無視するが、用途に応じてはその意味を解釈する、みたいな。
きっと、初心者はmeansを設定しないだろうし、誤解釈も減るはず。

しかし、そうすると現状のHTMLから離れてしまう罠orz

spanとdivだけが残るってこと？

structure要素各種、section要素、見出し要素、汎用ブロック要素、汎用インライン要素
だけでいいような気がしてきた

個人的には DocBook がいい線行ってるような気がする

導入コストがちょっと…

>>979
roleとかってなかったっけ

strictなhtmlを最も正しく表示できるブラウザって何だろ。

>>985
一応Amayaってことになってる・・・わけないよなあ

Opera9tp2は結構いい感じな気がする。

HTMLの「表示」はどうでもいいだろ、
意味の解釈さえできれば。

そうだな。どちらかというとこれはスタイルシートの実装に関する話題だ。

IEが一番下とは言える。

レンダリングされなくてもソース見ればOKな俺が来ましたよ

しかし>>991はFLASHに未対応だった

きっとSVGには対応してる

かっこええ・・・・

次スレは？

>>979
表のサマリ属性みたいなかんじ？

画像を埋め込む場合、みなさんは IMG要素 か OBJECT要素
どっち使っていますか？

そういった実務的な質問は

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

梅

1000Strict-HTMLよ永遠に・・・

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。