On 7/30/10 10:59 PM, Roger Hågensen wrote:
On 2010-07-31 04:52, Boris Zbarsky wrote:
When I say the "Save As" UI I mean the one you get currently, which
varies, some browsers only provide a Save As and Cancel, while others
provide Save As with Open and Cancel.
I can't name a single browser t
On 2010-07-31 04:52, Boris Zbarsky wrote:
When I say the "Save As" UI I mean the one you get currently, which
varies, some browsers only provide a Save As and Cancel, while others
provide Save As with Open and Cancel.
I can't name a single browser that provides an "Open" option if you
select
On 7/30/10 10:27 PM, Roger Hågensen wrote:
On 7/30/10 9:57 PM, Roger Hågensen wrote:
This defaults to application/octet-stream
and clicking the link will behave as if the user selected Save As from
UI context menu!
When I say the "Save As" UI I mean the one you get currently, which
varie
On 2010-07-30 20:54, Eduard Pascual wrote:
Let me complement the proposal with a use case:
http://stackoverflow.com/questions/3358209/triggering-a-file-download-without-any-server-request
Now something like that is a bit more tricky, but can't Javascript
actually trigger a proper Save As?
On 2010-07-31 04:17, Boris Zbarsky wrote:
On 7/30/10 9:57 PM, Roger Hågensen wrote:
This defaults to application/octet-stream
and clicking the link will behave as if the user selected Save As from
UI context menu!
I would object to implementing this. I have no problem putting up a
dialog ask
On 2010-07-31 03:57, Roger Hågensen wrote:
Another example:
How many here have had that wishful thinking work exactly like you wanted?
That is the minimal use case, old browsers would behave as currently,
those supporting this on the other hand would always present an expected
Save As.
I'm su
On 7/30/10 9:57 PM, Roger Hågensen wrote:
This defaults to application/octet-stream
and clicking the link will behave as if the user selected Save As from
UI context menu!
I would object to implementing this. I have no problem putting up a
dialog asking the user whether to save or open in a h
On 2010-07-30 20:54, Eduard Pascual wrote:
On Fri, Jul 30, 2010 at 12:36 PM, Dennis Joachimsthaler wrote:
Having a Content-Disposition property on tags which does the same as
the HTTP Header.
For example changing the file name of the file to be downloaded or rather
have a image
file downlo
On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas wrote:
> And I totally agree, this is not a strong security feature, and that’s not
> the intent. The intent is just to give an extra measure of control of the
> lifetime of the data to bring Web Storage closer to being a replacement for
> a wider r
On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
> On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking wrote:
>> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson wrote:
>>>
>>> The e-mails quoted below consist of the salient points of this thread:
>>>
>>> On Fri, 23 Apr 2010, David Bruant wrote:
On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking wrote:
> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson wrote:
>>
>> The e-mails quoted below consist of the salient points of this thread:
>>
>> On Fri, 23 Apr 2010, David Bruant wrote:
>>>
>>> Make that HTMLCollection (and all HTML*Collection, as a c
On Fri, Jul 30, 2010 at 12:36 PM, Dennis Joachimsthaler wrote:
> Hello,
>
> I have an idea which would be very cool for HTML5.
>
> Having a Content-Disposition property on tags which does the same as
> the HTTP Header.
> For example changing the file name of the file to be downloaded or rather
>
I'm also not keen on UA sniffing for the determination of features, which is
why I mentioned using localStorage.setItem.length to determine if the TTL
parameter is valid for the browser.
IMO, it's fine not to delete the data while the page is loaded, but I would
like to ensure that the data isn
On Fri, Jul 30, 2010 at 7:09 PM, Alexandre Morgaut wrote:
>
> Storage::setExpiration(in DOMString key, in TTL or expiration Date)
>>
>> (or Storage::setTTL() if you guys don't agree on the Date option)
>>
>
> This might make sense, but I'm also not sure it's worth the additional API
> surface are
To answer a few of the questions brought up in this thread all in one bang:
1) TTL vs. Date - I originally was going to propose a date, but the more
I dug in and around uses cases for cookies, the more frequently I found people
setting dates based on a TTL (i.e., I want this to expire in o
> Storage::setExpiration(in DOMString key, in TTL or expiration Date)
>
> (or Storage::setTTL() if you guys don't agree on the Date option)
>
> This might make sense, but I'm also not sure it's worth the additional API
> surface area. Plus I kind of like the idea of making it difficult for peo
On 7/29/10, Garrett Smith wrote:
> On 7/29/10, Ian Hickson wrote:
>>
>> The e-mails quoted below consist of the salient points of this thread:
>>
>> On Fri, 23 Apr 2010, David Bruant wrote:
>>>
>
[...]
> The difficulty is getting the special behavior for [[Get]] which would
> seem to require some
On Fri, Jul 30, 2010 at 12:20 PM, Jonas Sicking wrote:
> It might be worth integrating this into IndexedDB as it seems like
> people are more reluctant to add additional features to localStorage
> for various reasons.
>
I have expressed this opinion quite vocally in the past, but given that
expi
On 7/30/10 4:33 AM, zhao Matt wrote:
Obviously, the book thinks Client-side JavaScript is (or behaves as if
it is) *single-threaded*.
However,
HTML5 spec states 'the user agent must immediately execute the script
block, even if other scripts are *already* executing.',
Does it imply that scripts c
On Fri, Jul 30, 2010 at 12:43 AM, Oliver Hunt wrote:
> The various html collections aren't fixed length, they're not assignable, so
> they can't used interchangeably with arrays at the best of times.
Array generics work on arrays that aren't fixed-length, perhaps
obviously, and I believe they're
It might be worth integrating this into IndexedDB as it seems like
people are more reluctant to add additional features to localStorage
for various reasons.
One key question is if expiration needs to happen on a per-value
basis. Or if per-storage-area (per objectStore) is enough?
/ Jonas
On Thu,
On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson wrote:
>
> The e-mails quoted below consist of the salient points of this thread:
>
> On Fri, 23 Apr 2010, David Bruant wrote:
>>
>> Make that HTMLCollection (and all HTML*Collection, as a consequence of
>> inheritence of HTMLCollection) inherit from th
Hello,
I have an idea which would be very cool for HTML5.
Having a Content-Disposition property on tags which does the same as
the HTTP Header.
For example changing the file name of the file to be downloaded or rather
have a image
file download rather than it being shown in the browser directly
Ian Hickson:
> On Fri, 30 Apr 2010, Nikita Popov wrote:
>> Beyond that, using instead of would even be more backwards
>> compatible to the HTML 4 use of headings.
>
> Actually, it would be less compatible, since it wouldn't render like a
> heading in older browsers.
XHTML2’s ‘h’ is, especiall
Quote from: HTML spec -4.3 Scripting
"Otherwise:
The user agent must immediately execute the script block, even if other
scripts are already executing."
Quote from: "JavaScript - The Definitive Guide, 5th Edition"
"The core JavaScript language does not contain any threading mechanism, and
clie
On Jul 29, 2010, at 7:57 PM, Nicholas Zakas wrote:
> Proposed Interface Change:
>
> The easiest way to include such a change would be to augment the
> Storage::setItem() method with a third optional argument. So change from:
>
> setter creator void setItem(in DOMString key, in any data);
On Thu, Jul 29, 2010 at 8:57 PM, Nicholas Zakas wrote:
> setter creator void setItem(in DOMString key, in any data, [Optional] in
> unsigned long ttl);
> * If a TTL was previously set, and another call is made to setItem() that
> contains an invalid TTL (<= 0), then the original TTL remains.
27 matches
Mail list logo
