インストールされているPerlモジュールはinstmodshで見れる - 徒書
Perlで、インストールされているモジュールの一覧を取得するには ExtUtils::Installed を使うとよいという記事をよく見かけていたので、自分もよくそのようにしていました。 新しいPerlに今まで使ってたモジュールをまとめてインストールする - 酒日記 はてな支店 cpan コマンドでインストールしたモジュールを調べる - Yet Another Hackadelic しかし本日、perlbrewでperl-5.12.2をインストールした後、bin/ 配下に置かれるコマンドをなんとなく眺めていたところ、instmodsh というコマンドがあることに気付きました。これを使うと、 $ instmodsh Available commands are: l - List all installed modules m <module> - Select a module q - Q
Nifty Cornersについて考える - 徒書
Nifty_Cornersに関する議論 - 徒委記 元記事であるNifty CornersはWeb標準にHTMLをcleanに保つことについても配慮しており、最終的には、HTMLに余計なマークアップを加えることをせず、角を丸くするのに必要な要素はクライアントサイド(ブラウザ側)でDOM(Javascript)を用いて加えるという手法をとっています。 But we love webstandards and semantic markup and we'd like to maintain the HTML clean and light. しかしながら日本語で紹介される過程で、DOMを使う部分が抜け落ち、HTML + CSSだけの部分が広まっていたようでした。そのためか、批判的意見でもDOMを使う点についてはあまり言及されていないように見えます。 個人的には「HTML文書には余計なマークア
最も画数の多い漢字とは？（XHTML + SVG版）
JIS漢字なら「驫」「鸞」（三十画）、新明解漢和辞典では [鹿/2鹿] （三十三画）が、画数の多い漢字であるが、実はもっと画数の多い漢字がある。 それがこの二つだ。 [2龍/2龍] 意味：言葉が多い [2興/2興] 義未詳 実に六十四画という強者だ。ギネスブックにも「最も複雑な書き文字」として載っていた。*1 初めてこの字を見た方は奇異に感じるだろう。それは我々が普段使う字に「同じ漢字を四つ組み合わせた漢字」というのがあまり存在しないからであろう。JIS漢字では多分、「綴」の右側の「又」四つ組くらいしか無いのではないだろうか。しかし大漢和辭典にはこういう字は沢山ある。例えば…… [2雷/2雷] 、 [2雲/2雲] 、 [2風/2風] 、 [2魚/2魚] 、等々。 変わったところでは [2林/2林] があり、「林が四つ」であるが、「木が八つ」とも言える。 （1997年11月14日） さらに！
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
text/htmlは非推奨か - 徒書
徒委記内に作っていたapplication/xhtml+xmlなサイトというリンク集で、「application/xmlとの併用」の項目に以下のコメントが付記されていました（10月13日19時14分09秒時点）。 SHOULD NOTであるtext/html よりも適切なapplication/xmlとのコンテントネゴシエーション 何が非推奨《SHOULD NOT》なのかが曖昧なのですが、解釈としては以下の2通りが考えられました。 text/htmlメディア型の文書が非推奨 text/htmlメディア型の文書と、application/xhtml+xmlメディア型の文書のコンテントネゴシエーションが非推奨 しかし、これらはどちらにしても正当な根拠のある主張とは自分には思えないのです。おそらくこれを書いた方（自分ではないです）はXHTML Media Types（邦訳）を誤解しているのではな
スマートキーワードでCSS 2.1仕様書を直接参照 - 徒書
CSS2リファレンスを引くためのFirefoxスマートキーワード - HM weblog Mozilla Japan - Firefox サポート - 使い方ガイド - 様々な Web 検索機能 を読み、自分もFirefoxのスマートキーワードを応用してみようと思いました。取り敢えずCSSのプロパティ名からCSS 2.1仕様書を直接ひけるようにしようと、以下のbookmarklet用スクリプトを作成。 javascript:(function(prop){ var url = 'http://www.w3.org/TR/CSS21/'; var index = { 'azimuth':'aural', 'cue':'aural', 'cue-after':'aural', 'cue-before':'aural', 'elevation':'aural', 'pause':'aural',
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仕様に従ったものではないかとの指摘あり。 なるほ
application/xhtml+xmlなサイト - 徒委記
application/xhtml+xmlなサイト text/htmlとの併用既に内容が無いもの application/xhtml+xmlのみ application/xmlとの併用 単独ページ 註 ページのメディア型にapplication/xhtml+xmlを使用しているサイト。 他にも見つけたら追加していって下さい。自薦も可です。 text/htmlとの併用 いろんな方法でコンテントネゴシエーションを使っているところ。 グランドウェブ！ファンキーヘタレ・ロード http://anoh.s10.xrea.com/ 閑古鳥 http://bluestar.s32.xrea.com/index.php breakaway http://breakaway.xrea.jp/ Quadrilateral space http://www.quadspace.net/ Mozilla Fire
div class="section" とXHTML 2.0 - 徒書
ADP: 角を丸くしたいネタ (1)に対しての哀さんのコメントより。 .section は hn と「常に」セットで用いることによる、来る XHTML 2.0 の section h 構造への移行準備を目的としている場合が普通ですので、 や、div class="section" を使う人皆が皆XHTML 2.0への移行を準備しているってことは、幾らなんでも無いだろうと思うのですが（自分も div class="section" は使いますが、XHTML 2.0に移行することは今のところ考えてないです）。 div class="section" を、XHTML 2.0のsection要素のように用いるという流儀は、「そうする人もいる」「そうすることで、文書をうまく階層構造化できる」という程度のものであり、「それが普通」というものでも、またそのようにしなければならないという規範的なものでもな
formに複数の送信ボタン - 徒書
１つのformで複数ボタンの配置 - masdoiの日記より。 １つのformで複数ボタンを作り、どのボタンが押されたのかをCGI側で判定したい場合があります。 ということでJavaScriptを使用したソースが例示されていたのですが、「複数ボタンを作り、どのボタンが押されたのかをCGI側で判定」という目的に適うものならば、以下のようにHTMLだけでごく簡単に実現できます。 <form action="" method="get"> <input type="submit" name="b1" value="button1"> <input type="submit" name="b2" value="button2"> </form> サンプルHTML サンプルのフォームは action="" method="get" としているので、ボタンを押すとHTMLファイル自身のURLにクエリ文
文字エンコーディングについて、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つの記述は矛盾というよりは、現時点に
Google AdSenseとHTML妥当性 - 徒書
CSSコミュニティスレの693(と、以前に552でも)で、StrictなHTMLでGoogle AdSenseを使うことの問題が指摘されており、自分も以前から疑問に思っていた点だったので言及してみます。 Google AdSenseでは、スクリプトにより以下のようなHTMLソースを挿入していることで、広告表示を実現しています(...は省略部分)。 <iframe name="google_ads_frame" src="..." marginwidth="0" marginheight="0" vspace="0" hspace="0" allowtransparency="true" frameborder="0" height="..." scrolling="no" width="..."><img></iframe> 一方、HTML 4.01仕様には以下の記述があります
cite要素はblockquote要素とは関係ない - 徒書
cite要素に関して、柊アマテルさんの見解を拝見したのですが、何となく違和感がありました。 cite要素を使ふ上でも要素間の機械的な関係は全く考へない方が賢明です。 という結論については同意なのですが、でもそれはもとからそういうものだったのでは、と思うのです。HTMLの仕様から見ても、cite要素はその前後のblockquote要素やq要素と関連付けて何らかの処理を期待するようにはなっていないようですし。 cite要素は――ありていに言えば――もともと英文の活字文書等で、引用を行う際に引用元の表題の部分を斜字体にする習慣があり、それをHTMLで表現(スタイルとしてではなく、より抽象的な構造として)するためにあるものだと思ってます。 定義語を示すdfn要素も似たような事情で、活字文書で言葉の定義が述べられるときには、その言葉が斜字体なり太字なりで強調されることがあったので、それをHTMLで表
WinIEでabbr要素を何とかする - 徒書
WinIEがabbr要素を理解しないことへの対応として、The Web Kanzakiで用いられいてたスクリプトを少し変更したものを使ってました（参照: 見よう見まねJavascript）。それで今まで動作上特に問題もなく、またinnerHTMLと正規表現を使ってソースを書き替えるという手法はスクリプトの見た目もすっきりしていて分かりやすいのですが、別の手段として、正規のDOM的手法を用いてなんとかならないかと考えまして、試してみることにしました。DOMの勉強も兼ねて。 やり方としては、abbr要素ノードからその子テキストノードとtitle属性を取り出して、それを新しく作ったspan要素に適用し、span要素を文書に追加する、という感じで行けるかなと思っていたのですが、実際にやってみるとabbr要素の子ノードが取り出せなくて躓きました。色々と試してみる中で、確認のため、 <abbr tit
CSSでよく使う装飾定義をclass名でまとめることについて - 徒書
2xup.orgのCSS でよく使う装飾定義をコンポーネントとしてまとめるという記事を読んだのですが、挙げられているHTMLの例を見てみて、「いやいやその方向性は無しでしょう」と思ったのでした。何故かといえば、 リストをインラインで表示するために <ul class="inline"> ナビゲーションリストをタブのように表示するために <ul class="tab"> という書き方をしていたので。それはつまり「文字を赤くしたいので <span class="red">文字</span>」というのと同じなのでは。 ADP: class=red スタイルシートの基本 -- ごく簡単なHTMLの説明 (「クラス名の考え方」参照) 記事では、 見た目を意識しすぎてしまっているのが気になるので class の名前を変更したり、 とも書かれているのですが、単にclass名を変更するだけでは状況は大差な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「CSSでよく使う装飾定義をclass名でまとめることについて」への言及 - 徒書