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

[Bjartur Thorlacius]

On 8/5/10, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Wed, Aug 4, 2010 at 7:25 PM, Bjartur Thorlacius <svartman95 at gmail.com>
> wrote:
>>> On Tue, 18 May 2010, bjartur wrote:
>>> >
>>> > First of all I think we should use <a rel="embed" href="uri-ref">
>>> > instead of <source>.
>>>
>>> What problem would this solve?
>>>
>> It would tell UAs that don't implement HTML 5 that the value of @href is
>> an URI. Then it can provide means for the user to retrieve the identified
>> resource (and do something useful with it).
>
> If this is useful, browsers can do it today.  @src and @href are
> consistent in having their values be urls.
>
Yes. future browser are able to assume that @src and @href contain URIs.

>> For authors it would unnecessiate constructs such as (excerpt from spec):
>> <video controls src="http://video.example.com/vids/315981">
>>   <a href="http://video.example.com/vids/315981">View video</a>.
>> </video>
>
> I'll note, though, that that isn't a very useful pattern for users in
> the first place.  Most users won't have any idea what to do with a
> video file, especially if it doesn't come with an identifying
> extension.
>
I don't understand the comment about identifying extension. What's wrong with
IANA/MIME media types? Format metadata is often represented as a name/icon
combo anyway.

>
>> In fact, having the ability to follow this link is useful even though
>> my browser supports <video>. But that's an UI issue.
>
> Does your browser somehow not offer an "Open Video in New Tab" or
> similar option in the context menu?
>
Due to a lack of practical <video> support in my alpha quality browser, No.
>>> On Wed, 19 May 2010, Bjartur Thorlacius wrote:
>>> >
>>> >     Is the existing syntax backwards compatible? When using <A>, you
>>> > get a nice link as fallback content automagically, not requiring any
>>> > special workarounds by the content author. AFAICT you don't even get
>>> > that when using a browser that doesn't support <audio> and <video>.
>>>
>>> Indeed, with those you have to provide the fallback content (which could
>>> e.g. be flash) as a descendant of the <audio>/<video> element.
>>>
>> As a user of a browser that doesn't fully support <video> I'd prefer
>> getting a hyperlink to the resource to a Flash program. Just sayin'.
>
> I can assure you that you are a tiny, tiny minority.  Almost no one
> wants the video resource itself, because almost no one understands
> video playback, codecs, etc.  If they're lucky, the format is just
> right and they can just doubleclick it to play it in Windows Media
> Player.
>
And having the video prevents them from opening it in their media player how?
Video playback consist mostly of a mouse click and some watching.
Codecs are completely irrelevant.

> Doing a Flash or similar fallback that still plays the video is
> virtually always the best choice for the user.
>
"Virtually always" seems like an overstatement based on how often I
see people extract sound tracks from Youtube videos (and how I often I
see people don't in part due to them only having a dumb one-off
Flash-based video player). Or try to sequence playing of arbitrary
songs from Youtube with multiple browser windows + manual play/pausing
hackery. Or other things that would be trivial with their usual media
player.

>>> >     What I'm trying to write is that not all browsers support
>>> > JavaScript, not all pages must be able to control playback more than
>>> > play, pause, seek etc and that a mechanism for linking to files and
>>> > alternative encodings thereof semantically. Currently, that seems to be
>>> > only possible with video and audio. But if you create a media element
>>> > that adds no extra interface, you get this for all other types as well
>>> > (albeit with a lesser scripting interface). Although the <include>
>>> > element won't be as good integration point between one media and
>>> > scripts, it will have a standard interface somewhat applicable to many
>>> > medias/mediums and at least provide something to all medias, versus
>>> > (close to) nothing.
>>>
>>> I'm not sure I follow. If you're saying that we should also support other
>>> timed-based formats in the future even if they are not video, e.g. if you
>>> are saying we should support formats like SMIL, then there's no reason
>>> you
>>> can't do that with <video> itself. <video> really is just an API to
>>> time-based visual data, it doesn't have to be a sequence of bitmaps.
>>>
>> Oh, the following quote confused me.
>>> The video element is a media element whose media data is ostensibly
>>> video data
>>
>> I'm not just talking about SMIL. I'm talking about using a secondary
>> feature of media elements (the ability to link to multiple alternative
>> resources) even if the main feature (the API) is irrelevant.
>>
>> <video>
>>        <source src=f.utf8 charset=utf8>
>>        <source src=f.latin1 charset=latin1>
>> </video>
>> <video>
>>        <source src=img.png type="image/png">
>>        <source src=img.svg type="image/svg+xml">
>> </video>
>
> I don't understand what either of these examples could possibly mean.
> What is the charset of a video?  Why are you trying to use <video> to
> show an image?
>
>
>> I don't need to know the duration of an unanimated PNG.
>
> Correct, so why are you using <video>?  If you want image fallback,
> agitate for a solution to solve that problem.  Overloading <video>
> isn't a good idea.
>
I want a general fallback solution.

>
>>> On Wed, 19 May 2010, bjartur wrote:
>>> >
>>> > Yeah, maybe my crazy idealism and tendency to reuse existing things
>>> > don't mix up in this case. The main purpose of <video> and <audio> is
>>> > to
>>> > create a scripting interface to online video. But they also add new
>>> > linking capabilities which should be available to any content
>>> > whatsoever.
>>>
>>> I don't really see how. In what sense do they add new linking
>>> capabilities?
>>>
>> In the sense of multiple alternative (media) resources.
>>
>> This could possibly be done with <object> but its fallback mechanism
>> seems inferior.
>
> What media do you want to do fallback on?  audio and video are already
> covered.  Images aren't, but I think the image space is pretty stable.
>  If we have codec fights in the future surrounding images, we can
> solve the problem then.
>
What's wrong with solving the problem once for all?

And as SVG is not universally supported, what if I want to offer some
logos/icons/images as both (gzipped) SVG and PNG?

-- 
kv,
  - Bjartur