Top > CSS

FlexboxがLCに: プロパティ名などもろもろ変更

W3C CSS WebKit IE Chrome
タイトルの通りで、FlexboxのLCが公開。

LCは喜ばしいんだけど、なんせTabせんせやfantasaiせんせがEditorなので、政情不安定というか変なところで変更が毎回ある。

というわけで、今回はプロパティ名や値が変わった。計画だったようだけれど。

これまでかわったの
flex-align align-items
flex-item-align align-self
flex-line-pack align-content
flex-pack justify-content
flex-order order
flex-pack: start
flex-pack: end		 justify-content: flex-start
justify-content: flex-end
display: flexbox
display: inline-flexbox		 display: flex
display: inline-flex

一部のプロパティがalign-*となってるけれど、これはBox Alignmentというモジュールのプロパティに移して、FleboxではFlexboxに関係する値を追加するかたちにしたから。

で、仕様が変わるだけならまだいいんだけど、WebKitのほうですでに名前が変更されている。

そしてもうChrome 21から取り込まれている。エイリアスもないようなので、pre-LCWDバージョンのプロパティを使ってる場合は書き換えるなりしないといけない。エイリアスがないのはなんでだろう。Safariが実装してないからかな。

しかし『古い』「あたらしいFlexbox」を実装しているIE10は、だいぶタイミング悪くRC的なフェーズに入ってしまった。ふつうに考えると、RCからの変更は望めない。うーん。

それで、「あたらしいFlexbox」がふたつできてしまので、Modernizrでどうしようかって話をしている。さすがにModernizr.flexboxnewlegacyとか導入するのはねえ。

SafariがWD版のFlexboxをリリースしたらさらにカオスになるけど、どうなんだろう。

追記 (2012-06-15)

Modernizrでは、flexWrapをチェックするように変更。pre-LCWDとLCWDのバージョンを見分ける必要性があるのかってところから、LCで変わってないプロパティを選んでチェックすることに。

追記 (2012-07-10)

orderがさらに別の名前に変わることになった。

orderはその名前通り順序に影響するプロパティだけれど、変わるのは視覚的な順序であって、タブフォーカスの順序や読み上げの順序には影響しないというのが理由。

追記 (2013-08-12)

おおっと、追記＆編集してなかった。
結局その後すぐ、orderはそのままになることが決まった。

Resolved: For Issue 4 the order property is not renamed to better indicate that it only affects visual rendering (and not speech or tab-order) because it’s too late in the process and the WG doesn’t know of a significantly better alternative.

理由として、あくまで見た目の順序を変えるだけで、読み上げ順序やタブのフォーカス順序には影響しないこと、そして、もうプロセス的に遅い段階に入ってるし、いい名前も思いつかないからと。前者はなんかとってつけた理由な感じだ……

Transitions, Transforms, Animationsの接頭辞が省けるようになった

CSS W3C

昨晩というか今朝のCSS WG Teleconにて。

Resolved: Transitions, Transforms, and Animations may be released unprefixed.

IE10PP6でなぜだか接頭辞省いたバージョンも実装されたというのもあって、とりあえずAppleのVisual Effects 3仕様については接頭辞を省いてもよしとなったらしい。Animationsはうれしいね。

今回のはいちおう、Microsoftの行動を受けての決定らしいので、接頭辞に関するポリシーが変わったというわけではない。ただ、4月末からいろいろあったので、もうちょっと前進するんじゃないかと思いたい。

テストケースやドラフトのレビューやらはこれからだし、大きく手を叩けるわけではない。あと、IE10の実装がボロボロかもしれないということも否定はできない。まだRTMではないようなので、少し猶予はあるだろうけれど。充分なレベルになっててほしい。

あと、今後の取り組みも大事。CSS 2.1のときみたく、各ベンダーが挙動をどれくらい合わせてこれるかで、開発者が幸せになれるかそうでないかが変わってくる。

まあでもIEよりSafari

ただ、IE10で接頭辞が省かれても、あまり影響がないのかなと。というか、Safariがこれをやってくれないとしょうがない。

これまでのサイクルから考えると、次のSafari (5.2?) はWWDCあたりで発表されるだろうし。なので接頭辞を省いた実装がそれに載るなんてことは望めない。

で、デスクトップより重要なのが、iOS。次のバージョン (iOS6?)のSafariが使うWebKitのブランチが切られるまでに、WebKitが接頭辞を省いてくれないと、再来年くらいまでは-webkit-の面倒を見ないといけなくなる。

CSS3 Image ValuesがCRに

W3C CSS

「ようやくか」という声はぐっとこらえて。css3-imagesがついにCRに進むことが決まりましたよ。

Resolved: Publish CSS3 Images as CR

というわけでグラデーションの構文から接頭辞が消えますよと。

ただ、現状の仕様に即した実装をしてるのって、たぶん完全にない。Firefox 10とOpera 11.60ではlinear-gradient()のto bottomなんて記法に対応したけど、degの解釈は前のまま（0degが右）だったりする。接頭辞付き実装に依存したコンテンツとの互換性を考えてあえてそうしてるだろうはずなので、接頭辞のないものは角度の解釈が変わると思う。radial-gradient()の変更には、まだどこも追従してないんじゃないかな。

