Re: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread Ryosuke Niwa

> On Oct 16, 2015, at 2:45 AM, Anne van Kesteren  wrote:
> 
> On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa  wrote:
>> Can we discuss how we can integrate ES2015 modules into HTML on Tuesday,
>> October 27th at TPAC?
> 
> Pretty sure Tuesday has been reserved for service workers discussion.

The wiki page says there will be a parallel meeting all day on Tuesday:
https://www.w3.org/wiki/index.php?title=Webapps/October2015Meeting 


CSS / Web Platform joint meeting is definitely happening at 3pm on Tuesday
so service worker meeting needs to finish before that in order not to overlap.

Regardless, we still prefer discussing ES2015 module integration on Tuesday 
morning.

- R. Niwa



Re: [manifest] Manifest "background_color" with gradient?

2015-10-16 Thread Mounir Lamouri
On Thu, 15 Oct 2015, at 20:07, Binyamin wrote:
> בע"ה
> 
> 
> How about gradients in "background_color" (linear-gradient,
> radial-gradient, repeating-linear-gradient, repeating-radial-gradient)?
> Anything delays such spec/implementation?

The goal is to be able to paint something on the screen as soon as
possible. Using complex colours could make the task complex. For
example, Chrome Android uses the background_color information to create
an Android native View while Chrome is loading. Unless we can use
gradients with Android, we would need to re-implement gradients outside
of Blink.

-- Mounir



Re: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread Adam Klein
Consider this a second vote for a California-compatible time for such a
discussion. V8 also has a partial ES2015 module implementation that's
blocked on the loader, and I'm very interested in pushing forward support
for modules in HTML.

On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa  wrote:

> Hi all,
>
> Can we discuss how we can integrate ES2015 modules into HTML on Tuesday,
> October 27th at TPAC?
>
> Both Gecko and WebKit are basically done implementing ES6 module supports
> in their respective JavaScript engines but blocked on
> http://whatwg.github.io/loader/ to support in web contents.
>
> Since my colleague who is interested in this topic cannot attend TPAC in
> person, it would be great if we could have it in Tuesday Morning (Monday
> evening in California).
>
> - R. Niwa
>
>


Re: [manifest] Manifest "splash_screens" with animated "any" size SVG

2015-10-16 Thread Mounir Lamouri
Domenic is right. The design of the splashscreen feature is to keep the
user experience smooth while Chrome loads its processes and get the
first bits to render on the screen.

-- Mounir

On Thu, 15 Oct 2015, at 20:14, Domenic Denicola wrote:
> I don’t know the details of the implementation at all, but I would
> imagine this would defeat the point. My guess as to why Chrome does
> things this way is to show something before they spin up an entire
> HTML/SVG/etc. rendering engine. During that time displaying an animated
> SVG is going to be impossible.
> 
> If you want an animated loading screen for your app, you should work on
> using techniques like service worker to make sure that the app is loaded
> as fast as possible from the cache API, and you can display your loading
> screen while you fetch fresh content from the network.
> 
> From: Binyamin [mailto:7rai...@inbox.lv]
> Sent: Thursday, October 15, 2015 15:08
> To: public-webapps@w3.org
> Cc: Mounir Lamouri 
> Subject: [manifest] Manifest "splash_screens" with animated "any" size
> SVG
> 
> בע"ה
> 
> Hi,
> 
> 
> Google recently has published icon support centered in splash screen in
> Chrome 47 requiring icon minimum size 196px,
> https://developers.google.com/web/updates/2015/10/splashscreen.
> 
> I propose instead "splash_screens" with animated SVG that could display
> loading process similarly to almost any this days Android/iOS-native apps
> like Skype, etc. Link to spec
> https://w3c.github.io/manifest/#splash_screens-member
> 
> {
> "src": "splashscreen.svg",
> "sizes": "any"
> }
> 
> 
> 
> Binyamin
> 



