[whatwg] "Content-Disposition" property for <a> tags

[Bjartur Thorlacius]

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius <svartman95 at gmail.com> w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Content-Disposation header of RFC 2076 (MIME).
> 
> Not all resources have a place to put such metadata, and different
> resource types will require the metadata to be in different formats,
> and it shouldn't stick around if the user downloads and then uploads
> it someplace else, so I don't think this is suitable.
> 
IMO there should be a standard metadata wrapper that should be around
virtually all files being passed around the Internet. Downloaders should
register the metadata to xattrs or somesuch and uploaders should collect
said metadata and rewrap it. Technically application/http could be used.

> > B) By media type:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0A UA may decide that a resources of certain me=
> dia subtype
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be immediately processed or presented t=
> o the user. Think
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0application/octet-stream, executables and like=
> ly all subtypes
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0not present in mailcap (or equivalent).
> 
> This doesn't address the use-case at all.  Images can be immediately
> processed and presented to the user.
> 
True. Sorry for unnecessary noise.

> > C) Context:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Due to the context of the link, such as per li=
> nk metadata.
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0The straightforward solution is registering a =
> JavaScript callback
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0to the click event on the relevant <A> element=
> . This though is
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0highly problematic as the "click" event isn't =
> always fired when a
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0link is activated (thus possibly resulting in =
> normal navigation to
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination), UAs currently don't restyle =
> <A>s with listeners
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0on click (nor any elements with attached liste=
> ners). A (or AREA)
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0with @action, @method or @rel~=3Dsave would al=
> low easy styling
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0with CSS and ignoring.
> 
> One proposal was a new "download" attribute.  Or a parameter to data:
> URLs.  These seem practical, as does a new rel value.  A parameter to
> data: URLs would be a bit weird -- what if it were present in an <img
> src>, or if the user typed such a URL directly into the location bar?
> 
OK, lets rule out the data: parameter.

> > If the browsers UI doesn't have a "Print" button where the user expects
> > one to be the UI is broken, not the document to be printed.
> 
> An amazing number of users expect a "print" button inside the webpage
> itself.  Whatever your opinion of this is, it's a fact.  Many authors
> want to add print buttons inside the page to satisfy user demand, and
> it doesn't harm anything beyond what the page can already do (since
> the user can always dismiss the dialog), so it's a useful feature.
> 
So the browser should provide a "print" button where the user expects it.
Providing UI for common things like printing is entirely out of scope for
authors. A browser that can check whether there's an available printing
device would be more suited for the task.

> > True. That's why web pages should provide lots of semantic metadata to
> > applications that may use that data to make informed decisions.
> 
> Yes, like <a rel=3D"download"> or such, as is being proposed.
> 
> > I propose
> > the "method" attribute on <link>, <a> and <area> that MUST contain
> > a case insensitive space-seperated list of methods. A list of valid
> > methods should be obtainable from the WHATWG wiki. Note in particular
> > that methods are not limited to HTTP methods and neet not alter the
> > retrieval or submission of resources, though they most certainly can.
> > Valid methods might include:
> > GET (retrieve resource without presenting it to the user), PUT (alter
> > or create, akin to comp(ose) in run-mailcap), HEAD (retrieve metadata
> > about resource), navigate (present the resource to the user).
> 
> If I understand correctly, I don't think this is likely to be
> implemented or used enough to justify specifying it.  It doesn't have
> clear enough use-cases.
Somewhat agreed.

Note though that e.g. GMail could use <link href=mailto: method=POST
title="Compose mail">, wikis could mark "red" links with @method=PUT
(there have been previous request on this list for a standard method to
do this, so there's a real demand), the confusion of whether to post or
retrieve mail from a linked email address could be cleared up (although it
isn't a serious problem) and it would allow for a simpler way to request
the upload of a single file (which is somewhat awkward to do with <form>s).

In fact I think the wiki use case is bigger than the @download use case.