Re: IndieUI Teleconference Agenda; 12 November at 22:00Z for 60 minutes

2014-11-11 Thread James Craig 
I’ll be about 30 minutes late tomorrow.



> On Nov 11, 2014, at 5:44 PM, Janina Sajka  wrote:
> 
> Cross-posting as before ...
> 
> What:IndieUI Task Force Teleconference
> When:Wednesday 12 November
> 2:00 PMSan Francisco -- U.S. Pacific (Standard) Time   (PST: UTC 
> -8)
> 4:00 PMAustin -- U.S. Central (Standard) Time(CST: UTC -6)
> 5:00 PMBoston -- U.S. Eastern (Standard) Time(EST: UTC -5)
>10:00 PMLondon -- British (Standard) Time(BST: UTC +0)
>11:00 PMParis -- Central European Time  (CET: UTC +1)
> 6:00 AMBeijing -- China Standard Time (Thursday, 13 November CST: 
> UTC +8)
> 7:00 AMTokyo -- Japan Standard Time(Thursday, 13 November 
> JST: UTC +9)
> Where:W3C Teleconference--See Below
> 
> * Time of day conversions
> 
> Please verify the correct time of this meeting in your time zone using
> the Fixed Time Clock at:
> 
> http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconference&iso=20141112T1700&p1=43&ah=1
> 
> ** Preliminary Agenda for IndieUI Task Force Teleconference 12 November 2014
> 
> Meeting: IndieUI Task Force Teleconference
> Chair:Janina_Sajka
> agenda+ preview agenda with items from two minutes
> agenda+ Holliday Scheduling; November-January
> agenda+Checkin with Web Apps' Editing TF [See below]
> agenda+ Editor's Report
> agenda+Requirements & Use Cases Progress
> agenda+Testing Conversation; Polyfills
> agenda+ User Context Issues & Actions 
> https://www.w3.org/WAI/IndieUI/track/products/3
> agenda+ Events Issues & Actions 
> https://www.w3.org/WAI/IndieUI/track/products/2
> agenda+ Other Business
> agenda+Be Done
> 
> Resource: TPAC Minutes
> Monday:http://www.w3.org/2014/10/27-indie-ui-minutes.html
> Tuesday:http://www.w3.org/2014/10/28-indie-ui-minutes.html
> 
> Resource: Teleconference Minutes
> http://www.w3.org/2014/10/15-indie-ui-minutes.html
> 
> Resource: Web Apps Editing TF
> Editing Explainer:http://w3c.github.io/editing-explainer/
> User Intentions:
> http://w3c.github.io/editing-explainer/commands-explainer.html
> Resource: For Reference
> Home Page:http://www.w3.org/WAI/IndieUI/
> Email Archive:http://lists.w3.org/Archives/Public/public-indie-ui/
> 
> Resource: Teleconference Logistics
> Dial the Zakim bridge using either SIP or the PSTN.
> PSTN: +1.617.761.6200 (This is a U.S. number).
> SIP: za...@voip.w3.org
> You should be prompted for a pass code,
> This is
> 46343#
> (INDIE#)
> 
> Alternatively, bypass the Zakim prompts and SIP directly into our
> teleconference.
> SIP: 0046...@voip.w3.org
> 
> Instructions for connecting using SIP:
> http://www.w3.org/2006/tools/wiki/Zakim-SIP
> Place for users to contribute additional VoIP tips.
> http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips
> 
> IRC: server: irc.w3.org, channel: #indie-ui.
> 
> During the conference you can manage your participation with Zakim
> commands as follows:
>   61# to mute yourself
>   60# to unMute yourself
>   41# to raise your hand (enter speaking queue)
>   40# to lower your hand (exit speaking queue)
> 
> The system acknowledges these commands with a rapid, three-tone
> confirmation.  Mobile phone users especially should use the mute
> function
> if they don't have a mute function in their phone.  But the hand-raising
> function is a good idea for anyone not using IRC.
> 
> * IRC access
> 
> An IRC channel will be available. The server is
> irc.w3.org,
> The port number is 6665 (Note this is not the normal default) and
> The channel is #indie-ui.
> 
> * Some helpful Scribing and Participation Tips
> http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet
> 
> For more on the IRC setup and the robots we use for agenda and speaker
> queuing and for posting the log to the web, see:
> 
> - For RRSAgent, that captures and posts the log with special attention
> to action items:
> http://www.w3.org/2002/03/RRSAgent
> 
> - For Zakim, the IRC interface to the bridge manager, that will
> maintain speaker and agenda queues:
> http://www.w3.org/2001/12/zakim-irc-bot
> 
> - For a Web gateway to IRC you can use if your network administrators
> forbid IRC, see:
> http://www.w3.org/2001/01/cgi-irc
> 
> - For more on W3C use of IRC see:
> http://www.w3.org/Project/IRC/
> 
> -- 
> 
> Janina Sajka,Phone:+1.443.300.2200
>sip:jan...@asterisk.rednote.net
>Email:jan...@rednote.net
> 
> The Linux Foundation
> Chair, Open Accessibility:http://a11y.org
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,Protocols & Formatshttp://www.w3.org/wai/pf
>IndieUIhttp://www.w3.org/WAI/IndieUI/
>

IndieUI Teleconference Agenda; 12 November at 22:00Z for 60 minutes

2014-11-11 Thread Janina Sajka 

Cross-posting as before ...

What:   IndieUI Task Force Teleconference
When:   Wednesday 12 November
 2:00 PMSan Francisco -- U.S. Pacific (Standard) Time   (PST: 
UTC -8)
 4:00 PMAustin -- U.S. Central (Standard) Time  (CST: 
UTC -6)
 5:00 PMBoston -- U.S. Eastern (Standard) Time  (EST: 
UTC -5)
10:00 PMLondon -- British (Standard) Time   (BST: 
UTC +0)
11:00 PMParis -- Central European Time  (CET: 
UTC +1)
 6:00 AMBeijing -- China Standard Time (Thursday, 13 November 
CST: UTC +8)
 7:00 AMTokyo -- Japan Standard Time(Thursday, 13 November 
JST: UTC +9)
Where:  W3C Teleconference--See Below

* Time of day conversions

Please verify the correct time of this meeting in your time zone using
the Fixed Time Clock at:

http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconference&iso=20141112T1700&p1=43&ah=1

** Preliminary Agenda for IndieUI Task Force Teleconference 12 November 2014

Meeting: IndieUI Task Force Teleconference
Chair:  Janina_Sajka
agenda+ preview agenda with items from two minutes
agenda+ Holliday Scheduling; November-January
agenda+ Checkin with Web Apps' Editing TF [See below]
agenda+ Editor's Report
agenda+ Requirements & Use Cases Progress
agenda+ Testing Conversation; Polyfills
agenda+ User Context Issues & Actions 
https://www.w3.org/WAI/IndieUI/track/products/3
agenda+ Events Issues & Actions https://www.w3.org/WAI/IndieUI/track/products/2
agenda+  Other Business
agenda+ Be Done

Resource: TPAC Minutes
Monday: http://www.w3.org/2014/10/27-indie-ui-minutes.html  
Tuesday:http://www.w3.org/2014/10/28-indie-ui-minutes.html

Resource: Teleconference Minutes
http://www.w3.org/2014/10/15-indie-ui-minutes.html

Resource: Web Apps Editing TF
Editing Explainer:  http://w3c.github.io/editing-explainer/
User Intentions:
http://w3c.github.io/editing-explainer/commands-explainer.html

Resource: For Reference
Home Page:  http://www.w3.org/WAI/IndieUI/
Email Archive:  http://lists.w3.org/Archives/Public/public-indie-ui/

Resource: Teleconference Logistics
Dial the Zakim bridge using either SIP or the PSTN.
PSTN: +1.617.761.6200 (This is a U.S. number).
SIP: za...@voip.w3.org
You should be prompted for a pass code,
This is
46343#
(INDIE#)

Alternatively, bypass the Zakim prompts and SIP directly into our
teleconference.
SIP: 0046...@voip.w3.org

Instructions for connecting using SIP:
http://www.w3.org/2006/tools/wiki/Zakim-SIP
Place for users to contribute additional VoIP tips.
http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips

IRC: server: irc.w3.org, channel: #indie-ui.

During the conference you can manage your participation with Zakim
commands as follows:
   61# to mute yourself
   60# to unMute yourself
   41# to raise your hand (enter speaking queue)
   40# to lower your hand (exit speaking queue)

The system acknowledges these commands with a rapid, three-tone
confirmation.  Mobile phone users especially should use the mute
function
if they don't have a mute function in their phone.  But the hand-raising
function is a good idea for anyone not using IRC.

* IRC access

An IRC channel will be available. The server is
irc.w3.org,
The port number is 6665 (Note this is not the normal default) and
The channel is #indie-ui.

* Some helpful Scribing and Participation Tips
http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet

For more on the IRC setup and the robots we use for agenda and speaker
queuing and for posting the log to the web, see:

- For RRSAgent, that captures and posts the log with special attention
to action items:
http://www.w3.org/2002/03/RRSAgent

- For Zakim, the IRC interface to the bridge manager, that will
maintain speaker and agenda queues:
http://www.w3.org/2001/12/zakim-irc-bot

- For a Web gateway to IRC you can use if your network administrators
forbid IRC, see:
http://www.w3.org/2001/01/cgi-irc

- For more on W3C use of IRC see:
http://www.w3.org/Project/IRC/

--

Janina Sajka,   Phone:  +1.443.300.2200
sip:jan...@asterisk.rednote.net
Email:  jan...@rednote.net

The Linux Foundation
Chair, Open Accessibility:  http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,  Protocols & Formats http://www.w3.org/wai/pf
IndieUI http://www.w3.org/WAI/IndieUI/

Re: New approach to activities/intents

2014-11-11 Thread Brendan Eich 

Dimitri Glazkov wrote:
I thought about this a bit and realized that we first need to have a 
common criteria to evaluate whether we even need something like Tubes. 
That should be done before we get into mechanics of the solution. I 
apologize for jumping the gun. And I apologize even more to poor op 
whose conversation we hijacked.


So I came up with the following Capability Availability Success Criteria:

Given any capability on a modern computing device and a developer who 
wants to use it, what is a) the acceptable delay between when this 
capability becomes available on the web platform vs. first being 
available on a native platform, and b) the likelihood that this 
capability will ever be available on the web platform.