Re: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread Anne van Kesteren
On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa  wrote:
> Can we discuss how we can integrate ES2015 modules into HTML on Tuesday,
> October 27th at TPAC?

Pretty sure Tuesday has been reserved for service workers discussion.


-- 
https://annevankesteren.nl/



Re: App-to-App interaction APIs - one more time, with feeling

2015-10-16 Thread Chaals McCathie Nevile
TL;DR: It's worth pursuing, but chat in WICG first to get a proposal that  
Web Platform WG will formally take up.


On Thu, 15 Oct 2015 19:26:11 +0200, Daniel Buchner
 wrote:

After publishing the post, Google has reached out and we’ve been  
discussing options for solving this – would you like those discussions  
to be on the ML, or >back-channeled?




Hi Daniel,

at this stage we don't have a deliverable for this work - i.e. the W3C
members haven't approved doing something like this in Web Platform working
group. Given that people repeatedly attempt to do it, I think the
conversation is worth having. Personally I think this is something the Web  
needs, so one day we are going to have to get it done. On both counts, I  
encourage you to continue the conversations… But…


Since it is currently out of scope for this group, the normal path to get
it in scope would be to discuss it within the Web Incubator Community
Group. That way we don't lose important discussion by having it all
back-chanelled in private email.

That discussion should lead to a proposal for this group - use cases,
requirements, design considerations - initial thoughts about security,
privacy, internationalisation, accessibility, consistency with other Web
APIs, performance, …), perhaps a rough outline of a spec. You would be
aiming for First Public Working Draft, not Candidate Recommendation, so
having a pile of issues and bugs isn't a problem.

If that happens the next step is to change our charter.

That is an administrative thing that takes a few weeks (largely to ensure
we get the IPR protection W3C standards can enjoy, which happens because
we spend the time to do the admin with legal processes) if there is some
broad-based support. If we are at that point, the chairs and W3C staff
will handle most of the admin, beyond asking the Working Goup if they
agree we should add this to our charter.

And then we do the github magic to make a formal W3C Web Platform Working  
Group draft (usually takes me ages, so I'll ask someone smarter who will  
take a few minutes), and we're on our way to making a W3C standard…


…after that, it's just a matter of sorting out the issues, bugs,  
implementation, and then we're done :)


Until we look at the things we decided not to include in the first  
version, so we could ship faster…


cheers


- Daniel






From: Samsung account [mailto:bnw6...@gmail.com]


Sent: Thursday, October 15, 2015 9:26 AM

To: Arthur Barstow 

Cc: Daniel Buchner ; public-webapps@w3.org

Subject: Re: App-to-App interaction APIs - one more time, with feeling








2015/10/15 下午11:58於 "Arthur Barstow" 寫道:






On 10/14/15 12:33 PM, Daniel Buchner wrote:











Hey WebAppers,






Just ran into this dragon for the 1,326^th time, so thought I would do  
a write-up to rekindle >discussion on this important area of developer  
need the platform currently fails to address:


http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/.  
We have existing APIs/specs >that get relatively close, and my first  
instinct would be to leverage those and extend their >capabilities to  
cover the broader family of use-cases highlighted

in the post.






I welcome your ideas, feedback, and commentary,











Hi Daniel,






In case you haven't done so already, perhaps the Web Platform  
Incubation Group's Discourse service >would be a "better" place to  
discuss your proposal ?







--



AB
















--
Charles McCathie Nevile - web standards - CTO Office, Yandex
   cha...@yandex-team.ru - - - Find more at http://yandex.com



Re: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread Arthur Barstow

On 10/15/15 11:39 PM, Ryosuke Niwa wrote:
Can we discuss how we can integrate ES2015 modules into HTML on 
Tuesday, October 27th at TPAC?


Both Gecko and WebKit are basically done implementing ES6 module 
supports in their respective JavaScript engines but blocked on 
http://whatwg.github.io/loader/ to support in web contents.


