[whatwg] <INCLUDE> and links with @rel=embed

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'