接頭辞を取れる最低段階に達しただけで、実装しないといけない。例年通りならSafariのリリースが6月に控えてること、IE10も今年とうわさされてるので、けっこうシビアなタイミングだと思う。ただ、ここで接頭辞なしの実装をどちらにも盛り込んどかないと、面倒な事にはなりそう。「グラデつかなくても、まあプレーンな背景色でいいよ」的な空気にみんななればいいよ。

あ、そういえば、今回のCRはグラデーションから接頭辞をなくせキャンペーンなので、実装に乏しいelement()とかはすでにLevel 4へ回されることが決まっていたりする。待っていた人は残念。

Responsive imagesのための-webkit-image-set()

WebKit CSS Safari

AppleがWebKitに-webkit-image-set()なるものを実装した。

なにかというと、Retina displayやらPCとデバイスピクセル比が違うディスプレイに対して、違う画像を出し分ける、いわゆるResponsive imagesと呼ばれてるやつのための仕組み。

こんな感じで書くらしい。

selector {
  background: -webkit-image-set( url(foo-lowres.png)  1x,
                                 url(foo-highres.png) 2x ) center;

image-set()内には複数の"imagespec"というものが入る。imagespecは<image>（画像、グラデーションでもいい）に続けて、nxという表記で倍率を書いたもの。対応しているブラウザは、高密度なディスプレイには“2x”な画像（foo-highres.png）を、これまでのディスプレイには1xな画像をという風に出し分けることができる。

メディアクエリーとどう違うのか

出し分けるとなるとメディアクエリーとどう違うんだという話になる。この機能を提案したAppleのEdward O'Connorにはこういう考えがあるらしい。

Here are just a few of the problems with the current situation:

  • Bugs due to non-locality: One developer fixes a bug in the selector, but only in the low-resolution case. Another developer changes an image reference to refer to a different icon, but only in the high-resolution case.
  • Both assets may be loaded by the browser, which may degrade performance in a constrained bandwidth environment.
  • Authors can't specify both assets inside a style="" attribute.

メディアクエリーだとセレクタが多重になるので管理性が懸念されること、使わないもう片方の画像が読み込まれてしまう可能性があること、style属性でつかえないこと、この3つがいくつかある問題として取り上げられている。

あと、image-set()で出てきそうな質問にもすでに答えている。

Why a scale factor and not a full-blown media query?

Media queries are a claim about the state of the UA, whereas here we're making a claim about (the relationship between) the image assets themselves. It would be confusing to use similar syntax for such different things. Also, UAs should have the ability to choose between the given variants based on a variety of factors. For instance, a UA could use the lower res asset when a user has zoomed out. No existing media query distinguishes between the page being zoomed-out and being zoomed in. And even if such a media query existed, UAs should be free to choose between variant assets regardless of which media queries happen to match.

MQを使わず2xなんて倍率を使う理由は、MQがUAの性質について何かするという考えのもと作られてるのに対し、こっちは画像自体について言いたいと。なので違う構文のが間違わなくてよいだろうと。あと、UAの性質（デバイスピクセル比とか）だと「どちらか」になってしまうけど、image-set()はたとえば、ズームインしたときは解像度の高いものを選ぶとか、そういう利用も考えられているらしい。

ズームインとかを考えると、たしかにmedia featureとは言いづらいかもね。

The problem of stylesheet verbosity when using media queries isn't limited to image assets. Shouldn't we have a general mechanism for keeping media-specific property values together in rule sets?

In talking with content producers here, we've found that the non-locality of asset references is a real source of Web author pain. I think a focused feature to help with that pain is sensible. That said, we should also explore how to help authors avoid selector repetition and the other pains of @media in general.

image-set()っていう画像だけのやり方じゃなくて、もうちょっと一般的なことにできないのという点については、まずアセットの参照が一箇所にないことがかなり手間ということが分かったので、その解決にフォーカスした機能にしたと。一般化については、セレクタの重複や他にもあるだろうMQの問題について、いま一度どんなことができるか調査すべきだと。

Why not enhance the image() function instead of inventing a new function?

Unlike image(), these image specifiers are unordered. This isn't about fallback. There is no preferred variant. UAs are free to use whichever image it believes would be best. For instance, consider the page zoom example I mentioned earlier. Authors could even use image() and image-set() together to handle more exotic cases, e.g.:

image(image-set(url(foo.png) 1x, url(foo@2x.png) 2x) rtl,
      image-set(url(bar.png) 1x, url(bar@2x.png) 2x) ltr);

css3-imagesで提案されてるimage()を使わないのはどうしてかと。これは、image()がフォールバック目的で、また値の順序が影響するのに対して、image-set()はズームなんかの状態に応じて画像を選べると。

ふむ。

image()でなんとかできないのか

ズームとかそういうのはわかったんだけど、image()とは別というのは、なんだかね。まだ実装もないし、定義を変えてしまえばいいだけのような気もするんだけれど。

というわけでcss3-imagesのEditorのTab先生とちょっと議論している。ただ読む限り、Ted (Edward)はあくまでimage()はフォールバックのためとしておきたいという気持ちが強いようで。Tabがそのあと、image()のリスト中にスラッシュを入れて、それをimage-set()の代わりにしてはどうだという提案をしているけれど、とくに返信もなくという状態。こっちのが好きかなあ。

Retina時代の準備かねえ

実装されたのはさっきだけれど、やっぱり裏にはRetina display対応が絡んでるんだろう。今WebCoreに入れば、Safari 5.2の正式版に反映されてもおかしくないタイミングだし、iOSの次のバージョンにも取り込まれることは間違いない。

LionでHiDPIモードが進んでたのもあるし、OSXでもそのうちRetina display搭載のデバイスが出るんだろう。そこで多分使ってくるんだろうねえ。

そうなると、気になるのがHTML側ではどうするかということ。CSSではimage-set()ができたけど、HTMLにはそれが無いので、The new iPad™なページはXHRで2xな画像に差し替えてるなんてことをしている。

で、さっきのTedのメールに、こんなのが。

What about content images?

First off, this is www-style, so the design of an HTML feature for responsive <img>es is out of scope. :) That said, I can imagine the image-set() microsyntax being used in an attribute like so:

<img alt="A description of foo"
     src=foo-lowres.png
     set="foo-lowres.png 1x, foo-highres.png 2x">

I'll post something to the whatwg thread referencing this proposal.

とまあ、www-styleだからって提案ではないとしときながら、<img src=... set=...>と、属性を追加するかたちで提案している。後方互換性を考えると、srcの拡張は現実的ではないし、ズームイン/アウトのユースケースを考えると別の属性にしかならないだろう。<object>は禁句。

WHATWGになんかポストするとあるけれど、現時点ではとくにそんなメッセージはない。ただ今週あたまにCanvas APIにデバイスピクセル比やら高解像度用のImageDataやらが欲しいという提案をしている。

というわけで、来るんじゃないですかねえ。

-moz-border-radiusと-moz-box-shadowが削除された

Mozilla CSS

Geckoから-moz-border-radiusと-moz-box-shadowのエイリアスが削除された。
Firefox 13でこれらが無視されることになる。

Mozillaは接頭辞に関して、正式なプロパティを実装したら接頭辞付きの実装を削除するというポリシーをもっている。ただ、border-radiusなどずっと前からあったプロパティについては、削除のタイミングが先延ばしに（たぶん）なっていた。昔だと、opacityを実装してからも少しの間-moz-opacityが残っていたような気がする。

Firefox 4で正式なプロパティが実装されてから1年くらい。ついにかー。うん、でも他のブラウザも接頭辞なしで実装してるし、そうだよねえ。

これがWebKitだったらちょっと厄介で、というのもiOSが接頭辞なしのborder-radiusをサポートしたのがiOS4, box-shadowにいたってはiOS5なので、けっこう-webkit-だけなスタイルシートがあると予想される。ChromiumのUIで使ってるCSSでも、-webkit-box-shadowを使い続けてたりとかあるし。
なんだろう、依存するような違いがあるんだろうか。って、MozillaもUIのスタイルシートで-moz-プロパティ使い続けてたのか……

どちらにせよ、WebKitはエイリアスとしてサポートし続けるという方針があるから、サポートの点では問題ないんだけど。接頭辞をさらに意味無くしたっていう問題はあるけどね……

さて、どれくらい影響があるんだろう。-moz-border-radiusはかなり長いことあったはずだから、それなりにありそう。といっても、角ばって影がなくなるってくらいなので、それを影響と言ってもなあという気はする。ドラえもんとか、絵を描く系のデモで接頭辞に依存してたりなんかする場合は、問題かもしれないけれど。

しかし、グラデーションやら2D Transforms, Transitionsに関して同じポリシーを適用できるんだろうか。ここらへんはエイリアスとしてサポートし続けないといけないのかなあという気もする。

追記 (2012-03-20) Aurora 13が出たので試してみた

Unknown property '-moz-border-radius'. Declaration dropped.と、わからないプロパティ扱いされている。

Web Consoleでこういうのが出るのは便利ですね。書き間違えとかもわかりそうだし。

GeckoでCSS3のbackground-positionがサポート (残すはWebKit)

CSS Mozilla

「CSS3のbackground-position」というのがポイント。

CSS3のbackground-positionでは、bottom 10px right 10pxみたく、基点付きでlengthを指定できる。これまでは左上に固定されていたので、たとえば右下に画像を置きたいんだけどべったり右下ではないときとかに困ってた。percentageを使えばなんとかなるけど、計算が面倒。CSS3でこれが解決できる。

で、Opera 11+とIE9+で実装されてて、FirefoxとWebKit勢で使えない状態だった。Geckoで実装されたので、残すはWebKitになる。去年パッチが投げられたんだけどそれが難有りで、その後もアップデートがなされずといった状態。

なので、まだ使いづらい…

