Secure transfer of your domain Personal account manager for your transfer Different payment methods available
闇黒日記平成二十一年五月二十三日・二十七日 文書があつて、それをマーク附けした時に、結果としてXHTML 1.1適合になつてゐればXHTML 1.1と宣言する。妥当性の検証に関しては確かにそうだけれども、ではその文書が XHTML 1.1 適合になっている理由は何なのか。 ただ自分勝手にマーク付けをしているだけでは結果としてXHTML 1.1適合になつたりするはずはない。なぜあなたの文書の段落は「段落」タグでもなく「paragraph」タグでもなく「p」タグでマーク付けされているのかと問われた時、我々は結果として XHTML 1.1 (あるいは XHTML 1.0 や HTML 4.01) に適合するようにしたかったからという理由を認めざるを得ない。結局我々は、既定の DTD に従ってマーク付けを行うことを実質的に強制されている。 先にマーク付けを行って後から DTD を書くというのならま
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
>>Delta: 2008年12月 より。 来年は>>DeltaもXHTMLもどき(XML宣言省略)にしようかと企んでいます。 カスパさんのところを読み返して思ったのですが、 XHTML 文書を書く人って、なるべく XML 宣言を省略しようとするのですよ。 XML 文書なのだから XML 宣言したほうがいいと思うのは、 XHTML 文書と他の XML 文書を組み合わせて新たな可能性を見出そうとする人のわがまま? 何はともあれ、 XML 宣言はあったほうがいいと思うのです。 で、考えてみたところ、 IE でも XML 宣言ありで問題ないんじゃない? というのが個人的な考え。 XHTML などという、 HTML 文書に酷似し、なおかつ IE が対応していないメディア型 (application/xhtml+xml) を選ぶから IE で不都合が生じるわけであって、 XHTML が XML のひ
モジュール化されている DTD を一括して読みたい XHTML 1.1 の DTD のようなモジュール化された DTD というのは、作り手にとってはともかく読み手にとっては少々わずらわしいものです。 XHTML 1.1 の場合は DTD だけでなく仕様書自体もそうなっているので、 ID属性値を巡るhCalendarの奇妙な冒険 | hemiolia.com などでも XHTML1.1はモジュール化されてるということもあって、それ自体の仕様書は非常にコンパクトですが他の文書を参照しまくりです。泣きながらそれをたどっていきます というくだりがあります。 実践 Web Standards Design の 409 ページにてそのことについて軽く触れていますが、 XHTML 1.1 の ZIP archive または Gzip'd TAR archive をダウンロードして、そのアーカイブの中から
blog移行しました。新しいblogで更新を続けています。 XMLェ… text ja 2012-07-08 http://www.yomotsu.net/wp/?p=603 XMLェ… 日々の出来事2012年7月8日日曜日 ブログ作りなおそうかなーと思って、この Webサイト をみなおしてたら、Web ページのメタ情報としてダブリンコア (RDF) を混在させていたことを思い出した。バリデーターにかければ、グラフも取り出せて みたいな感じになる。でも結局あまり意味なかったです多分。いまは OGP とかありますしね。 Web ページは XHTML にしてたけど、ブログのコメントで参照先のない数値参照とか混ぜられると XML パースエラーになるし、XML だから他の語彙混在できるけど、RDF くらいしか混ぜてなかったし、XHTML 意味なかったです多分。いまは HTML に SVG 混在でき
Firefox3でabout:mozillaってアドレスバーに入れると、なんか表示されますが、&mozilla.quote;の中身はmozilla.dtdで定義されたエンティティなわけですけど、これだとp要素の中にstyle要素が入ってしまいます。XHTML 1.1なのに。 まあ、何をどのようにしても許される場所[謎]らしいですけど。
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2007-07-12 スキーマトロン(の補足)に追記・及び誤字・ソース(ショートカット効いてない問題)修正 ショートカットメニュー このレポートの概要 まず知っておくべき事 ルビの話 MIMEの話 複合文書の話 XHTML2の話 SVGの話 複合文書での名前空間 複合文書でのCSS アドレスバーに属性をコピペする? スキーマの話 DTDの編集 スキーマトロン(の補足) その他(質疑応答含む) オマケ このレポートの概要 途中からだったので、全ては聞けませんでしたけど難しい内容でした。 現時点では、一般の製作者というよりはマニア向け 。 内容は、W3Cで活動されていた石川さんが、自身が策定に関わった仕様などについて語ってくれるというもの。 将来的にXHTMLは複数のマークアップ言語を一緒に使える(SVGやMathMLとか)という話を中心に、スキーマとかW3C裏話なんかも。 石川さんは「仕様」
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
文書型宣言のない文書はHTML文書ではない事 いつ記述すべきか ある文書のマーク附けが完了した時、その文書がHTMLの仕様書(DTD:Document Type Definition:文書型定義)に照らして正当であったとします。その時、あなたはその文書の先頭に文書型宣言を記述できます。 マーク附けを行った結果、その文書がHTMLのDTDに適合するものである時、文書型宣言でその文書がHTML文書である事を宣言できます。あるDTDに適合した文書は、そのDTDに対応した特定の文書型宣言を記述する事が許されます。 具体的な記述の仕方は後述します。 DTDとは何か HTMLのDTD(Document Type Definition : 文書型定義)は、言ってみれば「HTMLの仕様書」です。 HTML 2.0/2.x(i18n)/3.2/4.01/XHTML 1.0/1.1といった各ヴァージョンのHT
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> ブロックレ
前のエントリー、「tfoot は tbody の前に書いた方がいいよ」では、行グループ、tfoot 要素の記述位置に関して hxxk.jp さんのエントリーに乗っからせて頂く形で書きましたが、該当エントリーのタイトルに突っ込みをいくつか頂いたので補足エントリー上げます。 突っ込みの内容としては、「書いた方がいいよ」 というタイトルの書き方だと、「書いても書かなくても自由だけど、書いたほうが吉」 と受け取る人がいて、ミスリードじゃないのということなんですが、確かにおっしゃる通りなのでその辺を補足したいと思います。 で、いきなり言い訳からなんですが、該当エントリーのタイトルを 「書いたほうがいいよ」 としたのは、 hxxk.jp さんのエントリーに対する突っ込みが主な内容だったので、hxxk.jp さんに向けて語りかける形で書いたからなんですね。なので、エントリー本文では 「仕様書には tfo
最近ウチの会社の中の人も書いていました、Web サイトのナビゲーションとしてよく使われる 「パンくずリスト」 (Topic Path なんて言い方もしますね) ... 最近ウチの会社の中の人も書いていました、Web サイトのナビゲーションとしてよく使われる 「パンくずリスト」 (Topic Path なんて言い方もしますね) ですが、マークアップの仕方はどういう方法がいいとか、そもそもパンくずリストって必要なの? なんて話まで、最近よく目にする気がします。 個人的にパンくずリストはサイト ID (ロゴなどですね) に対するトップページへのリンク設定同様の慣習みたいな感覚で、すべての人とは言わないまでも一定の認知はされていると考えていますので、サイト構築の際は基本的に要件に含めるようにしています。 で、今回はパンくずリストが必要か? とか、パンくずリストのマークアップはどのような方法が妥当か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く