If we're aiming at "years, not months", and "60-80%", then we're 
already successful.


If we're hoping to hit "weeks, not months" and "100%", we need 
something like Tubes.


If it's something in between, maybe there are other options.


There are definitely other options. I think you've backed yourself into 
a dialectical corner. MessagePorts are not the primitive droids we're 
looking for! For one, JS SIMD cannot and should not use them. Even 
witha  sync-on-this-async-API-call general API, they are not the right 
droid.


I see roc has replied (we are not communicating via back-channels) so 
I'll stop here.


The actor model is beautiful and in part true, but it's not workers or 
MessagePorts, and it's not the right droid. Even if we add actors to the 
web platform, we will need to make particular, non-actor, synchronous 
API additions. These require careful design and (multiple browser) 
implementation with web developer feedback validation. Sorry, no easy 
answers. I do not think we need weeks not months, in any event (as noted 
vs. native stacks). We need intentional design with user (web dev) testing.


/be

Re: CfC: publish a WG Note of Fullscreen; deadline November 14

2014-11-11 Thread Tab Atkins Jr. 
On Sat, Nov 8, 2014 at 5:43 AM, Domenic Denicola  wrote:
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
>> OK, so I just checked in a patch that sets the Latest Editor's Draft points 
>> to Anne's document
>> .
>
> I think it would be ideal to change the label to e.g. "See Instead" or 
> "Maintained Version" or "Replaced By". Framing the WHATWG as a source of 
> Editor's Drafts for the W3C is unnecessarily combative.

