[whatwg] <INCLUDE> and links with @rel=embed
svartman95 at gmail.com
Thu Aug 5 19:43:42 PDT 2010
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>
>>> 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>.
> 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
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
>> 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
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
>>> > What I'm trying to write is that not all browsers support
>>> > 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
>>> 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.
>> <source src=f.utf8 charset=utf8>
>> <source src=f.latin1 charset=latin1>
>> <source src=img.png type="image/png">
>> <source src=img.svg type="image/svg+xml">
> 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
>> 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?
More information about the whatwg