W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: <video> attributes and children

From: Joe D Williams <joedwil@earthlink.net>
Date: Sun, 7 Mar 2010 07:16:18 -0800
Message-ID: <CFCF6A103FE649D6903B7F32258F9162@joe1446a4150a8>
To: "Maciej Stachowiak" <mjs@apple.com>, "David Singer" <singer@apple.com>
Cc: "'HTML WG'" <public-html@w3.org>

Maciej Stachowiak Sent: Friday, March 05, 2010 10:38 PM

>
> On Mar 5, 2010, at 10:00 PM, Joe D Williams wrote:
>
>> questions for <video>
>>
>> 1. Why does <video> not include @type and @media?
>> If <source> uses/needs them, then why not <video> if only @src?
>> If no <source> then @type and @media would not be present.
>
> @type and @media are used to select from among multiple sources.
> It's  not allowed to combine @src and <source>. So <video src> has
> only one  possible source, and therefore there's no need for
> information that  would be used to choose a source in that case.

OK, each <source> can use @type and @media along with @src to decide
upon playing the resource.
But <video> @src> does not get that help from any @type or @media.
If it is necessary or helpful for <source @src @type @media> then why
not <video @src @media @type>?

I guess the real intent may be to just have <video> carry info for the
controls, etc. and let <source>(s) carry the media info. So, still, I
think that allowing <video @src> without any access to @type and
@media seems inconsistent. That makes me want to think about droping 
@src in <video>. Always use <source> to specify the resource.

>
>> 2. Why would <source> (or <param>) include Global attributes?
>> None are rendered and only the container really needs these.
>
> Some global attributes, such as id, class, and data-*, definitely do
> make sense even on non-visible elements. For other global
> attributes,  I expect it is more trouble than it's worth to make
> them specifically  disallowed for non-visible elements.

void/empty not displayed part of the dom
element metadata?  Not a media element.

>
>>
>> 3. Why does <video> @src empty or missing mean that <source>
>> elements
>> may be included?
>
> @src and <source> are mutually exclusive.
>

if only <video @src> then (not actually specified default) is as if 
media="all" and no type

>>
>> a src attribute, or zero or more source elements, followed by some 
>> or none flow content or phrasing content
>> http://dev.w3.org/html5/spec/video.html#attr-media-src
>>
>> "There are two ways to specify a media resource, the src attribute, 
>> or source elements. The attribute overrides the elements."
>>
>> But if the attribute is present, <source> not conforming?
>
> Correct.

Do we mean not conforming like ignored, or with warning.

>
>> If the attribute is not present or empty, one or more <source> are
>> conforming?.
>
> Also correct.

That seems like it would work better because of added info by @type
and @media.
This time fully specified default is media="all" and no type.

So  for <video src='mediaresourcevalidurl.joe'>
if .joe was a standardized file extension considered for loading then 
we have a very simple construction that plays the media=all resource 
at the valid URL., but with an opportunity for confusion if the URL is 
not @media='all' and type=''.

>
>> Sorry if I apparently hadn't looked at <video> in this detail 
>> before.
>> I just thought it seemed natural that this was a two level fallback
>> plan where is the <video> @src didn't play, then try <source> @src
>> content in sequence and if still no go then show the flow or
>> phrasing
>> content.
>
> That's not how it works. You can only use <video src> in the case
> where there is a single source. Otherwise you have to use <source>
> elements.

Fine, the single recognized source, or else fallback.

>
>> Why doesn't the standard at least imply that the browser does 
>> anything 'automatic' in the fallback scheme?
>
> The spec does say that the browser does something automatic, and in 
> fact describes exactly what the browser is supposed to do: 
> <http://dev.w3.org/html5/spec/Overview.html#concept-media-load-algorithm>
>  >. Notice that if there is a src attribute, it always takes 
> precedence. Otherwise, the <source> elements are tried in order.

I am not seeing that fallback or resouce <source> element fallback 
sequence described anywhere.
As a final step in that sequence, if all else fallis, isn't the final 
fallback then show the flow or phrasing content?
.
>> Are the <source> elements in there just so I can include some 
>> script to do fallback?
>
> That's not the intent. Hopefully the above answers clarify how it
> works.

That script example in <source> shows the script doing the checking 
and deciding fallback. From descriptions, it doesn't appear automated.

4. source element
is:
The following list shows some examples of how to use the codecs= MIME
parameter in the type attribute.

should be?:
The following list shows some examples of how to include the codec
parameter in the type attribute.

5. video element
is:
<p><video src="tgif.vid" autoplay controls
onerror="failed(event)"></video></p>
<p><a href="tgif.vid">Download the video file</a>.</p>

should be:
<video src="tgif.vid" autoplay controls>
<p><a href="tgif.vid">Download the video file.</a></p></video>

The <p>...</p> in the second example represents the flow or phrasing 
content shown in the event that no video can play. It should be 
contained by the <video> element.
It is hidden unless the video fails.
The current script example show what to do if <video> is not 
recognized, it seems out of place due to <video> fallback technique. 
The second example here should work to show the fallback content if 
<video> not recognized or won't play the @src. It would be appropriate 
to show at least one example of simulated spec behavior relating to 
automated fallback..

>
> Regrds,
> Maciej
>

Thank You,
Joe
Received on Sunday, 7 March 2010 15:16:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC