From mjs at apple.com Mon Jun 1 00:09:45 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 01 Jun 2009 00:09:45 -0700 Subject: [whatwg] getImageData/putImageData comments In-Reply-To: <4A233509.9040806@mit.edu> References: <4A233509.9040806@mit.edu> Message-ID: On May 31, 2009, at 6:55 PM, Boris Zbarsky wrote: > > 3) It's not clear to me why imagedata actually exposes device > pixels, > nor is it clear to me how this is supposed to work if the same > document is being rendered to multiple devices. Is a UA allowed > to have a higher internal resolution for a canvas (in device > pixels) > and then sample when painting to the device? This might well be > desirable if the UA expects the canvas to be scaled; it can well > reduce scaling artifacts in that situation. It doesn't seem > reasonable, to me, to expose such super-sampling via imageData; > it's entirely an optimization detail. > Worse yet, the current setup means that a script that tries > createImageData, fill in the pixels, and then paint it to the > canvas, needs to fill different numbers of pixels depending on the > output device. I fully expect script authors to get this very very > wrong, since it's such non-intuitive behavior. It would make more > sense to just have the script work entirely in CSS pixels; if it > wishes to create a higher-resolution image it can create a canvas > with bigger dimensions (and scale its actual display via setting > its width and height CSS properties). In some environments, a CSS pixel may be more than one device pixel. In this case, getImageData followed by putImageData will lose resolution. In other cases, a CSS pixel may be a non-integer number of device pixels. To see an example of a browser running in this environment, on Mac OS X launch Quartz Debug, open the User Interface Resolution window, and try setting the scale factor to 1.5 or 2.0. In this case in Safari, the CSS px unit will respect the scale factor, but the canvas backing store will still be in device pixels so users get the benefit of the higher resolution. (Currently Apple doesn't ship any systems that use a non-1.0 UI scale factor by default.) The current design makes it possible to write code that will do the right thing in a scaled UI. It also makes it easy to do the wrong thing and copy only a fraction of the area intended. The alternate design of using CSS pixels would make it impossible to get right, but the failure mode would just be to lose resolution. Regards, Maciej From mjs at apple.com Mon Jun 1 00:13:04 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Mon, 01 Jun 2009 00:13:04 -0700 Subject: [whatwg] getImageData/putImageData comments In-Reply-To: <11e306600905312108t34eb1879q4ccb583c3195c8a8@mail.gmail.com> References: <4A233509.9040806@mit.edu> <5A5825D2-9F11-428D-8EB1-CF16C8E3E8C9@apple.com> <4A234F54.1050800@mit.edu> <11e306600905312108t34eb1879q4ccb583c3195c8a8@mail.gmail.com> Message-ID: <9B752EDD-5B24-41F5-B905-669738B2380B@apple.com> On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote: > > Here are a couple of relevant threads: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html > Then there was a discussion on #whatwg more recently. > http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-263 > > So far it seems the data supports the hypothesis that authors expect > getImageData to return 1 image pixel per CSS pixel and their scripts > break when that's not true. That won't change until authors all have > high-dpi screens. I'm not surprised. On the other hand, if we use CSS pixels, it won't be possible for authors to get it right, even if they do have high-dpi screens. It might be wise to have separate APIs (or a distinguishing parameter) to indicate whether you want scaled or true resolution. That way, unaware code gets a resolution loss, but aware code can do the right thing. I guess you suggested something like that in the IRC conversation you cited. Regards, Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Mon Jun 1 00:36:04 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Mon, 1 Jun 2009 19:36:04 +1200 Subject: [whatwg] getImageData/putImageData comments In-Reply-To: <9B752EDD-5B24-41F5-B905-669738B2380B@apple.com> References: <4A233509.9040806@mit.edu> <5A5825D2-9F11-428D-8EB1-CF16C8E3E8C9@apple.com> <4A234F54.1050800@mit.edu> <11e306600905312108t34eb1879q4ccb583c3195c8a8@mail.gmail.com> <9B752EDD-5B24-41F5-B905-669738B2380B@apple.com> Message-ID: <11e306600906010036mb4258f8n2b3ca6b3d7e4a4ad@mail.gmail.com> On Mon, Jun 1, 2009 at 7:13 PM, Maciej Stachowiak wrote: > > On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote: > > Here are a couple of relevant threads: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html > Then there was a discussion on #whatwg more recently. > http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-263 > > So far it seems the data supports the hypothesis that authors expect > getImageData to return 1 image pixel per CSS pixel and their scripts break > when that's not true. That won't change until authors all have high-dpi > screens. > > > I'm not surprised. On the other hand, if we use CSS pixels, it won't be > possible for authors to get it right, even if they do have high-dpi screens. > It might be wise to have separate APIs (or a distinguishing parameter) to > indicate whether you want scaled or true resolution. That way, unaware code > gets a resolution loss, but aware code can do the right thing. I guess you > suggested something like that in the IRC conversation you cited. > Yes. Why don't we just redefine getImageData right now to have the behaviour authors are depending on, since we will likely be forced into that anyway? I'm not sure whether we should define the new API right now (getHighResolutionImageData?), or wait until CSS-to-device-pixel-ratios != 1 are common enough that authors are likely to use the new API correctly. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonp at opera.com Mon Jun 1 02:56:26 2009 From: simonp at opera.com (Simon Pieters) Date: Mon, 01 Jun 2009 11:56:26 +0200 Subject: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate. In-Reply-To: <20090530034920.D1C441389F2@hixie.dreamhostps.com> References: <20090530034920.D1C441389F2@hixie.dreamhostps.com> Message-ID: On Sat, 30 May 2009 05:49:20 +0200, wrote: > Author: ianh > Date: 2009-05-29 20:49:18 -0700 (Fri, 29 May 2009) > New Revision: 3151 > > Modified: > index > source > Log: > [] (0) Try to make the magic margin collapsing rule more accurate. > Modified: source > =================================================================== > --- source 2009-05-30 02:33:07 UTC (rev 3150) > +++ source 2009-05-30 03:49:18 UTC (rev 3151) > @@ -80436,9 +80436,10 @@ > form { margin-bottom: 1em; } >

When a Document is in quirks mode, > - margins on HTML elements at the top or bottom of the > - initial containing block, or the top of bottom of td or > - th elements, are expected to be collapsed to zero.

> + margins on HTML elements at the top or bottom of > + the body element, or the top of bottom of > + td or th elements, are expected to be > + collapsed to zero.

>

Alignment

Please change "the body element" to "body elements". -- Simon Pieters Opera Software From bzbarsky at MIT.EDU Mon Jun 1 06:40:24 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 01 Jun 2009 09:40:24 -0400 Subject: [whatwg] getImageData/putImageData comments In-Reply-To: References: <4A233509.9040806@mit.edu> Message-ID: <4A23DA48.2010603@mit.edu> Maciej Stachowiak wrote: > In some environments, a CSS pixel may be more than one device pixel. Yes, I'm well aware. > In this case, getImageData followed by putImageData will lose resolution. Right. I did mention that in my reply to Oliver. It seems that there are two significantly different use cases for putImageData. One is that of doing getImageData on a canvas followed by some manipulation of the existing pixel data. In this case I agree that: > The current design makes it possible to write code that will do the > right thing in a scaled UI. It also makes it easy to do the wrong thing > and copy only a fraction of the area intended. I'm not quite sure what I think of the tradeoffs here yet, and I need to go read through the old discussions, but I do appreciate the problems. The other use case is doing createImageData, followed by filling in the pixels, followed by putImageData. In this case, there is no quality loss of existing data involved, but the current design still makes it easy to do the wrong thing... In fact, it makes it much more difficult than it should be to do the right thing for a typical web developer. Perhaps the two use cases should use a different put API and incompatible imagedata objects and actually use different coordinate spaces? It'd be somewhat confusing, but the use cases for the two seem to me to be sufficiently different that it might be warranted... -Boris From bzbarsky at MIT.EDU Mon Jun 1 07:00:49 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 01 Jun 2009 10:00:49 -0400 Subject: [whatwg] getImageData/putImageData comments In-Reply-To: <4A23DA48.2010603@mit.edu> References: <4A233509.9040806@mit.edu> <4A23DA48.2010603@mit.edu> Message-ID: <4A23DF11.6010903@mit.edu> Boris Zbarsky wrote: > The other use case is doing createImageData, followed by filling in the > pixels, followed by putImageData. I just saw the example in the spec that does just this, but bases the values it puts in on numbers it gets out of getImageData. For that case you would of course want a blank imagedata that matches what getImageData hands out. I still think that we need a better "I have some externally-derived pixel data I'd like to just stick in this canvas" API here. fillRect() has terrible performance characteristics (as has been brought up many times before), and the current imagedata design makes it very difficult to use it correctly for this purpose... -Boris From ian at hixie.ch Mon Jun 1 12:09:56 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 1 Jun 2009 19:09:56 +0000 (UTC) Subject: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate. In-Reply-To: References: <20090530034920.D1C441389F2@hixie.dreamhostps.com> Message-ID: On Mon, 1 Jun 2009, Simon Pieters wrote: > > > Modified: source > > =================================================================== > > --- source 2009-05-30 02:33:07 UTC (rev 3150) > > +++ source 2009-05-30 03:49:18 UTC (rev 3151) > > @@ -80436,9 +80436,10 @@ > > form { margin-bottom: 1em; } > >

When a Document is in quirks mode, > > - margins on HTML elements at the top or bottom of the > > - initial containing block, or the top of bottom of td or > > - th elements, are expected to be collapsed to zero.

> > + margins on HTML elements at the top or bottom of > > + the body element, or the top of bottom of > > + td or th elements, are expected to be > > + collapsed to zero.

> >

Alignment

> > Please change "the body element" to "body elements". Really? Do you have a test case demonstrating this? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From simonp at opera.com Mon Jun 1 12:26:34 2009 From: simonp at opera.com (Simon Pieters) Date: Mon, 01 Jun 2009 21:26:34 +0200 Subject: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate. In-Reply-To: References: <20090530034920.D1C441389F2@hixie.dreamhostps.com> Message-ID: On Mon, 01 Jun 2009 21:09:56 +0200, Ian Hickson wrote: >> Please change "the body element" to "body >> elements". > > Really? Do you have a test case demonstrating this? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/124 -- Simon Pieters Opera Software From ian at hixie.ch Mon Jun 1 12:48:33 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 1 Jun 2009 19:48:33 +0000 (UTC) Subject: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate. In-Reply-To: References: <20090530034920.D1C441389F2@hixie.dreamhostps.com> Message-ID: On Mon, 1 Jun 2009, Simon Pieters wrote: > On Mon, 01 Jun 2009 21:09:56 +0200, Ian Hickson wrote: > > > > Please change "the body element" to "body > > > elements". > > > > Really? Do you have a test case demonstrating this? > > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/124 Huh. Interesting. Fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From den.molib at gmail.com Mon Jun 1 14:55:51 2009 From: den.molib at gmail.com (Den.Molib) Date: Mon, 01 Jun 2009 23:55:51 +0200 Subject: [whatwg] First or last Content-Type header? In-Reply-To: References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> Message-ID: <4A244E67.3080707@gmail.com> The only case of double headers I can think of is when using scripts that set a content-type, then try to set it again and the language itself don't prevent it. I think the "right" option in such case would be to follow the last one, as it's the one provided nearer the content. So I vote for using the last one. PS: Interestingly, this behavior could be used to send xhtml (and get it shown on IE) without sending different headers to each browser: Content-Type: text/html Content-Type: application/xhtml+xml From bil at corry.biz Mon Jun 1 16:25:33 2009 From: bil at corry.biz (Bil Corry) Date: Mon, 01 Jun 2009 18:25:33 -0500 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <4A244E67.3080707@gmail.com> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> Message-ID: <4A24636D.20902@corry.biz> Den.Molib wrote on 6/1/2009 4:55 PM: > follow the last one, as it's the one provided nearer the content. And by the same logic, the header closest to the content could be the one that was injected by an attacker (via application hole) -- so might choosing the first header be more prudent? - Bil From dhtmlkitchen at gmail.com Mon Jun 1 17:53:38 2009 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Mon, 1 Jun 2009 17:53:38 -0700 Subject: [whatwg] Exposing EventTarget to JavaScript In-Reply-To: <6fc58d0d0904241441g7ca3accesed3eff49a7665609@mail.gmail.com> References: <6eeb8bd10904241000x7d1cd78ftba8e1d77f911246c@mail.gmail.com> <49F208EF.6020807@mit.edu> <6fc58d0d0904241441g7ca3accesed3eff49a7665609@mail.gmail.com> Message-ID: On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell wrote: > On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky wrote: >> Erik Arvidsson wrote: >>> >>> To help out with this scenario >>> it would be good if an implementation of the EventTarget interface >>> could be exposed to JavaScript. >> >> Why do you want the eventTarget interface as opposed to a sane callback >> function registration setup? >> >>> The next and more important step is to allow a JavaScript "class" to >>> extend an EventTarget. For example: >>> >>> function MyClass() { >>> ?EventTarget.call(this); >>> ?... >>> } >>> MyClass.prototype = new EventTarget; // *[1] >> >> So this already works, no? >> >>> One more thing needs to be mentioned and that is how event propagation >>> should work in scenario. If the object has a "parentNode" property >>> then the event dispatching mechanism will do the right thing. >> >> What, precisely, is the use case for this in general? ?In the DOM, >> propagating events to parents makes sense (esp. because parents are unique). >> ?What would be the use case in a general object graph? > > Most of the JS object graphs that you'll see in the wild either > represent data hierarchies (wherein updates might trigger a UI change) > or wrapped sets of DOM nodes as a way to make up for the fact that you > can't freaking subclass Element from JS. In the latter case, it's > natural to need it to keep up the facade. In the former, it's a > performance convenience. > If I understand you correctly, you want to subclass the Element interface. If I got that right, then I am not sure how that concept would relate, as there are not interfaces in javascript, and so I am not sure how an object that has the interface of Element could also have the interface of your subclass. In the could have been ES4, maybe, but that is would-be fiction now. I can't think of any reason that anyone would even want that, anyway. In a fictitious version of javascript where interfaces could be created, you could just create your own, then implement both in the target class. But in reality, you could do something retarded like try to subclass NodeList. Oh yeah, someone already tried that, didn't they? Garrett From slightlyoff at google.com Mon Jun 1 18:02:36 2009 From: slightlyoff at google.com (Alex Russell) Date: Mon, 1 Jun 2009 18:02:36 -0700 Subject: [whatwg] Exposing EventTarget to JavaScript In-Reply-To: References: <6eeb8bd10904241000x7d1cd78ftba8e1d77f911246c@mail.gmail.com> <49F208EF.6020807@mit.edu> <6fc58d0d0904241441g7ca3accesed3eff49a7665609@mail.gmail.com> Message-ID: <6fc58d0d0906011802q887e6a7nc2feabcfc62471bf@mail.gmail.com> On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith wrote: > On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell wrote: >> On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky wrote: >>> Erik Arvidsson wrote: >>>> >>>> To help out with this scenario >>>> it would be good if an implementation of the EventTarget interface >>>> could be exposed to JavaScript. >>> >>> Why do you want the eventTarget interface as opposed to a sane callback >>> function registration setup? >>> >>>> The next and more important step is to allow a JavaScript "class" to >>>> extend an EventTarget. For example: >>>> >>>> function MyClass() { >>>> ?EventTarget.call(this); >>>> ?... >>>> } >>>> MyClass.prototype = new EventTarget; // *[1] >>> >>> So this already works, no? >>> >>>> One more thing needs to be mentioned and that is how event propagation >>>> should work in scenario. If the object has a "parentNode" property >>>> then the event dispatching mechanism will do the right thing. >>> >>> What, precisely, is the use case for this in general? ?In the DOM, >>> propagating events to parents makes sense (esp. because parents are unique). >>> ?What would be the use case in a general object graph? >> >> Most of the JS object graphs that you'll see in the wild either >> represent data hierarchies (wherein updates might trigger a UI change) >> or wrapped sets of DOM nodes as a way to make up for the fact that you >> can't freaking subclass Element from JS. In the latter case, it's >> natural to need it to keep up the facade. In the former, it's a >> performance convenience. >> > > If I understand you correctly, you want to subclass the Element interface. Think bigger. I want to create a concrete Element class (that's what a is, for all intents and purposes), re-interpret all the other elements in the DOM "class hierarchy" in terms of it, and make it subclassable (or treat it as a Trait for purposes of composition) so that we can do a component system that lets you introduce new elements that act sanely both in the HTML and JavaScript senses. > If I got that right, then I am not sure how that concept would relate, > as there are not interfaces in javascript, and so I am not sure how an > object that has the interface of Element could also have the interface > of your subclass. In the could have been ES4, maybe, but that is > would-be fiction now. > > I can't think of any reason that anyone would even want that, anyway. > In a fictitious version of javascript where interfaces could be > created, you could just create your own, then implement both in the > target class. > > But in reality, you could do something retarded like try to subclass > NodeList. Oh yeah, someone already tried that, didn't they? ...wow. Not sure I should engage with the rest of your message. It's belligerent for no apparent reason. Regards From bzbarsky at MIT.EDU Mon Jun 1 18:09:31 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 01 Jun 2009 21:09:31 -0400 Subject: [whatwg] Exposing EventTarget to JavaScript In-Reply-To: <6fc58d0d0906011802q887e6a7nc2feabcfc62471bf@mail.gmail.com> References: <6eeb8bd10904241000x7d1cd78ftba8e1d77f911246c@mail.gmail.com> <49F208EF.6020807@mit.edu> <6fc58d0d0904241441g7ca3accesed3eff49a7665609@mail.gmail.com> <6fc58d0d0906011802q887e6a7nc2feabcfc62471bf@mail.gmail.com> Message-ID: <4A247BCB.20202@mit.edu> Alex Russell wrote: > Think bigger. I want to create a concrete Element class (that's what a > is, for all intents and purposes) As a minor nit, a is basically an HTMLElement, not an Element. > and make it subclassable (or treat it as a Trait for purposes of composition) so > that we can do a component system that lets you introduce new elements > that act sanely both in the HTML and JavaScript senses. This has pretty serious security issues of various sorts, depending on what your subclassing would allow you to override. -Boris From cdibona at gmail.com Mon Jun 1 18:58:21 2009 From: cdibona at gmail.com (Chris DiBona) Date: Tue, 2 Jun 2009 09:58:21 +0800 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec Message-ID: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> I'd like to address some questions that have been raised about the use of FFmpeg in Chromium and Chrome as well as H.264 decoding in Chrome (Google's distribution of Chromium). The use of FFmpeg in Chromium and Chrome is fully compliant with the obligations of the associated licenses. It feels a little thread/list jacking to do this, but I don't like letting these kinds of questions stand, so... 1. FFmpeg and potential patent license issues FFmpeg is licensed under the LGPL 2.1 (there are some components that are licensed under the GPL but those are not relevant here, as explained below). The LGPL 2.1 states: "If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all." The LGPL 2.1 only requires that a party distributing LGPL code give other people the same rights to that code that they themselves received under the license. The Chromium project happily does exactly this. Google takes the FFmpeg libraries under the LGPL 2.1, with no attached patent license. Subsequently, Google makes the FFmpeg libraries available as part of Chromium under the LGPL 2.1, with no patent license attached. One participant quoted one of the examples from the LGPL 2.1, which says "For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library." To be clear, there are two situations here: Situation 1: (a) Party A gives Party B a library licensed under the LGPL 2.1 along with a patent license which says only Party B has the right to use it (b) Party B wants to distribute the library to others That's the situation the example in the LGPL 2.1 text is talking about and would likely be a violation. Situation 2: (a) Party A gives Party B a library licensed under the LGPL 2.1 (b) Party B gets a patent license from Party C (c) Party B then distribute the library under the LGPL 2.1 This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 for a license that does deal with this situation). Under the LGPL 2.1, the fact that Party B may have a patent license with an unrelated third-party is irrelevant as long as it doesn't prevent Party B from granting people the rights LGPL 2.1 requires they grant them (namely, only those rights it in fact received from Party A). 2. Location of FFmpeg source code The source code for FFmpeg is easily locatable in the same place as the rest of the Chromium source: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ 3. GPL licensed code in FFmpeg FFmpeg can be configured to use GPL licensed code, but it is not configured that way in Chromium. We use the set of configuration flags that only enables the LGPL 2.1 code. The list of configuration flags used is listed in the README file in the source directory: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium?revision=16648&view=markup We take our obligations under all open source licenses very seriously, and work hard to ensure we are in compliance with these licenses Chris DiBona On Mon, Jun 1, 2009 at 11:21 AM, wrote: > > Thank you for a very informative reply. ?Inline comments follow. > > --- On Sun, 5/31/09, Gregory Maxwell wrote: > >> From: Gregory Maxwell >> Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec >> To: whatwg at lists.whatwg.org >> Date: Sunday, May 31, 2009, 2:17 PM >> 2009/5/31? > at yahoo.com>: >> > Since the near complete MPEG-1 committee draft was >> publicly available in December 1991, >> [snip] >> >> You keep repeating this particular piece of misinformation, >> so I'm >> worried that people are going to take your word for it and >> get into >> trouble. >> >> What you are claiming with respect to the inventors >> disclosure and >> patent duration is correct for patents filed and granted >> today but it >> not true for patents from the mid-1990s. >> >> Prior to mid-1995 was possible to use application >> extensions to defer >> the grant date of a patent indefinitely.? You could >> begin an >> application in 1988, publicly expose your invention in >> 1991, all the >> while filing extensions only to have the patent granted in >> 1995. >> >> I am somewhat surprised that you are unaware of this >> issue, >> considering that you mentioned it specifically by name >> (submarine >> patent). > > Yes, I agree and I was not making this clear in my reply posts. ?The first email I sent I did detail this. > >> I'm more familiar with the area of audio coding than video, >> so I don't >> have a ready list of patents that read on mpeg1 video. >> However, There >> are mid-90s patents which read on both layer-2 (e.g. >> 5,214,678) and >> layer-3 audio which followed the 'submarine patent' style >> of prolonged >> application and late disclosure times. > > That is interesting that 5,214,678 is considered to read on Layer-2 since > AudioMPEG says that they are not doing licensing for Video-CD, which uses > MPEG-1 Layer 2 audio. ?It was granted in May 25, 1993 and filed on May 31, > 1990, so it barely made it in three years (and will not expire till > May 31, 2010). > > http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,214,678 > http://www.audiompeg.com/ > >> Additionally, Theora avoids some techniques used in MPEG1 >> which have >> been believed to be patented.? For example, the >> differential coding of >> motion vectors. While I don't have the knowledge needed to >> provide a >> detailed analysis, even I know enough to point out at least >> a few >> engineering reasons why Theora has less patent exposure >> surface than >> MPEG1. > > I can certainly believe that MPEG-1 Video might be non-royalty free and > Theora might be. ?I haven't really looked at the exact coding of Theora motion vectors. ?That is an interesting thing to look at. > >> Without the benefit of mpeg layer-3 audio MPEG1 is left >> enormously >> handicapped compared to Theora+Vorbis. 16kHz 16bit stereo >> PCM is >> 512kbit/sec on it own, which is comparable to the total >> bitrate 'high >> quality' option delivered by sites like Youtube. And 16kHz >> audio is >> pretty poor for anything that needs to carry music. > > Layer-2 audio can certainly beat PCM for compression, since it can reduce > the bit rate for coding the quieter frequency bands. ?Typical stereo bit > rates for stereo Layer 2 audio are probably more on the order of 256 > kbit/s. ?Vorbis and MPEG-1 Audio Layer 3 certainly can beat this rate. > >> While you could >> argue for using MPEG1+Vorbis, none of the few parties who >> indicated >> that they would not ship Theora have stated they would (or >> are >> already) shipping Vorbis. (For example, Nokia does not ship >> Vorbis on >> their Linux tables)? Everyone shipping Vorbis already >> seems to have no >> issue with Theora. > > I am not going to argue for MPEG-1 video plus Vorbis audio. > >> Even if you pay fairly low prices for transit the cost of >> sending PCM >> audio vs Vorbis is likely enough to pay for the H.264+AAC >> licensing no >> matter what it turns out to be in 2010.? A 'free' >> format which has an >> effective price much higher than the 'non-free' stuff would >> be >> something of a hollow victory. > > Interesting point. ?I think that transit costs will decrease > faster than H.264+AAC licensing costs, (unless Theora and Vorbis > start causing serious competion.) > >> And really, now that we see multiple large companies with >> experienced >> legal teams and non-trivial exposure committed to shipping >> Theora I >> think we're kidding ourselves when we attempt to analyze >> this as a >> legal issue. It's not. It's a business/political decision. >> The market >> is now going to battle it out.? Enjoy the show. > > I agree. ?I was not aware that Google planned on shipping Theora support when I made the first email last week (Wikipedia article since updated). > If Ogg Theora and Vorbis become the defacto standard, that is > fine with me. > > Right now, the best video codec/audio codec that works with Gstreamer good > plugins (i.e. Linux), Quicktime and Media Player is Motion JPEG with PCM > audio, which I have used for shipping videos on CDs and USB drives, but is > impractical for online transfers. ?I am hoping for a better outcome with > the video tag. > > Josh Cogliati > -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com From dhtmlkitchen at gmail.com Mon Jun 1 19:06:49 2009 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Mon, 1 Jun 2009 19:06:49 -0700 Subject: [whatwg] Exposing EventTarget to JavaScript In-Reply-To: <6fc58d0d0906011802q887e6a7nc2feabcfc62471bf@mail.gmail.com> References: <6eeb8bd10904241000x7d1cd78ftba8e1d77f911246c@mail.gmail.com> <49F208EF.6020807@mit.edu> <6fc58d0d0904241441g7ca3accesed3eff49a7665609@mail.gmail.com> <6fc58d0d0906011802q887e6a7nc2feabcfc62471bf@mail.gmail.com> Message-ID: On Mon, Jun 1, 2009 at 6:02 PM, Alex Russell wrote: > On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith wrote: >> On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell wrote: >>> On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky wrote: >>>> Erik Arvidsson wrote: [...] > > ...wow. Not sure I should engage with the rest of your message. It's > belligerent for no apparent reason. > The message I am trying to convey -- and let me make this clear -- is that it seems like a really bad idea to even want to try to do that. The subclassing of NodeList has also been attempted before, so one ought to be able to learn from such mistake. I think that makes my intent clearer and disambiguates any disparagement that may have been taken towards persons born with mental retardation[1]. That was not my intent. To those who have relation to such mentally handicapped individuals, my condolences for my careless word choice Garrett From whatwg at adambarth.com Mon Jun 1 19:09:51 2009 From: whatwg at adambarth.com (Adam Barth) Date: Mon, 1 Jun 2009 19:09:51 -0700 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <4A24636D.20902@corry.biz> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> Message-ID: <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> 2009/6/1 Bil Corry : > Den.Molib wrote on 6/1/2009 4:55 PM: >> follow the last one, as it's the one provided nearer the content. > > And by the same logic, the header closest to the content could be the one that was injected by an attacker (via application hole) -- so might choosing the first header be more prudent? If your site is vulnerable to header splitting, then you have bigger problems than injecting a Content-Type header. In any case, the four major browsers that actually look at the Content-Type header agree and use the last header. The only browser that uses the first header more or less ignores it anyway. Adam From howcome at opera.com Mon Jun 1 22:19:30 2009 From: howcome at opera.com (=?iso-8859-1?Q?H=E5kon?= Wium Lie) Date: Tue, 2 Jun 2009 07:19:30 +0200 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome In-Reply-To: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> Message-ID: <18980.46690.413772.64470@opera.com> Also sprach Chris DiBona: > To be clear, there are two situations here: > > Situation 1: > > (a) Party A gives Party B a library licensed under the LGPL 2.1 along > with a patent license which says only Party B has the right to use it > (b) Party B wants to distribute the library to others > > That's the situation the example in the LGPL 2.1 text is talking about > and would likely be a violation. > > Situation 2: > > (a) Party A gives Party B a library licensed under the LGPL 2.1 > (b) Party B gets a patent license from Party C > (c) Party B then distribute the library under the LGPL 2.1 > > This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 > for a license that does deal with this situation). Under the LGPL > 2.1, the fact that Party B may have a patent license with an unrelated > third-party is irrelevant as long as it doesn't prevent Party B from > granting people the rights LGPL 2.1 requires they grant them (namely, > only those rights it in fact received from Party A). Thanks for your willingness to discuss these matters. So, to be clear, you're saying that situation 2 applies in your case? -h&kon H?kon Wium Lie CTO ??e?? howcome at opera.com http://people.opera.com/howcome From julian.reschke at gmx.de Tue Jun 2 00:19:08 2009 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 02 Jun 2009 09:19:08 +0200 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> Message-ID: <4A24D26C.7070806@gmx.de> Adam Barth wrote: > 2009/6/1 Bil Corry : >> Den.Molib wrote on 6/1/2009 4:55 PM: >>> follow the last one, as it's the one provided nearer the content. >> And by the same logic, the header closest to the content could be the one that was injected by an attacker (via application hole) -- so might choosing the first header be more prudent? > > If your site is vulnerable to header splitting, then you have bigger > problems than injecting a Content-Type header. > > In any case, the four major browsers that actually look at the > Content-Type header agree and use the last header. The only browser > that uses the first header more or less ignores it anyway. Could you clarify that last point? Are you talking about IE? Which version? BR, Julian From cdibona at gmail.com Tue Jun 2 00:50:55 2009 From: cdibona at gmail.com (Chris DiBona) Date: Tue, 2 Jun 2009 15:50:55 +0800 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome In-Reply-To: <18980.46690.413772.64470@opera.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> <18980.46690.413772.64470@opera.com> Message-ID: <7d9492d90906020050w23673044k33270b12c5c82b89@mail.gmail.com> Looping in Dannyb (who may not be on the list, so if necessary, I'll forward) as I'm in the midst of a conference and can't give this the attention it deserves. Chris On Tue, Jun 2, 2009 at 1:19 PM, H?kon Wium Lie wrote: > Also sprach Chris DiBona: > > ?> To be clear, there are two situations here: > ?> > ?> Situation 1: > ?> > ?> (a) Party A gives Party B a library licensed under the LGPL 2.1 along > ?> with a patent license which says only Party B has the right to use it > ?> (b) Party B wants to distribute the library to others > ?> > ?> That's the situation the example in the LGPL 2.1 text is talking about > ?> and would likely be a violation. > ?> > ?> Situation 2: > ?> > ?> (a) Party A gives Party B a library licensed under the LGPL 2.1 > ?> (b) Party B gets a patent license from Party C > ?> (c) Party B then distribute the library under the LGPL 2.1 > ?> > ?> This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 > ?> for a license that does deal with this situation). ?Under the LGPL > ?> 2.1, the fact that Party B may have a patent license with an unrelated > ?> third-party is irrelevant as long as it doesn't prevent Party B from > ?> granting people the rights LGPL 2.1 requires they grant them (namely, > ?> only those rights it in fact received from Party A). > > Thanks for your willingness to discuss these matters. > > So, to be clear, you're saying that situation 2 applies in your case? > > -h&kon > ? ? ? ? ? ? ?H?kon Wium Lie ? ? ? ? ? ? ? ? ? ? ? ? ?CTO ??e?? > howcome at opera.com ? ? ? ? ? ? ? ? ?http://people.opera.com/howcome > -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com From whatwg at adambarth.com Tue Jun 2 01:17:14 2009 From: whatwg at adambarth.com (Adam Barth) Date: Tue, 2 Jun 2009 01:17:14 -0700 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <4A24D26C.7070806@gmx.de> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> Message-ID: <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> On Tue, Jun 2, 2009 at 12:19 AM, Julian Reschke wrote: > Adam Barth wrote: >> In any case, the four major browsers that actually look at the >> Content-Type header agree and use the last header. ?The only browser >> that uses the first header more or less ignores it anyway. > > Could you clarify that last point? > > Are you talking about IE? Which version? Sure. For the sake of discussion, let's say IE6 and IE7. Basically, if the Content-Type header contains a value IE knows about, then IE pretty much ignores the value and engages its sniffing algorithm. So, for example, if a response has: Content-Type: text/html Content-Type: image/gif and is really a GIF. IE will show the image correctly because it will see the text/html type, ignore it, and then sniff GIF from the content. By contrast, Firefox and Chrome will see the type image/gif type and show the image correctly. This is quite likely to occur on the web because it works in every browser. Now, consider the reverse: Content-Type: image/gif Content-Type: text/html In this case, IE renders the image correctly, but Firefox and Chrome don't show the image. This is less likely to occur on the web because it doesn't work in Firefox (e.g., >20% of the market). Adam From ian at hixie.ch Tue Jun 2 01:25:51 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 2 Jun 2009 08:25:51 +0000 (UTC) Subject: [whatwg] whitespace compression in document.title In-Reply-To: <11e306600808171932qa6a7283o73a5a7cf80189c89@mail.gmail.com> References: <11e306600808171857s48d9349fk98dc3087c6faf801@mail.gmail.com> <11e306600808171932qa6a7283o73a5a7cf80189c89@mail.gmail.com> Message-ID: On Mon, 18 Aug 2008, Robert O'Callahan wrote: > On Mon, Aug 18, 2008 at 2:19 PM, Ian Hickson wrote: > > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > > > > > > IE7, FF3 and Opera 9.51 compress whitespace when getting > > > document.title. \t and \n (at least) are converted to spaces, runs > > > of consecutive spaces are compressed to a single space, and leading > > > and trailing spaces are stripped. Safari 3.1 follows the spec and > > > does none of this. > > > > Do you mean for the purposes of the interface? Or in the API? > > The API, if I understand your question correctly. To be precise: the > rendering of this tescase: > > > > Hello Kitty > Kitty > > >

