Re: [whatwg] Video proposals
(oops, this is a re-send of an email I sent only to Ian Hixie. I keep
pressing the wrong reply button :-( )
On 3/15/07, Ian Hickson [EMAIL PROTECTED] wrote:
In the meantime, here's replies to the comments I got.
Wow. Nice.
On Wed, 28 Feb 2007, Anne van Kesteren wrote:
Opera has some internal expiremental builds with an implementation of a
video element. The element exposes a simple API (for the moment) much
like the Audio() object:
play()
pause()
stop()
The idea is that it works like object except that it has special
video semantics much like img has image semantics. In markup you
could prolly use it as follows:
figure
video src=news-snippet.ogg
...
/video
legendHTML5 in BBC News/legend
/figure
I attached a proposal for the element and as you can see there are still
some open issues. The element and its API are of course open for debate.
We're not enforcing this upon the world ;-)
I have added such an element and its corresponding API (influenced by the
other feedback received) to the specification. Thank you for the proposal
and implementation experience!
What are the events? I scanned the spec for events:
begin (can this be caught by script? is that what at the video
element means?)
progress
stalled
stopped
load
abort
Is this accurate?
I noticed the stop() method is used both to stop playback and to abort
any pending download. Is this a good idea? Wouldn't it be simpler to
add abort() to explicitly stop the download?
Are timeout's guaranteed to be in sync with the video? For example:
// assume myvid.position = 0;
myvid.play();
myvid.setTimeout('alert(myvid.position);', 10);
What happens?
I have a hunch most authors will care more about time till the end
than time since the 0. I don't have any evidence for this, and don't
know why I think it. Except for...
ON PLAYLISTS
On Mon, 30 Oct 2006, Shadow2531 wrote:
The handler should also support some type of playlist like
http://www.xspf.org/.
On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:
#3: Playlists. (A single video file just won't cut it.)
These were the only requests for playlists. Could you elaborate on the use
cases for playlists? What are the needs for playlists?
I don't see a need for this, if other things are reasonable, we can
implement continuous playback or a playlist using something like.
// could make a microformat to describe playlists... perhaps XOXO with an
// extra classname. playlist could be parsed from the dom, or provided
// via some other mechanism.
var playlist = ['one', 'two', 'three'];
var current = 0;
var mainVideo = document.getElementById('myvideo');
var dummyVideo = document.getElementById('dummyvideo');
window.onload = function() {
mainVideo = playlist[current];
};
// would *REALLY* prefer a finished event or something to tell the
difference between
// the user watching the video completely, and it having stopped, and
script or the
// user pressing a stop button.
// because otherwise, the code to tell if we've stopped looks something like:
video.stopEvent = function(callback) {
// not sure these apply()'s do what I think they would do.
callback = function(this) {
if(this.state == PLAYING) {
return callback.apply(this);
}
};
setTimeout(callback.apply(this), video.length - video.position);
};
// which is pretty undesirable, as it still doesn't always do what you
would expect.
// (eg. if the time to finish changes because of a seek, or the video's src
// changes or something...)
// so assuming a stopped event existed...
mainVideo.finished = onFinishedMain;
onFinishedMain = function() {
// uh... does the cache kick in, or do we need to clone and delete? :-
mainVideo.src = dummyVideo.src;
// uh.. if the src changes, does my event stick, or do I need to reassign it?
//mainVideo.finished = onFinishedMain;
current++;
}
function queueNextVideo() {
if(nearlyComplete(mainVideo) {
// have the next one start downloading...
dummyVideo.src = playlist[current+1];
}
if(current playlist.length) {
setTimeout(queueNextVideo, mainVideo.length*.20);
}
}
function nearlyComplete(video) {
if(video.state == PLAYING) {
if(video.position/video.length .80) {
return true;
}
}
return false;
}
Something like that would be pretty common, I think. I suspect most
script authors will want to know when a video is nearing completion,
and when the user has finished watching it. It's also a common
technique for authors to buffer images in the background, and then
swap them in when needed. (BTW, one thing that is really annoying is
not knowing when resources [like images or scripts] failed to load.)
OHHH I see, there is a played range, and that you can use /that/ to
tell if the user has seen the whole thing or not... still seems a bit
tricky to figure it out, if all you want is an event for we've just
finished watching the whole thing now, thanks!
What happens to the played range after we use seek()?
ON FEATURES
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/16, Gareth Hay [EMAIL PROTECTED]: Well, the current W3C spec has relatedTarget specifically for these use cases, so again I fail to see why adding convenient shorthand for functionality is a good thing here. If we try to cover everyone's use cases with easy functionality, the spec is going to be huge with lots of overlapping functions and elements. To me this is simply a programming problem, which is easily solved to the use cases suggested, and also the inverse of actually wanting the bubble. Well, there more examples like that that, which are very successful, like .innerHTML. Regards, Martijn Gareth On 16 Mar 2007, at 03:41, Benjamin West wrote: This is a pretty well known issue, and a constant stumbling block. There are use cases for using the capture/bubble stuff[1]. However, by far, the most common need is for simple one-off's, and the bubbling really gets in the way. The issue is explained quite well on PPK's site: http://www.quirksmode.org/js/events_order.html http://www.quirksmode.org/js/events_mouse.html -- covers mouseenter and mouseleave and why it's better (because it explains how tedious the traditional model is first.) The bottom line is that introducing mouseenter and mouseleave will reduce a lot of CPU cycles, and make authoring a lot easier. [1] http://decafbad.com/blog/2006/10/31/event-delegation-based- dhtml-drag-and-drop http://icant.co.uk/sandbox/eventdelegation/ -Ben -- Martijn Wargers Help Mozilla! http://weblogs.mozillazine.org/qa/ http://www.mozilla.org/contribute/
Re: [whatwg] Adding mouseenter and mouseleave events
Is one of the objectives here not to repeat the same mistakes as in the past? Anyway, I seem to be the only descenting voice on this topic, so I suppose I should yield. On 16 Mar 2007, at 09:31, Martijn wrote: 2007/3/16, Gareth Hay [EMAIL PROTECTED]: If we try to cover everyone's use cases with easy functionality, the spec is going to be huge with lots of overlapping functions and elements. To me this is simply a programming problem, which is easily solved to the use cases suggested, and also the inverse of actually wanting the bubble. Well, there more examples like that that, which are very successful, like .innerHTML. Regards, Martijn
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/16, Gareth Hay [EMAIL PROTECTED]: Is one of the objectives here not to repeat the same mistakes as in the past? What do you mean? Which mistakes? Regards, Martijn
Re: [whatwg] Video proposals
Also sprach Laurens Holst: http://www.whatwg.org/specs/web-apps/current-work/#video Correct me if I
Re: [whatwg] Adding mouseenter and mouseleave events
Well, this is my final word on the subject, it's my opinion, and by the looks of it, only my opinion, but I *personally* don't see the need for changing what we have. I believe that all use cases are currently covered by the W3C spec.I think IMHO that adding 'shorthand' functions, for functionality that already exists, and restricting that functionality adds a barrier of entry to a new developer, and produces a messy outcome. For instance, if you had a 'branding' image for your web sites, and it is always 100px x 100px, that is not good for you to have a new attribute on the img tag for 'branding', so that the image is always rendered 100x100, nor is it good to have a new tag imgbrand that renders the src as 100x100. You simply use the existing img tag and modify it to your specific case. Again, that is *only my opinion*, and final word on the subject. Gareth
Re: [whatwg] Video proposals
Benjamin West wrote: On 3/15/07, Ian Hickson [EMAIL PROTECTED] wrote: .loop, .startpos loop = false | true autostart = true | false startpos = 0 | specified pos Could you elaborate on the use cases for these? Can't these be done in script? Those attributes are basic values you'd want to use to initialize the video. For those that don't know Javascript very well and just want a video to play a certain way right away, it would be a real pain to only have access to these properties via scripting. Besides, I can't see the author wanting to set |autostart| and |startpos| dynamically, as they are clearly intended to be used when the page is loading. (The |loop| attribute might be set dynamically, but I can see situations where one would want the video to play in the background in a continuous loop from the moment the page is loaded. Granted, most of those uses are presentational.)
Re: [whatwg] Video proposals
On Fri, 16 Mar 2007 04:39:07 +0100, Ian Hickson [EMAIL PROTECTED] wrote: ON PLAYLISTS On Mon, 30 Oct 2006, Shadow2531 wrote: The handler should also support some type of playlist like http://www.xspf.org/. On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote: #3: Playlists. (A single video file just won't cut it.) These were the only requests for playlists. Could you elaborate on the use cases for playlists? What are the needs for playlists? When I think of playlists, the first thing that comes to mind are commercials. Some video sites show ad or promotion clips before and/or after the main video. I imagine they'd see that as a use case. It could also be used to create medleys of several smaller clips, although it might not be a big need. -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: [whatwg] Adding mouseenter and mouseleave events
On Fri, 16 Mar 2007 11:35:57 +0100, Gareth Hay [EMAIL PROTECTED] wrote: For instance, if you had a 'branding' image for your web sites, and it is always 100px x 100px, that is not good for you to have a new attribute on the img tag for 'branding', so that the image is always rendered 100x100, nor is it good to have a new tag imgbrand that renders the src as 100x100. You simply use the existing img tag and modify it to your specific case. FWIW: The proposal here is not entirely new. Internet Explorer supports these events. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Video proposals
Discussion on aspect ratio:
You may want to consider aspect ratio too: ratio=preserve being
default, ratio=1.333 could indicate 4:3 or get tricky and accept
16:9 for precision reasons.
Wouldn't we simply always want to use the authored size?
Do videos encode what size they are best displayed in? I hate
entering height and width for images.
The reason I requested this is because:
1) If you specify both a width and a height, video content that
doesn't match that gets distorted.
2) If you want an element to have a fixed width, but variable height
dependant on the aspect of the video, or fixed height and variable
width, yet still have a non-zero initial value for the variable
parameter (so that the video element occupies some screen area),
you cannot achieve this without distorting the final image by setting
both width and height.
3) Thinking about it more, the ratio should be explicitly advisory
and only valid until the downloaded video can provide it's own width
and height.
I envisage:
video src=foo width=386px aspect=59:54/video
pSome content below the video/p
Then, when the video is finally downloaded and it's inherent
dimensions (and thus aspect ratio) are known, re-layout can occur if
the aspect values don't match, but more importantly can be avoided if
they do.
The width given is an integer number of CSS pixels, by providing an
aspect ratio, the UA can calculate the resultant height in device
pixels without the user having to provide a height and associated
rounding errors (or plain mistakes). The example above has an
irrational height.
4) Only two of {width, height, aspect} can be specified on any video
element.
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] Video proposals
Laurens Holst wrote: Sure, native video playback, yay. But what has that got to do with creating a video element instead of using object. Objects can play Theora, too, you know. Natively. Just like browsers can render SVG in object tags, natively. It's all about ease of authoring. If you were new to HTML, would you want to do this... | object data=TheEarth.mpeg type=video/ogg-theora/object ...Or this... | video src=TheEarth.mpeg/video Do you know the MIME type for Ogg Theora? I don't. I made it up. If the MIME type on the object listed doesn't say video in it, would you even know if the object element was for a video???
Re: [whatwg] Adding mouseenter and mouseleave events
Gareth Hay wrote: Maybe your use case requires something different, but I can't imagine that scenario. I ran across this issue the other day, and found this explanation / example which may help clarify the issues people encounter: http://dynamic-tools.net/toolbox/isMouseLeaveOrEnter/ Rob
Re: [whatwg] Adding mouseenter and mouseleave events
It's not a case of not understanding. I fully understand the use case and bubbling, I just don't see this as a problem. On 16 Mar 2007, at 12:29, Rob Crowther wrote: Gareth Hay wrote: Maybe your use case requires something different, but I can't imagine that scenario. I ran across this issue the other day, and found this explanation / example which may help clarify the issues people encounter: http://dynamic-tools.net/toolbox/isMouseLeaveOrEnter/ Rob
Re: [whatwg] require img dimensions to be correct?
Regarding: img dimensions to be correct? Sander Tekelenburg wrote: We struggled with this for the WRI requirements[*]. We seem to be settling on requiring a width and height to be specified in HTML, because as nice as CSS is, Web pages must not be CSS-dependant. Even if the author means to provide CSS, it might not be available (network/server error; saving and local viewing of the HTML file; User CSS overrides) (A followup requirement would probably have to be that when CSS is available, and specifies IMG size in px, it must be the same as the size specified in the HTML.) The only other sensible option would be to completely disallow width and height in HTML. But that will result in 'jumpy rendering' because browsers can't allocate the proper rendering space until the image's dimensions are known. [*] http://webrepair.org/02strategy/02certification/01requirements.php Btw, this is our initial take. We very much welcome community feedback. I don't really think this is a good idea IMHO. Firstly, the chance of someone not being able to access the CSS for a web page is I'm guessing, pretty slim. The chance of someone not being able to access this CSS, *and* actually noticing or caring that the images aren't rendered correctly (if in fact they aren't), is very very slim. So I don't think it's really worth throwing away the benefits of CSS just for a very rare occasion like this that would probably not be of benefit to anyone anyway. Secondly, when scaling images you would normally just set the height, not the width. This ensures that the images proportions are kept intact, as specifying a width distorts the image. This being said I hope no one makes it a requirement to specify just the in-line height, as this would still create problems. For example if you had an images height set within the html to 100% of the parent elements height, and there was no CSS available to specify the parents height (for example a div), the user agent would probably just stretch the image to the full height of the screen (FF doesn't do this, but IE and Opera do), therefore causing more problems than if you had just left all the styling in the CSS to begin with. So the long and the short of it IMO is to just use CSS and rely on the user-agent to show the page the best it can in the absence of CSS. regards, -- Dean Edridge
Re: [whatwg] Video proposals
On 3/15/07, Ian Hickson [EMAIL PROTECTED] wrote: ON PLAYLISTS On Mon, 30 Oct 2006, Shadow2531 wrote: The handler should also support some type of playlist like http://www.xspf.org/. On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote: #3: Playlists. (A single video file just won't cut it.) These were the only requests for playlists. Could you elaborate on the use cases for playlists? What are the needs for playlists? A video might be split into separate files (chapters). A playlist is needed to provide consecutive playback without user interaction and to provide view of your choices. If you've ever watched episodes in parts on youtube, you might see why this is important. One could use the events and states to determine when a video is done playing. Then, the src attribute could be changed to the next video. The list of videos could be gotten from a JS array or by parsing an xml playlist via self-written code or some playlist parsing JS library. However, what if JS is turned off and you want to do playlists? video src=playlist.xspf/video The video element itself would need to handle the playlist. (Unless you set up links to video pages that where targeted at an iframe. Even then, user action would be required if consecutive playback was desired.) ON FEATURES On Thu, 1 Mar 2007, Shadow2531 wrote: [long list of desired features] I took your suggestions into account when desiging the API. I got feedback from a number of people (including some off-list from people who didn't want to express their interest publicly), some of which was contradictory, so the proposed API doesn't have everything you asked for. Let me know if there's anything that you think is missing that you really wanted. Understood. Thanks. .loop, .startpos loop = false | true autostart = true | false startpos = 0 | specified pos Could you elaborate on the use cases for these? video src=VideoIWasWatching.ogg param name=startpos value=value gotten from cookie where I left off at /video video src=AwesomeMusicVideo.ogg param name=loop value=true /video Page where a user is expecting a video to play. video src=file.ogg param name=autostart value=true /video Index page for example where a video starting up might not be expected. video src=file.ogg param name=autostart value=false pThis is my index page/p /video (From the list and the spec, it looks like the video will never play on its own. It looks like you have to invoke play() with js or nothing will ever happen.) Again though, autostart, loop and startpos could be simulated with the events and states provided. However, what if JS is turned off? You need params to provide initial state. JS should only be needed for controlling/interface stuff. If you just want to have a video load and play till the end (and loop possibly), that shouldn't require JS. However, if JS is needed for the video element to function at all, then the video element needs to fall back if JS is turned off. On Thu, 1 Mar 2007, Shadow2531 wrote: I think it'd be cool if the video element *just* supported theora. Supporting only one encoding is not going to fly: you can't stop browser vendors from adding features; and you want to allow the standard to evolve over time. Understood. The SHOULD for theora is good enough. -- burnout426
Re: [whatwg] Video proposals
On 16 Mar 2007, at 15:32, Shadow2531 wrote: .loop, .startpos loop = false | true autostart = true | false startpos = 0 | specified pos Could you elaborate on the use cases for these? video src=VideoIWasWatching.ogg param name=startpos value=value gotten from cookie where I left off at /video The downside of that is sites have to implement a cookie system. I don't want to do that on my own site and many personal website owners won't know how to either. For the above usage case, I don't see why remembering where you left off can't be a user-agent feature rather than part of the specification. Granted that would fail if you switch browsers but people don't do that much. All said, it would be very useful if the startpos param could be returned to the server when starting the download, or when scrubbing forward into parts of the video that haven't yet downloaded. as that would help avoid using bandwidth unnecessarily. I see two ways to do that over HTTP: 1) As a HTTP header 2) In the URL There is also currently this RTSP URL format understood by RealPlayer: rtsp://rmv8.bbc.net.uk/french/fre0600.ra?start=%2220%22 Other formats may understand other parameters, or not define startpos as an integer number of seconds, but use hrs:mins:secs etc. How would the UA then send the startpos if differing content types used different mechanisms? - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Video proposals
On Fri, 16 Mar 2007 07:23:53 -0400, Matthew Raymond [EMAIL PROTECTED] wrote: Do you know the MIME type for Ogg Theora? I don't. I made it up. If the MIME type on the object listed doesn't say video in it, would you even know if the object element was for a video??? application/ogg, presumably. -- J. King http://jking.dark-phantasy.com/
[whatwg] Frames.
Couple of thoughts aloud about that notorious frames. Sidenote: There are use cases when frames are good. As an example: online (and offline) help systems, e.g. [1] In such cases they provide level of usability higher than any other method of presenting content of such type. iframes are defined currently in WHATWG spec but frameset/frame are not there yet as far as I can see. So couple of ideas about frames and results of experiments with windowless frames I did recently. First idea is to separate frameset and frame/iframe: 1. frameset 1.1 frameset alone could be used as a container where different panels are splitted by so called splitter - UI element that allow to changing size of panels inside. In my interpretation/implementation frameset is a block element with display-model: blocks-inside so following markup is valid: body h1HTML 5 elements/h1 frameset cols=200px, * nav class=toc hTOC:/h ol/ol nav frame class=content-panel / /frameset /body That will create two panels divided by the splitter. First panel (nav.toc) will have static content that is given inline. Second panel is frame.content-panel (or iframe.content-panel , see below). 1.2. I think that it makes sense to allow frameset to appear in any place where block elements are allowed. I do not think that I need to elaborate this more. Benefits should be clear for those who are doing practical design these days. 2. frame If we will allow frameset to appear not only as immediate child of the body then I think we can do the same with the frame. This allowance will effectively eliminate all differences between frame and iframe. So frame and iframe can be declared as synonyms for backward compatibility. 3. windowless frame In my implementation frames are windowless entities. windowless here means that frame DOM element has no window object associated with it. Document with the frame plus loaded content of the frame constitute single DOM tree. html body ... frame html body.../body /html /frame /body /html In such model frames are close to ordinary block elements. The main purposes of such lightweight frames are: 1) isolation of style systems for parts of the page - needed in cases like on-line mail clients and the like. 2) isolation of script namespaces. 3) frame as a dynamic update panel in terms of AJAX. By addition of couple of attributes host document can share (provide default or override) style system with the content of such frame. So dynamic update of the page fragment will not require that ugly and highly non-effective tricks used by AJAX. I think that by adding some simple attribute switch for the frame element frame tag can be reused for windowed/windowless frames. If this needed of course. 4. frameless frames. To extend interface HTMLElement by the method: void loadFrom( DOMString urlRemoteDoc ); this method will replace innerHTML of the element by the innerHTML of the body element of the document given by urlRemoteDoc. No invocation of scripts from remote doc should be made, all style blocks need to be ignored. So this is only for pure content loading. 5. frame as an input element. To allow frame be inserted as input element on the form. Think about the case: form frame contenteditable name=e-mail-body / button type=submitSend/button /form --- Andrew Fedoniouk. http://terrainformatica.com [1] http://www.terrainformatica.com/htmlayout/doxydoc/index.html
Re: [whatwg] Video proposals
--- Matthew Raymond [EMAIL PROTECTED] wrote: It's all about ease of authoring. If you were new to HTML, would you want to do this... | object data=TheEarth.mpeg type=video/ogg-theora/object ...Or this... | video src=TheEarth.mpeg/video Do you know the MIME type for Ogg Theora? I don't. I made it up. If the MIME type on the object listed doesn't say video in it, would you even know if the object element was for a video??? The type attribute for object elements is optional if the data attribute is present. That's not new either - it was also specified that way in HTML 4.01. Some browsers have not been compliant about it, but people will probably be able to use an object element without a type attribute without worry before they're able to use a video element without worry. There's several good reasons for introducing a video element, but I don't consider easier markup to be one of them.
Re: [whatwg] require img dimensions to be correct?
On 3/16/07, Dean Edridge [EMAIL PROTECTED] wrote: Firstly, the chance of someone not being able to access the CSS for a web page is I'm guessing, pretty slim. img style=height: 50px; width: 50px; / Why is accessing CSS a problem? -Ben West
Re: [whatwg] Video proposals
This topic is worrying me slightly, as I can only see two possible outcomes :- using object for everything, images object type=image/jpeg data=some.jpg video object type=application/ogg data=video.ogg or defining separate tags for all possible content :- image video sound etc... As I can't see how it can be a mix and match of the two approaches. Gareth On 16 Mar 2007, at 19:40, James Justin Harrell wrote: --- Matthew Raymond [EMAIL PROTECTED] wrote: It's all about ease of authoring. If you were new to HTML, would you want to do this... | object data=TheEarth.mpeg type=video/ogg-theora/object ...Or this... | video src=TheEarth.mpeg/video Do you know the MIME type for Ogg Theora? I don't. I made it up. If the MIME type on the object listed doesn't say video in it, would you even know if the object element was for a video??? The type attribute for object elements is optional if the data attribute is present. That's not new either - it was also specified that way in HTML 4.01. Some browsers have not been compliant about it, but people will probably be able to use an object element without a type attribute without worry before they're able to use a video element without worry. There's several good reasons for introducing a video element, but I don't consider easier markup to be one of them.
Re: [whatwg] require img dimensions to be correct?
If i'm not mistaken, the idea of separation of content and style means you can use your own css, or even none at all, and still have the ability to view the content. If a page is dependent on the css, then, although in a separate file, it is fundamentally not separate at all, and we might as well just shove the css into the same html file anyway. Gareth On 16 Mar 2007, at 20:27, Benjamin West wrote: On 3/16/07, Dean Edridge [EMAIL PROTECTED] wrote: Firstly, the chance of someone not being able to access the CSS for a web page is I'm guessing, pretty slim. img style=height: 50px; width: 50px; / Why is accessing CSS a problem? -Ben West
Re: [whatwg] Video proposals
Huh? Huh? I don't seem to recall stating a preference, just that in my opinion you have one or the other, but it's hard to justify both. So you are advocating the later approach then? dispose of the object tag and just have imgvideosoundflashscriptto infinity and beyond etc? Gareth On 16 Mar 2007, at 21:16, Benjamin West wrote: On 3/16/07, Gareth Hay [EMAIL PROTECTED] wrote: This topic is worrying me slightly, as I can only see two possible outcomes :- using object for everything, images object type=image/jpeg data=some.jpg video object type=application/ogg data=video.ogg or defining separate tags for all possible content :- image video sound etc... As I can't see how it can be a mix and match of the two approaches. Gareth Huh? script isn't going away. img isn't going away. We've already heard feedback that overloading object with new behaviours is harder than providing specific elements for known use cases. Solving specific problems is good. It's easier for implementors, and it's easier for authors. Why continue to advocate for a general approach that is both harder to implement and harder to author, when we have a specific use case in hand? -Ben
Re: [whatwg] Video proposals
I think it would be useful if fragment identifiers in URL could specify starting position of video. This would let anyone to bookmark position in the video without having to worry about (lack of) site-specific navigation and UI for seeking. [EMAIL PROTECTED]:mm:ss (I'm not sure how should it be handled if video doesn't have an ID - maybe ID of any ancestor element could be used instead or fragment would affect any/first video on the page) The use case however is quite simple and common: If I'm watching long video and want to show interesting part of it to my friends (or bookmark it), I could right-click the video, choose Copy link to this video option and have URL with current playing position copied. -- regards, Kornel Lesiński
Re: [whatwg] Video proposals
On Fri, 2007-03-16 at 20:55 +, Gareth Hay wrote: As I can't see how it can be a mix and match of the two approaches. Why not? It seems pretty pragmatic to have first-class support for the handful of common cases and have an escape hatch for generic objects. -- ...jsled http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [whatwg] Video proposals
Gareth Hay wrote: Huh? Huh? I don't seem to recall stating a preference, just that in my opinion you have one or the other, but it's hard to justify both. So you are advocating the later approach then? dispose of the object tag and just have imgvideosoundflashscriptto infinity and beyond etc? object is pretty much now for browser plugins. video is for native video, img is for native images. flash would be a poor choice of something to put in a spec, simply because its use case is already handled by object. Pragmatically, there's no problem, especially with the flawed handling of object out there. Andrew Sidwell
Re: [whatwg] Video proposals
Andrew Sidwell said: flash would be a poor choice of something to put in a spec, simply because its use case is already handled by object. I wouldn't say it that way. I'd say because flash requires a browser plugin, we use object. Video is already handled by object but we don't want it to be any more. So, when you substitute flash with video in your sentence above, it is self-defeating. The reason Flash ought to stay in the object tag is because it is proprietary and requires a plugin. If Flash is ever open and freely available from Adobe, then flash might not be such a bad idea. Several video formats, on the other hand, are supported by major operating systems natively, and there is no need to have web developers jumping through hoops to use it. The theora codec, I assume, would be contained inside the browser itself, thus making it one format that would certainly be cross-browser and cross-platform whether the OS supported it or not. -- Robert http://robertdot.org
Re: [whatwg] Video proposals
Ok, I could understand that approach, with things like imgvideo handled internally. Is there then a case for doing object properly by specifying a replacement, something like plugin / extern? Gaz On 16 Mar 2007, at 22:15, Robert Brodrecht wrote: Andrew Sidwell said: flash would be a poor choice of something to put in a spec, simply because its use case is already handled by object. I wouldn't say it that way. I'd say because flash requires a browser plugin, we use object. Video is already handled by object but we don't want it to be any more. So, when you substitute flash with video in your sentence above, it is self-defeating. The reason Flash ought to stay in the object tag is because it is proprietary and requires a plugin. If Flash is ever open and freely available from Adobe, then flash might not be such a bad idea. Several video formats, on the other hand, are supported by major operating systems natively, and there is no need to have web developers jumping through hoops to use it. The theora codec, I assume, would be contained inside the browser itself, thus making it one format that would certainly be cross-browser and cross-platform whether the OS supported it or not. -- Robert http://robertdot.org
Re: [whatwg] Video proposals
Gareth Hay said: Ok, I could understand that approach, with things like imgvideo handled internally. Is there then a case for doing object properly by specifying a replacement, something like plugin / extern? Something that is bugging me over on the W3C HTMLWG mailing list is the want to drop acronym in favor of abbr. I'm emotionally attached to acronym. I use it a lot, and really do feel like it is semantically different from abbr. Asbjørn Ulsberg suggest replacing both with short. [1] The idea was a relief because it made the tag MUCH more generic and (now that I think about it) could have more accurate and broader references (e.g. microformats use abbr for shorter date format, but short would make more sense). The problem is that short is not backwards compatible, and it kills off two elements at once. What we need to do, instead, is disconnect from our internal definitions of what a tag is, and reuse it to serve as what it ought to have been called to be semantically correct. So, I'll just have to get over the idea that abbr really just means the string in here is a shortened version of a longer string and not the characters in here are a shortened version of a long word. In much the same way, object is now associated with media other than images (even though object will do images). Instead of killing it for better semantics, backward compatibility be damned, we need to change our thinking to: object means a file that needs a plugin object to play. We'll still be able to play video and show pictures using the object tag. We'll need that for backward compatibility. But, we should start using video to play video once HTML 5 is finalized and use object for playing video only as a fallback until browsers understand video. If we drop and change elements just because we think another would be semantically better / cooler, we'll end up looking like XHTML 2. We don't want to be there, I promise. [1] http://lists.w3.org/Archives/Public/public-html/2007JanMar/0140.html -- Robert http://robertdot.org
Re: [whatwg] Video proposals
Also sprach Ian Hickson: ON THE CODEC ... Given this, I would suggest Ogg Theora be the natively supported video format common to all browsers. It's designed from the beginning to be unencumbed. And implementations for it already exist under licenses that should make everyone happy. A number of other people said similar things about Ogg Theora. For now, the spec says that UAs SHOULD support Theora for video and Vorbis for audio, and SHOULD support the Ogg container format (it's not a MUST because some vendors may have legal reasons why they can't or won't support it, and there's no point making them non-conforming when they have no choice in the matter). I'd rather make video and audio optional so that those who cannot support these Ogg on these elements (for whatever reason) can still comply with the spec. They can also support proprietary codecs through object. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Håkon Wium Lie said: I'd rather make video and audio optional so that those who cannot support these Ogg on these elements (for whatever reason) can still comply with the spec. They can also support proprietary codecs through object. Do you mean make the elements themselves optional to support? If so, I think that is a good way to make sure no one supports them. If you mean not having the codec be required, I might be willing to agree. However, I would also think that it would be a good way to make sure few, if any, common formats are supported (I can't reliably get WMV files to play on my Mac, for example, and Microsoft would certainly provide support for WMV). PNG was donated to the W3C and has been implemented by the major vendors (so, there are no problems with licensing, apparently). I wonder if there is any video format that could be similarly used since this BSD-style-license'd format isn't up to spec for some vendors. It doesn't have to be the best. It just has to be decent. -- Robert http://robertdot.org
Re: [whatwg] video element proposal
* Håkon Wium Lie wrote: Namespaces are hard and I doubt that any markup that requires using them will succeed. Also, the vendor-specific string is troublesome for general use. If we want to make video a first-class citizen on the web (and I think we do) we can afford to give it its own element in HTML. The name and attributes can be borrowed from other specs, but the element itself should be in HTML. Second, about the codecs. I believe it's vital that we find a video format that is sufficiently open. It should be described in a freely available specification and there should be no (known or unresolved) patent claims. I don't think this is the case for the codecs on the other side of the t:video element. Yes, well, there are only so and so many variables you can optimize for. So let me just pick some and see where we stand. The first is, I want to leverage my knowledge of related technologies like SMIL, SVG, and Flash. This is important, for example, if I start with a plain HTML video page and later want a more sophisticated interface with vector graphics, ani- mation and so on, so I might switch from HTML to XHTML+SVG. Here is how we fare for some basic features: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED ... We can also compare with Flash: +--+-+ | Flash/ActionScript | WHATWG| +--+-+ pause() | togglePause() pause(true) | pause() pause(false) | togglePause() seek(s) | seek(1000 * s) time | position / 1000 ... So if I move from xhtml:video to svg:video or smil:video or ie:video, I would have to rewrite most of my scripts, whereas moving between the others can be done effortlessly. Web application technologies should be based on technologies authors are familiar with, except when you don't feel like it? The next is compatibility. I want my content to work in as many cases as possible. It goes without saying that WHATWG video works nowhere. I think Any solution that cannot be used with the current high-market- share user agent without the need for binary plug-ins is highly unlikely to be successful. Clearly WHATWG video cannot be made to work in IE either because at the very least that would require making the internal representation of the document invalid. I cannot effort that, as some people would think I might be actively sabotaging the work of web standards and W3C, or at the very least, be demonstrating an almost unbelievable lack of competence. So you can consider web standards compliance a third item in my list (I understand this is not shared by WHATWG, as using tag soup is considered a reasonable transition strategy). As for codecs, I recently had to put a bunch of my old videos into a form that I could publish and did try to use sufficiently open formats. Some of my findings are in the logs on http://swhack.com/, but to give a quick summary: that's far from working as yet. It is hard to find tools that take care of transcoding, they are difficult to use (lack of advise on which settings to use, crude command line interfaces, ...) and using Ogg Theora generally meant considerably reducing the quality while at the same time considerably increasing file size, not to mention that going from various of the formats I had meant going from works almost everywhere to works almost nowhere. For some of them I could not find free tools at all, and in a few cases I could find no tools whatsoever (old Intel Indeo encoded AVIs created under Win3.11, I have the codecs somewhere on backups, but they are not on the web and apparently not implemented independently, so much for proprietary formats). It would be easier, of course, if I still had the raw video data and could encode it directly, just like you get better HTML if you just write the HTML directly instead of going through your Word process and several conversion layers, but I don't have them. So, where does that leave me? Ah, yes, Page xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation; MediaElement Source=example.video / /Page which, too, has the benefit of actually working in my web browser. It also happens to be much simpler than the equivalent HTML5 document. So, sure, don't pick the not-invented-here APIs,
Re: [whatwg] Video proposals
Also sprach Robert Brodrecht: I'd rather make video and audio optional so that those who cannot support these Ogg on these elements (for whatever reason) can still comply with the spec. They can also support proprietary codecs through object. Do you mean make the elements themselves optional to support? Yes. If a vendor, for some reason, is unable to support the Ogg codecs, I think it's better that they (a) do not support video, than (b) they support video with proprietary codecs only. Interoperability has more value than conformace. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] require img dimensions to be correct?
Benjamin West wrote: On 3/16/07, Dean Edridge [EMAIL PROTECTED] wrote: Firstly, the chance of someone not being able to access the CSS for a web page is I'm guessing, pretty slim. img style=height: 50px; width: 50px; / Why is accessing CSS a problem? -Ben West I never said that accessing the CSS would be a problem. It was suggested earlier that in case it was, we should make it compulsory to set the width and height of images in-line. If you read my post it explains the problems of having a mix of in-line styling and styles in a CSS file, and suggests that styling should just be left in the CSS and not a mix of both. This is because, if there is no CSS available, the browser only has styling rules for some of the elements and this can sometimes be a problem. Dean Edridge
Re: [whatwg] require img dimensions to be correct?
Gareth Hay wrote: If i'm not mistaken, the idea of separation of content and style means you can use your own css, or even none at all, and still have the ability to view the content. If a page is dependent on the css, then, although in a separate file, it is fundamentally not separate at all, and we might as well just shove the css into the same html file anyway. Gareth On 16 Mar 2007, at 20:27, Benjamin West wrote: On 3/16/07, Dean Edridge [EMAIL PROTECTED] wrote: Firstly, the chance of someone not being able to access the CSS for a web page is I'm guessing, pretty slim. img style=height: 50px; width: 50px; / Why is accessing CSS a problem? -Ben West --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.11/723 - Release Date: 15/03/2007 11:27 a.m. I never proposed that a web page should be dependant on CSS, nor did I say that there shouldn't be a separation of content and style. Quite the opposite. I said that if there is no CSS available for an img tag, the browser should just display the image the best it can(and they do this quite well already, in my experience). And that this very rare occasion of CSS failure does not warrant the mandatory requirement of in-line styling of the img tag. Dean Edridge
Re: [whatwg] video element proposal
Also sprach Bjoern Hoehrmann: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED ... I personallay think play, stop and pause are better names. So, sure, don't pick the not-invented-here APIs We didn't really invent play, stop, pause. These words are printed on at least fire remote controls within easy reach of me at the moment. Do you really think using beginElement would be better? The next is compatibility. I want my content to work in as many cases as possible. It goes without saying that WHATWG video works nowhere. I think Any solution that cannot be used with the current high-market- share user agent without the need for binary plug-ins is highly unlikely to be successful. This is an issue. I don't know if will be possible to extend IEx to support video/OggTheora without Microsoft's consent. IEx has proven to be amazingly extensible in the past. We'll see. Even if it turns out to be impossible to use open codecs in IEx, people should still be encouraged to use open codecs. It is hard to find tools that take care of transcoding, they are difficult to use (lack of advise on which settings to use, crude command line interfaces, ...) and using Ogg Theora generally meant considerably reducing the quality while at the same time considerably increasing file size Compared to which formats? I believe Ogg Theora performs better than Flash. Given the video quality of some of the superhits on YouTube, I doubt this is the most important factor, though. So, where does that leave me? Ah, yes, Page xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation; MediaElement Source=example.video / /Page which, too, has the benefit of actually working in my web browser. It also happens to be much simpler than the equivalent HTML5 document. It doesn't work in my browser. What does the code do? -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
On Mar 16, 2007, at 5:29 PM, Håkon Wium Lie wrote: Compared to which formats? I believe Ogg Theora performs better than Flash. Given the video quality of some of the superhits on YouTube, I doubt this is the most important factor, though. Ogg Theora is based on the VP3 codec [1] that flash video uses. [2] The Theora site says the main differences are architectural. After reading past their techno speak, it looks like Theora MAY be able to create better video with it's encoder than Flash can at a given bit rate. If YouTube is what you are basing your comparison on, they probably have pretty crappy conversion settings to save bandwidth. I haven't done / seen any comparisons between Theora and FLV in a controlled environment. They may turn out to create fairly similar video quality at fairly similar sizes. Hopefully people don't expect super-high-quality video on the web. It's possible, but it isn't practical for most site owners. However, the quality decisions will be left up to the person encoding the video, not the player. [1] http://www.theora.org/theorafaq.html#20 [2] http://www.on2.com/technology/flix_praise/ -- Robert http://robertdot.org
Re: [whatwg] video element proposal
* Håkon Wium Lie wrote:
Do you really think using beginElement would be better?
Do you really think using two different methods to trigger playback of
svg:video and xhtml:video elements is better than using a single method?
Or what about different methods to trigger an animation or transition
effect versus multimedia content playback? Let's extend my example:
t:video id='video'
begin='play.click'
end='stop.click'
src='example.video'
t:transitionFilter begin=video.begin
type='barnDoorWipe'
dur=5 /
/t:video
pinput type='button' value='Play!' id='play' /
input type='button' value='Stop!' id='stop' /
Here the playback of the video begins when the play control is clicked,
and the barnDoorWipe transition effect on the video will begin in turn
when playback of the video begins. The begin attribute is quite flex-
ible, I might change the example so playback of the video begins auto-
matically 2 seconds after the document began:
t:video id='video'
begin='2s; play.click'
end='stop.click'
src='example.video'
or I might just drop the controls and just let it begin at 2s:
t:video begin='2s' src='example.video' /
You said 'play' might be a better name, so let's just use that for a
moment:
t:video play='2s' src='example.video' /
That does not look so much better to me, I would think this plays for
two seconds, not to start playing after two seconds have elapsed. I
also would not consider a transition effect as I've used it above to
play, and animation effects also don't really play for me. I do
think that common timing control attributes and APIs are a good thing,
and play turns out to be much less flexible than begin. So, no, I
do not agree that play is a better name, even if it was 1997 and we
would have the opportunity to pick a different name.
This is an issue. I don't know if will be possible to extend IEx to
support video/OggTheora without Microsoft's consent. IEx has proven
to be amazingly extensible in the past. We'll see.
It does not seem very likely that Microsoft will ship the codec out of
the box in the forseeable future, but sure, you can easily install more
codecs manually on the system and Internet Explorer will automatically
support them. I understand it is quite common to install a DivX codec,
for example.
Compared to which formats? I believe Ogg Theora performs better than
Flash. Given the video quality of some of the superhits on YouTube, I
doubt this is the most important factor, though.
Flash supports two codecs, the more recent one is VP6, a successor of
VP3; VP3 in turn is what Ogg Theora is based on. I would be surprised
to learn that On2 gave the superior codec away for free while it sells
the inferior one. http://www.demoscene.tv/ uses VP6 (independently of
Flash, you need a separate plugin or application) and notes in its FAQ:
Why don't you use another video codec than ON2's VP6,
that would be more cross-platform ?
We use that codec in order to provide the best quality
to the Demoscene. It has the best quality/bandwidth
especially for low bandwidth (ie a web TV) You'll find
more [on http://www.on2.com/].
That's not so much the issue in my case though, I don't have high
quality input and just have to pick my favourite codec, I have input
that is already compressed using proprietary lossy codecs, recoding
almost necessarily decreases quality, and in my cases considerably
increases file size (formats include Xvid, rmvb, mp43, and others,
most of them are at least as widely deployed as Ogg Theora).
It doesn't work in my browser. What does the code do?
It just plays the video back, where the video is positioned and scaled
as the typical media player would do (it's scaled to fit the browser
window while preserving the aspect ratio, and centered in the space
left to fill). I would have given the HTML5 equivalent but I could
not think of a simple solution for this. It would probably be some-
thing like
body, html { margin: 0; padding: 0 }
body { height: 100%; width:100% }
video {
fit: meet;
fit-position: center;
}
or
html, body { margin: 0; padding: 0 }
video {
position: center; aspect-ratio: preserve;
height: 1vh; width: 1vw;
}
along with doctype, title element, and so on. But when writing this
I started wondering why video? Isn't this really just a HTML frag-
ment with an alternate motion picture representation with optional
sound, much like img?
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Thesis draft about HTML5 conformance checking
On Wed, 14 Mar 2007, olivier Thereaux wrote: If lightweigh browsers [on mobile devices] with less tolerance of tag soup carry more weight I don't know why you think that browsers on mobile phones have less tolerance of tag soup. All the testing I have seen shows that they support tag soup as much as the desktop browsers. In fact the only browsers that I am aware of that actually has stricter (XML) parsing on mobile phones is Opera, running the same core engine as the desktop Opera browser. (See, e.g., http://simon.html5.org/articles/mobile-results but note the paragaph at the bottom of http://simon.html5.org/test/mobile/ which points out that the only pass line for a non-Opera browser is in fact a false positive, that browser in fact having even more tolerant parsing and even less support for the relevant standards.) All considered, of course I understand your point that desktop browsers *today* have a considerable influence in defining the state of the art of the web. But any standardization work, or study of the web, made under the assumption that other classes of product only have a minor importance because for the most part they follow this current balance of power and mimick the desktop browsers, is IMHO missing a good chunk of the big picture. Given that I work for a company that authors content by hand, provides a template-based Web authoring tool, runs a search engine, contributes to a browser's development, and is working on mobile device software, I assure you that I agree that all of these things should be considered (and, in the WHATWG context, are). My original point, which I still believe is true, is that the details of the _parsing model_ of search engines is not important. That is what is relevant in the context of Henri's thesis. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
