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

[Aryeh Gregor]

On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius <svartman95 at gmail.com> wrote:
> A) Per resource metadata:
>        Some resource is inherently insuitable for immediate
>        presentation. Metadata regarding this can be provided by e.g. the
>        Content-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.

> B) By media type:
>        A UA may decide that a resources of certain media subtype
>        cannot be immediately processed or presented to the user. Think
>        application/octet-stream, executables and likely all subtypes
>        not present in mailcap (or equivalent).

This doesn't address the use-case at all.  Images can be immediately
processed and presented to the user.

> C) Context:
>        Due to the context of the link, such as per link metadata.
>        The straightforward solution is registering a JavaScript callback
>        to the click event on the relevant <A> element. This though is
>        highly problematic as the "click" event isn't always fired when a
>        link is activated (thus possibly resulting in normal navigation to
>        the destination), UAs currently don't restyle <A>s with listeners
>        on click (nor any elements with attached listeners). A (or AREA)
>        with @action, @method or @rel~=save would allow easy styling
>        with 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?

> 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.

> 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="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.