Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

<webview> API common subset between vendors

29 views
Skip to first unread message

Kan-Ru Chen (陳侃如)

unread,
Jan 14, 2015, 4:39:41 AM1/14/15
to Dev-Webapi
Hi all,

I put up a wiki page that summarize the browser-api or <webview> API
that has been implemented by vendors here:

https://wiki.mozilla.org/WebAPI/BrowserAPI/Common_Subset

Next step is to decide what APIs should be included in our <webview>
implementation and their semantics.

Kanru

Ehsan Akhgari

unread,
Jan 14, 2015, 1:42:53 PM1/14/15
to "Kan-Ru Chen (陳侃如)", Dev-Webapi
Have you reached out to the Chrome and IE teams to see if they are
interested in such a unification (specifically them being willing to
make changes to their side where needed)?

Kan-Ru Chen (陳侃如)

unread,
Jan 14, 2015, 9:46:36 PM1/14/15
to Ehsan Akhgari, Dev-Webapi
Not yet. I think no matter what they do we still want to develop our
<webview> so I put up this table first. I'll ask them to see if they
have any idea.

Kanru

Benjamin Francis

unread,
Jan 16, 2015, 6:40:15 AM1/16/15
to Kan-Ru Chen (陳侃如), Dev-Webapi
On 14 January 2015 at 09:39, Kan-Ru Chen (陳侃如) <kc...@mozilla.com> wrote:

> I put up a wiki page that summarize the browser-api or <webview> API
> that has been implemented by vendors here:
>
> https://wiki.mozilla.org/WebAPI/BrowserAPI/Common_Subset
>

This is awesome Kan-Ru, nice work.

I did a similar analysis a while back which is what led me to start
drafting this Webview spec http://benfrancis.github.io/webview/

I think there could be a lot of value in a standard <webview> element and
the existing implementations are close enough that I think it wouldn't be
too hard to reach consensus on a common subset of the APIs.

I think the biggest obstacle is going to be that we still don't have a web
standard way of safely exposing this API to the web. If we reached
consensus on the <webview> element and API, we'd still be lacking a way to
expose it to the web to make it part of the web platform.

Is it worth approaching Google and Microsoft about working towards a
standard, even with this piece missing? I've already had conversations with
the people working on Google's implementation in the past and would be
happy to follow up with them. Could hosted packaged apps be a candidate for
that missing piece?

Even if making <webview> a new standard element for the web is some way
off, I still think the transition from <iframe mozbrowser> to <webview> in
Gecko is long overdue. I've been wondering whether we could start by
creating a <moz-webview> polyfill using Web Components, so that <webview>
could be reserved for a future standardised version?

Ben

Kan-Ru Chen (陳侃如)

unread,
Jan 23, 2015, 3:55:15 AM1/23/15
to Benjamin Francis, Dev-Webapi
Benjamin Francis <bfra...@mozilla.com> writes:

> On 14 January 2015 at 09:39, Kan-Ru Chen (陳侃如) <kc...@mozilla.com> wrote:
>
>> I put up a wiki page that summarize the browser-api or <webview> API
>> that has been implemented by vendors here:
>>
>> https://wiki.mozilla.org/WebAPI/BrowserAPI/Common_Subset
>>
>
> This is awesome Kan-Ru, nice work.
>
> I did a similar analysis a while back which is what led me to start
> drafting this Webview spec http://benfrancis.github.io/webview/
>
> I think there could be a lot of value in a standard <webview> element and
> the existing implementations are close enough that I think it wouldn't be
> too hard to reach consensus on a common subset of the APIs.
>
> I think the biggest obstacle is going to be that we still don't have a web
> standard way of safely exposing this API to the web. If we reached
> consensus on the <webview> element and API, we'd still be lacking a way to
> expose it to the web to make it part of the web platform.
>
> Is it worth approaching Google and Microsoft about working towards a
> standard, even with this piece missing? I've already had conversations with
> the people working on Google's implementation in the past and would be
> happy to follow up with them. Could hosted packaged apps be a candidate for
> that missing piece?

It's still nice to know how they think. If hosted packaged app does
solve the signing & permission issue then I think it could be the
solution. But I think it is still worth to have a standard <webview> in
web apps even without a standard way to expose it to the general web.

> Even if making <webview> a new standard element for the web is some way
> off, I still think the transition from <iframe mozbrowser> to <webview> in
> Gecko is long overdue. I've been wondering whether we could start by
> creating a <moz-webview> polyfill using Web Components, so that <webview>
> could be reserved for a future standardised version?

Yes, I think a web component based on our current mozbrowser iframe is
possible.

Kanru
0 new messages