Are you most likely in control of all the users of browser-element, maybe you
could fix the small things you mentioned to be in common and return not
implemented for the new things you don't want to spend time adding?
> If we care about the compatibility, what could be the proper way to
experiment with an alternative API?
For Gecko code, maybe not letting it graduate beyond Nightly? Or maybe
MOZ_UPDATE_CHANNEL nightly or not defined.
On Thursday, November 12, 2015 at 10:06:23 AM UTC-5, Paul Rouget wrote:
> to dev-servo. dev-platform cc'ed.
>
> context: browser.html + servo
>
> There are some changes we'd like to make to the Browser API.
>
> At least, we'd like to always use event.detail instead of
> event.details (because DOM events use detail, not details). Also, the
> details field in Gecko can be a string, or an object. I'd like to
> enforce the detail property to be an object described in the WebIDL.
>
> Named properties make more sense I believe, and it makes it easier to
> add fields, for example, the "locationchange" event comes with a
> string (the new location). I'd like to change that to
> {location:string}, and eventually add extra fields, like
> {location:string,cangoback:bool,cangoforward:bool}.
>
> And having these events described in the WebIDL will make it easier to
> document the API.
>
> But mostly, we'd like to have the freedom to experiment with new
> methods and events. But the Gecko/Gaia compatibility will slow us
> down.
>
> If we don't really care about keeping the compatibility between gecko
> and servo, do we want to rename the events/API (mozbrowser could be
> renamed to something else)?
>
> If we care about the compatibility, what could be the proper way to
> experiment with an alternative API?
>
> -- Paul
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
