ラベル CSS の投稿を表示しています。 すべての投稿を表示
ラベル CSS の投稿を表示しています。 すべての投稿を表示

2015-01-14

ルビ on Firefox

ちょっと前縦書きの話を書いたので、次はルビの話でも。日本語で残さないとMozillaはやる気がないとか、変なこと言う人が日本には多いしね。

ルビについてもFirefoxでは開発チーム的にはは実装途中になっている。ルビの実装状況をみたいのであれば、Nightlyを使ってabout:configでlayout.css.ruby.enabledをtrueにすれば使えるよ。

例えば、こんな感じのHTMLは、

<div><ruby><rb>🍛</rb><rt>咖喱</rt></ruby></div>

以下の感じに描画される。


もちろん、以下のような感じでwriting-modeを設定すれば、

<div style="writing-mode: vertical-lr;">
<ruby><rb>🍛</rb><rt>咖喱</rt></ruby>
</div>

writing-modeが適用された状態で表示される。



CSS Rubyはまだほとんど実装されていないのだけど、デフォルト値のruby-align: space-aroundだけ動作する。

このバグをウォッチしているといろんなバグの修正がわかるはず。

今のところそんな感じ。自分が実装をやってないからどのバージョンでデフォルト有効になるかは知らないけど、2015年中には有効になると思うよ。

2014-11-22

Status of 縦書き on Firefox

今週とある情報筋よりMozillaは縦書きのレイアウトに反対しているから実装しないと言っているという痛い噂が流れているという情報を耳にしたので、現状の話を書いておく。

