Hi Glenn,
> > var xhr = new XMLHttpRequest();
> > xhr.open("GET", "resource.jpg");
> > var urlObject = xhr.getURLObject();
> > var newURL = URL.getObjectURL(urlObject);
> > img.src = newURL;
It's neat and I like the idea, too. However, there is a reason that I prefer
our blob approaches:
> > ===
On 08/07/2012 03:29 AM, Glenn Maynard wrote:
On Sat, Aug 4, 2012 at 4:24 AM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:
5ms is quite low when the aim is 60Hz updates... but with
incremental/generational GCs 5ms sounds very much possible.
5ms is an *eternity* when you're aiming fo
On Tue, Aug 7, 2012 at 2:29 AM, Glenn Maynard wrote:
> 5ms is an *eternity* when you're aiming for 60 FPS, where you only have
> 16.6ms per frame to play with. That's 30% of your CPU budget just for
> memory management. It doesn't matter if it's 5ms every 100 frames, since
> it's the worst case
On Tue, Aug 7, 2012 at 4:07 AM, Jungkee Song wrote:
> window.intent.postResult(blob);
>
> From totally client developer's point of view, who perhaps do not care the
> underlying details at all, it is absolutely transparent to use the obtained
> blob as they used to deal with. (no matter which type
On Aug 7, 2012, at 17:06 , Glenn Maynard wrote:
> A different option, equivalent to users, is to make URLObject a base class of
> Blob. URLObject would replace Blob in methods like FileReader.readAsDataURL,
> createObjectURL and all other places where methods can work without knowing
> the size
FWIW it's fairly hard to for a database to index arbitrary content for
regexes, to the point where it's going to be hard to do MUCH better than
simply filtering based on regex. Out of curiosity, would the "free text
search" feature on that wiki page that Arthur provided meet your needs?
it's more a
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18320
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
The access request policy says to address security concerns.
This raises a few questions.
One is what are the security concerns.
Two is what of the previous DOM related security models does not address
them.
Three is unless all scripts are authored and packaged as widgets in
accordance to/with
> > - URLObject represents a resource that can be fetched, FileReader'd,
> createObjectURL'd, and cloned, but without any knowledge of the contents
> (no size attribute, no type attribute) and no slice() as URLObjects may
> not be seekable.
> > - Blob extends URLObject, adding size, type, slice(),
On Tue, Aug 7, 2012 at 6:53 PM, Jungkee Song wrote:
> > > - URLObject represents a resource that can be fetched, FileReader'd,
> > createObjectURL'd, and cloned, but without any knowledge of the contents
> > (no size attribute, no type attribute) and no slice() as URLObjects may
> > not be seekabl
On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams wrote:
> I would suggest using a different name than "URLObject". I think that name
> will cause a lot of head scratching.
>
No disagreement there; that was just a placeholder. I'd suggest waiting
for further input from Anne, Jonas and Arun (the edito
On Tue, Aug 7, 2012 at 7:38 PM, Glenn Maynard wrote:
> On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams wrote:
>
>> I would suggest using a different name than "URLObject". I think that
>> name will cause a lot of head scratching.
>>
>
> No disagreement there; that was just a placeholder. I'd sugges
On Sun, Aug 5, 2012 at 7:00 AM, Henri Sivonen wrote:
> On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth wrote:
> > On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein wrote:
> >>
> >> On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth wrote:
> >>>
> >>> Inspired by a conversation with hsivonen in #whatwg, I spe
Hi Cameron,
While reading about "dictionary" from your "Web IDL (Second Edition)" draft,
I found a part that needs clarification:
->8-
3.3 Dictionaries
If the Type is an identifier or an identifier followed by ?, then the
identifier must identify an interface, *dictionary*, enumeration, c
14 matches
Mail list logo
