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と。