Since my colleague who is interested in this topic cannot attend TPAC 
in person, it would be great if we could have it in Tuesday Morning 
(Monday evening in California).


Given the WPWG charter sets an expectation of collaboration with WHATWG, 
using meeting time at TPAC for this (or other mutual areas of interest) 
seems reasonable (assuming you can find a mutually acceptable day + time).


On the other hand, perhaps it would be useful to raise discussion topics 
on the list now (and not necessarily wait for TPAC).


-AB




Re: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread Dimitri Glazkov
Also keenly interested in moving this forward.

:DG<

On Fri, Oct 16, 2015 at 2:45 AM, Anne van Kesteren  wrote:

> On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa  wrote:
> > Can we discuss how we can integrate ES2015 modules into HTML on Tuesday,
> > October 27th at TPAC?
>
> Pretty sure Tuesday has been reserved for service workers discussion.
>
>
> --
> https://annevankesteren.nl/
>
>


Re: App-to-App interaction APIs - one more time, with feeling

2015-10-16 Thread Aymeric Vitte
Ccing the authors of [1], [2] and [3] if there is still an interest.

> 
> at this stage we don't have a deliverable for this work - i.e. the W3C
> members haven't approved doing something like this in Web Platform working
> group. Given that people repeatedly attempt to do it, I think the
> conversation is worth having. Personally I think this is something the
> Web needs

Indeed, that will be more than time to do so, but the current view of
the main actors or past specs seems a kind of narrowed and not very
imaginative/innovative, I don't think you should close the web intents
task force [5] but restart it on new bases.

This approach [1] and [2] looks quite good, simple and can cover all cases.

I don't know if we can call it a Web Component really for all cases but
let's call it as such.

In [2] examples the Bio component could be extracted to be passed to the
editor for example and/or could be shared on fb, and idem from fb be
edited, shared, etc

Or let's imagine that I am a 0 in web programming and even Web
Components are too complicate for me, I put an empty Google map and
edit/customize it via a Google map editor, there is [3] maybe too but
anyway the use cases are legions.

That's incredible that nobody can see this and that [1] did not get any
echo (this comment I especially dedicate it to some people that will
recognize themselves about some inappropriate comments, not to say more,
they made regarding the subject related to the last paragraph of this post).

The Intent service would then be a visible or a silent Web Component
discussing with the Intent client using postMessage.

Maybe the process could  be instanciated with something specific in href
(as suggested in [2] again) but an Intent object still looks mandatory.

But in case of visible Intent service, the pop-up style looks very ugly
and old, something should be modified so it seems to appear in the
calling page, then the Intent service needs to have the possibility to
become invisible (after login for example).

I don't see any technical difficulty to spec and implement this (except
maybe how to avoid the horrible pop-up effect) and this covers everything.


> If that happens the next step is to change our charter.
> 
> That is an administrative thing that takes a few weeks (largely to ensure
> we get the IPR protection W3C standards can enjoy, which happens because
> we spend the time to do the admin with legal processes) if there is some
> broad-based support.

Unfortunately, despite of our efforts and patience, due to the lack of
agreement on this matter with the related W3C members, unless people
decide to restrict Intents to some trivial edit, share uses of simple
images, text, files, which looks quite limited (but surprisingly seems
enough for Microsoft, Mozilla and Google) and will necessarily end-up
redoing the spec again several years later, the specs will inevitably
cross again the path of the patent you know [4], for parts related to
the extraction mechanisms that time, which anyway the web will one day
implement.


[1]
https://lists.w3.org/Archives/Public/public-web-intents/2014Oct/0001.html
[2]
http://dev.mygrid.org.uk/blog/2014/10/you-want-to-do-what-theres-an-app-for-that/
[3] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/
[4] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0911.html
[5]
https://lists.w3.org/Archives/Public/public-web-intents/2015Oct/.html

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms