date:20100330

On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky  wrote:
> On 3/30/10 10:22 AM, Jonas Sicking wrote:
>>
>> Making it implementation dependent is likely to lead to website
>> incompatibilities. Such as:
>>
>> ws = new WebSocket(...);
>> ws.onopen = function() {
>>   ws.send(someString);
>>   if (ws.bufferedAmount>  X) {
>>     doStuff();
>
> Can bufferedAmount not change due to data actually hitting the network
> during the execution of this code?  As in, will all the someString data be
> buffered immediately after that send() call?

I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop. We generally try to avoid
"racy" variables since people don't expect them. Consider for example

if (ws.bufferedAmount > X) {
  setUpSomeState();
}

try {
  doOtherThings();
}
finally {
  if (ws.bufferedAmount > X) {
cleanUpState();
  }
}

I'd imagine most JS developers to expect the cleanup to always happen
if the setup did.

/ Jonas

Re: [whatwg] WebSocket bufferedAmount includes overhead or not


On 3/30/10 10:22 AM, Jonas Sicking wrote:

Making it implementation dependent is likely to lead to website
incompatibilities. Such as:

ws = new WebSocket(...);
ws.onopen = function() {
   ws.send(someString);
   if (ws.bufferedAmount>  X) {
 doStuff();


Can bufferedAmount not change due to data actually hitting the network 
during the execution of this code?  As in, will all the someString data 
be buffered immediately after that send() call?


-Boris

Re: [whatwg] Workers: What can be done in a worker after call to close()?

2010-03-30 Thread Dmitry Titov

On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson  wrote:

> I'll note that the spec gives the UA an significant amount of latitude
> about its behavior after close() is called:
>
> User agents may invoke the "kill a worker<#127b1baa1cefaebf_kill-a-worker>"
> processing model on a worker at any time, e.g. in response to user requests,
> in response to CPU quota management, or when a worker stops being an active
> needed worker <#127b1baa1cefaebf_active-needed-worker> if the worker
> continues executing even after its 
> closing<#127b1baa1cefaebf_dom-workerglobalscope-closing> flag
> was set to true.
>
> Essentially, UAs can kill a worker at any time, and since the "kill a
> worker" algorithm allows UAs to abort the script after a user-agent-defined
> amount of time (including zero), it seems like almost any behavior
> post-close is compliant. This seems like a guaranteed source of
> cross-browser incompatibilities.
>

Yes, and this, after many hours of troubles, may eventually crystallize into
"don't have any code after close() in your worker code" rule-of-thumb for
web developers. Which is basically a bad thing...
This is why it could be better to specify explicitly that either execution
is immediately terminated or it runs until JS exits with full functionality
of the worker, not in a special almost-closed mode. Having a timeout

>
> I've always operated under the impression that the intent of the spec is to
> allow pending worker operations to complete, but still give UAs the ability
> to abort scripts that don't exit in a timely manner (so close() should not
> immediately abort the script), but I don't see anything in the spec
> regarding this.
>
> For #2 below, I believe that exceptions in worker context should *always*
> be reported, regardless of closing state. Section 4.6 (Runtime script
> errors) makes no mention of tying this behavior to the closing flag.
>

This applies as long as the browser still executes the code after close().
In WebKit V8 case, we terminate execution almost instantly, so we don't even
run the code that causes an error :-) If we are not to terminate execution
instantly, then it'd be nice to say the script runs until it ends (or parent
document closes, which actually terminates the script forcefully), and not
have a requirement to stop the queue or disconnect ports, as to not create a
whole new 'mode of worker execution' which needs to have a spec on its own
since all other features will need to be mentions (like sync APIs).

It's not clear why a fixed timeout would be useful. It would create some
randomness in what a worker can still do after calling close(). I think web
developers would then rather do those things before calling close(), to
avoid random results.

But if we say close() lets script run until completion (but prevents further
messages/events from dispatching), then perhaps we don't need it at all -
there is nothing then that script in the worker can not do to the same
effect (unregister onmessage, clear timers etc).

That means letting worker to call close() on itself only makes additional
sense if it is specified as immediate termination. It could be useful and it
can be specified in deterministic manner.

On a separate note, I agree with giving workers some time before terminating
them in case the parent page closes - but this is the case when forces
outside and async to the worker need to close it. I think
it's different when worker's own script wants to terminate - it could do its
last wishes before calling close() as well.

>
> -atw
>
>
>
> On Tue, Mar 30, 2010 at 4:44 PM, Dmitry Titov  wrote:
>
>> Hi!
>>
>> Trying to fix some bugs for Workers, I've got some questions about close()
>> method on 
>> WorkerGlobalScope
>> .
>>
>> In particular, the spec seems to imply that after calling close() inside
>> the worker, the JS does not get terminated right away, but rather continue
>> to execute, while an internal 'closing' flag is set and a message
>> queue associated with the worker discards all the tasks, existing and
>> future. Also, all ports are immediately disentangled.
>>
>> This seems to leave some questions without explicit answer, with
>> differences in current implementations:
>>
>> 1. Does this code in a worker continues looping until the parent page
>> unloads:
>>  ...
>>  close();
>>  while(true) {}
>>
>> WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not
>> terminate.
>>
>> 2. Do the errors propagate back to Worker object after close()?
>> ...
>> close();
>> nonExistingFunction();  <<-- throws, if not processed locally, posts error
>> info to the Worker object.
>>
>> In WebKit and FF errors propagate, although it does not seem consistent
>> while worker closed all the ports and is in a dormant state.
>>
>> 3. Should synchronous operations work after close()? Asynchronous ones
>> perhaps should not, because of the event loop queue which is stopped...
>> ...

Re: [whatwg] Video Tag Proposal

2010-03-30 Thread Richard Watts


Boris Zbarsky wrote:

On 3/30/10 11:43 AM, Perry Smith wrote:

Isn't the concept of a submarine patent also possible against a
"patented" algorithm?


Yes, but since Apple already ships other H.264 decoders it already has 
exposure to whatever patents could come up against it.  So from their 
point of view, the marginal patent exposure of shipping H.264 in  
is 0.  Similar for Microsoft.  I can't speak to the situation Google is in.


 For my money (and this is worth what you paid for it :-)) the whole
submarine patents thing is a non-issue in the context of HTML5. The same
argument could be made about any feature of HTML5 - and I'm sure there
are 'submarine' (in the sense of not-widely-known-about) patents on
many other HTML5 features that all of the big browser companies are
happily implementing.

 Unless they know something I don't, the risk is certainly not much
less - at least the Theora guys have taken care to avoid all the
patents they knew about: more than can be said for most standards bodies
(and I don't know how vigorous the whatwg have been in sanitising
HTML5, but you can bet that someone somewhere involved in the
implementation of your browser hasn't).

 So: I think the submarine patents argument is a red herring.

 Given what I've seen of the utter incomprehension the computing
strategy people in general have of video, I suspect the actual reason
for resistance is some form of pure political idiocy centering on the
mobile companies lobbying to restrict video to things they already
(think they have) silicon to accelerate.

 One might expect resistance from Apple, at least - they have a lot of
iPods and iPhones out there (and now iPads) which as far as I know
simply won't play anything but H.264 without a major upgrade - or
that's what they could be expected to think, anyway.

 It will be interesting to see what the attitude is to the H.265
propsals the MPEG-LA are now discussing when they finally become
public (of course, in a sane world, VP8 would become H.265 and
everyone would be happy)


R

Re: [whatwg] Workers: What can be done in a worker after call to close()?

2010-03-30 Thread Drew Wilson

I'll note that the spec gives the UA an significant amount of latitude about
its behavior after close() is called:

User agents may invoke the "kill a worker <#kill-a-worker>" processing model
on a worker at any time, e.g. in response to user requests, in response to
CPU quota management, or when a worker stops being an active needed
worker<#active-needed-worker> if
the worker continues executing even after its
closing<#dom-workerglobalscope-closing> flag
was set to true.

Essentially, UAs can kill a worker at any time, and since the "kill a
worker" algorithm allows UAs to abort the script after a user-agent-defined
amount of time (including zero), it seems like almost any behavior
post-close is compliant. This seems like a guaranteed source of
cross-browser incompatibilities.

I've always operated under the impression that the intent of the spec is to
allow pending worker operations to complete, but still give UAs the ability
to abort scripts that don't exit in a timely manner (so close() should not
immediately abort the script), but I don't see anything in the spec
regarding this.