I use a "replaced by" wording on specs I've moved elsewhere; see
 for an example.

~TJ

Clarification of CSP sandbox and workers

2014-11-11 Thread Deian Stefan 

Hey guys,

I am implementing CSP for Workers in Firefox, but like to get a
clarification on workers and the sandbox flag. Currently, a Worker can
inherit or be accompanied by a CSP header. As written, the implications
of the sandbox directive on the Worker context is not clear.

[Following up on https://github.com/w3c/webappsec/issues/69]

Arguably most of the sandbox flags don't make sense for Workers, but the
empty directive (i.e., just sandbox) and sandbox allow-same-origin can
have reasonable semantics.  So, if a Worker inherits the CSP from the
owner document (or parent worker in later specs) or is accompanied by a
CSP header which has the 'sandbox' directive, should the worker script's
origin be set to a unique origin?  Or should we just ignore (and
appropriately warn about) the sandbox flag for Workers and address the
need for sandboxed Workers separately?

Thanks,
Deian


signature.asc
Description: PGP signature

[Bug 27259] [Custom]: custom element constructor generation algorithm doesn't do anything with REGISTRY

2014-11-11 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27259

Dimitri Glazkov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dimitri Glazkov  ---
https://github.com/w3c/webcomponents/commit/d09f30fd57a8bae02dc76049b714df75b2443928

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Bringing APIs for experimental hardware/software to the Web

2014-11-11 Thread Dimitri Glazkov 
On Tue, Nov 11, 2014 at 3:01 PM, Robert O'Callahan 
wrote:

> On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov 
> wrote:
>
>> Given any capability on a modern computing device and a developer who
>> wants to use it, what is a) the acceptable delay between when this
>> capability becomes available on the web platform vs. first being available
>> on a native platform, and b) the likelihood that this capability will ever
>> be available on the web platform.
>>
>> If we're aiming at "years, not months", and "60-80%", then we're already
>> successful.
>>
>> If we're hoping to hit "weeks, not months" and "100%", we need something
>> like Tubes.
>>
>
> I don't think we should set targets for a) and b) and hit those targets no
> matter what the cost. We need to do the hard work of evaluating tradeoffs
> case by case. I assume everyone agrees that when there are no hard
> tradeoffs to make, of course we'd like to have nice things.
>
> We can have a productive discussion about how to bring APIs for
> experimental hardware and software to the Web faster. Subject changed to
> suit. Here's my problem statement:
>
> We have a set of traditional goals for the Web platform: backward
> compatibility, device independence, multiple interoperable implementations,
> long-term durability, coherence, ease of use, safety, etc. People
> frequently release new hardware and software with new capabilities that
> don't fit into existing Web APIs. Can we expose these capabilities to Web
> developers with very low delay, without violating some of our existing
> goals? If we can't, what tradeoffs are we willing to make?
>
> If this is the discussion you want to have, then I will reveal some ideas
> :-).
>

