Deprecating (web-facing) features and vendor prefixing

Moderator: jchaffraix Scribe: aklein (note that the below is not literally what people said; feel free to fix things if your statements were misinterpreted)

Deprecating features

jchaffraix: How do we deprecate web features? e.g., layerX & layerY on events. Added a deprecation warning, got lots of complaints, turns out IE 9 & 10 implement it.

weinig: is this a problem? sounds like it worked!

jchaffraix: it did work, but now we have to standardize it.

weinig: how do we decide when to deprecate a feature? how much of a burden is it on the project [WebKit]. if it's big enough, it may be worth it

ojan: MutationEvents may be an example of something that's big.

weinig: and we'll have to see how much complaining we can put up with. previously we've said things like "we are thinking of changing the scope of the unload handler", no one said anything, and we didn't do anything.

fishd: options: get feedback from developers via warning messages; measuring usage with instrumentation; more developer outreach. but also webkit contributors may disagree about whether getting rid of stuff is really a goal. we wouldn't want different ports to deprecate different features.

zherczeg: this could be a thread on webkit-dev

weinig: we could have some sort of committee to decide what to deprecate [fishd doesn't like this idea]. but it's an open source project, not clear if this would work. data plus discussion may be the best we can do.

[various brainstorming]: how was the decision about layerX/layerY made? just discussion among webkit developers on the bug. maybe we should get folks like annevk or other spec folks involved at points like that. [lots more discussion about details of layerX/layerY].

fishd: another example is removing ArrayBuffer support from sync XMLHttpRequest. we removed that, as did other vendors, but it broke real websites, e.g. a game framework that needed it to load resources from AppCache. in the end, we kept to our guns and the framework worked around it.

weinig: was that a good outcome?

fishd: well, sync XHR sucks, so in this case it seems worthwhile.

jchaffraix: maybe we should require folks who want to deprecate something to show data that people don't use it.

fishd: Blob.slice is a success story: got the arguments wrong, shipped in Chrome, and was changed to Blob.webkitSlice without complaint, with the correct API newly shipped as Blob.slice.

weinig: aren't gradients a success story? we were able to ship the new syntax without breaking anything.

arv: but we haven't removed the old syntax.

weinig: but is that really hurting us?

jamesr: who is "us" here? the web or webkit developers?

weinig: webkit developers.

jamesr: but it seems like we should consider the web platform as well.

weinig: well, lots of stuff is added to the web platform all the time; some good, some bad, and we have to support all of it. the reason we'd want to remove stuff is if it imposes a burden on webkit itself.

jamesr: seems like we should also measure how many sites depend on webkit-specific stuff, especially over the long haul; that seems like a bad thing for the web platform if we don't deprecate stuff and thus drag out the webkit-specific stuff.

zherczeg/fishd/weinig: [discussion of whether console warnings are something we are OK with adding; are they useful?]

macpherson: it's important to deprecate things not only because they're inconvenient for us to support, but because we've webkit-prefixed something and want to push people towards using the new standardized, non-prefixed thing. a warning message provides a way to push developers that's lighter-weight than just breaking entirely.

[unknown]: what about features that aren't maintained? those could have, e.g., security issues and no one's looking at them. maybe WebSQL?

fishd: WebSQL is maintained at the moment, because it is so central. I think everything we ship ought to be maintained. WebSQL in particular isn't going away for a long time; maybe someday someone will build a replacement on top of IndexedDB.

weinig: we can't get rid of stuff that people are using. we shouldn't deprecate [add warnings] for features that we don't have the "drive" to eliminate current usage, e.g., transforms/animations.

fishd: but what about things we want to get rid of but do have lots of usage?

weinig: if there's not a good reason to stop using something, then we probably shouldn't deprecate. IndexedDB needs to be better in some way than WebSQL.

AI: jchaffraix will write up some guidelines on how to deprecate a prefix.

Removing vendor prefixes

weinig: Mozilla has said that they would like to remove vendor prefixes; they're a browser, though. WebKit is used for browsers and other applications. It's not clear that some rule for when to remove prefixes makes sense for the non-browser case [i.e., you can't just break Mac apps].

jamesr: there's also a question about adding properties. when you're adding something, when do you add a -webkit- prefix? there's also a discussion about what the "webkit" prefix means. sometimes a feature is shipped without community discussion, and that seems possibly damaging.

fishd: is it a cover for an experimental feature, or is it just a way of shipping non-standard behavior.

weinig: traditionally, we've hoped that people would not depend on prefixed properties (not standardized, doesn't work in other browsers). as a second measure, we figured that we'd be able to ship the standardized thing with the proper behavior. a second chance to get the API right, basically. seems weirder in DOM than CSS (no fallback). sometimes we also do this for non-standardized properties that are needed for some particular application, when standards bodies don't seem to be interested or fast enough.

arv: vendor prefixes actually started out this way, when Mozilla wanted to expose things to XUL.

fishd: sometimes we implement new stuff without vendor prefixing, maybe because they're small or uncontroversial.

weinig: querySelectorAll, for example. if all the parties are at the table, it's sometimes ideal.

jamesr: what if no one's saying no, but people are saying "I'm not sure"? should we ship unprefixed and force others to match?

weinig: it's a balancing act

jamesr: there's a case where you have especially a big feature, and you're really not sure the API is right without getting developers to right real code against it. we need some way to ship things like this to developers.

weinig: isn't a custom build the right thing?

jamesr: [example from WebAudio, where we needed to get real feedback with all the features at trunk, not just a custom build with WebAudio enabled]

weinig: was that a success? Mozilla won't implement it as is.

jamesr: but we got feedback, that's the success.

[discussion of whether webkit would start supporting, e.g., -ms- prefix; pointed out that it would depend on what happens in the marketplace]

fishd: well, webkit implemented window.external. if it had been called window.msExternal, we probably would have shipped it too.

hober: XMLHttpRequest is another example.

jamesr: well, iOS has shipped webkit-prefixed things that aren't in upstream webkit, and other mobile webkits have had to implement them too.

weinig: the example that comes to mind is -moz-outline, which we decided not to implement.

fishd: we [google] plan to collect data on the usage of CSS on the web, to see which prefixes we could get rid of, how prevalent they are.

fishd: it would be nice if different browsers could move all together, shipping the same set of prefixes, e.g., could we get rid of -webkit-opacity? what would Apple want to know?

weinig: it's hard to say what we would need to know.

hober: if it's used on the web, it's hard to argue that we should remove it and make those pages render worse.

aklein/jamesr: is there any difference between the first and second parts of the discussion? is the vendor prefixed case different than other deprecation? Mozilla is willing to remove prefixed versions.

weinig: we don't want to break content.

jamesr: presumably Mozilla doesn't want to break content either.

fishd: although are clearly cases where they're more willing to break stuff.

dglazkov: over time, you end up with so many prefixes it becomes hard to build webapps.

weinig: but they could just use the non-prefixed version. it's just a burden on WebKit to support both versions.

jamesr: except that the behavior could be different, and developers have to think about it.

[unknown]: what about cases where Apple-internal stuff breaks? looking on the web isn't sufficient to decide whether a change will break something.

weinig: how do we know we're not breaking SAP all the time? I think we can all agree that there are times when we should deprecate a feature.