元々の縦書き (CSS Writing Mode) のスペックにはいろいろ問題があって、例えば世の中のどの言語であっても存在しないレイアウトが規格として存在してた (これは後に削除) とか、縦中横の時の文字のレイアウト (90度回転するかどうかとか) が決まってなかったとか (これは後にunicode.orgでTR#50としてちゃんと定義される)。そんな感じでまだstableではないという判断をしてて、もう少しstableな仕様になった時に実装を始めようということで内々の人たちでは合意が取れてたって感じだった。すごく中途半端な仕様で実装を始めても、それはCSS Flexboxみたいに間違った利用をする人たちを増やすだけだからね!

ということだったんだけど、今年になってある程度stableになったという認識になっていて、最低限のところ (実際には writing-mode プロパティ) の実装は始めるということでPlatform Teamの今年の目標になってた。

この縦書きレイアウトの実装に関しては、Gecko 36の開発サイクルの中で開発が大きく進んで、Nightly Buildのみabout:configでlayout.css.vertical-text.enabledをtrueにすればwriting-modeプロパティで縦書きを指定可能になった。

もちろんcontenteditableを使えば、こんなHTMLで縦書き編集も可能。

<div contenteditable="true" style="writing-mode: vertical-lr;">
私の名前は中野です
</div>


仕様があっても仕様がstableじゃないと実装ってのは進まないものなんだよってこと。リリース版でも有効になればFirefox OSでも使えることになるよ。

2014-08-22

この文字はカラー絵文字をつかうべきか、モノクロの絵文字をつかうべきか

Firefox 32でWindows 8.1でのカラー絵文字サポートが入っているが、今のbetaチャンネルで有効になっているので、こういうバグがファイルされた。

Bug 1054780 - Gecko picks Segoe UI Emoji over Segoe UI Symbols on Windows 8.1, leading to colored (and not-CSS-color-alterable) symbols

今のコードだとBMP外とSymbolのコードポイントの場合にSegoe UI Emojiの優先順位を上げているんだけど (該当する文字を持つフォントがCSSで指定されていない場合)、いくつかの記号がSegoe UI Emojiに含まれるから、これはカラーじゃないほうがいいんじゃないのって話だ。

これは好みが発生するところでもあるし、また、いろんな都合で逆にデフォルトがカラー絵文字になるほうがいいということもある (例: モバイル)。確かに、U+2xxxの文字はやりすぎなのもしれない。

ということで、CSS Fonts ModuleのエディタのJohnさんと議論をしたんだけど、そもそもCSSでコントロールすべきかもしれないよねってことで、Johnさんがこのような提案をするに至った。


ちなみに、議論中に日本の絵文字で存在してたアニメーションつきのフォントの場合にアニメーションを止めるとかをどうするんだという話に派生したけど、それは今回の議論には入れない。

2012-12-14

SVGの次のお話

来年の1月か2月のオーストラリアのF2Fミーティング以降にたぶんSVG 2.0のワーキングドラフトが更新されるらしいんだけど、今日はそれのお話。語られることないんで書いてみる。

HTML5だCSS3だって話がいろいろ聞かれるけど、SVGもやっと2.0の話がぼちぼち出てきてる。SVG自体は元から日本人とかが絡んでるってのをみんな知らなかったりする。キャノンの藤澤さんが元々仕様策定に絡んでいたりしたんだけど、2.0だとKDDI(もちろん日本のね!)が仕様策定に絡んでたり (次の更新の際にはエディタに入るんじゃないかな?)。

SVG 1.1とかを制定したときと比べて今一番違うところは、HTML5やCSS3を通った後ってところ。現在の状態だと、CSSとSVGで被っている機能が増え始めてる。たとえばアニメーション (SVG Animation vs CSS Animation) とかフィルタ (SVG Filter vs CSS Filter) とか。こういう被っている機能ってのは、ブラウザ作ってる側にとっても実装コストが面倒だし、それよりもWeb開発者にとってはもっと面倒臭いよね。

そもそも同じW3Cで決めてる規格なので、こういう被る機能 (FilterやTransform、Animation) に関してSVG側とCSS側とで共同チームが組まれてて、FX TaskForceってのが該当する。そもそもSVG Working GroupのメンバもAdobeとかMicrosoftとかGoogleとかMozillaとかがいるし、同様にCSS Working Groupもだしね。

一例としては、アニメーションなんかはWeb Animationと呼ばれる規格になってく。これは、規格作ってるBrianのインタビュー(英語)でも参照してみてね。こういう被るような仕様に関しては両方で共通化できる仕組みにすることを考えてる。

なので、たとえばCSS Filterの動作サンプルを見てると、WebKitで実装されたCSS FilterがOperaとかMozillaがいつ実装するのかどうかってみんなは思うかもしれないけど、現在のあの仕様がそのまま全社が実装するとは思えない。FX TaskForceの活動の結果、共通化されたFilterの仕様が新規に決められることになるので、それを各社が実装することになる。そうしたほうが覚えるコスト少なくていいしね!

SVG2らへんの話は矢倉さんあたりが書いてくれるとうれしいなと思うけど、守備範囲だっけ?

2012-05-30

word-break: break-all が Firefox 15でも使えるわけだが

word-breakプロパティがFirefox 15で実装された (というか、コード書いたの自分だし、放置したのも自分) んだけど、ちょっと別件でテストケースを書いてて、面白いことに気付いた。

元々のテストケースは、http://mxr.mozilla.org/mozilla-central/source/layout/reftests/text/wordbreak-4a.htmlなんだけど、WebKit (テストしたのは、WebKit Nightly r117392 と Chrome canary 21.0.1155.2) だと、ハングル語が分割されて表示される。

意味が分からないと思うから、まずはInternet Explorer 9。


WebKit Nightly。


まぁ、break-allなんて使うなってことですよ。ハングル語とか結合文字列を使う場合にはね。。。ってか、これでいいのかハングル語圏ユーザー。

2011-06-25

text-overflowの仕様が複雑になってる話

Firefox (7ね) でもtext-overflow: ellipsisが実装されたわけだけど、text-overflowのスペックがcss-uiに移った関係上、Tantekがいろいろなことを細かく追加してくれてる。それらの話は勝手にTantekが書いたわけではなくて、いくつかの議論が過去にあったことをちゃんと反映したということが事実でもある。

でさ、IE9が出たときに一番感心した点でこのtext-overflowの実装がちゃんと最新の話を追従してきてたというところ。最新の仕様でちゃんと定義されたものの一つとして、スクロール時の動作ってのがあるんだ。

<div style="width: 5em; text-overflow: ellipsis; overflow: scroll;">
  AWESOME
</div>

こんなCSSがあるとすると、スクロール可能な状態でかつ省略文字(...)がつく状態になる。で、スクロールしたらどうなるかというと、ちゃんとスクロールに追従して、"..."を表示する場所を変えなければいけないってことになったんだ。で、これを最初にちゃんと実装したのがIE9だった。で、複雑すぎるテストケース (rtlにしてみるとかいろいろあるよね!) を書いてみてもIE9はまともに実装されて感心した。

ちなみに、ちゃんとOpera 11.50ではこの仕様にちゃんと追従してて感心した(けど、rtlになったとたん破綻する話は相変わらずだったけどね)。

これFirefox 7でもちゃんと実装してあるんで、最新仕様に追従してないのはWebKit系だけっていうことになるんだけど、これってもうWebKitの最新版で追従できてたっけ?

2011-03-11

初心者が陥りやすいCSSの間違った理解

一瞬気付かなかったけど、こんなCSS書いて、Chromeしか動かないと言っている人がいるらしい。まさに間違い探しだね!

#transformSample img {
-webkit-transform: rotateY(0deg);
-webkit-transition: -webkit-transform 0.5s linear;

-moz-transform: rotateY(0deg);
-moz-transition: -webkit-transform 0.5s linear;

-o-transform: rotateY(0deg);
-o-transition: -webkit-transform 0.5s linear;
}
#transformSample a:hover img {
-webkit-transform: rotateY(180deg);
-webkit-transform-origin: 50% 0;
-webkit-transition: -webkit-transform 0.5s linear;