background-imageのサブプロパティが実装されたりと、B&Bの機能は去年の秋くらいから前進している。全ブラウザ実装となるとまだちょっと遠そうだけど、勧告の条件はけっこう早く満たせるのかもしれない。いや、そうでもないかな…

CSS WG Paris F2F ― 他のベンダー接頭辞（の一部）などをエイリアスとして定義する提案

CSS W3C

そういえばCSS WGのF2Fだった。minutesを読むとすごいことが書いてある。

Vendor Prefixes

Discussed problem of WebKit monopoly on mobile and the consequent pressure for other engines to implement -webkit- properties. See also Tantek's questions at https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology

Aliasing

Aliases are used both for vendor prefixed / unprefixed property pairs as well as for the word-wrap/overflow-wrap property and for the page-break-* properties (which are aliased to break-*). We discussed what, exactly, aliasing means:

  • RESOLVED: When a browser supports multiple syntaxes of a single property, they're treated as aliases in the cascade, such that last wins. In the OM, *all* variants show up, with equivalent values, regardless of which version was specified or which won.
  • RESOLVED: The last resolution applies to WG-approved aliases. It MAY be used by browsers for handling prefixed versions as well.
  • RESOLVED: When value aliases are supported, return the version that the author provided.
  • RESOLVED: In media query feature strings, also return the version that the author provided.

まずは、-webkit-HTML5化が著しいモバイルについて、他のベンダーが-webkit-な機能をも実装しないといけない空気になってきてると。で、互換性を向上させるために、一部のクリティカルな接頭辞つき機能を他のブラウザでも実装できないかと。その方針について、議論になってるのかなってないのかわかんない話が。

そこから、機能のエイリアスについて。resolutionによると、ベンダー接頭辞つきプロパティや接頭辞なしのプロパティの一部（page-break-*など）でエイリアスを利用できるようにすると。

エイリアスの詳細はこんな感じ。

  • ブラウザがあるひとつのプロパティに対し、複数の構文を実装する場合、継承においてそれらはエイリアスとして扱われる。すなわち、最後に登場したものが適用される。いっぽうOMでは、対応する値を含んだすべての構文が現れる。これはどの構文が使われたか、どの指定が適用されたかを問わない。
  • この仕組みは、CSS WGが認可したエイリアスに対して適用される。ブラウザは、この仕組みを接頭辞つきの構文に対して利用してもよい（MAY）。
  • 値のエイリアスがサポートされたとき、製作者が提供したものを返す。
  • MQのfeatureの場合も、製作者が提供したものを返す。

これはこれで既存コンテンツとの互換性のために必要とは思うけれど、接頭辞にこだわる理由が、やはりよく分からない。ある機能が安定しているかしていないかどうかは、名前じゃなくて実際に試して知ることが多い。古い実装があっても、HTML5のように、過去のものと互換性をできるだけとる形で標準化できないもんだろうかねえ。

しかし、ログを読んでみたらだいぶ長かった…

接頭辞の議論

tantek: This is a specific subtopic of vendor prefixes

tantek: The problem statement right now, and this is a problem for Mozilla and any other non-WebKit browser

tantek: Sites have webkit-specific content, and serve backup content to everyone else. Specifically for mobile content.

tantek: Non-WebKit browsers face prisoners dilemma

tantek: similar to quirks in 2003 or so

tantek: At this point we're trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla

plinss: Zero.

tantek: Currently we have zero. Zero is no longer an option for us.

Florian, Sylvain: Zero is not an option for us anymore either.

Mozilla (Tantek)のZero is no longer an option for us.に対して、Opera (Florian), Microsoft (Sylvain)もZero is not an option for us anymore either.と。

試験的な実装についてベンダー接頭辞をつけるってしくみが、もう破綻している。

tantek: We don't consider this a long-term situation. The goal is to open up the webkit-specific part of the web to others, same as implementing parts of IE-specific web.

XHRやら、HTML5はそういうアプローチをとっている。接頭辞システムが出来る前の独自拡張を標準化してるので、接頭辞つきほど話がこじれはしないんだろう。x-vendor-attributeなんて仕組みもあるけど、かなり強く使うな的なことが書かれてもいる。Googleが2つほど導入してるけど。

plinss: You said this is a short-terms solution. Quirks mode was supposed to be a short-term solution.

tantek: No it wasn't.

plinss: Yes it was.

plinss: I implemented it before you did.

plinss: The intention was to solve a short-term problem. It was supposed to be gone in a few years. We're stuck with it.

plinss: If we open this Pandora's box, we're going to be stuck with it.

plinss: If people implement other vendor prefixes, then everyone will implement others prefixes and we'll be stuck with it forever.

別のベンダーの接頭辞付き機能を実装してしまうと、そこから逃れられないんじゃないかという指摘。機能に寄りそうだけれど、Apple拡張のAnimations, Transitions, Transformsはもうそういう時期なんじゃないかなと。short-termにはいかないでしょうね。

Tab: Given the discussion is about webkit being a monoculture on Mobile, if webkit decides to remove a prefix then it's okay for everyone to remove prefixes also.

WebKitが接頭辞を省けばいいんじゃないかと。実装はそうかもしれんが、既存コンテンツは無理なわけでして。

