Re: Mozilla and the Shadow DOM
On Wed, Apr 8, 2015 at 8:17 AM, Anne van Kesteren ann...@annevk.nl 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 x-dialog component. It takes care of transitioning # in and out of the viewport and appropriate styling contained # elements (h1, button, p). # # I want to be able to extend this component to produce # x-dialog-alert. In this case extending the prototype alone # isn't enough, I need to also be able to extend the markup # and styling of x-dialog. # # At the point of creation x-dialog-alert can add a second # ShadowRoot that allows it to compose its own content # inside that of the 'old' x-dialog ShadowRoot. Without this # x-dialog-alert would have to duplicate all the markup, style # and interaction code again. -- https://annevankesteren.nl/
Re: PSA: publishing new WD of File API on April 21
On 4/15/15 10:23 AM, Arthur Barstow wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ That repo is actually https://github.com/w3c/FileAPI/.
PSA: publishing new WD of File API on April 21
Hi All, A new Working Draft publication of File API is planned for April 21 using the following version as the basis: https://w3c.github.io/FileAPI/TR.html If anyone has any major concerns about this, please reply right away. A few notes about this spec: * This spec is now using Github https://w3c.github.io/FileAPI/ and the ED is https://w3c.github.io/FileAPI/Overview.html. 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] https://www.w3.org/Bugs/Public/buglist.cgi?component=File%20APIlist_id=54713product=WebAppsWGresolution=---
Re: IndieUI Teleconference Agenda; 15 April at 21:00Z
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+Teleconferenceiso=20150415T1700p1=43ah=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
On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ and the ED is https://w3c.github.io/FileAPI/Overview.html. 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
On 15 April 2015 at 07:26, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ That repo is actually https://github.com/w3c/FileAPI/. 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: PSA: publishing new WD of File API on April 21
On 4/15/15 3:09 PM, Tab Atkins Jr. wrote: On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ and the ED is https://w3c.github.io/FileAPI/Overview.html. 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
On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: Hi All, A new Working Draft publication of File API is planned for April 21 using the following version as the basis: https://w3c.github.io/FileAPI/TR.html Note that this version appears to be based off the Overview-FAWD.xml file in the CVS repo, which hasn't been touched in 5 years. The file Overview-FA.xml is much more recent and appears to be what the current file at http://www.w3.org/TR/FileAPI/ 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
On 4/15/15 5:56 PM, Tab Atkins Jr. wrote: On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: https://w3c.github.io/FileAPI/TR.html Note that this version appears to be based off the Overview-FAWD.xml file in the CVS repo, which hasn't been touched in 5 years. The file Overview-FA.xml is much more recent and appears to be what the current file at http://www.w3.org/TR/FileAPI/ 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
[Bug 28496] New: Allow Blob constructor to take ownership of ArrayBuffer(View) / invoke DetachArrayBuffer
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: PSA: publishing new WD of File API on April 21
On Wed, Apr 15, 2015 at 3:00 PM, Arthur Barstow art.bars...@gmail.com wrote: On 4/15/15 5:56 PM, Tab Atkins Jr. wrote: On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote: https://w3c.github.io/FileAPI/TR.html Note that this version appears to be based off the Overview-FAWD.xml file in the CVS repo, which hasn't been touched in 5 years. The file Overview-FA.xml is much more recent and appears to be what the current file at http://www.w3.org/TR/FileAPI/ 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
Re: Mozilla and the Shadow DOM
On Thu, Apr 16, 2015 at 2:41 AM, Elliott Sprehn espr...@chromium.org 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/
Re: [Imports] Considering imperative HTML imports?
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: PromiseDocument 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 link rel=import src=... (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
[Imports] Considering imperative HTML imports?
Was an imperative form of HTML imports already considered? E.g., the following springs to mind: PromiseDocument importDocument(DOMString url); I was thinking about Worker's importScripts(DOMString... urls), and the above seems like a nice related corollary.
Re: PSA: publishing new WD of File API on April 21
On 4/15/15 3:54 PM, Martin Thomson wrote: On 15 April 2015 at 07:26, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ That repo is actually https://github.com/w3c/FileAPI/. 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
On Wed, Apr 15, 2015 at 12:54 PM, Martin Thomson martin.thom...@gmail.com wrote: On 15 April 2015 at 07:26, Arthur Barstow art.bars...@gmail.com wrote: * This spec is now using Github https://w3c.github.io/FileAPI/ That repo is actually https://github.com/w3c/FileAPI/. 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
[Bug 28493] New: [Shadow]: Have a common interface between Document and ShadowRoot
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493
Bug ID: 28493
Summary: [Shadow]: Have a common interface between Document and
ShadowRoot
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: hay...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978
# This is separated from
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27829#c2
Instead of defining these in Shadow Root as well as in Document, I've started
to feel that it'd be better that we have the common interface between Document
and Shadow Root.
e.g.
interface NodeTreeRoot {
Element? elementFromPoint(double x, double y);
sequenceElement elementsFromPoint(double x, double y);
CaretPosition? caretPositionFromPoint(double x, double y);
Selection? getSelection ();
readonlyattribute Element? activeElement;
readonlyattribute StyleSheetList styleSheets;
};
Document implements NodeTreeRoot;
ShadowRoot implements NodeTreeRoot;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 27829] [Shadow]: Update ShadowRoot to have elementsFromPoint and caretPositionFromPoint
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27829 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Hayato Ito hay...@chromium.org --- Let me close this bug. I've filed a bug for comment #2 as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 21066] Provide an event path API
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21066 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Assignee|dglaz...@chromium.org |hay...@chromium.org --- Comment #67 from Hayato Ito hay...@chromium.org --- Let me close this bug because all issues were resolved or filed as a separate bug. Let's focus each bug separately and close this bug. -- You are receiving this mail because: You are on the CC list for the bug.
RfC: LCWD of Media Capture and Streams; deadline May 15
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: http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/ 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