-moz-transform: rotateY(180deg);
-moz-transform-origin: 50% 0;
-moz-transition: -webkit-transform 0.5s linear;

-o-transform: rotateY(180deg);
-o-transform-origin: 50% 0;
-o-transition: -webkit-transform 0.5s linear;
}

なんか、これ書いた人、マークアップエンジニアって名乗ってるらしいけど、たぶんその会社は人が多いから、その人はHTMLしか書けなくて、別にスタイルシートエンジニアってのがいるんだとオレは信じてる!

2010-11-26

困った人たち - CSS WG編

最近、提灯記事とか読んでて、分かってない人たちが多すぎなので、実際の話を書こうと思う。CSS縦書きのホントの話。

publickey (この人も何も分かってないっていうか、Webメディアの人にちゃんとしたジャーナリズムを要求するのは間違ってるのかもしれない) とか見てると、彼らは日本のために頑張ってるなぁ、なんでCSS WGの動きが遅いんだろって思えるかもしれないけど、実際は、全くもって話が違う。

一番重要な点は、推進しようとしている人たち (困ったことにエディタ張本人) が、requirementとconvenienceの違いを分かってないってことなんだ。

まず、なんで話がずっと進まないかというと、エディタが論理プロパティと物理プロパティの話にこだわりすぎてる (このループで約半年以上かかってて、まだそのループ中なんだよ、実は!!) ってこと。一番重要なのは、彼の意見では、"これがあると便利だ"という話をしているんだけど、そもそも"便利"であって、"必須"ではないんだ。

で、必須な話 (writing-modeを変えるとCSSの各プロパティに影響を与えるから、どう与えるのかをちゃんとSpecに入れるとかってこと) が一切議論出来てないんだよ、マジで。必須な話が片づいた後にその話 (便利な機能の話) をするんだったら、全然いいんだけどさ、必須なことをないがしろにしている状況なんで、話が進むわけないじゃん。

また彼らの話では、XSLではこう出来るのになんでCSSだとダメなの!なんて話をしてるのを聞いたことがあるんだけど、だったら、EPUBでXSL使えばすべてハッピーになるんじゃない?ってこっちだって思うよね。EPUBの論理をCSSに持ち込むのは違う。EPUBのためにCSS作ってるわけでもないし。

