(These e-mails were sent after I started working on the previous one.)
On Wed, 20 Jul 2011, Chris Bentzel wrote:
Who should be trusted for filename if the one specified by a on the
referring page differs from the one specified by Content-Disposition on
the to-be-downloaded resource?
I've
On Fri, 22 Jul 2011, Hironori Bono (坊野 博典) wrote:
This is just out of curiosity. Would it be possible to give me the
encoding used for this download attribute? I think we have several
options when we use non-ASCII characters (this example uses Cyrillic
characters) as the value of this
On 2011-07-22 09:00, Ian Hickson wrote:
(These e-mails were sent after I started working on the previous one.)
On Wed, 20 Jul 2011, Chris Bentzel wrote:
Who should be trusted for filename if the one specified bya on the
referring page differs from the one specified by Content-Disposition on
On 2011-07-22 05:03, Hironori Bono (坊野 博典) wrote:
Greetings all,
This is just out of curiosity.
Would it be possible to give me the encoding used for this download
attribute? I think we have several options when we use non-ASCII
characters (this example uses Cyrillic characters) as the
On Fri, 22 Jul 2011, Julian Reschke wrote:
That isn't really in scope for the HTML spec, it's something either
for the HTTP spec or the Content-Disposition spec (if HTTP doesn't
define th header itself) to define.
Is there a specific reason why the new text doesn't mention
On 2011-07-22 09:24, Ian Hickson wrote:
On Fri, 22 Jul 2011, Julian Reschke wrote:
That isn't really in scope for the HTML spec, it's something either
for the HTTP spec or the Content-Disposition spec (if HTTP doesn't
define th header itself) to define.
Is there a specific reason why the new
On Fri, 22 Jul 2011 12:37:10 +0200, Julian Reschke julian.resc...@gmx.de
wrote:
I was looking at the diff r6318. Maybe there were more changes?
Searching for content-disposition in http://html5.org/r/6318 gives plenty
of results.
--
Anne van Kesteren
http://annevankesteren.nl/
Greetings all,
This is just out of curiosity.
Would it be possible to give me the encoding used for this download
attribute? I think we have several options when we use non-ASCII
characters (this example uses Cyrillic characters) as the value of
this attribute as listed below.
1. Use the same
Who should be trusted for filename if the one specified by a on the
referring page differs from the one specified by Content-Disposition
on the to-be-downloaded resource?
On Tue, Jul 19, 2011 at 1:42 PM, Alexey Proskuryakov a...@webkit.org wrote:
18.07.2011, в 9:35, Glenn Maynard написал(а):
On 2011-07-20 13:33, Chris Bentzel wrote:
Who should be trusted for filename if the one specified bya on the
referring page differs from the one specified by Content-Disposition
on the to-be-downloaded resource?
...
I think the header field needs to be authoritative.
That being said, if you
18.07.2011, в 9:35, Glenn Maynard написал(а):
A different scenario which I don't think has been discussed in this thread
is bypassing a hosting service security settings. Consider a highly
reputable hosting that doesn't let you upload executable files (or maybe
just scans those for
17.07.2011, в 21:05, Adam Barth написал(а):
In summary, using CORS for this purpose is costly (both to
implementors and to authors), and I don't think it solves a real
security problem.
Agreed. This feature basically gives authors two abilities: (1) force
downloading of resources that
On Mon, Jul 18, 2011 at 8:58 AM, Alexey Proskuryakov a...@webkit.org wrote:
17.07.2011, в 21:05, Adam Barth написал(а):
In summary, using CORS for this purpose is costly (both to
implementors and to authors), and I don't think it solves a real
security problem.
Agreed. This feature
On Mon, Jul 18, 2011 at 11:58 AM, Alexey Proskuryakov a...@webkit.org wrote:
A different scenario which I don't think has been discussed in this thread
is bypassing a hosting service security settings. Consider a highly
reputable hosting that doesn't let you upload executable files (or maybe
just
Þann fös 15.júl 2011 18:39, skrifaði Jonas Sicking:
2011/7/14 Ian Fette (イアンフェッティ)ife...@google.com:
One concern which was brought up was the ability to cause the user to
download a file from a third party site. I.e. this would allow
evil.com to trick the user into downloading an email from the
Þann fös 15.júl 2011 21:34, skrifaði Darin Fisher:
2) Unlike rel=something, @download provides a way to specify the name
of the file to save. This makes the feature useful with data: URLs and
blob:
URLs (that are not backed by a single file). This is valuable to me because
I can imagine
2011/7/15 Jonas Sicking jo...@sicking.cc:
We've discussed a different solution to the same problem at mozilla.
The solution we discussed was allowing FileSaver to in addition to
taking a blob argument, allow it to take a url argument.
One concern which was brought up was the ability to cause
On Sun, Jul 17, 2011 at 12:41 PM, Bjartur Thorlacius
svartma...@gmail.com wrote:
Þann fös 15.júl 2011 18:39, skrifaði Jonas Sicking:
2011/7/14 Ian Fette (イアンフェッティ)ife...@google.com:
One concern which was brought up was the ability to cause the user to
download a file from a third party site.
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com
I really don't see the importance of the name the thing that isn't going
to be downloaded usecase; there are countless edge cases that we could
concern ourselves with in HTML but that few users will ever hit, this is
one.
A common case is
On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth w...@adambarth.com wrote:
2011/7/15 Jonas Sicking jo...@sicking.cc:
We've discussed a different solution to the same problem at mozilla.
The solution we discussed was allowing FileSaver to in addition to
taking a blob argument, allow it to take a url
On Sun, Jul 17, 2011 at 8:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth w...@adambarth.com wrote:
2011/7/15 Jonas Sicking jo...@sicking.cc:
We've discussed a different solution to the same problem at mozilla.
The solution we discussed was allowing
On 16 July 2011 02:20, Peter Kasting pkast...@google.com wrote:
On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
* existing rel=enclosure spec - download the link when clicked/activated.
I object to rel=enclosure purely on naming grounds. It is completely
rel=anything makes me sad as it will mean more UA sniffing. The fallback
behavior of loading the href inline could be dangerous.
On Jul 15, 2011 5:38 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
14.07.2011, в 13:59, Tab Atkins Jr. написал(а):
re-using the enclosure term from the Atom format (thus minimal
bikeshedding)
enclosure is a completely opaque name. I have no idea how it is
meant to refer to download the linked resource instead of navigating
to it. If I think about it
On Fri, Jul 15, 2011 at 9:08 AM, Alexey Proskuryakov a...@webkit.org wrote:
14.07.2011, в 13:59, Tab Atkins Jr. написал(а):
re-using the enclosure term from the Atom format (thus minimal
bikeshedding)
enclosure is a completely opaque name. I have no idea how it is
meant to refer to
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com
Yes and no - both are sort of a poor man's Content-Disposition :) The
question is whether we need to handle filename, and the proposal of
download=filename at least maps content-disposition fully and compactly.
Not fully; it lacks an
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com:
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is to set a
content-disposition header.
On Fri, Jul 15, 2011 at 11:24 AM, Glenn Maynard gl...@zewt.org wrote:
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com
Yes and no - both are sort of a poor man's Content-Disposition :) The
question is whether we need to handle filename, and the proposal of
download=filename at least maps
2011/7/15 Jonas Sicking jo...@sicking.cc
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com:
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com:
2011/7/15 Jonas Sicking jo...@sicking.cc
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com:
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
On 2011-07-15 19:05, Ian Fette (イアンフェッティ) wrote:
..
It also doesn't naturally help understanding that it's just poor man's
Content-Disposition:attachment. From this point of view, I like Ian's
original proposal (rel=attachment) more.
Yes and no - both are sort of a poor man's
On Fri, Jul 15, 2011 at 1:15 PM, Julian Reschke julian.resc...@gmx.dewrote:
On 2011-07-15 19:05, Ian Fette (イアンフェッティ) wrote:
..
It also doesn't naturally help understanding that it's just poor man's
Content-Disposition:**attachment. From this point of view, I like Ian's
original proposal
On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote:
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com:
2011/7/15 Jonas Sicking jo...@sicking.cc
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com:
Many websites wish to offer a file for download, even though it could
2011/7/15 Darin Fisher da...@chromium.org:
On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote:
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com:
2011/7/15 Jonas Sicking jo...@sicking.cc
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com:
Many websites wish to offer a
2011/7/15 Jonas Sicking jo...@sicking.cc
It definitely is an interesting usecase that Glenn brought up about
being able to specify a save-as name without otherwise modifying the
behavior of a reference. However that seems like a much more rare
usecase and so not the one we should optimize
] a rel=attachment
2011/7/15 Jonas Sicking jo...@sicking.cc
It definitely is an interesting usecase that Glenn brought up about
being able to specify a save-as name without otherwise modifying the
behavior of a reference. However that seems like a much more rare
usecase and so not the one we
On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
* existing rel=enclosure spec - download the link when clicked/activated.
I object to rel=enclosure purely on naming grounds. It is completely
unintuitive. I don't find the fact that a spec exists for it a compelling
...@google.com
Subject: Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
* existing rel=enclosure spec - download the link when clicked/activated.
I object to rel=enclosure purely on naming grounds. It is completely
unintuitive. I don't
On Fri, Jul 15, 2011 at 6:25 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
** Specs *and* publishers/consumers/implementations of rel-enclosure exist
(see aforementioned wiki page).
The list on the wiki page, which I assume is non-exhaustive, is
extraordinarily uncompelling.
And the name
Enclosure is precisely this use case.
You can go back and grep
http://www.imc.org/atom-syntax/entire-arch.txt for enclosure for the
discussion if you like. After much debate, rel=enclosure was used to
replace RSS's enclosure element, preserving the name.
This will lead you back via the RSS specs
On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/15 Jonas Sicking jo...@sicking.cc
It definitely is an interesting usecase that Glenn brought up about
being able to specify a save-as name without otherwise modifying the
behavior of a reference. However that seems
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is to set a
content-disposition header. *However, sometimes it is not possible for the
page author to
On Thu, Jul 14, 2011 at 12:03 PM, Karl Dubost ka...@opera.com wrote:
Le 14 juil. 2011 à 14:45, Ian Fette (イアンフェッティ) a écrit :
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example).
Which
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is to set a
content-disposition header.
Le 14 juil. 2011 à 14:45, Ian Fette (イアンフェッティ) a écrit :
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example).
Which current websites?
it seems like adding a rel attribute to the a
tag would
2011/7/14 Andy Mabbett a...@pigsonthewing.org.uk
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com:
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve
On 7/14/11, Ian Fette (イアンフェッティ) ife...@google.com wrote:
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is to set a
content-disposition header.
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the only way to achieve this is to set a
content-disposition header.
The download=filename seems like a nice proposal (assuming that the filename
is optional, and if not specified it just takes whatever the name would
otherwise be). It also neatly solves the filename issue without cluttering
the a tag with tons of options.
On Thu, Jul 14, 2011 at 12:36 PM, Glenn
On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the
2011/7/14 Darin Fisher da...@chromium.org:
On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word
On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
2011/7/14 Darin Fisher da...@chromium.org:
On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com
Many websites wish to offer a file for download,
On Thu, Jul 14, 2011 at 13:46, Darin Fisher da...@chromium.org wrote:
On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.edu
wrote:
2011/7/14 Darin Fisher da...@chromium.org:
On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Ian Fette
2011/7/14 Darin Fisher da...@chromium.org
I know that there is also a proposal to add a FileSaver API. I like that
as well, _but_ it is very nice to be able to simply decorate an anchor tag.
In many cases, that will be a lot simpler for developers than using
JavaScript to construct a
On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Darin Fisher da...@chromium.org
I know that there is also a proposal to add a FileSaver API. I like that
as well, _but_ it is very nice to be able to simply decorate an anchor tag.
In many cases, that will be a
On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
Indeed, and has been pointed out, already specified (since 2005) and
implemented as well for HTML:
http://microformats.org/wiki/rel-enclosure
re-using the enclosure term from the Atom format (thus minimal
Le 14 juil. 2011 à 14:45, Ian Fette (イアンフェッティ) a écrit :
a rel=attachment href=blah.pdf would indicate that the browser
should treat this link as if the response came with a content-disposition:
attachment header, and offer to download/save the file for the user.
A random thought just occured
On Thu, Jul 14, 2011 at 1:52 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
Also the empty download attribute doesn't work as it is supposed to be
equivalent to download=download which would simply name the file
download which is unlikely what author or user want.
This is incorrect. If you
On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard gl...@zewt.org wrote:
That reminds me of something download=filename can't do: assign a filename
while leaving it inline, so save as and other operations can have a
specified filename. That would require two separate properties. One case
I've
On 7/14/11, Karl Dubost ka...@opera.com wrote:
what about adding
a href=foo.pdf target=_downloadSave a Tree, Eat a beaver/a
This seems like the best solution to me. A filename hint has two use
cases: a suggestion for a local identifier, and providing a filename
extension for systems that use
On Thu, Jul 14, 2011 at 5:44 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Optimizing for the user choosing to right-click=Save seems like a
much more niche case than linking to a file that should be downloaded.
Plus, you could address it by just wrapping the img in an a:
a
61 matches
Mail list logo
