Re: [whatwg] Some video questions
Charles wrote: Maciej, But I think the premise of the question misses the point of the video element. I may very well be completely missing the point. I'll be satisfied if someone tells me that video is not intended to be the preferred way to embed video on web pages, in which case I'll quietly return to my corner. I may be misinterpreting your tone, but from reading this discussion it seems that you're deliberately being difficult. Of course video is the preferred way to embed video on web pages in HTML5. It seems that you are either inadvertently or deliberately misunderstanding the stack of components that implement audio and video playback in browsers. * The Quicktime browser plugin is a video player. * The Windows Media browser plugin is a video player. * The Totem Movie Player browser plugin is a video player. * YouTube's /player2.swf is a video player. * The video player used on channel9.msdn.com is a video player. * A browser's implementation of video is a video player. None of the above things are videos. They are used to play videos. None of the above things are media frameworks, either: * Quicktime's browser plugin is a front-end for the Quicktime media framework. * Windows Media browser plugin is a front-end for Microsoft's DirectShow media framework. * Totem Movie Player plugin is a front-end for either gstreamer or xine, which are both media frameworks. * YouTube's player is a front-end implemented in Flash to the media framework built in to the flash plugin. * The video player used on channel9.msdn.com is a front-end implemented in Silverlight to Silverlight's video API. (which I suspect uses DirectShow when running on on Windows.) * video is a front-end to a media framework or some media frameworks of the browser implementor's choice. It is up to the page author to decide which video player they wish to use. Currently, many authors create their own players in Flash or they use someone else's player written in Flash. video is an alternative to a video player implemented in Flash, and an alternative to embedding the Windows Media browser plugin. It is designed to embed video, not video players implemented in other technologies. But in Safari, video = QuickTime. Is that not a player-centric rather than a content-centric design? Please be careful to qualify QuickTime when you refer to it. It's perhaps partially Apple's fault for calling everything by the same name, but it's important to keep in mind the difference between: * The QuickTime player, which is an application users can run. * The QuickTime browser plugin, which is a browser plugin similar to the QuickTime player. * The QuickTime framework, which is an API provided by MacOS for video playback, which is used by QuickTime player and is also used by iTunes, Safari, and I imagine many other MacOS applications. (I'm not a Mac user, so I hope you'll excuse the lack of an extensive list of examples.) The same distinction exists in Windows. Windows Media Player, WinAmp, Media Player Classic and several other applications are all front-ends to DirectShow, which is the Windows equivalent of the QuickTime framework. Likewise, there are several Gtk+ and GNOME applications that use gstreamer. Neither QuickTime the framework, DirectShow nor gstreamer are video players. They are frameworks on which players are built. One thing that QuickTime the framework, DirectShow and gstreamer all have in common is that all of the media decoding is done via pluggable modules, so any of these frameworks can, assuming a suitable module is installed, play any video format. (assuming that we define video to mean a non-interactive sequence of images optionally synchronised with some audio.) The HTML5 spec doesn't say you must implement video with Quicktime, it simply describes the behavior of a video element and how it interacts with the page it's embedded in. It's up to the browser vendor to decide how best to achieve the behavior that the specification requires. I believe that it is correct to say that in the version of Safari under discussion, the video element is implemented using the QuickTime framework. However, you don't need to care about this. All you need to care about is what video codecs it supports. The HTML5 spec should ultimately require at least one video format that will be available in all compliant implementations, which Apple is likely to implement by simply supplying a Quicktime module that can decode that format. It is an accepted open issue with the HTML5 spec that there is not currently at least one standard video format required. You remarked in an earlier thread that you think YouTube ought to be able to embed their player via video. Here lies the confusion: video doesn't embed players, it embeds video. What we want isn't this:[1] video src=/player2.swf but rather something like: video src=/videos/Z73xtJN6IdA.flv That is, they would
Re: [whatwg] Administrivia: new member in the oversight committee
Hi Ian, Ian Hickson wrote: FYI, Anne van Kesteren was just invited to join the WHATWG membership (as defined by our charter, basically that's the small group of people whom I have to answer to in my role as editor). He was invited due to his long involvement in the WHATWG. This oversight group doesn't do much and this won't really change anything; basically the group is there to make sure I don't become evil and biased somehow, and to help direct the group should we decide to take on some new project. Does the committee have a mailing list? Where do they discuss things? Any papertrail? cheers, Dan -- http://danbri.org/
Re: [whatwg] several messages
Ian Hickson (2008-03-23): On Tue, 18 Mar 2008, Christoph Päper wrote: a spanvalid non-negative integer/span greater than zero. Isn't that the description of a valid positive integer? If that term is not used or defined yet, why not? Because positive is confusing to people. Some people (including me) think that 0 is positive. Sure, but I thought non-negative integer was used to make it clear that zero was included. Thus for the (fewer) instances like this one, where zero is excluded, positive integer becomes available. You only need to say this once in 3.2.3., which is linked each time any way, and thereby improve readability. You could of course adopt the other definition of 'positive' instead. Btw., there is a typo in the first sentence of 3.2.3.1.: the second 'of' should be an 'or'. Comparison of character string length: Zero Count -oo .. +oo integer ind.7 i -oo .. -1negative integer ind. 16 -i non-positive integer less than zero sep. 35! +i0 non-positive integer pos. 20!+i -oo .. 0negative integer or zero ind. 24 -i|0 non-positive integer sep. 20!+i non-positive integer or zero pos. 28! +i|0 0 .. +oo non-negative integer ind. 20!-i positive integer or zero sep. 24 +i|0 positive integer pos. 16 +i 1 .. +oo non-negative integer greater than zero ind. 38!- i0 positive integer sep. 16 +i positive integer greater than zero pos.* 34 +i0 pos.: zero is positive sep.: zero has a separate state ind.: independent of choice (based on negative never includes zero) The second and third case (only negative integers) are virtually unneeded in HTML5. ind. sep. pos. 0 20 24 16 1 38 16 34 ø 29 20 25 On average character count supports non-positive zero (especially if combined with ind. wording), but if zero is usually included in HTML5, it may make sense to use positive in that way. The fully independent wording currently chosen is the worst alternative (by this criterion). So either non-negative integer / positive integer (instead of positive integer or zero / positive integer) or positive integer / positive integer greater than zero, but neither non-negative integer / non-negative integer greater than zero nor non-negative integer / positive integer greater than zero. One may consider these independet formulations, too: -oo .. -1integer less than zero ind. 22 i0 -oo .. 0integer less than oneind. 21 i1 1 .. +oo integer greater than zeroind. 25 i0 .oO(Much fuzz about nothing.) Why can |rowspan|, unlike |colspan|, be 0, but is then also normalised to 1? It's not normalised to 1, is it? I don't understand. It is not, I misinterpreted this sentence: Its default value, which must be used if parsing the attribute as a non-negative integer returns an error, is also 1.
Re: [whatwg] Administrivia: new member in the oversight committee
On Sun, 30 Mar 2008, Dan Brickley wrote: Ian Hickson wrote: FYI, Anne van Kesteren was just invited to join the WHATWG membership (as defined by our charter, basically that's the small group of people whom I have to answer to in my role as editor). He was invited due to his long involvement in the WHATWG. This oversight group doesn't do much and this won't really change anything; basically the group is there to make sure I don't become evil and biased somehow, and to help direct the group should we decide to take on some new project. Does the committee have a mailing list? Where do they discuss things? Any papertrail? There's no public accountability for this group, no. It's roughly equivalent to W3C staff, except that it is not a paid position. See also: http://www.whatwg.org/charter -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: new member in the oversight committee
Le 31 mars 2008 à 10:43, Ian Hickson a écrit : There's no public accountability for this group, no. It's roughly equivalent to W3C staff, except that it is not a paid position. If you really want your metaphor flies… You could have said it's roughly equivalent to W3C Members of Advisory Committee, or Members of Advisory Board. That's all. W3C staff is tied by a work contract and a process. -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool
Re: [whatwg] [HTML5] Accessibility question
@irrelevant is virtually indistinguishable from setting content to display:
none. My point in bringing up accessibility with a possible attribute or
element is to figure out where the lines between HTML and CSS are, as it
appears HTML 5 has muddied the water. As I stated earlier on this list, if
something is truly irrelevant, then it's not included in the page. Something
that's on the page and hidden is relevant, just perhaps not at the current
time, which led to the suggestion on this list to rename the attribute
ignore.
I understand your point about superfluity being defined by the presentation
(one could argue the same about relevance...). Aural CSS seemed, at one point,
like it would make sense for handling such issues. However, since screen
readers read the screen media styles, it doesn't really help.
I still feel like it's a good idea to have an optional attribute on each
element that indicates the element's content should not be ignored by screen
readers regardless of the style applied. Perhaps this could be better handled
by an ARIA role...
-Nicholas
- Original Message
From: Benjamin Hawkes-Lewis [EMAIL PROTECTED]
To: Nicholas C. Zakas [EMAIL PROTECTED]
Cc: whatwg List [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 12:27:37 PM
Subject: Re: [whatwg] [HTML5] Accessibility question
Nicholas C. Zakas wrote:
The first use case is now handled in HTML 5 via @irrelevant.
I don't think it is, actually:
http://www.w3.org/html/wg/html5/#the-irrelevant
Additional content is not irrelevant; it's helpful sometimes and
superfluous at other times.
The draft spec says User agents should not render elements that have
the irrelevant attribute specified. This is incompatible with what I'm
suggesting, which is that user agents might want to render additional
content when it is helpful and ignore it when it is superfluous.
The intention of the draft seems to be that @irrelevant should be
manipulated by scripting. That too is incompatible with what I'm
suggesting, where UA logic and user actions decide whether to render
additional content or not (a bit like @title).hey
We currently now use display: none or
visibility: hidden to hide content that isn't necessary for users at
that time, which is the same purpose as @irrelevant (from previous
discussions).
Display: none; or visibility: hidden; affect only the suggested
presentation of information; @irrelevant changes the semantics.
It's true that developers sometimes try to use display: none; and
visibility: hidden; like @irrelevant could be used; I think that's
(often) unwise because they are such brittle tweaks in the wrong layer.
I'm very familiar with defining separate CSS classes for moving content
offscreen, and it seems like a big hack to me.
It is very hacky, agreed.
It also seems that this
is a common enough use case that it merits further investigation.
Yep.
Perhaps the greater
question is whether or all showing/hiding of content is really a CSS
issue or if there are some that use cases that do belong in HTML.
Sometimes content's superfluity is itself dependent on the
presentational skin. For example, if CSS radically distinguishes a
navigation area from surrounding content, having a Navigation header
might become superfluous. In such cases, it makes more sense to use the
off-screen hack or some better (future) CSS technique, e.g.:
nav h1:out-of-context {
display: block;
}
But ideally a suggested presentational skin should not be used to try
and designate content to be superflous when its superfluity depends on
browsing context not the skin itself, for example when part of a link's
text is superfluous if you're going through the document in order.
--
Benjamin Hawkes-Lewis
No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo!
users and friends.
http://tc.deals.yahoo.com/tc/blockbuster/text1.com