For #2 below, I believe that exceptions in worker context should *always* be
reported, regardless of closing state. Section 4.6 (Runtime script errors)
makes no mention of tying this behavior to the closing flag.

-atw

On Tue, Mar 30, 2010 at 4:44 PM, Dmitry Titov  wrote:

> Hi!
>
> Trying to fix some bugs for Workers, I've got some questions about close()
> method on 
> WorkerGlobalScope
> .
>
> In particular, the spec seems to imply that after calling close() inside
> the worker, the JS does not get terminated right away, but rather continue
> to execute, while an internal 'closing' flag is set and a message
> queue associated with the worker discards all the tasks, existing and
> future. Also, all ports are immediately disentangled.
>
> This seems to leave some questions without explicit answer, with
> differences in current implementations:
>
> 1. Does this code in a worker continues looping until the parent page
> unloads:
>  ...
>  close();
>  while(true) {}
>
> WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not
> terminate.
>
> 2. Do the errors propagate back to Worker object after close()?
> ...
> close();
> nonExistingFunction();  <<-- throws, if not processed locally, posts error
> info to the Worker object.
>
> In WebKit and FF errors propagate, although it does not seem consistent
> while worker closed all the ports and is in a dormant state.
>
> 3. Should synchronous operations work after close()? Asynchronous ones
> perhaps should not, because of the event loop queue which is stopped...
> ...
> close();
> xhr.open("GET", "foo.com", *false*);
> xhr.send();
>
> WebKit: does not work (mostly), FF - does work.
>
> Perhaps it would be simpler to either say nothing is executed/posted/fired
> after close() (immediate termination), or to enable worker run unimpeded
> (with ports open, etc) until it naturally yields from JS.
>
> Any opinions?
>
> Thanks,
> Dmitry
>
>
>

Re: [whatwg] Video Tag Proposal


On 3/30/10 11:43 AM, Perry Smith wrote:

Isn't the concept of a submarine patent also possible against a
"patented" algorithm?


Yes, but since Apple already ships other H.264 decoders it already has 
exposure to whatever patents could come up against it.  So from their 
point of view, the marginal patent exposure of shipping H.264 in  
is 0.  Similar for Microsoft.  I can't speak to the situation Google is in.


-Boris

Re: [whatwg] location.reload() on document.open()ed documents


On 3/30/10 10:38 AM, Henri Sivonen wrote:

This makes me wonder: If the two engines with the largest market
share both take steps to enable document.open()ed docs to be
reloaded, is the behavior needed for optimal Web compatibility?


At one point, yes.  I don't recall many bug reports about this aspect of 
things recently, but that may be because Gecko now has the "do something 
sane on reload in the simple cases" behavior.


I do feel pretty strongly that reload() doing something different from 
the browser's reload UI is ... very odd.


-Boris

Re: [whatwg] Video Tag Proposal


On 3/30/10 9:58 AM, Eoin Kilfeather wrote:

If a browser supports it in good faith, and subsequently a troll successfully 
introduces a
patent challenge, would the consequence not be that the codec would
simply be dropped with the next maintenance release of the browser?


IANAL, but as I understand the answer is "it depends".


In fact a court would surely allow a reasonable time for transition.


Depends on how one defines "reasonable".  Also depends on whether a 
preliminary injunction is issued; if one is the chances of "reasonable 
time" seem slimmer to me.



but that is at least a work-flow susceptible to automation.


Sort of.  Transcoding of a large corpus of video can well take more than 
a "reasonable time".



I can't see a court giving financial "damages" for infringement of a
patent which hasn't surfaced since  was proposed at the end of
2006.


Why not?  It's a patent and it's being infringed.  Why wouldn't there be 
financial damages?


I think you're being too optimistic about the way patents work 
nowadays...  :(


-Boris

Re: [whatwg] Proposal for secure key-value data stores

2010-03-30 Thread Nicholas Zakas

I certainly can't argue against a focus on JS crypto. :) What I'd like to do is 
eliminate what I believe will be a repeated pattern for developers in the 
future. It would be really nice if, in addition to having access to crypto 
functions, there was an area where I could stick data that would get encrypted 
automatically (and of course, where I could be sure the data would be 
eliminated after a set amount of time).

My proposal is less about encryption and more about providing better control 
over how data is stored and for how long.

-Nicholas
 
__
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Dirk Pranke
Sent: Tuesday, March 30, 2010 3:09 PM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for secure key-value data stores

On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas  wrote:
> Yes, that's precisely what I'm talking about. It seems to me that this will 
> end up being a pretty common pattern (encrypting/decrypting data stored 
> locally).
>
> The idea behind letting the key to be defined by the developer is to allow 
> any usage that developers deem appropriate for the situation. For example, 
> one might want to only use a server-generated key to access the data, in 
> which case this data won't be available offline but will be used to 
> supplement the online behavior. Another might determine the key based on some 
> information in a cookie, which is less secure but does allow offline access 
> while also ensuring that if the cookie changes or is deleted, the data 
> remains secure.
>
> The idea behind the expiration date is to allow developers to be sure the 
> data won't stay around on disk indefinitely. Think about the Internet café 
> use case where people are repeatedly logging in and out - we don't want 
> everyone's data living on that computer for however many years it's in use.
>
> One way or another, I think JavaScript crypto is going to be important in the 
> next few years.

Perhaps we should instead focus on a set of JS Crypto APIs, since that
is largely orthogonal to the storage APIs?

-- Dirk

[whatwg] Workers: What can be done in a worker after call to close()?

2010-03-30 Thread Dmitry Titov

Hi!

Trying to fix some bugs for Workers, I've got some questions about close()
method on 
WorkerGlobalScope
.

In particular, the spec seems to imply that after calling close() inside the
worker, the JS does not get terminated right away, but rather continue to
execute, while an internal 'closing' flag is set and a message
queue associated with the worker discards all the tasks, existing and
future. Also, all ports are immediately disentangled.

This seems to leave some questions without explicit answer, with differences
in current implementations:

1. Does this code in a worker continues looping until the parent page
unloads:
 ...
 close();
 while(true) {}

WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not
terminate.

2. Do the errors propagate back to Worker object after close()?
...
close();
nonExistingFunction();  <<-- throws, if not processed locally, posts error
info to the Worker object.

In WebKit and FF errors propagate, although it does not seem consistent
while worker closed all the ports and is in a dormant state.

3. Should synchronous operations work after close()? Asynchronous ones
perhaps should not, because of the event loop queue which is stopped...
...
close();
xhr.open("GET", "foo.com", *false*);
xhr.send();

WebKit: does not work (mostly), FF - does work.

Perhaps it would be simpler to either say nothing is executed/posted/fired
after close() (immediate termination), or to enable worker run unimpeded
(with ports open, etc) until it naturally yields from JS.

Any opinions?

Thanks,
Dmitry

Re: [whatwg] Simple Links

2010-03-30 Thread Ashley Sheridan

On Tue, 2010-03-30 at 23:44 +0200, Christoph Päper wrote:

> If you think about various syntax variants of wiki systems they’ve got one 
> thing in common that makes them preferable to direct HTML input: easy links! 
> (Local ones at least, whatever that means.) The best known example is 
> probably double square brackets as in Mediawiki, the engine that powers the 
> Wikimediaverse. A link to another article on the same wiki is as simple as 
> “[[Foo]]”, where HTML would have needed “Foo”.
> 
> I wonder whether HTML could and should provide some sort of similar 
> shortening, i.e. “Foo” or even, just maybe, “Foo”. The UA 
> would append the string content, properly encoded, to the base Web address as 
> the hyperlink’s target, thus behave as had it encounters “ href="Foo">Foo”.
> 
> I prefer the binary toggle role of the ‘href’ attribute, although it doesn’t 
> work well in the XML serialisation, because it provides better compatibility 
> with existing content and when I see or write “Bar” I rather think of 
> the origin of that element name, ‘anchor’. So I expect it to be equivalent to 
> “Bar” and “Bar” which would be shortcuts for “ id="Bar">Bar”.
> 
> PS: Square brackets aren’t that simple actually, because on many keyboard 
> layouts they’re not easy to input and might not be found on keytops at all.
> PPS: The serialisation difference is not that important, because XML, unlike 
> HTML, isn’t intended to be written by hand anyway.


I think to me foo would indicate it is a named anchor in a page.
Are all UA's intelligent enough to be able to accurately recognise any
form of URL? Also, in XHTML the tag would look like foo.

And, shouldn't links be as semantic as possible? Consider these two:


  * find the latest spec at http://www.somespecsite.com";>http://www.somespecsite.com
  * get http://www.somespecsite.com";>the latest spec


In my opinion, the second one is far more semantic, and is what I prefer
to use on anything I put together. The HTML spec should encourage the
best practices, and making shorter link tags that actually take a step
backwards in the world of semantic markup just seems a little foolish.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] Web Workers feedback

