[whatwg] Fw: new message
Hello! You have a new message, please read <http://yourdentalfirst.com.previewdns.com/support.php?gkp5j> whatwg
[whatwg] Fw: new important message
Hello! New message, please read <http://getsport.pro/economics.php?8> whatwg
[whatwg] Proposal: implement a usescookies tag.
To post feedback to the WHATWG list, please subscribe first (and post from the same e-mail address as you subscribed from). We require this because of the level of spam the list would otherwise receive. If you just want to submit drive-by feedback and aren't concerned about receiving a reply, you can also file a bug using the review comments tool found at the bottom right of the screen when viewing the spec: http://whatwg.org/html If you have any questions about any of this or if you want to send private feedback, please feel free to e-mail Ian at i...@hixie.ch. Thanks! Opnieuw-verstuurd-door: Eric Imthorn ericimth...@me.com Van: Eric Imthorn eric.imth...@gmail.com Onderwerp: Proposal: implement a usescookies tag. Datum: 15 november 2012 21:52:33 CET Opnieuw-verstuurd-aan: whatwg@lists.whatwg.org whatwg@lists.whatwg.org Aan: whatwg@lists.whatwg.org Because of European legislation, all sites must warn users about the usage of cookies on the sites. Over 90% of European websites use cookies, which could make a We use cookies block become more common than a footer. So assuming the law is here to stay, this common mandatory block might as well get his own usescookies tag (or something in that nature). Another advantage is that browser-builders can implement an option to automatically display:none these elements (redering the whole legislation useless).
[whatwg] Web Forms 2 Repetition Model—please reinstate on specification
Please reinstate this feature (Web Forms 2 / Repetition Model) on the official specification. My use-case/ justification is explained on this forum thread: http://forums.whatwg.org/bb3/viewtopic.php?f=3t=4717 I want a declarative solution for simple repetition (e.g. for scientific data forms, for use in high-security institutions where Javascript may be disabled); and the ability to write my own Javascript based solution for anything else. (I can already do the latter, but the former eludes me; most disappointingly considering that this feature was well designed and close to being released). Matthew Slyman
Re: [whatwg] :invalid
On Fri, Dec 31, 2010 at 3:28 AM, Mounir Lamouri mounir.lamo...@gmail.com wrote: On 12/31/2010 02:13 AM, Ian Hickson wrote: On Thu, 23 Sep 2010, Mounir Lamouri wrote: The current specification of :invalid is pretty simple: it matches all invalid elements which are candidate for constraint validation. Unfortunately, :invalid is far from being perfect and most UI/UX guys would tell you that the current :invalid behavior is really bad. For example, having the invalid style applying as soon as you load the page (ie. for input required) is not a good thing. I consider myself a UI/UX guy and I completely agree on this point. Since then, we have implemented something you can try with Firefox 4.0b8: :-moz-ui-invalid and :-moz-ui-valid. By default, all element matching :-moz-ui-invalid have a red box shadow. The rules for :-moz-ui-invalid are the following: a. When not focused (AND list) 1. The element has its default value changed OR the element is in a form that the user tried to submit (but was invalid) ; 2. The element is invalid (:invalid applies). b. When focused (OR list): 1. If the element had :-moz-ui-invalid before it was focused, :-moz-ui-invalid applies if the element is invalid (IOW, if the element was valid or no style was applying, the element will not be shown as invalid as long as the user do not blur the elemnet) ; 2. Otherwise, :-moz-ui-invalid will not apply as long as the element is focused. This sounds fantastic. I will have to play with this beta, but it sounds like exactly what UAs should be doing to let authors easily create a fantastic user experience. Alan Hogan
[whatwg] required attribute in label
This question is sort of CSS related, but I think it's worth bringing up
here, assuming it hasn't already been discussed.
The first thing I wanted to do with the required attribute when I started
playing with it is to use the CSS :after pseudo-element to add an asterisk
after every required input:
style
[required]:after {content:*;}
/style
label for=name1Name/label
input id=name1 type=text required
However, it seems that since input is an empty element, the content cannot
be added after. My next thought was to somehow get at that required state
via the label for it, but that seems a bit complicated. Then I realized the
asterisk really ought to be after the label, not the input--which is perfect
since the label is not an empty element. However, required is for input
only.
Why not make required an acceptable attribute for the label element? It
could be done so that the required attribute can be on either just the
input or both the input and the label. Ideally, it could be put in the label
element only, and that would be transfered down to the input to which it is
connected automatically, so putting the required attribute on the label
automatically makes all attributes to which the label is connected required
as well.
Brenton
[whatwg] Script-invokable copy action
Hi. I am an author web developer. Searching the latest HTML5 spec I could find [1], the only references to a command to copy to clipboard involve the drag-and-drop API. I personally would like to see a cross-browser way to invoke a copy-to-clipboard command without using any drag-and-drop APIs. I understand access to the clipboard is sensitive. I call for user agents to respond to a JavaScript method that takes one parameter and assigns it to the clipboard, if the user trusts the site (as determined by the user agent). Good UAs would remember preferences by domain after warning the user about the copy action's sensitivity. The inability to copy to clipboard via JS is one of the few technical superiorities plugins and native apps have over web standards-based apps, and I would like HTML5 to support this functionality. It will be easier for me, an author, to implement than by using a plugin; it will save me bandwidth; and it benefits my end users. An example use case: Allowing users to click a button to copy a short URL (rel-shortlink value) to their clipboard, for sharing. [1]: http://www.w3.org/TR/html5/editing.html#copy-to-clipboard
Re: [whatwg] Codecs for audio and video
--- On Mon, 6/29/09, Ian Hickson i...@hixie.ch wrote: 2. The remaining H.264 baseline patents owned by companies who are not willing to license them royalty-free expire, leading to H.264 support being available without license fees. = H.264 becomes the de facto codec for the Web. This could be awhile. I took the US patents listed on at: http://www.mpegla.com/avc/avc-patentlist.cfm in http://www.mpegla.com/avc/avc-att1.pdf and checked their expiration dates. The last ones expires in 2028. There maybe other patents that are not listed, and some that are listed may not actually be essential to the real date for H.264 being royalty free could be different. Here is the complete list: Patent: 7,292,636 Filed: 02 mar 2004 Granted: 06 nov 2007 Expiration: 02 mar 2024 Summary: Using order value for processing a video picture Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,292,636 Patent: RE35,093 Filed: 03 dec 1990 Granted: 09 mar 1993 Expiration: 03 dec 2010 Summary: Systems and methods for coding even fields of interlaced video sequences Notes: Reissue of 05193004 filed 09 dec 1994 granted 21 nov 1995 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE35,093 Patent: 7,388,916 Filed: 07 jul 2001 Granted: 17 jun 2008 Expiration: 07 jul 2021 Summary: Water ring scanning apparatus and method, and apparatus and method for encoding/decoding video sequences using the same Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,388,916 Patent: 4,796,087 Filed: 01 jun 1987 Granted: 03 jan 1989 Expiration: 01 jun 2007 Summary: Process for coding by transformation for the transmission of picture signals Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=4,796,087 Patent: 6,894,628 Filed: 17 jul 2003 Granted: 17 may 2005 Expiration: 17 jul 2023 Summary: Apparatus and methods for entropy-encoding or entropy-decoding using an initialization of context variables Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,894,628 Patent: 6,900,748 Filed: 17 jul 2003 Granted: 31 may 2005 Expiration: 17 jul 2023 Summary: Method and apparatus for binarization and arithmetic coding of a data value Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,900,748 Patent: 7,088,271 Filed: 03 may 2005 Granted: 08 aug 2006 Expiration: 03 may 2025 Summary: Method and apparatus for binarization and arithmetic coding of a data value Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,088,271 Patent: 6,943,710 Filed: 04 dec 2003 Granted: 13 sep 2005 Expiration: 04 dec 2023 Summary: Method and arrangement for arithmetic encoding and decoding binary states and a corresponding computer program and a corresponding computer-readable storage medium Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,943,710 Patent: 7,286,710 Filed: 01 oct 2003 Granted: 23 oct 2007 Expiration: 01 oct 2023 Summary: Coding of a syntax element contained in a pre-coded video signal Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,286,710 Patent: 7,379,608 Filed: 04 dec 2003 Granted: 27 may 2008 Expiration: 04 dec 2023 Summary: Arithmetic coding for transforming video and picture data units Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,379,608 Patent: 7,496,143 Filed: 27 dec 2004 Granted: 24 feb 2009 Expiration: 27 dec 2024 Summary: Method and arrangement for coding transform coefficients in picture and/or video coders and decoders and a corresponding computer program and a corresponding computer-readable storage medium Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,496,143 Patent: 5,235,618 Filed: 06 nov 1990 Granted: 10 aug 1993 Expiration: 06 nov 2010 Summary: Video signal coding apparatus, coding method used in the video signal coding apparatus and video signal coding transmission system having the video signal coding apparatus Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,235,618 Patent: 4,849,812 Filed: 24 feb 1988 Granted: 18 jul 1989 Expiration: 24 feb 2008 Summary: Television system in which digitized picture signals subjected to a transform coding are transmitted from an encoding station to a decoding station Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=4,849,812 Patent: 5,021,879 Filed: 24 sep 1990 Granted: 04 jun 1991 Expiration: 24 sep 2010 Summary: System for transmitting video pictures Notes: http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,021,879 Patent: 5,128,758 Filed: 02 jun 1989 Granted: 07 jul 1992 Expiration: 02 jun 2009 Summary: Method and apparatus for digitally processing a high definition television augmentation signal Notes:
Re: [whatwg] Codecs for audio and video
--- On Wed, 7/1/09, Gregory Maxwell gmaxw...@gmail.com wrote: It was suggested here that MJPEG be added as a baseline. I considered this as an option for Wikipedia video support some years ago before we had the Theora in Java playback working. I quickly determined that it was unworkable for over-the-web use because of the bitrate: we're talking about on the order of 10x the required bitrate over Theora before considering the audio (which would also be 10x the bitrate of Vorbis). Mozilla already supports Motion JPEG for the image tag (but not for video tag so far as I know). Basically, right now if you want a video file that will play on Quicktime, Media Player and Gstreamer's good set of plugins, the best option is Motion JPEG. I have mailed CDs with MJPEG video and PCM audio, and you can fit ~15 minutes of this in ~TV quality. For ~TV quality video and audio (240 x 320 pixels 30 fps) we are talking something like (If you have better numbers, point them out to me): 5 MBit/s MJPEG video with PCM audio 1-2 MBit/s MPEG-1 0.5 MBit/s Ogg Vorbis My suggestion (and I am not particularly serious) was: [(H.264 OR Theora) AND Motion JPEG] If you care about bandwidth more than licensing fees, you provide both H.264 and Theora. If you care more about licensing costs, you can provide Theora and Motion JPEG. I don't think that enshrining this in the spec is a very good idea however since it is a somewhat poor compromise. I can envision a future where a year from now Apple still has not added Theora support, but Mozilla has added gstreamer support, and suddenly Motion JPEG is the 'best' baseline codec, and the defacto video support is [(H.264 OR Theora) AND Motion JPEG] As far as I'm concerned spec might as well recommend a lossless codec as MJPEG— at least lossless has advantages for the set of applications which are completely insensitive to bitrate. What lossless codecs might be available without patent problems?
Re: [whatwg] Codecs for audio and video
--- On Tue, 6/30/09, Mikko Rantalainen mikko.rantalai...@peda.net wrote:
(2) Specify {Theora or H.264} as the baseline. That way all
vendors that
have displayed any interest for video could
implement the spec.
Authors would be required to provide the video in both
formats to be
sure that any spec compliant user agent is able to display
the content,
but at least there would be some real target set by the
spec. However, I
think that this just moves the H.264 patent licensing issue
from browser
vendors to content authors: if you believe that you cannot
decode H.264
without proper patent license there's no way you could
encode H.264
content without the very same license. As a result, many
authors will
not be able to provide H.264 variant -- and as a result the
Theora would
become de facto standard in the future.
--
Mikko
Specify {Theora or H.264} AND {Motion JPEG} That way there is a fallback
mechanism when you care more about compatibility than bandwidth and don't want
to deal with the hassle of the H.264 patents. Sometimes compatibility is more
important than bandwidth. (HTML is a common method of putting content on
CD-ROMs.)
Josh Cogliati
Re: [whatwg] HTML 5 video tag questions
Okay. Thanks. Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere like: Authors may provide multiple source elements to provide different codecs for different user agents. Thank you. --- On Mon, 6/15/09, Tab Atkins Jr. jackalm...@gmail.com wrote: From: Tab Atkins Jr. jackalm...@gmail.com Subject: Re: [whatwg] HTML 5 video tag questions To: Chris Double chris.dou...@double.co.nz Cc: whatwg@lists.whatwg.org, jjcogliati-wha...@yahoo.com Date: Monday, June 15, 2009, 6:55 AM On Mon, Jun 15, 2009 at 4:49 AM, Chris Doublechris.dou...@double.co.nz wrote: On Mon, Jun 15, 2009 at 5:27 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: (That said, I don't think there's anything wrong with nesting videos, it's just unnecessary.) This won't work since fallback content is not displayed unless video is not supported. Dang, I was wrong. I know I remembered some conversations about nested video, but I guess I was just remembering people *asking* about it. Regardless, as noted by others, my source suggestion was correct. Provide multiple sources if you're not sure about what format your users can view. ~TJ
[whatwg] HTML 5 video tag questions
I read section 4.8.7 The video element and I have some questions: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? 2. What is the recommended way for website authors to determine what video and audio codecs and containers are supported by a user agent? Joshua Cogliati http://jjc.freeshell.org/
Re: [whatwg] Codec mess with video and audio tags
--- On Sun, 6/7/09, David Gerard dger...@gmail.com wrote: From: David Gerard dger...@gmail.com Subject: Re: [whatwg] Codec mess with video and audio tags To: whatwg@lists.whatwg.org Date: Sunday, June 7, 2009, 9:30 AM 2009/6/7 jjcogliati-wha...@yahoo.com: There are concerns or issues with all of these: a) a number of large companies are concerned about the possible unintended entanglements of the open-source codecs; a 'deep pockets' company deploying them may be subject to risk here. Google and other companies have announced plans to ship Ogg Vorbis and Theora or are shipping Ogg Vorbis and Theora, so this may not be considered a problem in the future. Indeed. There are no *credible* claims of submarine patent problems with the Ogg codecs that would not apply precisely as much to *any other codec whatsoever*. I fully agree that any codec can have the possibility that there may be unknown patents that read on them. In fact, there are less, because the Ogg codecs have in fact been thoroughly researched. I have looked for evidence of that there has been any patent research on the Ogg codecs. I assume that Google, Redhat and others have at least done some research, but I have yet to find any public research information. I probably am just missing the pointers to this, so could you please tell me where I can find results of this research? Thank you. This claimed objection to Ogg is purest odious FUD, and should be described as such at every mention of it. It is not credible, it is a blatant and knowing lie.
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
That is a potential problem, but for MPEG-1 it is less of a problem than with newer codecs. Since the near complete MPEG-1 committee draft was publicly available in December 1991, remaining patents for decoding of the full MPEG-1 spec should be expiring in the 2012 timeframe or before. The next question is why not just wait until the complete MPEG-1 can be decoded? If there is still no decision on a suitable codec for HTML5 when MPEG-1 becomes royalty free and MPEG-1 decoding starts showing up in things like gstreamer's good set of plugins then the full MPEG-1 might be worth considering then. --- On Sat, 5/30/09, Den.Molib den.mo...@gmail.com wrote: From: Den.Molib den.mo...@gmail.com Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec To: jjcogliati-wha...@yahoo.com, whatwg@lists.whatwg.org Date: Saturday, May 30, 2009, 5:20 AM I'm afraid that if using a subset of a bigger, patented, standard. Some browsers will include the full codec. Web authors see their videos reproduce correctly, and put them in the web thinking they're 'standard', while the user agents including only the license-free version won't be able to view them. Thus de facto requiring the full support for the web, in what could be considered a variant of 'embrace and extend' issues, even if not intentional.
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
--- On Sat, 5/30/09, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: From: Silvia Pfeiffer silviapfeiff...@gmail.com Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec To: jjcogliati-wha...@yahoo.com Cc: whatwg@lists.whatwg.org Date: Saturday, May 30, 2009, 6:45 AM On Fri, May 29, 2009 at 10:03 PM, jjcogliati-wha...@yahoo.com wrote: I propose that a MPEG-1 subset should be considered as the required codec for the HTML-5 video tag. == MPEG-1 Background == ... == Brief comparison to other video codecs == ... Ogg Theora and Ogg Vorbis are newer standards than MPEG-1. My guess is that they can do substantially better at compression than MPEG-1. Assuming there are no submarine patents, I think the OGG codecs would be a better choice than MPEG-1. That's good to know. ... == Remaining Work == I am not a lawyer. In order to use MPEG-1 PRF, patent lawyers will have to investigate the patent issue and publicly report on the patent status. Unless there is a report sitting around that can be published, this will likely be expensive. The reason that current browser vendors put forward for not supporting Ogg Theora/Vorbis is that there is no thorough report available on their patent status which also convincingly shows that the risk of submarine patents is minimal. If you would also prefer Ogg Theora/Vorbis over MPEG-1 PRF, then I don't understand why such a report should not rather be created about these codecs than on MPEG-1 PRF. As well, the prior art review is not complete. The biggest missing piece is synthesis window for the audio layer. Same argument here for Ogg Theora/Vorbis. ... == Satisfaction of requirements == From 4.8.7.1 HTML 5 draft: 1. does not require per-unit or per-distributor licensing Probably. There does not seem to be anyone requesting this kind of licensing right now. 2. Must be compatible with the open source development model. Probably. There does not seem to be any identified patents for MPEG-1 PRF. 3. Is of sufficient quality as to be usable Yes. Much better than the next best option of Motion JPEG. Probably worse than Ogg Theora or H.264. These three are better satisfied by Ogg Theora/Vorbis. 4. Is not an additional submarine patent risk for large companies. Probably. It has been widely implemented (in DVD players, in Apple Quicktime and Microsoft Media Player) Note that these example uses have either a license for MPEG-2 or MPEG-4 however. Wide implementation does not save you from submarine patents. Nothing really does. Wide implementation only spreads the risk across more bodies. An existing lawsuit that has been resolved reduces the risk. But there will always be the risk of another unknown patent that could be interpreted to be infringed. == Conclusion == The MPEG-1 PRF subset defined here seems to fit all the requirements of a codec for video for HTML5. It seems to be patent free. A final conclusion will depend on whether or not patent lawyers can sign off on this proposal and if the quality of MPEG-1 PRF is deemed sufficient. Honestly, I'd rather suggest spending the money on Ogg Theora if you are really suggesting spending money on lawyers and patent research. Ogg Theora/Vorbis is miles ahead of MPEG-1 in Quality and in increasingly wider spread use on the Web. If the cost for patent clearing MPEG-1 PRF and Ogg Theora and Vorbis were the same, then I would completely agree with you. I think that the cost for patent clearing MPEG-1 PRF would be cheaper for the following reasons: 1. Age of Standard. MPEG-1 final standard (parts 1,2,3) came out in August 1993. Ogg Theora standard came out in about 2004. Basically, for all but the oldest unexpired patents, the MPEG-1 standard can be considered prior art, but for Theora, there is another decade of time where outside prior art needs to be found. 2. Simplicity. MPEG-1 PRF is quite a bit simpler than Ogg Theora and Vorbis. Ogg Theora contains much of what is in MPEG-1 Video (such as Motion vectors) and much that is newer than MPEG-1. 3. Existing use. MPEG-1 has been in use by major media players such as Apple Quicktime and Microsoft Media Player, so there probably are internal patent reviews that have been done. (These are probably considered very proprietary, so this reason is very weak.) So I think that a MPEG-1 PRF patent review would be cheaper than a Ogg Vorbis and Theora review. The questions I don't have a good answer to are how much better Ogg Theora and Vorbis are than MPEG-1 PRF, and how much more expensive patent reviewing Ogg Theora and Vorbis is compared to MPEG-1 PRF. I would like to see a comparison that shows Ogg Theora/Vorbis is miles ahead of MPEG-1 in Quality. I would also like to know what kind of patent review has already been done on Ogg Theora and Vorbis
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
Thank you for a very informative reply. Inline comments follow. --- On Sun, 5/31/09, Gregory Maxwell gmaxw...@gmail.com wrote: From: Gregory Maxwell gmaxw...@gmail.com Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec To: whatwg@lists.whatwg.org Date: Sunday, May 31, 2009, 2:17 PM 2009/5/31 jjcogliati-whatwg 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
[whatwg] MPEG-1 subset proposal for HTML5 video codec
I propose that a MPEG-1 subset should be considered as the required codec for the HTML-5 video tag. == MPEG-1 Background == MPEG-1 was published as the ISO standard ISO 11172 in August 1993. It is a widely used standard for audio and video compression. Both Windows Media and Apple Quicktime support playing MPEG-1 videos using Audio Layer 2. MPEG-1 provides three different audio layers. The simplest is Audio Layer 1 and the most complicated is Audio Layer 3, usually known as MP3. Since MPEG-1 includes MP3, a full implementation of a MPEG-1 decoder would not be royalty free until either all the essential MP3 patents expire, or a royalty free license is granted for all the essential MP3 patents. == MPEG-1 PRF == I propose the following subset of MPEG-1 as the MPEG-1 Potentially royalty free subset (MPEG-1 PRF): MPEG-1 Video without: forward and backward prediction frames (B-frames) dc-pictures (D-frames) MPEG-1 Audio Layers 1 and 2 only (no Layer 3 audio) This subset eliminates the currently patented MP3 portion of the MPEG-1 Audio. It also eliminates the non-needed B-frames and D-frames because there is less prior art for them and this has the side effect of simplifying MPEG-1 PRF decoding. == Patents == To the best of my knowledge, there are no essential patents on this MPEG-1 PRF subset. I have discussed this on a kuro5hin article, a post on the gstreamer mailing list and the MPEG-1 discussion page at Wikipedia, and no-one has been able to definitively list any patents on this subset. http://www.kuro5hin.org/story/2008/7/18/232618/312 http://sourceforge.net/mailarchive/message.php?msg_id=257198.16969.qm%40web62405.mail.re1.yahoo.com http://en.wikipedia.org/wiki/Talk:MPEG-1#Can_MPEG-1_be_used_without_Licensing_Fees.3F That said, absence of evidence is not evidence of absence. There still may certainly be patents on MPEG-1 PRF. Next I will discuss some prior art that exists for this subset. == Prior Art for MPEG-1 PRF == The H.261 (12/90) specification contains most of the elements that appear in MPEG-1 video with the exception of the B-Frames and D-frames. H.261 however only allows 352 x 288 and 176 x 144 sized video. H.261 is generally considered to be royalty free (such as by the OMS video project). There are no unexpired US patents listed for it on the ITU patent database. http://www.itu.int/rec/T-REC-H.261 http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of As for MPEG-1 Audio Layer 2, it is very close to MASCAM, which was described in Low bit-rate coding of high-quality audio signals. An introduction to the MASCAM system by G. Thiele, G. Stoll and M. Link, published in EBU Technical Review, no. 230, pp. 158-181, August 1988 The Pseudo-QMF filter bank used by Layer 2 is similar to that described in H. J. Nussbaumer. Pseudo-QMF Filter Bank, IBM technical disclosure bulletin., Vol 24. pp 3081-3087, November 1981. The MPEG-1 committee draft was publicly available as ISO CD 11172 by December 6, 1991. There is only a few year window for patents to have been filed before this counts as prior art, and not have expired. This list of prior art is by no means complete, in that there certainly could be patents that are essential for a MPEG-1 PRF implementation, but can not be invalided by this list of prior art. In the US, patents filed before 1995 last the longer of 20 years after they are filed or 17 years after they are granted. They also have to be filed within a year of the first publication of the method. This means that for US patents, most (that is all that took less than three years to be granted) patents that could apply to MPEG-1 will be expired by December 2012 (21 years after the committee draft was published.). == Brief comparison to other video codecs == Motion JPEG with PCM audio is the only codec that I know of that can be played in a stock Windows, Linux and Mac OS X setup. On the other hand, since it is basically a series of JPEG images and a 'WAV' file, the compression is much poorer than MPEG-1 PRF. Ogg Theora and Ogg Vorbis are newer standards than MPEG-1. My guess is that they can do substantially better at compression than MPEG-1. Assuming there are no submarine patents, I think the OGG codecs would be a better choice than MPEG-1. If you think that MPEG-1 PRF is not royalty free, but Ogg Theora and Ogg Vorbis are, you may find that comparing Theora to H.261 or Theora and Vorbis to MPEG-1 PRF is an enlightening exercise. Much of what is in MPEG-1 PRF is also in Ogg Theora and Ogg Vorbis. MPEG-2 is the next MPEG standard. It mainly adds error correction and interlacing. Neither of these features is particularly important for streaming video to computer monitors using a reliable data transport. MPEG-2 definitely is patented, and will be until at least the 2018 time-frame. I don't think that this buys much over MPEG-1 PRF, and it definitely adds more patent issues. MPEG-4, H.264 have
[Whatwg] Are Web Applications Still a Vague Subject ?
From the Working Group?s charter the first deliverable is stated as: ?A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web. ???..? Reading the draft specification and other related documentation a number of fundamental questions relating to the application part of this deliverable remain unclear to me. So I don?t waste the groups time and can contribute productively, can anyone point me to the previous discussion threads or parts of the specification which gives answers or guidance to the following questions. 1 Is there an accepted definition of ?document? and ?application?? (Depending on the answer the remainder of these questions may be irrelevant. eg if application really means a ?form?. The last paragraph of Section 1.1 of the spec further confuses me, which is not difficult to do. ) 2 When does a document become an application? 3 Is equal weight and priority given to addressing the requirements of documents and applications within the HTML5 specification? 4 Is there an accepted design basis for applications i.e. an Application Object Model (AOM)? Kind Regards Ian Hart
Re: [whatwg] Attributes vs. Elements
XHTML2 moves a lot of semantics and behavior from elements to global attributes. For example, href can turn any element into a hyperlink, and src can turn any element into an image. I liked the href adding a link to any object, but the src, I don't care for. I can already set a background image on an element to turn it into an image. As I followed the thread you mentioned, I could see cases where code would be cleaner to, for example, have an href in a heading element. That would solve some issues with inline elements holding block elements (e.g. improperly adding an anchor to an entire h1 tag). - It's easier (and, in many implementations, more efficient) to style by tag name rather than by presence or absence of an attribute. As I followed the thread, thinking about styling the element was the clincher for me. IE 6 doesn't support attribute based selectors. So, I, for one, couldn't use it until IE 6 (haven't tested attribute selectors in IE 7, since I stopped using them in light of IE 6) lost most of it's popularity. After that, having the href in, say, an ordered list used for navigation would save a few keystrokes. - Typically, browser implementations have an implementation class per element, but not a class per attribute, so putting primary semantics and behavior on an element instead of an attribute promotes clean implementation. Otherwise, all behavior ends up in the HTMLElement base class. I can certainly see how this would trouble an implementor. If it made working with DOM objects (e.g. looping through an object's properties) more tedious, developers would certainly care. Finally, I'd like to conclude with this reductio ad absurdum of the XHTML2 approach. If assigning behavior and semantics to attributes is so much better, why not just have a single elt element: While the href attribute is pretty common (lots of things need to be links that are already wrapped in some kind of tag) and could simplify code, the src element definitely seems to follow this reduction. Having a few select attributes (specifically the href) applicable to all tags could be useful. But, I agree with you in the end. The potential problems and compromise of semantics is important enough either not to have it, or not to use it if it is available if you desire a semantic document (ignoring things like the title, lang, etc that really do need to be available). -- Robert Brodrecht http://robertdot.org
Re: [whatwg] Attributes vs. Elements
ddailey wrote: The ease of using DOM methods to find tags, as opposed to attributes, tends to suggest that all things having href's should be easily findable by script. a works nicely for that, but would the availability of a document.links array then include all things with href's? In JavaScript, document.links would work, though I've been indoctrinated into the modern DOM camp and like to use document.getElementsByTagName(a). I try to avoid DOM 0 style collections, but for things like form validation, I end up using the .elements collection frequently. I'm sure I could adjust my way of thinking if I needed to. My gripe, however, was with CSS attribute selectors.[1] I didn't really make that clear. IE 6 doesn't do them. However, as someone pointed out, something like td:link would work. I wouldn't need td[href] to get at all tds with hrefs. Assuming that is true, and it had support from the 4 major browsers, the href-on-all-attributes would work pragmatically. If it would make sense semantically / ideologically, I'm still unsure. I don't know if the existence of the anchor element was lack of foresight or if it has a real semantic meaning like em or strong that is independent of the href. [1] http://www.w3.org/TR/CSS21/selector.html#attribute-selectors
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Mar 10, 2007, at 8:38 AM, Mihai Sucan wrote: There's no way to advertise the document as HTML 5, and it's certainly not the purpose of the specification to do so. This is a problem. It is especially a problem now that the W3C is working on their version of HTML 5. When I asked Ian Hickson how WHATWG would handle divergence in the W3C spec [1], he said he intended to make every effort to keep the two in sync. [2] While I appreciate his effort and I fully believe that he will do his best, we are dealing with a body (i.e. the W3C) who have a history of stubbornness and unwillingness to work with important members of the community. [3] The future is still undecided, but I don't think it is a good idea to operate under the assumption that the W3C will copy and paste the entire WHATWG HTML 5 spec. Even if DTDs are non-normative and antiquated in the HTML 5 spec, it at least provides some method for authors to indicate their intentions. If my intention was to write a document conforming to HTML 3.2, I can use the HTML 3.2 DTD to tell anyone in the future that I was using a certain set of elements. If browsers pay no attention to DTDs, as WHATWG has said time and again, browsers must be rendering the latest and greatest markup. If in 50 years, the i element has been out of use for 40 years, and browsers stop rendering that element and validators throw errors on that element, the document still conforms to the DTD. It's not the author's fault that the document doesn't perform the way it intended. Ideally, the browser should care about DTDs. The WHATWG HTML 5 spec provides no way to specify what version / fork of HTML the author intended to use. Even if browsers don't pay attention, I think it is a shame that there is no way to specify (if for nothing else, to future-proof documents). I blogged about this in more detail. [4] It seems the WHATWG is staunchly against DTDs, even if it has an appropriate use (e.g. emails in this thread talking about XML entities). I've mulled over this awhile. Since DTDs aren't normative in browsers, perhaps a link element with a rel=specification and an href=http://www.whatwg.org/specs/web-apps/ current-work/ (for example) would be a new way to say, this is the specification I used to create this document. It is easier to remember than the DOCTYPE DTDs on pervious versions of HTML, and it is much more human-readable than DTDs. It addresses my concerns, and doesn't use DTDs. Now, I don't know if it can be used as a quirksmode switch. The DOCTYPE seems like an ideal place to run the switch. The problem will be if the W3C (or some other as yet unformed working group that decides to fork HTML) doesn't implement a DTD-less DOCTYPE. If the switch is the WHATWG HTML5 DOCTYPE, documents authored under W3C HTML 5 spec will not render in super-standard mode. Browsers will have to have multiple super-standards modes switches depending on what version of HTML5 the author uses. IE asking a working group to provide some new way to specify standards mode doesn't make sense. That is an implementation problem that they need to figure out. It isn't our job to write their software. WHATWG doesn't need to bloat the spec for them. The IE team needs to be creative and find a solution to their problem. We're already using headers to swap between HTML and XHTML (since we still call both .html files). Headers are for telling user agents how to deal with content. It seems like sending a header X- STANDARDS-MODE: HTML5; (or WHATWG-HTML5 if W3C's HTML 5 is significantly different) or setting an http-equiv meta tag to tell IE to use their super-standards mode is cleaner and more desirable as it doesn't bloat the spec, and should be more than enough for them. If their standards mode for HTML5 has flaws and they need a NEW switch, it can be changed to X-STANDARDS-MODE: HTML6; or whatever the latest version of HTML is. This can be set across an entire server in a few seconds via config files if needed, or set on a single folder via .htaccess files. If headers are used, that also doesn't bloat the file if is is saved on someone's HDD. [1] http://blog.whatwg.org/w3c-restarts-html-effort#comment-2020 [2] http://blog.whatwg.org/w3c-restarts-html-effort#comment-2022 [3] http://meyerweb.com/eric/thoughts/2006/08/14/angry-indeed/ [4] http://robertdot.org/2007/03/08/html-5-whatwg-versus-w3c.html
[whatwg] contentEditable - block breaks (enter)
contentEditable - block breaks (enter) -- A few weeks ago I was working with Anne van Kesteren on the contentEditable behaviour of Internet Explorer. I noticed IE does not behave correctly to my mind when it comes to block breaks (pressing the enter key). So I was wondering; how should block break behaviour work? I have written a small document on block break behaviour and I was wondering whether or not this is valuable for the WA spec. http://jorgenhorstink.nl/projects/whatwg/blockbreak.htm The document is not even nearly complete, but I want to start the discussion about contentEditable and block breaks. -jorgen