あとさ、CSS WGはIRCミーティングとかを定期的にやってるんだけど、そこに日本人のエディタが参加してるんだが、彼はIRCでほとんど発言しない。tate-cho-yokoの話をそこに参加している日本人が話さなくてRichard Ishidaが説明してるような状況。ミニッツログ見てて、ウケる状況だよ。"お前の番だろ、そこ!"ってさ。

そもそもエディタの仕事ってのは、みんなの意見をまとめて、合意を取ることであって、自分の考える仕様を推し進めることじゃない。HTML5のエディタのIanのやり方を見れば分かるけど、彼の所属会社 (Google。彼は元MozillaのCommitterだったり、前はOperaにいたりする人だけどさ) の意見を推すことはそんなにせずにコンセンサスを取ることに終始しているよね。だから、みんなが活発にいい物を作ろうと考えるんだ。反対意見を言ったからって、罵倒するようなことをすることはないしね。

でさ、ここからは、ちょっと話を変えて。

どうも政府の仕分け対象に電子出版関係が入ってたようで、それが対象に確定した後に、焦ってる人がこんなメールをwww-stylesに投げてる (名前は伏せておくけど、アーカイブ見れば分かるけどさ)

Some Japanese now point out that the CSS writing modes is not 
yet a FPWD even after the TPAC, and claim that Japan should not 
use CSS writing modes for E-book but rather use XMDF, DotBook 
(should not be confused with DocBook), or an upcoming "Japanese 
intermediate format" (supported by the Japanese government as a 
candidate for an IEC standard) in the near future at least.

これ見て、こっち的にはさぁ、いろいろと勘ぐりたくなるわけじゃん。そもそもそんなことメールすべきじゃないし、議論の場でしょ?ってことで。こんなメール書きたくなるじゃん(実際出しました)。

This is CSS WG, not EPUB WG.  Although CSS writing-mode is necessary
for some languages, I think that we need more discussions for agreed
specification.  If EPUB wants something like the XSL specification,
EPUB should use it instead of CSS.

Also, I look that your claim is a Japanese government / business
issue.  I think that CSS is for Web.  Web isn't the replacement of
paper media.  Of course, it is wonderful that EPUB uses CSS.

You should do the productive discussion instead of sending claim mail.

てか、焦ってそんなメール出す暇があったら、必須な項目についての議論を英語でしろ。日本語でツイートしたりブログエントリ書いてる場合じゃないと思うけどね、マジで。文句があるんだったら、日本語でツイートするんじゃなくて、www-stylesメーリングリストに投げろって。

というのが、本当の実情。議論が進まないのは、ただ単にCSS WGのせいじゃなくて、エディタ達の問題によるところが多いだけなんだよ。笑えないでしょ?

2008-09-10

word-breakの各ブラウザの実装

word-breakというCSS3 Textのドラフト (W3C Working Draft 6 March 2007) に入っているプロパティがあるのだけど、そのプロパティの各ブラウザの実装の違い。

このプロパティ自体は、Internet Explorerで実装されて、その後CSS3のドラフトに入ったもの。現在の WebKitでも実装されている。Firefox (Gecko) は、自分がバグオーナーで、コードのテスト中。

そこで各ブラウザの実装 (looseとbreak-strict以外) について調べてみた。

Safari 3.1 (WebKit)

日本語(CJK)はまったく考慮していない。WebKitは、IBMのicuライブラリを使ってラインブレーカーを行っていた記憶があるので、それに手を入れることはしていないんだろう。(Carbonにラインブレーカー用の関数があったのにそれを使ってないってところがAppleらしい)

Internet Explorer 7 (Trident)

これも変な動き。word-break: keep-allの時に読点では改行するのに区点では改行しない。句読点で改行すべきかどうかは、暗黙的な改行 (implied break points) ではない気がするから、微妙なんだが、どっちかに統一してほしい

どっちも微妙な実装だということはわかった。