On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking wrote:
Yup. I do wonder if we should introduce a DOMError class which can be
reused in various cases which need APIs like this. IndexedDB could
also use it and I seem to recall that HTML5 does too.
I could certainly introduce a DOMError interfa
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14376
Summary: Move to the new WebIDL exceptions
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
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
wrote:
> Hi,
>
> If I underst
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 disappea
On Mon, Oct 3, 2011 at 7:17 PM, Jonas Sicking 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 defined to igno
On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio 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
> represented as an impl
On Mon, Oct 3, 2011 at 10:32 PM, Jonas Sicking wrote:
> > (More precisely, no method that starts or finishes a loadstart/loadend
> > sequence can be called from within an algorithm that also starts or
> finishes
> > a sequence. abort() from within onprogress is fine, for example.)
>
> I think th
On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking 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 f
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 pla
On Mon, Oct 3, 2011 at 5:36 PM, Israel Hilerio 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 DOMString in order
> t
On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio 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:
>>
>> UNKNOWN_ERR
>> Mint a
On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking 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 guarantee
that lo
On Mon, Oct 3, 2011 at 6:00 PM, Ian Hickson 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 websocket/eventsource obj
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking 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 always a "loadend" f
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 propert
Gmail rather unhelpfully linked to the tests in the text/html version of my
earlier mail with links that didn't match the text. Fixed (hopefully):
[1] https://zewt.org/~glenn/test-open-during-onabort.html#http/onabort (HTTP
timeout)
[2] https://zewt.org/~glenn/test-open-during-onabort.html#tcp/on
On Mon, Oct 3, 2011 at 5:10 PM, Joshua Bell wrote:
> On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio
> 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. That
>> > seems
>> > to matc
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan wrote:
> On 10/3/11 4:59 PM, Jonas Sicking wrote:
>>
>> On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan
>> 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 b
On Mon, Oct 3, 2011 at 4:26 PM, Ian Hickson 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 for
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 im
On Mon, Oct 3, 2011 at 4:16 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking 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 r
On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio 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. That seems
> > to match closely to how TypeError is used by WebIDL now.
>
> As I'm mapping
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14323
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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
> EC
On 10/3/11 6:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan wrote:
On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan
wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to i
On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking 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 auto-complete UI backed
On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan 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,
On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren wrote:
> On Thu, 29 Sep 2011 23:17:21 +0200, Eric U 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
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 Hileriomailto:isra...@microsoft.com)>
wrote:
On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote:
Actually, given
http://dvcs.w3.or
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan 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 n
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U 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 explained XHR2's model,
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 us
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 excep
On 10/1/11 4:59 AM, Ms2ger wrote:
Hi Jonas, Arun
As described in bug 13433 [1], the type of event handler IDL
attributes should be "[TreatNonCallableAsNull] Function?". Could you
change File API accordingly?
Thanks
Ms2ger
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13433
Done.
-- A
On Fri, Sep 30, 2011 at 7:03 PM, Ojan Vafai wrote:
> On Fri, Sep 30, 2011 at 12:40 PM, Ms2ger wrote:
>>
>> On 09/29/2011 04:32 PM, Doug Schepers wrote:
>>>
>>> Hi, Adam-
>>>
>>> I'm glad to see some progress on a replacement for Mutation Events.
>>>
>>> Would you be interested in being the editor
On Mon, Oct 3, 2011 at 9:30 AM, Joshua Bell 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
> < second
>
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
P
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14331
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NEEDS
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14288
Ms2ger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
On Fri, Sep 30, 2011 at 8:05 PM, Jonas Sicking 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" we curre
+1
What Charles said = )
On Wed, Sep 28, 2011 at 5:22 PM, Charles Pritchard 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 HTML
>> eleme
Is x-mywidget necessarily more performant? Why?
On Oct 3, 2011 5:33 AM, "Roland Steiner" wrote:
>
> If I may briefly summarize the pros and cons of every approach discussed:
>
>
>
> Pros:
> - element name is inherently immutable
> - can provide arbitrary API, can (but does not have to) derive f
If I may briefly summarize the pros and cons of every approach discussed:
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:
- accessibility onl
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14351
Anne changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sat, 23 Jul 2011 16:49:38 +0200, Glenn Adams 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?
--
Anne van
On Sat, 23 Jul 2011 16:19:37 +0200, Glenn Adams 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 Wikipedia:
http
On Sat, 23 Jul 2011 16:04:56 +0200, Glenn Adams 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/
49 matches
Mail list logo
