Re: [whatwg] Installable web apps
On Tue, 08 Jun 2010 21:26:12 +0200, Atul Varma ava...@mozilla.com wrote: For what it's worth, I think that giving developers tools to easily define more granular security mechanisms without resorting to subdomains is a win in terms of usability, as it's quite difficult to figure out how to create subdomains and do virtual hosting--to say nothing of doing it over SSL. On DreamHost creating a new subdomain is a couple of clicks... That said, introducing a brand new mechanism for security on top of SOP does seem like it might make the security landscape more complex as a whole, and thereby potentially more vulnerable. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] input type=upload (not just files) proposal
Forgive me if this has already been discussed... I cannot find it on the current working draft spec... I think an interesting addition to the input type=upload would be a script-accessible progress value. Either as a percentage, or probably more useful two values, one being the size of the upload and the other being current bytes sent. Is this already in the spec somewhere? I can't find anything... Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element? -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Eitan Adler Sent: 08 June 2010 17:10 To: Lachlan Hunt Cc: wha...@whatwg.org; Simpson, Grant Leyton Subject: Re: [whatwg] input type=upload (not just files) proposal My understanding of the proposal is that given this particular control, the browser would provide an interface for either selecting a local file or entering a URL. If a file is selected, the file is uploaded as normal, equivalent to input type=file name=foo. Otherwise, if a URL is entered, the field is instead submitted as text, equivalent to input type=url name=foo. The server would then determine whether the foo field that was submitted was a file upload or a text field value, and if it were a text field, then it would supposedly be treated as a URL that should then be fetched. Eitan, have I understood your proposal correctly? Yes - exactly. -- Eitan Adler
[whatwg] Device Element
Having a look over the draft, I notice a comment about the device element, RS232 is only included below to give an idea of where we could go with this. Should we instead just make this only useful for audiovisual streams? Unless there are compelling reasons, we probably should not be this generic. So far, the reasons aren't that compelling. I have a usage case that would benefit from other types of device access other than audiovisual: We currently run a news service that requires users log on to access our data and market reports (practically all major banking institutions in the world use us). I could envisage either a thumb-print reader allowing us to authenticate the user biometrically, or providing each user with a USB thumb stick that contains a unique identifier of some sort that when read using the device element could be used to authenticate them like a sort-of web-dongle. One of our big issues is plagiarism and password sharing amongst our clients. This type of access would allow us to lock down secure content without having to install applications on the client computers which as you can imagine, is a no-no when dealing with banks! Comments anyone?
Re: [whatwg] input type=upload (not just files) proposal
On Wed, Jun 9, 2010 at 5:22 AM, Rob Evans r...@mtn-i.com wrote: I think an interesting addition to the input type=upload would be a script-accessible progress value. Either as a percentage, or probably more useful two values, one being the size of the upload and the other being current bytes sent. If you are uploading by reference to URL (which presumably the server would fetch to save bandwidth) then progress information is probably not something that can easily be exposed by the HTML interface. You might want to use an out-of-band ajax-style channel with javascript to show progress instead. Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element? That's been in there since HTML 3.2, I believe, and was implemented by some browsers (IE 5-8?). User interface concerns almost always end up preferring dynamic form behaviors, with variable numbers of input type=file elements added and removed on an as-needed basis before the form is submitted.
[whatwg] A 'muted' event for the video element
Hi everyone, i'm currently building a Javascript based interface for the video element. One of the things that really seem to be lacking from the specification (and hence, browsers too) is a distinct 'muted' event that occurs whenever you set the muted property to 'true' or 'false'. Of course, the 'volumechange' event occurs, but that also happens whenever you set the volume so you have to check every time the event occurs if it originated from a change on the volume or muted property. Because these two capabilities of the video element have different properties, it seems to make sense to let them trigger different events too (or have the muted property trigger 'volumechange' as well). Regards, -- Hay Kranen
Re: [whatwg] input type=upload (not just files) proposal
If you are uploading by reference to URL (which presumably the server would fetch to save bandwidth) then progress information is probably not something that can easily be exposed by the HTML interface. You might want to use an out-of-band ajax-style channel with javascript to show progress instead. Indeed, when referencing a URL I don't think progress bars are much of an issue, but when dealing with a local file upload it would be great to have those values exposed to scripts! I hate having to poll the server for a progress update... it's so 1990. Or has this already been exposed to scripts... am I behind the times? So much to keep up with! That's been in there since HTML 3.2, I believe, and was implemented by some browsers (IE 5-8?). User interface concerns almost always end up preferring dynamic form behaviors, with variable numbers of input type=file elements added and removed on an as-needed basis before the form is submitted. I guess it's a matter of preference, but if you're uploading a load of images for instance, it gets tiresome having to keep clicking select file on every new input element. I wasn't aware that IE had implemented multiple file selection inside a single element however I would never have noticed anyway as I shun IE and avoid it like the plague. -Original Message- From: James Salsman [mailto:jsals...@gmail.com] Sent: 09 June 2010 13:47 To: Rob Evans; whatwg@lists.whatwg.org Subject: Re: [whatwg] input type=upload (not just files) proposal On Wed, Jun 9, 2010 at 5:22 AM, Rob Evans r...@mtn-i.com wrote: I think an interesting addition to the input type=upload would be a script-accessible progress value. Either as a percentage, or probably more useful two values, one being the size of the upload and the other being current bytes sent. If you are uploading by reference to URL (which presumably the server would fetch to save bandwidth) then progress information is probably not something that can easily be exposed by the HTML interface. You might want to use an out-of-band ajax-style channel with javascript to show progress instead. Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element? That's been in there since HTML 3.2, I believe, and was implemented by some browsers (IE 5-8?). User interface concerns almost always end up preferring dynamic form behaviors, with variable numbers of input type=file elements added and removed on an as-needed basis before the form is submitted.
[whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com But we have potential danger to misuse it also for the sake of non-standards. prediction *Case 1 *- Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a *Server Side HTML5 toolkit* which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API. A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5. So, This I do not like,,,-- ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5 We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools. /prediction I *guess*, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence. . -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘ Yet another HTML5 Developer.
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 20:29, narendra sisodiya naren...@narendrasisodiya.com wrote: Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com But we have potential danger to misuse it also for the sake of non-standards. prediction Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API. A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5. So, This I do not like,,,-- ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5 We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools. /prediction I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence. . -- ┌─┐ │ Narendra Sisodiya │ http://narendrasisodiya.com └─┘ Yet another HTML5 Developer. Hello Narandra, Do you have any links or sources backing up that Adobe is working on the server-side? While your scenario certainly is possible, even with today's possibilities, I see a number of problems with it: 1) The number of simultaneous users in any web application will be severely limited by the available processing power of the server. Thinking of the current uses of Flash, a really large part of which are video players and games, it does not seem realistic. Extend this to Flash applications such as FarmVille on Facebook and server-side processing and rendering will be pretty close to impossible. 2) How exactly is this different from normal webpages? A lot of websites use scripting languages as their back end, such as PHP, delivering a certain flexibility which is not directly visible to the user. The same thing can be applied to achieve creating personalized Application Cache Manifests. On top of that, there are various Javascript obfuscators around which convert code to nearly unreadable pieces of text. While code formatting can be normalized using a range of tools, variables like _ and ___ will be continue to be confusing nonetheless. Such obfuscation is enough to stop 99% of the people from getting/copying the code, going through the trouble of continuous connections and server-side processing for that last percent seems unlikely. If any application is that critical, the author should consider limiting access to the application altogether. Regards, Peter
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 2:29 PM, narendra sisodiya naren...@narendrasisodiya.com wrote: Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API. A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5. So, This I do not like,,,-- ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5 The goal of HTML5 is that all browsers and platforms should be able to display all web pages, without dependence on any particular software vendor. If a company like Adobe writes a framework using cross-browser, cross-platform, openly specified APIs, we're in a far better situation than now. It would really be no different from jQuery. Furthermore, it's not *possible* to prevent anyone from writing toolkits that use HTML5 features. Or do you have any suggestions to stop it?
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Thu, Jun 10, 2010 at 12:24 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Wed, Jun 9, 2010 at 2:29 PM, narendra sisodiya naren...@narendrasisodiya.com wrote: Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API. A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5. So, This I do not like,,,-- ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5 The goal of HTML5 is that all browsers and platforms should be able to display all web pages, without dependence on any particular software vendor. If a company like Adobe writes a framework using cross-browser, cross-platform, openly specified APIs, we're in a far better situation than now. It would really be no different from jQuery. Yes, sure, I love to advocate adobe/similarcompany and modify my video - http://tinyvid.tv/show/2dz18ka146nfz , Provided they should do it in Client side so source can be seen.* Providing a server side or similar rendering system which use 'Canvas' for displaying everything inside canvas from server side is as bad as flash player/plugin.Web may be hidden again under pixels.* Furthermore, it's not *possible* to prevent anyone from writing toolkits that use HTML5 features. Or do you have any suggestions to stop it? We can't stop anyone. Advocate SVG and making SVG-animation support with SVG animation authoring tools is a good way to reduce 'server side canvas rendering'. -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 3:26 PM, narendra sisodiya naren...@narendrasisodiya.com wrote: Yes, sure, I love to advocate adobe/similarcompany and modify my video - http://tinyvid.tv/show/2dz18ka146nfz , Provided they should do it in Client side so source can be seen. Providing a server side or similar rendering system which use 'Canvas' for displaying everything inside canvas from server side is as bad as flash player/plugin.Web may be hidden again under pixels. It's not as bad. It will work equally on all browsers and all platforms, and several parties will get to compete on some key aspects of the implementation (such as the speed and stability of the underlying JavaScript). It's not much different from any website using closed-source server-side code. We can't stop anyone. Advocate SVG and making SVG-animation support with SVG animation authoring tools is a good way to reduce 'server side canvas rendering'. If you don't have spec changes to propose, this is probably the wrong list.
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo pe...@lvp-media.comwrote: On Wed, Jun 9, 2010 at 20:29, narendra sisodiya naren...@narendrasisodiya.com wrote: Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com But we have potential danger to misuse it also for the sake of non-standards. prediction Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API. A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5. So, This I do not like,,,-- ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5 We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools. /prediction I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence. . -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘ Yet another HTML5 Developer. Hello Narandra, Do you have any links or sources backing up that Adobe is working on the server-side? While your scenario certainly is possible, even with today's possibilities, I see a number of problems with it: No, i do not have any info. I am independent developer who enjoy making predictions - http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html 1) The number of simultaneous users in any web application will be severely limited by the available processing power of the server. Thinking of the current uses of Flash, a really large part of which are video players and games, it does not seem realistic. Extend this to Flash applications such as FarmVille on Facebook and server-side processing and rendering will be pretty close to impossible. Yes, you are correct at this points, 2) How exactly is this different from normal webpages? A lot of websites use scripting languages as their back end, such as PHP, delivering a certain flexibility which is not directly visible to the user. The same thing can be applied to achieve creating personalized Application Cache Manifests. PHP script generate HTML code along with JavaScript. It make our task easy. But, Lets imagine if we have a very good Tookkit which have everything for webdesign like buttions, menus, dropdown and final code renders everything in CANVAS. ToolKits may use altogether different higher level sytax to generate canvas based applications. further this toolkit has JavaScript unzip library. then you will be able to create a application in zipped format. Let me explain this more - Designer/Developer will use drag and drop based Toolkit which has altogether different higher level sytax which generate CANVAS based application. - Toolkit Or some JavaScript code will generate JavaScript code with all resource like image, htmlcode, source code and everything in application directory. - Toolkit will zip the whole application and finally designer/developer will get a *myfirstgame.wapp * Now developer/designer need to write this much code script src=./js/wapp-engine.js/script div class='wapp-application' data-src='./myfirstgame.wapp' width='600' height='800' / This wapp-engine.js will be a wapp player which load *myfirstgame.wapp*using Ajax and unzip files. Create a dynamic canvas, and render the game in canvas area. So we are using HTML5 canvas but what are we doing - Fast and GUI based development tools with a non-standards/proprietary ToolKit for generating a .wapp files which can be distributed and developed easily - .wapp will be played in browser will be JS wapp player which render it inside CANVAS API with hiding images, text and everything under pixels which is the prime requirement of many website - Desktop based wapp player inorder to play downloded .wapp files. - Web will become a binary world. So, it is
[whatwg] IETF BoF @IETF-78 Maastricht: HASMAT - HTTP Application Security Minus Authentication and Transport
[apologies for cross-post] Hi, We will be hosting the HTTP Application Security Minus Authentication and Transport (HASMAT) Birds-of-a-Feather (BoF) session at IETF-78 in Maastricht NL during the week of July 25-30, 2010 (see [0] for mailing list). The purpose of IETF BoFs is to determine whether there is a problem worth solving, and whether the IETF is the right group to solve it. To that end, the problem statement is summarized below in the Draft HASMAT Working Group Charter, and is drawn from this paper [1]. Various facets of this work are already underway, as outlined below in the draft WG charter, e.g. Strict Transport Security (STS) [2]. Of course the scope of HTTP application security is quite broad (as outlined in [1]), thus the intent is to coordinate this work closely with related work likely to land in the W3C (and possibly other orgs), e.g. Content Security Policy (CSP) [3]. We have created a public mailing list [0] for pre-BoF discussion -- has...@ietf.org -- to which you can freely subscribe here: https://www.ietf.org/mailman/listinfo/hasmat We encourage all interested parties to join the hasmat@ mailing list and engage in the on-going discussion there. thanks, =JeffH (current IETF HTTPstate WG chair) Peter Saint-Andre (IETF Applications Area Director) Hannes Tschofenig (IAB, IETF WG chair) [0] HASMAT mailing list. https://www.ietf.org/mailman/listinfo/hasmat [1] Hodges and Steingruebl, The Need for a Coherent Web Security Policy Framework, W2SP position paper, 2010. http://w2spconf.com/2010/papers/p11.pdf [2] Hodges, Jackson, and Barth, Strict Transport Security (STS), revision -06. http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html see also: http://en.wikipedia.org/wiki/Strict_Transport_Security [3] Sterne and Stamm, Content Security Policy (CSP). https://wiki.mozilla.org/Security/CSP/Specification see also: http://people.mozilla.org/~bsterne/content-security-policy/ https://wiki.mozilla.org/Security/CSP/Design_Considerations ### Proposed HASMAT BoF agenda -- Chairs: Hannes Tschofenig and Jeff Hodges 5 min Agenda bashing (Chairs) 10 min Description of the problem space (TBD) 20 min Motivation for standardizing (TBD) draft-abarth-mime-sniff draft-abarth-origin draft-hodges-stricttransportsec (to-be-submitted) 15 min Presentation of charter text (TBD) 60 min Discussion of charter text and choice of the initial specifications (All) 10 min Conclusion (Chairs/ADs) ### Draft Charter for HASMAT: HTTP Application Security Minus Authentication and Transport WG Problem Statement Although modern Web applications are built on top of HTTP, they provide rich functionality and have requirements beyond the original vision of static web pages. HTTP, and the applications built on it, have evolved organically. Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so-called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality, e.g. social networking, to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies. The list of attacks is long and includes Cross-Site-Request Forgery (CSRF)-based attacks, content-sniffing cross-site-scripting (XSS) attacks, attacks against browsers supporting anti-XSS policies, clickjacking attacks, malvertising attacks, as well as man-in-the-middle (MITM) attacks against secure (e.g. Transport Layer Security (TLS/SSL)-based) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip). Objectives and Scope With the arrival of new attacks the introduction of new web security indicators, security techniques, and policy communication mechanisms have sprinkled throughout the various layers of the Web and HTTP. The goal of this working group is to standardize a small number of selected specifications that have proven to improve security of Internet Web applications. The requirements guiding the work will be taken from the Web application and Web security communities. Initial work will be limited to the following topics: - Same origin policy, as discussed in draft-abarth-origin - Strict transport security, as discussed in draft-hodges-stricttransportsec (to be submitted shortly) - Media type sniffing, as discussed in draft-abarth-mime-sniff In addition, this working group will consider the overall topic of HTTP application security and compose a problem statement and requirements document that can be used to guide further work. This working group will work closely with IETF Apps Area WGs (such as HYBI,
Re: [whatwg] audio and video: volume and muted as content attributes?
Setting volume above 1.0 can be very useful if the original is too quiet. For example, Quicktime allows a volume of 300% to amplify quiet tracks On May 31, 2010 11:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Ju... This would make volume even more special, as a float that reflects as an integer percentage. Just using the existing definition for reflecting a float would be simpler. So, I am neither in favor or against of reflecting volume and mute as content attributes. Im... I'd be fine with reflecting muted if many people think it would be useful. I'm not the one to make that judgment though. Volume isn't a huge problem, just not as trivial as one might suspect. Another thing to consider is that it is currently impossible to set volume to a value outside the range [0,1] via the DOM API. With a content attribute, volume=-1 and volume=1.1 would need to be handled too. I'd prefer it being ignored rather than being clamped. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect Ch... -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] audio and video: volume and muted as content attributes?
I don't think that is possible in the way that the volume attribute is currently defined as a value between [0;1]. That is an orthogonal, but still important question about the volume attribute then. So, if you say 300%, I assume you mean 3 times louder than what the track is given as? I do wonder how to do that with the current volume attribute - right now the spec says that the default value set is 1.0 [1]. It seems that means we cannot amplify a quiet audio track but have to rely on the user to turn up the volume on their computer? I would actually prefer if the default setting was something like 0.5 and we could then turn the volume up or down in javascript or preferably event through a content attribute as mentioned. Cheers, Silvia. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks kevinma...@gmail.com wrote: Setting volume above 1.0 can be very useful if the original is too quiet. For example, Quicktime allows a volume of 300% to amplify quiet tracks On May 31, 2010 11:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Ju... This would make volume even more special, as a float that reflects as an integer percentage. Just using the existing definition for reflecting a float would be simpler. So, I am neither in favor or against of reflecting volume and mute as content attributes. Im... I'd be fine with reflecting muted if many people think it would be useful. I'm not the one to make that judgment though. Volume isn't a huge problem, just not as trivial as one might suspect. Another thing to consider is that it is currently impossible to set volume to a value outside the range [0,1] via the DOM API. With a content attribute, volume=-1 and volume=1.1 would need to be handled too. I'd prefer it being ignored rather than being clamped. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect Ch... -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] audio and video: volume and muted as content attributes?
On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote: I don't think that is possible in the way that the volume attribute is currently defined as a value between [0;1]. That is an orthogonal, but still important question about the volume attribute then. So, if you say 300%, I assume you mean 3 times louder than what the track is given as? I do wonder how to do that with the current volume attribute - right now the spec says that the default value set is 1.0 [1]. It seems that means we cannot amplify a quiet audio track but have to rely on the user to turn up the volume on their computer? I would actually prefer if the default setting was something like 0.5 and we could then turn the volume up or down in javascript or preferably event through a content attribute as mentioned. Cheers, Silvia. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks kevinma...@gmail.com wrote: Setting volume above 1.0 can be very useful if the original is too quiet. For example, Quicktime allows a volume of 300% to amplify quiet tracks On May 31, 2010 11:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Ju... This would make volume even more special, as a float that reflects as an integer percentage. Just using the existing definition for reflecting a float would be simpler. So, I am neither in favor or against of reflecting volume and mute as content attributes. Im... I'd be fine with reflecting muted if many people think it would be useful. I'm not the one to make that judgment though. Volume isn't a huge problem, just not as trivial as one might suspect. Another thing to consider is that it is currently impossible to set volume to a value outside the range [0,1] via the DOM API. With a content attribute, volume=-1 and volume=1.1 would need to be handled too. I'd prefer it being ignored rather than being clamped. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect Ch... -- Philip Jägenstedt Core Developer Opera Software Or you could just raise the volume of the audio track itself. I think being able to raise the volume like this (beyond 100% of what it is) with script just makes it something more likely to be abused (think how the TV adverts always seem twice as loud as the programs they surround) and so will end up getting blocked more often. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] audio and video: volume and muted as content attributes?
On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote: I don't think that is possible in the way that the volume attribute is currently defined as a value between [0;1]. That is an orthogonal, but still important question about the volume attribute then. So, if you say 300%, I assume you mean 3 times louder than what the track is given as? I do wonder how to do that with the current volume attribute - right now the spec says that the default value set is 1.0 [1]. It seems that means we cannot amplify a quiet audio track but have to rely on the user to turn up the volume on their computer? I would actually prefer if the default setting was something like 0.5 and we could then turn the volume up or down in javascript or preferably event through a content attribute as mentioned. Cheers, Silvia. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks kevinma...@gmail.com wrote: Setting volume above 1.0 can be very useful if the original is too quiet. For example, Quicktime allows a volume of 300% to amplify quiet tracks On May 31, 2010 11:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Ju... This would make volume even more special, as a float that reflects as an integer percentage. Just using the existing definition for reflecting a float would be simpler. So, I am neither in favor or against of reflecting volume and mute as content attributes. Im... I'd be fine with reflecting muted if many people think it would be useful. I'm not the one to make that judgment though. Volume isn't a huge problem, just not as trivial as one might suspect. Another thing to consider is that it is currently impossible to set volume to a value outside the range [0,1] via the DOM API. With a content attribute, volume=-1 and volume=1.1 would need to be handled too. I'd prefer it being ignored rather than being clamped. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect Ch... -- Philip Jägenstedt Core Developer Opera Software Or you could just raise the volume of the audio track itself. I think being able to raise the volume like this (beyond 100% of what it is) with script just makes it something more likely to be abused (think how the TV adverts always seem twice as loud as the programs they surround) and so will end up getting blocked more often. That requires editing the resource. Think about it from a process point-of-view: you're a Web developer and have been given a set of media resources to put on a Website. As you put it all together, you notice that the volume of the different files is different and thus playing them back next to each other will create a very confusing user experience. Do you really want to shoot the files back to the production to adjust the volume settings so they are all similar? If you're under time pressure, you'd probably much prefer just setting a volume attribute on each so they all play back with the same level. Your example of TV ads being louder than the rest of the program is indeed a production issue but would not replicable through a volume setting for the resource, since that volume applies to the whole resource and not just to the ad clip inside it. I don't think that kind of abuse would originate from JavaScript - it already originates from production and doesn't really apply to this issue. Cheers, Silvia.
Re: [whatwg] audio and video: volume and muted as content attributes?
On Thu, 2010-06-10 at 12:03 +1000, Silvia Pfeiffer wrote: On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote: I don't think that is possible in the way that the volume attribute is currently defined as a value between [0;1]. That is an orthogonal, but still important question about the volume attribute then. So, if you say 300%, I assume you mean 3 times louder than what the track is given as? I do wonder how to do that with the current volume attribute - right now the spec says that the default value set is 1.0 [1]. It seems that means we cannot amplify a quiet audio track but have to rely on the user to turn up the volume on their computer? I would actually prefer if the default setting was something like 0.5 and we could then turn the volume up or down in javascript or preferably event through a content attribute as mentioned. Cheers, Silvia. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks kevinma...@gmail.com wrote: Setting volume above 1.0 can be very useful if the original is too quiet. For example, Quicktime allows a volume of 300% to amplify quiet tracks On May 31, 2010 11:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Ju... This would make volume even more special, as a float that reflects as an integer percentage. Just using the existing definition for reflecting a float would be simpler. So, I am neither in favor or against of reflecting volume and mute as content attributes. Im... I'd be fine with reflecting muted if many people think it would be useful. I'm not the one to make that judgment though. Volume isn't a huge problem, just not as trivial as one might suspect. Another thing to consider is that it is currently impossible to set volume to a value outside the range [0,1] via the DOM API. With a content attribute, volume=-1 and volume=1.1 would need to be handled too. I'd prefer it being ignored rather than being clamped. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect Ch... -- Philip Jägenstedt Core Developer Opera Software Or you could just raise the volume of the audio track itself. I think being able to raise the volume like this (beyond 100% of what it is) with script just makes it something more likely to be abused (think how the TV adverts always seem twice as loud as the programs they surround) and so will end up getting blocked more often. That requires editing the resource. Think about it from a process point-of-view: you're a Web developer and have been given a set of media resources to put on a Website. As you put it all together, you notice that the volume of the different files is different and thus playing them back next to each other will create a very confusing user experience. Do you really want to shoot the files back to the production to adjust the volume settings so they are all similar? If you're under time pressure, you'd probably much prefer just setting a volume attribute on each so they all play back with the same level. Your example of TV ads being louder than the rest of the program is indeed a production issue but would not replicable through a volume setting for the resource, since that volume applies to the whole resource and not just to the ad clip inside it. I don't think that kind of abuse would originate from JavaScript - it already originates from production and doesn't really apply to this issue. Cheers, Silvia. If, like you mentioned in your example, all the media files are of different volumes, then your script would have to somehow detect the actual real volume of them in order to give the right level of adjustment for normalisation, something which I don't believe is possible just at the moment. If I was in such a situation, yes I would most likely send them back to the post production team, or at the very least normalise them myself with ffmpeg or some similar tool. It would be like sourcing a bunch of
Re: [whatwg] audio and video: volume and muted as content attributes?
On Thu, Jun 10, 2010 at 12:13 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: On Thu, 2010-06-10 at 12:03 +1000, Silvia Pfeiffer wrote: On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote: I don't think that is possible in the way that the volume attribute is currently defined as a value between [0;1]. That is an orthogonal, but still important question about the volume attribute then. So, if you say 300%, I assume you mean 3 times louder than what the track is given as? I do wonder how to do that with the current volume attribute - right now the spec says that the default value set is 1.0 [1]. It seems that means we cannot amplify a quiet audio track but have to rely on the user to turn up the volume on their computer? I would actually prefer if the default setting was something like 0.5 and we could then turn the volume up or down in javascript or preferably event through a content attribute as mentioned. Cheers, Silvia. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks kevinma...@gmail.com wrote: Setting volume above 1.0 can be very useful if the original is too quiet. For example, Quicktime allows a volume of 300% to amplify quiet tracks On May 31, 2010 11:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Ju... This would make volume even more special, as a float that reflects as an integer percentage. Just using the existing definition for reflecting a float would be simpler. So, I am neither in favor or against of reflecting volume and mute as content attributes. Im... I'd be fine with reflecting muted if many people think it would be useful. I'm not the one to make that judgment though. Volume isn't a huge problem, just not as trivial as one might suspect. Another thing to consider is that it is currently impossible to set volume to a value outside the range [0,1] via the DOM API. With a content attribute, volume=-1 and volume=1.1 would need to be handled too. I'd prefer it being ignored rather than being clamped. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect Ch... -- Philip Jägenstedt Core Developer Opera Software Or you could just raise the volume of the audio track itself. I think being able to raise the volume like this (beyond 100% of what it is) with script just makes it something more likely to be abused (think how the TV adverts always seem twice as loud as the programs they surround) and so will end up getting blocked more often. That requires editing the resource. Think about it from a process point-of-view: you're a Web developer and have been given a set of media resources to put on a Website. As you put it all together, you notice that the volume of the different files is different and thus playing them back next to each other will create a very confusing user experience. Do you really want to shoot the files back to the production to adjust the volume settings so they are all similar? If you're under time pressure, you'd probably much prefer just setting a volume attribute on each so they all play back with the same level. Your example of TV ads being louder than the rest of the program is indeed a production issue but would not replicable through a volume setting for the resource, since that volume applies to the whole resource and not just to the ad clip inside it. I don't think that kind of abuse would originate from JavaScript - it already originates from production and doesn't really apply to this issue. Cheers, Silvia. If, like you mentioned in your example, all the media files are of different volumes, then your script would have to somehow detect the actual real volume of them in order to give the right level of adjustment for normalisation, something which I don't believe is possible just at the moment. It is possible, but not necessary. You can just make some changes yourself - after all, it's only done once, since the resources won't change. If I was in such a situation, yes I would most likely send them back to the post production team, or at the very least normalise them myself with ffmpeg or some similar tool. Yes, sure you can. But should it be the only possibility? It would be like sourcing a bunch of images for a website and using canvas to applying a filter to adjust the light volumes of them all. Sure, it might be possible, but the images really should have been adjusted before they were used on the site. Why should we encourage sloppy content producers? If you get the videos from different producers, how should they be able to normalise the volume? Silvia.
