user agent MAY release means that people will write code which works
now, and later the browser vendor will make a change that will break
their code. Who is at fault? We all know that the browser vendor is
at fault!
Suggest the user agent SHALL release the storage mutex on any API
operation
On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell
brian.p.campb...@dartmouth.edu wrote:
On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote:
On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell
brian.p.campb...@dartmouth.edu wrote:
As a multimedia developer, I am wondering about the purpose of the
I can only imagine the usage of address/ will be utilized more
productively if its intuitive purpose (arbitrary contact/postal addresses)
were its actual function. As our friends at HTML5 Doctor illustrate, it is
all too easy to jump to conclusions and use this element incorrectly.
Perhaps a
By API operation I mean anything other than core ecmascript and
localstorage itself.
Eg you can be sure that the following will not release the mutex:
* do nothing
* function call
* if/for etc
* access to a local variable
* access to a basic ecmascript object (not host objects)
But anything
That version is fine with me.
My reason for using MAY was I thought it would make efficient
implementation easier. Also, testing when things are being unlocked is
pretty much impossible for users due to the statistical nature of race
conditions and shedulers.
But yeah, SHALL is better
On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell
brian.p.campb...@dartmouth.edu wrote:
As implemented by Safari and Chrome (which is the minimum rate allowed by
the spec), it's not really useful for that purpose, as 4 updates per second
makes any sort of synchronization feel jerky and laggy.
It
[this is Ron Ennals from Intel, posting from gmail on my phone while
at tpac]
I've talked to a few people about the distibuted extensibility problem
and I'd like to suggest a possible compremise:
* maintain a central registry of prefixes with standard meanings - so
eg fb always means
Ug.
s/compremise/compromise/
s/Ron Ennals/Rob Ennals/
I'm tired...
-Rob
On Nov 5, 2009, at 4:50 PM, Rob Ennals rob.enn...@gmail.com wrote:
[this is Ron Ennals from Intel, posting from gmail on my phone while
at tpac]
I've talked to a few people about the distibuted extensibility
problem
As some of you know, WebKit is reviewing a patch to add the sandbox
attribute to frames, as specced in HTML5. I'm hoping this will
motivate various folks to review @sandbox and give their feedback.
== allow-same-origin + allow-script ==
It's clear that adding both allow-same-origin and
I talked to a few more people, resulting in the following additional
requirement:
A prefixed node MUST NOT contain HTML nodes
This is to stop people creating prefixed nodes that replace HTML
nodes, with resulting loss in universally understood semantics.
Prefixed tag names are to be used only
I'll respond in more depth later, but some quick notes since you're
reviewing a patch:
On Thu, 5 Nov 2009, Adam Barth wrote:
One interesting feature of @sandbox is that the hosting page can change
the value of the sandbox attribute. Even though it's clear that having
both
On Thu, Nov 5, 2009 at 9:11 PM, Ian Hickson i...@hixie.ch wrote:
I'll respond in more depth later, but some quick notes since you're
reviewing a patch:
Thanks. The plan is to implement the spec as currently written and
then track changes to the spec.
On Thu, 5 Nov 2009, Adam Barth wrote:
I see both US-ASCII and ASCII are used in:
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54
If they mean the same thing, one should be used consistently.
In the document, US-ASCII seems to mean encoding while ASCII
mean charset. Is this common? (I guess US-ASCII is commonly
Hi,
First of all, there is a typo error in this example. The main HTML page
is a copy/paste of the first example (Worker example: One-core
computation).
My point here is to ask for a new attribute for the navigator object
that could describe the best number of workers in a delegation use case.
Hi,
Section 4.4 of
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54
specifies how erroneous UTF-8 must be handled on the client side.
Does the same apply for the server side?
Yuzo
15 matches
Mail list logo