On Tue, Mar 30, 2010 at 3:09 PM, Ian Hickson  wrote:
> On Tue, 30 Mar 2010, Jonas Sicking wrote:
>> >
>> > I agree that people are less likely to depend on exceptions. The
>> > problem is feature detection so that you can use the new feature
>> > (sending DOM nodes) in new clients without failing in old clients.
>> > When sending null it's easy; when raising exceptions, you have to have
>> > two different sends.
>>
>> I would rather argue that throwing an exception makes feature detection
>> simpler. That way you can do something like:
>>
>> try {
>>   w.postMessage(obj);
>> } catch() {
>>   var f = {};
>>   f.x = obj.x;
>>   f.y = obj.y;
>>   f.complex = serializeOrCreateOtherFallback(obj.complex);
>>   w.postMessage(f);
>> }
>
> My understanding was that relying on exceptions for non-exceptional cases
> is bad API design. Why would it be ok here?

I think fallback is to be considered an exceptional case. Especially
as time goes on and more browsers implement support for the new type.

>> If null is sent you have to inside the worker send back an error message
>> to the sender. The sender has to find the correct data to send, which
>> could be hard given that the error message is received asynchronously,
>> and then resend.
>
> I agree that if you need the data either way, that sending null is
> useless. There are simple work-arounds for this (for example, sending one
> DOM node in a test message and having the worker let you know if it worked
> or not, so that you can construct the right class of object to handle the
> communication: one that sends DOM nodes or one that constructs the
> relevant data), but of course they are not ideal, just like using
> exceptions everywhere isn't ideal.
>
> The question is, what are the actual concrete cases where people will be
> sending DOM nodes? Without concrete cases, it's easy to construct
> artificial cases that prove this to be better one way or the other.

Say sending a DOM that the user has edited (using contentEditable)
which the worker will convert into a ODF document and send to the
server.

>> Ok, I guess it comes down to if we think it's more likely that people
>> will send Nodes and other unsupported objects by accident or as optional
>> data, or because they really want to send them.
>
> Yes.
>
>
>> Personally my guess it's more likely that they really wanted to.
>
> I have no idea which is more likely. The only use case I'm aware of is
> passing an  in, and for that there isn't really a fallback position,
> so it doesn't matter if we send null or throw an exception.

It just seems unlikely to me that people send data without actually
needing to. If someone does postMessage(X), then I would think they
intend to use X on the other end, be that if X is a DOM Node object or
a JS Array.

"they probably intended to say postMessage(Y)" seems as likely as
"they probably meant to appendChild(X)".

>> Personally, I think throwing an exception fits in with the spec's use of
>> them elsewhere (i.e., cross-document and web workers.)
>
> Where do we use exceptions for extension points in a similar way?

For circular object graphs in the very same algorithms. So

var a = {};
a.x = a;
worker.postMessage(a);

throws an exception.

/ Jonas

Re: [whatwg] Web Workers feedback

2010-03-30 Thread Ian Hickson

On Tue, 30 Mar 2010, Jonas Sicking wrote:
> >
> > I agree that people are less likely to depend on exceptions. The 
> > problem is feature detection so that you can use the new feature 
> > (sending DOM nodes) in new clients without failing in old clients. 
> > When sending null it's easy; when raising exceptions, you have to have 
> > two different sends.
> 
> I would rather argue that throwing an exception makes feature detection 
> simpler. That way you can do something like:
> 
> try {
>   w.postMessage(obj);
> } catch() {
>   var f = {};
>   f.x = obj.x;
>   f.y = obj.y;
>   f.complex = serializeOrCreateOtherFallback(obj.complex);
>   w.postMessage(f);
> }

My understanding was that relying on exceptions for non-exceptional cases 
is bad API design. Why would it be ok here?

> If null is sent you have to inside the worker send back an error message 
> to the sender. The sender has to find the correct data to send, which 
> could be hard given that the error message is received asynchronously, 
> and then resend.

I agree that if you need the data either way, that sending null is 
useless. There are simple work-arounds for this (for example, sending one 
DOM node in a test message and having the worker let you know if it worked 
or not, so that you can construct the right class of object to handle the 
communication: one that sends DOM nodes or one that constructs the 
relevant data), but of course they are not ideal, just like using 
exceptions everywhere isn't ideal.

The question is, what are the actual concrete cases where people will be 
sending DOM nodes? Without concrete cases, it's easy to construct 
artificial cases that prove this to be better one way or the other.

> Ok, I guess it comes down to if we think it's more likely that people 
> will send Nodes and other unsupported objects by accident or as optional 
> data, or because they really want to send them.

Yes.

> Personally my guess it's more likely that they really wanted to.

I have no idea which is more likely. The only use case I'm aware of is 
passing an  in, and for that there isn't really a fallback position, 
so it doesn't matter if we send null or throw an exception.

On Tue, 30 Mar 2010, Sigbjorn Finne wrote:
> 
> At Opera, we've gone back and forth on what's the preferable behaviour 
> here (previous spec versions did choose exceptions, I believe.) A third 
> option, and the traditional way of solving serialisation extensibility, 
> is to define an interface that host objects then need to implement to be 
> cloneable. Extra machinery.
> 
> Which one? Tempting to say that this it is a property of the host 
> language; returning 'null' fits non-strict EcmaScript one might argue, 
> exceptions its strict mode (such as it is/might become.) Languages that 
> provide more sophisticated type systems and enforcement might do a 
> better job.

I really don't think we want to even have a strict mode (just look at the 
mess it's given us in HTML!), so I am not of the opinion that we should 
add extra things that depend on that mode.

> Personally, I think throwing an exception fits in with the spec's use of 
> them elsewhere (i.e., cross-document and web workers.)

Where do we use exceptions for extension points in a similar way?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Proposal for secure key-value data stores

2010-03-30 Thread Dirk Pranke

On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas  wrote:
> Yes, that's precisely what I'm talking about. It seems to me that this will 
> end up being a pretty common pattern (encrypting/decrypting data stored 
> locally).
>
> The idea behind letting the key to be defined by the developer is to allow 
> any usage that developers deem appropriate for the situation. For example, 
> one might want to only use a server-generated key to access the data, in 
> which case this data won't be available offline but will be used to 
> supplement the online behavior. Another might determine the key based on some 
> information in a cookie, which is less secure but does allow offline access 
> while also ensuring that if the cookie changes or is deleted, the data 
> remains secure.
>
> The idea behind the expiration date is to allow developers to be sure the 
> data won't stay around on disk indefinitely. Think about the Internet café 
> use case where people are repeatedly logging in and out - we don't want 
> everyone's data living on that computer for however many years it's in use.
>
> One way or another, I think JavaScript crypto is going to be important in the 
> next few years.

Perhaps we should instead focus on a set of JS Crypto APIs, since that
is largely orthogonal to the storage APIs?

-- Dirk

[whatwg] Bug in form association algorithm

The spec says

"When a form-associated element has a form attribute and the ID of any
of the form elements in the Document changes, then the user agent must
reset the form owner of that form-associated element."

However it does not seem to reset the form owner if a form element
with an ID is added or removed to the Document. I suspect this is an
oversight that needs to be fixed.

Also, one critical step in the "reset the form owner" algorithm is
somewhat ambigious. Step 3.1 says

"If the first element in the Document to have an ID that is
case-sensitively equal to the element's form content attribute's value
is a form element, then associate the form-associated element with
that form  element."

