Chaals, Marcos,
Based on this discussion, I concluded this CfC has failed to show we
have consensus. As such, after you two have agreed on a version of the
spec that satisfies all of Chaals' concerns, my recommendation is we
start a new CfC.
-Thanks, AB
On 7/26/12 9:52 AM, ext Chaals
On Thu, 09 Aug 2012 13:52:26 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
Chaals, Marcos,
Based on this discussion, I concluded this CfC has failed to show we
have consensus. As such, after you two have agreed on a version of the
spec that satisfies all of Chaals' concerns, my
On Aug 9, 2012, at 01:39 , Jonas Sicking wrote:
On Wed, Aug 8, 2012 at 1:33 AM, Yuval Sadan sadan.yu...@gmail.com wrote:
Perhaps it shouldn't be a full-text *index* but simply a search feature.
Though I'm unfamiliar with specific implementations, I gather that filtering
records in native code
On 9 Aug 2012, at 12:52, Arthur Barstow art.bars...@nokia.com wrote:
Chaals, Marcos,
Based on this discussion, I concluded this CfC has failed to show we have
consensus. As such, after you two have agreed on a version of the spec that
satisfies all of Chaals' concerns, my recommendation
On 9 Aug 2012, at 13:10, Chaals McCathieNevile w...@chaals.com wrote:
On Thu, 09 Aug 2012 13:52:26 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
Chaals, Marcos,
Based on this discussion, I concluded this CfC has failed to show we have
consensus. As such, after you two have agreed
On Aug 9, 2012, at 02:28 , Boris Zbarsky wrote:
On 8/8/12 8:23 PM, Adam Barth wrote:
If we're telling people to use that pattern, we might as well just not
prefix the API in the first place because that pattern just tells the
web developers to unilaterally unprefix the API themselves.
Yep.
On Thu, 09 Aug 2012 14:53:06 +0200, Robin Berjon ro...@berjon.com wrote:
On Aug 9, 2012, at 02:28 , Boris Zbarsky wrote:
On 8/8/12 8:23 PM, Adam Barth wrote:
If we're telling people to use that pattern, we might as well just not
prefix the API in the first place because that pattern just
On Thu, Aug 9, 2012 at 3:53 PM, Robin Berjon ro...@berjon.com wrote:
Trying to evangelise that something is experimental is unlikely to succeed.
But when trying out a new API people do look at the console a lot (you tend
to have to :). It might be useful to emit a warning upon the first usage
On 8/9/12 9:10 AM, Odin Hørthe Omdal wrote:
We will get this specific IDB problem too
Will you? In my testing, Opera seemed to put Window properties directly
on the global, not on the global's prototype, unlike other DOM objects
-Boris
This is somewhat similar to [1] and something we decided was
out-of-scope for v1. But for v2 I definitely think we should look at
mechanisms for using JS code to filter/sort/index data in such a way
that the JS code is run on the IO thread.
[1]
Kyle Huey:
PS. We're also going to run into this in the future with any other
prefixed DOM APIs we add to the global, probably even if we don't tell
people to do it wrong in our tutorials. This behavior is a pretty
massive footgun.
The problem seems to be because Web IDL moved properties from
On 8/9/12 9:44 PM, Cameron McCormack wrote:
Kyle Huey:
PS. We're also going to run into this in the future with any other
prefixed DOM APIs we add to the global, probably even if we don't tell
people to do it wrong in our tutorials. This behavior is a pretty
massive footgun.
The problem
Boris Zbarsky:
Just for Window? What about interfaces Window inherits from?
Them too.
An why not for operations? Seems like exactly the same issue arises with:
var requestAnimationFrame = window.requestAnimationFrame || ;
I was thinking that properties for operations have always
On Wednesday 2012-08-08 21:16 -0500, Glenn Maynard wrote:
APIs should always be shipped prefixed and unprefixed for a reasonable
period, so people have an opportunity to add the unprefixed name to their
site before the unprefixed name goes away.
Except that authors don't notice that they need
On Thu, Aug 9, 2012 at 9:38 PM, L. David Baron dba...@dbaron.org wrote:
On Wednesday 2012-08-08 21:16 -0500, Glenn Maynard wrote:
APIs should always be shipped prefixed and unprefixed for a reasonable
period, so people have an opportunity to add the unprefixed name to their
site before the
On 8/9/12 10:47 PM, Glenn Maynard wrote:
That makes it impossible for *anyone* to avoid breakage (unless they add
the unprefixed version before unprefixing happens).
Or unless they avoid using prefixed things in production code to start with.
Which brings us back to not shipping unstable
On 8/9/12 10:56 PM, Boris Zbarsky wrote:
On 8/9/12 10:47 PM, Glenn Maynard wrote:
Meanwhile, pages will continue to work in other browsers that do this
more sensibly.
The main other option is basically to never drop the prefixed version,
ever, which is what said other browsers actually do in
No technical comments.
A few editorial comments.
CLOSING (numeric value 2)
The connection is going through the closing handshake.
The readyState can enter CLOSING also when close() is called before
establishment. In that case, it's not going through closing handshake.
// networking
18 matches
Mail list logo
