Re: ACTION-570: Update packaging-configuration.rnc to reflect the iew-modes in the CR (Web Applications Working Group)
On 8/16/10 8:30 PM, Web Applications Working Group Issue Tracker wrote: ACTION-570: Update packaging-configuration.rnc to reflect the iew-modes in the CR (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/570 On: Marcos Caceres Due: 2010-08-23 Fixed and uploaded. -- Marcos Caceres Opera Software
[widgets] widget tests for view mode media feature
Hi, Opera has completed the first draft of the widget-based tests for the view-mode media feature. These tests are designed to be run in the context of a widget user agent (we might need a completely different test suite for browsers in general, for which we might need to coordinate with the CSS WG). For the purposes of testing, the tests assume the default mode that widgets will be run in is floating. I don't know if this is a problem or not... so please let us know ASAP if we need to change the tests. The overview of the test suite is available from the link below (note that the Overview document is just a copy/paste from another test suite, so contains errors... just scroll to the bottom of the page and click on Product ua to access the tests): http://dev.w3.org/2006/waf/widgets-vmmf/test-suite/ Comments welcomed... Kind regards, Marcos -- Marcos Caceres Opera Software
Re: Lifetime of Blob URL
I do not see any more discussions on blob URL API in recent days. Any more thoughts or conclusion? In addition, do we want to rename FileError and File Exception to BlobError and BlobException to match with BlobReader naming, or rather keep them intact? On Mon, Aug 2, 2010 at 3:22 PM, Dmitry Titov dim...@chromium.org wrote: It feels developers will make less errors with window.getBlobUrl(blob) kind of API, because, unlike blob.url, it doesn't violate pretty common programming assumptions (like querying a property of the same object should return the same value if nothing was done to the object, or that value of property should not depend on what is a global object in the context of the query if the blob is the same). The spec language describing why and when blob.url returns different values with different lifetimes would be a bit hairy... Agree though that functionally they are the same. On Mon, Aug 2, 2010 at 3:05 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman micha...@google.com wrote: On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman micha...@google.com wrote: On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking jo...@sicking.cc wrote: Sorry about the slow response. I'm currently at blackhat, so my internet connectivity is somewhat... unreliable, so generally having to try to stay off the webs :) On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov dim...@chromium.org wrote: Thanks Jonas, Just to clarify some details we had while discussing this, could you confirm if this matches with your thinking (or not): 1. If blob was created in window1, blob.url was queried, then passed (as JS object) to window2, and window1 was closed - then the url gets invalidated when window1 is closed, but immediately re-validated if window2 queries blob.url. The url string is going to be the same, only there will be a time interval between closing window1 and querying blob.url in window2, during which loading from the url returns 404. Actually, it might make sense to make blob.url, when queried by window2, return a different string. This makes things somewhat more consistent as to when a URL is working an when not. Now suppose window2 queries the .url attribute before window1 is closed? I think most people would expect the same value as returned in window1 (yes?). Having the same or different value depending on whether the attribute was queried before or after another window was closed seems confusing. I think having the .url remain consistent from frame to frame/window to window could help with debugging. The idea would be that we *always* return different urls depending on which window queries a url. This gives the most consistent behavior in that every url given is always limited to the lifetime of the current window. No matter what windows around it does. If that's the idea, then I would vote for a non-instance method somewhere to provide the context specific URL. Having a simple attribute accessor return different values depending on which context its being accessed in is very unusual behavior. Can't say that its ideal, but window.getBlobUrl(blob) and window.revokeBlobUrl(...) would be an improvement. I can't say that I'm a big fan of this syntax given that I think the current syntax works fine in most cases. I'm definitely curious to hear what others think though. / Jonas
Re: [Web Storage] A couple questions about the storage spec
On 2010/8/17, at 上午4:39, Jeremy Orlow wrote:
On Tue, Aug 17, 2010 at 12:08 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 8 Jul 2010, David John Burrowes wrote:
I have a couple questions about the storage spec (I'm reading the June
15th version at (http://dev.w3.org/html5/webstorage/).
(1) The spec says: The object's indices of the supported indexed
properties are the numbers in the range zero to one less than the number
of key/value pairs currently present in the list associated with the
object. If the list is empty, then there are no supported indexed
properties.
As far as I can tell, this seems to say I should be able to say
something like:
window.localStorage[3]
and get something back (not clear if the key or the value). Am I right
in my interpretation of that paragraph?
Yes.
I saw some discussion earlier about whether something like
localStorage[3] was meaningful, but I didn't find the resolution. It
does seem undesirable/confusing to me. And none of the browsers I've
tried this with do this.
On Wed, 14 Jul 2010, Jeremy Orlow wrote:
All the browsers I know of handle localStorage[3] as
localStorage.get/setItem('3', ...). My impression is that this behavior
is pretty firmly rooted at this point. It seems as though the spec may
need to change.
Firefox seems to implement this correctly. It just seems to be a bug in
Opera and Chrome. (I didn't test Safari or IE.)
I'm surprised I overlooked Firefox.
I think in the grand scheme of things here, this is a minor point. But, in
Firefox saying localStorage[2] = foo creates a key (2) with a value (foo).
Shouldn't that be changing the name of the 2nd key? Otherwise this notation is
a bit asymmetrical (does one thing when read from, a very different thing when
assigned to).
Safari and IE act the same way as Opera and Chrome, so I would agree with
David's assertion that this behavior is fairly firmly rooted. But you
disagree, Ian? If so, let me just make sure I understand correctly: if you
do localStorage[x] and x is a number, then it should be an index into item
number x, and if x is anything else, it should be interpreted as
.get(x)/.set(x, ...) ?
I algo agree that it would be nice for the correct behavior for this ambiguous
situation to be explicitly stated in the spec.
This is the kind of thing that will shake out when we have a test suite.
I'm sure that is true!
On Thu, 8 Jul 2010, David John Burrowes wrote:
(2) The spec also says:
The names of the supported named properties on a Storage object are the
keys of each key/value pair currently present in the list associated
with the object.
I read that (possibly/probably wrongly) as saying I should be able to say
window.localStorage.setItem(foo, bar);
myVariable = window.localStorage[foo];
and now myVariable will have bar.
Yes.
If my reading is right (and it is the behavior I see in a couple browsers)
this makes me very nervous, because I can do something like:
window.localStorage.setItem(length, a value we computer);
window.localStorage.setItem(clear, something that is transparent);
which of course allows:
window.localStorage[length];
window.localStorage[clear];
but in the browsers I've looked at, this (of course) also kinda messes up
things like:
for (index = 0; index window.localStorage.length; index++) {
// whatever
}
window.localStorage.clear();
since length is now not a number, and clear isn't a function.
Actually length and clear don't get overrideen, because the interface is
not defined as [OverrideBuiltins].
So, that means window.localStorage[length] will still return a value we
computer[sic] ?
Wha? This seems completely different than your answer in this thread:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020349.html
Why is this a desirable feature?
Code like this:
if (localStorage.visitedAlready) { ... }
...is simpler to read than code like:
if (localStorage.getItem('visitedAlready')) { ... }
I can definitely see that that is easier to read. It also strikes me as
fragile to write this as localStorage.visitedAlready. If a later version of
the standard adds a 'visitedAlready' function or attribute to the localStorage
object, my code may not behave as it did in the previous version (which scares
the out of me as a developer :-) ). But, this looks like it depends on
the previous part of my question about whether length and clear get overridden.
(3) Real nitpicking here:
The IDL for the Storage interface says
setter creator void setItem(in DOMString key, in any data);
but the text says
The setItem(key, value) method
Note the name of the second parameter is different between these.
Fixed IDL.
Thanks! My type-A-ness is made happy ;-)
David
--
Ian Hickson U+1047E
Possible addition to file API
At present, the only way a web page can read a file's binary data via the File API (http://dev.w3.org/2006/webapi/FileAPI) is if the person reading the page enters the file name in an input type=file/. The API applies to only local files, if I read it correctly. Is it possible to extend the spec to allow a script to read any file that can been loaded as part of the HTML page, such as an img/? This extension would let web pages read the EXIF data of an image that is part of an img element; a very useful capability for web apps. Similarly, you could access metadata from a file destined for an audio or video element. The spec seems to suggest that this is possible: http://dev.w3.org/2006/webapi/FileAPI/#url , but is it implemented in any browsers? I understand there are good security reasons for restricting file reads; you don't want someone else's web page to be able to go willy-nilly through your local hard disk and send all the information back to the Bad Guys. But this scenario is different; if you have loaded an img/, you must already have read permission for it, and its data is there in the browser. I'm just asking to be able to access its bits. Precedent: think of link rel=stylesheet href=blah.css/; you have access to all the elements in that file via the DOM, and there's no security issue involved, even if it's a cross-domain href. That's because it is *not* an arbitrary file on the user's local file system; it's one that the author has explicitly specified and is allowed to read. I think my suggestion here meets the same criteria. Am I missing something obvious on the security front? The back story for this idea (you may safely skip this portion if you are not interested): My brother and I have just spent the past few days looking over several large boxes of photos that my mom had stored away. Most of them had nothing written on the back, so we had no idea of where or when the pictures were taken, nor who the people in them were, nor what the picture meant to Mom. Obviously, metadata matters. This told me that I need to start using the comments feature in GIMP to add descriptions to my photos. A few days ago, some of our family got together and I told my cousin George that I'm going to start doing this. He said that was nice, but the only way to get the data out is to use a program similar to the one that you used when editing the image, and most people won't have that. So I thought, You know, it would be great if you could get access to an img/'s EXIF data from the browser.