However I wonder if "in the Document" includes only nodes that are
descendants of Document, or if it includes all nodes whose
ownerDocument is the Document. I.e. are disconnected subtrees "in the
Document"?

/ Jonas

[whatwg] Simple Links

2010-03-30 Thread Christoph Päper

If you think about various syntax variants of wiki systems they’ve got one 
thing in common that makes them preferable to direct HTML input: easy links! 
(Local ones at least, whatever that means.) The best known example is probably 
double square brackets as in Mediawiki, the engine that powers the 
Wikimediaverse. A link to another article on the same wiki is as simple as 
“[[Foo]]”, where HTML would have needed “Foo”.

I wonder whether HTML could and should provide some sort of similar shortening, 
i.e. “Foo” or even, just maybe, “Foo”. The UA would append 
the string content, properly encoded, to the base Web address as the 
hyperlink’s target, thus behave as had it encounters “Foo”.

I prefer the binary toggle role of the ‘href’ attribute, although it doesn’t 
work well in the XML serialisation, because it provides better compatibility 
with existing content and when I see or write “Bar” I rather think of 
the origin of that element name, ‘anchor’. So I expect it to be equivalent to 
“Bar” and “Bar” which would be shortcuts for “Bar”.

PS: Square brackets aren’t that simple actually, because on many keyboard 
layouts they’re not easy to input and might not be found on keytops at all.
PPS: The serialisation difference is not that important, because XML, unlike 
HTML, isn’t intended to be written by hand anyway.

Re: [whatwg] What will not work when we do not have server ?

2010-03-30 Thread Tab Atkins Jr.

On Mon, Mar 29, 2010 at 9:50 AM, narendra sisodiya
 wrote:
> Thanks a lot, what about server-sent, websocket ?
> At the same time I am thinking for using webshare command too.
> alias webshare='python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"'
> this command will start simple server at current directory. If i am unable
> to do something using file:/// , I will try to use this simple server.

Same exact thing.  If you don't have a webserver, anything that needs
to communicate with a webserver won't work.

If you can package a simple webserver that can be run automatically by
the end-user, then, well, you'll have a server to use.

~TJ

Re: [whatwg] Proposal for secure key-value data stores

2010-03-30 Thread Nicholas Zakas

Yes, that's precisely what I'm talking about. It seems to me that this will end 
up being a pretty common pattern (encrypting/decrypting data stored locally).

The idea behind letting the key to be defined by the developer is to allow any 
usage that developers deem appropriate for the situation. For example, one 
might want to only use a server-generated key to access the data, in which case 
this data won't be available offline but will be used to supplement the online 
behavior. Another might determine the key based on some information in a 
cookie, which is less secure but does allow offline access while also ensuring 
that if the cookie changes or is deleted, the data remains secure.

The idea behind the expiration date is to allow developers to be sure the data 
won't stay around on disk indefinitely. Think about the Internet café use case 
where people are repeatedly logging in and out - we don't want everyone's data 
living on that computer for however many years it's in use.

One way or another, I think JavaScript crypto is going to be important in the 
next few years. 

-Nicholas

__
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: dpra...@google.com [mailto:dpra...@google.com] On Behalf Of Dirk Pranke
Sent: Tuesday, March 30, 2010 1:24 PM
To: Jeremy Orlow
Cc: Nicholas Zakas; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for secure key-value data stores

Nicholas is almost certainly discussing the case where the service
provider requires any data stored on a customer's computer to be
encrypted, not the provider's own computers. (e.g., this could be a
Yahoo! policy that data stored on Yahoo! users' computers must be
encrypted).

Hence they cannot enforce anything like "use FileVault".

If the data is being encrypted and decrypted with a key provided by
the service (and not stored persistently), then the fact that the data
is accessible offline is moot. Although if the key can be retrieved
using the cookies that were available in the clear on the computer,
this is a weaker (but not completely shot down) point.

Perhaps an easy example of this would be to use LocalStorage for
password sync and password management for a web app (like LastPass).
We can implement the required crypto in JavaScript, but should we have
to?

-- Dirk

On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow  wrote:
> Most companies that have such policies enforce them with software that
> encrypts your home directory (or entire hard drive).  Since most (all?)
> browsers store such data within a users home directory, that should be
> sufficient for the specific case you're mentioning.  (Well, except
> for expiration.)  Note that home directory encryption is easy and free on
> some Linux distros and Mac OS.  (I don't know either way about Windows.)
> To be honest, if someone can get at _any_ of your browser data (LocalStorage
> included) you have a pretty major problem.  So tacking something onto other
> storage APIs doesn't really make that much sense.  If someone can get at
> even just your cookies, they can probably do a lot of damage.
> What are the use cases around expiration of data?
> Lastly, we really should not be creating new APIs that are synchronous that
> involve multiple top level windows (like LocalStorage and this API you're
> proposing).  It makes it very difficult to achieve isolation and parallelism
> between multiple sites.
> J
> On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas 
> wrote:
>>
>> Hi everyone,
>>
>>
>>
>> In attempting to use localStorage at work, we ran into some major security
>> issues. Primary among those are the guidelines we have in place regarding
>> personalized user data. The short story is that personalized data cannot be
>> stored on disk unless it's encrypted using a company-validated encryption
>> mechanism and key. So if we actually wanted to use localStorage, we'd be
>> forced to encrypt each value as it was being written and then decrypt each
>> value being read. Because of this tediousness, we opted not to use it.
>>
>>
>>
>> Another major issue also relates to the persistence of the data in
>> localStorage. Whereas cookies allow you to specify a time at which the data
>> will be removed, localStorage is there more or less forever.
>>
>>
>>
>> It seems like any company that takes the security of its data seriously
>> would run into the same issues, and rather than forcing every company to
>> implement their own version of the same approach, a common native approach
>> would be incredibly useful.
>>
>>
>>
>> With these problems in mind, and talking with a few other interested
>> parties, I came up with a draft proposal for a client-side data storage
>> mechanism that automatically handles encryption, decryption, and data
>> expiration. I'd love to hear what people think:
>>
>>
>>
>> http://www.nczonline.net/blog/securestore-propo

Re: [whatwg] location.reload() on document.open()ed documents

2010-03-30 Thread Maciej Stachowiak

On Mar 30, 2010, at 7:38 AM, Henri Sivonen wrote:

The spec says about location.reload():
"Navigate the browsing context to the document's current address
with replacement enabled. The source browsing context must be the
browsing context being navigated."

It appears that this is what WebKit and Presto do. However, for
document.open()ed documents, it's not what Gecko and Trident do.

On each document.write() on a document.open()ed document, Gecko
appends the written string to a cache entry (at the method call
time--not at the tokenization time--which makes a difference of the
document loads external scripts that also call document.write()!).
Upon reload, Gecko parses the contents of the cache entry. This
produces interesting results if the document.open()ed document
itself calls document.write():

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/430

Trident does something more complicated, because demo 430 doesn't
show the same results as in Gecko. However, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/429
shows that reload() exists in Trident and is not a no-op. Trident's
behavior could be explained by Trident making document.write() a no-
op when reloading a document.open()ed document. See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/431

Loading demo 429 in WebKit or Presto reloads the top-level document
in the iframe causing the alert to run again and again and again.

...

This makes me wonder: If the two engines with the largest market
share both take steps to enable document.open()ed docs to be
reloaded, is the behavior needed for optimal Web compatibility? How
well are WebKit and Presto getting away with their failure to do
what Gecko and Trident do here? It seems that Gecko is getting away
with its failure to do exactly what Trident does in the complex cases.

I could not find any bugs in http://bugs.webkit.org/ that were
identifiably about this issue. Nor in Radar (Apple's internal bug
tracker). Though I have not done thorough testing, I do not believe it
is a compatibility issue.

Regards,
Maciej

Re: [whatwg] Proposal for secure key-value data stores

2010-03-30 Thread Dirk Pranke

Nicholas is almost certainly discussing the case where the service
provider requires any data stored on a customer's computer to be
encrypted, not the provider's own computers. (e.g., this could be a
Yahoo! policy that data stored on Yahoo! users' computers must be
encrypted).

Hence they cannot enforce anything like "use FileVault".

