Re: [whatwg] video element proposal
On 3/1/07, Lachlan Hunt [EMAIL PROTECTED] wrote: Shadow2531 wrote: On 2/28/07, Anne van Kesteren [EMAIL PROTECTED] 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: I think it'd be cool if the video element *just* supported theora. Mandating support for a single specific video format like Theora would be like requiring browsers to only support PNG for images. As Martin said, Perhaps ogg can be the format required to conform. Then other types can be supported through whatever means (native or mapping to a plugin like wmp etc.) If it supports whatever the browser wants to implement, we'd have to do like the following I think. video src=test.wmv video src=test.mpg video src=test.ogg I give up /video /video /video Or simply use video src=testembed src=test!-- fallback --/video Yes, that also. And use server-side content negotiation to determine the best one to send. The browser could send along the list of supported MIME types in it's accept header for video formats, like: Accept: application/ogg, video/mpeg, video/mp4, application/mp4, video/quicktime, */*;q=0.1 Sounds good. -- burnout426
Re: [whatwg] [html5] %Pixels; unnecessary
On Thu, 01 Mar 2007 03:11:06 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 15 Apr 2005, David Håsäther wrote: The Pixels parameter entity replacement text should be NUMBER instead of CDATA since the comment says integer representing length in pixels. Also, the entity is only used once in the DTD (for the BORDER attribute of the TABLE element type) so it could as well be: border NUMBER #IMPLIED -- controls frame width around table -- Given that HTML5 has no DTD, this is presumably not an issue. Yes, I didn't know that at the time, and there was a DTD lying around somewhere IIRC. -- David Håsäther
Re: [whatwg] [html5] %Pixels; unnecessary
On Mar 1, 2007, at 12:21, David Håsäther wrote: Yes, I didn't know that at the time, and there was a DTD lying around somewhere IIRC. I think you mean http://syntax.whatwg.org/ . It is abandoned. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] video element proposal
On Thu, 01 Mar 2007 06:27:45 +0100, Shadow2531 [EMAIL PROTECTED] 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: I think it'd be cool if the video element *just* supported theora. It probably doesn't make much sense to impose such restrictions. If it supports whatever the browser wants to implement, we'd have to do like the following I think. video src=test.wmv video src=test.mpg video src=test.ogg I give up /video /video /video The intentention of the draft is that this is allowed. It might not be specified entirely correct though. Hence the proposal status :-) You probably want the video element to be really, really basic, but I don't think it should be. It needs to have some features (eventually). These are just some of the things *I* might like. [...] That's one of the reasons a dedicated element is better than reusing the object element. All the new video specific APIs would otherwise have to be defined for all possible things the object element can represent (images, nested browser context, video, audio, plugins, etc.). Given that the object element is already a nightmare for implementors... I assume you want the width and height attributes to be used only for specifying the original width and height the video was made at, and css should be used to set the width and height to a % or px etc.? Yeah, maybe. I was thinking about something along those lines, but I couldn't really figure out how it would work. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video element proposal
On Mar 1, 2007, at 08:26, Lachlan Hunt wrote: The browser could send along the list of supported MIME types in it's accept header for video formats, like: Accept: application/ogg, video/mpeg, video/mp4, application/mp4, video/quicktime, */*;q=0.1 Content negotiation is like a box of chocolates. You never know what you are going to GET. :-) The problem in this case is that the media types map roughly to the container formats. However, the codecs are what really count. For example, MPEG-4 Simple Profile, MPEG-4 Advanced Simple Profile and H. 264 all live in the video/mp4 container. However, support for these codecs and their zillion subprofiles varies. (Yet another example why optional profiles in spec are bad for interop. The profiling of the MPEG-4 video stuff is worse than any Web spec Mobile Profile.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] video element proposal
Anne van Kesteren wrote: I'm not sure what fallback has to do with interoperability. Fallback allows text mode browsers or video plugins that do not support a given codec to access the essential information. Hence it makes for a form of communication interoperable with a wide range of devices. (i.e. it doesn't make the video interoperable, it makes the website interoperable.) It doesn't seem wise to mandate a particular UI. Sorry, I've obviously been unclear. I don't mean tell UAs what UI to use, I mean tell them what minimal functionality to expose (e.g. UAs should allow users to pause video.). /How/ they do that (play button, mouse gestures, telepathy, etc.) should be up to them entirely (subject to UAAG considerations of course). User agents are free of course to expose the functionality of play(), pause() and stop() in some way, in my opinion. Isn't it important that content authors know whether there will or won't be an automatic UI provided, so that end users don't end up being presented with two (possibly conflicting, certainly confusing) UIs? That's why I suggested using an attribute to control For most use-cases, I suspect the minimum functionality would not only be more than enough, but superior than anything the content producer would put together. This would actually make it a lot easier for ordinary HTML authors to put video on the web. If we could mandate captioning and audio description exposure by UAs it would make putting video on the web in an accessible manner much easier too. Which would be great, as it currently seems to be a somewhat complicated task. -- Benjamin Hawkes-Lewis -- Benjamin Hawkes-Lewis
Re: [whatwg] video element proposal
Also sprach Bjoern Hoehrmann: 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() May I suggest Opera does not implement features that are incompatible with SMIL, the SMIL implementation in Internet Explorer, and SVG for no extraordinarily good reason? I think we want to make video a first class citizen of the web. That means, IMHO, that there must be a simple way to add video to HTML pages. I don't think one shoulr rely on other languages for this, although I'm perfectly happy supporting those other languages as well. Part of the reason why we could to this so quickly is the work we have done on SVG. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
Also sprach Shadow2531: I think it'd be cool if the video element *just* supported theora. It's an interesting proposal. Traditionally, HTML/CSS hasn't said anything about which image/icon formats to support. Given, however, that (a) our ultimate goal is interoperability and that (b) many video formats are impossible to support on all devices (mostly due to legal issue), I think we should consider your proposal. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
On 1 Mar 2007, at 11:56, Anne van Kesteren wrote: That's one of the reasons a dedicated element is better than reusing the object element. All the new video specific APIs would otherwise have to be defined for all possible things the object element can represent (images, nested browser context, video, audio, plugins, etc.). Given that the object element is already a nightmare for implementors... Would I be right in thinking of video as inheriting from/a subclass of object then, to draw an OOP analogy. Or would they be more like siblings? Secondly, I think of ‘video’ as a sequence of visual frames with no audio. I presume you mean something more akin to what I call a movie container, with a video track, multiple audio dubbing tracks in different languages, subtitles or graphical overlays, c. If so, do you think the name could be altered to reflect this? Thirdly, are you intending for there to be audio counterpart? I assume you want the width and height attributes to be used only for specifying the original width and height the video was made at, and css should be used to set the width and height to a % or px etc.? Yeah, maybe. I was thinking about something along those lines, but I couldn't really figure out how it would work. Video streams/files already contain their native pixel dimensions, and as Henri said, you never know what you're going to GET. A better attribute would be scale which takes a floating point value, defaulting to 1.0 (should probably have a corresponding CSS element too, which we could apply to other things that have native dimensions like still images). This would work well with max-/min-width. 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. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element proposal
Håkon Wium Lie wrote: I think we want to make video a first class citizen of the web. Arguably it already is. It just hasn't been implemented in a easy-to-author, UA-interoperable, or end-user accessible fashion. That means, IMHO, that there must be a simple way to add video to HTML pages. How is that incompatible with the use of SMIL? It seems to me adding video to web pages is complicated because of: 1) Poor support for a wide variety of formats. 2) No guaranteed end-user capability to play, pause, rewind, etc. (so that authors must build such interfaces themselves with JS). 3) Lack of guidance for transcripting/subtitling/captioning/audio description (Joe Clark's working in this area) and poor implementations of technology for such features. 4) Different browsers support different techniques for embedding content in text/html (e.g. embed vs object, ActiveX for MIME handling, the Eolas problems in IE). As it stands, the video element proposal is interesting, but it doesn't solve any of these problems for current or future UAs. If we require HTML5 UAs to support Theora and to expose a minimal subset of functionality, then we could conceivably fix 1) and 2) over the next few years (IE/WMP being the major barriers here). Whether we can fix 4) seems to be partly dependent on American courts. Mandating support for SMIL should help with 3). It may be mandating support for Ogg would also help, but there seems to be some doubt (e.g. from a BBC researcher) as to whether Ogg is really suitable for multiple audio video streams in the same file for things like audio description and multi-language subtitles, and alternate audio tracks: http://lists.xiph.org/pipermail/xiph-rtp/2007-January/000461.html I don't think one shoulr rely on other languages for this, In reality, aren't you always relying on a language /of some sort/ (e.g. a wrapper language for video)? It's not like you're trying to express the video data within HTML. Part of the reason why we could to this so quickly is the work we have done on SVG. IANAL and don't know Opera's licencing policy anyway, but if it makes any difference there is a SMIL 2.1 player whose source code is available for use by third parties under the LGPL: http://www.cwi.nl/projects/Ambulant/FAQ.html -- Benjamin Hawkes-Lewis
Re: [whatwg] video element proposal
Anne van Kesteren [EMAIL PROTECTED] wrote: Opera has some internal expiremental builds with an implementation of a video element. I've observed widespread frustration amongst authors on how to offer audio and/or video on web pages. Quite a few have started using Flash since apparently it takes some of the pain out of doing so. That seems to warrant looking at a solution that doesn't use a proprietary technology like Flash. When the src= attribute is set, the user agent must immediately begin to download the specified resource, unless the user agent cannot support videos, or its support for videos has been disabled. As soon as enough data is received the user agent should start decoding the video. This means that play() and other methods can already be used before the resource is downloaded completely. I strongly dislike audio and/or video that automatically downloads and starts playing automatically, so much so that I've disabled media player plugins altogether. Both audio and video files are often considerable in size. I don't want my web browser to start making noise unless I've explicitly chosen to play audio, this should not be the result of simply loading a web page. I'd favour a spec requirement that a UA must offer users a configuration option not to automatically download and start audio and/or video and let the user decide first. Another current common frustration amongst authors is how to get file based media files to play before they've been fully downloaded. This is currently achieved by using text based redirector files containing the url to the actual media file, but these redirector formats have only been defined for a limited number of media formats. That would suggest that a UA could by default employ progressive downloading. Issue: should we very much like the img element just ignore 404 errors and the Content-Type header? And use the file extension or content sniffing? Using file extensions doesn't seem possible given the existence of wrapper formats. I imagine that a browser that can handle JPEG, PNG and GIF can use content sniffing and depending on the outcome feed it to the right decoder. I'm having difficulty imagining how that would work with video. Wouldn't that require a UA to at least be able to open the file headers of the many video file formats out there to sniff what media format is actually inside them before it can decide where to send the data? Issue: height / width Currently an issue with supplying height and width for video content embedded with the object element is that the supplied width and height includes the chrome and UI controls of the embedded player. That creates problems for authors who often don't know the size of those elements in advance, it may depend on the player and/or player skin they use. Scaling video can be very GPU intensive, so it would be helpful if there was a way to ensure that video can play in it's native size, whilst at the same time knowing in advance what room to reserve in the flow for the media and any player chrome. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] video element proposal
Spartanicus wrote: Another current common frustration amongst authors is how to get file based media files to play before they've been fully downloaded. This is currently achieved by using text based redirector files containing the url to the actual media file, but these redirector formats have only been defined for a limited number of media formats. That would suggest that a UA could by default employ progressive downloading. I was thinking about this the other day. There seems to be no way of distinguishing the case where you want to hand the data from a URL to an external program (e.g. Word files), and you want to hand the URL itself to an external program (e.g. streaming audio). Not sure if a solution to this is in scope for WHAT-WG... Currently an issue with supplying height and width for video content embedded with the object element is that the supplied width and height includes the chrome and UI controls of the embedded player. That creates problems for authors who often don't know the size of those elements in advance, it may depend on the player and/or player skin they use. Scaling video can be very GPU intensive, so it would be helpful if there was a way to ensure that video can play in it's native size, whilst at the same time knowing in advance what room to reserve in the flow for the media and any player chrome. That's the equivalent of: yvideo + ygui = ytotal where yvideo is defined in advance by the video file, and ytotal needs to be known in advance. The only way that's possible is for ygui to be fixed across all platforms etc. Gerv
Re: [whatwg] OBJECT as a link target?
On Mon, 13 Jun 2005, Hallvord R M Steen wrote: often a page needs to interact with a plugin and tell it to load another file. Today this is of course done with JavaScript, which is difficult because most plugins have different JS interfaces, and there are also differences between the plugins' ActiveX based interfaces in IE and the NPAPI plugin ones. Hence I thought it would be a great simplification if we could do the following: object type=application/x-shockwave-flash id=myMedia data=init.swf /object a href=animation1.swf target=myMedia load movie 1 /a A compliant UA would detect that the target was a plugin and not a window, and call the plugin's NPP_NewStream method (I think, I don't know NPAPI well at all) to notify it of the new file to load. I think backwards compatibility is pretty good since a non-compliant UA would open a new window for the new file. I think this is an interesting idea, though I don't know how much demand there is for this. I would recommend following this up with the group documenting the NPAPI. The HTML language basically already supports what you're asking for; although most UAs would implement it by launching a new instance of the plugin, it isn't be a requirement IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Ideas regarding Web Applications 1.0
- Original Message - From: Ian Hickson [EMAIL PROTECTED] To: Matthew Raymond [EMAIL PROTECTED] Cc: WHAT WG List [EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 9:38 PM Subject: Re: [whatwg] Ideas regarding Web Applications 1.0 On Tue, 23 Nov 2004, Matthew Raymond wrote: I'd rather not depend on XBL to do something as basic and common as tabs. It's entirely possible that some WA1 clients may not support XBL. I'd prefer that we be able to implement tabs with little more than HTML and CSS. I'm not convinced tabs are as simple as you say. That said, if I could somehow link navigational lists to switch: | div id=tabbox | nl orientation=horizontal | hContents/h | lia href=#introductionIntroduction/a/li | lia href=#conformanceConformance/a/li | lia href=#referencesReferences/a/li | /nl | | switch | section id=introduction |pIntroduction contents.../p | /section | section id=conformance |pConformance contents.../p | /section | section id=references |pReferences contents.../p | /section | /switch | /div The above markup is fairly obvious. The nl element creates a serious of blocks that can be styled as buttons or tabs. These tabs contain hyperlinks to sections in the switch element. When the hyperlinks are clicked, the respective section is made active. I'm definitely not convinced that it is a _semantic_ of that document that the three sections are mutually exclusive. Why would I never want to compare the references and the conformance section side-by-side? Yeah. At the moment we've just dropped the tab feature. I think a good argument can be made for saying it's presentational, and I didn't see any good proposals for how to put it into markup. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Tabs are not more than styled group of button type=radio (tabs per se) binded with some visibility attribute of correspondent panels. Ideologically tab/panel pair is close to label for=... and correspondent input - click on first causes some event happen on second. The simplest way to define it is to use something like: button type=radio name=tabs bind=:checked; $(#panel1):expanded First tab /button button type=radio name=tabs bind=:checked; $(#panel2):expandedSecond tab/button Where 'bind' connects :checked state flag of the button with :expanded state of correspondend panel so CSS will be able to style it appropriately. Tabs need to be presented in wide range of ways so I think to have label of the tab combined with the panel in single DOM element/entity will simply do not work. There are also other cases when state of 'master' element (frequently it has radio button behavior) needs to be mapped on state of another 'slave' element so to have some simple binding mechanism will be a good thing. As an example, collapsible list: http://terrainformatica.com/htmlayout/images/animation-slide-bar.jpg can also be defined by such simple 'bind' attribute. Ability to style buttons + simple bind(what; with-what) will cover surprisingly many cases implemented now by scripts only. Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] video element proposal
On 3/1/07, Håkon Wium Lie [EMAIL PROTECTED] wrote: Also sprach Shadow2531: I think it'd be cool if the video element *just* supported theora. It's an interesting proposal. Traditionally, HTML/CSS hasn't said anything about which image/icon formats to support. Given, however, that (a) our ultimate goal is interoperability and that (b) many video formats are impossible to support on all devices (mostly due to legal issue), I think we should consider your proposal. Yes, those are the main reasons for my suggestion. I realize that just supporting one format like theora for example means that a lot of the current content out there couldn't be handled by the video element. However, the video element would be new and with it new content. It doesn't necessarily need to be compatible with everything (as it'd be a new element). I don't think the video element can replace OBJECT and its wide (but messy) handling of different things. I think VIDEO should be specific and avoid all or most of the problems object has. As you said, it'd be untraditional, but if the format is not specified, I can see one browser's video element only supporting mpeg and another only supporting wmv and another only supporting ogg and other only support .flv etc. With that said, if a browser can make its video element support as many formats as it wants (which I believe most people want), I do believe that its essential that there be a base format that must (or strongly should) be supported. That base format might be theora or something else. Or, do most feel the video element should just support whatever the browser wants and leave it at that? -- burnout426
