Re: Proposal for a Permissions API
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
I'm generally supportive of this direction.
I'm not sure that that the PermissionStatus thing is needed. For
example in order to support bluetooth is might be better to make the
call look like:
permissions.has(bluetooth, fitbit).then(...);
That's more Permission than PermissionStatus, right?
What you proposed here would probably be something like that in WebIDL:
Promise has(PermissionName name, any options);
But really, we could make that option bag be a dictionary because it
gives good context about what you are passing like what does fitbit
means here? Is that a black listed device or a white listed one? The one
you want to target?
I agree that it might be unusual to have a required name than might
often be used alone but it makes the API way more javascript-y and self
explanatory. IMO, this call is nicer to read than the one you wrote
above:
permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.
On Wed, 3 Sep 2014, at 05:45, Boris Zbarsky wrote:
On 9/2/14, 9:51 AM, Mounir Lamouri wrote:
required PermissionName name;
Glad to see required being put to good use. ;)
Let say that required was added at the right time. My draft had this
odd requirement before ;)
interface PermissionManager {
IDL nit: This needs Exposed=(Window,Worker)
[NoInterfaceObject, Exposed=Window,Worker]
And parens.
The proposal in the document has been updated accordingly.
On Wed, 3 Sep 2014, at 07:10, Dave Raggett wrote:
Have you considered making this return a promise, as per Nikhil's
proposal:
It does. navigator.permissions.has({}) returns a
PromisePermissionStatus.
p.s. I will bring your idea to the trust permissions in the open web
platform meeting, we're holding in Paris this week, see:
Adrienne Felt from Chrome Security will be representing Google at that
meeting. She should be able to present the proposal and answer any
questions about it. It was on purpose sent before the meeting FWIW.
-- Mounir
Re: =[xhr]
I would like to emphasise the detrimental effect that the proposed experimentation would have on a large number of sites across Chemistry research and education that would mysteriously stop working when users (automatically) upgraded their browsers and JSmol ceased to function. JSmol is used so widely because it gets away from the historic need for a specific browser version and a specific plugin or Java installation and works across all browsers and platforms. Examples of critical sites that would be broken/have to be rebuilt include UK National Chemical Database Service http://cds.rsc.org notably CSD, ICSD, ChemSpider, CrystalWorks I should also declare a vested interest as my own Open Educational Resource ChemTube3D depends on JSmol, which supports the teaching of Chemistry in Liverpool and across the world. There were more than 590,000 visitors (up 48% on the previous year) from 209 countries in the last year of operation. -- Nick Greevesvia OS X Mail Director of Teaching and Learning Department of Chemistry University of Liverpool Donnan and Robert Robinson Laboratories Crown Street, LIVERPOOL L69 7ZD U.K. Email address:ngree...@liverpool.ac.ukmailto:ngree...@liverpool.ac.uk WWW Pages:http://www.chemtube3d.com Tel:+44 (0)151-794-3506 (3500 secretary) Dept Fax: +44 (0)151-794-3588
Re: =[xhr]
Yes, sure, a lot of it can be done asynchronously. And I do that as much as possible. But I suggest there are times where synchronous transfer is both appropriate and necessary. The case in point is 50 levels deep in the stack of function calls when a new Java class is needed. This statement is inacurate; if you conceptualize your Java-to-JavaScript conversion to use Async calls where normal calls are done in Java, you should not suffer from any issue. As C# did show, every single piece of high-level code can be transformed in an asynchronous one by the mean of a state machine, which can be auto-generated from the initial code without any major syntax change. Sure, this will require a large rewrite of the conveter you are currently using, and this is a non-trivial work not a lot of people can achieve today, but I think everyone here understands that. We don't expect you to make the switch overnight, nor in the coming months. The reason we don't expect this is that neither the browser implementation of the concepts nor the developer tools and experience with the technology required for this rewrite are tailored for a broad usage at this time. I think everyone also understands the old code relying on sync xhr will take a lot of time to go away. But, eventually, browsers will have to break sites. The hope is to reduce the amount of sites over time, by the use of scary warnings like this. What you need to understand is that this feature will eventually be removed from the web platform, and therefore spec writers already warn now of what shall be done in the future, so that the phasing out will work the same way accross all browsers. This doesn’t mean this phasing out is planned anytime soon, but at least people will have received a fair warning for a long time when such phasing out will happen. If you rely on synchronous xhr calls for your Java-to-Javascript converter, you would better schedule in the coming years a rewrite that makes use of async/await calls.
Re: {Spam?} Re: [xhr]
On 9/2/14 9:10 PM, Brendan Eich wrote: cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should set some sense of expectation about*when* it won't work. Different parts of the Web move on different timelines. Right. Given this, it seems like the current Note should indeed be updated to reflect this reality: [[ http://xhr.spec.whatwg.org/#the-open()-method https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html#the-open()-method Warning: Developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs so the feature can eventually be removed from the platform. ]] Is there a good (enuf) precedence on the deprecation warning that can be reuse? If not, how about something like: [[ Warning: synchronous XHR is in the process of being deprecated i.e. it will eventually be removed from the Web platform. As such, developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and the tool may experiment with throwing an InvalidAccessError exception. ]] Robert, Anne, All, WDYT? -AB
Re: {Spam?} Re: [xhr]
That I think what is unclear from the writing of the warning are two things: 1) It *appears *to be part of the spec. (The parts before say they are non-normative, but this section does not.) And it uses the word must -- implying that it is a requirement, not a recommendation. 2) Perhaps it is just unclear to me what experiment means, but I read that as saying that Mozilla, tomorrow, is encouraged to kill all sites that utilize async=false and not wait until the standard is adopted. I have a feeling I am misunderstanding what a developer tool is as opposed to standard web page operation. Could you please clarify? Does it mean that if I have the debugger running, my site will fail, but if it is not running, it will work? Bob Hanson Robert, Anne, All, WDYT? On Wed, Sep 3, 2014 at 2:14 PM, Arthur Barstow art.bars...@gmail.com wrote: On 9/2/14 9:10 PM, Brendan Eich wrote: cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should set some sense of expectation about*when* it won't work. Different parts of the Web move on different timelines. Right. Given this, it seems like the current Note should indeed be updated to reflect this reality: [[ http://xhr.spec.whatwg.org/#the-open()-method https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/ Overview.html#the-open()-method Warning: Developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs so the feature can eventually be removed from the platform. ]] Is there a good (enuf) precedence on the deprecation warning that can be reuse? If not, how about something like: [[ Warning: synchronous XHR is in the process of being deprecated i.e. it will eventually be removed from the Web platform. As such, developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and the tool may experiment with throwing an InvalidAccessError exception. ]] Robert, Anne, All, WDYT? -AB -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Department of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
Re: =[xhr]
On 09/03/2014 12:10 PM, Greeves, Nick wrote: I would like to emphasise the detrimental effect that the proposed experimentation would have on a large number of sites across Chemistry research and education that would mysteriously stop working when users (automatically) upgraded their browsers and JSmol ceased to function. But you know now that sync XHR will be removed from the main thread, and have plenty of time to fix JSmol to use async XHR. I wouldn't expect any browser to even try to remove support for sync XHR before 2016, and even then only if the usage is low enough. (and the initial experiments to try to remove the feature would be done in nightly/development builds, not in release builds) -Olli JSmol is used so widely because it gets away from the historic need for a specific browser version and a specific plugin or Java installation and works across all browsers and platforms. Examples of critical sites that would be broken/have to be rebuilt include UK National Chemical Database Service http://cds.rsc.org notably CSD, ICSD, ChemSpider, CrystalWorks I should also declare a vested interest as my own Open Educational Resource ChemTube3D depends on JSmol, which supports the teaching of Chemistry in Liverpool and across the world. There were more than 590,000 visitors (up 48% on the previous year) from 209 countries in the last year of operation. -- Nick Greevesvia OS X Mail Director of Teaching and Learning Department of Chemistry University of Liverpool Donnan and Robert Robinson Laboratories Crown Street, LIVERPOOL L69 7ZD U.K. Email address: ngree...@liverpool.ac.uk mailto:ngree...@liverpool.ac.uk WWW Pages: http://www.chemtube3d.com Tel:+44 (0)151-794-3506 (3500 secretary) Dept Fax: +44 (0)151-794-3588
Re: =[xhr]
Q1) No, there is no immediate alternative at the moment, nor is there one planned. One of the reasons for this proposed change to the semantics of XHR is to stop hiding asynchronous behavior behind a synchronous implementation that cannot be quite implemented in a satisfactory manner. Q2) The general recommendation is to either move code off the main thread (e.g. to a worker) or to rewrite it asynchronously (possibly using Promise and Task.js to maintain a readable syntax and exception semantics). This is quite some work, but my personal experience shows that it also makes the code much more flexible/optimizable for responsiveness in many ways. In this case, I believe that it would require changes to Java2Script. Cheers, David On 12/07/14 17:57, Robert Hanson wrote: Q1) I don't see how that could possibly be done asynchronously. This could easily be called from a stack that is 50 levels deep. Am I missing something here? How would one restart an entire JavaScript stack asynchronously? Q2) Is there an alternative to the main thread involving AJAX still using synchronous transfer? Bob Hanson Principal Developer, Jmol/JSmol -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Department of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature
Re: =[xhr]
Olli, Thanks for the reassurance and your comment about nightly builds makes a lot of sense. Users of those would expect things to break. All the best Nick -- 3D Organic Animations http://www.chemtube3d.com Tel: +44 (0)151-794-3506 (3500 secretary) On 3 Sep 2014, at 13:57, Olli Pettay o...@pettay.fimailto:o...@pettay.fi wrote: On 09/03/2014 12:10 PM, Greeves, Nick wrote: I would like to emphasise the detrimental effect that the proposed experimentation would have on a large number of sites across Chemistry research and education that would mysteriously stop working when users (automatically) upgraded their browsers and JSmol ceased to function. But you know now that sync XHR will be removed from the main thread, and have plenty of time to fix JSmol to use async XHR. I wouldn't expect any browser to even try to remove support for sync XHR before 2016, and even then only if the usage is low enough. (and the initial experiments to try to remove the feature would be done in nightly/development builds, not in release builds) -Olli JSmol is used so widely because it gets away from the historic need for a specific browser version and a specific plugin or Java installation and works across all browsers and platforms. Examples of critical sites that would be broken/have to be rebuilt include UK National Chemical Database Service http://cds.rsc.org notably CSD, ICSD, ChemSpider, CrystalWorks I should also declare a vested interest as my own Open Educational Resource ChemTube3D depends on JSmol, which supports the teaching of Chemistry in Liverpool and across the world. There were more than 590,000 visitors (up 48% on the previous year) from 209 countries in the last year of operation. -- Nick Greevesvia OS X Mail Director of Teaching and Learning Department of Chemistry University of Liverpool Donnan and Robert Robinson Laboratories Crown Street, LIVERPOOL L69 7ZD U.K. Email address: ngree...@liverpool.ac.ukmailto:ngree...@liverpool.ac.uk mailto:ngree...@liverpool.ac.uk WWW Pages: http://www.chemtube3d.comhttp://www.chemtube3d.com/ Tel:+44 (0)151-794-3506 (3500 secretary) Dept Fax: +44 (0)151-794-3588
Re: =[xhr]
David Rajchenbach-Teller wrote: it would require changes to Java2Script. Big changes -- CPS conversion, compiling with continuations. This would require identifying all the potential blocking points. It's not clear anyone will do it, even if it is feasible (thanks to Java's static types and more analyzable scope rules). Don't hold your breath. Is Java2Script open source? I couldn't find a repo at a quick search. /be
Re: =[xhr]
David Rajchenbach-Teller wrote: Clearly, it would require big changes, although compiling to return Promise and using Task.js + yield at call sites would probably be much simpler than CPS conversion. All call sites, every last Java method = JS function call? That means every single function becomes a generate, all functions use yield and so become generator functions, all calls construct a generator which must have .next() called to get it started. The performance is not going to be tolerable. This vague suggestion has come up with Emscripten re: sync APIs for workers, and it's a bogus hand-wave. Please don't suggest it as a solution and then make definite plans to reject sync APIs in workers or schedule removal of XHR's async=false mode on a date certain! /be
Re: Proposal for a Permissions API
On 02 Sep 2014, at 16:51, Mounir Lamouri mou...@lamouri.fr wrote:
TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.
You can find the chromium.org design document in [1].
[...]
Thanks for the strawman proposal. I think your v1 requirements are reasonable
and the proposed solution seems fine.
We’ve been looking at this problem space earlier (e.g. [2], [3], there must be
more), and the other suggested solutions seem pretty similar. However, your v1
proposal is more tightly scoped, which I think is a good thing.
Re requestPermission() I agree there’s a real risk that this could be used to
spam the user, thus starting with as small API surface as possible makes sense.
To mitigate spamming, I’d guess UAs could come up with heuristics that suppress
requests made by spammy sites, similarly to how e.g. alert() or open() spam is
handled nowadays (of course, it would be better if we could come up with an API
that cannot be abused).
FWIW, here’s the earlier proposal [2] in pseudo-ish IDL:
enum PermissionLevel { default”, denied”, “granted };
[NoInterfaceObject]
interface Permissions {
PromisePermissionLevel requestPermission ();
Promiseboolean hasPermission ();
};
Notification implements Permissions;
PushManager implements Permissions;
/* ... */
Geolocation implements Permissions;
The key difference is the has*() and request*() methods sit directly on the
host objects. To bundle permissions, use Promise.all():
Promise.all([
Notification.requestPermission(),
navigator.push.hasPermission()
]).then(function(perms) {
if (perms[0] == 'granted') { // notifications ok; }
if (perms[1]) { navigator.push.register(); }
});
Given there's good discussion going on at the Paris meeting right now [4] and
the topic is on the agenda, I’m expecting more input from the meeting
participants on how to proceed.
Thanks,
-Anssi
[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
[2] https://github.com/w3c/push-api/issues/3
[3] http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
[4] http://www.w3.org/2014/07/permissions/#agenda
Re: =[xhr]
On 03/09/14 17:27, Brendan Eich wrote: David Rajchenbach-Teller wrote: it would require changes to Java2Script. Big changes -- CPS conversion, compiling with continuations. Clearly, it would require big changes, although compiling to return Promise and using Task.js + yield at call sites would probably be much simpler than CPS conversion. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature
Re: {Spam?} Re: [xhr]
On Tue, 2 Sep 2014, Brendan Eich wrote: Also (I am a WHATWG cofounder) it is overreach to promise obsolescence on any timeline on the Web. Robert should not worry about real browser implementors breaking content by removing sync XHR -- to do so would be to lose market share. In this light, WHATWG should avoid making indefinite-timescale, over-ambitious assertions. Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: {Spam?} Re: [xhr]
On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. See http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232 for why we added a warning to the specification. It was thought that if we made a collective effort we can steer people away from depending on this. And I think from that perspective gradually phasing it out from the specification makes sense. With some other features we take the opposite approach, we never really defined them and are awaiting implementation experience to see whether they can be killed or need to be added (mutation events). I think it's fine to have several strategies for removing features. Hopefully over time we learn what is effective and what is not. Deprecation warnings have worked for browsers. They might well work better if specifications were aligned with them. -- http://annevankesteren.nl/
Re: {Spam?} Re: [xhr]
On 9/3/14 8:25 AM, Robert Hanson wrote: That I think what is unclear from the writing of the warning are two things: Per the specs' Participate boilerplate, perhaps you should file a bug (^1). -Thanks, AB ^1 https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWGcomponent=XHR
Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes
Regrets. I've had another responsibility arise that will prevent me from attending today's conference call. On Sep 2, 2014, at 1:00 PM, Janina Sajka jan...@rednote.net wrote: As before I'm cross-posting this IndieUI agenda As part of IndieUI's continuing open invitation continuing our conversation about working jointly. Allow me to invite you to the next Indie-UI teleconference as detailed below. Please feel free to join us on this call, or any following call. What: IndieUI Task Force Teleconference When: Wednesday 3 September 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central (Daylight) Time (CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern (Daylight) Time (EDT: UTC -4) 10:00 PMLondon -- British (Summer) Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 4 September CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time (Thursday, 4 September JST: UTC +9) 7:00 AMMelbourne -- Australian Eastern (Standard) Time (Thursday 4 September AEST: UTC +10) 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=20140903T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 3 September 2014 Meeting: IndieUI Task Force Teleconference Chair:Michael_Cooper agenda+ preview agenda with items from two minutes agenda+ Editor's Report agenda+ Checkin with Web Apps' Editing TF [See below] agenda+ Testing Conversation; Polyfills agenda+ Requirements Use Cases Progress agenda+ TPAC Planning http://www.w3.org/2014/11/TPAC/ 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: IndieUI Minutes http://www.w3.org/2014/08/20-indie-ui-minutes.html Resource: Web Apps Editing TF Explainer: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: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes
My probable regrets as well due to a one-time scheduling conflict. Michael, given that James and Jason are also both unavailable, I leave it to your discretion whether to cancell today's call. Janina Janina Sajka writes: As before I'm cross-posting this IndieUI agenda As part of IndieUI's continuing open invitation continuing our conversation about working jointly. Allow me to invite you to the next Indie-UI teleconference as detailed below. Please feel free to join us on this call, or any following call. What: IndieUI Task Force Teleconference When: Wednesday 3 September 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central (Daylight) Time (CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern (Daylight) Time (EDT: UTC -4) 10:00 PMLondon -- British (Summer) Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 4 September CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time (Thursday, 4 September JST: UTC +9) 7:00 AMMelbourne -- Australian Eastern (Standard) Time (Thursday 4 September AEST: UTC +10) 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=20140903T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 3 September 2014 Meeting: IndieUI Task Force Teleconference Chair:Michael_Cooper agenda+ preview agenda with items from two minutes agenda+ Editor's Report agenda+ Checkin with Web Apps' Editing TF [See below] agenda+ Testing Conversation; Polyfills agenda+ Requirements Use Cases Progress agenda+ TPAC Planning http://www.w3.org/2014/11/TPAC/ 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: IndieUI Minutes http://www.w3.org/2014/08/20-indie-ui-minutes.html Resource: Web Apps Editing TF Explainer: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
Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes
regrets for tonight. Rich Schwerdtfeger From: Janina Sajka jan...@rednote.net To: public-indie...@w3.org Cc: public-editing...@w3.org public-editing...@w3.org, public-webapps@w3.org public-webapps@w3.org Date: 09/03/2014 01:59 PM Subject:Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes My probable regrets as well due to a one-time scheduling conflict. Michael, given that James and Jason are also both unavailable, I leave it to your discretion whether to cancell today's call. Janina Janina Sajka writes: As before I'm cross-posting this IndieUI agenda As part of IndieUI's continuing open invitation continuing our conversation about working jointly. Allow me to invite you to the next Indie-UI teleconference as detailed below. Please feel free to join us on this call, or any following call. What: IndieUI Task Force Teleconference When: Wednesday 3 September 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central (Daylight) Time (CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern (Daylight) Time (EDT: UTC -4) 10:00 PMLondon -- British (Summer) Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 4 September CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time (Thursday, 4 September JST: UTC +9) 7:00 AMMelbourne -- Australian Eastern (Standard) Time (Thursday 4 September AEST: UTC +10) 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=20140903T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 3 September 2014 Meeting: IndieUI Task Force Teleconference Chair: Michael_Cooper agenda+ preview agenda with items from two minutes agenda+ Editor's Report agenda+Checkin with Web Apps' Editing TF [See below] agenda+Testing Conversation; Polyfills agenda+Requirements Use Cases Progress agenda+ TPAC Planning http://www.w3.org/2014/11/TPAC/ 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: IndieUI Minutes http://www.w3.org/2014/08/20-indie-ui-minutes.html Resource: Web Apps Editing TF Explainer: 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:
Re: {Spam?} Re: [xhr]
On Wed, 3 Sep 2014, Anne van Kesteren wrote: On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. See http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232 for why we added a warning to the specification. It was thought that if we made a collective effort we can steer people away from depending on this. The text of the warning seems fine to me. It doesn't make any assertions about the future as far as I can tell; it just discourages use of a feature and says that we hope to remove it. If we are ever to remove something as widely used as sync XHR, this kind of advocacy seems like a prerequisite. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: {Spam?} Re: [xhr]
(Branden, your mails keep getting {Spam?} put in the header, which means
every time you post, you create a new thread for Gmail users. I guess it's
the list software to blame for changing subject lines, but it's making a
mess of this thread...)
On Wed, Sep 3, 2014 at 12:49 PM, Anne van Kesteren ann...@annevk.nl wrote:
See
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232
for why we added a warning to the specification. It was thought that
if we made a collective effort we can steer people away from depending
on this. And I think from that perspective gradually phasing it out
from the specification makes sense. With some other features we take
the opposite approach, we never really defined them and are awaiting
implementation experience to see whether they can be killed or need to
be added (mutation events). I think it's fine to have several
strategies for removing features. Hopefully over time we learn what is
effective and what is not.
It's perfectly valid to warn people when they shouldn't use a feature.
Sync XHR is such a strong case of this that a spec would be deeply
neglegent not to have a warning.
My only issue is the wording: it doesn't make sense to have normative
language saying you must not use this feature. This should be a
non-normative note warning that this shouldn't be used, not a normative
requirement telling people that they must not use it. (This is a more
general problem--the use of normative language to describe authoring
conformance criteria is generally confusing.)
--
Glenn Maynard
Re: {Spam?} Re: [xhr]
On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard gl...@zewt.org wrote: My only issue is the wording: it doesn't make sense to have normative language saying you must not use this feature. This should be a non-normative note warning that this shouldn't be used, not a normative requirement telling people that they must not use it. (This is a more general problem--the use of normative language to describe authoring conformance criteria is generally confusing.) This is indeed just that general problem that some people have with normative requirements on authors. I've got no problem with normatively requiring authors to do (or not do) things; the restrictions can then be checked in validators or linting tools, and give those tools a place to point to as justification. ~TJ
Re: {Spam?} Re: [xhr]
On Wed, Sep 3, 2014 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. See http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232 for why we added a warning to the specification. It was thought that if we made a collective effort we can steer people away from depending on this. And I think from that perspective gradually phasing it out from the specification makes sense. With some other features we take the opposite approach, we never really defined them and are awaiting implementation experience to see whether they can be killed or need to be added (mutation events). I think it's fine to have several strategies for removing features. Hopefully over time we learn what is effective and what is not. Deprecation warnings have worked for browsers. They might well work better if specifications were aligned with them. I generally agree with Anne here. As a browser developer it is frustrating when attempts to remove old cruft from the web is met with pushback from authors with the argument you can't remove/deprecate this features because the spec says that this feature must be there. Obviously many authors are just using this as an argument when what they really mean is you can't remove/deprecate this feature because I use it. However I've also noticed that it's true that authors are much more willing to deal with features being removed when they know it's not happening on the whim of a single browser vendor, and that it might be reverted in the future, but rather that it's an agreed upon change to the web platform with an agreed upon other solution. I also don't think that simply updating a spec once multiple browser vendors have removed a feature helps. It's the process of removing the feature in the first place which is harder if the spec doesn't back you up. But possibly this can be better expressed than what's currently in the spec. I.e. if we say that the feature is deprecated because it leads to bad UI, and that since the expectation is that eventually implementations will remove support for the feature it is already now considered conformat to the spec to throw an exception. However many websites still use the feature, so implementations that want to be compatible with such websites need to still keep the feature working. / Jonas
Re: {Spam?} Re: [xhr]
On Wed, Sep 3, 2014 at 2:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard gl...@zewt.org wrote: My only issue is the wording: it doesn't make sense to have normative language saying you must not use this feature. This should be a non-normative note warning that this shouldn't be used, not a normative requirement telling people that they must not use it. (This is a more general problem--the use of normative language to describe authoring conformance criteria is generally confusing.) This is indeed just that general problem that some people have with normative requirements on authors. I've got no problem with normatively requiring authors to do (or not do) things; the restrictions can then be checked in validators or linting tools, and give those tools a place to point to as justification. Agreed. Making it a conformance requirement not to use sync XHR seems like a good idea. That way we can also phrase it as implementations that want to be compatible with non-conformant websites need to still support sync requests. / Jonas
[No quorum] Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes
Only Takeshi and I joined the call, with Jason for a brief hi. This is not enough quorum to discuss anything meaningful so we ended the call after 15 minutes. Michael On 02/09/2014 4:00 PM, Janina Sajka wrote: As before I'm cross-posting this IndieUI agenda As part of IndieUI's continuing open invitation continuing our conversation about working jointly. Allow me to invite you to the next Indie-UI teleconference as detailed below. Please feel free to join us on this call, or any following call. What:IndieUI Task Force Teleconference When:Wednesday 3 September 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central (Daylight) Time (CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern (Daylight) Time (EDT: UTC -4) 10:00 PMLondon -- British (Summer) Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 4 September CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time (Thursday, 4 September JST: UTC +9) 7:00 AMMelbourne -- Australian Eastern (Standard) Time (Thursday 4 September AEST: UTC +10) 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=20140903T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 3 September 2014 Meeting: IndieUI Task Force Teleconference Chair:Michael_Cooper agenda+ preview agenda with items from two minutes agenda+ Editor's Report agenda+Checkin with Web Apps' Editing TF [See below] agenda+Testing Conversation; Polyfills agenda+Requirements Use Cases Progress agenda+ TPAC Planning http://www.w3.org/2014/11/TPAC/ 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: IndieUI Minutes http://www.w3.org/2014/08/20-indie-ui-minutes.html Resource: Web Apps Editing TF Explainer: 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/
Re: File API: reading a Blob
Sorry to interfer then but your discussion with Arun seems to have no point if streams are there. But some points I mentioned have, whether it's really linked to the initial subject or not. The fact is that most of the W3C groups impacted by streams (File, indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream, etc, I must forget a lot here) seem not to care a lot about it and maybe just expect streams to land in the right place in the APIs when they are available, by some unknown magic. I still think that the effort should start from now for all the APIs (as well as the implementation inside browsers, which apparently has started for Chrome, but Chrome was supposed to have started some implementation of the previous Streams APIs, so it's not very clear), and that it should be very clearly synchronized, disregarding vague assumptions from the groups about low/high level and Vx releases, eluding the issue. Le 01/09/2014 11:14, Anne van Kesteren a écrit : On Thu, Aug 28, 2014 at 2:15 AM, Aymeric Vitte vitteayme...@gmail.com wrote: I have contributed to streams already, of course it will solve most of what is being discussed here but when? And then what's the point of this discussion? This discussion between me and Arun is about how to describe various algorithms in File API and Fetch, ideally enabling APIs on top of those low-level descriptions later on. But it is about describing the behavior of existing APIs in more detail. -- 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
Re: File API: reading a Blob
On Aug 11, 2014, at 7:24 AM, Anne van Kesteren ann...@annevk.nl wrote: Other than “chunks of bytes” which needs some normative backbone, is the basic abstract model what you had in mind? If so, that might be worth getting into File APi and calling it done, because that’s a reusable abstract model for Fetch and for FileSystem. Yeah that looks good. https://whatwg.github.io/streams/ defines chunks and such, but is not quite there yet. But it is what we want to build this upon eventually. I’ve fixed the model according to these discussions: 1. We’ve separated the read operation and the “annotated task read operation.” The former uses Fetch’s notion of a body, which is a byte stream, and so is convenient to work with. Hopefully, it should allow plugging right back into Fetch. 2. The methods now invoke an annotated task read operation. http://dev.w3.org/2006/webapi/FileAPI/#reading-data-section — A*
Re: File API: reading a Blob
On Sep 3, 2014, at 6:02 PM, Aymeric Vitte vitteayme...@gmail.com wrote: The fact is that most of the W3C groups impacted by streams (File, indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream, etc, I must forget a lot here) seem not to care a lot about it and maybe just expect streams to land in the right place in the APIs when they are available, by some unknown magic. I care about it. Till the API is totally baked, I’m amenable to getting the model right. File API now refers to chunks read, which is more correct. But I understand that your use cases aren’t catered to just yet; FileReader/FileReaderSync don’t do easily extractable partials. I’d like to see if there’s interest in the earlier proposal, to extract a stream straight from Blob. I still think that the effort should start from now for all the APIs (as well as the implementation inside browsers, which apparently has started for Chrome, but Chrome was supposed to have started some implementation of the previous Streams APIs, so it's not very clear), and that it should be very clearly synchronized, disregarding vague assumptions from the groups about low/high level and Vx releases, eluding the issue. What issue is being eluded? Seems like another of your main use cases is to have URL.createObjectURL or URL.createFor return a streamable resource. I agree that’s a good problem to solve. — A*
