On Sat, 23 Jul 2011 16:19:37 +0200, Glenn Adams gl...@skynav.com wrote:
Under the description of clickjacking, appears causing harm to
visitor; however, there is no indication of how this may cause such
harm. Please
elaborate or refer to an external document that elaborates.
Referenced
On Sat, 23 Jul 2011 16:04:56 +0200, Glenn Adams gl...@skynav.com wrote:
I would suggest not using the word theft, even if placed in quotes.
Fair enough.
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html#introduction
--
Anne van Kesteren
http://annevankesteren.nl/
On Sat, 23 Jul 2011 16:49:38 +0200, Glenn Adams gl...@skynav.com wrote:
The description of privacy leakage doesn't elaborate the issue
sufficiently. I'd suggest adding a reference to a more complete, external
document that discusses this in detail.
It seems pretty clear to me. Any suggestions?
If I may briefly summarize the pros and cons of every approach discussed:
X-MYWIDGET
Pros:
- element name is inherently immutable
- can provide arbitrary API, can (but does not have to) derive from
arbitrary HTML element
- best performance (in instantiation, CSS selector matching)
Cons:
-
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14351
Anne ann...@opera.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Is x-mywidget necessarily more performant? Why?
On Oct 3, 2011 5:33 AM, Roland Steiner rolandstei...@google.com wrote:
If I may briefly summarize the pros and cons of every approach discussed:
X-MYWIDGET
Pros:
- element name is inherently immutable
- can provide arbitrary API, can (but
+1
What Charles said = )
On Wed, Sep 28, 2011 at 5:22 PM, Charles Pritchard ch...@jumis.com wrote:
On 9/27/2011 11:39 PM, Roland Steiner wrote:
Expanding on the general web component discussion, one area that hasn't
been touched on AFAIK is how components fit within the content model of
On Fri, Sep 30, 2011 at 8:05 PM, Jonas Sicking jo...@sicking.cc wrote:
Unless responseType== or responseType==document I don't think we
should do *any* HTML or XML parsing. Even the minimal amount needed to
do charset detection.
I'd be happy to implement it that way.
For responseType==text
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364
Summary: [appcache] manifest attribute should accept data-uris
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14288
Ms2ger ms2...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14331
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
As we're implementing IDBFactory.cmp in WebKit we noticed that the
ordering sense is reversed compared to C's strcmp/memcmp, Perl's cmp/=
operators, etc.
As currently spec'd, IDBFactory.cmp(first, second) returns 1 if first
second
C's memcmp/strcmp(first, second) return -1 if first second
On Mon, Oct 3, 2011 at 9:30 AM, Joshua Bell jsb...@chromium.org wrote:
As we're implementing IDBFactory.cmp in WebKit we noticed that the
ordering sense is reversed compared to C's strcmp/memcmp, Perl's cmp/=
operators, etc.
As currently spec'd, IDBFactory.cmp(first, second) returns 1 if first
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel outlined for IndexedDB, we're
happy with the new WebIDL approach.
I think we should go ahead and migrate the File API
On Sat, 1 Oct 2011, Israel Hilerio wrote:
We believe it is simpler and closer to the intent on the WebIDL spec to
say: Throws a DOMException of type VersionError.
Instead of having to explain what it means to throw a type as an
exception: To throw a “VersionError” exception, a user
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U er...@google.com wrote:
I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a loadend.
Now that Anne's
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan a...@mozilla.com wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel outlined for IndexedDB,
we're
happy with the
On 10/2/11 7:38 AM, Marcos Caceres wrote:
On Saturday, 1 October 2011 at 08:15, Anne van Kesteren wrote:
On Sat, 01 Oct 2011 02:56:55 +0200, Israel Hilerioisra...@microsoft.com
(mailto:isra...@microsoft.com)
wrote:
On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote:
Actually,
On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U er...@google.com wrote:
I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a
On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel
On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking jo...@sicking.cc wrote:
Unfortunately I suspect wanting to call open from event handlers is a
pretty common use case. Here are two use cases:
1. In case of a network error, let the onerror handler retry the request.
2. Implementing a
On 10/3/11 6:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathana...@mozilla.com wrote:
On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com
wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for
On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
For several of these I think we can reuse existing DOMExceptions.
Here's how I'd map the exceptions which are currently in the IndexedDB
spec:
UNKNOWN_ERR
Mint a new UnknownError. Alternatively we could simply throw an
On Mon, 3 Oct 2011, Arun Ranganathan wrote:
Cc'ing Hixie as well to comment on what HTML might need.
As far as I'm concerned, what HTML has now is fine (DOMException based
on how DOM Core defines it).
I'll leave this one for Anne. I personally don't care where the new
strings are
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14323
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Oct 3, 2011 at 4:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking jo...@sicking.cc wrote:
Unfortunately I suspect wanting to call open from event handlers is a
pretty common use case. Here are two use cases:
1. In case of a network error, let
Jonas,
We're removing error code values as part of the new exception type model. This
will impact the IDBRequest.errorCode property. I believe we want to rename
this property to errorName and change its type to DOMString in order to match
the new Exception type model name. This change will
On Mon, Oct 3, 2011 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 3 Oct 2011, Arun Ranganathan wrote:
Cc'ing Hixie as well to comment on what HTML might need.
As far as I'm concerned, what HTML has now is fine (DOMException based
on how DOM Core defines it).
I'll leave this one
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan a...@mozilla.com wrote:
On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com
wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to it.
On Mon, Oct 3, 2011 at 5:10 PM, Joshua Bell jsb...@chromium.org wrote:
On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
NON_TRANSIENT_ERR
I think in many cases we should simply throw a TypeError here.
On Mon, 3 Oct 2011, Jonas Sicking wrote:
I looked at how for example WebSockets and EventSource exposes error
information. I would have thought in both cases that it would have been
done as a property on the websocket/eventsource object itself. However I
couldn't find any such property,
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
1. Make loadend not fire in case a new load is started from
onabort/onload/onerror. Thus loadend and loadstart isn't always
paired up. Though there is
On Mon, Oct 3, 2011 at 6:00 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 3 Oct 2011, Jonas Sicking wrote:
I looked at how for example WebSockets and EventSource exposes error
information. I would have thought in both cases that it would have been
done as a property on the
On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking jo...@sicking.cc wrote:
So what exactly are you proposing we do for XHR and for
FileReader/FileWriter?
For APIs other than XHR, don't allow calling read* or abort during events
fired on the object from its own algorithms. This should give the
On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio isra...@microsoft.com wrote:
On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
For several of these I think we can reuse existing DOMExceptions.
Here's how I'd map the exceptions which are currently in the IndexedDB
spec:
On Mon, Oct 3, 2011 at 5:36 PM, Israel Hilerio isra...@microsoft.com wrote:
Jonas,
We’re removing error code values as part of the new exception type model.
This will impact the IDBRequest.errorCode property. I believe we want to
rename this property to errorName and change its type to
On Mon, 3 Oct 2011, Jonas Sicking wrote:
So MediaError is exactly the type of thing that I'm talking about that
we might want to move into the DOM4 spec. We have the same thing in the
File API spec. The FileError interface is just a plain object with a
single .code property. We're
On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking jo...@sicking.cc wrote:
So what exactly are you proposing we do for XHR and for
FileReader/FileWriter?
For APIs other than XHR, don't allow calling read* or abort during events
On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio isra...@microsoft.com wrote:
Based on previous conversations, it seems we've agreed that there are
situations in which a transaction could failed independent of explicit
requests (i.e. QUOTA_ERR, TIMEOUT_ERR). We believe that this can be
On Mon, Oct 3, 2011 at 7:17 PM, Jonas Sicking jo...@sicking.cc wrote:
IDBDatabase(Sync).createObjectStore if the options argument is handed
an object with properties other than those in the dictionary.
This doesn't actually match how dictionaries are supposed to behave
per WebIDL. They are
On Fri, 30 Sep 2011, Dominic Cooney wrote:
My point was just that the parsing differences have nothing to do with
whether you're creating a component that inherits from HTMLElement.
There are parsing issues regardless of where in the DOM you are.
Parsing issues which disappear
For reference, I wrote down all different variants of rendering and styling
of the host element/shadow root I could think of at:
http://wiki.whatwg.org/wiki/Component_Model_Discussion:_Rendering
Cheers,
- Roland
On Wed, Sep 28, 2011 at 5:14 AM, Julien Richard-Foy
jul...@richard-foy.frwrote:
42 matches
Mail list logo
