Re: [whatwg] Stream API Feedback
On 2011-03-14 17:59, Lachlan Hunt wrote:
There are a few issues with the recently added media streaming API.
In addition to what I sent previously, there are some additional use
cases that do not appear to be addressed adequately by the current spec
for streaming media.
In chat clients, like Skype, it's common for users to be able to adjust
the microphone volume or mute the audio stream, or to enable or disable
the video stream, without interupting the call. However, the
GeneratedStream interface only provides a very simple API to pause,
resume or stop the entire stream, and not individual tracks within the
stream.
e.g.
var stream;
navigator.getUserMedia(audio,video, success);
function success(s) {
stream = s;
// ... Code to make P2P connection for video chat
}
In this case, stream.pause() will pause both the audio and video
streams, whereas the user, for example, may just temporarily want to
pause the video stream, leaving the audio enabled.
While it may be possible for the browser to allow such control entirely
from the browser chrome, independently of the page, the page author may
wish to provide customised controls for these features. I believe the
API should be adjusted to allow the individual tracks within a stream to
be paused or resumed independently of each other, and for there to be
some way to adjust or mute the microphone volume.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] device use cases
Where did you hear that device was cancelled? On Tue, Mar 15, 2011 at 14:10, jesp...@opera.com wrote: Hi! I just heard that device was canceled and replaced by navigator.getUserMedia()... Just wanted to point out a couple of use cases that I was looking forward to, that seems to maybe have gotten a bit lost on the way? I was really looking forward to start playing around with USB MIDI interfaces to control my synth and maybe even do really creative stuff the other way around. Just imagine being able to play on your synth (or any other device with MIDI output) and generate sound or graphics in a canvas web application or so! Or... be able to control other devices using serial connection. Maybe do lirc-alike stuff, using your IR based remote to control Youtube or other HTML5 video services, etc. Amazing new possibilities, that would be (almost) endless... :)
Re: [whatwg] device use cases
On Tue, Mar 15, 2011 at 14:26, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Where did you hear that device was cancelled? On Tue, Mar 15, 2011 at 14:10, jesp...@opera.com wrote: Hi! I just heard that device was canceled and replaced by navigator.getUserMedia()... Just wanted to point out a couple of use cases that I was looking forward to, that seems to maybe have gotten a bit lost on the way? I was really looking forward to start playing around with USB MIDI interfaces to control my synth and maybe even do really creative stuff the other way around. Just imagine being able to play on your synth (or any other device with MIDI output) and generate sound or graphics in a canvas web application or so! Or... be able to control other devices using serial connection. Maybe do lirc-alike stuff, using your IR based remote to control Youtube or other HTML5 video services, etc. Amazing new possibilities, that would be (almost) endless... :) The following change was committed to the specification yesterday: http://html5.org/tools/web-apps-tracker?from=5944to=5945 Most references to the device element have been removed as well, and this section has been introduced: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#obtaining-local-multimedia-content Regards, Peter Beverloo
Re: [whatwg] device use cases
On Tue, 15 Mar 2011 14:26:29 +0100, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Where did you hear that device was cancelled? http://html5.org/tools/web-apps-tracker?from=5944to=5945 Detailed responses to feedback on the topic will be sent out soon. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] device use cases
On 2011-03-15 14:10, jesp...@opera.com wrote: I just heard that device was canceled and replaced by navigator.getUserMedia()... Just wanted to point out a couple of use cases that I was looking forward to, that seems to maybe have gotten a bit lost on the way? I was really looking forward to start playing around with USB MIDI interfaces to control my synth and maybe even do really creative stuff the other way around. Just imagine being able to play on your synth (or any other device with MIDI output) and generate sound or graphics in a canvas web application or so! It may be possible to address these use cases using an API based approach in the future, which will be better than the element based approach of device, but at this stage it is better to keep things simple and focus on just audio and video for now. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Form input element for value-unit pairs
Jukka K. Korpela: Christoph Päper wrote: input type=number id=fontsize value=12 unit=pt Or do you mean that the presence of the unit=... attribute would trigger a special implementation of numeric input, so that the user is expected to enter both a number and a unit, with the latter defaulted according to the unit attribute? Yes. UIs may autoconvert the value if the unit changes or keep it. I’m not sure which solution is better. Although the need for number unit input is relatively common, I think it can quite satisfactorily be handled using a number input field and e.g. a dropdown menu of units accepted by an application (or maybe a textfield). After all, processing of the form data would most probably want to split a combined number unit data item into its components, so why put them together in the first place? Usability. Maybe it would work better with ‘datalist’: input name=fontsize type=number unit=typo datalist id=typo option value=2.835 label=pt option value=1 label=mm /datalist or input name=fontsize type=number unit=#typo datalist id=typo option value=pt label=point option value=mm label=millimetre /datalist
Re: [whatwg] Form input element for value-unit pairs
Am 15.03.2011 17:36 schrieb Christoph Päper: Jukka K. Korpela: Christoph Päper wrote: input type=number id=fontsize value=12 unit=pt Or do you mean that the presence of the unit=... attribute would trigger a special implementation of numeric input, so that the user is expected to enter both a number and a unit, with the latter defaulted according to the unit attribute? Yes. UIs may autoconvert the value if the unit changes or keep it. I’m not sure which solution is better. Although the need for number unit input is relatively common, I think it can quite satisfactorily be handled using a number input field and e.g. a dropdown menu of units accepted by an application (or maybe a textfield). After all, processing of the form data would most probably want to split a combined number unit data item into its components, so why put them together in the first place? Usability. Maybe it would work better with ‘datalist’: input name=fontsize type=number unit=typo datalist id=typo option value=2.835 label=pt option value=1 label=mm /datalist I like this approach because it is author configurable and extensible beyond the rich text editor use case. A billing application might apply a list of currencies with appropriate exchange rates for the day. What I do not yet understand is, in what point does this proposal enhance usability compared to a dropdown box with the units, and some client side script that does the conversion?
Re: [whatwg] Interpretation issue: can section be used for extended
Why would anyone want to include lists inside paragraphs? Aside from those very old, ancient documents/sites that are left out there, who left out the closing tags for paragraphs? Where you would typically see one large paragraph of text in books (to save space), you would see the same paragraph breaken up into multiple paragraphs on a web page, for readability purposes.. I would generally recommend to break it up, and create a new paragraph after the table, list, or whatever you included. Even though that browsers may not have an outline, and might not need one? some can still find proper use of sectioning elements useful. I.e. Search engines, and assistive devices. Jacob Kristensen http://blueboden.com/
Re: [whatwg] Interpretation issue: can section be used for extended
On Tue, 2011-03-15 at 19:47 +0100, Jacob Kristensen wrote: Why would anyone want to include lists inside paragraphs? Aside from those very old, ancient documents/sites that are left out there, who left out the closing tags for paragraphs? Where you would typically see one large paragraph of text in books (to save space), you would see the same paragraph breaken up into multiple paragraphs on a web page, for readability purposes.. I would generally recommend to break it up, and create a new paragraph after the table, list, or whatever you included. Even though that browsers may not have an outline, and might not need one? some can still find proper use of sectioning elements useful. I.e. Search engines, and assistive devices. Jacob Kristensen http://blueboden.com/ I can think of a couple of reasons, namely that a) a paragraph shouldn't break mid-sentence and a sentence may surround a list, and b) people might want to use inline lists like this -- Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] Embedding custom hierarchical data
Hi everyone, what would be the 'preferred' way to embed custom hierarchical data in a HTML document? Consider, for example, a list that contains custom data that needs to be displayed using Javascript. In most cases, the data-* attributes are a nice way to embed non-visual data to be read out later, but that doesn't work for hierarchical structures. There are a few possible solutions: 1) Microdata. This could work, but only if the data should be displayed as well. If the data should be processed (and for example, be shown in another part of the page) this doesn't work really well. You could the hide the parent element with CSS, but that's pretty clunky. 2) data-* attributes with JSON data. Would work, but pretty ugly and not very expressive and readable. 3) 'Data blocks' in a script element, as described in the spec. You can, for example, use a script element with an 'application/xml' or 'application/json' type, which will not be processed by a browser, and use Javascript to do the parsing. Data blocks seem to be the current most usable solution, but i get the feeling that it's not quite expressive enough. script tags should contain scripts, and XML and JSON are not scripting languages. Semantically, 'xml islands' as used in older versions of IE seem like an elegant solution but are not supported in other browsers. Something like a data tag, with a required 'type' attribute that can contain a mime type that could indicate to browsers what type of content follows might be an interesting solution, but i'm not sure what the implications might be.It would be cool if you do a data type=application/json and get an automatic Javascript object when getting the element with document.getElementById. -- Hay Kranen
Re: [whatwg] Stream API Feedback
Instead of creating new state signalling and control API for streams, what about the alternative approach of letting video and audio use sensors as sources, and a way to connect the output of video and audio to encoders? Then we'd get all the existing state machinery for free. We'd also get sensor input for audio processing (e.g. Mozilla or Chrome's audio APIs), and in-page video preview, and using canvas to take snapshots, and more... Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Embedding custom hierarchical data
On 3/15/11, Hay (Husky) hus...@gmail.com wrote: Hi everyone, what would be the 'preferred' way to embed custom hierarchical data in a HTML document? You should also consider passing the data along with the script and HTML, rather than embedding it in the markup. This may save you from headaches stemming from the data being parsed as HTML.
Re: [whatwg] Embedding custom hierarchical data
Thanks for the suggestion Bjartur, but unfortunately that's not an option in the usecase. Data is parsed using Freemarker (a template language) and can't be included using a script src= tag. -- Hay On Tue, Mar 15, 2011 at 10:15 PM, Bjartur Thorlacius svartma...@gmail.com wrote: On 3/15/11, Hay (Husky) hus...@gmail.com wrote: Hi everyone, what would be the 'preferred' way to embed custom hierarchical data in a HTML document? You should also consider passing the data along with the script and HTML, rather than embedding it in the markup. This may save you from headaches stemming from the data being parsed as HTML.
Re: [whatwg] Stream API Feedback
On 3/15/11, Robert O'Callahan rob...@ocallahan.org wrote: Instead of creating new state signalling and control API for streams, what about the alternative approach of letting video and audio use sensors as sources, and a way to connect the output of video and audio to encoders? Then we'd get all the existing state machinery for free. We'd also get sensor input for audio processing (e.g. Mozilla or Chrome's audio APIs), and in-page video preview, and using canvas to take snapshots, and more... That would make sense, assuming you are suggesting reusing objects representing media elements, rather than using HTML elements.
Re: [whatwg] Stream API Feedback
On Wed, Mar 16, 2011 at 11:11 AM, Bjartur Thorlacius svartma...@gmail.comwrote: On 3/15/11, Robert O'Callahan rob...@ocallahan.org wrote: Instead of creating new state signalling and control API for streams, what about the alternative approach of letting video and audio use sensors as sources, and a way to connect the output of video and audio to encoders? Then we'd get all the existing state machinery for free. We'd also get sensor input for audio processing (e.g. Mozilla or Chrome's audio APIs), and in-page video preview, and using canvas to take snapshots, and more... That would make sense, assuming you are suggesting reusing objects representing media elements, rather than using HTML elements. HTML elements can be used as objects just fine. See new Audio() etc. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Embedding custom hierarchical data
On Tue, Mar 15, 2011 at 4:06 PM, Hay (Husky) hus...@gmail.com wrote: 1) Microdata. This could work, but only if the data should be displayed as well. If the data should be processed (and for example, be shown in another part of the page) this doesn't work really well. You could the hide the parent element with CSS, but that's pretty clunky. Microdata is allowed on meta for this reason, last I checked.