Title: > Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From julian.reschke at gmx.de Tue Jun 2 01:31:00 2009 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 02 Jun 2009 10:31:00 +0200 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> Message-ID: <4A24E344.8040209@gmx.de> Adam Barth wrote: > Sure. For the sake of discussion, let's say IE6 and IE7. Basically, > if the Content-Type header contains a value IE knows about, then IE > pretty much ignores the value and engages its sniffing algorithm. So, > for example, if a response has: > > Content-Type: text/html > Content-Type: image/gif > > and is really a GIF. IE will show the image correctly because it will > see the text/html type, ignore it, and then sniff GIF from the > content. By contrast, Firefox and Chrome will see the type image/gif > type and show the image correctly. This is quite likely to occur on > the web because it works in every browser. > > Now, consider the reverse: > > Content-Type: image/gif > Content-Type: text/html > > In this case, IE renders the image correctly, but Firefox and Chrome > don't show the image. This is less likely to occur on the web because > it doesn't work in Firefox (e.g., >20% of the market). Thanks! BR, Julian From timeless at gmail.com Tue Jun 2 01:31:30 2009 From: timeless at gmail.com (timeless) Date: Tue, 2 Jun 2009 11:31:30 +0300 Subject: [whatwg] Workers and URL origin check In-Reply-To: <6FDDABC1128B4A17839A241CFDD6AC18@POCZTOWIEC> References: <28040fc60905271713t302920e1y4658d827d11975f@mail.gmail.com> <63df84f0905280111h1d608628ne55a2d43c74bf058@mail.gmail.com> <28040fc60905281205maaeac39rdf9d1d1a43456bb6@mail.gmail.com> <6FDDABC1128B4A17839A241CFDD6AC18@POCZTOWIEC> Message-ID: <26b395e60906020131u12ae8596u4dcb9db789a51924@mail.gmail.com> On Fri, May 29, 2009 at 12:27 PM, Kristof Zelechovski wrote: > Inserting a SCRIPT element is not equivalent to a server-side include. ?It > is more like linking to an object file.? In particular, substitution macros > (e.g. CONST in BASIC) in one script do not apply other scripts (all scripts > present have already been parsed, and applying them to future scripts would > be to fragile). um data:text/html, to the extent that a script can affect any variable that is reachable, it does apply to all other scripts and certainly if i replace a primitive object property/method i'm affecting future scripts. Sure you could argue that the object file example is accurate if you remind people of ld preloading and symbol shadowing etc., btu most people wouldn't think about it that way. From ian at hixie.ch Tue Jun 2 02:23:34 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 2 Jun 2009 09:23:34 +0000 (UTC) Subject: [whatwg] Origins, reprise In-Reply-To: <4967D3AE.7030501@mit.edu> References: <49679AA7.2020902@mit.edu> <7789133a0901091316g58f02b51m57f3e4697fae8799@mail.gmail.com> <4967D3AE.7030501@mit.edu> Message-ID: On Fri, 9 Jan 2009, Boris Zbarsky wrote: > > I've recently come across another issue with the origin definition. > > Right now, this says: > > 1) If url does not use a server-based naming authority, or if parsing > url failed, or if url is not an absolute URL, then return a new > globally unique identifier. > 2) Return the tuple (scheme, host, port). > > (with some steps to determine the tuple thrown in). > > In Gecko, we actually have three classes of URIs for security purposes: > > 1) Those for which the URI is not same-origin with anything (the > globally unique identifier case). > 2) Those for which the URI is same-origin with anything with the same > scheme+host+port. > 3) Those for which the URI is same-origin with itself but no other URI > (not to be confused with the globally unique identifier case). > > It would be nice if we could express this in terms of the origin setup, but it > doesn't seem to me like that's workable as things stand... On Fri, 9 Jan 2009, Adam Barth wrote: > > Can you give an example of this kind of URI? On Fri, 9 Jan 2009, Boris Zbarsky wrote: > > Yes, of course. IMAP URIs [1] have an authority component which is the > IMAP server. At the same time, each message needs to be treated as a > separate trust domain. > > Similar for the proposed nntp URIs [2]. > > [1] http://www.rfc-editor.org/rfc/rfc5092.txt > [2] http://tools.ietf.org/html/draft-ellermann-news-nntp-uri-11 I've updated the algorithm for deriving an Origin from a URL in the HTML5 spec to handle this case. Adam: I believe that you are editing a draft that also has this algorithm; hat parts of HTML5 should I be stripping here? Will this particular algorithm belong in your draft or HTML5? (If the former, can you take this change also?) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From whatwg at adambarth.com Tue Jun 2 02:29:32 2009 From: whatwg at adambarth.com (Adam Barth) Date: Tue, 2 Jun 2009 02:29:32 -0700 Subject: [whatwg] Origins, reprise In-Reply-To: References: <49679AA7.2020902@mit.edu> <7789133a0901091316g58f02b51m57f3e4697fae8799@mail.gmail.com> <4967D3AE.7030501@mit.edu> Message-ID: <7789133a0906020229k118417ffrce48f7fc61f21dae@mail.gmail.com> On Tue, Jun 2, 2009 at 2:23 AM, Ian Hickson wrote: > Adam: I believe that you are editing a draft that also has this algorithm; > hat parts of HTML5 should I be stripping here? Will this particular > algorithm belong in your draft or HTML5? (If the former, can you take this > change also?) It's unclear to me whether the algorithm is better off in HTML 5 or in the I-D. We can sort that out later. In the mean time, I'll update the I-D. Adam From bdarcus at gmail.com Tue Jun 2 08:28:52 2009 From: bdarcus at gmail.com (Bruce D'Arcus) Date: Tue, 2 Jun 2009 11:28:52 -0400 Subject: [whatwg] on bibtex-in-html5 In-Reply-To: References: <9ABBA478-E05D-41F0-A9BB-0C007D75689E@simifilm.ch> Message-ID: So exactly what is the process by which this gets resolved? Is there one? On Sun, May 24, 2009 at 10:17 AM, Bruce D'Arcus wrote: > On Sat, May 23, 2009 at 5:35 PM, Ian Hickson wrote: > > ... > >> I agree that BibTeX is suboptimal. But what should we use instead? > > As I've suggested: > > 1) use Dublin Core. > > This gives you the basic critical properties: literals for titles and > dates, and relations for versions, part/containers, contributors, > subjects. > > You then have a consistent and general way to represent (HTML) > documents and embedded references to other documents, etc. (citation > references). This would cover the most important areas that BibTeX > covers. > > 2) this goes far, but you're then left with a few missing pieces for citations: > > a. more specific contributors (like editors and translators) > b. identifiers (there's dc:identifier, but no way to explicitly denote > that it's a doi, isbn, issn, etc.) > c. what I call "locators"; volume, issue, pages, etc. > d. types (book, article, patent, etc.) > > If there's some consensus on this basic way forward, we can talk about > details on 2. > > Bruce > From jgraham at opera.com Tue Jun 2 09:05:28 2009 From: jgraham at opera.com (James Graham) Date: Tue, 02 Jun 2009 18:05:28 +0200 Subject: [whatwg] on bibtex-in-html5 In-Reply-To: References: <9ABBA478-E05D-41F0-A9BB-0C007D75689E@simifilm.ch> Message-ID: <4A254DC8.6020105@opera.com> Bruce D'Arcus wrote: > So exactly what is the process by which this gets resolved? Is there one? Hixie will respond to substantive emails sent to this list at some point. However there are some hundreds of outstanding emails (see [1]) so the responses can take a while. If you have a pressing deadline that would benefit from your issue being addressed sooner, I suggest you talk to Hixie about it. FWIW I have a few general thoughts about the bibtex section which may or may not be interesting: 1) It seems like this and similar sections (bibtex, vCard, iCalendar) could be productively split out of the main spec into separate normative documents, since they are rather self-contained and have rather obvious interest for communities who are unlikely to find them at present or to be interested in the rest of the spec. Although the drag and drop stuff being dependent on them does mean that you'd need some circular references. 2) For the bibliographic data the most important issues that I see are ease of use and ease of export. Although I am not attached to the bibtex format per-se I would be extremely disappointed if a different, harder to author, format were used. Formats that are flexible but rarely used are less useful overall than more limited formats with ubiquitous deployment. In addition formats that are hard to use make it more likely that people will make accidental mistakes, so decreasing the reliability of the data and devaluing tools that consume the data. Although I don't think we have to use bibtex as the basis for the format, I do think a canonical mapping to bibtex is a requirement. Obviously this reflects my background in the physical sciences but, at least in that field LaTeX and, by association, bibtex are overwhelmingly popular. I am well aware that the situation in other fields is different but without clean, high fidelity, bibtex export (at least to the extend required to support common citation patterns within the physical sciences) the format will lose out on a large audience with a higher than average number of potential early adopters. [1] http://www.whatwg.org/issues/data.html > > On Sun, May 24, 2009 at 10:17 AM, Bruce D'Arcus wrote: >> On Sat, May 23, 2009 at 5:35 PM, Ian Hickson wrote: >> >> ... >> >>> I agree that BibTeX is suboptimal. But what should we use instead? >> As I've suggested: >> >> 1) use Dublin Core. >> >> This gives you the basic critical properties: literals for titles and >> dates, and relations for versions, part/containers, contributors, >> subjects. >> >> You then have a consistent and general way to represent (HTML) >> documents and embedded references to other documents, etc. (citation >> references). This would cover the most important areas that BibTeX >> covers. >> >> 2) this goes far, but you're then left with a few missing pieces for citations: >> >> a. more specific contributors (like editors and translators) >> b. identifiers (there's dc:identifier, but no way to explicitly denote >> that it's a doi, isbn, issn, etc.) >> c. what I call "locators"; volume, issue, pages, etc. >> d. types (book, article, patent, etc.) >> >> If there's some consensus on this basic way forward, we can talk about >> details on 2. >> >> Bruce >> From bil at corry.biz Tue Jun 2 09:25:54 2009 From: bil at corry.biz (Bil Corry) Date: Tue, 02 Jun 2009 11:25:54 -0500 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> Message-ID: <4A255292.6080002@corry.biz> Adam Barth wrote on 6/2/2009 3:17 AM: > Now, consider the reverse: > > Content-Type: image/gif > Content-Type: text/html > > In this case, IE renders the image correctly, but Firefox and Chrome > don't show the image. This is less likely to occur on the web because > it doesn't work in Firefox (e.g., >20% of the market). It's less likely to occur legitimately, but more likely to occur under a header injection scenario. For example, here's a page that simulates serving an image from an untrusted user[1], with the correct content-type of image/x-ms-bmp, then a second (injected) content-type of text/html: http://www.corry.biz:40100/ In Firefox 3, the page renders as HTML and delivers its hidden JavaScript payload, but in Internet Explorer 8, the page renders as a BMP image with no payload being delivered. It seems to me that IE has the correct behavior, or at least the more desirable behavior in this case. - Bil [1] Image from: http://www.h-online.com/security/Risky-MIME-sniffing-in-Internet-Explorer--/features/112589 From whatwg at adambarth.com Tue Jun 2 09:47:35 2009 From: whatwg at adambarth.com (Adam Barth) Date: Tue, 2 Jun 2009 09:47:35 -0700 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <4A255292.6080002@corry.biz> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> <4A255292.6080002@corry.biz> Message-ID: <7789133a0906020947t3480b4c4k45c88e5c7a4e2640@mail.gmail.com> On Tue, Jun 2, 2009 at 9:25 AM, Bil Corry wrote: > It's less likely to occur legitimately, but more likely to occur under a header injection scenario. As I wrote before in this thread, if the attacker can inject headers, there are far more severe attacks than changing the type of an HTTP response. Adam From jonas at sicking.cc Tue Jun 2 10:36:25 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Tue, 2 Jun 2009 10:36:25 -0700 Subject: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate. In-Reply-To: References: <20090530034920.D1C441389F2@hixie.dreamhostps.com> Message-ID: <63df84f0906021036p2c551626w133d5da404a44904@mail.gmail.com> On Mon, Jun 1, 2009 at 12:48 PM, Ian Hickson wrote: > On Mon, 1 Jun 2009, Simon Pieters wrote: >> On Mon, 01 Jun 2009 21:09:56 +0200, Ian Hickson wrote: >> >> > > Please change "the body element" to "body >> > > elements". >> > >> > Really? Do you have a test case demonstrating this? >> >> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/124 > > Huh. Interesting. Fixed. Is this something that's really needed for web compatibility though? Creating a DOM with multiple s is hard since the parser will never output such a DOM. Instead you have to manually set up such a DOM using DOM methods, something that I'd expect extremely few pages to do. I don't have a strong opinion either way on this, I think we should go with whatever's simplest to implement, but I don't know what that is. / Jonas From foolistbar at googlemail.com Tue Jun 2 10:38:33 2009 From: foolistbar at googlemail.com (Geoffrey Sneddon) Date: Tue, 2 Jun 2009 18:38:33 +0100 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec In-Reply-To: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> Message-ID: <51F8160A-DA76-4D06-96D4-6822B46AEF96@googlemail.com> On 2 Jun 2009, at 02:58, Chris DiBona wrote: > One participant quoted one of the examples from the LGPL 2.1, which > says "For example, if a patent license would not permit royalty-free > redistribution of the Library by all those who receive copies directly > or indirectly through you, then the only way you could satisfy both it > and this License would be to refrain entirely from distribution of the > Library." I'm still unclear as to how this does not apply to Chrome's case. If I get a copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the source ffmpeg, and I must be able to redistribute that in either binary or source form. I would, however, get in trouble for not having paid patent fees for doing so. Hence, as that example concludes, you cannot distribute ffmpeg whatsoever. -- Geoffrey Sneddon From bil at corry.biz Tue Jun 2 11:53:46 2009 From: bil at corry.biz (Bil Corry) Date: Tue, 02 Jun 2009 13:53:46 -0500 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <7789133a0906020947t3480b4c4k45c88e5c7a4e2640@mail.gmail.com> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> <4A255292.6080002@corry.biz> <7789133a0906020947t3480b4c4k45c88e5c7a4e2640@mail.gmail.com> Message-ID: <4A25753A.4080006@corry.biz> Adam Barth wrote on 6/2/2009 11:47 AM: > On Tue, Jun 2, 2009 at 9:25 AM, Bil Corry wrote: >> It's less likely to occur legitimately, but more likely to occur under a header injection scenario. > > As I wrote before in this thread, if the attacker can inject headers, > there are far more severe attacks than changing the type of an HTTP > response. That may be true, but changing the content-type is a very serious issue, as you yourself point out in the draft we're discussing: When a user agent uses different heuristics for media type detection than the server expects, security problems can occur. For example, if a server believes that the client will treat a contributed file as an image (and thus treat it as benign), but a user agent believes the content to be HTML (and thus privileged to execute any scripts contained therein), an attacker might be able to steal the user's authentication credentials and mount other cross-site scripting attacks. from: http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt Perhaps the better choice would be to toss out the multiple content-headers entirely and rely exclusively on content-sniffing. Without the content-header, Firefox 3 correctly shows the image, and Internet Explorer incorrectly delivers the payload -- but your draft, if adopted, should fix that problem, correct? - Bil From ian at hixie.ch Tue Jun 2 12:28:35 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 2 Jun 2009 19:28:35 +0000 (UTC) Subject: [whatwg] DOM Storage feedback In-Reply-To: <20090113233707.GE30640@arc.mcc.id.au> References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com> <63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com> <20090113233707.GE30640@arc.mcc.id.au> Message-ID: On Wed, 14 Jan 2009, Cameron McCormack wrote: > > I began testing all attributes and operations with DOMString arguments > from a selection of specs for their behaviour wrt null and undefined: > > http://mcc.id.au/2009/01/string-handling/string-handling > > Each pair of characters in the column for a browser is the behaviour for > null and undefined, respectively. It?s nowhere near complete, though > you can see that there are some operations arguments and attributes that > stringify null to "null" (?S? in the column). In particular it seems that IE does this reliably. After spot checking a few more using IE8, I have left the HTML5 spec and the other specs I work on at using the WebIDL defaults. If there are specific cases that people believe should be treated specially, please raise those explicitly. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From giecrilj at stegny.2a.pl Tue Jun 2 13:00:35 2009 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Tue, 2 Jun 2009 22:00:35 +0200 Subject: [whatwg] Workers and URL origin check In-Reply-To: <26b395e60906020131u12ae8596u4dcb9db789a51924@mail.gmail.com> References: <28040fc60905271713t302920e1y4658d827d11975f@mail.gmail.com> <63df84f0905280111h1d608628ne55a2d43c74bf058@mail.gmail.com> <28040fc60905281205maaeac39rdf9d1d1a43456bb6@mail.gmail.com> <6FDDABC1128B4A17839A241CFDD6AC18@POCZTOWIEC> <26b395e60906020131u12ae8596u4dcb9db789a51924@mail.gmail.com> Message-ID: <83303A8DB5E04827BC0BAC3E5E000CBD@POCZTOWIEC> I was wrong: CONST values and conditional compilation variables land as properties of the window, which means they are unavailable to other scripts only if the defining script is external and deferred. Still, I do not think this behavior is mandatory for run-time; there may be symbols that are handled by the parser and do not survive after the script has been loaded. Admittedly, neither JavaScript nor Basic support such a construct, but it would be easy to think of a scripting language that does. Hypothetically, Chris From simonp at opera.com Tue Jun 2 13:42:27 2009 From: simonp at opera.com (Simon Pieters) Date: Tue, 02 Jun 2009 22:42:27 +0200 Subject: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate. In-Reply-To: <63df84f0906021036p2c551626w133d5da404a44904@mail.gmail.com> References: <20090530034920.D1C441389F2@hixie.dreamhostps.com> <63df84f0906021036p2c551626w133d5da404a44904@mail.gmail.com> Message-ID: On Tue, 02 Jun 2009 19:36:25 +0200, Jonas Sicking wrote: > Is this something that's really needed for web compatibility though? Probably not. > Creating a DOM with multiple s is hard since the parser will > never output such a DOM. Instead you have to manually set up such a > DOM using DOM methods, something that I'd expect extremely few pages > to do. > > I don't have a strong opinion either way on this, I think we should go > with whatever's simplest to implement, but I don't know what that is. "The body element" is the first (if any) or

