Re: [whatwg] figureimg* caption
On Tue, Dec 1, 2009 at 7:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The @caption proposal isn't for an attribute on p only, but rather for an attribute on any element that is a child of a figure. (It's just that most of the time using a p is most appropriate.) Ah, OK. Well, given the circumstances, this does seem like the best approach, though I feel conditionally allowing certain attributes depending on an element's context is a step in the wrong direction. It's confusing given the way HTML will have worked up until that point; as a document author, although I expect elements themselves only to be allowed in certain contexts, I also expect them to carry all of their attributes with them when they are; i.e., attributes are perceived as belonging to the element within which they are set, not the parent of that element. Most of us agree that a more semantic element would be ideal here, yet we can't use one [yet] because of current technical limitations. That sounds like the very situation microformats was created to address. What if we used @itemprop as a placeholder for a future figure-caption element? To make things less verbose, figure could have an implied @itemscope and @itemtype unless specifically overwritten by the author. Ex: figure img src=figure.gif alt=graph p itemprop=captionThe findings/p /figure On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak m...@apple.com wrote: It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. Is this issue being addressed by the latest DOM specification? It seems there should really be a standard behavior for browsers when encountering unknown or unexpected elements that ensures that the next version of HTML is not similarly encumbered by this.
Re: [whatwg] figureimg* caption
On Dec 2, 2009, at 12:58 AM, Hugh Guiney wrote: On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak m...@apple.com wrote: It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. Is this issue being addressed by the latest DOM specification? It seems there should really be a standard behavior for browsers when encountering unknown or unexpected elements that ensures that the next version of HTML is not similarly encumbered by this. HTML5 parsing requirements will fix this both for legend and for unknown elements. For what it's worth, all non-IE browsers handle unknown elements in a consistent way, and IE can be made to do so by first creating an instance of said element in script. legend is not a new element though, it has a longstanding use in fieldset many of it's particular oddities stem from the fact that browsers have only expected it to appear inside fieldset, where it has specialized rendering. Regards, Maciej
Re: [whatwg] figureimg* caption
On Wed, 02 Dec 2009 03:58:32 +0100, Maciej Stachowiak m...@apple.com wrote: On Dec 1, 2009, at 4:08 PM, Tab Atkins Jr. wrote: On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney hugh.gui...@gmail.com wrote: Is there a reason we can't reuse legend (or label)? I don't think giving p an attribute that it can only use inside of figure is very straightforward. Yes. legend is documented as having rendering issues in all current browsers if placed outside of a fieldset (for example, in some browsers it will *generate a fieldset* around itself). label doesn't have appropriate keyboard accessibility when used for details. It's not just rendering issues - all current browsers produce a broken DOM when you include legend outside of fieldset, ranging from dropping the legend element entirely to creating a fieldset to doing the IE thing of adding void elements named legend and /legend (but without the usual script workaround. I don't think keyboard accessibility is a problem for label. details itself can be made focusable. I believe the only technical issues with label are: 1) Some sites already have style rules for label based on the assumption that it is only ever used for form labels. So they would have to tweak their CSS to be able to use details. I don't think this argument is very strong. 2) Using label could create issues in present-day browsers if the label includes a form control. Specifically the label would be considered the label of the form control if it has no other label, which may not be appropriate. This is somewhat unlikely but not altogether impossible. 3) If label were used for the caption, it would not be possible to use label as a form control label inside the figure caption (use case: hot or not). 4) If label were used for the caption, it would not be possible to use label as the figure content (can't think of a compelling use case for this, but it's currently allowed). Opinions on the seriousness of these two issues vary, but I must concede that the dt/dd solution does not have these two specific problems. BTW the current alternate proposal in the HTML Working Group is to replace dt/dd with a fltcap element to use as the label for both figure and details: http://esw.w3.org/topic/HTML/ChangeProposals/DdDt . Regards, Maciej -- Simon Pieters Opera Software
Re: [whatwg] localStorage feedback
Summary: I haven't removed the storage mutex, but I did adjust when it is released slightly to handle some cases that had been missed before. On Thu, 29 Oct 2009, Darin Fisher wrote: On Mon, Oct 12, 2009 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: the problem here is that localStorage is a pile of global variables. we are trying to give people global variables without giving them tools to synchronize access to them. the claim i've heard is that developers are not savy enough to use those tools properly. i agree that developers tend to use tools without fully understanding them. ok, but then why are we giving them global variables? The global variables have implicit locks such that you can build the tools for explicit locking on top of them: // run this first, in one script block var id = localStorage['last-id'] + 1; localStorage['last-id'] = id; localStorage['email-ready-' + id] = 0; // begin // these can run each in separate script blocks as desired localStorage['email-subject-' + id] = subject; localStorage['email-from-' + id] = from; localStorage['email-to-' + id] = to; localStorage['email-body-' + id] = body; // run this last localStorage['email-ready-' + id] = 1; // commit Dividing up work like this into separate SCRIPT elements to scope the locking seems really awkward to me. Oh I agree, I'm just saying that your original point -- that we are trying to give people global variables without giving them tools to synchronize access to them -- is mistaken insofar as we _are_ trying to give them tools to synchronise access, that's what this whole thread is basically about. It just happens that those tools have unfortunate side-effects (they can require synchronous blocking of other processes running code for the same domain). The current API exposes race conditions to the web. The implicit dropping of the storage lock is that. In Chrome, we'll have to drop an existing lock whenever a new lock is acquired. That can happen due to a variety of really odd cases (usually related to nested loops or nested JS execution), which will be difficult for developers to predict, especially if they are relying on third-party JS libraries. This issue seems to be discounted for reasons I do not understand. You can only lose the lock in very specific conditions. Those conditions are rarely going to interact with code that actually does storage work in a way that relies on the lock: - changing document.domain - history.back(), .forward(), .go(n) - invoking a plugin - alert(), confirm(), prompt(), print() - showModalDialog() - yieldForStorageUpdates() I discussed this in more detail here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html You are right that the conditions are specific, but I don't know that that is the exhaustive list. If it's not, then we should fix it. Rather than defining unlock points, I would implement implicit unlocking by having any nested attempt to acquire a lock cause the existing lock to be dropped. Nesting can happen in the cases you mention, but depending on the UA, it may happen for other reasons too. I don't think this is equivalent at all. Most of the release points are points where the thread is about to hang (sync XHR, alert(), etc) and we want to unlock other processes. The plugin case is about third-party code causing a deadlock through undetectable thread synchronisation (e.g. where a plugin causes code in another process to try to grab the lock and waits for that to complete before handing control back to the UA). The nesting defence only helps in the case of preventing deadlocks with two processes trying to grab different domains' locks in reverse order from each other, as far as I can tell, which is just a subset of the cases where it is released per the spec. This combined with the fact that most people use JS libraries means that the coder is not going to have an easy time knowing when these specific conditions are met. I don't think defining a set of allowed unlock points is sufficient to make this API not be a minefield for users. I don't think anyone is arguing that this is ideal. I do think it's orders of magnitude better than having the API be always racy even without any libraries being involved. For example, a JS library might evolve to use flash for something small (like storage or sound) that it previously didn't use when I first developed my code. Voila, now my storage lock is released out from under me. At least this is documentable. On Sat, 31 Oct 2009, Darin Fisher wrote: Unlock if yieldForStorageUpdates is called. Unlock when returning from script execution. Unlock if another attempt to lock occurs (any form of nesting). In the third case, I'd probably log something to the JS console to alert developers.
[whatwg] two minor things in history traversal
6.11.9, step 3.1: To me, this text: If the browsing context is a top-level browsing context (and not an auxiliary browsing context) seems to imply that an auxiliary b-c is not a top-level b-c. This is subjective of course, but it might be a good thing to rephrase the sentence into something like: If the browsing context is a top-level browsing context which is not an auxiliary browsing context or: If the browsing context is a top-level browsing context (but not an auxiliary browsing context) Or, I guess it would also be possible to invent a new term for independent top-level browsing contexts or something in the same spirit. 6.11.9, step 3.1.2: The browsing context's browsing context name must be unset. It might be good with a note that the browsing context name is only switched by the user agent for history traversal to another origin, and not for navigation to a new origin. Best regards Mike Wilson
Re: [whatwg] localStorage feedback
On Wed, Dec 2, 2009 at 2:06 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Nov 2009, Jeremy Orlow wrote: If we do this, we need to re-visit ways that scripts can tell whether the lock has been dropped. I can't remember which idea was most in favor last time we talked about it, but a counter that increments every time LocalStorage is unlocked sticks out in my mind. (Scripts can check the counter, do something that could cause unlocking, and then verify the counter is still the same after.) The counter could be a boolean -- does the event loop have the lock [for the origin of the first script]. I would recommend implementing this as a property window.navigator.webkitStorageUpdatesLocked which is true when the lock is obtained and false when it is released. If people find it useful, we can add it to the language. If it's a boolean, it's possible that it was implicitly unlocked and then re-locked. If you have a counter, you can simply check that the count is the same as when you started. Another option that just came to mind is to have some flag that says throw an exception whenever there's been a serialization violation. Could you elaborate on this? You'd have some boolean property that defaults to false (say navigator.throwOnStorageMutexDeadlocks) that when set to true would cause an exception to be thrown either immediately or the next time you try to do a localStorage operation before either calling navigator.yieldForStorageUpdates or the task ending. On Wed, 25 Nov 2009, Jeremy Orlow wrote: I know that we've discussed approximations of run to completion before, but maybe it's worth one more shot: What if on the first use of document.cookie or local storage we took a snapshot of both and used that during the task's execution. All writes would be queued up until the task finishes, at which point they'd be written to the central version of the cookie and/or local storage. This would provide a consistent view of data for the duration of the task and would solve almost all the atomicity problems except |document.cookie = document.cookie + foo;|. For that, I'd suggest adding a method that allows scripts to do atomic modifications to storage within a callback. I can understand everyone's desire to have completely serializable semantics for local storage access and cookies (if you don't count the servers' interaction with them), but maybe we need to go back to use cases. In a world with WebDatabase/WebSimpleDB, I really don't see anyone turning to LocalStorage except for more basic uses. Most of which I'm guessing need consistent reads much more than serialization of everything. And let's be realistic. IE has had this problem with document.cookie for a long time. And IE8 now has this problem with localStorage. Given that in the best case (MS and all others implement the storage mutex) web developers will not be able to assume localStorage and document.cookie access is atomic for many years at a minimum, I think we're being pretty unrealistic about how much the storage mutex is going to improve anyone's life. Let's come up with an approximation, give developers a callback for atomic access, and be done with it. As far as I can tell, this wouldn't remove race problems. It would in fact make it impossible to avoid them, since as far as I can tell you can't build a sane locking mechanism based on the above. I don't understand what you mean by building a sane locking mechanism. The idea is that we'd have near-run-to-completion semantics when using local storage normally (via repeatable reads semantics on localStorage and document.cookie) and actual run-to-completion semantics (serializable) if you use the callback based mechanism for localStorage access. Given that network based cookie access is essentially repeatable read semantics and both cookie and localStorage in IE and Chrome aren't even that currently, I'd say that such semantics seem good enough. The fact that Chrome has never gotten any complaints about the racy behavior of its current document.cookie implementation is some evidence to support that. J
Re: [whatwg] localStorage feedback
On Wed, 2 Dec 2009, Jeremy Orlow wrote: On Wed, Dec 2, 2009 at 2:06 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Nov 2009, Jeremy Orlow wrote: If we do this, we need to re-visit ways that scripts can tell whether the lock has been dropped. I can't remember which idea was most in favor last time we talked about it, but a counter that increments every time LocalStorage is unlocked sticks out in my mind. (Scripts can check the counter, do something that could cause unlocking, and then verify the counter is still the same after.) The counter could be a boolean -- does the event loop have the lock [for the origin of the first script]. I would recommend implementing this as a property window.navigator.webkitStorageUpdatesLocked which is true when the lock is obtained and false when it is released. If people find it useful, we can add it to the language. If it's a boolean, it's possible that it was implicitly unlocked and then re-locked. If you have a counter, you can simply check that the count is the same as when you started. Oh, I see. I misunderstood how the counter would work (I thought you meant it would go down again when unlocking). Yeah, that would work too. webkitStorageUpdatesLockedCount or something. Another option that just came to mind is to have some flag that says throw an exception whenever there's been a serialization violation. Could you elaborate on this? You'd have some boolean property that defaults to false (say navigator.throwOnStorageMutexDeadlocks) that when set to true would cause an exception to be thrown either immediately or the next time you try to do a localStorage operation before either calling navigator.yieldForStorageUpdates or the task ending. This would basically just be a development aid, then? I would be a bit worried about people accidentally enabling that kind of thing in production code and ending up with even more confusing user-facing bugs. It's generally been the kind of thing we've avoided standardising in the platform. It might make sense as some kind of UA-specific development aid, though. On Wed, 25 Nov 2009, Jeremy Orlow wrote: I know that we've discussed approximations of run to completion before, but maybe it's worth one more shot: What if on the first use of document.cookie or local storage we took a snapshot of both and used that during the task's execution. All writes would be queued up until the task finishes, at which point they'd be written to the central version of the cookie and/or local storage. This would provide a consistent view of data for the duration of the task and would solve almost all the atomicity problems except |document.cookie = document.cookie + foo;|. For that, I'd suggest adding a method that allows scripts to do atomic modifications to storage within a callback. I can understand everyone's desire to have completely serializable semantics for local storage access and cookies (if you don't count the servers' interaction with them), but maybe we need to go back to use cases. In a world with WebDatabase/WebSimpleDB, I really don't see anyone turning to LocalStorage except for more basic uses. Most of which I'm guessing need consistent reads much more than serialization of everything. And let's be realistic. IE has had this problem with document.cookie for a long time. And IE8 now has this problem with localStorage. Given that in the best case (MS and all others implement the storage mutex) web developers will not be able to assume localStorage and document.cookie access is atomic for many years at a minimum, I think we're being pretty unrealistic about how much the storage mutex is going to improve anyone's life. Let's come up with an approximation, give developers a callback for atomic access, and be done with it. As far as I can tell, this wouldn't remove race problems. It would in fact make it impossible to avoid them, since as far as I can tell you can't build a sane locking mechanism based on the above. I don't understand what you mean by building a sane locking mechanism. The idea is that we'd have near-run-to-completion semantics when using local storage normally (via repeatable reads semantics on localStorage and document.cookie) and actual run-to-completion semantics (serializable) if you use the callback based mechanism for localStorage access. If we decide to introduce a whole new API, then there are lots of things we could do that would make this much better, yes. I am not planning on introducing a fourth new storage API this year, though. I figure the Web needs time to get a handle on the ones we're introducing already. Without the additional API, I think it makes the storage mechanism much less reliable than no storage mutex at all. It would make it much more likely to have a
[whatwg] Web API for speech recognition and synthesis
We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson -- Bjorn Bringert Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902
Re: [whatwg] Web API for speech recognition and synthesis
On Wed, Dec 2, 2009 at 3:32 AM, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson Short answer: Yes, very :) Longer answer: APIs for accessing microphone and camera is something that I think is very needed. There's several aspects to this, ranging from simply uploading video/audio clips using an input type=file element, to streaming APIs that allow video/audio conferancing using a browser, to being able to do video/audio processing/playback inside the browser. There's a ton of work here to be done, anywhere you are willing to help would be hugely appreciated. / Jonas
Re: [whatwg] Web API for speech recognition and synthesis
Is speech support a feature of the web page, or the web browser? On Wed, Dec 2, 2009 at 12:32 PM, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson -- Bjorn Bringert Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902
Re: [whatwg] Web API for speech recognition and synthesis
I think that it would be best to extend the browser with a JavaScript speech API intended for use by web apps. That is, only web apps that use the speech API would have speech support. But it should be possible to use such an API to write browser extensions (using Greasemonkey, Chrome extensions etc) that allow speech control of the browser and speech synthesis of web page contents. Doing it the other way around seems like it would reduce the flexibility for web app developers. /Bjorn On Wed, Dec 2, 2009 at 4:55 PM, Mike Hearn m...@plan99.net wrote: Is speech support a feature of the web page, or the web browser? On Wed, Dec 2, 2009 at 12:32 PM, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson -- Bjorn Bringert Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902 -- Bjorn Bringert Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902
[whatwg] Syntax of void element
Hi WHATWG members, This was posted by Akatsuki Kitamura on the W3C Japanese Interest Group Mailing List. The section 9.2.1 of HTML5 spec says; Start tags must have the following format: 1. The first character of a start tag must be a U+003C LESS-THAN SIGN character (). 2. The next few characters of a start tag must be the element's tag name. 3. If there are to be any attributes in the next step, there must first be one or more space characters. 4. Then, the start tag may have a number of attributes, the syntax for which is described below. Attributes may be separated from each other by one or more space characters. 5. After the attributes, there may be one or more space characters. (Some attributes are required to be followed by a space. See the attributes section below.) 6. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing. 7. Finally, start tags must be closed by a U+003E GREATER-THAN SIGN character (). As far as I understand, if I want to write a void element with no attribute, such as the br, I do steps 1 ( character) and 2 (tag name), then ignore 3 and 4. In the step 5, since I don't have any attributes, the after the attribute situation does not apply here, so I ignore it too. Then I close the tag by going through step 6 (/ character) and step 7 ( character). Akatsuki's question was that if you write space characters before closing the tag like the following, if they are still valid or not. br br / I think the step 5 should be written as; After the attributes, or after the element's tag name if there are no attributes, then there may be one or more space characters. Thanks, A. Takayama
Re: [whatwg] Web API for speech recognition and synthesis
On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert bring...@google.com wrote: I think that it would be best to extend the browser with a JavaScript speech API intended for use by web apps. That is, only web apps that use the speech API would have speech support. But it should be possible to use such an API to write browser extensions (using Greasemonkey, Chrome extensions etc) that allow speech control of the browser and speech synthesis of web page contents. Doing it the other way around seems like it would reduce the flexibility for web app developers. Hmm.. I guess I misunderstood your original proposal. Do you want the browser to expose an API that converts speech to text? Or do you want the browser to expose access to the microphone so that you can do speech to text convertion in javascript? If the former, could you describe your use cases in more detail? / Jonas
Re: [whatwg] Web API for speech recognition and synthesis
I missunderstood too. It would be great to have the ability to access the microphone and record+upload or stream sound to the web server. -- D. On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote: On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert bring...@google.com wrote: I think that it would be best to extend the browser with a JavaScript speech API intended for use by web apps. That is, only web apps that use the speech API would have speech support. But it should be possible to use such an API to write browser extensions (using Greasemonkey, Chrome extensions etc) that allow speech control of the browser and speech synthesis of web page contents. Doing it the other way around seems like it would reduce the flexibility for web app developers. Hmm.. I guess I misunderstood your original proposal. Do you want the browser to expose an API that converts speech to text? Or do you want the browser to expose access to the microphone so that you can do speech to text convertion in javascript? If the former, could you describe your use cases in more detail? / Jonas signature.asc Description: This is a digitally signed message part
Re: [whatwg] Web API for speech recognition and synthesis
I agree that being able to capture and upload audio to a server would be useful for a lot of applications, and it could be used to do speech recognition. However, for a web app developer who just wants to develop an application that uses speech input and/or output, it doesn't seem very convenient, since it requires server-side infrastructure that is very costly to develop and run. A speech-specific API in the browser gives browser implementors the option to use on-device speech services provided by the OS, or server-side speech synthesis/recognition. /Bjorn On Wed, Dec 2, 2009 at 6:23 PM, Diogo Resende drese...@thinkdigital.pt wrote: I missunderstood too. It would be great to have the ability to access the microphone and record+upload or stream sound to the web server. -- D. On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote: On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert bring...@google.com wrote: I think that it would be best to extend the browser with a JavaScript speech API intended for use by web apps. That is, only web apps that use the speech API would have speech support. But it should be possible to use such an API to write browser extensions (using Greasemonkey, Chrome extensions etc) that allow speech control of the browser and speech synthesis of web page contents. Doing it the other way around seems like it would reduce the flexibility for web app developers. Hmm.. I guess I misunderstood your original proposal. Do you want the browser to expose an API that converts speech to text? Or do you want the browser to expose access to the microphone so that you can do speech to text convertion in javascript? If the former, could you describe your use cases in more detail? / Jonas -- Bjorn Bringert Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902
Re: [whatwg] Web API for speech recognition and synthesis
On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson This exists already, but only Opera supports it, although there are problems with the library we use for speech recognition. http://www.w3.org/TR/xhtml+voice/ http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/ Would be nice to revive that specification and get vendor buy-in. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] Web API for speech recognition and synthesis
If you're able to read from the mic, you don't need to upload. You could save it locally (for example for voice memos). The read+upload was just 2 steps I sugested instead of direct streaming. Speech recognition could be done separatly. One could use the mic to capture a voice note. Other could use the speech recognition without the mic (saved file?). Divide and conquer :) -- Diogo Resende drese...@thinkdigital.pt ThinkDigital On Wed, 2009-12-02 at 19:17 +, Bjorn Bringert wrote: I agree that being able to capture and upload audio to a server would be useful for a lot of applications, and it could be used to do speech recognition. However, for a web app developer who just wants to develop an application that uses speech input and/or output, it doesn't seem very convenient, since it requires server-side infrastructure that is very costly to develop and run. A speech-specific API in the browser gives browser implementors the option to use on-device speech services provided by the OS, or server-side speech synthesis/recognition. /Bjorn On Wed, Dec 2, 2009 at 6:23 PM, Diogo Resende drese...@thinkdigital.pt wrote: I missunderstood too. It would be great to have the ability to access the microphone and record+upload or stream sound to the web server. -- D. On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote: On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert bring...@google.com wrote: I think that it would be best to extend the browser with a JavaScript speech API intended for use by web apps. That is, only web apps that use the speech API would have speech support. But it should be possible to use such an API to write browser extensions (using Greasemonkey, Chrome extensions etc) that allow speech control of the browser and speech synthesis of web page contents. Doing it the other way around seems like it would reduce the flexibility for web app developers. Hmm.. I guess I misunderstood your original proposal. Do you want the browser to expose an API that converts speech to text? Or do you want the browser to expose access to the microphone so that you can do speech to text convertion in javascript? If the former, could you describe your use cases in more detail? / Jonas signature.asc Description: This is a digitally signed message part
[whatwg] Web Sockets URL
Currently, the Web Sockets API spec says that the WebSocket.URL attribute must just return a value that was passed to the WebSocket constructor. This doesn't match how many other url accessors work, and consequentially, it doesn't match what currently happens in WebKit. I think it makes more sense to return a resolved URL - e.g. (new WebSocket(ws://host/path/../)).URL would return ws://host/. - WBR, Alexey Proskuryakov
Re: [whatwg] Web API for speech recognition and synthesis
On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert bring...@google.com wrote: I agree that being able to capture and upload audio to a server would be useful for a lot of applications, and it could be used to do speech recognition. However, for a web app developer who just wants to develop an application that uses speech input and/or output, it doesn't seem very convenient, since it requires server-side infrastructure that is very costly to develop and run. A speech-specific API in the browser gives browser implementors the option to use on-device speech services provided by the OS, or server-side speech synthesis/recognition. Again, it would help a lot of you could provide use cases and requirements. This helps both with designing an API, as well as evaluating if the use cases are common enough that a dedicated API is the best solution. / Jonas
Re: [whatwg] Web API for speech recognition and synthesis
We're envisaging a simpler programmatic API that looks familiar to the modern Web developer but one which avoids the legacy of dialog system languages. Dave On Wed, Dec 2, 2009 at 7:25 PM, João Eiras jo...@opera.com wrote: On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson This exists already, but only Opera supports it, although there are problems with the library we use for speech recognition. http://www.w3.org/TR/xhtml+voice/ http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/ Would be nice to revive that specification and get vendor buy-in. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] Web API for speech recognition and synthesis
On Thu, 03 Dec 2009 01:50:20 +0100, Dave Burke davebu...@google.com wrote: We're envisaging a simpler programmatic API that looks familiar to the modern Web developer but one which avoids the legacy of dialog system languages. Ok. I referenced that XHTML+Voice because there is already a specification with markup, css 2 aural stylesheets and javascript APIs, and one implementation. I quite sure someone can revisit this whole issue, and refactor the xhtml+voice specification into something more acceptable and implementable. I don't think anyone would implement it the way it is. Dave On Wed, Dec 2, 2009 at 7:25 PM, João Eiras jo...@opera.com wrote: On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert bring...@google.com wrote: We've been watching our colleagues build native apps that use speech recognition and speech synthesis, and would like to have JavaScript APIs that let us do the same in web apps. We are thinking about creating a lightweight and implementation-independent API that lets web apps use speech services. Is anyone else interested in that? Bjorn Bringert, David Singleton, Gummi Hafsteinsson This exists already, but only Opera supports it, although there are problems with the library we use for speech recognition. http://www.w3.org/TR/xhtml+voice/ http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/ Would be nice to revive that specification and get vendor buy-in. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] HTML5 video element - default to fallback in cases where UA can't play format
On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote: On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose k...@iqmultimedia.com.au wrote: Can I get some sort of an understanding on why this behaviour (non- descript error in supported UAs rather than using the fallback content that can provide alternate access methods) would be preferred? Suppose browsers fell back to the contents if they couldn't play any of the sources. Then what happens if the browser isn't sure whether it can play a video until it's started loading it? This would be extremely common -- it would happen any time the source is given with src=, or if source elements are given with no type=, or even if there was a type= but the browser wasn't sure it supported the exact versions or didn't fully trust the author or whatnot. Then does the browser not load the contents until it figures out it can't play the video, then load the contents at some undefined later time? So scripts execute out of order and so on? Sorry to resurrect an old thread but I was using my iPhone and had an extra couple of questions about this I was hoping people might be able to answer for me. The iPhone (and other similar devices) are restricted to certain file formats and even bitrates/image sizes. When the iPhone encounters our video element, I can supply a non-compatible video (still in an MP4 container) and the iPhone knows to mark the video in place as non-playable. If I whack in a compatible H.264 video, the video is shown as playable. Can someone explain to me how this works, given Aryeh's response above? Surely if the iPhone can determine its capacity to be able to play a video file, other UAs could do likewise and fall back on the content accordingly as UAs with zero video support do? —Kit
[whatwg] value content attribute of input
Hi all Could you please see the section in the spec? http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element There is a table which includes summarizes which of content attributes, IDL attributes, methods, and events apply to each state. Is the value content attribute needed to include to the table, isn't it? -- Futomi Hatano www.html5.jp
Re: [whatwg] Thread to run Web Socket feedback from the protocol ?
I've question about thread to run Web Socket feedback from the protocol. If server sends back handshake response and a data frame, and close immediately, fast enough to run JavaScript on browser, how readyState should be? 1) When client recognizes handshake response header, it changes readyState to OPEN and queue a task to fire a simple event named open. 2) Then client reads a data frame, and queue a task to fire a MessageEvent. 3) Then client recognizes the socket is closed, it changes readyState to CLOSED and queue a task to fire a simple event named close. I'm wondering this process should be done on the same thread of the JavaScript, or may be on the different thread. If it should run on the same thread, 1) would be processed after JavaScript code is processed. Thus, readyState is OPEN when it receives open event. However, if it may run on the different thread, 1)-3) might be processed before JavaScript code is processed. So, readyState might be CLOSED when it receives open event. Which is correct behavior? It seems WebKit/Mac does former, and Chromium does latter, so LayoutTests/websocket/tests/simple.html would fail with Chromium. -- ukai
