RfC: LCWD of Media Capture and Streams; deadline May 15

[Arthur Barstow]

Hi All,

WebApps has been asked to review and submit comments for the April 14 
Last Call Working Draft of WebRT and DAP's Media Capture and Streams spec:




WebApps is specifically mentioned re "the overall usage of Web IDL and 
the definition of error handling".


If anyone in WebApps wants to propose an official group response, please 
do so ASAP, in reply to this e-mail so the group can discuss it.


Comments should be sent to public-media-capture @ w3.org [1] by May 15. 
Presumably, the groups also welcome "silent review" type data such as "I 
reviewed section N.N and have no comments".


-Thanks, ArtB

[1] https://lists.w3.org/Archives/Public/public-media-capture/


On 4/15/15 1:31 AM, Stefan Håkansson LK wrote:

The WebRTC and Device APIs Working Groups request feedback on the Last
Call Working Draft of Media Capture and Streams, a JavaScript API that
enables access to cameras and microphones from Web browsers as well as
control of the use of the data generated (e.g. rendering what a camera
captures in a html video element):
http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/

The groups have identified the following other W3C Working Groups as
likely sources of feedback:

- HTML Working Group, especially the HTML Media Task Force, as our API
extends the HTMLMediaElement interface and defines a new type of media
input via MediaStream

- WebApps Working Group, especially on the overall usage of Web IDL and
the definition of error handling
Audio Working Group, as the Web Audio API builds upon the MediaStream
interface

- WAI Protocol and Formats Working Group, especially on the impact of
the user consent dialog and the applicability of the indicators of
device usage in assistive tools

- Web and TV Interest Group, as the manipulation of media input can be
relevant to some of their use cases (e.g. glass to glass)

- Web App Security Working Group, especially on our links between
secured origins and persistent permissions, and our current policy with
regard to handling access to this "powerful feature"

- Web Security Interest Group, especially on our security considerations
Privacy Interest Group, as access to camera and microphone has strong
privacy implications

- Technical Architecture Group, for an overall review of the API,
especially the introduction of the concept of a IANA registry-based
constraints system, the use of promises, and our handling of persistent
permissions

We naturally also welcome feedback from any other reviewers.

The end of last call review for this specification is set to May 15
2015; should that deadline prove difficult to meet, please get in touch
so that we can determine a new deadline for your group.

As indicated in the document, comments should be sent to the
public-media-capt...@w3.org mailing list.

Thanks,

Frederick Hirsch, Device APIs Working Group Chair,
Harald Alvestrand and Stefan Hakansson, WebRTC Working Group Chairs and
Media Capture Task Force Chairs

Re: Mozilla and the Shadow DOM

[Anne van Kesteren]

On Wed, Apr 8, 2015 at 8:17 AM, Anne van Kesteren  wrote:
> * Multiple shadow roots. We'd like to retain this feature.
> Although it has complexity, we've heard from both Firefox UI and
> Firefox OS application developers that the moment your library gets
> sophisticated, you want this for extensibility.

I was asked to provide a use case for our stance. One that we've found
with Firefox OS is custom dialogs, quoting Wilson Page:

# I have an  component. It takes care of transitioning
# in and out of the viewport and appropriate styling contained
# elements (, , ).
#
# I want to be able to extend this component to produce
# . In this case extending the prototype alone
# isn't enough, I need to also be able to extend the markup
# and styling of .
#
# At the point of creation  can add a second
# ShadowRoot that allows it to compose its own content
# inside that of the 'old'  ShadowRoot. Without this
#  would have to duplicate all the markup, style
# and interaction code again.


-- 
https://annevankesteren.nl/

PSA: publishing new WD of File API on April 21

[Arthur Barstow]

Hi All,

A new Working Draft publication of File API is planned for April 21 
using the following version as the basis:


 

If anyone has any major concerns about this, please reply right away.

A few notes about this spec:

* This spec is now using Github  and the 
ED is . PRs are welcome and 
encouraged. (I think it would be useful if this spec used ReSpec and if 
anyone can help with that port, please do contact me.)


* The permissions of the spec's now obsolete CVS repository will be set 
to read-only.