I think that's a reasonable problem statement. There are two problems with
it:

1) it makes an assumption that everyone on this forum wants very low delay
and all capabilities. I don't know if that is true, though I definitely
want to believe it.

2) it's not as focused as my formulation on actually setting a target for
ourselves, which makes me worried we'll end up in the same loosely
incoherent state we always end up.

Nevertheless, I am optimistic. I would like to have this discussion and
hear your ideas.

:DG<

Bringing APIs for experimental hardware/software to the Web

2014-11-11 Thread Robert O'Callahan 
On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov 
wrote:

> Given any capability on a modern computing device and a developer who
> wants to use it, what is a) the acceptable delay between when this
> capability becomes available on the web platform vs. first being available
> on a native platform, and b) the likelihood that this capability will ever
> be available on the web platform.
>
> If we're aiming at "years, not months", and "60-80%", then we're already
> successful.
>
> If we're hoping to hit "weeks, not months" and "100%", we need something
> like Tubes.
>

I don't think we should set targets for a) and b) and hit those targets no
matter what the cost. We need to do the hard work of evaluating tradeoffs
case by case. I assume everyone agrees that when there are no hard
tradeoffs to make, of course we'd like to have nice things.

We can have a productive discussion about how to bring APIs for
experimental hardware and software to the Web faster. Subject changed to
suit. Here's my problem statement:

We have a set of traditional goals for the Web platform: backward
compatibility, device independence, multiple interoperable implementations,
long-term durability, coherence, ease of use, safety, etc. People
frequently release new hardware and software with new capabilities that
don't fit into existing Web APIs. Can we expose these capabilities to Web
developers with very low delay, without violating some of our existing
goals? If we can't, what tradeoffs are we willing to make?

If this is the discussion you want to have, then I will reveal some ideas
:-).

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Re: New approach to activities/intents

2014-11-11 Thread Dimitri Glazkov 
On Tue, Nov 11, 2014 at 12:28 PM, Robert O'Callahan 
wrote:

