On Tuesday, February 17, 2015 at 8:18:56 PM UTC+10, Dale Harvey wrote: > It feels like this would be a more productive conversation if you used > firefox os (as well as other mobile os's) understood at a deep level the > feature requirements and where you think you had a better idea suggested > alternative approaches, possibly individually >
The DOM team is trying - sorry if you feel we (or just me?) are out of touch. We do our best to look across all platforms, not just FxOS. We do the best we can to collect use cases and understand the problems developers are having. Recent examples I've personally participated in: * http://www.w3.org/TR/netinfo-usecases/ * http://www.w3.org/TR/wake-lock-use-cases/ * http://w3c-webmob.github.io/installable-webapps/ * http://usecases.responsiveimages.org/ * https://github.com/whatwg/media-keys/ > <input type="file" accept="image/*> > is not a sensible suggestion for a replacement on how the gallery works I was not suggesting any such replacement - if we don't already support this, I was suggesting accessing the gallery through that means (like other mobile platforms allow). > Applications do need access to systemXHR, the very obvious example being > 'read it later' / feed reader app where the remote servers do not support > CORs, email, calendar, browser probably others all have needs to talk to > remote servers that are not under our control. This is fairly commonly > discussed in part of the standards efforts > (https://groups.google.com/forum/#!topic/mozilla.dev.webapi/6a9QBn2Z0k4) > there isnt a viable solution as yet. A feed reader / scraper that only works > on the 2 servers in the world that supports CORS is not a sensible suggestion. > Well, the it's going to be very amusing then when we start telling people to use service workers, which rely both on CORS and TLS ^_^. The same with Geolocation, which we hope to move to requiring TLS to access it. I'm sure there was a time before TLS was not well supported on servers when someone exclaimed "A [insert thing here] that only works on the 2 servers in the world that supports [TLS] is not a sensible suggestion"! Hell, someone probably shouted the same thing about HTTP back in 1991, lol:) All browsers support CORS now (http://caniuse.com/#search=cors). To not enable it for an app is irresponsible. To not require TLS for service workers would put users privacy at risk. So are we also going to chicken-out and do a "System Service Workers" because not enough developers have TLS? > <input type="file" accept="image/*;capture=camera"> > Does not replace the camera api and is similiar to what it does already, the > functionality the 'system camera service' has is not any different than the > features a camera based application (like instragram) would fully expect to > have. This has long been slated to be added to GUM. > Yes, which is why I mentioned getUserMedia(). > Being able to share data between applications, photos between the camera / > gallery, contacts in various places are the result of use cases we hit > against and found a requirement for. > Sure, that's an extremely valuable requirement. > We cant just say 'replace X with an <input>' as a serious discussion about > how move forward with standardisation efforts, there needs to be a deep > understanding of what use cases is being fulfilled. > Please try to avoid being condescending. I'm not suggesting we solve anything with overly simplistic solutions: I'm saying that we need to evaluate where the standardized solutions are failing and get that feedback back to the web platform. FxOS can add APIs till it solves all the things, but if no other browser implements those solutions too, then it hardly makes FxOS an attractive platform to code for: precisely because it doesn't work in other browsers. So as a developer, you won't be able to build a cross-browser app - or worst, we start seeing "works best in FxOS!" on things - the equivalent of "download from the App/Play Store". I doubt that's the web we want, is it? Again, the DOM team is here to help FxOS be part of the Web platform - we don't have any of the answers, just suggestions (but working together hopefully we can find some solutions that can benefit everyone). As you can see from the links above, there is scope to do in-depth analysis of the use cases and requirements to help come up with standardized cross-browser solutions that address the use cases in a "webby way". _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
