Re: [whatwg] on codecs in a 'video' tag.
At 19:28 +0200 27/03/07, Christian F.K. Schaller wrote: That is a matter of perception. Flash player which is the de-facto standard at this point provides support on at least linux, windows and Mac. We do risk that if this element is provided it could replace Flash video with something that only supports Windows/Mac like Quicktime or Windows only like Windows Media. So this could turn out to be a step backward for interoperability. And I do prefer Adobe as a neutral broker to be our 'evil overlords' if that is the choice given than someone like Microsoft or Apple which has a their operating system platforms to push and thus has an inherent interest to make life hard for Linux and Solaris users. I have a hard time believing what I am reading here. A new video tag cannot 'replace' flash support unless Adobe wishes it. Apple has neither power or desire to stop people implementing the video tag on any platform, and indeed the whole point in helping develop open standards is tyhat we want there to be broad support and interoperability. In many places, we openly encourage companies to implement standards, or we open-source software to make it easy (webkit, Darwin Streaming Server, to name but two). Our interest in multi-vendor multimedia standards is deep and long-lasting, interoperable, and very open. Really, conspiracy theories are out of place here, please. But I think this codec discussion isn't a reason to block on the discussion of how this element should work. I am glad we agree on that! I think there are many common sense decisions that can be made there which are irrelevant to whether there are a baseline set of codecs and container format defined in the spec. Agreed as well. If the end result is a specification contains requirements for Vorbis and Theora and Apple choose to not be spec compliant with Safari or Apple gets support for not including any mention of specific codecs in the spec is in some ways irrelevant to the discussion of how these elements should work. Yes. I re-iterate; we have nothing aganist the Ogg or Theora codecs; we just don't have a commercial reason to implement them, and we'd rather not have the HTML spec. try to force the issue. It just gets ugly (like the 3G exception). -- David Singer Apple Computer/QuickTime
Re: [whatwg] on codecs in a 'video' tag.
At 20:30 +0200 27/03/07, Maik Merten wrote: Actually the current audio draft requires user agents to support PCM in a .wav container (that's way stronger than what can be found in the video section). I guess your points apply there, too? Yes, technically I think we should stay clean and write an HTML specification, not a HTML+coding specification. But at least in this case, most people already implement raw audio in AVI and WAV containers. -- David Singer Apple Computer/QuickTime
Re: [whatwg] on codecs in a 'video' tag.
At 6:40 +1000 28/03/07, Silvia Pfeiffer wrote: Hi Dave, On 3/28/07, Dave Singer [EMAIL PROTECTED] wrote: We really feel that the HTML spec. should say no more about video and audio formats than it does about image formats (which is merely to give examples), and we should strive independently for audio/video convergence. We'd really like to discuss the 'meat' of the proposal -- the tags, the CSS, and so on! The whole point of the spec is to make sure implementations are compatible. Just discussing the meat and ignoring how things work out in practice may backfire. I think the example of SVG (a 'markup' language) having a codec requirement that 3GPP then had to explicitly write-out is instructive. The attempt there didn't work. I would be curious for the reasons that 3GPP has taken the requirement of vorbis out of the spec. Was that a decision based on technical reasons and could you please explain what these technical reasons were? It happened before my time, but I rather suspect that the answer is that 3GPP specifications have a set of required and recommended audio codecs (AMR, AMR wideband, AAC, AMR WB+) and that there was neither need nor desire to add to the terminal load a new codec. Someone would need to come to 3GPP and convince the membership it's in their commercial interests to require (and thus implement) a new audio codec over and above the current required and recommended set, and I doubt that anyone even tried. -- David Singer Apple Computer/QuickTime
Re: [whatwg] on codecs in a 'video' tag.
Dave Singer wrote: Yes. I re-iterate; we have nothing aganist the Ogg or Theora codecs; we just don't have a commercial reason to implement them, and we'd rather not have the HTML spec. try to force the issue. It just gets ugly (like the 3G exception). But that's circular reasoning. We don't have a commercial reason to implement Ogg or Theora, and so we'd rather not have the HTML spec give us a commercial reason. If the HTML spec said that Theora support was a SHOULD, and the other browser manufacturers were implementing it, then you would have a commercial reason. If you have nothing against Ogg or Theora, and your interest in multi-vendor multimedia standards is deep and long-lasting, interoperable, and very open, and other parties have said that a baseline codec for video needs to be open and (as far as can be discerned) patent and royalty-free, then surely your position must one one of the following: - You don't actually want a baseline codec in the spec - i.e. you don't actually have a commitment to interoperability - You do want a baseline codec in the spec, but you are happy for it to be someone other people can't implement - i.e. you don't actually have a commitment to multi-vendor multimedia standards - You do want a baseline codec in the spec, and want it to be one everyone can implement - i.e. you are happy for Ogg Theora (or another codec with a similar IP position, such as Dirac) to be it That seems to logically enumerate the possibilities. Or have I missed something? Gerv (Just in case there's any concern, I speak only for myself in this post, as someone keen to see logical debate on this issue, and not for my employer.)
Re: [whatwg] on codecs in a 'video' tag.
On Wed, 2007-03-28 at 16:57 +0900, Dave Singer wrote: At 19:28 +0200 27/03/07, Christian F.K. Schaller wrote: That is a matter of perception. Flash player which is the de-facto standard at this point provides support on at least linux, windows and Mac. We do risk that if this element is provided it could replace Flash video with something that only supports Windows/Mac like Quicktime or Windows only like Windows Media. So this could turn out to be a step backward for interoperability. And I do prefer Adobe as a neutral broker to be our 'evil overlords' if that is the choice given than someone like Microsoft or Apple which has a their operating system platforms to push and thus has an inherent interest to make life hard for Linux and Solaris users. I have a hard time believing what I am reading here. A new video tag cannot 'replace' flash support unless Adobe wishes it. I must have been more unclear here than I thought. So let me rephrase. If people today want to put video inside a web page the de-facto standard for doing so today is using flash video because a) Flash is very widely deployed so you don't need your users to download something to view the video b) its available accross all desktop platforms. c) its fairly easy to make a nice looking 'player' gui to embedd in your webpage using Flash. If the video element becomes widely deployed then a lot of content providers could decide that it is a better way to push their content than using Flash video and either switch or if they are just starting out just target this instead. Thus the market would replace the use of Flash video with this video tag, no need for Adobe's permission. So to make it clear I was not claiming that this video tag would replace flash video inside flash or whatever you managed to think I was saying. Apple has neither power or desire to stop people implementing the video tag on any platform, and indeed the whole point in helping develop open standards is tyhat we want there to be broad support and interoperability. Well so my point is that if this standard do not specify a free codec set like Theora, Vorbis or Dirac as its baseline then it will up to the vendors out there to define the standard codecs through supporting them, just like jpeg, gif and png are the de-facto standard image formats today even though they not defined in the current specs. The chance is that with this standard not specifying any codecs the most likely candidates for becoming de-facto standard is either a WMA/WMV/ASF combo or a MOV/H264/AAC combo, as those are the options that will be pushed by Apple and Microsoft. But at least if Apple is willing to go out and state that Apple will never sue anyone for trying to support the de-facto format on non-Apple platforms even if it requires Apple IPR related to the media container format and codecs that would be a good first step. In many places, we openly encourage companies to implement standards, or we open-source software to make it easy (webkit, Darwin Streaming Server, to name but two). Our interest in multi-vendor multimedia standards is deep and long-lasting, interoperable, and very open. Really, conspiracy theories are out of place here, please. Not sure I agree that assuming that Apple's business philosophy is not based upon altruism qualifies as a conspiracy theory :) Christian
Re: [whatwg] on codecs in a 'video' tag.
On 3/28/07, Christian F.K. Schaller [EMAIL PROTECTED] wrote: On Wed, 2007-03-28 at 16:57 +0900, Dave Singer wrote: At 19:28 +0200 27/03/07, Christian F.K. Schaller wrote: Apple has neither power or desire to stop people implementing the video tag on any platform, and indeed the whole point in helping develop open standards is tyhat we want there to be broad support and interoperability. Well so my point is that if this standard do not specify a free codec set like Theora, Vorbis or Dirac as its baseline then it will up to the vendors out there to define the standard codecs through supporting them, just like jpeg, gif and png are the de-facto standard image formats today even though they not defined in the current specs. The chance is that with this standard not specifying any codecs the most likely candidates for becoming de-facto standard is either a WMA/WMV/ASF combo or a MOV/H264/AAC combo, as those are the options that will be pushed by Apple and Microsoft. I disagree. It will likely result in no change at all and Flash will continue to be the format of choice for Web developers (for all the reasons you have pointed out). I think even worse: people will laugh at the creation of a video tag in HTML that has no recommendation at all about which video codec to use, since it doesn't improve on the current situation and clarify the current codec confusion. BTW: it is not unheard of that the W3C make a statement about the preferred choice of codecs. In the press release for the publication of the PNG recommendation, TBL stated We are seeing more of our Members adopt the format and are helping make it the industry standard. (see http://www.w3.org/Press/PNG-PR.en.html). That press release even states openly: The development of the PNG specification was supported by W3C and by CompuServe - original creators of the GIF format and now W3C Members - who both wished to see PNG become accepted as the new Internet standard format for lossless graphics. Regards, Silvia.
Re: [whatwg] Thesis draft about HTML5 conformance checking
On Mar 12, 2007, at 05:27, olivier Thereaux wrote: On Mar 11, 2007, at 02:15 , Henri Sivonen wrote: The draft of my master's thesis is available for commenting at: http://hsivonen.iki.fi/thesis/ Henri, congratulations on your work on the HTML conformance checker and on the Thesis. Thanks. It's been a truly informative and enlightening reading, especially the parts where you develop on the (im)possibility of using only schemas to describe conformance to the html5 specs. This is a question that has been bothering me for a long time, especially as there is only one (as of today) production-ready conformance checking tool not based on some kind (or combination) of schema- based parsers, I take it that you mean the Feed Validator? [2.3.2] I share the view of the Web that holds WebKit, Presto, Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox and IE, respectively) to be the most important browser engines. Did you have a chance to look at engines in authoring tools? I didn't investigate them beyond mentioning three authoring tools that have a RELAX NG-driven auto-completion feature. What type of parser do NVU, Amaya, golive etc work on? For authoring tools, the key thing is that their serializers work with browser parsers. The details of how authoring tools recovers from bad markup is not as crucial as recovery in browsers because with authoring tools the author has a chance review the recovery result. How about parsing engines for search engine robots? These are probably as important, if not more as some of the browser engines in defining the generic engine for the web today. Search engines are secretive about what they do, but I would assume that they'd want be compatible with browsers in order to fight SEO cloaking. [4.1] The W3C Validator sticks strictly to the SGML validity formalism. It is often argued that it would be inappropriate for a program to be called a “validator” unless it checks exactly for validity in the SGML sense of the word – nothing more, nothing less. That's very true, there's a strong reluctance from part of the validator user community tool to do anything else than formal validation, mostly (?) out of fear that it would eventually make the term of validation meaningless. The only thing the validator does beyond DTD validation are the preparse checks on encoding, presence of doctype, media type etc. ISO and the W3C have already expanded the notion of validation to cover schema languages other than DTDs. In colloquial usage validation is already understood to mean checking in general. The notion of a schema could be detached from a schema language to be be an abstract partitioning of the set of possible XML documents into two disjoint sets: valid and invalid. Calling the process of deciding which set a given document instance belongs into validation would give a formal definition that matched the colloquial usage. I do sympathize with Hixie's reluctance to call HTML5 conformance checking HTML5 validation, though. Calling it conformance checking makes sure that others don't have a claim on defining what it means. Fighting the colloquial usage will probably be futile, though, outside spec lawyerism. [6.1.3] Erroneous Source Is Not Shown The error messages do not show the erroneous markup. For this reason it is unnecessarily hard for the user to see where the problem is. Was this by lack of time? Yes. Showing the source code based on the SAX-reported line and column numbers is useful but it isn't novel enough or central enough to proving the feasibility of the chosen implementation approach for it to delay the publication of the thesis. Observing the thesis projects of my friends who started before me has taught me that it is a mistake to promise a complete software product as a precondition for the completion of the thesis. Software always has one more bug to fix or one more feature to add. On the other hand, as far as the academic requirements go, one could even write a thesis explaining why a project failed. Did you have a look at existing implementations? On this particular point, not yet. Oh I see [ 8.10 Showing the Erroneous Source Markup] as future work. If you're looking for a decent, though by no means perfect, implementation, look for sub truncate_line in http://dev.w3.org/cvsweb/~checkout~/validator/httpd/cgi-bin/check Thanks. I'll keep this in mind. [8.1] Even though the software developed in this project is Free Software / Open Source, it has not been developed in a way that would make it easily approachable to potential contributors. Perhaps the most pressing need for change in order to move the software forward after the completion of this thesis is moving the software to a public version control system and making building and deploying the software easy. Making it available on a more open-sourcey
Re: [whatwg] on codecs in a 'video' tag.
On Mar 27, 2007, at 23:40, Silvia Pfeiffer wrote: I would be curious for the reasons that 3GPP has taken the requirement of vorbis out of the spec. Was that a decision based on technical reasons and could you please explain what these technical reasons were? First: I don't know about what goes on inside 3GPP. However, about one 3GPP stakeholder with significant clout: When Nokia guys show up Open Source meetings, the FAQ about Maemo is why they don't ship Vorbis support. The manager of the Maemo operation has said that Nokia is afraid of Vorbis having some Fraunhofer-owned stuff in it after all, so Nokia does not want to ship Vorbis support until their own people have vetted Vorbis for patent issues. It is entirely unclear to me if they are actively vetting it. That's the stated reason. In addition, it might be relevant that *all* the companies that have patents in the AAC patent portfolio are 3GPP members. If everyone used Vorbis, the value of the AAC patents would be diluted both in terms of licensing revenue and as MAD warheads mounted on defensive patent missiles. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] on codecs in a 'video' tag.
Henri Sivonen schrieb: When Nokia guys show up Open Source meetings, the FAQ about Maemo is why they don't ship Vorbis support. The manager of the Maemo operation has said that Nokia is afraid of Vorbis having some Fraunhofer-owned stuff in it after all, so Nokia does not want to ship Vorbis support until their own people have vetted Vorbis for patent issues. It is entirely unclear to me if they are actively vetting it. I guess a very old story (2001) is again doing its damage here: http://news.com.com/MP3+rival+attempts+to+shield+developers/2100-1023_3-253253.html There a Thomson guy was quoted as saying: We continue to follow Ogg Vorbis, said Henri Linde, vice president of new business at Thomson . I would say we continue to have some thoughts that it is very likely that they are using some of the Thomson/Fraunhofer solutions in the project...But it's not part of our daily concern. What is missing is that that spokesperson was led to believe that Vorbis was a reworked MP3 with a few changes here and there to work around patents (I can't quote sources, but I think I read that on the Vorbis mailing list). It is not. To this day neither Thomson nor Fraunhofer made any patent claims and they did not issue any more statements concerning the patent status of Vorbis, but still this old old old story is doing its damage. Maik Merten
Re: [whatwg] Apply script.defer to internal scripts
On Tue, 27 Mar 2007 21:49:41 +0200, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Consider the following example:
script type=text/javascript defer
function ha8validate(p5event) { return true }
document.forms[0].onsubmit = ha8validate
/script
The script embedded here is so short and specific that it makes no sense
relaying it to an external location; however, if the script is not
deferred, the script fails with an exception at run time because the
document body is not constructed yet.
What's wrong with simply placing it after /body?
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] video element feedback
Laurens Holst wrote: As said, I tried a few things with embedding an image, video and SVG with the object tag: ... First of all, one annoying thing is that you have to provide sizes, otherwise the object will not be visible. At least in Mozilla, this is false for images. It should become false for SVG by Gecko 1.9, hopefully. The issue of sizing of object that's rendered via a plug-in remains in Gecko, due to limitations in the plug-in API. But that's not a fundamental issue with object itself. In all browsers the object is an inline replaced element. Unless styled to be a block, in which case it's a block-level replaced element. ;) Also, in reality everybody adds a two big attributes for Internet Explorer’s plugin finder, and an embed tag inside the object for Mozilla’s plugin finder (which still only works with embed and not object). Sorry, that's false. Plug-ins work fine with object in Mozilla, _unless_ you use a classid attribute with a value that is an ActiveX component ID. If you do that, Mozilla will fall back, since it doesn't support ActiveX plug-ins. Now the problem is that the _only_ way IE supports plug-ins via object is if they're ActiveX and the right component ID is specified. It doesn't support dispatch based on MIME type. So you get the nesting you mentioned. Oh, and IE does something broken if you nest object inside object; otherwise authors could use object inside object instead of embed inside object as they do now. However, if the image specifies dimensions, in Firefox they override the object dimensions and you get scroll bars on the object This is a bug, hopefully to be fixed for Gecko 1.9. -Boris
Re: [whatwg] on codecs in a 'video' tag.
At 18:14 +0300 28/03/07, Henri Sivonen wrote: On Mar 27, 2007, at 23:40, Silvia Pfeiffer wrote: I would be curious for the reasons that 3GPP has taken the requirement of vorbis out of the spec. Was that a decision based on technical reasons and could you please explain what these technical reasons were? First: I don't know about what goes on inside 3GPP. However, about one 3GPP stakeholder with significant clout: When Nokia guys show up Open Source meetings, the FAQ about Maemo is why they don't ship Vorbis support. The manager of the Maemo operation has said that Nokia is afraid of Vorbis having some Fraunhofer-owned stuff in it after all, so Nokia does not want to ship Vorbis support until their own people have vetted Vorbis for patent issues. It is entirely unclear to me if they are actively vetting it. That's the stated reason. In addition, it might be relevant that *all* the companies that have patents in the AAC patent portfolio are 3GPP members. If everyone used Vorbis, the value of the AAC patents would be diluted both in terms of licensing revenue and as MAD warheads mounted on defensive patent missiles. I think the first reason is more likely. The dominant players in 3GPP are network operators and equipment vendors, and the AAC patent owners are (to my impression) very much both a minority and less powerful. The AAC patent owners are, for the most part, organizations that do RD for license -- that's their business, and it's perfectly respectable. They develop good technology and understand that without licenses they don't have a business. Just my personal opinion, you understand; I don't see anything wrong with this business model, and indeed I think it benefits the industry. (There are other business models around patents which we need not elaborate, which I dare say many of us would have a harder time defending). -- David Singer Apple Computer/QuickTime
Re: [whatwg] on codecs in a 'video' tag.
At 9:48 +0100 28/03/07, Gervase Markham wrote: Dave Singer wrote: Yes. I re-iterate; we have nothing aganist the Ogg or Theora codecs; we just don't have a commercial reason to implement them, and we'd rather not have the HTML spec. try to force the issue. It just gets ugly (like the 3G exception). But that's circular reasoning. We don't have a commercial reason to implement Ogg or Theora, and so we'd rather not have the HTML spec give us a commercial reason. No, writing it into the HTML specification is not a commercial reason. That's an attempt to force the issue by fiat. If the HTML spec said that Theora support was a SHOULD, and the other browser manufacturers were implementing it, then you would have a commercial reason. No matter what the spec. says, if broad support became a reality, then yes, it may be in our commercial interests. And at that point there would be many companies using the codec in a money-making way, with 'pockets', and we'd be clearer about the likelihood of IPR challenges. If you have nothing against Ogg or Theora, and your interest in multi-vendor multimedia standards is deep and long-lasting, interoperable, and very open, and other parties have said that a baseline codec for video needs to be open and (as far as can be discerned) patent and royalty-free, then surely your position must one one of the following: - You don't actually want a baseline codec in the spec - i.e. you don't actually have a commitment to interoperability we have a strong commitment to interoperability in each spec. on its own right - You do want a baseline codec in the spec, but you are happy for it to be someone other people can't implement - i.e. you don't actually have a commitment to multi-vendor multimedia standards anyone *can* implement the codecs we implement; they may choose not to, for commercial reasons (e.g. they don't like the license) - You do want a baseline codec in the spec, and want it to be one everyone can implement - i.e. you are happy for Ogg Theora (or another codec with a similar IP position, such as Dirac) to be it Until someone starts using the Ogg family to make money, and in such a way that any possible IPR owners consider it in their business interests to start enforcing their IPR, the situation remains in question. We have nothing against these codecs, but we are not currently feeling like being the guinea-pig... How about - we'd an HTML specification which is clear and interoperable on the HTML level, and is in a similar position to the img tag on what may be embedded (it mentions only examples) -- David Singer Apple Computer/QuickTime
Re: [whatwg] Video proposals
Laurens Holst wrote: One of the main reasons that object is still broken on the web and why embed needs to be used is Mozilla; their plugin finder doesn’t work with object. I'm sorry, but that's false. See my other post (under Re: video element feedback) and http://developer.mozilla.org/en/docs/Using_the_Right_Markup_to_Invoke_Plugins for details. -Boris