tantek: So this is not saying implement -webkit- across the board.

tantek: This is consider implementing some -webkit- properties, and be very deliberate about which ones and why.

tantek: We need to do analysis about how many sites we can fix and how much.

すべての-webkit-やら他のベンダー接頭辞を実装するというわけではなくて、何が互換性を向上するために必要かを見極めた上でという話らしい。やっぱり機能によるよね。

tantek: None. We will also need to send a webkit-tricking UA string.

tantek: Just like WebKit sent "like Gecko" in its UA string, we have to do the same thing again

glazou: Two implementations will not fully match, but you will treat -o- and -webkit- as the same.

Florian, Sylvain: Evangelism has failed.

glazou: Have you tried pinging the WASP about that? Other activists of web standards?

sylvaing: If MS can't scale to handle this, you think WASP can?

Sylvainの最後の発言がなんとも。というかWASPは生きているのかねえ。

glazou: Tab, how do you feel about that? Is there anything you can do?

Tab: There's enough legacy content that there are some properties that we can't drop the prefixes.

Tab: Given that's a reality for us, totally sympathetic that it's a problem for everyone else.

Tab: These are used on production sites.

WebKit側でも、古い実装に依存したコンテンツがあるものね。

smfr: Two categories of problem.

smfr: We have things like Transforms, which are being standardized and implemented by other browsers.

smfr: There's others like text-size-adjust, which is only proprietary on iPhone

smfr: Not sure about standardizing things like that.

smfr: Some of this is due to iPhone's success

Florian: If something is intended for internal use, then it is proprietary.

Florian: But once it's encouraged out on the Open Web, it cannot be proprietary anymore.

Florian: The cat is out of the box.

Florian: ... If you submit a spec about things like this, we're back into the other case.

Florian: If we don't get specs for these, the problem is harder. But I think we should get specs for these.

tantek: Once it gets served over the open Web, it is no longer proprietary.

sylvaing: A lot of authors assume that any -webkit- property is in the standards process.

標準化されている仕様と、-webkit-text-size-adjustみたく仕様のないベンダー固有拡張について違いがあるんじゃと。「ね　え　よ」って話。

ただ仕様があればずっといいのは確か。-webkit-text-size-adjustはWindows PhoneのIEでも、Firefox 12でも固有の接頭辞付きで実装されたけど、挙動はリバースエンジニアリングでなんとかしてるので、同じというわけではない。

tantek: Bringing to WG because I believe we can solve problem better together than individually.

tantek: I'm going with assumption that none of us want to just implement all -webkit- properties.

Tab: I don't even want to implement all -webkit- properties.

<tantek> https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology

tantek: What are the thresholds, even approximate, for implementing -webkit- properites (or none)?

tantek: Help us minimize the damage.

dbaron: Part of what Tantek is saying is that we want to look very carefully at the evidence to see whether we need to do this.

dbaron: Can we get the draft to a point where we can unprefix?

dbaron: E.g. 2D transforms, based on Aryeh's tests, are interoperable enough to drop prefixes right now.

dbaron: Maybe revisit our decision to merge 2D and 3D transforms, and take draft to CR in a couple months.

Florian: Might not be enough to solve the problem.

dbaron: What Tantek is saying is that we're not going to look at this as a single problem.

dbaron: The more we can unprefix, perhaps the less we have this problem.

tantek: One possible proposal is to only parse other vendors' prefixes in conjunction with parsing unprefixed.

tantek: e.g. with -webkit-transform. We wouldn't parse that until we also parse transform.

tantek: Thereby giving authors option to just use unprefixed, hopefully biasing new authors to using that instead.

tantek: That is one example of methodology that we want to apply to limit the damage of this.

tantek: If you can think of other examples of ways of thinking about this, to provide ways of moving forward.

tantek: We are absolutely open to other ideas.

interopのために必要な接頭辞付き機能は何かという話の一方で、実装が成熟して接頭辞を外せる状態になるものについてはそうしていくほうがよい。

glazou: Simon said that Apple WebKit implemented -webkit-text-size adjust for better experience on mobile.

glazou: I suppose this aims at mobile.

tantek, florian: yes.

glazou: This is replacing standardization by turning one implementation into a de facto standard.

glazou: Instead of creating a de jure standard here.

glazou: The right thing to do would be for Apple to submit text-size-adjust for standardization here.

dbaron: I don't see why Apple has to write the spec if they're not writing the spec.

dbaron: We dealt with this with IE6. Bunch of stuff we had to copy IE6 into the spec and implement that.

Tab: IE6 monoculture of desktop. WebKit monoculture of mobile. It's the same problem.

smfr: I can take a list of properties we need back and see if we can bring it back for standardization

glazou: In a reasonable timeframe?

smfr: Yes.

Apple拡張の標準化について。これもこれで重要。

dbaron: Off the top of my head, the only thing not in this WG that's a major issue is text-size-adjust

Florian: -webkit-appearance

?: That's in UI. But was dropped

fantasai: Maybe we need appearance: auto | none. (None of the other values are useful.)

