Re: [whatwg] media resources: addressing media fragments through URIs spec
On Sun, Jul 4, 2010 at 5:26 AM, silviapfeiffer1 silviapfeiff...@gmail.com wrote: It doesn't actually matter what element the URI appears in - your element has to deal with the data that it receives and if file.ogv#t=1:00,1:15 is an Ogg Theora segment out of a video, then that is what the img element receives. right. I am not aware though of any img element implementation that can deal with Ogg Theora video. That's changeable. And you seem to be totally ignoring that this is the thrust of someone else's request. Note that I'm not the one asking for it. Just trying to explain it to you since you seem to be doing a good job of totally missing the point. If you are, however, asking to turn the Ogg Theora video into a APNG or a animated GIF or even a MNG, there will need to be a transcoding step at the server, No no. If a browser can decode a frame or sequence of frames from an ogg, then it can display them, and since it can display various image formats in img (jpg, gif, png, apng, potentially mng, and in future geckos SVG), then someone (not me!) is merely suggesting that ogg be another one, either as a single frame or an animated sequence.
Re: [whatwg] Resolutions meta tag proposal
Another way about handling this PPI ratio business would be with HTTP 300 multiple choice. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 This may not be the best answer for every image on a page, but the first HTML page in a server controlled session could store the PPI ratio setting based on the page the UA chooses and then modify the HTML or content-negotiation setting. A problem with this is that the browsers wouldn't be likely to render a page correctly unless they were modified for this image request yields 300 behavior. I still like something like this for client content negotiation: GET /image/dog HTTP/1.1 Accept: image/*; ppiratio=2 ... HTTP/1.1 200 OK Content-type: image/jpeg ... d...@2x.jpg Apache rewrite rules could even handle this by detecting ppiratio in the Accept header and then looking for a matching images/ratio/2/dog file. If it didn't exist the rewrite would fail resulting in the server responding with images/dog which is suitable if not optimal. This has me thinking Accept: image/*; x=400; y=300 could be attached with any image request based on clients intent for the image. (The HTML said 'width=400 height=300' so I don't need anything better.) The server can ignore this or return something better suited than the 1200x1200 image that it would otherwise return. I still don't have a handle on this retinal / ppi stuff so ppiratio may be the wording. I also like Accept: video/*; kbps=500 for a similar purpose. 2010/7/3 timeless timel...@gmail.com 2010/7/3 André Luís andreluis...@gmail.com: (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 img lowsrc used to exist: http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html it's mostly gone now. I think that if someone wants to be fancy they can use the existing features (min-device-pixel-ratio, alternate stylesheets) and hide the img content and replace it with background images or something.
Re: [whatwg] More YouTube response
Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2010-07-02 21:01, John Harding wrote: On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Huntlachlan.h...@lachy.id.auwrote: 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. I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? 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. How can the industry have control over the DVD player market and not their own government-designated markets?
Re: [whatwg] media resources: addressing media fragments through URIs spec
On Sun, Jul 4, 2010 at 9:43 PM, timeless timel...@gmail.com wrote: On Sun, Jul 4, 2010 at 5:26 AM, silviapfeiffer1 silviapfeiff...@gmail.com wrote: It doesn't actually matter what element the URI appears in - your element has to deal with the data that it receives and if file.ogv#t=1:00,1:15 is an Ogg Theora segment out of a video, then that is what the img element receives. right. I am not aware though of any img element implementation that can deal with Ogg Theora video. That's changeable. And you seem to be totally ignoring that this is the thrust of someone else's request. Note that I'm not the one asking for it. Just trying to explain it to you since you seem to be doing a good job of totally missing the point. Same here. ;-) Note that I do understand the need and am trying to explain how it can be made to work. Also I am trying to show that what might look as the simplest approach won't work and why. If you are, however, asking to turn the Ogg Theora video into a APNG or a animated GIF or even a MNG, there will need to be a transcoding step at the server, No no. If a browser can decode a frame or sequence of frames from an ogg, then it can display them, and since it can display various image formats in img (jpg, gif, png, apng, potentially mng, and in future geckos SVG), then someone (not me!) is merely suggesting that ogg be another one, either as a single frame or an animated sequence. All of the image formats that you are pointing out have an image mime type. I am merely pointing out that to support ogg theora browsers would need to support a video mime type in an img element. I don't see that as the intention of the img element, in particular since img elements do not have transport controls and the like. Otherwise, why did we create a video element in the first place. So, I am just pointing out that with current img element implementations and with the existing intentions of img elements (as opposed to video elements), using a segment of Ogg Theora video as defined through a media fragment URI will not work as an image resource and will also not work as a video resource. Hope that clarifies it. Regards, Silvia.
Re: [whatwg] More YouTube response
On Fri, Jul 2, 2010 at 3:09 PM, John Harding jhard...@google.com wrote: 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. This will only happen if the iframe support is widely advertised, though. I assume that practically everyone who embeds YouTube videos just copies the code given under the video. If iframe support were only mentioned in out-of-the-way places (like only if you've opted into the HTML5 beta) and labeled with only use this if you're sure you don't want the normal embed code, it would allow people who cared to use it, and they could push sites to whitelist it if any don't. This is probably low-priority from your perspective, I can see that. But it's pretty sad when the IE blog is now consistently using video instead of Flash, while the Chrome blog only uses Flash embeds (because of the YouTube dependency). Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. I'd be very surprised if major sites allowed arbitrary Flash but not arbitrary iframe. The former is extremely dangerous, the latter is not (although it could still create annoying popups, etc.). Do you have an example of such a site? On Fri, Jul 2, 2010 at 4:56 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: 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. Given how many lawsuits those major players have filed against Google *despite* concessions on DRM, I don't think it's practical to suggest that Google should provoke them even *more*. However, this isn't something standards groups have to deal with, since standardized DRM is more or less a contradiction in terms (in the absence of hardware support). Flash can continue to be used for video indefinitely where DRM is desired, just as Flash is occasionally used for still image galleries to prevent easy copying.
Re: [whatwg] media resources: addressing media fragments through URIs spec
On Sun, Jul 4, 2010 at 9:19 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: All of the image formats that you are pointing out have an image mime type. I am merely pointing out that to support ogg theora browsers would need to support a video mime type in an img element. I don't see that as the intention of the img element, in particular since img elements do not have transport controls and the like. Otherwise, why did we create a video element in the first place. I'd expect that a video in img would behave like an animated GIF -- no sound, no APIs to control playback, no browser-provided controls. You might want this sometimes, especially if you're only selecting one frame. Animated images are conceptually different from videos, and there's no reason you couldn't support the same format for both img and video, with those different semantics. It would be particularly useful to support video frames as images in places where video can't be used, like for the video poster attribute, CSS backgrounds, and so on. The video MIME type does not conflict at all with allowing this kind of usage. So to cover this use-case, it would be good if there were a way of explicitly selecting one frame, which could be treated as a video that contains only one frame. This might, in turn, be accepted by some browsers in places where they accept images. You could do this by explicitly allowing syntax like #t=10,10, where the start point equals the end point, as selecting only one frame. (But I guess this could be emulated by #t=10,10.001 or something, assuming the frame starts at exactly t=10.)
Re: [whatwg] media resources: addressing media fragments through URIs spec
On Sun, Jul 4, 2010 at 4:19 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Note that I do understand the need and am trying to explain how it can be made to work. Also I am trying to show that what might look as the simplest approach won't work and why. It doesn't have to be made to work that way, which is the point that the others were trying to make. http://www.w3.org/TR/REC-html40/struct/objects.html#adef-src-IMG src = uri [CT] This attribute specifies the location of the image resource. Examples of widely recognized image formats include GIF, JPEG, and PNG. Nothing in the definition here says the img tag only allows mime types of image/* http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-src The src attribute must be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted. Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs), single-page vector documents (single-page PDFs, XML files with an SVG root element), animated bitmaps (APNGs, animated GIFs), animated vector graphics (XML files with an SVG root element that use declarative SMIL animation), and so forth. However, this also precludes SVG files with script, multipage PDF files, interactive MNG files, HTML documents, plain text documents, and so forth. While there is text in the html5 definition which precludes scripts, it too doesn't explicitly limit the range to image/*, and in fact I believe since the PDF mime type is application/pdf, it's safe to say that browsers do render things which are not image/*. In testing, although Chrome, Safari, Opera, and Minefield (after bug 276431) support image/svg+xml today none support application/svg+xml. However, as Safari supports application/pdf, the cat's out of the bag on non image/ mime types. http://www.webwizardry.net/~timeless/svg/276431.html All of the image formats that you are pointing out have an image mime type. I should have listed PDF which doesn't, mia culpa -- It is in the HTML5 specification as a suggestion as noted above in this reply. I am merely pointing out that to support ogg theora browsers would need to support a video mime type in an img element. You didn't point that out, you suggested that instead servers would have to do content conversions. I don't see that as the intention of the img element, in particular since img elements do not have transport controls and the like. html5: An img element represents an image., that's all the proposal wants, an image, a non interactive image (possibly animated), and it's possible to decode an ogg video in a way which achieves this. Otherwise, why did we create a video element in the first place. http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video html5: A video element is used for playing videos or movies. User agents should provide controls to enable or disable the display of closed captions, audio description tracks, and other additional data associated with the video stream, though such features should, again, not interfere with the page's normal rendering. User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent. Video offers video controls, the suggestions which you were presented were clearly instances where people just wanted animated frames without such controls. So, I am just pointing out that with current img element implementations and with the existing intentions of img elements (as opposed to video elements), using a segment of Ogg Theora video as defined through a media fragment URI will not work as an image resource and will also not work as a video resource. In order to support media fragments, media fragment support would have to be implemented. This is obvious to everyone. Similarly, adding support for ogg in img would require adding support for ogg in img, just as adding support for svg in img requires adding support for svg in img. Of note, since SVG is already supported by most browsers, the incremental cost of adding svg support in img is relatively low (as seen demonstrated by https://bugzilla.mozilla.org/show_bug.cgi?id=276431 which adds it to Gecko). This is in contrast with the cost of adding media fragment support, which is essentially entirely new code. But once it's there, the cost of letting it work in an img tag would not be very high. Again, I'm not saying it should be done, but you've chosen to ignore how it could work and
Re: [whatwg] Resolutions meta tag proposal
On 2010-07-04 14:34, Marques Johansson wrote: Another way about handling this PPI ratio business would be with HTTP 300 multiple choice. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 This may not be the best answer for every image on a page, but the first HTML page in a server controlled session could store the PPI ratio setting based on the page the UA chooses and then modify the HTML or content-negotiation setting. A problem with this is that the browsers wouldn't be likely to render a page correctly unless they were modified for this image request yields 300 behavior. I still like something like this for client content negotiation: GET /image/dog HTTP/1.1 Accept: image/*; ppiratio=2 ... HTTP/1.1 200 OK Content-type: image/jpeg ... d...@2x.jpg Apache rewrite rules could even handle this by detecting ppiratio in the Accept header and then looking for a matching images/ratio/2/dog file. If it didn't exist the rewrite would fail resulting in the server responding with images/dog which is suitable if not optimal. This has me thinking Accept: image/*; x=400; y=300 could be attached with any image request based on clients intent for the image. (The HTML said 'width=400 height=300' so I don't need anything better.) The server can ignore this or return something better suited than the 1200x1200 image that it would otherwise return. I still don't have a handle on this retinal / ppi stuff so ppiratio may be the wording. I also like Accept: video/*; kbps=500 for a similar purpose. Again this is negotiation related, and although I'm able to do fancy apache stuff on my site I'd rather not have to. This however takes advantage of CSS http://www.alistapart.com/articles/hiresprinting/ Not exactly ideal, but I think it's the better approach, it just need to be refined and standardized some way. But here's an idea I have that would fit into HTML5. Examples: 1. img src=img/test.png width=512 height=256 dpi=96;;300;image/test300.png work better? (96 dpi is current thus empty ;; while 300 dpi is alternative hence specified. 2. img src=img/test.png width=512 height=256 dpi=300 woould also be valid, indicating that the image is 300 dpi and no alternatives. 3. img src=img/test.png width=512 height=256 dpi=300;image/test300.png same as example 1, 96 dpi default assumed. 4. img src=img/test.png width=512 height=256 dpi=*;image/test.svg 96 dpi default assumed, the * indicate any DPI and in this case it's a vector format. If dpi= or is not specified, then the image should be assumed to be 96dpi, unless the image format has it's own dpi info (JPG support this, but does PNG?) that is. This would make printouts look better, and allows the author to specify displayed size (width and height being logical pixels for non-96 dpi images obviously) High DPI displays would make the browser get the high dpi image instead of the default. The only parts of a site that has issues currently is fixed pixel graphics (and fixed pixel based layout as well I guess), it is only pixel based (bitmapped) images that has issues with scaling, embed video already tend to offer multiple resolutions. So a dpi param for img might just be a nice way to fix the issue. The CSS folks might have to add some support for this too, as well as scripting support. This is just something I came up with right now, but it's at least simple in use which is the important thing I guess. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] More YouTube response
On 4 July 2010 13:57, bjartur svartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. It's all very complicated when real money is at stake. (c.f. The Innovator's Dilemma.) That said: DRM is a provably broken concept. Anyone who demands it be incorporated into a standard is fundamentally, deeply wrong and can work around it with some sort of proprietary plugin, because that way they won't be requiring anyone else to pretend mathematics doesn't work. - d.
Re: [whatwg] More YouTube response
On Sun, 2010-07-04 at 23:56 +0100, David Gerard wrote: On 4 July 2010 13:57, bjartur svartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. It's all very complicated when real money is at stake. (c.f. The Innovator's Dilemma.) That said: DRM is a provably broken concept. Anyone who demands it be incorporated into a standard is fundamentally, deeply wrong and can work around it with some sort of proprietary plugin, because that way they won't be requiring anyone else to pretend mathematics doesn't work. - d. I agree. I don't condone illegally distributing digital content, but DRM doesn't have a good track record. At best, it disrupts illegal copyright infringement, at its worst, it harms the honest consumer. The game Spore was arguably one of the most copyrighted games ever, despite (or maybe because of) its almost draconian DRM. DVD's suffered for a long time with being locked into regions by DRM, making it difficult for people who travelled a lot but wanted to watch films, and made little or no impact on those that obtained an illegal DRM-free copy. There are countless more tales all like this, but until a fiscally viable alternative is offered to the media companies (as let's face it, it's not the artists pushing for DRM!) then we will continue to see more measures brought into place and broken. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] media resources: addressing media fragments through URIs spec
On Mon, Jul 5, 2010 at 2:46 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Sun, Jul 4, 2010 at 9:19 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: All of the image formats that you are pointing out have an image mime type. I am merely pointing out that to support ogg theora browsers would need to support a video mime type in an img element. I don't see that as the intention of the img element, in particular since img elements do not have transport controls and the like. Otherwise, why did we create a video element in the first place. I'd expect that a video in img would behave like an animated GIF -- no sound, no APIs to control playback, no browser-provided controls. You might want this sometimes, especially if you're only selecting one frame. Animated images are conceptually different from videos, and there's no reason you couldn't support the same format for both img and video, with those different semantics. It would be particularly useful to support video frames as images in places where video can't be used, like for the video poster attribute, CSS backgrounds, and so on. The video MIME type does not conflict at all with allowing this kind of usage. So to cover this use-case, it would be good if there were a way of explicitly selecting one frame, which could be treated as a video that contains only one frame. This might, in turn, be accepted by some browsers in places where they accept images. You could do this by explicitly allowing syntax like #t=10,10, where the start point equals the end point, as selecting only one frame. (But I guess this could be emulated by #t=10,10.001 or something, assuming the frame starts at exactly t=10.) The issue with #t=10,10 is that the semantics of the interval are that of a semi-open interval: the start point is in and the end point is out. This has been the traditional understanding of an interval related to video (e.g. RTSP defines it that way too). Thus, video.ogv#t=10,10 is like asking from byte range 50 to 50 - it's simply empty. Further, there are complications with extracting a single frame from a video since not every point in time will map onto a keyframe, but most will map onto intra frames, i.e. non-complete frames. Thus, if you ask for #t=10,10.001, you will most likely receive a region around that time segment that is a decodable video byte range - maybe a region that maps to #t=9.02, 12.4 - the UA will know what it asked for and be able to display only the actually requested part in the middle after decoding all the bits. To repeat: I am not convinced it is a good idea to support the video mime type in an img element, even if we change the semantics and ignore the audio etc. I am not saying it is not possible, I am just saying that I would not recommend it and would suggest to rather do it on the server with some transcoding action - it is really not difficult to install ffmpeg or mplayer on the server, develop a query format that delivers keyframes from a particular time offset, and do a keyframe dump on the server upon request. You might want to cache the result, too. Cheers, Silvia.
Re: [whatwg] media resources: addressing media fragments through URIs spec
On Mon, Jul 5, 2010 at 4:23 AM, timeless timel...@gmail.com wrote: On Sun, Jul 4, 2010 at 4:19 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Note that I do understand the need and am trying to explain how it can be made to work. Also I am trying to show that what might look as the simplest approach won't work and why. It doesn't have to be made to work that way, which is the point that the others were trying to make. http://www.w3.org/TR/REC-html40/struct/objects.html#adef-src-IMG src = uri [CT] This attribute specifies the location of the image resource. Examples of widely recognized image formats include GIF, JPEG, and PNG. Nothing in the definition here says the img tag only allows mime types of image/* http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-src The src attribute must be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted. Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs), single-page vector documents (single-page PDFs, XML files with an SVG root element), animated bitmaps (APNGs, animated GIFs), animated vector graphics (XML files with an SVG root element that use declarative SMIL animation), and so forth. However, this also precludes SVG files with script, multipage PDF files, interactive MNG files, HTML documents, plain text documents, and so forth. While there is text in the html5 definition which precludes scripts, it too doesn't explicitly limit the range to image/*, and in fact I believe since the PDF mime type is application/pdf, it's safe to say that browsers do render things which are not image/*. In testing, although Chrome, Safari, Opera, and Minefield (after bug 276431) support image/svg+xml today none support application/svg+xml. However, as Safari supports application/pdf, the cat's out of the bag on non image/ mime types. http://www.webwizardry.net/~timeless/svg/276431.html All of the image formats that you are pointing out have an image mime type. I should have listed PDF which doesn't, mia culpa -- It is in the HTML5 specification as a suggestion as noted above in this reply. I am merely pointing out that to support ogg theora browsers would need to support a video mime type in an img element. You didn't point that out, you suggested that instead servers would have to do content conversions. I don't see that as the intention of the img element, in particular since img elements do not have transport controls and the like. html5: An img element represents an image., that's all the proposal wants, an image, a non interactive image (possibly animated), and it's possible to decode an ogg video in a way which achieves this. Otherwise, why did we create a video element in the first place. http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video html5: A video element is used for playing videos or movies. User agents should provide controls to enable or disable the display of closed captions, audio description tracks, and other additional data associated with the video stream, though such features should, again, not interfere with the page's normal rendering. User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent. Video offers video controls, the suggestions which you were presented were clearly instances where people just wanted animated frames without such controls. So, I am just pointing out that with current img element implementations and with the existing intentions of img elements (as opposed to video elements), using a segment of Ogg Theora video as defined through a media fragment URI will not work as an image resource and will also not work as a video resource. In order to support media fragments, media fragment support would have to be implemented. This is obvious to everyone. Similarly, adding support for ogg in img would require adding support for ogg in img, just as adding support for svg in img requires adding support for svg in img. Of note, since SVG is already supported by most browsers, the incremental cost of adding svg support in img is relatively low (as seen demonstrated by https://bugzilla.mozilla.org/show_bug.cgi?id=276431 which adds it to Gecko). This is in contrast with the cost of adding media fragment support, which is essentially entirely new code. But once it's there, the cost of letting it
Re: [whatwg] media resources: addressing media fragments through URIs spec
Aryeh Gregor simetrical+...@gmail.com wrote: On Sun, Jul 4, 2010 at 9:19 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: All of the image formats that you are pointing out have an image mime type. I am merely pointing out that to support ogg theora browsers would need to support a video mime type in an img element. I don't see that as the intention of the img element, in particular since img elements do not have transport controls and the like. Otherwise, why did we create a video element in the first place. I'd expect that a video in img would behave like an animated GIF -- no sound, no APIs to control playback, no browser-provided controls. Is the no controls part specified by the spec? A MUST in that regard seems plain wrong. UI shall be implementation defined. The video element is there to allow webapp authors to control the playback of video they link to in ways that may make even less sense for different media types and to allow linking to multiple related media streams. You might want this sometimes, especially if you're only selecting one frame. Animated images are conceptually different from videos, and there's no reason you couldn't support the same format for both img and video, with those different semantics. It would be particularly useful to support video frames as images in places where video can't be used, like for the video poster attribute, CSS backgrounds, and so on. The video MIME type does not conflict at all with allowing this kind of usage. So to cover this use-case, it would be good if there were a way of explicitly selecting one frame, which could be treated as a video that contains only one frame. This might, in turn, be accepted by some browsers in places where they accept images. You could do this by explicitly allowing syntax like #t=10,10, where the start point equals the end point, as selecting only one frame. (But I guess this could be emulated by #t=10,10.001 or something, assuming the frame starts at exactly t=10.) IMO single frames should be encoded as frames/images rather than full blown videos consisting of a single frame. The format that the video codec uses for (golden) frames. In the case of fragments the frame will of course have to be extracted dynamically on the client side.
Re: [whatwg] More YouTube response
David Gerard dger...@gmail.com wrote: On 4 July 2010 13:57, bjartur svartma...@gmail.com wrote: I fail to see how BBC would be harmed by the usage of alternative software. Its business model is about content, not software, right? See, you're using logic and sense ... about half the BBC want to just *make their stuff available*, the other half are worried about the thicket of laws and agreements that made sense in the days of analogue tape broadcast on analogue television that, despite not making sense on the Internet, still bind them legally. (Broadcast rights, residuals for actors and writers, etc.) These are serious and real concerns and they can't just ignore them. AFAIK BBC hasn't been harmed by the usage of VHS players made and distributed by 3rd partys nor do I know about any laws that require them to technically and legally restrict consumer ability to play their media with their ware of choice. Limiting who and how their media can be consumed should harm BBC rather than the other way around.
[whatwg] proposal - link relations: rel=prefetch to be exchanged for a boolean attribute
Hi All, I'm sure link relations have already had many debates around how they should work and the exact use case that they cover. I'd like to add another card to the deck :-) When using link relations on an a tag, one would find it useful to have next and previous link relations, this is especially highlighted for documentation, online books—publication, in general. I'd find it useful if I could ask the user agent to prefetch the next page as its more than likely that the user will be lead to this page soon after the current browsing context. Having a linkrel of next is useful for styling. However, as far as my understanding goes, linkrels should not contain multiple values; eg: a rel=prefetch nextNext page/a I put it forward that prefetch should be moved to become a boolean attribute, so that it can be used as follows: a rel=next prefetchNext page/a This would allow content producers to improve the user experience for their users while also maintaining clean, cohesive stylesheets and markup. (most of) The other link relations describe the content behind a link, and how one might style or what a browser may do to change the user experience, this is useful. Prefetch however only aids the browser, not describing the content whatsoever. I've floated this idea to the attendees of my HTML5/CSS3 workshop. The result thus far has been unanimous. Cheers, Ben -
Re: [whatwg] proposal - link relations: rel=prefetch to be exchanged for a boolean attribute
On 7/4/10, Ben Schwarz ben.schw...@gmail.com wrote: Hi All, [...] However, as far as my understanding goes, linkrels should not contain multiple values; eg: a rel=prefetch nextNext page/a Why not? They can in HTML4. http://www.w3.org/TR/html401/struct/links.html#adef-rel rel = link-types [CI] This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. Though many, for some odd reason, seem to want to separate those with comma, not space. Quite often seen: rel=noindex, nofollow, when it should be just: rel=noindex, nofollow. Garrett
[whatwg] Should window.name be [Replaceable]?
Should window.name be [Replaceable]?
There are a number of [Replaceable] [1] properties on the window
object. However, window.name is not marked as such [2]. Not being
marked as replaceable means that if authors use a global variable
named name it will be coerced into a string. For many this causes
confusion. It seems some browsers have opted to make it replaceable.
Test case. You can test your browser at [3].
(function() {
var arr = [];
arr.push( typeof window.name );
window.name = 1;
arr.push( typeof window.name );
name = 1;
// number if [Replaceable], string otherwise
arr.push( typeof window.name );
alert( arr );
})();
Browser Results:
- Safari 5 / WebKit Nightly and Chrome 5
NOT [Replaceable], printing string,string,string
- Firefox 3.6.3 / 3.7a5 and Opera 10.5.3 / 10.6
[Replaceable], printing string,string,number
- I didn't have access to IE to test. I'd appreciate
someone giving it a shot to see how they act.
Has there been discussion on this in the past? I searched and
didn't find any discussion.
- Joe
[1]: http://dev.w3.org/2006/webapi/WebIDL/#Replaceable
[2]:
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
[3]: https://bug-19967-attachments.webkit.org/attachment.cgi?id=60491
Re: [whatwg] Should window.name be [Replaceable]?
On Mon, Jul 5, 2010 at 12:05 AM, Joseph Pecoraro pecor...@apple.com wrote:
- I didn't have access to IE to test. I'd appreciate
someone giving it a shot to see how they act.
On IE8 it is printing string,string,string
And it looks like in Firefox
1) name = with_a_number changes type to matched the assigned value
2) window.name = with_a_number keeps the previous type
See
(function() {
var arr = [];
arr.push( typeof window.name );
name = 1;
// number if [Replaceable], string otherwise
arr.push( typeof window.name );
window.name = 1;
arr.push( typeof window.name );
alert( arr );
})();
give === string,number,number
Re: [whatwg] Should window.name be [Replaceable]?
On Jul 4, 2010, at 9:35 PM, Biju wrote: On Mon, Jul 5, 2010 at 12:05 AM, Joseph Pecoraro pecor...@apple.com wrote: - I didn't have access to IE to test. I'd appreciate someone giving it a shot to see how they act. On IE8 it is printing string,string,string Thanks for checking! So its not Replaceable. And it looks like in Firefox 1) name = with_a_number changes type to matched the assigned value 2) window.name = with_a_number keeps the previous type Yes. So there is no way to access the real window.name once it has been replaced. - Joe
Re: [whatwg] proposal - link relations: rel=prefetch to be exchanged for a boolean attribute
On 7/4/10, timeless timel...@gmail.com wrote: On Mon, Jul 5, 2010 at 6:27 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. Though many, for some odd reason, seem to want to separate those with comma, not space. Quite often seen: rel=noindex, nofollow, when it should be just: rel=noindex, nofollow. i think you suffered from a copy+paste error. Yes, I did it *again* (dammit!) should be just: rel=noindex nofollow. (and thanks BTW) -g
