HTML5の空要素タグの文法 - 徒書
HTML5の空要素タグについては、/ が入っても入っていなくてもどちらでもよいものと認識していた(参照: WHATWG FAQ - 日本語訳 - HTML5.JP)。しかし具体的に仕様を確認したことがまだなかったので、仕様書の9.1.2.1 Start tagsの項を読んでみた。(以下、自分なりの訳も付記してみました) Start tags must have the following format: (訳) 開始タグには、以下の書式がなければなりません: 1. The first character of a start tag must be a U+003C LESS-THAN SIGN character (<). (訳) 1. 開始タグの先頭文字は U+003C LESS-THAN SIGN (<) でなければなりません。 2. The next few characters
XHTML 1.1からHTML 4.01への変換 - 徒書
deadspace #2009-05-20 にてXSLTの問題提議がされていたので、少し考えてみました。かいつまんで言うと、XHTML 1.1からHTML 4.01、HTML4.01からXHTML 1.1へのXSL変換では、単にコピーしただけではうまくいかない箇所がでてくるというものです。 取り敢えずこの記事ではXHTML 1.1文書からHTML 4.01文書への変換について考えてみました。 input.xml : <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="
em要素とstrong要素 - 徒書
HTMLにはemとstrongという要素型があり、それぞれ強調《emphasis》とより強い強調《stronger emphasis》を示すものとされています。これらの要素については、強調の強弱を示すためなら要素を多重に入れ子にすればよい（例えば、<strong><strong>強調</strong></strong> のように）との考えから、強調を表す要素は2つも必要無いという意見があります。 野望の王国の強調に一言物申す < Blog < Black Box XHTML 2.0草案（2003年5月6日版）の9.11. The strong elementには、"Leave in, deprecate or remove? No consensus."という記述がある。尚、2004年7月22日版草案の9.11. The strong elementの項には記載されていない。 しかし、自分
XML::LibXMLでHTML文書を扱う - 徒書
XML::LibXML大好きな者が以下述べてみます。 しかし、XML::Liberalを除けば、XML::*なモジュールはX抜きのHTMLを食ってくれない.... と、404 Blog Not Found:perl - HTMLをXMLとして扱うで書かれていたのですが、XML::LibXML、というかその基となるCライブラリlibxml2はHTMLパーサも備えているので、直にHTMLを扱うこともできます。 ただ元がXMLパーサなだけに、少しでもHTML文書に壊れた部分があると解析エラーを起こして停止してしまいますが、幸いなことにそのエラーから回復するモードも備えています。以下サンプルを。 use strict; use warnings; use XML::LibXML; my $parser = XML::LibXML->new(); $parser->recover_silently(
HTML5仕様書の要素索引を作ってみる - 徒書
HTML5仕様書を拾い読みしていこうかと思い索引を見てみたら、全然作られてなくてがっかりしたのでありました。取り敢えず要素索引だけでもと思い、目次を元に自分で作成してみました。 index of HTML5 elements ちなみに作成には以下のようなPerlスクリプトを使用しました。もし要素の抜けなどありましたら、何らかの方法でご報告頂ければ幸いです。 # version: 2010-06-11 use strict; use warnings; use XML::LibXML; my $url = 'http://www.whatwg.org/specs/web-apps/current-work/multipage/'; my $parser = XML::LibXML->new; $parser->recover_silently(1); my $doc = $parser->p
スタイル変更2009 - 徒書
ふと思い立ってここ徒書と徒委記のスタイルを簡素なものに変更してみました。 背景画像はやっつけなので後日変更したいところ。 2009年1月21日23時49分 分類: 徒 コメント/トラックバック (3)
ゆの in XSLT (feat. XPath) - 徒書
ゆの in Ruby - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech ゆの in languageとは - はてなダイアリー XSLT版はid:mayukiさんが既に作られているのですが、他の言語だと複数の解が出ているところもあるので、自分もXSLTでの別解を作ってみようと試みました。方針は以下。 XSLTスタイルシートの埋め込みを使ってみる。 入力文字列がXPathとして評価されるようにしてみる。 できたものは以下の通り。 <?xml version="1.0" encoding="utf-8"?> <?xml-stylesheet type="text/xsl" href="#style"?> <!DOCTYPE ひだまりスケッチ [ <!ATTLIST xsl:stylesheet id ID #REQUIRED> ]> <ひだまりスケッチ> <xs
文字エンコーディングについて、text/htmlの事情とXMLの事情 - 徒書
text/htmlのXHTML(1.0)文書のデフォルトの文字エンコーディングは - cnrdの日記より。 XML宣言とDOCTYPE宣言 - vantguarde - web:gをきっかけにXHTML Media Types - Second Editionを見て、XHTML Media Types(FE, SE)のtext/htmlの項とXHTML 1.0 SEやXHTML Media Types FEのHTML互換性ガイドラインはデフォルトの文字エンコーディングの点で矛盾があるのでは、と思いました。 上記を拝見して自分も XHTML Media Types Second Edition の「3.1. 'text/html'」の項 XHTML Media Types Second Edition の互換性ガイドラインの項 を読んでみたのですが、この2つの記述は矛盾というよりは、現時点に
CSSでよく使う装飾定義をclass名でまとめることについて - 徒書
2xup.orgのCSS でよく使う装飾定義をコンポーネントとしてまとめるという記事を読んだのですが、挙げられているHTMLの例を見てみて、「いやいやその方向性は無しでしょう」と思ったのでした。何故かといえば、 リストをインラインで表示するために <ul class="inline"> ナビゲーションリストをタブのように表示するために <ul class="tab"> という書き方をしていたので。それはつまり「文字を赤くしたいので <span class="red">文字</span>」というのと同じなのでは。 ADP: class=red スタイルシートの基本 -- ごく簡単なHTMLの説明 (「クラス名の考え方」参照) 記事では、 見た目を意識しすぎてしまっているのが気になるので class の名前を変更したり、 とも書かれているのですが、単にclass名を変更するだけでは状況は大差な
XSLTでナビゲーションリンク表示 - 徒書
link要素とCSSのみでナビゲーションを作るで、CSSでlink要素によるナビゲーションを可視化する方法を知りました。 便利そうなのですが、「link要素をCSSで表示させると、a要素と同様のアンカーとして表示される」という実装をしているのは今のところFirefox等のGecko搭載ブラウザだけのようであり、HTMLの仕様上も必ずそのように実装しなければならないわけではないので、汎用的な方法とは言い難いのが惜しいところ。 そこで、 「出来るだけ既存のXHTML文書を書き換える事なく済ませたい。」 「JavaScriptを無効にしている方も困る事ないようにしたい。」 という条件の上で、より汎用的な解決方法はないかと考えてみて、「XSLTを使ってlink要素の内容をリストとして反映できるのでは」ということを思いつきました。 で久しぶりにXSLTを書いてみまして、できたのが以下です。 test
あれこれポップアップとCSS生成内容 - 徒書
CSS生成内容による属性値の表示とあれこれポップアップを組み合わせて使っている場合の問題点と、解決方法について述べてみます。 CSS2では、:before擬似要素や:after疑似要素とcontentプロパティを使うことにより、HTML文書の本文に無い内容を生成することができます。例えば、引用文のマークアップ(blockquote, q要素)について、title属性で示した引用元を表示させたりすることが可能です。 CSS生成内容表示サンプル ※ Firefox, OperaなどCSS2生成内容に対応したブラウザでご覧ください。CSSはHTML文書内にstyle要素として記述しています(以下のサンプルも同様)。 このようにCSSによりtitle属性の値を表示させている文書で、あれこれポップアップを同時に使用していると問題が起ります。マウスカーソルを該当の要素の上に移動させると、生成内容のうち
CSS Nite Vol.10に行きました - 徒書
7月20日にCSS Nite Vol.10に行ってきました。 プレゼント抽選でユニバーサルHTML/XHTMLを頂きました。 さらにサインまで頂いてしまいました。(さすがサインの日付もW3CDTFですよ) 神崎正英さんを初めて目にしたその日に著書とサインを頂けることになるとは思ってもみませんでした。有難いことです。 さて神崎さん講演ですが、フォーマルで行こうと題して、情報の共有と再利用のために重要となる形式《フォーム》についての話が語られました。 情報を共有するには名前をつける必要がある。 名前にはそれが通用する文脈《コンテクスト》がある。 という身近な話題から出発し、 ローカルにXHTMLを拡張 → class属性 コミュニティでclass属性名を共有 → microformats URIを用いてグローバルに情報(とその関係)に名前付け → RDF という風に発展して行きました。RDFと
ルビ表示はユーザスタイルシートで! - 徒書
なんだか最近になってMozillaでルビ表示3の記事(個別ページ)がブックマークされているなと思っていたのですが、404 Blog Not Found:css - ルビもCSSでで紹介されていたからのようでした。 それにしてもその紹介記事のブックマーク数が200以上ってすごいな。やはりウェブでは作った人よりも紹介した人の方が注目される、ということなのでしょうか。それはいいとしても、トラックバックで「プログラマーの小飼弾氏のアイデアと技術には……」と書かれているのを見てしまうと釈然としないものを感じてもいいでしょうか。(←誤った疑問文) それはそれとして、404 Blog Not Foundではルビ表示用のスタイル定義をサイト用のCSSに組み込んでいますが、これはあまりよくありません。あのスタイル定義は(2001年当時のMozilla用に作った、)あくまで擬似的な表示を行うスタイルです。製作
HTML4の要素がXHTML名前空間に属するものとして扱われる件 - 徒書
先のStylishを改造してみるの記事がCSSコミュニティスレで言及されまして、やや意外な展開となりました。かいつまんでまとめると以下のような感じ。 FirefoxのCSS実装では、text/htmlの文書の要素もXHTML名前空間を選択するセレクタで選択されるようだ。 <title>例</title> <style type="text/css"> @namespace h url(http://www.w3.org/1999/xhtml); h|p{display:none;} </style> <p>表示されない段落。</p> これは仕様上正しい動作なのだろうか。 @namespaceの規則からするとおかしいように見える。 和泉さんによりBugzillaへ報告。 えむけいさんにより、WHATWGのWeb Applications 1.0仕様に従ったものではないかとの指摘あり。 なるほ
CSS關係者に37の質問への回答リンク集 - 徒委記
CSS關係者に37の質問への回答リンク集 回答リンク 「CSS關係者に37の質問」への回答リンク集です。 CSS關係者に37の質問 編集と追記の便を図るため、wikiに移すことにしました。 追加質問については、CSS關係者に37の質問と追加質問をご参照下さい。 CSS關係者に37の質問の囘答 野嵜健秀さん Diary : 2001/9 - Ancient library 近藤和宏さん http://niaou.alib.jp/notes/q100css.html NiAOUさん 日記 - 果ての領域 龜井健太郎さん http://www2.jan.ne.jp/~u-z/misc/QandA.html U-Zさん 犬豌豆・轟天號 暗黒な方さん 平成13年9月23日「CSS關係者に37の質問」より iMaさん CSS關係者に37の質問+α shelarcyさん CSS関係者に37の質問への回答
cite要素はblockquote要素とは関係ない - 徒書
cite要素に関して、柊アマテルさんの見解を拝見したのですが、何となく違和感がありました。 cite要素を使ふ上でも要素間の機械的な関係は全く考へない方が賢明です。 という結論については同意なのですが、でもそれはもとからそういうものだったのでは、と思うのです。HTMLの仕様から見ても、cite要素はその前後のblockquote要素やq要素と関連付けて何らかの処理を期待するようにはなっていないようですし。 cite要素は――ありていに言えば――もともと英文の活字文書等で、引用を行う際に引用元の表題の部分を斜字体にする習慣があり、それをHTMLで表現(スタイルとしてではなく、より抽象的な構造として)するためにあるものだと思ってます。 定義語を示すdfn要素も似たような事情で、活字文書で言葉の定義が述べられるときには、その言葉が斜字体なり太字なりで強調されることがあったので、それをHTMLで表
引用元の表示と表記の改変に関する議論 - 徒委記
引用元の表示と表記の改変に関する議論 2005年9月9日 2005年9月12日 2005年9月13日 2005年9月14日 2005年9月15日 2005年9月16日 2005年9月17日 2005年9月18日 2005年9月19日 2005年9月21日 引用文の表記改変はどこまで許されるか? また、引用元の表示は cite 属性で十分なのか? 2005年9月9日 無断リンク禁止とか Akky さん 2005年9月12日 ネチケットの拡大解釈 真名垣 郁夫 さん ちょっと一言いいですか？ Akky さん 2005年9月13日 無為徒食日記 2005年9月13日 真名垣 郁夫 さん 自ら誤りを正そうとしない人間は論外 Akky さん 引用のやり方と著作権 takopons さん 2005年9月14日 無為徒食日記 2005年9月14日 真名垣 郁夫 さん 面倒なので Akky さん 引用元は
変わらないURIこそがクール - 徒書
クールなURIは変わらないとはよく言われますが、この文章、そしてその題名の意味するところは、最も重要なのは変わらないことであるということだと思うのです。つまり言い換えれば、「変わらないURIこそがクールである」ということであり。 クールなURIは変わらないの後半部分ではURIの設計について述べられていますが、これはあくまで、これから作るウェブページやシステムについて、どんなURIにするかをあらかじめ考えるための指針であり、目的のための手段だと思うのです。目的はやはり「URIを変えないため」であって、これこそがクールであるために欠かせないものです。 クールなURIは変わらないを読んで、「そんなこと言われても、もう".html"とか"/cgi-bin/"が入ったURIでサイトを作ってしまったのにどうしたらいいのか」と嘆く人もいるかもしれません。しかし解決法は簡単で、ただURIを変えなければよい
fontプロパティはややこしい - 徒書
CSSのfontプロパティでは、フォントに関する複数のプロパティの値を一括で指定できますが、その書き方には結構ややこしいところがあります。例えば、 font-size: 1em; line-height: 1.5em; font-weight: bold; font-style: italic; font-variant: small-caps; font-family: verdana,serif; という指定を短く書こうとして、 font: 1em/1.5em bold italic small-caps verdana,serif と書くのは誤りです。何故かというと、font-style, font-variant, font-weightの値は、font-sizeの値より前に書く必要があるからです。文法上、font-size/line-heightの後にはfont-familyの値
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
object要素の使い方 - 徒書