「正しくHTMLを（中略）5つの質問」に対する回答一覧 : 雑記帳 : der Gegenwart
[ Web関係 ] 何人か回答してくださった方がいらっしゃいましたので、ここで紹介します。順番は私が気づいた順です。基本的にアクセス解析のリファラで確認してます。全くアクセスのないサイトでない限りは多分平気。「回答したからすぐにでも載せてくれ」って方がいらっしゃいましたら、メールにて当該URIを送って下さいな。はてなのコメントで知らせてくれてもOK。 っていうかこういうときトラックバックあると便利なのかな。今さら面倒だからそんな機能つけないけど。 質問の数が5個ってのは概ね好評みたい。 我的春秋: Re: 正しくHTMLを書こうと心がけている人に5つの質問 Re : 正しくHTMLを書こうと心がけている人に5つの質問（pixel） 正しくHTMLを書こうと心がけている人に5つの質問 (kuruman.org > 諸情報) Re: 正しくHTMLを書こうと心がけている人に5つの質問（JamG
ol 要素 の子(li 要素)に連番クラスをつける | ヨモツネット
概要 全ての ol 要素の子要素となる li 要素の class 属性値に orderN を追加します。N は 1 から始まる整数です。 動作確認用の demo ダウンロード 説明 このスクリプトを使用するとページの読み込みが完了した時点で、 <ol> <li>text</li> <li>text</li> <li>text <ol> <li>text</li> <li>text</li> <li>text</li> <li>text</li> </ol> </li> <li>text</li> </ol> <ol> <li class="order1">text</li> <li class="order2">text</li> <li class="order3">text <ol> <li class="order1">text</li> <li
hr 要素をかっこよく使う | ヨモツネット
概要 hr 要素は構造を区切るためのものではなく、線を引くだけの要素で、u 要素, i 要素, big 要素などと同じ視覚的な目的で使用される要素でそのレンダリングは UA 依存のため枠線が消えなくてもおかしいというわけではなさそうです。 hr 要素はブロック要素なので CSS で border を none にして、width, height や background を指定すれば装飾が可能です。しかし IE では hr 要素の border を消すことができません。Firefoxや opera, Netscape などの CSS をしっかり処理してくれるブラウザでは border を消すことができます。 そこで、IE だった場合のみ、hr 要素を div 要素に置き換えしてしまうための JavaScript を書いてみました。(mixi でご助言下さった皆様、ありがとうございました。)
XHTML1.0 Strict 内容モデル
head要素の子要素 <base /> href属性必須 空要素 <link /> 空要素 <meta /> content属性必須 空要素 <object>-</object> 他の内容よりも param要素を先行させるべき param要素 ブロックレベル要素 インライン要素 テキスト <param /> name属性必須 空要素 <script>-</script> type属性必須 スクリプト（PCDATA） <style>-</style> type属性必須 スタイルシート（PCDATA） <title>-</title> head要素内に必ず1個だけ定義 テキストのみ（PCDATA） ブロックレベル要素 <address>-</address> インライン要素 テキスト <blockquote>-</blockquote> ブロックレベル要素 <div>-</div> ブロックレ
DOCTYPEスイッチ
Updated 2013.09.27 / Published 2006.05.08 現在リリースされている視覚環境のUAには、宣言された文書型に応じてレンダリングモードを標準準拠(standard)モードか後方互換(quirk)モードに切り替えるDOCTYPEスイッチ(DOCTYPE Switching)の機能が備えられています。 これは、全ての制作者が宣言した文書型に定義されている仕様（ルール）に沿った文書を作成していれば、その仕様通りの動作や表示が期待できるので問題は起こりませんが、中には問題のある記述をしている制作者もいるために、UA側で宣言されている文書型に応じてレンダリングモードを切り替えるようになっています。後方互換(quirk)モードでは、拡大解釈をしたり、仕様で定義されている内容とは異なる独自の解釈する場合があります。 後方互換(quirk)モードの際に問題となる記述例 c
「DOCTYPE スイッチ」 CSS 解釈実例編
説明 このページでは、「DOCTYPE スイッチ」によって CSS の解釈がどのよーに変わるのか、実例を挙げていくです。 仕様どおりの解釈をしない古いブラウザが多かったために、それに合わせる形の記述慣習とそのノウハウが普及しきっている感があります。それは HTML に限らず今や CSS においても。しかしそのような記述は、「仕様どおりに解釈するブラウザ」では正しく（意図したとおりには）表示されないことが多いのです。 「DOCTYPE スイッチ」機構を備えたブラウザが、「仕様準拠の厳格解釈モード (Standards mode)」へ解釈モードを切り替えた時、そのような「仕様どおりに解釈しない古いブラウザを前提として書かれた慣習的な記述」の表示ぐあいにはかなりの変化があります。特によく見かけるそういうモノをいくつか例示してみるです～。 解釈モード想定サンプルページ 「DOCTYPE 宣言による
tfoot に関するエントリーの補足
前のエントリー、「tfoot は tbody の前に書いた方がいいよ」では、行グループ、tfoot 要素の記述位置に関して hxxk.jp さんのエントリーに乗っからせて頂く形で書きましたが、該当エントリーのタイトルに突っ込みをいくつか頂いたので補足エントリー上げます。 突っ込みの内容としては、「書いた方がいいよ」 というタイトルの書き方だと、「書いても書かなくても自由だけど、書いたほうが吉」 と受け取る人がいて、ミスリードじゃないのということなんですが、確かにおっしゃる通りなのでその辺を補足したいと思います。 で、いきなり言い訳からなんですが、該当エントリーのタイトルを 「書いたほうがいいよ」 としたのは、 hxxk.jp さんのエントリーに対する突っ込みが主な内容だったので、hxxk.jp さんに向けて語りかける形で書いたからなんですね。なので、エントリー本文では 「仕様書には tfo
W3C Relaunches HTML Activity
Developers and Browser Vendors Shape HTML Future http://www.w3.org/ -- 7 March 2007 -- Recognizing the importance of an open forum for the development of the predominant Web content technology, W3C today invites browser vendors, application developers, and content designers to help design the next version of HTML by participating in the new W3C HTML Working Group. Based on significant input from t
テキストをXHTMLに変換するJavaScript製「Markdown」ライブラリ:phpspot開発日誌
Showdown - Markdown in Javascript テキストをXHTMLに変換するJavaScript製「Markdown」ライブラリ。 次の画像を見てください。左の入力欄にテキストを入力すると、リアルタイムで右のウィンドウにHTMLに変換されたページが表示されます。 要は、Markdownとは、WIKIのような文字列変換を行うもののようですね。 ライブラリ自体はダウンロードして自分のツールに独自に組み込んだり出来そうです。 JavaScriptで出来ているということで、サーバに依存せず、アイデア次第で面白いもの/便利なものが作れるかもしれませんね。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
完璧なXHTMLの利点はなんでしょうか？ CSSでデザインや、CSS外部ファイル化は別にXHTMLでなくてもできますし、SEO対策もそうです。…
SEO×PHP×XHTMLに最適化されたCMS開発のコツ-CSS Nite in Osaka 2007 春の陣 前夜祭