<tantek> https://bugzilla.mozilla.org/show_bug.cgi?id=708406

tantek: Have to do crawls by switching UA strings. But here's our data.

sylvaing: The -webkit-tap-highlight-color is very highly requested

fantasai: I think that's a case that's not very critical. Nice to have, but not having it won't break anything. We should solve the problem it's solving, but don't think we need to implement exactly that.

CSS3-UIから外されはしたものの、appearance: noneはかなり使われてるので、必要だと思う。あとGeckoについては、セレクトボックスの▼のところを消したりするような、実装の調整も必要だろうなあ。

tap-highlight-colorの重要性について。ここは何を持って“break”とするかにかかるよね。要らんだろと思うけれど…

tantek: I think if you're working on open standards, you should propose your features before you implement them and discuss that here.

smfr: We can't do that.

sylvaing: We can't do that either.

tantek: We're going to push you to do that sooner and sooner.

jdaggett: If you're proposing something that's going to be put on a Web page, how is that proprietary?

「実装する前に言えよ」「いや無理」「こっちも」っていう。特許とか、開発中の製品に必要な機能とかだと、どうしてもそうなる。ただ、「Webページで使われる機能をどうプロプライエタリって言うんだ」ってのは、うんうん。

Florian: Properties is not the only thing, e.g. gradients.

Florian: device-pixel-ratio is another problem.

glazou: I think it's very unfortunate timing, esp. now that we're trying to use prefixes for JS APIs.

そう。CSSだけじゃないというのが結構めんどくさい。ただAPIについては、まだJavaScriptでちょこちょこできるというのがある。CSSもできなくはないけど、OMがへぼいからやってらんない感は強い。

glazou: You are solving a problem not with the right way.

Florian: give us a better way

glazou: You're saying that because you're saying the other ways did not succeed.

Florian: We have 15-20 people in devrel, one of their primary jobs is that.

Florian: It doesn't scale.

tantek: Number of mobile websites providing webkit content first is growing faster than we can contact them.

glazou: We're not just here to do things. We're here to do things the right way. We want things to be stable on the Web for 50 years.

glazou: The technology, yes, it has to be readable.

glazou: I don't think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.

sylvaing: Many don't consider the right way to be good.

glazou: You don't have to teach me about pragmatism.

sylvaing: We have authors who actively write tools to avoid the right way.

plinss: As soon as we do this, vendor prefixes have failed.

tantek: I don't think we need to throw out the baby with the bathwater.

plinss: I think the fact that Mozilla is discussing this publicly is harmful.

plinss: Nevermind actually doing this.

Florian: So what should we do?

dbaron: So what should we do, disband the WG?

plinss: yes

plinss: If we go down this path we have broken standardization.

As soon as we do this, vendor prefixes have failed.ってのは、もうだいぶ前に終わってしまったことで、broken standardizationというのは、接頭辞によってもたらされてるんじゃないかと。

（こっから何行かよくわかんない話が続く）

Anton: I think it'll be very dangerous to make it obvious that we can implement each others prefixes without making it very clear what vendor prefixes are and how they're supposed to work.

Anton: Need the WG to agree and explain what problem they're trying to solve with prefixes.

Anton: I think it is harmful to concentrate on this one problem and not concentrate on the global problem. Send a very mixed message to authors.

plinss: You're telling authors to just use webkit prefixes, we'll make it work.

Tantek: No, we're only implementing a small minimized number of these.

fantasai: But if you don't make that clear, and communicate that, it'll be interpreted as "if enough websites use it they will implement it".

fantasai: Anton's point is that you need to send that message, and not just in the CSSWG minutes.

何を、をちゃんと見極める。

（さらに収集つかなくなってくる）

plinss: If you have a list of properties you have to implement to survive, then let's get that list, get consensus on it, and then agree to standardize them as-is implemented in WebKit.

Florian: That only stops the bleeding.

plinss: If we do this without a plan to stop the bleeding, it's only going to get worse.

Anton: And will cause confusion.

うん。

plinss: To go back to Quirks mode. The original intention -- it was intended for NS4, btw, not IE6 -- the problem was too many sites to fix, we have to support them.

plinss: But we wanted to support only the old sites, and new sites should be written to standard

plinss: People are still writing sites today that depend on quirks mode in order to function.

plinss: People 20 years from now will be writing sites that support webkit prefxes.

dbaron: There's a major piece of Web standards community, not well represented in this room, but better represented in HTML and WHATWG

dbaron: They think quirks mode was a mistake. That we should have just lived with that behavior.

plinss: I accept that as a philosophy, but that was impossible.

plinss: NS4 did not treat HTML as a structured document.

dbaron: I think quirks mode very quickly diverged from its original intent

dbaron: Because 2 years after IE had 95%+ market share

dbaron: It became about being compatible with IE, not NS4.

plinss: If we launch this vendor-prefixed quirks mode, it's going to get out of hand. Whatever our desire to minimize our impact, it's going to get worse than what we expect.

Florian: Not spread to everything

plinss: Going to get worse than you expect

dbaron: Email headers with X-. Supposed to be experimental. But the world still works.

