- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 27 Jul 2011 23:38:47 +0000 (UTC)
On Fri, 29 Apr 2011, Bjartur Thorlacius wrote: > On 4/28/11, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 28 Apr 2011, Bjartur Thorlacius wrote: > >> All current UAs would understand the link (and most probably present it > >> to the user). Inline presentation is an optional luxury: the important > >> thing is getting the media across. I, for one, can't find any sign of > >> <source> support in wget, and a few other "non-mainstream" UAs. > > > > Well for <video> fallback people are likely to use <a> as well, but I > > don't think it makes sense to force every <source> to be a link. > > Writing both <source> and <a> for every source seems like unnecessary > duplication to me. The primary difference between the two is that the > resource referenced by the former is to be displayed inline, but the > resource referenced by the latter is to be accessible interactively. > <a style="content: url(attr(href));" href="/usr/videos/lolcatz">Funny > cats jumping around</a>. > Ok, this isn't valid CSS, but you get my thinking (I hope). While I can see where you're coming from, I don't think overloading one element for all hyperlink and resource link features makes sense. Different links have different needs. The incremental cost of adding new ways to get resources in wget(1) is much lower than the cost of overloading all the various linking mechanisms into one element, IMHO. It is, in any case, too late for <video>. However, I will keep in mind what you have said for future features. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 27 July 2011 16:38:47 UTC