ネタが無いので小ネタをひとつ。
Personal Toolbar上のアイテムをドラッグ中にCtrlキーを押すと、 ブックマークを移動ではなく、コピーすることができます。
また、Personal Toolbar上にあるフォルダでShiftキーを押しながらドラッグを開始すると、 フォルダも移動、コピーできます。
Personal Toolbar上にコンテキストメニューから新しいフォルダを作成し、 Shift + ドラッグで別のフォルダへ移動することによって、 通常はPersonal Toolbar上では作れないサブフォルダを作ることができるので便利です。
以上。
気が付きませんでした、今の今まで。 XMLでは空白類が減っているのですね。 ところで何故0xA0は空白類に含まれていないのか、前々から不思議なのですが。
CSS2の場合は、
らしい。
そういえばCSS3仕様書の中にはNBSPが直接記述されているものがありましたが、 海外のPCでISO-8859-xの0x80以降の文字ってどうやって入力するのでしょうか?
機種依存文字、と呼ばれるローマ数字ですがこのページでは多用しています。 苦情が特に来ていないのでMacやLinux等でも問題なく表示できているのでしょうか?
このページは、UTF-8で記述していますので ローマ数字(注意:リンク先はPDF)を直接HTMLで記述しても機種依存ではありません。 そのため、このページでは商品名に合わせるために使用しています。
未だに多くの人が勘違いしているようですが、 機種依存文字の定義そのものがUnicodeの普及によって昔とは変わっています。 例えば他にも以下の文字はUnicodeには存在します(つまり、理論上これらの文字は使える)。
ちなみに矢印も色々あるので例えば、 ブレイクスパイラル: ←↙↓↘→↗↓と、格ゲーのコマンドも画像無しで書けます。
しかし、Unicodeフォントが必要なのでどのみち環境依存には違いありません。 ですから使うことを推奨しませんし、使わない方が無難と言えます。
ところで、ローマ数字は機種依存文字なのでアルファベットで代用すれば良い
と主張しているページもたまに見かけますが、これは間違いです。
例えばローマ数字でⅢと書けば、音声ブラウザはさんとかスリーとか読み上げることができます(実情は知りません)。
しかし、アルファベットで代用してIIIと書くと、あい、あい、あいとなってしまいます。
また、検索エンジンでも3と三と３とⅢと③などを同一の文字と見なした検索も可能でしょうが、
これにIIIを含めるかどうかは難しいところでは無いかと思います
(技術的には可能ですが、処理効率がよくないですし、なにより検索精度に問題がありそう)。
どのみち、代用なのですから、見た目のために文章の意味が変わってしまっているという点は間違いありません。
要約で全て説明してしまった。
Windows2000以降のこの挙動自体知らなかった。
本家への報告から1日で修正されてしまったので、詳しい紹介は無し。
一度修正依頼を小池さんが送信したものの、 中途半端に対応されたため、 ページの内容の変化と共に再発してしまった問題。
もう何度もあちらこちらで言ってることですが、 内容にテキストを含む場合、heightプロパティを使うべきではありません。
テキストは表示のされ方が環境依存です。 文字の大きさ、形等。 文字の大きさが変われば、同じ幅の要素でも折り返し位置が変わります。 そうなれば当然、その要素に必要な高さも変わってしまいます。 そしてあふれたテキストは次の内容と重なって表示されてしまいます。
ちなみにフォントサイズを固定し、訪問者に強制することができると考えるのは、 InternetExplorerという今、最も有名で デキの悪いブラウザ しか使ったことの無い人の幻想にすぎません。
日本語の場合、文章の途中で改行してしまうと、ブラウザ上でスペースがあいてしまう。 だから私は <p>タグの中は原則改行を入れないことにしている。 今のところまだ様子見といったところ。
気持ちは分からなくもないんですが、これはMozillaとOperaのバグなんですよね。
HTML4.01の仕様書には次のようにあります。
テキストのレイアウトには、語と語の間にスペース(語間スペースと呼ぶ)を挟むことも含まれるであろうが、 語間スペースの取り扱いは用字系毎に異なる。 例えば、ラテン文字では、典型的語間スペースはASCIIスペース( )だが、 タイの用字系ではゼロ幅単語分離 (​)である。 日本と中国の用字系では、語間スペースは典型的には全くレンダリングされない。
それでも、実際問題として色々とややこしい点があったのですが、 CSS3で次のよう記述することで解決できるようになります。
:lang(ja){
linefeed-treatment: ignore;
white-space-treatment: ignore;
}
そろそろこのバグも挙げておいた方が良いんですかね? > 関係各位
:target疑似クラス等の後に隣接セレクタを使うと、隣接セレクタが機能しない。
メニューがぐちゃぐちゃに重なり合っているという問題。
見た目の問題は
Bug 3186
と同じく、インライン要素にwidthを指定しただけでdisplay: block;を拡大解釈で適用してしまう、
某駄目ブラウザでしかテストしていないことが原因。
ただ、Mozillaのバグなのか一番上のメニューがセンタリングされないという問題が残っている。 もう少し詳しい検証が必要だ。
それからもうひとつ、a要素中のinput要素の挙動。 Mozillaはa要素中のinput要素をクリックした時点、 例えばこの問題のようにドロップダウンリストをクリックした時点で、 a要素をクリックしたことになってしまう。 これはHTMLの仕様のバグと言ってしまって良いと個人的には思うのだが、 UAの挙動はどうあるべきなのだろうか。