- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Wed, 28 May 2008 23:33:12 -0400
- To: "Robert J Burns" <rob@robburns.com>
- Cc: "HTML Issue Tracking WG" <public-html@w3.org>
On 5/28/08, Robert J Burns <rob@robburns.com> wrote: > > Dear WG, > > Here is another issue that needs to be introduced here for discussion, as > it will be added to the issue-tracker in time. It has been discussed on the > list in relation to content type issues and http headers. It has not been > addressed in the draft. > > New attributes for handling and downloading linked and embedded > resources.[1] > > [1]: > <http://esw.w3.org/topic/HTML/LinkAndEmbeddingAttributes> I like the general idea of this at least. For @download, 'default' and 'download-dialog' seem fine. For example, a site might serve file.cpp as text/plain, but I want to provide a left-click download link and would use <a href="http://somesite.com/file.cpp" download="download-dialog"> But, 'download' does not. 'download' is dangerous in my opinion. For an example of why, see <http://reddit.com/info/6jheq/comments/> (think windows users). For @processas, that could be convenient. For example, if some site serves file.pls as text/plain, I might use <a href="http://somesite.com/file.pls" processas="_audio/x-scpls"> so that it opens in foobar instead of being displayed as a text file. As another example, there might be a text/html page that you want to load as text/plain. <a href="http://somesite.com/file.html" processass="_text/plain"> Browsers sometimes have problems with figuring out the type and filename (especially through redirections). Sometimes it's a bug in the browser or a difference between browsers or a misconfigured server. I often use wget or curl instead to "just download the damn thing !". These feature could help an author solve some of this. I guess most would want these problems solved outside HTML though.
Received on Thursday, 29 May 2008 03:33:50 UTC