Re: [whatwg] Codecs for audio and video
Hi Sylvia, On Sun, Aug 09, 2009 at 11:16:01AM +1000, Silvia Pfeiffer wrote: On Sun, Aug 9, 2009 at 3:15 AM, Chris McCormickch...@mccormick.cx wrote: On Wed, Jul 08, 2009 at 09:24:42AM -0700, Charles Pritchard wrote: There are two use cases that I think are important: a codec implementation (let's use Vorbis), and an accessibility implementation, working with a canvas element. Here are a few more use-cases that many people would consider just as important: * Browser based music software and synthesis toys. * New types of 'algorithmic' music like that pioneered by Brian Eno. * Browser based games which want to use procedural audio instead of pre-rendered sound effects. Why don't you just implement an example in javascript to show off what you're talking about and make a use case for having it implemented inside the browsers? Yes, you are right I should definately do that. What is the normal process for that: write some code, post it up on my website, and then post here with a link? Is that sufficient to get the attention of the browser implementors? By 'implement an example in javascript' do you mean that I should implement an example of what I wish the browsers could do, or implement an actual reference vector library that the browsers could use? The former I can see myself doing, but the latter has been on my TODO list long enough for me to know that I won't get it done any time soon. :/ Chris. --- http://mccormick.cx
Re: [whatwg] Codecs for audio and video
On Sun, Aug 9, 2009 at 7:20 PM, Chris McCormickch...@mccormick.cx wrote: Hi Sylvia, On Sun, Aug 09, 2009 at 11:16:01AM +1000, Silvia Pfeiffer wrote: On Sun, Aug 9, 2009 at 3:15 AM, Chris McCormickch...@mccormick.cx wrote: On Wed, Jul 08, 2009 at 09:24:42AM -0700, Charles Pritchard wrote: There are two use cases that I think are important: a codec implementation (let's use Vorbis), and an accessibility implementation, working with a canvas element. Here are a few more use-cases that many people would consider just as important: * Browser based music software and synthesis toys. * New types of 'algorithmic' music like that pioneered by Brian Eno. * Browser based games which want to use procedural audio instead of pre-rendered sound effects. Why don't you just implement an example in javascript to show off what you're talking about and make a use case for having it implemented inside the browsers? Yes, you are right I should definately do that. What is the normal process for that: write some code, post it up on my website, and then post here with a link? Is that sufficient to get the attention of the browser implementors? I would think so. Not automatically, of course, but it would go a long way. By 'implement an example in javascript' do you mean that I should implement an example of what I wish the browsers could do, or implement an actual reference vector library that the browsers could use? The former I can see myself doing, but the latter has been on my TODO list long enough for me to know that I won't get it done any time soon. :/ The former. Do it in javascript even if it is very slow. Just needs to demonstrate the idea and how useful it is for browser users. Regards, Silvia.
Re: [whatwg] small element should allow nested elements
On Fri, 07 Aug 2009 14:19:23 +0100, Remy Sharp r...@leftlogic.com wrote: Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. I suggested it in the w3c list, not this one. Link: http://lists.w3.org/Archives/Public/public-html/2009Jan/0130.html ... When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed Previously we got on a bit of a navelgaze about what constitutes legalese/ disclaimers and whether any sites actually use it. But given that browsers currently allow small to go round block level elements, I agree with Remy that we should document the current state of browsers and allow the element to be both inline and block, like a, ins and del. bruce
[whatwg] HTML5-warnings - request to publish as next heartbeat WD
I took some time this weekend to go through the HTML5 specification and write warning language for features that are currently either controversial or have long-standing bugs logged against them. It is important that we draw attention to the least stable sections of the HTML5 draft in order to align public expectation as we move towards Last Call. The only difference between this draft and Ian's latest draft are the warnings - there are no new technical additions or deletions. Since there are no new technical changes, there is no need to trigger a FPWD. I am requesting three things of the HTML WG: 1. That this version is published as the next heartbeat Working Draft. Specifically, this is not a FPWD since there are no technical changes and thus there are no additional patent concerns. 2. Two other independent voices to support the publishing of this draft. Without those voices, this proposal cannot be considered for publishing. 3. A poll is created with two options: [ ] Publish Ian's latest draft to address the heartbeat requirement. [ ] Publish Ian's latest draft with Manu's warning language to address the heartbeat requirement. Whichever option that receives more than 50% of the vote will be published. A tie will result in Ian's latest draft being published. Here is the complete diff-marked version: http://html5.digitalbazaar.com/specs/html5-warnings-diff.html Here is a link to every warning that was added to the HTML5 specification (this is the easiest way to review the changes): http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#editor-s-draft-date-08-August-2009 http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#urls http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#fetch http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#misinterpreted-for-compatibility http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#implied-strong-reference http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#other-metadata-names http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#microdata http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#predefined-type http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#obsolete http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-source-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#alt http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-head-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#navigating-across-documents http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-bb-element If Ian updates his spec, I can regenerate and republish an updated version of this document within an hour or two. The non-diff-marked specification can be found here: http://html5.digitalbazaar.com/specs/html5-warnings.html This version of the specification will be checked into W3C CVS when Mike(tm) clears its addition to the repository. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Released - Browser-based P2P Commerce http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/
Re: [whatwg] Codecs for audio and video
As an aside to Chris McCormick's comments, I wonder if it might also be useful/possible/appropriate (or not) to provide access to media data in the way that the ActionScript computeSpectrum function does: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/media/SoundMixer.html#computeSpectrum%28%29 Sample visualization using Canvas with computeSpectrum: http://www2.nihilogic.dk/labs/canvas_music_visualization/ Sam Dutton -- Message: 1 Date: Sun, 9 Aug 2009 11:16:01 +1000 From: Silvia Pfeiffer silviapfeiff...@gmail.com Subject: Re: [whatwg] Codecs for audio and video To: Chris McCormick ch...@mccormick.cx Cc: whatwg@lists.whatwg.org Message-ID: 2c0e02830908081816v74711d64ya72c8cc11550b...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 9, 2009 at 3:15 AM, Chris McCormickch...@mccormick.cx wrote: On Wed, Jul 08, 2009 at 09:24:42AM -0700, Charles Pritchard wrote: There are two use cases that I think are important: a codec implementation (let's use Vorbis), and an accessibility implementation, working with a canvas element. Here are a few more use-cases that many people would consider just as important: * Browser based music software and synthesis toys. * New types of 'algorithmic' music like that pioneered by Brian Eno. * Browser based games which want to use procedural audio instead of pre-rendered sound effects. I'd like to reiterate the previously expressed sentiment that only implementing pre-rendered audio playback is like having a browser that only supports static images loaded from the server instead of animations and canvas tags. What is really needed is a DSP vector processor which runs outside of ECMA script, but with a good API so that the ECMAscripts can talk to it directly. Examples of reference software, mostly open source, which do this type of thing follow: * Csound * Supercollider * Pure Data * Nyquist * Chuck * Steinberg VSTs I am going to use the terms signal vector, audio buffer, and array interchangeably below. Four major types of synthesis would be useful, but they are pretty much isomorphic, so any one of them could be implemented as a base-line: * Wavetable (implement vector write/read/lookup operators) * FM AM (implement vector + and * operators) * Subtractive (implement unit delay from which you can build filters) * Frequency domain (implemnt FFT and back again) Of these, I feel that wavetable synthesis should be the first type of synthesis to be implemented, since most of the code for manipulating audio buffers is already going to be in the browsers and exposing those buffers shouldn't be hugely difficult. Basically what this would take is ensuring some things about the audio tag: * Supports playback of arbitrarily small buffers. * Seamlessly loops those small buffers. * Allows read/write access to those buffers from ECMAscript. Given the above, the other types of synthesis are possible, albeit slowly. For example, FM AM synthesis are possible by adding adding/multiplying vectors of sine data together into a currently looping audio buffer. Subtractive synthesis is possible by adding delayed versions of the data in the buffer to itself. Frequency domain synthesis is possible by analysing the data in the buffer with FFT (and reverse FFT) and writing back new data. I see this API as working as previously posted, by Charles Prichard, but with the following extra possibility: audio id='mybuffer' buffer = document.getElementById(mybuffer); // here myfunc is a function which will change // the audio buffer each time the buffer loops buffer.loopCallback = myfunc; buffer.loop = True; buffer.play(); Of course, the ECMA script is probably going to be too slow in the short term, so moving forward it would be great if there was a library/API which can do the following vector operations in the background at a speed faster than doing them directly, element by element inside ECMAscript (a bit like Python's Numeric module). All inputs and outputs are signal vectors/audio tag buffers: * + - add two signal vectors (2 input, 1 output) * * - multiply two signal vectors (2 input, 1 output) * z - delay a signal vector with customisable sample length (2 input, 1 output) * read - do a table lookup (1 input, 1 output) * write - do a table write (2 input, 1 output) * copy - memcpy a signal vector (1 input, 1 output) * fft do a fast fourier transform - (1 input, 2 output) * rfft do a reverse fast fourier transform - (2 inputs, 1 output) It would be so great if it was possible to unify the above into an API that looked and worked something like this: audio id='mybuffer' outbuffer = document.getElementById(mybuffer); b = new AudioBuffer(64) for (x=0; x64; x++) ? ? ? ?b[x] = Math.sin(x / 64 * Math.PI)a; // inside the loopCallback do a vector multiplication of the data in our buffer //
Re: [whatwg] HTML5-warnings - request to publish as next heartbeat WD
On Sun, Aug 9, 2009 at 8:32 AM, Manu Spornymspo...@digitalbazaar.com wrote: I took some time this weekend to go through the HTML5 specification and write warning language for features that are currently either controversial or have long-standing bugs logged against them. It is important that we draw attention to the least stable sections of the HTML5 draft in order to align public expectation as we move towards Last Call. The only difference between this draft and Ian's latest draft are the warnings - there are no new technical additions or deletions. Since there are no new technical changes, there is no need to trigger a FPWD. I am requesting three things of the HTML WG: 1. That this version is published as the next heartbeat Working Draft. Specifically, this is not a FPWD since there are no technical changes and thus there are no additional patent concerns. 2. Two other independent voices to support the publishing of this draft. Without those voices, this proposal cannot be considered for publishing. 3. A poll is created with two options: [ ] Publish Ian's latest draft to address the heartbeat requirement. [ ] Publish Ian's latest draft with Manu's warning language to address the heartbeat requirement. Whichever option that receives more than 50% of the vote will be published. A tie will result in Ian's latest draft being published. Here is the complete diff-marked version: http://html5.digitalbazaar.com/specs/html5-warnings-diff.html Here is a link to every warning that was added to the HTML5 specification (this is the easiest way to review the changes): http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#editor-s-draft-date-08-August-2009 http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#urls http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#fetch http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#misinterpreted-for-compatibility http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#implied-strong-reference http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#other-metadata-names http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#microdata http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#predefined-type http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#obsolete http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-source-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#alt http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-head-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#navigating-across-documents http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-bb-element If Ian updates his spec, I can regenerate and republish an updated version of this document within an hour or two. The non-diff-marked specification can be found here: http://html5.digitalbazaar.com/specs/html5-warnings.html This version of the specification will be checked into W3C CVS when Mike(tm) clears its addition to the repository. I think it appropriate to note that the #urls section willfully violates existing specs for legacy web compat reasons, as you have done with #misinterpreted-for-compatibility. I don't recall any controversy being generated around #implied-strong-reference. Was it only on the HTMLWG list, or perhaps far enough in the past that it predated my following the WHATWG list? The warning text for #alt is incorrect - the concerns that have been raised are about @alt being *omitted*, not left blank. Blank @alt is perfectly fine and the only correct value for the attribute in many cases. In many of the code examples strewn throughout the diff-marked document, the text will suddenly change to one word per line, which makes it very difficult to follow (I noted it especially in the #alt section, as it has tons of examples). There doesn't seem to be any rhyme or reason to this, as it can happen in the middle of an example and then switch back to normal behavior before the block is closed. This problem is not present in the non-diff-marked version. ~TJ
[whatwg] Removing versioning from HTML
[If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. - a
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 11:10 AM, Aaron Boodmana...@google.com wrote: [If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. A feature that is not widely supported is a feature we authors can't depend on. If we're lucky, we can put in some extra effort to work around the lack and still deliver a decent experience. If we're not, we simply don't do what we wanted, or deliver something inferior that relies on technologies we *can* rely on. The idea behind pushing something to the next version is that it gives implementors time to catch up to the spec and converge on what they support. This is good for people like me. ^_^ In the meantime, there's certainly nothing preventing someone from exploring an idea. The fact that it won't make it into a spec *yet* doesn't mean you can't still discuss and refine it, or implement test versions of it in js, or anything else. ~TJ
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 11:10 AM, Aaron Boodman a...@google.com wrote: [If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. - a If we never cut things off then the spec will really never be finished before 2020. I agree that somethings can be reopened but there are also some which have been resolved and any new discussions are coming a year++ later. -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 9:21 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: A feature that is not widely supported is a feature we authors can't depend on. If we're lucky, we can put in some extra effort to work around the lack and still deliver a decent experience. If we're not, we simply don't do what we wanted, or deliver something inferior that relies on technologies we *can* rely on. Clearly, but how does limiting the things that vendors can work on affect this one way or the other? I think there is an assumption that vendors will implement something solely because it is in the spec. This is not true, and can be verified by looking at history. Just yesterday, Jonas mentioned that Mozilla was less than enthused about implementing the bb tag from HTML5. Microsoft recently suggested they weren't happy with some of the new tags introduced in HTML5. And Ian has repeatedly said that he is not interested in writing fiction: he will only spec something that vendors will implement. The idea behind pushing something to the next version is that it gives implementors time to catch up to the spec and converge on what they support. This is good for people like me. ^_^ I don't think implementations will ever catch up. Partial mixed support is the natural state of a system where there are several completing implementations, and it is healthy. Some ideas aren't good. We shouldn't halt work on other things waiting for everyone to implement every idea. That is a recipe for stagnation. Instead, let some ideas die on the vine, and let growth occur in other places. If authors want a vendor to implement something, they will still be able to put pressure on the vendor to do that. In fact, that is exactly what happens today. Ian frequently says if you want that, please go talk to the vendors. In the meantime, there's certainly nothing preventing someone from exploring an idea. The fact that it won't make it into a spec *yet* doesn't mean you can't still discuss and refine it, or implement test versions of it in js, or anything else. In theory this is true. In practice, there is a lot of nice infrastructure setup at WhatWG that would be nice to reuse. Plus the WhatWG mailing list has become a very nice place for vendors to come together and discuss browser futures. What I am suggesting is that there should be no limit to the number of micro specs in a draft state concurrently at WhatWG. On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannonashannon1...@gmail.com wrote: If we never cut things off then the spec will really never be finished before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? - a
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannonashannon1...@gmail.com wrote: If we never cut things off then the spec will really never be finished before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? - a If you are looking for quantity of features then yes it is better, but if you are looking for quality of implementations then the latter is not as good. I would highly prefer IE to have video, audio, canvas, geoLocation implemented in IE9 than wasting that update trying to decide if we should reopen the codec issue (example of possible debate). Sure, if we can wait 10 years for HTML5 then neither matters, but I don't think that we have that option. A 20 year spec will not stand the test of time nor provide the needed qualifications for the pace of development. -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] Removing versioning from HTML
On 8/9/09 7:10 PM, Aaron Boodman wrote: [If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. If you say the HTML5 draft should be split to many smaller parts, I agree. We need to be able to say that some feature is stable i.e. recommendation. Without stability it is pretty awkward to implement anything, IMO Currently there is the draft where one can just guess the stability of the features. HTML5 should contain just the core features of the web platform. Everything else should go to some other specifications. Also, I believe splitting the spec would make it more readable. -Olli
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 11:50 AM, Aaron Boodmana...@google.com wrote: On Sun, Aug 9, 2009 at 9:21 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: A feature that is not widely supported is a feature we authors can't depend on. If we're lucky, we can put in some extra effort to work around the lack and still deliver a decent experience. If we're not, we simply don't do what we wanted, or deliver something inferior that relies on technologies we *can* rely on. Clearly, but how does limiting the things that vendors can work on affect this one way or the other? I think there is an assumption that vendors will implement something solely because it is in the spec. This is not true, and can be verified by looking at history. Just yesterday, Jonas mentioned that Mozilla was less than enthused about implementing the bb tag from HTML5. Microsoft recently suggested they weren't happy with some of the new tags introduced in HTML5. And Ian has repeatedly said that he is not interested in writing fiction: he will only spec something that vendors will implement. Certainly, but the spec gives some nice direction. Nobody implemented the new input types, frex, until someone wrote it up; now Opera has some decent support for it, while Webkit is starting support. Aiming at a target, especially one that you know other people will probably also be aiming at, is a lot easier than coding up a new feature that you just dreamed up. The idea behind pushing something to the next version is that it gives implementors time to catch up to the spec and converge on what they support. This is good for people like me. ^_^ I don't think implementations will ever catch up. Partial mixed support is the natural state of a system where there are several completing implementations, and it is healthy. Some ideas aren't good. We shouldn't halt work on other things waiting for everyone to implement every idea. That is a recipe for stagnation. Instead, let some ideas die on the vine, and let growth occur in other places. Not completely, sure. But they'll get closer. And we certainly won't wait for everyone to implement everything - the 2022 date that keeps getting bandied about was Ian's estimation of when complete conformance from 2 browsers would first happen. HTML6 will start *long* before that. Giving people a bit of breathing room, though, and a static target to code towards, helps out. If authors want a vendor to implement something, they will still be able to put pressure on the vendor to do that. In fact, that is exactly what happens today. Ian frequently says if you want that, please go talk to the vendors. Agreed. However, using *only* author feedback to direct browser implementors seems insufficient when we can also direct it in a useful manner by the spec. In the meantime, there's certainly nothing preventing someone from exploring an idea. The fact that it won't make it into a spec *yet* doesn't mean you can't still discuss and refine it, or implement test versions of it in js, or anything else. In theory this is true. In practice, there is a lot of nice infrastructure setup at WhatWG that would be nice to reuse. Plus the WhatWG mailing list has become a very nice place for vendors to come together and discuss browser futures. What I am suggesting is that there should be no limit to the number of micro specs in a draft state concurrently at WhatWG. Nobody's preventing that sort of discussion, even if Ian says Not for HTML5. On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannonashannon1...@gmail.com wrote: If we never cut things off then the spec will really never be finished before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? That reality is fantasy, though. ^_^ The rate at which an implementor can code is independent of the number of features that are in the spec. Increase the number of features (and assume some reasonable distribution of interest among the features) and the % of them that are interoperably implemented, especially within a given time frame, will drop. There's clearly some optimizing to be done - it's silly to spec only one thing at a time and wait for everyone to implement it, but an unbounded spec size is also bad. Ian's charting a course that already leans heavily into the lots of features side of the debate, and I disagree that pushing it further in that direction will necessarily help interop. ~TJ (Imo, we are getting *way* too meta about the whole thing lately. Meta is rarely a good thing...)
Re: [whatwg] HTML5-warnings - request to publish as next heartbeat WD
Hi Manu, Manu Sporny wrote: I took some time this weekend to go through the HTML5 specification and write warning language for features that are currently either controversial or have long-standing bugs logged against them. It is important that we draw attention to the least stable sections of the HTML5 draft in order to align public expectation as we move towards Last Call. Thanks a lot for that. The only difference between this draft and Ian's latest draft are the warnings - there are no new technical additions or deletions. Since there are no new technical changes, there is no need to trigger a FPWD. I am requesting three things of the HTML WG: 1. That this version is published as the next heartbeat Working Draft. Specifically, this is not a FPWD since there are no technical changes and thus there are no additional patent concerns. Sounds good to me. 2. Two other independent voices to support the publishing of this draft. Without those voices, this proposal cannot be considered for publishing. I support that, even though I have some remarks about the actual warnings (or their lack of). 3. A poll is created with two options: [ ] Publish Ian's latest draft to address the heartbeat requirement. [ ] Publish Ian's latest draft with Manu's warning language to address the heartbeat requirement. Whichever option that receives more than 50% of the vote will be published. A tie will result in Ian's latest draft being published. Here is the complete diff-marked version: http://html5.digitalbazaar.com/specs/html5-warnings-diff.html Here is a link to every warning that was added to the HTML5 specification (this is the easiest way to review the changes): http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#editor-s-draft-date-08-August-2009 http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#urls I think that note should be rephrased; as far as I can tell, W3C, WHATWG and IETF people are working together to improve the situation. The main risk here is that revising RFC3987 (IRI) may take longer than we all wish, due to unrelated issues. http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#fetch http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#misinterpreted-for-compatibility http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#implied-strong-reference http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#other-metadata-names http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#microdata http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#predefined-type http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#obsolete http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-source-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#alt http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-head-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#navigating-across-documents http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-bb-element ... I agree with those. Optimally, the hyperlink auditing (a/@ping) section should be mentioned as well. If Ian updates his spec, I can regenerate and republish an updated version of this document within an hour or two. The non-diff-marked specification can be found here: http://html5.digitalbazaar.com/specs/html5-warnings.html This version of the specification will be checked into W3C CVS when Mike(tm) clears its addition to the repository. -- manu BR, Julian
Re: [whatwg] HTML5-warnings - request to publish as next heartbeat WD
On Aug 9, 2009, at 6:32 AM, Manu Sporny wrote: 3. A poll is created with two options: [ ] Publish Ian's latest draft to address the heartbeat requirement. [ ] Publish Ian's latest draft with Manu's warning language to address the heartbeat requirement. If we indeed have a draft, then I'd like to have the option to vote yes or no on either draft independently, instead of either-or. For example, some people may wish to vote for both, and I would like to have that opportunity, though I would probably only exercise it if Manu's draft is changed. Sam's call for multiple drafts was based on the premise that they would be published independently, not that we'd have either-or votes. Whichever option that receives more than 50% of the vote will be published. A tie will result in Ian's latest draft being published. Here is the complete diff-marked version: http://html5.digitalbazaar.com/specs/html5-warnings-diff.html Here is a link to every warning that was added to the HTML5 specification (this is the easiest way to review the changes): I don't agree that this is a correct and reasonable set of controversial issues. Some of these are longstanding points of contention, it is true. Others are areas where the spec has already been changed or is in the process of being changed to address concerns. Still others are very recent feedback that has not been raised to the editor at all. Still others have not been properly raised as feedback to at all. For example, I don't recall seeing any objections to the garbage collection section. If you limit your list to open issues that have been unresolved for at least 6 months without meaningful progress (with reference to an issue tracker issue, or a mailing list post, dating back at least 6 months) and if you remove the other (seemingly unintended) technical differences from Ian's draft (such as adding back the Database section), then I will support publication of your draft in addition to Ian's. I don't think I can sign on to marking up a seemingly arbitrary grab bag of issues. http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#editor-s-draft-date-08-August-2009 http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#urls http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#fetch http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#misinterpreted-for-compatibility http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#implied-strong-reference http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#other-metadata-names http://html5.digitalbazaar.com/specs/html5-warnings- diff.html#microdata http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#predefined-type http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#obsolete http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-source-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#alt http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-head-element http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#navigating-across-documents http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-bb-element If Ian updates his spec, I can regenerate and republish an updated version of this document within an hour or two. The non-diff-marked specification can be found here: http://html5.digitalbazaar.com/specs/html5-warnings.html This version of the specification will be checked into W3C CVS when Mike(tm) clears its addition to the repository. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Released - Browser-based P2P Commerce http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/
[whatwg] Request in bug 7144
In bug 7144, somebody wrote: I am not sure if we are ditching ALT in favour of legend. You don't make this clear here. Some of your alt examples here resemble longdesc, which I am in favour of ditching completely. I'd be interested to see your answer on whatwg list about this It's not clear to me exactly what the question is here. alt= is not being ditched; it's a very important part of using images on the Web. I'm not sure what to add that isn't already said in the spec, though. The relevant section is pretty detailed. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList: mutation clarification
On Thu, 9 Jul 2009, Sylvain Pasche wrote: 1) in http://www.whatwg.org/specs/web-apps/current-work/#common-dom-interfaces When the attribute is absent, then the string represented by the object is the empty string; when the object mutates this empty string, the user agent must first add the corresponding content attribute, and then mutate that attribute instead Does it mean it should fire two DOMAttrModified events, one with the empty string addition, and the other with the attribute mutation? I think it should simply fire only one mutation event in that case as in all other cases (should be simpler and more efficient, although that case shouldn't happen very often). I don't see a good reason to fire one with the empty string. I've reworded it to imply only one mutation event fires. 2) (using the class attribute for the discussion) What should happen when you do a remove(foo) on an element which has no class attribute? My understanding is that it shouldn't add a class attribute with an empty string. That's because the remove() algorithm starts with an empty string and doesn't change it, so the when the object mutates this empty string, case shouldn't be true (and thus no attribute modification should happen). However Simon's testcase [1] doesn't agree with this, and adds an empty string. So maybe it's worth clarifying this situation? I think that the spec now implies that you set the attribute to the empty string. Do you agree? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Alt attribute for video and audio
Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Remco
Re: [whatwg] Alt attribute for video and audio
At 1:12 +0200 10/08/09, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Your search was too quick...we are discussing accessibility provisions for video and audio in general. Have a look under that. I think alt has been shown to have problems as well as provisions...perhaps we can find a better way? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Alt attribute for video and audio
Am Montag, den 10.08.2009, 01:12 +0200 schrieb Remco: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Hmm … subtitles have not been discussed before ? I don't think so. Or what else do you think could enhance accessability ? Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Alt attribute for video and audio
On 10/08/2009 00:12, Remco wrote: Shouldn'tvideos andaudios (and maybeobjects too?) also have an alt attribute? Bearing in mind: http://www.w3.org/TR/WCAG20/#text-equiv and http://www.w3.org/TR/WCAG20/#media-equiv What function would alt on video serve? -- Benjamin Hawkes-Lewis
Re: [whatwg] Alt attribute for video and audio
My search was indeed too quick. I stand corrected. Captions/subtitles seem like a very good idea for accessibility, but in addition to that I think that an alt attribute would still be appropriate for browsers that can't display the media at all. The alt is a replacement for an external element that cannot be displayed at all for whatever reason. It replaces the element. That's why I would suggest alt attributes for objects, embeds, frames, etc. too. Remco
Re: [whatwg] Alt attribute for video and audio
On Sun, Aug 9, 2009 at 6:50 PM, Remcoremc...@gmail.com wrote: My search was indeed too quick. I stand corrected. Captions/subtitles seem like a very good idea for accessibility, but in addition to that I think that an alt attribute would still be appropriate for browsers that can't display the media at all. The alt is a replacement for an external element that cannot be displayed at all for whatever reason. It replaces the element. That's why I would suggest alt attributes for objects, embeds, frames, etc. too. If a particular UA does not support the video element at all, it should display the fallback content inside the element. ~TJ
Re: [whatwg] HTML5-warnings - request to publish as next heartbeat WD
On Aug 9, 2009, at 2:16 PM, Maciej Stachowiak wrote: If you limit your list to open issues that have been unresolved for at least 6 months without meaningful progress (with reference to an issue tracker issue, or a mailing list post, dating back at least 6 months) and if you remove the other (seemingly unintended) technical differences from Ian's draft (such as adding back the Database section), then I will support publication of your draft in addition to Ian's. I don't think I can sign on to marking up a seemingly arbitrary grab bag of issues. To clarify somewhat: the 6 month threshold is one example of a rule I could support. But I would find a wide range of rules acceptable. My only hard requirements are: (a) The rule has to have a reasonable relationship to what can be considered a controversial open issue (b) The rule has to be reasonably objective. (c) The rule should not be so broad that it would apply to almost every open issue. (d) It needs to be stated clearly what the rule is. If any issue gets this kind of distinctive marker, then I will expect the Chairs to make it a high priority to promptly bring it to a definitive resolution. Regards, Maciej
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 2:15 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: On Sun, Aug 9, 2009 at 6:50 PM, Remcoremc...@gmail.com wrote: My search was indeed too quick. I stand corrected. Captions/subtitles seem like a very good idea for accessibility, but in addition to that I think that an alt attribute would still be appropriate for browsers that can't display the media at all. The alt is a replacement for an external element that cannot be displayed at all for whatever reason. It replaces the element. That's why I would suggest alt attributes for objects, embeds, frames, etc. too. If a particular UA does not support the video element at all, it should display the fallback content inside the element. ~TJ But that fallback content will not be rendered when the video isn't available. The same is true for audio. Object, embed and iframe don't have any fallback at all. If these external resources are unavailable, or if administrative policies prevent loading of external resources, there is no alternative content. It will just be an empty square on the page (or skipped by a screenreader / ignored by a textual browser, etc.). I would argue that alternative content is just as useful for any external content as it is for the specific external content that is images. Remco
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 9:22 AM, David Singersin...@apple.com wrote: At 1:12 +0200 10/08/09, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Your search was too quick...we are discussing accessibility provisions for video and audio in general. Have a look under that. I think alt has been shown to have problems as well as provisions...perhaps we can find a better way? Dave, I'd be curious to hear what those problems and provisions are for video and audio. Even though I'm a strong supporter of solving the subtitles/captions/i18n/sign language/audio annotation a11y issues of video and audio, I still believe that alt may have a use similar to what it is used for with images. E.g. when you tab onto a video element, the alt tag could give a very brief summary as to what the video is about, e.g. Elephant Dreams video. It would be much shorter and not time-aligned. But I am curious in people's opinions about this. Cheers, Silvia.
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 4:13 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: On 10/08/2009 02:22, Silvia Pfeiffer wrote: E.g. when you tab onto avideo element, the alt tag could give a very brief summary as to what the video is about, e.g. Elephant Dreams video. Don't the following already do that: 1. video title=Elephant Dreams video ... 2. h3 id=elephantsElephant Dreams video/h3video aria-labelledby=elephants ... 3. video aria-label=Elephant Dreams video ... What would alt add here? -- Benjamin Hawkes-Lewis A title is a short description, and could be the movie title in the case of a video element. An alt is a textual alternative for the content. It conveys the same meaning as the img, audio, video, iframe, ... element. It doesn't describe the content: it *is* the content. For an image this usually works well. An image usually doesn't convey a lot of meaning. It can be replaced by a simple sentence like A young dog plays with a red ball on the grass.. For video, audio, object, iframe, this is a little sparse. Shortening Elephants Dream's content to An old man and a young boy walk through a surrealistic world and have a conversation. doesn't tell you a lot about the content. But it is very helpful if the content is not available. It is even more helpful if it isn't as short as the previous alt-text for Elephants Dream. If it gives more details about what you see and hear in the video, you get information that for example a plot description doesn't provide. But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. Remco