既存コンテンツがちゃんと更新されることはそこまで多くないんだろう。JavaScriptのMIMEのカオスさとかね。納品しちゃって手を入れられない状態になったら、知っててもメンテできないし。

tantek: While I understand the analogy with Quirks mode, I disagree

tantek: We can search for and get data on prefixed property use

tantek: You can write a linter that points out your webkit properties.

tantek: quirks mode you can start relying on accidentally

tantek: I don't think this is as bad as quirks mode.

tantek: Quirks mode biased being lazy.

tantek: The policy we have for prefixes biases the right thing, which is no prefix.

tantek: It takes work to use a prefix, whereas it didn't take work to use Quirks mode.

tantek: I can see the similarities but in practice I think they're very different.

plinss: My assertion is that it's still going to be worse than you think.

plinss: People will write tools and inject things, etc.

The policy we have for prefixes biases the right thing, which is no prefix.これに尽きると思うんだよなあ。

sylvaing: Once those -webkit- properties work in other browsers, are people going to check which ones work? Or are they just going to assume that all -webkit- properties work?

tantek: It is up to us to make sure that the unprefixed properties are the most reliable.

tantek: And that's how we end up driving off the -webkit-

tantek: Being neat only drives authors so far. They want reliability. If we can deliver that with unprefixed

plinss: We need to get in people's minds that if you use prefixed, we will drop support for it at some point.

plinss: We should assert leverage to get MS and Webkit to change their mind.

plinss: Prefix has half-life. It will live for so many years, then go away, by definition. That will help this problem.

plinss: If we can get something like that stuck in the ground, then my objection drops dramatically. Because we've cut the bleeding.

他のベンダー拡張を一部サポートするだけじゃなくて、それは不安定だという印象を与えるってのは、うんわかるんだけど、じゃあMSやWebKitの方針を変えられるかというと、無理だろう。合理的じゃないし、メリットがないもの。

とまあこんな感じでランチに突入したらしい。

エイリアスの詳細

florian: When a browser supports several variants of the same property (either prefixed and unprefixed, or multiple prefixed), what does it look like through the OM?

florian: If we favor interop here, we should decide what it says.

florian: But David argues that we shouldn't favor interop here - the fragility helps discourage prefix usage.

[some discussion over one impl strategy]

florian: Another strategy is to always favor your impl, as it can let someone target your impl well.

sylvaing: What do browsers do today?

florian: We don't have a problem with it yet.

dbaron: Gecko never implements different semantics for two things.

dbaron: The only time we've had two things in gecko is with prefixed and unprefixed.

dbaron: When we did that, -moz- was treated as an alias for unprefixed.

dbaron: If you asked for the -moz- in the OM, you'd get back the unprefixed.

dbaron: If you got the list of properties, you'd get the unprefixed as well.

dbaron: It was meant to steer people toward the unprefixed.

dbaron: Webkit supports multiple prefixes with different semantics.

複数の構文をサポートする場合、OMではどうなるか。Geckoは複数の構文に対して違うセマンティクスを持たない。WenKitは一方でいろいろやってる。ここらへんは古いプロパティのサポートもあるんだろうなあ。

alexmog: In general, only cascading should matter. If a dev puts it there, it means that they want it.

alexmog: If you have two prefixes, you should favor your own.

TabAtkins: What about -webkit- and -epub-?

alexmog: You should favor the -webkit-.

sylvaing: Why is it different from prefixed and unprefixed?

alexmog: I need to be able to target specific impls.

sylvaing: So if -webkit- is supported by Opera and it's the last one, what happens?

florian: If you set up a hierarchy (your prefix is stronger than other prefix, unprefixed is most important), what happens if you have different specificity/important?

sylvaing: We had that with 'opacity' and 'filter'.

ここは気になるところ。異なるベンダーの接頭辞が混在するときどうするか。自分たちの実装を「強く」するとspecificityが絡んだ時にどうなるのかとか。

florian: If you use multiple versions in the stylesheet, then all are preserved in the specified value, but only the "winning" one lives in the computed style.

TabAtkins: But Gecko always returns the unprefixed version in the computed style - they don't remember the source.

fantasai: We have some unprefixed aliasing too - overflow-wrap and word-wrap are (unprefixed) aliases.

dbaron: I don't think we should have aliases in the spec.

florian: I think it's reasonable, even if it's just an optional alias. We should still define how the cascade and OM work for them.

florian: I propose that it gets converted to the "most standard" one, and it appears as that in all cases in the OM.

fantasai: We also have page-break-* and break-*.

fantasai: I need to put that into a spec. So we need a resolution for this.

word-wrapをoverflow-wrapにするっていう決定はなんなんだろうねえ。

plinss: Maybe that's a good approach, though. Just *never* show prefixed in the OM.

TabAtkins: That seems reasonable to me.

glazou: And what about when serialized?

plinss: Serialization is different.

glazou: If it doesn't show up in the OM at all (when an unprefixed doesn't exist yet), that will break editors.

tantek: We set a precedent for prefixing in the DOM, too.

tantek: We probably want to keep things prefixed in the OM, then, so we can justify other web apis prefixing.

<sgalineau> if one supports -prefix-foo and foo and the stylesheet only sets -prefix-foo, does getComputedStyle() expose it as prefixFoo or foo ?

florian: The simplest thing we can do is that, at the cascading level, the last one wins.

florian: In the OM, the one that's used is returned.

dbaron: I don't see any need to remember prefixes in Gecko.

macpherson: I think the most consistent is to reflect the used version.

macpherson: If we change the spec after implementation, you'll need to return the value in the old form as a prefix.

dbaron: Part of the Gecko strategy to discourage prefixes is that, the *instant* the unprefixed is supported, the OM no longer supports th eprefix.

dbaron: We may support it still in the stylesheet for a bit, as necessary.

接頭辞付きのものがOMに表れるかないか。

dbaron: We haven't had content breaking because of dropping the prefix in the OM. smfr: We probably would have content break in WebKit if we did that.

WebKitの場合、OMから接頭辞を省くと既存のコンテンツに影響がでるだろうと。

florian: As an editor, Daniel, do you prefer what the stylesheet originally said, or what is used?

glazou: From a CSS editing program, I'd prefer getting back *everything*. But at least, what the author said.

glazou: If an editor changes properties between input and output, we'd just get complaints from users.

florian: By now I know what I want to ipmlement, so I wonder if we should consider discussing until we agree on what to implement, or if we should learn to love the breakage.

florian: The cascade wins (the one that comes last). When you query through the OM, you only see the one that won (with or without prefix, depending on which one won).

florian: So internally you remember which name was used, but you otherwise treat them as aliases.

glazou: Say that Opera supports a -webkit- property, and -webkit- drops its prefix.

glazou: Before you drop the prefix too, if -webkit- is used last, you'll output the -webkit- rule in the OM, even though it will no longer work in WebKit.

florian: Yes. That's internally consistent.

glazou: But you have inconsistencies for a little while.

glazou: My preference would go to supporting the last one in implementation order, not cascading.

florian: When a page is authored toward a particular prefix in script, that'll break the page.

CSSのエディタをつくってるDanielとしてはOMにすべてのバリエーションがあらわれて欲しい。など。

alexmog: I can explain what we might think of doing.

alexmog: We preserve all the properties that are set.

alexmog: So if you write out a file, we'll write out everything.

alexmog: If you query through the OM, we only preserve one of the values after cascading.

alexmog: If hypothetically we have -ms- and -webkit- and unprefixed, all will return the appropriate syntax, but from only the winning value.

florian: If the -webkit- won the cascade, do you see it as -webkit-, or as something else, or as all of them?

alexmog: So if we support multiple names for a property, we'll return the winning declaration as *all* of them (perhaps with adjusted syntax, as necessary).

alexmog: So we probably won't want to remember who won.

szilles: What do you do if the values changed between property versions?

alexmog: We'll adjust the output to match the syntax of the given version.

Rossen: I don't think that's right.

Rossen: Today we only have aliases.

alexmog: We remember literal attribute and property values.

[some discussion about the exact behavior of MS] florian: But if you ask for a list of the properties on an element, do you get all of them, or just the winning? sylvaing: Yes, even if you only specify one of them in the stylesheet.

まとまってきた。

plinss: We won't ever get every single value - fully unsupported properties won't show up.

[something about how Blue Gryphon works]

florian: So the suggestion is that, if you specify only -moz- (in Firefox), then in the OM you'll see both unprefixed and moz-prefixed.

florian: Is that okay?

glazou: Maybe.

glazou: [explains why it may be difficult, but not impossible]

plinss: You just need to have a table, based on the version of Gecko you're using, saying which properties are unprefixed.

TabAtkins: That behavior sounds fine to me.

dbaron: [explains exactly what Gecko does - it's identical to the proposed behavior, except that the CSS2Properties interface (like el.style.boxShadow) only shows one version at a time]

glazou: [clarifies his understanding, and asks about prefixed values as well]

RESOLVED: When a browser supports multiple versions of a property, they're treated as aliases in the cascade, such that last wins. In the OM, *all* variants show up, with equivalent values, regardless of which version was specified or which won.

plinss: For aliases, this should be clearly specced.

plinss: Distinct from prefixed stuff.

florian: Is this somewhere centralized in CSSOM, or do we specify it every time we have an alias.

RESOLVED: The last resolution applies to WG-approved aliases. It MAY be used by browsers for prefixed versions as well.

とりあえずエイリアスについてはこういう仕組みに。

florian: Now, for prefixed values.

florian: I say just return the one you got.

plinss: Agreed.

TabAtkins: Agreed.

Florian: What about individual media query features?

TabAtkins: I think they feel a little more like values, so I'd preserve them as the author wrote.

florian: Does anyone who cares object?

fantasai: Deferring to dbaron.

plinss: The point for properties is so we don't have to remember which version it came from.

florian: But for values we reasonably often can't cover all the possibilities between versions.

RESOLVED: When value aliases are supported, return the version that the author provided.

RESOLVED: In media query feature strings, also return the version that the author provided.

というわけで、いちおうresolvedと。