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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
(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
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
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
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
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
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,
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
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
27 matches
Mail list logo