If the data is being encrypted and decrypted with a key provided by
the service (and not stored persistently), then the fact that the data
is accessible offline is moot. Although if the key can be retrieved
using the cookies that were available in the clear on the computer,
this is a weaker (but not completely shot down) point.

Perhaps an easy example of this would be to use LocalStorage for
password sync and password management for a web app (like LastPass).
We can implement the required crypto in JavaScript, but should we have
to?

-- Dirk

On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow  wrote:
> Most companies that have such policies enforce them with software that
> encrypts your home directory (or entire hard drive).  Since most (all?)
> browsers store such data within a users home directory, that should be
> sufficient for the specific case you're mentioning.  (Well, except
> for expiration.)  Note that home directory encryption is easy and free on
> some Linux distros and Mac OS.  (I don't know either way about Windows.)
> To be honest, if someone can get at _any_ of your browser data (LocalStorage
> included) you have a pretty major problem.  So tacking something onto other
> storage APIs doesn't really make that much sense.  If someone can get at
> even just your cookies, they can probably do a lot of damage.
> What are the use cases around expiration of data?
> Lastly, we really should not be creating new APIs that are synchronous that
> involve multiple top level windows (like LocalStorage and this API you're
> proposing).  It makes it very difficult to achieve isolation and parallelism
> between multiple sites.
> J
> On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas 
> wrote:
>>
>> Hi everyone,
>>
>>
>>
>> In attempting to use localStorage at work, we ran into some major security
>> issues. Primary among those are the guidelines we have in place regarding
>> personalized user data. The short story is that personalized data cannot be
>> stored on disk unless it’s encrypted using a company-validated encryption
>> mechanism and key. So if we actually wanted to use localStorage, we’d be
>> forced to encrypt each value as it was being written and then decrypt each
>> value being read. Because of this tediousness, we opted not to use it.
>>
>>
>>
>> Another major issue also relates to the persistence of the data in
>> localStorage. Whereas cookies allow you to specify a time at which the data
>> will be removed, localStorage is there more or less forever.
>>
>>
>>
>> It seems like any company that takes the security of its data seriously
>> would run into the same issues, and rather than forcing every company to
>> implement their own version of the same approach, a common native approach
>> would be incredibly useful.
>>
>>
>>
>> With these problems in mind, and talking with a few other interested
>> parties, I came up with a draft proposal for a client-side data storage
>> mechanism that automatically handles encryption, decryption, and data
>> expiration. I’d love to hear what people think:
>>
>>
>>
>> http://www.nczonline.net/blog/securestore-proposal/
>>
>>
>>
>>
>>
>> -Nicholas
>>
>>
>>
>> __
>>
>> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
>>
>> Morpheus: "My beliefs do not require them to."
>>
>>
>

Re: [whatwg] whatwg Digest, Vol 72, Issue 63

2010-03-30 Thread Evan Ireland

Nicholas,

Looks interesting. Quite similar to an API I was working on recently (a
non-web API in my case). 

A question though:

"... the callback must be called asynchronously ..."

Why? Do you anticipate that openSecureStorage may take so long to execute
that we want to avoid blocking the UI thread? Can't we have a callback
that is invoked synchronously?

> -Original Message-
> From: whatwg-boun...@lists.whatwg.org 
> [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of 
> whatwg-requ...@lists.whatwg.org
> Sent: Wednesday, 31 March 2010 8:07 a.m.
> To: whatwg@lists.whatwg.org
> Subject: whatwg Digest, Vol 72, Issue 63
> 
> Send whatwg mailing list submissions to
>   whatwg@lists.whatwg.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
> or, via email, send a message with subject or body 'help' to
>   whatwg-requ...@lists.whatwg.org
> 
> You can reach the person managing the list at
>   whatwg-ow...@lists.whatwg.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of whatwg digest..."
> 
> 
> Today's Topics:
> 
>1. Proposal for secure key-value data stores (Nicholas Zakas)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 30 Mar 2010 11:55:12 -0700
> From: "Nicholas Zakas" 
> To: 
> Subject: [whatwg] Proposal for secure key-value data stores
> Message-ID:
>   
> <4e45ec6ad219fd47ad1bc06e4ee3845d04a42...@snv-exvs09.ds.corp.y
ahoo.com>
>   
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi everyone,
> 
>  
> 
> In attempting to use localStorage at work, we ran into some major
> security issues. Primary among those are the guidelines we 
> have in place
> regarding personalized user data. The short story is that personalized
> data cannot be stored on disk unless it's encrypted using a
> company-validated encryption mechanism and key. So if we 
> actually wanted
> to use localStorage, we'd be forced to encrypt each value as it was
> being written and then decrypt each value being read. Because of this
> tediousness, we opted not to use it. 
> 
>  
> 
> Another major issue also relates to the persistence of the data in
> localStorage. Whereas cookies allow you to specify a time at which the
> data will be removed, localStorage is there more or less forever.
> 
>  
> 
> It seems like any company that takes the security of its data 
> seriously
> would run into the same issues, and rather than forcing every 
> company to
> implement their own version of the same approach, a common native
> approach would be incredibly useful.
> 
>  
> 
> With these problems in mind, and talking with a few other interested
> parties, I came up with a draft proposal for a client-side 
> data storage
> mechanism that automatically handles encryption, decryption, and data
> expiration. I'd love to hear what people think:
> 
>  
> 
> http://www.nczonline.net/blog/securestore-proposal/
> 
>  
> 
>  
> 
> -Nicholas
> 
>  
> 
> __
> 
> Commander Lock: "Damnit Morpheus, not everyone believes what you
> believe!"
> 
> Morpheus: "My beliefs do not require them to."
> 
>  
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachmen
ts/20100330/161836e3/attachment.html>
> 
> --
> 
> ___
> whatwg mailing list
> whatwg@lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
> 
> 
> End of whatwg Digest, Vol 72, Issue 63
> **
>

Re: [whatwg] Proposal for secure key-value data stores

On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow  wrote:
> Lastly, we really should not be creating new APIs that are synchronous that
> involve multiple top level windows (like LocalStorage and this API you're
> proposing).  It makes it very difficult to achieve isolation and parallelism
> between multiple sites.

For what it's worth, this API uses an asynchronous getter to get hold
of the storage object. So the problem that you are describing, and
which does exist with localStorage, does not exist with this new API.

/ Jonas

Re: [whatwg] More questions about the DnD API

On Tue, Mar 30, 2010 at 2:54 AM, Stef Epardaud  wrote:

> On Tue, Mar 30, 2010 at 02:33:07AM -0700, Daniel Cheng wrote:
> >  But what was the rationale for preventing key events while doing
> DnD?
> >
> >I'm not 100% sure, but I'm assume it's so that the process of dragging
> and
> >dropping doesn't trigger unrelated mouse / keyboard listeners.
>
> Unrelated yes, but that also prevents applications from adding DnD
> functionality based on key presses.
>
> >  Why not make the implied drag and/or dragstart explicitely fired
> when
> >  external applications start DnD in the browser? That might make it
> >  simpler and more consistent.
> >
> >Because those events are intended for a source node. It introduces
> several
> >new problems (which node should get the event? how do authors
> differentiate
> >between the two different types of dragstart?) without really solving
> >anything that isn't already handled by other events. If you have drop
> >targets in your page, you don't really care about a drag and drop
> operation
> >in progress unless the item is dragged over your page--at which point
> one
> >can simply use dragenter / dragover / dragleave.
>
> How about registering the drag/dragstart on window.external?
>
> So you're saying that if I start dragging from a document element (say a
> div) and from an external application over the document, in both cases a
> dragenter listener registered on the body element should get fired even
> when the drag is currently over a descendent of the body?
> Same for dragleave when the drag is finished or the drag went out of the
> browser window (to other external apps for example)?
>
> If so, then I can live with this.
>

Yep, as long as event propagation is not stopped.


> --
> Stéphane Epardaud
>

Re: [whatwg] Proposal for secure key-value data stores

2010-03-30 Thread Jeremy Orlow

Most companies that have such policies enforce them with software that
encrypts your home directory (or entire hard drive).  Since most (all?)
browsers store such data within a users home directory, that should be
sufficient for the specific case you're mentioning.  (Well, except
for expiration.)  Note that home directory encryption is easy and free on
some Linux distros and Mac OS.  (I don't know either way about Windows.)

To be honest, if someone can get at _any_ of your browser data (LocalStorage
included) you have a pretty major problem.  So tacking something onto other
storage APIs doesn't really make that much sense.  If someone can get at
even just your cookies, they can probably do a lot of damage.

What are the use cases around expiration of data?

Lastly, we really should not be creating new APIs that are synchronous that
involve multiple top level windows (like LocalStorage and this API you're
proposing).  It makes it very difficult to achieve isolation and parallelism
between multiple sites.

J

On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas wrote:

>  Hi everyone,
>
>
>
> In attempting to use localStorage at work, we ran into some major security
> issues. Primary among those are the guidelines we have in place regarding
> personalized user data. The short story is that personalized data cannot be
> stored on disk unless it’s encrypted using a company-validated encryption
> mechanism and key. So if we actually wanted to use localStorage, we’d be
> forced to encrypt each value as it was being written and then decrypt each
> value being read. Because of this tediousness, we opted not to use it.
>
>
>
> Another major issue also relates to the persistence of the data in
> localStorage. Whereas cookies allow you to specify a time at which the data
> will be removed, localStorage is there more or less forever.
>
>
>
> It seems like any company that takes the security of its data seriously
> would run into the same issues, and rather than forcing every company to
> implement their own version of the same approach, a common native approach
> would be incredibly useful.
>
>
>
> With these problems in mind, and talking with a few other interested
> parties, I came up with a draft proposal for a client-side data storage
> mechanism that automatically handles encryption, decryption, and data
> expiration. I’d love to hear what people think:
>
>
>
> http://www.nczonline.net/blog/securestore-proposal/
>
>
>
>
>
> -Nicholas
>
>
>
> __
>
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
>
> Morpheus: "My beliefs do not require them to."
>
>
>

[whatwg] Proposal for secure key-value data stores

2010-03-30 Thread Nicholas Zakas

Hi everyone,

 

In attempting to use localStorage at work, we ran into some major
security issues. Primary among those are the guidelines we have in place
regarding personalized user data. The short story is that personalized
data cannot be stored on disk unless it's encrypted using a
company-validated encryption mechanism and key. So if we actually wanted
to use localStorage, we'd be forced to encrypt each value as it was
being written and then decrypt each value being read. Because of this
tediousness, we opted not to use it. 

 

Another major issue also relates to the persistence of the data in
localStorage. Whereas cookies allow you to specify a time at which the
data will be removed, localStorage is there more or less forever.

 

It seems like any company that takes the security of its data seriously
would run into the same issues, and rather than forcing every company to
implement their own version of the same approach, a common native
approach would be incredibly useful.

 

With these problems in mind, and talking with a few other interested
parties, I came up with a draft proposal for a client-side data storage
mechanism that automatically handles encryption, decryption, and data
expiration. I'd love to hear what people think:

 

http://www.nczonline.net/blog/securestore-proposal/

 

 

-Nicholas

 

__

Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"

Morpheus: "My beliefs do not require them to."

Re: [whatwg] Video Tag Proposal

2010-03-30 Thread Perry Smith

Isn't the concept of a submarine patent also possible against a  
"patented" algorithm?


Perry

[whatwg] location.reload() on document.open()ed documents

2010-03-30 Thread Henri Sivonen

The spec says about location.reload():
"Navigate the browsing context to the document's current address with 
replacement enabled. The source browsing context must be the browsing context 
being navigated."

It appears that this is what WebKit and Presto do. However, for 
document.open()ed documents, it's not what Gecko and Trident do.

On each document.write() on a document.open()ed document, Gecko appends the 
written string to a cache entry (at the method call time--not at the 
tokenization time--which makes a difference of the document loads external 
scripts that also call document.write()!). Upon reload, Gecko parses the 
contents of the cache entry. This produces interesting results if the 
document.open()ed document itself calls document.write():
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/430

Trident does something more complicated, because demo 430 doesn't show the same 
results as in Gecko. However, 
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/429 shows that 
reload() exists in Trident and is not a no-op. Trident's behavior could be 
explained by Trident making document.write() a no-op when reloading a 
document.open()ed document. See 
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/431

Loading demo 429 in WebKit or Presto reloads the top-level document in the 
iframe causing the alert to run again and again and again.

What about the reload UI? 
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/428 creates a 
document.open()ed top-level browsing context making it possible to try out the 
reload button in the UI.

Gecko and Trident appear to do what they do with reload(). WebKit makes 
reloading from the UI a no-op, but neither Safari nor Chrome bothers to put the 
reload UI in the disabled state. Presto loads the document at the document's 
address (i.e. the opener's address).

This makes me wonder: If the two engines with the largest market share both 
take steps to enable document.open()ed docs to be reloaded, is the behavior 
needed for optimal Web compatibility? How well are WebKit and Presto getting 
away with their failure to do what Gecko and Trident do here? It seems that 
Gecko is getting away with its failure to do exactly what Trident does in the 
complex cases.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] Video Tag Proposal

2010-03-30 Thread Tab Atkins Jr.

On Tue, Mar 30, 2010 at 6:58 AM, Eoin Kilfeather  wrote:
> Forgive my ignorance, I Am Not A Lawyer, but what are the consequences
> of a submarine patent on Theora and/or Vorbis? If a browser supports
> it in good faith, and subsequently a troll successfully introduces a
> patent challenge, would the consequence not be that the codec would
> simply be dropped with the next maintenance release of the browser? In
> fact a court would surely allow a reasonable time for transition. OK,
> annoying that content providers need to  re-encoded in a "legal"
> codec, but that is at least a work-flow susceptible to automation. I
> can't see a court giving financial "damages" for infringement of a
> patent which hasn't surfaced since  was proposed at the end of
> 2006.

Never doubt the stupidity and banality of patent judges in America.

~TJ

Re: [whatwg] Video Tag Proposal

2010-03-30 Thread Rob Crowther


Eoin Kilfeather wrote:

Forgive my ignorance, I Am Not A Lawyer,


Neither am I..

In fact a court would surely allow a reasonable time for transition. 


If it's got as far as a court then it probably already cost you a 
significant chunk of money.


Rob

Re: [whatwg] WebSocket bufferedAmount includes overhead or not

On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer  wrote:
> On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking  wrote:
>>
>> On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson  wrote:
>>>
>>> On Tue, 23 Mar 2010, Anne van Kesteren wrote:

 We (Opera) would prefer this too. I.e. to not impose details of the
 protocol on the API.
>>>
>>> If we're exposing nothing from the protocol, does that mean we shouldn't
>>> be exposing that the string converts to UTF-8 either?
>>
>> While exposing the fact that strings are sent as UTF-8 does say
>> something about the protocol, I think it's still much more protocol
>> independent than including the message headers. The string has to be
>> serialized in some way, and it seems unlikely that any newly developed
>> protocol in the foreseeable future would use anything other than UTF-8
>> as serialization.
>
> True, but if bufferedAmount does not byte for byte (or character for
> character) match what is fed to the API, what does a few bytes
> representing the current overhead matter? IIRC EcmaScript uses UTF-16,
> which means that serialization will in most cases make the number of
> actually buffered bytes differ from the number of bytes in the original
> message buffer.

EcmaScript doesn't do any serialization so I'm not sure what you mean here?

> And just because we currently use UTF-8 for
> serialization doesn't mean that will always be the case. Thus API users
> cannot rely on performing their own conversion to UTF-8 just to find out
> exactly how many characters in their message have been sent.

My point was that using anything but UTF-8 is unlikely. So the
opposite of what you're saying here.

> The fact remains that, unless we want to force implementors of the
> protocol to match each byte sent over the network with a specific
> character in the original message handed to the API, bufferedAmount cannot
> represent something unaffected by the protocol. And if we allow
> bufferedAmount to be affected by the protocol, why not let it be decided
> by the implementation whether or not to include protocol overhead?

Making it implementation dependent is likely to lead to website
incompatibilities. Such as:

ws = new WebSocket(...);
ws.onopen = function() {
  ws.send(someString);
  if (ws.bufferedAmount > X) {
doStuff();
  }
};

If this is implementation dependent then the above could reliably call
doStuff in one implementation, but reliably not another.

/ Jonas

Re: [whatwg] Video Tag Proposal

2010-03-30 Thread Eoin Kilfeather

Forgive my ignorance, I Am Not A Lawyer, but what are the consequences
of a submarine patent on Theora and/or Vorbis? If a browser supports
it in good faith, and subsequently a troll successfully introduces a
patent challenge, would the consequence not be that the codec would
simply be dropped with the next maintenance release of the browser? In
fact a court would surely allow a reasonable time for transition. OK,
annoying that content providers need to  re-encoded in a "legal"
codec, but that is at least a work-flow susceptible to automation. I
can't see a court giving financial "damages" for infringement of a
patent which hasn't surfaced since  was proposed at the end of
2006.

On Mon, Mar 29, 2010 at 10:23 AM, David Gerard  wrote:
> On 29 March 2010 09:41, Kit Grose  wrote:
>
>> Apple is at heart a hardware company. My understanding of their objections 
>> to OGG have been also largely due to a lack of hardware decoder support in 
>> their iPods/iPhones.
>
>
> No, they claimed submarine patents as their actual objection to Theora.
>
> (I'm not aware of them making an express claim of this sort regarding Vorbis.)
>
>
> - d.
>

-- 
Eoin Kilfeather
Digital Media Centre
Dublin Institute of Technology
Aungier Street
Dublin 2
m. +353 87 2235928
skype:ekilfeather

Re: [whatwg] More questions about the DnD API

On Tue, Mar 30, 2010 at 02:33:07AM -0700, Daniel Cheng wrote:
>  But what was the rationale for preventing key events while doing DnD?
> 
>I'm not 100% sure, but I'm assume it's so that the process of dragging and
>dropping doesn't trigger unrelated mouse / keyboard listeners.

Unrelated yes, but that also prevents applications from adding DnD
functionality based on key presses.

>  Why not make the implied drag and/or dragstart explicitely fired when
>  external applications start DnD in the browser? That might make it
>  simpler and more consistent.
> 
>Because those events are intended for a source node. It introduces several
>new problems (which node should get the event? how do authors differentiate
>between the two different types of dragstart?) without really solving
>anything that isn't already handled by other events. If you have drop
>targets in your page, you don't really care about a drag and drop operation
>in progress unless the item is dragged over your page--at which point one
>can simply use dragenter / dragover / dragleave.

How about registering the drag/dragstart on window.external?

So you're saying that if I start dragging from a document element (say a
div) and from an external application over the document, in both cases a
dragenter listener registered on the body element should get fired even
when the drag is currently over a descendent of the body?
Same for dragleave when the drag is finished or the drag went out of the
browser window (to other external apps for example)?

If so, then I can live with this.
-- 
Stéphane Epardaud

Re: [whatwg] WebSocket bufferedAmount includes overhead or not

2010-03-30 Thread Niklas Beischer


On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking  wrote:


On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson  wrote:

On Tue, 23 Mar 2010, Anne van Kesteren wrote:


We (Opera) would prefer this too. I.e. to not impose details of the
protocol on the API.


If we're exposing nothing from the protocol, does that mean we shouldn't
be exposing that the string converts to UTF-8 either?


While exposing the fact that strings are sent as UTF-8 does say
something about the protocol, I think it's still much more protocol
independent than including the message headers. The string has to be
serialized in some way, and it seems unlikely that any newly developed
protocol in the foreseeable future would use anything other than UTF-8
as serialization.


True, but if bufferedAmount does not byte for byte (or character for
character) match what is fed to the API, what does a few bytes
representing the current overhead matter? IIRC EcmaScript uses UTF-16,
which means that serialization will in most cases make the number of
actually buffered bytes differ from the number of bytes in the original
message buffer. And just because we currently use UTF-8 for
serialization doesn't mean that will always be the case. Thus API users
cannot rely on performing their own conversion to UTF-8 just to find out
exactly how many characters in their message have been sent.

The fact remains that, unless we want to force implementors of the
protocol to match each byte sent over the network with a specific
character in the original message handed to the API, bufferedAmount cannot
represent something unaffected by the protocol. And if we allow
bufferedAmount to be affected by the protocol, why not let it be decided
by the implementation whether or not to include protocol overhead?

As Boris Zbarsky suggested earlier in this thread it might be an idea to
not over-specify this particular part of the API.

BR,
 /niklas


--
Niklas Beischer
Software Developer
Opera Software

Re: [whatwg] More questions about the DnD API

On Tue, Mar 30, 2010 at 1:58 AM, Stef Epardaud  wrote:

> On Tue, Mar 30, 2010 at 01:50:45AM -0700, Daniel Cheng wrote:
> >  I want to do more than most file managers and let users visit
> >  subdirectories by pressing control while over them, so they can
> continue
> >  the drag operation inside the directory (and go deeper potentially).
> >  A separate event makes it much easier to detect the key press.
>
> But what was the rationale for preventing key events while doing DnD?
>

I'm not 100% sure, but I'm assume it's so that the process of dragging and
dropping doesn't trigger unrelated mouse / keyboard listeners.

>
> >  No I mean, when an external application initiates a drag and then
> enters
> >  my browser window/document to look for potential places where it
> could
> >  drop it. I want to detect that and highlight all drop targets in the
> >  page. I would do this in the "drag" or "dragstart" events if this
> was
> >  started in the document, but how to do it when it is started by an
> >  external application?
> >
> >I'd probably use a dragenter listener on the body of the document.
>
> I couldn't get that to work properly with FF 3.6 and gave up after a few
> crashes and hangs (which admitedly are not the spec's fault).

This is probably just an artifact of an incomplete implementation. I don't
think any released browser has implemented 100% of the DnD interfaces yet.
I've also  noticed that some browsers hang if you use alert() during a DnD
event.

>
> Why not make the implied drag and/or dragstart explicitely fired when
> external applications start DnD in the browser? That might make it
> simpler and more consistent.
>

Because those events are intended for a source node. It introduces several
new problems (which node should get the event? how do authors differentiate
between the two different types of dragstart?) without really solving
anything that isn't already handled by other events. If you have drop
targets in your page, you don't really care about a drag and drop operation
in progress unless the item is dragged over your page--at which point one
can simply use dragenter / dragover / dragleave.

> --
> Stéphane Epardaud
>

Re: [whatwg] More questions about the DnD API

On Tue, Mar 30, 2010 at 01:31:15AM -0700, Daniel Cheng wrote:
>  But then it's up to the developer to detect that the keys weren't
>  pressed before (implement keydown events themselves), which is less
>  practical.
> 
>If you're copying the behavior of file managers, isn't it simply a matter 
> of
>setting dropEffect to whatever the current state of the modifier keys are?
>function dragOver(e) {
>Â Â if (e.ctrlKey) e.dropEffect = 'copy';
>Â Â else e.dropEffect = 'move';
>Â Â e.preventDefault();
>}
>I'm not sure how having separate keyboard events would help in this case,
>since you can't set dropEffect directly from a keyboard event.

I want to do more than most file managers and let users visit
subdirectories by pressing control while over them, so they can continue
the drag operation inside the directory (and go deeper potentially).

A separate event makes it much easier to detect the key press.

>  But if I want to be notified that an external application started a drag
>  in my document, where should I place the listener then? document? body
>  node?
> 
>If an external application initiates a drag in your DOM page via the
>appropriate method for your platform, it should be the same as if a user
>initiated it. The dragstart event / drag events should end up getting fired
>at whatever node the application initiated the drag on. Maybe I'm
>misunderstanding your question though...

No I mean, when an external application initiates a drag and then enters
my browser window/document to look for potential places where it could
drop it. I want to detect that and highlight all drop targets in the
page. I would do this in the "drag" or "dragstart" events if this was
started in the document, but how to do it when it is started by an
external application?
-- 
Stéphane Epardaud

Re: [whatwg] More questions about the DnD API

On Tue, Mar 30, 2010 at 01:50:45AM -0700, Daniel Cheng wrote:
>  I want to do more than most file managers and let users visit
>  subdirectories by pressing control while over them, so they can continue
>  the drag operation inside the directory (and go deeper potentially).
>  A separate event makes it much easier to detect the key press.

But what was the rationale for preventing key events while doing DnD?

>  No I mean, when an external application initiates a drag and then enters
>  my browser window/document to look for potential places where it could
>  drop it. I want to detect that and highlight all drop targets in the
>  page. I would do this in the "drag" or "dragstart" events if this was
>  started in the document, but how to do it when it is started by an
>  external application?
> 
>I'd probably use a dragenter listener on the body of the document.

I couldn't get that to work properly with FF 3.6 and gave up after a few
crashes and hangs (which admitedly are not the spec's fault).

Why not make the implied drag and/or dragstart explicitely fired when
external applications start DnD in the browser? That might make it
simpler and more consistent.
-- 
Stéphane Epardaud

Re: [whatwg] Web Workers feedback

2010-03-30 Thread Sigbjorn Finne

On 3/30/2010 09:54, Jonas Sicking wrote:
> On Tue, Mar 30, 2010 at 12:20 AM, Ian Hickson  wrote:
>   
>> On Mon, 29 Mar 2010, Jonas Sicking wrote:
>> 
>> ...
>>> Additionally, it's unlikely that converting to null is the fallback
>>> behavior you want for downlevel clients. Likely you'd want to manually
>>> serialize such objects and then parse them on the receiver side. In this
>>> case too an exception would likely help you more than silently
>>> converting to null.
>>>   
>> It depends on how critical the DOM node is. If it's just a reference deep
>> inside some nested structure, which the other side only uses as an
>> additional hint rather than as a required component of the corresponding
>> algorithm, it's simpler just to have the UA convert it to null.
>> 
> Ok, I guess it comes down to if we think it's more likely that people
> will send Nodes and other unsupported objects by accident or as
> optional data, or because they really want to send them.
>
> Personally my guess it's more likely that they really wanted to.
>   

Hence tell them upfront that they are straying outside the supported set
of objects.

At Opera, we've gone back and forth on what's the preferable behaviour
here (previous spec versions did choose exceptions, I believe.) A third
option, and the traditional way of solving serialisation extensibility,
is to define an interface that host objects then need to implement to be
cloneable. Extra machinery.

Which one? Tempting to say that this it is a property of the host
language; returning 'null' fits non-strict EcmaScript one might argue,
exceptions its strict mode (such as it is/might become.) Languages that
provide more sophisticated type systems and enforcement might do a
better job. Personally, I think throwing an exception fits in with the
spec's use of them elsewhere (i.e., cross-document and web workers.)

If it is changed back, please leave behind a footnote about the issue ;-)

--sigbjorn | s...@opera.com

Re: [whatwg] More questions about the DnD API

On Tue, Mar 30, 2010 at 1:39 AM, Stef Epardaud  wrote:

> On Tue, Mar 30, 2010 at 01:31:15AM -0700, Daniel Cheng wrote:
> >  But then it's up to the developer to detect that the keys weren't
> >  pressed before (implement keydown events themselves), which is less
> >  practical.
> >
> >If you're copying the behavior of file managers, isn't it simply a
> matter of
> >setting dropEffect to whatever the current state of the modifier keys
> are?
> >function dragOver(e) {
> >Â Â if (e.ctrlKey) e.dropEffect = 'copy';
> >Â Â else e.dropEffect = 'move';
> >Â Â e.preventDefault();
> >}
> >I'm not sure how having separate keyboard events would help in this
> case,
> >since you can't set dropEffect directly from a keyboard event.
>
> I want to do more than most file managers and let users visit
> subdirectories by pressing control while over them, so they can continue
> the drag operation inside the directory (and go deeper potentially).
>
> A separate event makes it much easier to detect the key press.
>
> >  But if I want to be notified that an external application started a
> drag
> >  in my document, where should I place the listener then? document?
> body
> >  node?
> >
> >If an external application initiates a drag in your DOM page via the
> >appropriate method for your platform, it should be the same as if a
> user
> >initiated it. The dragstart event / drag events should end up getting
> fired
> >at whatever node the application initiated the drag on. Maybe I'm
> >misunderstanding your question though...
>
> No I mean, when an external application initiates a drag and then enters
> my browser window/document to look for potential places where it could
> drop it. I want to detect that and highlight all drop targets in the
> page. I would do this in the "drag" or "dragstart" events if this was
> started in the document, but how to do it when it is started by an
> external application?
>

I'd probably use a dragenter listener on the body of the document.


> --
> Stéphane Epardaud
>

Re: [whatwg] More questions about the DnD API

On Tue, Mar 30, 2010 at 12:38 AM, Stef Epardaud  wrote:

> On Mon, Mar 29, 2010 at 02:04:22PM -0700, Daniel Cheng wrote:
> >  I'm still trying to use the DnD for a real-world use, and keep
> hitting
> >  problems. This is the HTML 5 draft at 7.9.4 Drag-and-drop processing
> >  model:
> >  "From this point until the end of the drag-and-drop operation,
> device
> >  input events (e.g. mouse and keyboard events) must be suppressed."
> >
> >DragEvent (via MouseEvent) should expose ctrlKey, altKey, metaKey, and
> >shiftKey properties.
>
> But then it's up to the developer to detect that the keys weren't
> pressed before (implement keydown events themselves), which is less
> practical.
>

If you're copying the behavior of file managers, isn't it simply a matter of
setting dropEffect to whatever the current state of the modifier keys are?

function dragOver(e) {
  if (e.ctrlKey) e.dropEffect = 'copy';
  else e.dropEffect = 'move';
  e.preventDefault();
}

I'm not sure how having separate keyboard events would help in this case,
since you can't set dropEffect directly from a keyboard event.

>
> >dragstart and drag events are fired at the source node, but since
> you're
> >dragging from a non-DOM application, you won't get any. You should
> still be
> >getting dragenter / dragover / dragleave / drop if the item is
> >dragged/dropped over a DOM page though. It works for me in WebKit.
>
> But if I want to be notified that an external application started a drag
> in my document, where should I place the listener then? document? body
> node?
>

If an external application initiates a drag in your DOM page via the
appropriate method for your platform, it should be the same as if a user
initiated it. The dragstart event / drag events should end up getting fired
at whatever node the application initiated the drag on. Maybe I'm
misunderstanding your question though...

> --
> Stéphane Epardaud
>

Re: [whatwg] Web Workers feedback

On Tue, Mar 30, 2010 at 12:20 AM, Ian Hickson  wrote:
> On Mon, 29 Mar 2010, Jonas Sicking wrote:
>> >
>> > We could throw an exception, but that would make migrating from this
>> > not being supported to this being supported later a lot harder (you'd
>> > have to catch exceptions and then remove the nodes, rather than just
>> > doing null checks in the worker). I don't know that that's worth it.
>>
>> I don't see why it would be harder to add support for passing objects
>> later harder. I would say quite the opposite. People are more likely to
>> come to depend on objects down in an object graph being converted to
>> null, than they are to come to depend on that throwing an exception.
>
> I agree that people are less likely to depend on exceptions. The problem
> is feature detection so that you can use the new feature (sending DOM
> nodes) in new clients without failing in old clients. When sending null
> it's easy; when raising exceptions, you have to have two different sends.

I would rather argue that throwing an exception makes feature
detection simpler. That way you can do something like:

try {
  w.postMessage(obj);
} catch() {
  var f = {};
  f.x = obj.x;
  f.y = obj.y;
  f.complex = serializeOrCreateOtherFallback(obj.complex);
  w.postMessage(f);
}


If null is sent you have to inside the worker send back an error
message to the sender. The sender has to find the correct data to
send, which could be hard given that the error message is received
asynchronously, and then resend.

>> Additionally, it's unlikely that converting to null is the fallback
>> behavior you want for downlevel clients. Likely you'd want to manually
>> serialize such objects and then parse them on the receiver side. In this
>> case too an exception would likely help you more than silently
>> converting to null.
>
> It depends on how critical the DOM node is. If it's just a reference deep
> inside some nested structure, which the other side only uses as an
> additional hint rather than as a required component of the corresponding
> algorithm, it's simpler just to have the UA convert it to null.

Ok, I guess it comes down to if we think it's more likely that people
will send Nodes and other unsupported objects by accident or as
optional data, or because they really want to send them.

Personally my guess it's more likely that they really wanted to.

/ Jonas

Re: [whatwg] More questions about the DnD API