child of the root . I don't know what's simpler to implement, but the spec now matches at least Opera, Firefox and Safari (haven't tested IE). -- Simon Pieters Opera Software From den.molib at gmail.com Tue Jun 2 14:19:47 2009 From: den.molib at gmail.com (Den.Molib) Date: Tue, 02 Jun 2009 23:19:47 +0200 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <4A25753A.4080006@corry.biz> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> <4A255292.6080002@corry.biz> <7789133a0906020947t3480b4c4k45c88e5c7a4e2640@mail.gmail.com> <4A25753A.4080006@corry.biz> Message-ID: <4A259773.4000703@gmail.com> Bil Corry wrote: > It's less likely to occur legitimately, but more likely to occur under a header injection scenario. For example, here's a page that simulates serving an image from an untrusted user[1], with the correct content-type of image/x-ms-bmp, then a second (injected) content-type of text/html: > > http://www.corry.biz:40100/ > > In Firefox 3, the page renders as HTML and delivers its hidden JavaScript payload, but in Internet Explorer 8, the page renders as a BMP image with no payload being delivered. It seems to me that IE has the correct behavior, or at least the more desirable behavior in this case. > 1. The server or the script language you used to inject the payload may be replacing the header when you add the second header. 2. Browsers in widespread use take into account the last header. Thus, presending a header is not a method to protect the app. > Perhaps the better choice would be to toss out the multiple content-headers entirely and rely exclusively on content-sniffing. Without the content-header, Firefox 3 correctly shows the image, and Internet Explorer incorrectly delivers the payload -- but your draft, if adopted, should fix that problem, correct? > > - Bil > How do you send as plain text html content (eg. samples of malicious javascript) if using just heuristics? Or simply send a html-howto in plain text. From bil at corry.biz Tue Jun 2 16:24:20 2009 From: bil at corry.biz (Bil Corry) Date: Tue, 02 Jun 2009 18:24:20 -0500 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <4A259773.4000703@gmail.com> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <26628B55-678F-4ED8-BF72-B6D78C332641@googlemail.com> <4A244E67.3080707@gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> <4A255292.6080002@corry.biz> <7789133a0906020947t3480b4c4k45c88e5c7a4e2640@mail.gmail.com> <4A25753A.4080006@corry.biz> <4A259773.4000703@gmail.com> Message-ID: <4A25B4A4.90908@corry.biz> Den.Molib wrote on 6/2/2009 4:19 PM: > Bil Corry wrote: >> It's less likely to occur legitimately, but more likely to occur under a header injection scenario. For example, here's a page that simulates serving an image from an untrusted user[1], with the correct content-type of image/x-ms-bmp, then a second (injected) content-type of text/html: >> >> http://www.corry.biz:40100/ >> >> In Firefox 3, the page renders as HTML and delivers its hidden JavaScript payload, but in Internet Explorer 8, the page renders as a BMP image with no payload being delivered. It seems to me that IE has the correct behavior, or at least the more desirable behavior in this case. >> > > 1. The server or the script language you used to inject the payload may > be replacing the header when you add the second header. It may, but then there wouldn't be two headers and falls outside the scope of this discussion. > 2. Browsers in widespread use take into account the last header. Yes, Adam has made this clear; only IE differs. > Thus, presending a header is not a method to protect the app. Are you referring to current browser behavior? Or the proposed content-sniffing algorithm? If you're talking about current browser behavior, then it does work for IE. >> Perhaps the better choice would be to toss out the multiple content-headers entirely and rely exclusively on content-sniffing. Without the content-header, Firefox 3 correctly shows the image, and Internet Explorer incorrectly delivers the payload -- but your draft, if adopted, should fix that problem, correct? > > How do you send as plain text html content (eg. samples of malicious > javascript) if using just heuristics? > > Or simply send a html-howto in plain text. The server should provide a single content-type header that specifies text/plain. In the context that there are two content-type headers, then the answer will depend on which browser you want to protect; IE, set the first header to text/plain; all the others, set the last header to text/plain. And to be clear, if the content-sniffing draft decides to use the last header because it interoperates with the most sites, then I get that. I just don't want to see it using a less secure method just because that's what 4 out 5 browsers currently do. - Bil From Simetrical+w3c at gmail.com Tue Jun 2 16:51:38 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Tue, 2 Jun 2009 19:51:38 -0400 Subject: [whatwg] First or last Content-Type header? In-Reply-To: <4A25B4A4.90908@corry.biz> References: <7789133a0905301520u4d8d20bfm757140c226f77e7e@mail.gmail.com> <4A24636D.20902@corry.biz> <7789133a0906011909j78385963jff022f71201d9d8b@mail.gmail.com> <4A24D26C.7070806@gmx.de> <7789133a0906020117j7c06d9f7qc69fadbacaf3c8b6@mail.gmail.com> <4A255292.6080002@corry.biz> <7789133a0906020947t3480b4c4k45c88e5c7a4e2640@mail.gmail.com> <4A25753A.4080006@corry.biz> <4A259773.4000703@gmail.com> <4A25B4A4.90908@corry.biz> Message-ID: <7c2a12e20906021651g5bd3cccdhd3316dde5e97de0@mail.gmail.com> On Tue, Jun 2, 2009 at 7:24 PM, Bil Corry wrote: > The server should provide a single content-type header that specifies text/plain. ?In the context that there are two content-type headers, then the answer will depend on which browser you want to protect; IE, set the first header to text/plain; all the others, set the last header to text/plain. Sending a text/plain Content-Type will not prevent any (default-configured) version of IE from interpreting the file as HTML, even if it's the *only* Content-Type header sent. This is why Adam Barth said "The only browser that uses the first header more or less ignores it anyway." This apparently isn't fixed even in IE8: it insists on still upsniffing text/plain to text/html unless you use the nonstandard header "Content-Type: text/plain; authoritative=true;". (The reason given is compatibility. As usual, Microsoft seems to have compatibility problems where all other browsers have been doing the right thing for years -- maybe because of their intranet usage share. IE8 at least won't treat image/* as HTML anymore.) So anyway, IE is irrelevant to this discussion. Reference: http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx From cdibona at gmail.com Tue Jun 2 17:20:15 2009 From: cdibona at gmail.com (Chris DiBona) Date: Wed, 3 Jun 2009 08:20:15 +0800 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec In-Reply-To: <51F8160A-DA76-4D06-96D4-6822B46AEF96@googlemail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> <51F8160A-DA76-4D06-96D4-6822B46AEF96@googlemail.com> Message-ID: <7d9492d90906021720yddb186eq504ba2c29d67f210@mail.gmail.com> Looping in Danny (in transit) On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon wrote: > > On 2 Jun 2009, at 02:58, Chris DiBona wrote: > >> One participant quoted one of the examples from the LGPL 2.1, which >> says "For example, if a patent license would not permit royalty-free >> redistribution of the Library by all those who receive copies directly >> or indirectly through you, then the only way you could satisfy both it >> and this License would be to refrain entirely from distribution of the >> Library." > > I'm still unclear as to how this does not apply to Chrome's case. If I get a > copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the > source ffmpeg, and I must be able to redistribute that in either binary or > source form. I would, however, get in trouble for not having paid patent > fees for doing so. Hence, as that example concludes, you cannot distribute > ffmpeg whatsoever. > > > -- > Geoffrey Sneddon > > > -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com From dannyb at google.com Tue Jun 2 07:53:37 2009 From: dannyb at google.com (Daniel Berlin) Date: Tue, 2 Jun 2009 10:53:37 -0400 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome In-Reply-To: <7d9492d90906020050w23673044k33270b12c5c82b89@mail.gmail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> <18980.46690.413772.64470@opera.com> <7d9492d90906020050w23673044k33270b12c5c82b89@mail.gmail.com> Message-ID: <2fbe2a060906020753m23ddd719u2dd6fdae8cdb0eef@mail.gmail.com> On Tue, Jun 2, 2009 at 3:50 AM, Chris DiBona wrote: > Looping in Dannyb (who may not be on the list, so if necessary, I'll > forward) as I'm in the midst of a conference and can't give this the > attention it deserves. > > Chris > > On Tue, Jun 2, 2009 at 1:19 PM, H?kon Wium Lie wrote: >> Also sprach Chris DiBona: >> >> ?> To be clear, there are two situations here: >> ?> >> ?> Situation 1: >> ?> >> ?> (a) Party A gives Party B a library licensed under the LGPL 2.1 along >> ?> with a patent license which says only Party B has the right to use it >> ?> (b) Party B wants to distribute the library to others >> ?> >> ?> That's the situation the example in the LGPL 2.1 text is talking about >> ?> and would likely be a violation. >> ?> >> ?> Situation 2: >> ?> >> ?> (a) Party A gives Party B a library licensed under the LGPL 2.1 >> ?> (b) Party B gets a patent license from Party C >> ?> (c) Party B then distribute the library under the LGPL 2.1 >> ?> >> ?> This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 >> ?> for a license that does deal with this situation). ?Under the LGPL >> ?> 2.1, the fact that Party B may have a patent license with an unrelated >> ?> third-party is irrelevant as long as it doesn't prevent Party B from >> ?> granting people the rights LGPL 2.1 requires they grant them (namely, >> ?> only those rights it in fact received from Party A). >> >> Thanks for your willingness to discuss these matters. >> >> So, to be clear, you're saying that situation 2 applies in your case? >> That would be correct :) From ian at hixie.ch Tue Jun 2 18:11:30 2009 From: ian at hixie.ch (Ian Hickson) Date: Wed, 3 Jun 2009 01:11:30 +0000 (UTC) Subject: [whatwg] Do we need to rename the Origin header? In-Reply-To: <49D59768.5020308@corry.biz> References: <63df84f0901121631m41e1cf1av5cc5dcf318e24d72@mail.gmail.com> <7789133a0901131002k5559e02eu323eb5bfb3b4b6ed@mail.gmail.com> <63df84f0901131439i5231231fxb2d3ff37ee1f2972@mail.gmail.com> <63df84f0901131850j710c8defqe7c5205cc391af90@mail.gmail.com> <49D59768.5020308@corry.biz> Message-ID: On Thu, 2 Apr 2009, Bil Corry wrote: > > Since the public-webapps list was never able to reconcile[1] HTML5's > Origin header (now renamed XXX-Origin[2]) with CORS's Origin header[3], > we're left with two headers with similar implementations and similar > names. Due to this, it may prudent to rename XXX-Origin to something > without "Origin" in the name to better distinguish between the two. I > don't know what the header should be renamed to ("Source"?), but no > matter which name is chosen for the header, it should be listed as a > prohibited header for XHR.setRequestHeader()[4]. > > [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0057.html > [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step > [3] http://www.w3.org/TR/cors/#origin-header > [4] http://www.w3.org/TR/XMLHttpRequest2/#author-request-headers Based on advice from Adam, I have updated HTML5 to have "Origin" again. On Thu, 2 Apr 2009, Bil Corry wrote: > > Related, HTML5 currently prohibits sending the XXX-Origin header for GET > requests. This is to prevent intranet applications leaking their > internal hostnames to external sites (are there other reasons?). > > However, there is value in a site being able to determine that a request > originated from itself, so to that end, I'd like to request that HTML5 > specify that the XXX-Origin header should be sent for any same-origin > GET requests. This would still avoid leaking intranet hostnames while > allowing a site to verify that a request came from itself. That's an interesting idea; Adam, what do you think? I'm a bit wary of adding too many features at once here, and it's difficult to define exactly what consists a same-origin request sometimes, so this might not be that easy to do. On Thu, 2 Apr 2009, Bil Corry wrote: > > Since HTML5's XXX-Origin header now differs slightly from CORS Origin > header, I propose we rename HTML5's header to something without "Origin" > in it to make the distinction between the two more clear -- i.e. to > avoid developer implementation errors where they check for the wrong > header. As far as a name for the header goes, perhaps "Source" or > "Request-Source" or ???? Can we just resolve the differences? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From brettz9 at yahoo.com Tue Jun 2 18:24:29 2009 From: brettz9 at yahoo.com (Brett Zamir) Date: Wed, 03 Jun 2009 09:24:29 +0800 Subject: [whatwg] document.contentType Message-ID: <4A25D0CD.8000203@yahoo.com> Hello, Regardless of any decision on whether my recommendation for document.contentType to be standardized and made settable on a document created by createDocument() (rather than needing to call the less-than-intuitive doc.open() fix for HTML), I'd still like to recommend standardizing on Mozilla's document.contentType ( https://developer.mozilla.org/en/DOM/document.contentType ) for at least being able to get the property. It can be very useful for JavaScript code or a generic library to offer support for XHTML or HTML, such as conditionally calling getElementsByTagNameNS() (feature detection will not help since a document may still be in HTML even if the browser supports XHTML). thanks, Brett From dannyb at google.com Tue Jun 2 18:29:04 2009 From: dannyb at google.com (Daniel Berlin) Date: Tue, 2 Jun 2009 21:29:04 -0400 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec In-Reply-To: <7d9492d90906021720yddb186eq504ba2c29d67f210@mail.gmail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> <51F8160A-DA76-4D06-96D4-6822B46AEF96@googlemail.com> <7d9492d90906021720yddb186eq504ba2c29d67f210@mail.gmail.com> Message-ID: <2fbe2a060906021829j59be7466ma1fcf03c164e50a@mail.gmail.com> On Tue, Jun 2, 2009 at 8:20 PM, Chris DiBona wrote: > Looping in Danny (in transit) > > On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon > wrote: >> >> On 2 Jun 2009, at 02:58, Chris DiBona wrote: >> >>> One participant quoted one of the examples from the LGPL 2.1, which >>> says "For example, if a patent license would not permit royalty-free >>> redistribution of the Library by all those who receive copies directly >>> or indirectly through you, then the only way you could satisfy both it >>> and this License would be to refrain entirely from distribution of the >>> Library." >> >> I'm still unclear as to how this does not apply to Chrome's case. If I get a >> copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the >> source ffmpeg, and I must be able to redistribute that in either binary or >> source form. Which you can. > I would, however, get in trouble for not having paid patent >> fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do not restrict any of your rights under the LGPL 2.1, is the important part. > Hence, as that example concludes, you cannot distribute >> ffmpeg whatsoever. > Not quite :) Nowhere in the LGPL 2.1 are we required to grant you patent rights that we may have. We are only required to ensure any other licenses we may have signed do not prevent us from distributing the library under the terms of the LGPL 2.1, and that we place no further restrictions on use/redistribution/etc of the Library than the terms of the LGPL 2.1. Note that the actual *clause* (not the example) in question says "If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. " It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. In short, the only thing this clause does is prevent you from getting a license that restricts your ability to fulfill the obligations of the other clauses of the LGPL, or would restrict the ability of those downstream to fulfill their obligations. No patent license we have does that. --Dan From silviapfeiffer1 at gmail.com Tue Jun 2 18:38:53 2009 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Wed, 3 Jun 2009 11:38:53 +1000 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec In-Reply-To: <2fbe2a060906021829j59be7466ma1fcf03c164e50a@mail.gmail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> <51F8160A-DA76-4D06-96D4-6822B46AEF96@googlemail.com> <7d9492d90906021720yddb186eq504ba2c29d67f210@mail.gmail.com> <2fbe2a060906021829j59be7466ma1fcf03c164e50a@mail.gmail.com> Message-ID: <2c0e02830906021838x18e57c5w583153e744971835@mail.gmail.com> On Wed, Jun 3, 2009 at 11:29 AM, Daniel Berlin wrote: > On Tue, Jun 2, 2009 at 8:20 PM, Chris DiBona wrote: >> Looping in Danny (in transit) >> >> On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon >> wrote: >>> >>> On 2 Jun 2009, at 02:58, Chris DiBona wrote: >>> >>>> One participant quoted one of the examples from the LGPL 2.1, which >>>> says "For example, if a patent license would not permit royalty-free >>>> redistribution of the Library by all those who receive copies directly >>>> or indirectly through you, then the only way you could satisfy both it >>>> and this License would be to refrain entirely from distribution of the >>>> Library." >>> >>> I'm still unclear as to how this does not apply to Chrome's case. If I get a >>> copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the >>> source ffmpeg, and I must be able to redistribute that in either binary or >>> source form. > Which you can. > >> ?I would, however, get in trouble for not having paid patent >>> fees for doing so. > No more or less trouble than you would have gotten in had you gotten > it from ffmpeg instead of us, which combined with the fact that we do > not restrict any of your rights under the LGPL 2.1, is the important > part. Let me ask for more clarification here, since you seem to have a really good understanding of the legal implications. It seems to me that if I have decided for whatever reason (probably because I did not want to use a library that is likely to infringe on patents) that I did not want to have ffmpeg installed on my computer, and I installed Chrome, that in this case I would get a library installed on my computer without being aware of it. Or turned the other way - if I knew that Chrome comes with ffmpeg and I really didn't want ffmpeg installed on my computer, I could not use Chrome. Is this correct? I know full well that this is a theoretical example and that patent holders don't normally go after end users for patent infringements. However, I am asking for legal clarification and whether this has been thought through. Regards, Silvia. From gmaxwell at gmail.com Tue Jun 2 18:50:55 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 2 Jun 2009 21:50:55 -0400 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec In-Reply-To: <2fbe2a060906021829j59be7466ma1fcf03c164e50a@mail.gmail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> <51F8160A-DA76-4D06-96D4-6822B46AEF96@googlemail.com> <7d9492d90906021720yddb186eq504ba2c29d67f210@mail.gmail.com> <2fbe2a060906021829j59be7466ma1fcf03c164e50a@mail.gmail.com> Message-ID: On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin wrote: [snip] >> ?I would, however, get in trouble for not having paid patent >> fees for doing so. > No more or less trouble than you would have gotten in had you gotten > it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself? From dannyb at google.com Tue Jun 2 19:06:57 2009 From: dannyb at google.com (Daniel Berlin) Date: Tue, 2 Jun 2009 22:06:57 -0400 Subject: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec In-Reply-To: <2c0e02830906021838x18e57c5w583153e744971835@mail.gmail.com> References: <7d9492d90906011858y2c311e9v3bf7ac19417b9d14@mail.gmail.com> <51F8160A-DA76-4D06-96D4-6822B46AEF96@googlemail.com> <7d9492d90906021720yddb186eq504ba2c29d67f210@mail.gmail.com> <2fbe2a060906021829j59be7466ma1fcf03c164e50a@mail.gmail.com> <2c0e02830906021838x18e57c5w583153e744971835@mail.gmail.com> Message-ID: <2fbe2a060906021906t1297193dn420f9b70ff0d9ac@mail.gmail.com> On Tue, Jun 2, 2009 at 9:38 PM, Silvia Pfeiffer wrote: > On Wed, Jun 3, 2009 at 11:29 AM, Daniel Berlin wrote: >> On Tue, Jun 2, 2009 at 8:20 PM, Chris DiBona wrote: >>> Looping in Danny (in transit) >>> >>> On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon >>> wrote: >>>> >>>> On 2 Jun 2009, at 02:58, Chris DiBona wrote: >>>> >>>>> One participant quoted one of the examples from the LGPL 2.1, which >>>>> says "For example, if a patent license would not permit royalty-free >>>>> redistribution of the Library by all those who receive copies directly >>>>> or indirectly through you, then the only way you could satisfy both it >>>>> and this License would be to refrain entirely from distribution of the >>>>> Library." >>>> >>>> I'm still unclear as to how this does not apply to Chrome's case. If I get a >>>> copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the >>>> source ffmpeg, and I must be able to redistribute that in either binary or >>>> source form. >> Which you can. >> >>> ?I would, however, get in trouble for not having paid patent >>>> fees for doing so. >> No more or less trouble than you would have gotten in had you gotten >> it from ffmpeg instead of us, which combined with the fact that we do >> not restrict any of your rights under the LGPL 2.1, is the important >> part. > > Let me ask for more clarification here, since you seem to have a > really good understanding of the legal implications. > > It seems to me that if I have decided for whatever reason (probably > because I did not want to use a library that is likely to infringe on > patents) that I did not want to have ffmpeg installed on my computer, > and I installed Chrome, that in this case I would get a library > installed on my computer without being aware of it. Or turned the > other way - if I knew that Chrome comes with ffmpeg and I really > didn't want ffmpeg installed on my computer, I could not use Chrome. > Is this correct? No, it isn't. I'm told if you remove the ffmpeg dll, Chrome should still function properly, it should just not recognize