Re: [whatwg] Web Workers API
All meesaging through postMessage uses the internal structured cloning
algorithm detailed at
http://www.w3.org/TR/2010/WD-html5-20100304/Overview.html#internal-structured-cloning-algorithm
It's basically a deep copy, but has a few restrictions on the types cloned, and
doesn't copy functions or the prototype property, etc.
--Oliver
On Jul 1, 2010, at 9:06 PM, Evan Ireland wrote:
Hi,
The IDL for Worker in the Web Workers API specification shows:
void postMessage(in any message, in optional MessagePortArray ports);
I have a question regarding the 'any' type for message.
If a caller of postMessage passes an object to a worker that is not a
string, is it converted to a string or can non-string objects be propagated
through to the onmessage(event) in the worker.
So if I write:
var w = new MyWorker('MyWorker.js');
w.postMessage(new MyObject());
--
// MyWorker.js
onmessage = function(event)
{
var d = event.data;
// what type is 'd'?
}
If 'd' is not a string, then is it a MyObject, and if so, how is it supposed
to be marshalled by the inter-worker(thread) communication?
I suggest that whatever the answer, that this be covered when the spec
document is next updated.
Thanks.
Re: [whatwg] HTML 5 : The Youtube response
Hello, The Flash player exposes a string of metrics: http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/net/NetStreamInfo.html The most useful ones are: *) droppedFrames: it can be used to determine whether the client can play the video without stuttering. *) maxBytesPerSecond: it can be used to determine the bandwidth of the connection. In addition to this, the metadata embedded in the video is interesting. For example: *) width height: already available *) duration: already avaliable *) bitrates: for comparison against maxBytesPerSecond. *) seekpoints: for anticipating seek results in the UI *) content metadata (e.g. ID3 or MP4 Images) Here's an example with the exposed metadata printed on top of the player: http://developer.longtailvideo.com/trac/testing/?plugins=metaviewerfile=%2Fplayer%2Ftesting%2Ffiles%2Fbunny.mp4height=260width=500autostart=truemute=true Kind regards, Jeroen One part of (2) [well, debatably part, but related to video streaming] is the lack of visibility into stream behavior. I can't ask the video element questions about dropped frames, bitrate, etc. This is incredibly useful in Flash for getting streaming feedback, and means I really don't know how well the HTML5 player is working for users. The best I can do is waiting/stalled events which is nowhere near as granular. I agree that exposing info like that would be useful. What does the Flash API for this look like? What parts of the available data do you find most useful? Regards, Maciej -Kevin On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote: I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient: A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened. B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor. C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5. D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms. E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W). F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode. I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate. Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen — text and UI elements displayed by attacker will look noticeably different. That would probably make the controls look ugly for video with custom controls, and I suspect neither users nor content authors would appreciate that. Interesting idea, though. - Maciej
Re: [whatwg] media resources: addressing media fragments through URIs spec
Actually, a point in time is nothing - it's an empty set. You never want to actually point to a point in time, but rather to either the point in time and an interval after that point in time, or everything from that point onwards. That's what these URIs represent. Cheers, Silvia. On Fri, Jul 2, 2010 at 7:56 AM, Jonas Sicking jo...@sicking.cc wrote: That would be great. I guess it's unclear to me how the UIs would differ for video.ogv#t=40,50 and video.ogv#t=40 In particular it seems strange to me that video.ogv#t=40 represents the whole range from the selected point to the end of the video, given that most commonly when wanting to point out a particular point in a video you actually just want to represent a point. / Jonas On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: BTW: I will try and make a screencast of that firefox plugin, which should clarify things further. Stay tuned... Cheers, Silvia. On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi Jonas, On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking jo...@sicking.cc wrote: Hi Silvia, Back in may last year I brought [1] up the fact that there are two use cases for temporal media fragments: 1. Skipping to a particular point in a longer resource, such as wanting to start a video at a particular point while still allowing seeking in the entire resource. This is currently supported by for example YouTube [2]. It is also the model used for web pages where including a fragment identifier only scrolls to a particular point, while allowing the user to scroll to any point both before and after the identified fragment. 2. Only displaying part of a video. For example out of a longer video from a discussion panel, only displaying the part where a specific topic is discussed. While there seemed to be agreement [3][4] that these are in fact two separate use cases, it seems like the media fragments draft is only attempting to address one. Additionally, it only addresses the one that has the least precedence as far as current technologies on the web goes. Was this an intentional omission? Is it planned to solve use case 1 above in a future revision? [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201 [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html I think you may have misunderstood the specification. Use case 1 is indeed the main use case being addressed in the specification. There is a Firefox plugin implementation[1] of the specification that shows exactly use case 1 in a video element - a URI with a fragment such as video.ogv#t=40,50 is being included in a video element and the effect is that the video is displayed from 40s to 50s, but the transport bar (or controls) are still those of the complete resource, so you can still seek to any position. To be sure, this is just a recommendation of how it is supposed to be implemented (see http://www.w3.org/TR/media-frags/#media-fragment-display). The group only defined what URIs look like that point to such a segment - it cannot prescribe what an application (such as a HTML document) does with the URI. I would propose that this discussion should be had about HTML5 and a sentence be added to the HTML5 spec on how UAs are expected to deal with such segments. Further, if you are indeed only interested in a subpart of the original media resource and want to completely blend out all context (i.e. all other bits of the media resource), you should be using the URI query addressing method instead of the URI fragment, e.g. video.ogv?t=40,50. This URI is supposed to create a new resource that consist only of the segment - it will only do so, of course, if your server supports this functionality. All of this is described in more detail in the spec [2]. If that is unclear or anything is confusing, please do point it out so it can be fixed. Best Regards, Silvia. [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs) [2] http://www.w3.org/TR/media-frags/
Re: [whatwg] media resources: addressing media fragments through URIs spec
On Fri, Jul 2, 2010 at 1:55 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Actually, a point in time is nothing - it's an empty set. You never want to actually point to a point in time, but rather to either the point in time and an interval after that point in time, or everything from that point onwards. That's what these URIs represent. I'm not sure I agree, but to avoid meta-discussions I'll just wait to see the suggested UI. / Jonas
Re: [whatwg] More YouTube response
John Harding jhard...@google.com wrote: Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. I think this would defeat a huge chunk of the value of video. A big part of the value of video is that competition and innovation on the computing platform space will be fostered when the vendor of a computing platform can port (or have ported) one of the Open Source browsers to the platform, pay Opera to port Presto or write their own (like Microsoft) without having to persuade a plug-in proprietor that it's worth the plug-in proprietor's effort to port a certain plug-in to the platform. Pluggable DRM or codec modules would regress back to the situation where the proprietors of those plug-ins act as gatekeepers for the success of computing platforms. I observe that Hollywood movies (the most premium of content, supposedly) are routinely licensed for DVB broadcast without DRM, and on the Internet every other form of content is distributed without DRM. It may well be that when the potential audience grows enough, at some point the ability to reach that audience weighs more than protection and the problem gets solved without DRM (and without the ill effects of DRM to computing platform freedom, competition and innovation). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] More YouTube response
On Thu, Jul 1, 2010 at 6:59 PM, John Harding jhard...@google.com wrote: 2. Robust Video Streaming Andy Berkheimer on our team has been putting some thought into this, so I'll defer to him for more specific proposals. For an app like YouTube, it is extremely useful to have fine-grained control over how the browser fetches media from the server. Whether the details belong in the HTML5 spec or not depends on the preferred design - something similar to Flash 10.1's appendBytes() mechanism would affect the video tag interface, for example, while a transport protocol could be completely separate. 3. Content Protection Some of the discussion here seems to have conflated application-controlled video delivery with content protection, but in an ideal world, the two are independent. The basic requirements around content protection that we get I was muddling my recent requests related to browser fetch behavior and application-controlled video delivery: with the despised topic of DRM and content protection. Thanks for clearing that up, John. If a seek on a HTMLMediaElement's exposed and passed along the XHR Request to a fetcher method then I could set my constraints for the impending request. I would add HTTP Range headers if they are not present and set a Range upper bound (since the server will return 402,403, or 416 on any Range: bytes x- request to retrieve the full remaining content). The initiating caller would need to understand that the length of data requested may have shrunk (which would require the browser to seek again when the content was all played up or when the buffer was running low - things that should already be in place). This, to me, seems like an alternative to an addBytes method (if that does what I think it does). This would provide me with a strictly Javascript solution. Other methods I have been asking for would give me a purely HTTP solution (with new range related 4xxs and, spec endorsed, shorter than requested 206 responses) to achieve this or an HTML solution (using new video+source element attributes for buffer (min request size) and max request size).
Re: [whatwg] More YouTube response
On Fri, 2010-07-02 at 02:37 -0700, Henri Sivonen wrote: John Harding jhard...@google.com wrote: Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the video tag for protected content - not all that different than selecting a pluggable codec. I think this would defeat a huge chunk of the value of video. A big part of the value of video is that competition and innovation on the computing platform space will be fostered when the vendor of a computing platform can port (or have ported) one of the Open Source browsers to the platform, pay Opera to port Presto or write their own (like Microsoft) without having to persuade a plug-in proprietor that it's worth the plug-in proprietor's effort to port a certain plug-in to the platform. Pluggable DRM or codec modules would regress back to the situation where the proprietors of those plug-ins act as gatekeepers for the success of computing platforms. I observe that Hollywood movies (the most premium of content, supposedly) are routinely licensed for DVB broadcast without DRM, and on the Internet every other form of content is distributed without DRM. It may well be that when the potential audience grows enough, at some point the ability to reach that audience weighs more than protection and the problem gets solved without DRM (and without the ill effects of DRM to computing platform freedom, competition and innovation). Hey Henri, Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. --fagan
Re: [whatwg] media resources: addressing media fragments through URIs spec
A point in time, if it relates to an I-frame, is very small set and it represents an image. It would be interesting to have img src=file.ogg#t=1:00.5,1:00.5 or animated images in the sense of: img src=file.ogg#t=1:00,1:15 I think the earlier post was looking to display video thumbnails using this sort of fragment notation. If the video wasn't being played I would hope that a browser would fetch the meta data first and then just seek the byte ranges for that fragment. On Fri, Jul 2, 2010 at 4:55 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Actually, a point in time is nothing - it's an empty set. You never want to actually point to a point in time, but rather to either the point in time and an interval after that point in time, or everything from that point onwards. That's what these URIs represent. Cheers, Silvia. On Fri, Jul 2, 2010 at 7:56 AM, Jonas Sicking jo...@sicking.cc wrote: That would be great. I guess it's unclear to me how the UIs would differ for video.ogv#t=40,50 and video.ogv#t=40 In particular it seems strange to me that video.ogv#t=40 represents the whole range from the selected point to the end of the video, given that most commonly when wanting to point out a particular point in a video you actually just want to represent a point. / Jonas On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: BTW: I will try and make a screencast of that firefox plugin, which should clarify things further. Stay tuned... Cheers, Silvia. On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi Jonas, On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking jo...@sicking.cc wrote: Hi Silvia, Back in may last year I brought [1] up the fact that there are two use cases for temporal media fragments: 1. Skipping to a particular point in a longer resource, such as wanting to start a video at a particular point while still allowing seeking in the entire resource. This is currently supported by for example YouTube [2]. It is also the model used for web pages where including a fragment identifier only scrolls to a particular point, while allowing the user to scroll to any point both before and after the identified fragment. 2. Only displaying part of a video. For example out of a longer video from a discussion panel, only displaying the part where a specific topic is discussed. While there seemed to be agreement [3][4] that these are in fact two separate use cases, it seems like the media fragments draft is only attempting to address one. Additionally, it only addresses the one that has the least precedence as far as current technologies on the web goes. Was this an intentional omission? Is it planned to solve use case 1 above in a future revision? [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201 [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html I think you may have misunderstood the specification. Use case 1 is indeed the main use case being addressed in the specification. There is a Firefox plugin implementation[1] of the specification that shows exactly use case 1 in a video element - a URI with a fragment such as video.ogv#t=40,50 is being included in a video element and the effect is that the video is displayed from 40s to 50s, but the transport bar (or controls) are still those of the complete resource, so you can still seek to any position. To be sure, this is just a recommendation of how it is supposed to be implemented (see http://www.w3.org/TR/media-frags/#media-fragment-display). The group only defined what URIs look like that point to such a segment - it cannot prescribe what an application (such as a HTML document) does with the URI. I would propose that this discussion should be had about HTML5 and a sentence be added to the HTML5 spec on how UAs are expected to deal with such segments. Further, if you are indeed only interested in a subpart of the original media resource and want to completely blend out all context (i.e. all other bits of the media resource), you should be using the URI query addressing method instead of the URI fragment, e.g. video.ogv?t=40,50. This URI is supposed to create a new resource that consist only of the segment - it will only do so, of course, if your server supports this functionality. All of this is described in more detail in the spec [2]. If that is unclear or anything is confusing, please do point it out so it can be fixed. Best Regards, Silvia. [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs) [2] http://www.w3.org/TR/media-frags/
Re: [whatwg] More YouTube response
If the seek method was further hookable it should be possible to add decrypt or transcode methods to interpret the fetched content, possibly requesting more data to the filter stream bucket, before apending the bytes of media. On Jul 2, 2010 6:10 AM, Marques Johansson marq...@displague.com wrote: On Thu, Jul 1, 2010 at 6:59 PM, John Harding jhard...@google.com wrote: 2. Robust Video Streamin... I was muddling my recent requests related to browser fetch behavior and application-controlled video delivery: with the despised topic of DRM and content protection. Thanks for clearing that up, John. If a seek on a HTMLMediaElement's exposed and passed along the XHR Request to a fetcher method then I could set my constraints for the impending request. I would add HTTP Range headers if they are not present and set a Range upper bound (since the server will return 402,403, or 416 on any Range: bytes x- request to retrieve the full remaining content). The initiating caller would need to understand that the length of data requested may have shrunk (which would require the browser to seek again when the content was all played up or when the buffer was running low - things that should already be in place). This, to me, seems like an alternative to an addBytes method (if that does what I think it does). This would provide me with a strictly Javascript solution. Other methods I have been asking for would give me a purely HTTP solution (with new range related 4xxs and, spec endorsed, shorter than requested 206 responses) to achieve this or an HTML solution (using new video+source element attributes for buffer (min request size) and max request size).
Re: [whatwg] More YouTube response
On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] 1 new photo on MyDailyFlog!
Hi! I would like you to come and see my latest photos on MyDailyFlog. Check out: http://www.mydailyflog.com/go/invite_register/nandhu_mdf/67426545stc=71 Thanks! nanda kumar ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ To unsubscribe of this type of email from MyDailyFlog in the future, please click below: http://www.mydailyflog.com/un/whatwg@lists.whatwg.orgmd5=57c70ecf3790c7b9bl=16 Please do not reply directly to this email. Questions? Contact us - http://www.mydailyflog.com/go/contact_us MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT.
[whatwg] Check out this photo on MyDailyFlog!
Hi! I would like to invite you to visit MyDailyFlog and see my latest photos. Check out: http://www.mydailyflog.com/go/invite_register/nandhu_mdf/67426545stc=16 Cheers! nanda kumar Got a digital camera? MyDailyFlog is a personal photo-blogging space where you can easily post your latest and greatest photos, and share them with your friends and family. Create your own DailyFlog at www.MyDailyFlog.com ~~ Unsubscribe: to opt out of further invitations from your friends to see their DailyFlogs, please click below: http://www.mydailyflog.com/un/whatwg@lists.whatwg.orgmd5=57c70ecf3790c7b9bl=16 Please do not reply directly to this email. Questions? Contact us - http://www.mydailyflog.com/go/contact_us MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT.
Re: [whatwg] More YouTube response
On 02.07.2010 13:38, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Best regards, Julian
Re: [whatwg] More YouTube response
On Fri, 2010-07-02 at 13:38 +0200, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. Well I got that from what Henri was saying. The reason why I said that was that we cant tell people how to use the spec. The video tag could be used for any kind of video be it a DRM video or non DRM .webm or .mp4 video, its really vendor preference on what they use. Shipping the DRM codec as a plugin will be a lot smaller and a lot easier than shipping the entire flash platform so it would be better than the current situation. I have to clarify that im against DRM anyway because not only does it not protect the content well in most cases but also most of it doesnt work on Linux by default. All im saying is that if youtube has a problem with html5 and want content protection through DRM then thats their decision. --fagan
Re: [whatwg] More YouTube response
If there were hooks for handling the bytes being requested and supplied to the media object, would you agree that DRM modules could be written with Javascript (if a bit of a straw man - as all DRM is perceived to varying degrees)? I think this could prevent the need for some plugins. On Fri, Jul 2, 2010 at 8:17 AM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: On Fri, 2010-07-02 at 13:38 +0200, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. Well I got that from what Henri was saying. The reason why I said that was that we cant tell people how to use the spec. The video tag could be used for any kind of video be it a DRM video or non DRM .webm or .mp4 video, its really vendor preference on what they use. Shipping the DRM codec as a plugin will be a lot smaller and a lot easier than shipping the entire flash platform so it would be better than the current situation. I have to clarify that im against DRM anyway because not only does it not protect the content well in most cases but also most of it doesnt work on Linux by default. All im saying is that if youtube has a problem with html5 and want content protection through DRM then thats their decision. --fagan
[whatwg] Resolutions meta tag proposal
I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals (Currently, although you can use the min-device-pixel-ratio CSS Media Query to achieve this for background images, no such mechanism exists for images displayed via the img tag short of setting a flag in CSS and using image substitution via JavaScript. This new meta tag proposes a JavaScript-free and easy-to-author mechanism to handle the above use case.) I look forward to hearing your thoughts :) All the best, Aral
Re: [whatwg] More YouTube response
On 2010-07-02 13:56, Julian Reschke wrote: On 02.07.2010 13:38, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use. Apple, for example, could support FairPlay protected videos, though the use of such content with video would effectively be limited to within iTunes. Even Matroska has elements that can be used for general purpose encryption and DRM purposes, though these features were not included within WebM. But theoretically, those features could be added and implemented with some agreed upon encryption scheme. I would still, however, argue against anything of the sort being added to WebM because DRM doesn't do anything to protect content, but is rather used as a way for content providers to control the market by blocking unwanted innovation and competition that they don't like, including open source software. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Resolutions meta tag proposal
On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: ... http://wiki.whatwg.org/wiki/MetaExtensions#Proposals In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flo...@2x.jpg, flo...@4x.jpg, and And what if the image was named images/flower (using the accept header to send a jpg vs png vs gif) instead of flower.jpg. The browser would need to have rules about how to rewrite the name of the file. I think @ in the filename would break the many Dos 6.22 based web servers ;-). I don't think a single element with a single attribute can handle this problem. What about an HTTP header like: Accept: image/*;ppiratio=2 This would allow the server to send the correct images for that client or return a 307 to the rewritten filename as the server deems fit. A new Accept property doesn't seem to require changing any specs. I'ld like to think that image/*;q=x could be used in some way for this. On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals (Currently, although you can use the min-device-pixel-ratio CSS Media Query to achieve this for background images, no such mechanism exists for images displayed via the img tag short of setting a flag in CSS and using image substitution via JavaScript. This new meta tag proposes a JavaScript-free and easy-to-author mechanism to handle the above use case.) I look forward to hearing your thoughts :) All the best, Aral
Re: [whatwg] media resources: addressing media fragments through URIs spec
The idea or returning a single image for a URI that points at a video has indeed been discussed. It is not possible to do with a URI fragment, since a URI fragment (#) can only return the same mime type as the main URI. But the suggestion for this is to use a URI query. Then, it is possible to return an image. A URI scheme such as video.ogv?image=64 could be used to provide this (or anything else that your server will make up and provide to clients). Since providing an image in return for a video URI requires some form of transcoding, a URI query is the only way to realise this. On Fri, Jul 2, 2010 at 8:18 PM, Marques Johansson marq...@displague.com wrote: A point in time, if it relates to an I-frame, is very small set and it represents an image. It would be interesting to have img src=file.ogg#t=1:00.5,1:00.5 or animated images in the sense of: img src=file.ogg#t=1:00,1:15 (Note: I'm sure you meant s/ogg/ogv/ so we can talk about video files.) This latter one is already defined as a 5 sec video extract from the full file.ogv - it's not possible to overload that with turning the byte range into an animated gif. You will also need to use transcoding for this and thus will want to create a new URI query scheme. I think the earlier post was looking to display video thumbnails using this sort of fragment notation. If the video wasn't being played I would hope that a browser would fetch the meta data first and then just seek the byte ranges for that fragment. The whole media fragment URI spec is based on retrieving byte ranges. I'd encourage you to read it and see if it matches your expectations. Cheers, Silvia. On Fri, Jul 2, 2010 at 4:55 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Actually, a point in time is nothing - it's an empty set. You never want to actually point to a point in time, but rather to either the point in time and an interval after that point in time, or everything from that point onwards. That's what these URIs represent. Cheers, Silvia. On Fri, Jul 2, 2010 at 7:56 AM, Jonas Sicking jo...@sicking.cc wrote: That would be great. I guess it's unclear to me how the UIs would differ for video.ogv#t=40,50 and video.ogv#t=40 In particular it seems strange to me that video.ogv#t=40 represents the whole range from the selected point to the end of the video, given that most commonly when wanting to point out a particular point in a video you actually just want to represent a point. / Jonas On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: BTW: I will try and make a screencast of that firefox plugin, which should clarify things further. Stay tuned... Cheers, Silvia. On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi Jonas, On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking jo...@sicking.cc wrote: Hi Silvia, Back in may last year I brought [1] up the fact that there are two use cases for temporal media fragments: 1. Skipping to a particular point in a longer resource, such as wanting to start a video at a particular point while still allowing seeking in the entire resource. This is currently supported by for example YouTube [2]. It is also the model used for web pages where including a fragment identifier only scrolls to a particular point, while allowing the user to scroll to any point both before and after the identified fragment. 2. Only displaying part of a video. For example out of a longer video from a discussion panel, only displaying the part where a specific topic is discussed. While there seemed to be agreement [3][4] that these are in fact two separate use cases, it seems like the media fragments draft is only attempting to address one. Additionally, it only addresses the one that has the least precedence as far as current technologies on the web goes. Was this an intentional omission? Is it planned to solve use case 1 above in a future revision? [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201 [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html I think you may have misunderstood the specification. Use case 1 is indeed the main use case being addressed in the specification. There is a Firefox plugin implementation[1] of the specification that shows exactly use case 1 in a video element - a URI with a fragment such as video.ogv#t=40,50 is being included in a video element and the effect is that the video is displayed from 40s to 50s, but the transport bar (or controls) are still those of the complete resource, so you can still seek to any position. To be sure, this is just a recommendation of how it is supposed to be implemented (see http://www.w3.org/TR/media-frags/#media-fragment-display). The group only defined what URIs look like
Re: [whatwg] Resolutions meta tag proposal
Hi Marques, I'm an interaction designer/developer, not a rocket scientist. :) A meta tag, I can easily add. If you start talking about HTTP headers, you've lost me. i.e., this is meant to be a pragmatic, easy-to-author solution. Thanks, Aral On Fri, Jul 2, 2010 at 2:13 PM, Marques Johansson marq...@displague.com wrote: snip And what if the image was named images/flower (using the accept header to send a jpg vs png vs gif) instead of flower.jpg. The browser would need to have rules about how to rewrite the name of the file. I think @ in the filename would break the many Dos 6.22 based web servers ;-). I don't think a single element with a single attribute can handle this problem. What about an HTTP header like: Accept: image/*;ppiratio=2 This would allow the server to send the correct images for that client or return a 307 to the rewritten filename as the server deems fit. A new Accept property doesn't seem to require changing any specs. I'ld like to think that image/*;q=x could be used in some way for this. On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals snip
Re: [whatwg] HTML 5 : The Youtube response
On Wed, 2010-06-30 at 18:11 -0700, David Singer wrote: I think it's interesting to look at these and ask to what extent they are in scope. 1. Standard video format 2. Robust video streaming 3. Content Protection 4. Encapsulation + embedding 5. Fullscreen video 6. Camera and Microphone access #4 is soluble 'on top of' HTML5 and the media formats, if needed. Web Archives, Web Apps, and so on. I think. Yes, iframes, objecs and audio/videos should solve the problem of embedding, and (if I understand the meaning of Encapsulation correctly) html wrappers should solve encapsulation as well. #5 is a problem only if you care about phishing attacks...or indeed apps that have the gall to believe that you should be able to see nothing else when they are running. We talked about this a week or two ago and the idea was to have a allow full screen element in the video tag that makes a control that can be used by the user to go full screen. The problem here is abuse but I think the browser vendors should make some safeguards if this is the route they take. #6 is well, rather different from the problem of delivering a/v to a user. I'm not enthusiastic about web pages that can listen to me or watch me, myself... Agreed, such access for web pages should be limited to input type=file. That would require the user to go out of his way to grossly violate his privacy rather than just clicking OK or being click-jacked into approving of recording of himself (such as with interactive JavaScripts and CSS'd images of hot women labeled Click here for more). Camera and mic access could be done in the spec IMO and it would be useful. How its implemented would be interesting. For sites like hotmail, gmail, youtube(for their webcam capture)..etc that have integrated chat it would be very useful. Obviously in terms of implementation they would have to safe guard by asking. Id look for something as simple as webcam / or mic / or something and dont have any parameters and allow the browser to work out what to do would be ok to put in the spec. Its a little bit out there but I think it would be beneficial if its a blocker for some sites. Will webcam and mic be form elements, interactive content that can go anywhere in a web page? If the latter, what whould HTML renderers do with it? But you're probably thinking about device, save the no @attrs suggestion. I for one don't understand why this would be any better than (in the case of form elements) input type=file accept=video/*|audio/* and for more complex and esoteric use cases (i.e. webapps), the device APIs from the DAP WG of W3C.
Re: [whatwg] HTML 5 : The Youtube response
Also related discussion, where I proposed something similar on WHATWG: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg21565.html On Thu, Jul 1, 2010 at 2:02 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 1, 2010, at 1:37 PM, Kevin Carle wrote: One part of (2) [well, debatably part, but related to video streaming] is the lack of visibility into stream behavior. I can't ask the video element questions about dropped frames, bitrate, etc. This is incredibly useful in Flash for getting streaming feedback, and means I really don't know how well the HTML5 player is working for users. The best I can do is waiting/stalled events which is nowhere near as granular. I agree that exposing info like that would be useful. What does the Flash API for this look like? What parts of the available data do you find most useful? Regards, Maciej -Kevin On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote: I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient: A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened. B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor. C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5 . D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms. E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W). F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode. I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate. Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen — text and UI elements displayed by attacker will look noticeably different. That would probably make the controls look ugly for video with custom controls, and I suspect neither users nor content authors would appreciate that. Interesting idea, though. - Maciej
Re: [whatwg] Resolutions meta tag proposal
On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals I don't know what the right solution is for this problem (other than use SVG :) ), but I don't think your proposal is workable. Inevitably, some images will be available in different sizes and some not, but your proposed meta tag will affect all images on the page. Also, the author needs to be able to control the names of the resized images to fit their needs -- on a site allowing user-uploaded images, for instance, you might not be able to guarantee that there isn't already a file named flo...@2x.jpg in the directory. The most natural way to do something like this is probably along the lines of content negotiation, but as we all know, that doesn't work well in practice because it's hard for authors to set up. Ideally, you could have the browser include a Resolution: header or something like that, saying what resolution it expects to see, and then the web server should automatically try resizing the image to match (using appropriate caching). But this is too hard to deploy and control. So I don't have any really good ideas.
Re: [whatwg] More YouTube response
On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: On 2010-07-02 13:56, Julian Reschke wrote: On 02.07.2010 13:38, Anne van Kesteren wrote: Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use. Apple, for example, could support FairPlay protected videos, though the use of such content with video would effectively be limited to within iTunes. Even Matroska has elements that can be used for general purpose encryption and DRM purposes, though these features were not included within WebM. But theoretically, those features could be added and implemented with some agreed upon encryption scheme. I would still, however, argue against anything of the sort being added to WebM because DRM doesn't do anything to protect content, but is rather used as a way for content providers to control the market by blocking unwanted innovation and competition that they don't like, including open source software. I think it's unavoidable that the functionality of the video tag in some browsers will be extended by various add-ons to the browser. IE's implementation uses whatever codecs are installed and available to DirectShow; my understanding is that Safari operates this way as well. My point here is primarily that it would be good for video tag adoption in general if browsers enabled traditional DRM solutions to integrate in this way. It still requires that users will have some non-open software installed on their machine (that's unavoidable as long as content owners require it of us), but means that users can continue using their browser of choice, and content distributors don't need to write a completely new player for each DRM provider they need to support.
Re: [whatwg] More YouTube response
On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2010-07-02 13:56, Julian Reschke wrote: On 02.07.2010 13:38, Anne van Kesteren wrote: On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have video in the first place. That may be true. But there's nothing in the spec that actually disallows adding support for plugin-based DRM, right? (Just clarifying) Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use. Apple, for example, could support FairPlay protected videos, though the use of such content with video would effectively be limited to within iTunes. Even Matroska has elements that can be used for general purpose encryption and DRM purposes, though these features were not included within WebM. But theoretically, those features could be added and implemented with some agreed upon encryption scheme. I would still, however, argue against anything of the sort being added to WebM because DRM doesn't do anything to protect content, but is rather used as a way for content providers to control the market by blocking unwanted innovation and competition that they don't like, including open source software. Indeed. Also compare to the recent battle that was fought over font formats. Some parties where heavily pushing for DRM formats, however ultimately we were able to persuade them that this wasn't needed, and we ended up with a format that everyone is happy with. / Jonas
Re: [whatwg] More YouTube response
On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. Wouldn't it be straightforward for YouTube to offer iframe support right now, in addition to object? The backend support should be simple to do. If you keep the object code as the default embed recommendation and hide the iframe embed code somewhere so people will only use it if they look for it, you won't risk confusing anyone. Sites that currently whitelist object from YouTube will eventually whitelist iframe from YouTube too -- I hope there aren't many sites that permit *arbitrary* objects to be inserted by untrusted users. Allowing iframe will have other benefits, like allowing fallback install Flash content (currently omitted from the object code, I assume to keep the size down). Yes, it's pretty straightforward to offer iframe-based embed code, but it needs to be coupled with getting sites to accept them, or we end up with a lot of confused, unhappy users. Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. Another thing that occurs to me is that you might show HTML5 video when Flash isn't installed/enabled, or when the Flash player crashes. Or at least you could give an option, instead of just failing silently (for embeds) or saying the user should install Flash (on the site itself). My primary machine runs Linux, and Flash usually doesn't work at all. If I didn't know about the HTML5 beta, I wouldn't be able to use YouTube at all. And as it is, I can't use any YouTube embeds most of the time. Yes, this is the main point of using an iframe to embed code - it allows the site providing embeddable content to tailor the presentation to the user/device/context at runtime, rather than requiring the presentation to be fixed up-front. When limiting keyboard input, I'd suggest devices w/ onscreen keyboards simply disable the keyboard. Applications that work well with touch interfaces generally provide gesture alternatives for the limited set of keys that would be available. Alternately, devices could limit the keyboard to the set of allowed keys. The problem is if the program makes a fake keyboard and then directly intercepts touch events to that location, without invoking the OS's keyboard at all. The user won't be able to tell that the keypresses are going to the website instead of the OS. But I can't see this as being a big issue -- screen space is so limited on these devices that websites are fullscreen anyway, or practically. On my Nexus One, unless you're scrolled to the top of the site, websites take up the whole screen except for the bar at the top, which is present in all apps. So they could already trivially spoof any application, if they know the target platform. Not if the user presses the menu button, I guess. Yeah, I realized that loophole after I sent the mail. The same vulnerability is there if fullscreen is initiated by a control the browser chrome, though - at the end of the day, the primary problem to solve is ensuring that users understand they're still viewing a web page, and the contents are provided by the web page rather than the OS. As pointed out, this is not strictly an issue for video tag, though certainly related especially for local preview. I have not been closely following the work on the device element, though that seems to be where this is headed. device adoption shouldn't interfere with video adoption, though. Even if YouTube switched to video by default, it could keep Flash for recording until device was implemented. It's probably best for implementers to focus on perfecting video (and maybe canvas, etc.) before they put too much work into device, since those are much bigger use-cases. You're absolutely right, and I think the order things are going is correct - video is more important than device
[whatwg] Check out this photo on MyDailyFlog!
Hello!!! I just uploaded a photo on nandhu_mdf's DailyFlog page that I want you to see. Check out: http://www.mydailyflog.com/go/invite_register/nandhu_mdf/67426545stc=82 Cheers! Got a digital camera? MyDailyFlog is a personal photo-blogging space where you can easily post your latest and greatest photos, and share them with your friends and family. Create your own DailyFlog at www.MyDailyFlog.com ... Unsubscribe: to opt out of further invitations from your friends to see their DailyFlogs, please click below: http://www.mydailyflog.com/un/whatwg@lists.whatwg.orgmd5=57c70ecf3790c7b9bl=82 Please do not reply directly to this email. Questions? Contact us - http://www.mydailyflog.com/go/contact_us MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT. ...
Re: [whatwg] More YouTube response
On 2010-07-02 21:01, John Harding wrote: On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Huntlachlan.h...@lachy.id.auwrote: Correct. Vendors can theoretically implement any codec or container they like, with any features or limitations they like. MP4 already has various DRM schemes in use... I would still, however, argue against anything of the sort being added to WebM... I think it's unavoidable that the functionality of thevideo tag in some browsers will be extended by various add-ons to the browser. Right, as I said, it's possible. But that doesn't mean we should support it in any way. YouTube would do better to address this issue by bringing the major players in the content industry to the table to discuss methods of publishing their content in interoperable ways without DRM. As Henri pointed out, major content producers already broadcast their TV shows and movies over the air without DRM. Although the BBC iPlayer uses DRM for the desktop version, they broadcast the show DRM free over the air and they make DRM free content available to the iPhone. People have even found ways to access that from other devices too. So the DRM really isn't there to protect the content. It's just to force users to use the BBC's own iPlayer software, rather than letting users use their own choice of software. The industry even releases content on DVD knowing that the DRM is completely ineffective, because they only use it so they can control the DVD player market, rather than actually doing anything practical about illegal copying. The music industry have already largely dropped DRM. Even Spotify, which does use DRM, permits the open source application deSpotify that bypasses the DRM to continue unimpeded for premium subscribers. (The developers opted not to work around the blocks placed on free accounts though). It's all about the business model. The industry thinks they need their DRM so they can hold onto the same business model they've had for years, without adapting. That's why they've gone to court over every new innovation in the last 50 years, before slowly catching up. The truth is they don't need DRM, as so many independent content producers are demonstrating. YouTube and other video streaming sites just needs to push them to accept a reasonable and fair business model that will work. Make it easy for users to stream the content, and even easier for users who want to buy and download the content legally. Users currently go to torrent sites because it's easier than fighting with the industry to get what they want. Make it easier to do the right thing. Don't punish the legitimate them with DRM, while the pirates get away with a better user experience. Give users a real reason to buy, and they will. e.g. Make the purchased content have a higher bit-rate and resolution, surround sound, no ads, no visible logo watermark, and/or other added features. Provide some incentive, maybe a reward system that benefits the subscribers in some tangible way. Do whatever you do to find a business model that works; just say no to DRM. It's not needed. The big content industry knows that, they just won't admit it. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Resolutions meta tag proposal
On 2 July 2010 14:28, Aral Balkan a...@aralbalkan.com wrote: Hi Marques, I'm an interaction designer/developer, not a rocket scientist. :) A meta tag, I can easily add. If you start talking about HTTP headers, you've lost me. i.e., this is meant to be a pragmatic, easy-to-author solution. I think this point Aral made is very important. This is the kind of stuff that falls under the sphere of the designer/markup author, who might not have control on the webserver configuration. If there is a solution (or solutions), there should exist at least one in the realm of the markup. That's not to say there can't be more than one way of doing this.. content negotiation sounds good, too. I've been musing over this since I read Aral's post... I've been leaning towards a mixture of media queries and a base tag... to specify a different folder for each resolution... but, as it's been pointed out here this would apply to all img tags. This brings me to another question... shouldn't the same exist for all kinds of visual media resources? Thinking img, video, object and possibly iframe. (alt-option 1) Trying to step away from the solution presented, I can only imagine something along the lines of different src attributes for different resolutions: img src=imgs/standard-def.png src-2x=imgs/high-def.png video src=movs/sd.ogv src-2x=movs/hd.ogv But this might be pushing the syntax a bit too further... but it gracefully degrades and can be controlled on a per element basis. (alt-option 2) Or maybe allow an approach similiar to video tag for imgs? img source src= media=..insert media query here.. ? -- André Luís http://id.andr3.net/ On 2 July 2010 18:22, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals I don't know what the right solution is for this problem (other than use SVG :) ), but I don't think your proposal is workable. Inevitably, some images will be available in different sizes and some not, but your proposed meta tag will affect all images on the page. Also, the author needs to be able to control the names of the resized images to fit their needs -- on a site allowing user-uploaded images, for instance, you might not be able to guarantee that there isn't already a file named flo...@2x.jpg in the directory. The most natural way to do something like this is probably along the lines of content negotiation, but as we all know, that doesn't work well in practice because it's hard for authors to set up. Ideally, you could have the browser include a Resolution: header or something like that, saying what resolution it expects to see, and then the web server should automatically try resizing the image to match (using appropriate caching). But this is too hard to deploy and control. So I don't have any really good ideas.
Re: [whatwg] More YouTube response
On Jul 2, 2010, at 12:09 PM, John Harding wrote: On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor simetrical+...@gmail.com wrote: As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via iframe will be a big step forward. Wouldn't it be straightforward for YouTube to offer iframe support right now, in addition to object? The backend support should be simple to do. If you keep the object code as the default embed recommendation and hide the iframe embed code somewhere so people will only use it if they look for it, you won't risk confusing anyone. Sites that currently whitelist object from YouTube will eventually whitelist iframe from YouTube too -- I hope there aren't many sites that permit *arbitrary* objects to be inserted by untrusted users. Allowing iframe will have other benefits, like allowing fallback install Flash content (currently omitted from the object code, I assume to keep the size down). Yes, it's pretty straightforward to offer iframe-based embed code, but it needs to be coupled with getting sites to accept them, or we end up with a lot of confused, unhappy users. Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. Any site which does that has a giant security hole, since Flash can be used to arbitrarily script the embedding page. It's about as safe as allowing embedding of arbitrary off-site script. If you are aware of sites that allow embedding of arbitrary off-site Flash, you should alert them to the potential security risks. For example a social network site that allowed this would be vulnerable to a self-propagating worm. What I have heard before is that sites whitelist specific SWFs or Flash from specific domains. I'm don't have any first-hand knowledge of how sites actually do it. Regards, Maciej
Re: [whatwg] More YouTube response
On Jul 2, 2010, at 6:04 PM, Maciej Stachowiak wrote: Any site which does that has a giant security hole, since Flash can be used to arbitrarily script the embedding page. It's about as safe as allowing embedding of arbitrary off-site script. If you are aware of sites that allow embedding of arbitrary off-site Flash, you should alert them to the potential security risks. For example a social network site that allowed this would be vulnerable to a self-propagating worm. What I have heard before is that sites whitelist specific SWFs or Flash from specific domains. I'm don't have any first-hand knowledge of how sites actually do it. With testing I found at least one site where I can apparently embed arbitrary SWFs. However, this site has per-user domains, so it might be relatively safe. This site also allows me to embed arbitrary content in an iframe. Regards, Maciej