* After the Editors copy the open Bugzilla bugs [1] to Github Issues (or 
the last open Bugzilla bug is closed), the spec's Bugzilla component 
will be marked `Historical` and set to read-only.


-Thanks, ArtB

[1] 

Re: PSA: publishing new WD of File API on April 21

[Arthur Barstow]

On 4/15/15 10:23 AM, Arthur Barstow wrote:

* This spec is now using Github 


That repo is actually .

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow  wrote:
> * This spec is now using Github  and the ED
> is . PRs are welcome and
> encouraged. (I think it would be useful if this spec used ReSpec and if
> anyone can help with that port, please do contact me.)

This was actually already next on my list of specs to Bikeshed, as
soon as I finish DOM (which I'm doing as I type this).  WebIDL-heavy
specs benefit a lot from being Bikeshedded, so all the IDL definitions
get properly marked up for the linking database. ^_^

~TJ

Re: PSA: publishing new WD of File API on April 21

[Arthur Barstow]

On 4/15/15 3:09 PM, Tab Atkins Jr. wrote:

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow  wrote:

* This spec is now using Github  and the ED
is . PRs are welcome and
encouraged. (I think it would be useful if this spec used ReSpec and if
anyone can help with that port, please do contact me.)

This was actually already next on my list of specs to Bikeshed, as
soon as I finish DOM (which I'm doing as I type this).  WebIDL-heavy
specs benefit a lot from being Bikeshedded, so all the IDL definitions
get properly marked up for the linking database. ^_^


:-).

Arun , Jonas - unless we otherwise from you, we'll assume this is `all 
good` from your perspective.


-Thanks, AB

Re: PSA: publishing new WD of File API on April 21

[Martin Thomson]

On 15 April 2015 at 07:26, Arthur Barstow  wrote:
>> * This spec is now using Github 
>
>
> That repo is actually .


Since the most obvious github.io link is currently broken, would it
make sense to move Overview.html to index.html?  Does the name
Overview.html hold special meaning?

Re: IndieUI Teleconference Agenda; 15 April at 21:00Z

[Andy Heath]

apologies -andy

On 14/04/2015 20:40, Janina Sajka wrote:

Cross-posting as is usual ...

What:IndieUI Task Force Teleconference
When:Wednesday 15 April
  2:00 PMSan Francisco -- U.S. Pacific  Time(PDT: UTC -7)
  4:00 PMAustin -- U.S. Central  Time(CDT: UTC -5)
  5:00 PMBoston -- U.S. Eastern  Time(EDT: UTC -4)
 10:00 PMLondon -- British  Time(BST: UTC +1)
 11:00 PMParis -- Central European Time(CET: UTC +2)
  5:00 AMBeijing -- China Standard Time(Thursday, 16
April CST: UTC +8)
  6:00 AMTokyo -- Japan Standard Time(Thursday, 16 April
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=20150415T1700&p1=43&ah=1


** Preliminary Agenda for IndieUI Task Force Teleconference 15 April 2015

Meeting: IndieUI Task Force Teleconference
Chair:Janina_Sajka
agenda+ preview agenda with items from two minutes
agenda+ Editors' Reports
agenda+Checkin with Web Apps' Editing TF [See below]
agenda+Future of IndieUI Work (Continued)
agenda+Schema.org Mappings (Continued) -- Rich & Andy [See Below]
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: Teleconference Minutes
http://www.w3.org/2015/04/01-indie-ui-minutes.html

Resource: Results from WBS Survey on IndieUI's Future
https://www.w3.org/2002/09/wbs/54997/201503_planning/results

Resource: Schema.org meta data mapping to Indie UI User context
https://docs.google.com/spreadsheets/d/1pb92piOlud5sXQadXYnbmtp9LCut26gv8ku-qqZTwec/edit#gid=0


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/



--
Andy Heath : andyhe...@axelafa.com : http://axelafa.com

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 12:54 PM, Martin Thomson
 wrote:
> On 15 April 2015 at 07:26, Arthur Barstow  wrote:
>>> * This spec is now using Github 
>>
>>
>> That repo is actually .
>
>
> Since the most obvious github.io link is currently broken, would it
> make sense to move Overview.html to index.html?  Does the name
> Overview.html hold special meaning?

No, it's just an older tradition for specs in some working groups.  I
also recommend using index.html as the generated file name (and am
doing so in my Bikeshedding, which is now underway).

~TJ

Re: PSA: publishing new WD of File API on April 21

[Arthur Barstow]

On 4/15/15 3:54 PM, Martin Thomson wrote:

On 15 April 2015 at 07:26, Arthur Barstow  wrote:

* This spec is now using Github 


That repo is actually .


Since the most obvious github.io link is currently broken, would it
make sense to move Overview.html to index.html?


That would be fine with me (we've already done that for a few specs 
we've recently migrated to Github) and it seems like a reasonable `best 
practice` to follow.



  Does the name
Overview.html hold special meaning?


We'll have to ask the Editors and I believe Jonas is OOO now and Arun is 
part-time. I filed an Issue so they can provide some input and if I 
don't hear otherwise from them, I'll plan to make the filename change 
before the new WD is published.


-Thanks, AB

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow  wrote:
> Hi All,
>
> A new Working Draft publication of File API is planned for April 21 using
> the following version as the basis:
>
>  

Note that this version appears to be based off the 
file in the CVS repo, which hasn't been touched in 5 years.  The file
 is much more recent and appears to be what the
current file at  is based on (note the
relative positions of the FileList and Blob sections - in
Overview-FA.xml and the current TR, FileList comes first).  I suspect,
then, that the file you're referencing is out-of-date and shouldn't be
used.

~TJ

Re: PSA: publishing new WD of File API on April 21

[Arthur Barstow]

On 4/15/15 5:56 PM, Tab Atkins Jr. wrote:

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow  wrote:

  

Note that this version appears to be based off the 
file in the CVS repo, which hasn't been touched in 5 years.  The file
 is much more recent and appears to be what the
current file at  is based on (note the
relative positions of the FileList and Blob sections - in
Overview-FA.xml and the current TR, FileList comes first).  I suspect,
then, that the file you're referencing is out-of-date and shouldn't be
used.


I didn't use either of those files but Overview.html, as directed by Arun.

(He told me he stopped editing the Overview-FA.xml file some type ago).

-Thanks, AB

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 3:00 PM, Arthur Barstow  wrote:
> On 4/15/15 5:56 PM, Tab Atkins Jr. wrote:
>>
>> On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow 
>> wrote:
>>>
>>>   
>>
>> Note that this version appears to be based off the 
>> file in the CVS repo, which hasn't been touched in 5 years.  The file
>>  is much more recent and appears to be what the
>> current file at  is based on (note the
>> relative positions of the FileList and Blob sections - in
>> Overview-FA.xml and the current TR, FileList comes first).  I suspect,
>> then, that the file you're referencing is out-of-date and shouldn't be
>> used.
>
>
> I didn't use either of those files but Overview.html, as directed by Arun.
>
> (He told me he stopped editing the Overview-FA.xml file some type ago).

Oh god, you're right, it looks like Arun has been directly editting
the generated HTML since Jan 2013.  Confusingly, there's a single
commit to Overview-FA.xml in Nov 2014 which just updates the
Prev/Current links in the header; the immediately preceding commit is
from Jan 2013, though, while Overview.html has been editted repeatedly
in that span.

Ugh, working with the XML was a lot easier.  Darn.

Arun, buddy, I'm sorry you had to go through the pain of directly
editting generated HTML.

~TJ

[Bug 28496] New: Allow Blob constructor to take ownership of ArrayBuffer(View) / invoke DetachArrayBuffer

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28496

Bug ID: 28496
   Summary: Allow Blob constructor to take ownership of
ArrayBuffer(View) / invoke DetachArrayBuffer
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
  Assignee: a...@mozilla.com
  Reporter: bugm...@asutherland.org
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org

Motivation: For the Firefox OS email app when we download attachments we end up
with a lot of TypedArray instaces piling up that exist only to be wrapped into
a Blob and then forgotten.  Lacking any way to neuter ArrayBuffers directly, it
would be nice if the Blob could takeownership of them as we pass them in.

Arguably it could be considered a common data-flow to create some data with a
TypedArray and then stuff it in a Blob to store it somewhere

Risks:
- I guess the 2-step process of "new Blob(takingOwnership).close()" could end
up as a disturbingly hacky general purpose means of disposing of the contents
of TypedArrays.

Mitigation strategies:
- In our specific case we are using the proprietary-mozTCPSocket that just
throws typed arrays at us, but I understand the Streams API provides a
mechanism to allow reads into existing buffers.  APIs that allow use of
existing buffers won't suffer from the "oh no, so many ArrayBuffers!" problem.
- GC will catch the stuff eventually.  Just crank up the GC.

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

Re: Mozilla and the Shadow DOM

[Elliott Sprehn]

On Wed, Apr 15, 2015 at 6:30 AM, Anne van Kesteren  wrote:

> On Wed, Apr 8, 2015 at 8:17 AM, Anne van Kesteren 
> wrote:
> > * Multiple shadow roots. We'd like to retain this feature.
> > Although it has complexity, we've heard from both Firefox UI and
> > Firefox OS application developers that the moment your library gets
> > sophisticated, you want this for extensibility.
>
> I was asked to provide a use case for our stance. One that we've found
> with Firefox OS is custom dialogs, quoting Wilson Page:
>
> # I have an  component. It takes care of transitioning
> # in and out of the viewport and appropriate styling contained
> # elements (, , ).
> #
> # I want to be able to extend this component to produce
> # . In this case extending the prototype alone
> # isn't enough, I need to also be able to extend the markup
> # and styling of .
> #
> # At the point of creation  can add a second
> # ShadowRoot that allows it to compose its own content
> # inside that of the 'old'  ShadowRoot. Without this
> #  would have to duplicate all the markup, style
> # and interaction code again.
>
>
I don't think you need to duplicate anything. The super class can still
fill in the original shadow root, then the subclass can modify it. This is
the same concept of the prototype inheritance, your methods will shadow the
super class methods, but you can just call them and then extend the
behavior.

This is also the reason the created and attached callbacks are on the
prototype. So you can call super and use the parent behavior by shared
protocol.

- E

Re: Mozilla and the Shadow DOM

[Anne van Kesteren]

On Thu, Apr 16, 2015 at 2:41 AM, Elliott Sprehn  wrote:
> I don't think you need to duplicate anything. The super class can still fill
> in the original shadow root, then the subclass can modify it. This is the
> same concept of the prototype inheritance, your methods will shadow the
> super class methods, but you can just call them and then extend the
> behavior.

In this case the subclass would have to poke into the superclass'
shadow DOM. If at any point those writing the superclass decide to
change the structure of that DOM they might end up breaking a subclass
they had no knowledge of. Allowing insertion of the whole shadow DOM
allows for changes that have fewer side effects.

Having said that, if your comment means that Google is no longer
interested in keeping this, we can probably be persuaded to keep this
out of a cross-browser v1 of shadow DOM.


-- 
https://annevankesteren.nl/

[Imports] Considering imperative HTML imports?

[Travis Leithead]

Was an imperative form of HTML imports already considered? E.g., the following 
springs to mind:
  Promise importDocument(DOMString url);

I was thinking about Worker's importScripts(DOMString... urls), and the above 
seems like a nice related corollary.

Re: [Imports] Considering imperative HTML imports?

[Dominic Cooney]

On Thu, Apr 16, 2015 at 1:37 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Was an imperative form of HTML imports already considered? E.g., the
> following springs to mind:
>
>   Promise importDocument(DOMString url);
>
>
>
> I was thinking about Worker’s importScripts(DOMString… urls), and the
> above seems like a nice related corollary.
>

One big difference, I'm assuming, is whether it's asynchronous. Returning a
Promise kind of implies that importDocument may be/is asynchronous.

The trend seems to be away from adding synchronous APIs, but then you can't
express  (ie no 'async') using this API. I
think the declarative, script-blocking element is more palatable than a
synchronous method because the UA can process it when there's no user
script running.

Dominic