> I still don't see how exposing an API via MessagePorts is in any way
> better than exposing an API via WebIDL. Can you describe with concrete
> examples how this makes life better for implementors or authors? I've read
> your presentation but I did not see the answer there.
>
> Furthermore I don't see any necessary connection between MessagePorts vs
> WebIDL and the issues around rapidly bringing experimental APIs to the Web.
> Are you claiming that it's quicker and easier to add MesagePort-based APIs
> to browsers than using WebIDL?
>

I would like to state explicitly that as of
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0376.html, I
withdraw the proposal of Tubes as the exact solution to the problem in lieu
of the need to first formulate a decent problem statement -- in the form of
the criteria I proposed.

:DG<

Re: New approach to activities/intents

2014-11-11 Thread Robert O'Callahan 
I still don't see how exposing an API via MessagePorts is in any way better
than exposing an API via WebIDL. Can you describe with concrete examples
how this makes life better for implementors or authors? I've read your
presentation but I did not see the answer there.

Furthermore I don't see any necessary connection between MessagePorts vs
WebIDL and the issues around rapidly bringing experimental APIs to the Web.
Are you claiming that it's quicker and easier to add MesagePort-based APIs
to browsers than using WebIDL?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Re: New approach to activities/intents

2014-11-11 Thread Dimitri Glazkov 
On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich 
wrote:

> Dimitri Glazkov wrote:
>
>> Domenic's question still needs addressing separately, but just a quick
>> response here -- the API roc described there is different. Tubes are just
>> like talking to a worker or any MessagePort. There is no extra API surface
>> emerging from getContext-like function call.
>>
>
> Any getContext or postMessage protocol is inherently not
> object-detectable, at least not at the string-keyed level.
>
> In principal, as bz said, the tension between extensions and standards
> motivates supporting extensions, and I share your desire to support
> experimentation so long as it is consensus-oriented. We want to avoid
> overlarge jumps by one proprietor, who both risks failing to bring along
> competitors step by step, and seeming to abuse any market power it may
> possess.
>
> So we want to support extension, extensibility, in ways that don't lead to
> bad game-theoretic and real-world outcomes, e.g. ActiveX PKI in Korea.
> There's no silver bullet or algorithm to do this, but API style matters
> (object detection vs. non-detection; gentle-peoples' agreements about how
> proprietary/particular an API to try).
>
> The JS SIMD work definitely experiences this tension. Do we want a union
> of all (SSE, NEON, AVX2) vector instructions? Intersection may be too
> small, and emulation may be too slow to be worth using. The
> http://github.com/johnmccutchan/ecmascript_simd issues cover this well,
> and show good particularized thinking.
>
> To particularize without object detection is hard.
>
> In any event, IMHO native stacks are not killing the Web, nor are native
> stacks evolving willy-nilly on random and arbitrarily rapid schedules or
> via message-based API settings. Apple and Android are at most annual
> big-release OSes, e.g. I welcome counterexamples.
>
> Sorry to be skeptical. Object detection, extensible-web-manifesto
> low-level APIs, avoiding indefinitely scoped or "lifetime" proprietary
> extension mechanisms in favor of incrementalism, all seem better to me.
>
> /be
>


I would like to reframe this conversation in a slightly more layered
context. Your scepticism is appreciated, but I also would like to make sure
we're on the same page in regard to "the tension" and our collective
understanding of the situation. So, here goes.

I thought about this a bit and realized that we first need to have a common
criteria to evaluate whether we even need something like Tubes. That should
be done before we get into mechanics of the solution. I apologize for
jumping the gun. And I apologize even more to poor op whose conversation we
hijacked.

So I came up with the following Capability Availability Success Criteria:

Given any capability on a modern computing device and a developer who wants
to use it, what is a) the acceptable delay between when this capability
becomes available on the web platform vs. first being available on a native
platform, and b) the likelihood that this capability will ever be available
on the web platform.

If we're aiming at "years, not months", and "60-80%", then we're already
successful.

If we're hoping to hit "weeks, not months" and "100%", we need something
like Tubes.

If it's something in between, maybe there are other options.

Setting the bar in terms of these numbers seems like a very charter-ey
thing to decide and agree upon. We should probably do that.

:DG<

PSA: publishing new WD of Service Workers on November 13

2014-11-11 Thread Arthur Barstow 
Jungkee and Alex created a new Working Draft of Service Workers for 
publication as a Technical Report on November 13:


  



If anyone has any major concerns this proposal, please speak up as soon 
as possible.


-Thanks, AB