| 00:41 | <roc> | jgraham: it's the "theoretically" part that worries me |
| 00:45 | <jgraham> | roc: Sure. But if it's both not *that* widely used and we have others also agreeing to only implement the new thing it seems more sensible to do that first and then go back and implement the old thing if there's an actual problem |
| 00:45 | <roc> | sure |
| 00:46 | <roc> | but every day Chrome implements this cool API and we don't is a problem |
| 00:47 | <roc> | er |
| 00:47 | <jgraham> | That's true of everything though. Is the cost of missing this one especially high? |
| 00:47 | <roc> | better to say: every day these sites work in Chrome and not Firefox is an actual problem |
| 00:48 | <jgraham> | I mean it doesn't actually stop sites working, does it? It just makes for more convenient authentication for a small group of users |
| 00:48 | <roc> | every day that feature of those sites works in Chrome and not Firefox is an actual problem |
| 00:49 | <roc> | maybe it's not a big deal in practice |
| 00:49 | <roc> | maybe it is |
| 00:51 | <roc> | we've been burned many times by Webkit or Blink exposing some non-standard API, which gets revised in a shiny standard API, which we implement, but too many sites stick with the non-standard or prefixed stuff and we're twisting in the wind |
| 00:51 | <roc> | I'm tired of it |
| 00:51 | <TabAtkins> | Yup. :/ |
| 00:57 | <roc> | jgraham: maybe the right question to ask is: is Chrome willing to commit to implement the new thing *and* remove their nonstandard entry point, and at what date? If we don't like the answers we definitely need to implement the API people are actually using |
| 00:58 | <roc> | even if we do like the answers we still have to think how much we trust them :-) |
| 01:00 | roc | has not forgotten the H.264 debacle |
| 01:03 | TabAtkins | was lied to about that, too. |
| 01:05 | <jgraham> | roc: So I absolutely don't think they'll remove the nonstandard thing. But the question is oppertunity cost. If we can get away with doing one implementation then the engineers that would have spent the time reverse engineering a second implementaion can instead work on some other feature that's needed to improve Gecko. |
| 01:05 | <roc> | fair |
| 01:47 | <caitp> | I think webkit and blink developers often feel just as burned by not being able to remove or revise absolute broken crap |
| 01:56 | <roc> | yeah but it's not costing them market share |
| 01:56 | <roc> | just guilt |
| 01:56 | <roc> | and technical debt |
| 01:56 | <roc> | so "just as burned", I think not |
| 02:18 | <caitp> | I don't know if people pick their mobile phone based on the stock web browser |
| 02:19 | <caitp> | but still don't want to break those mobile sites |