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
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
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
con
On Thu, Nov 5, 2009 at 9:11 PM, Ian Hickson 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:
> It's actuall
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 allow-same-o
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
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 allow-scr
Ug.
s/compremise/compromise/
s/Ron Ennals/Rob Ennals/
I'm tired...
-Rob
On Nov 5, 2009, at 4:50 PM, Rob Ennals 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 and I'd like to sugg
[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 fbml
On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell
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 really depends what you're
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 sem
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
I can only imagine the usage of 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 element wou
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 purp
"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 /
15 matches
Mail list logo