Re: Replacing Gecko's URL parser
On Wed, Jul 3, 2013 at 4:08 PM, Benjamin Smedberg wrote: > I don't understand why it matters. chrome: and resource: are both > gecko-specific extensions and we have no desire to standardize them. > Chromium uses a different scheme for their chrome: protocol. Because doing so would be a violation of the standard. It's pretty clear on what the results must be for any given input. Having differences for some unknown-in-advance schemes would be bad. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing Gecko's URL parser
On Thu, Jul 4, 2013 at 1:45 AM, Anne van Kesteren wrote: > On Wed, Jul 3, 2013 at 4:08 PM, Benjamin Smedberg > wrote: > > I don't understand why it matters. chrome: and resource: are both > > gecko-specific extensions and we have no desire to standardize them. > > Chromium uses a different scheme for their chrome: protocol. > > Because doing so would be a violation of the standard. It's pretty > clear on what the results must be for any given input. Having > differences for some unknown-in-advance schemes would be bad. > > > -- > http://annevankesteren.nl/ > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > Presumably we could have a blacklist of the handful of protocols that are internal to browsers and have compat issues. "It violates the standard" isn't a very compelling argument when the standard is in the process of being written and nobody implements it. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing Gecko's URL parser
On Thu, Jul 4, 2013 at 5:17 PM, Kyle Huey wrote: > Presumably we could have a blacklist of the handful of protocols that are > internal to browsers and have compat issues. "It violates the standard" > isn't a very compelling argument when the standard is in the process of > being written and nobody implements it. Then we might as well define them. It's not like their parsing behavior is particularly hard. And this does not just affect new URL(), it affects how e.g. behaves as well. And a large part of the reason of defining this is because of the current mess of nobody following the IETF standards (which were not compatible, URL standard hopefully is)... In any event, this issue seems relatively minor compared to what's involved in getting Gecko to switch URL parsers. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
Thank you to everyone that provided feedback. I've read everyone's comments and taken them into account with my new draft: https://wiki.mozilla.org/User:Overholt/APIExposurePolicy In general I tried to make it more of a set of requests and guidelines than a set of "must"s. I also clarified some of the wording around what it means for something to be "standardized" or "ready for shipping". It's ready for another round of feedback when people have time. Thanks again! Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
