[whatwg] HTMLMediaElement buffered/bufferedBytes
Hi, I'm currently implementing more of audio and video (in Opera) and will probably have quite a lot of questions/comments during the coming months. If this is not the best place for such discussion, please point out where I need to be. Today's issue: The name of the buffered/bufferedBytes attributes imply that these ranges are buffered on disk or in memory, so that they will not have to be re-downloaded. However, the description reads the ranges of the media resource, if any, that the user agent has downloaded, at the time the attribute is evaluated. This is not the same things, as we will not be able to buffer large files on memory-limited devices. Instead, we might only buffer 1 MB of data around the current playback point, or some other scheme. I would suggest that buffered/bufferedBytes be taken to mean exactly what they sound like by changing the description to something like: (differences marked *like this*) The buffered attribute must return a static normalized TimeRanges object that represents the ranges of the media resource, if any, that the user agent has *buffered*, at the time the attribute is evaluated. Note: Typically this will be a single range anchored at the zero point, but if, e.g. the user agent uses HTTP range requests in response to seeking, then there could be multiple ranges. *There is no guarantee that all buffered ranges will remain buffered, due to storage/memory constraints or other reasons.* The intention is that only ranges which are actually internally buffered should be exposed in the buffered/bufferedBytes ranges, whereas the current phrasing implies that all ranges which have at some point been downloaded/buffered should be included. Admittedly, this makes the attributes useless for determining how much of the resource has been downloaded, but if this is needed I might suggest the attributes downloaded/downloadedBytes instead. The usefulness of the buffered attribute (in my current interpretation) is not obvious to me at all, I would appreciate some use cases if possible. -- Philip Jägenstedt Opera Software
Re: [whatwg] HTMLMediaElement buffered/bufferedBytes
I think this all makes sense. +1 from me. Cheers, Silvia. On Tue, Jun 10, 2008 at 8:24 PM, Philip Jägenstedt [EMAIL PROTECTED] wrote: Hi, I'm currently implementing more of audio and video (in Opera) and will probably have quite a lot of questions/comments during the coming months. If this is not the best place for such discussion, please point out where I need to be. Today's issue: The name of the buffered/bufferedBytes attributes imply that these ranges are buffered on disk or in memory, so that they will not have to be re-downloaded. However, the description reads the ranges of the media resource, if any, that the user agent has downloaded, at the time the attribute is evaluated. This is not the same things, as we will not be able to buffer large files on memory-limited devices. Instead, we might only buffer 1 MB of data around the current playback point, or some other scheme. I would suggest that buffered/bufferedBytes be taken to mean exactly what they sound like by changing the description to something like: (differences marked *like this*) The buffered attribute must return a static normalized TimeRanges object that represents the ranges of the media resource, if any, that the user agent has *buffered*, at the time the attribute is evaluated. Note: Typically this will be a single range anchored at the zero point, but if, e.g. the user agent uses HTTP range requests in response to seeking, then there could be multiple ranges. *There is no guarantee that all buffered ranges will remain buffered, due to storage/memory constraints or other reasons.* The intention is that only ranges which are actually internally buffered should be exposed in the buffered/bufferedBytes ranges, whereas the current phrasing implies that all ranges which have at some point been downloaded/buffered should be included. Admittedly, this makes the attributes useless for determining how much of the resource has been downloaded, but if this is needed I might suggest the attributes downloaded/downloadedBytes instead. The usefulness of the buffered attribute (in my current interpretation) is not obvious to me at all, I would appreciate some use cases if possible. -- Philip Jägenstedt Opera Software
[whatwg] Proposal: target=_tab
In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Use case for opening a new window with specified size: help popup. Use case for opening a new window without specified size: print page. Use case for opening a new tab: links in GReader for later reading. Demand for this feature: http://www.google.com/search?q=_tab -- Simon Pieters Opera Software
Re: [whatwg] Proposal: target=_tab
In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its target-new property) supposed to fit in, /theoretically/ allowing us to drop @target altogether? [1] http://www.w3.org/TR/css3-hyperlinks/ -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Proposal: target=_tab
IMO, both _blank and _tab should always open in the same window, under a new tab. Else that would be bad usability. Browsers currently already support this. So, I think it's therefore redundant. Na , Simon Pieters [EMAIL PROTECTED] escreveu: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Use case for opening a new window with specified size: help popup. Use case for opening a new window without specified size: print page. Use case for opening a new tab: links in GReader for later reading. Demand for this feature: http://www.google.com/search?q=_tab
Re: [whatwg] Proposal: target=_tab
Simon Pieters wrote: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. I don't believe it should be up to the document author to distinguish between a page opened up in a new window or new tab, since that is entirely a browser interface issue. Since several browsers already treat _blank in that way anyway, introducing a new keyword doesn't seem particularly useful. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Proposal: target=_tab
Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its target-new property) supposed to fit in, /theoretically/ allowing us to drop @target altogether? That looks great (didn't know of that!), that would sort out the HTML/CSS part of game (although implementing target=_tab would be probably easier for browser vendors than implementing CSS3). We would still need something equivalent in JavaScript though -- but I'm not sure how that is related to WHATWG. Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Change request: rules for pixel ratio
On 10-Jun-08, at 9:31 AM, Philip Jägenstedt wrote: The default value, if the attribute is omitted or cannot be parsed, is the media resource's self-described pixel ratio, or 1.0 for media resources that do not self-describe their pixel ratio. This is actually how I read the original, but your wording resolves the ambiguity. Sounds like an improvement to me. Does this mean the implementation must retrieve the self-described pixel aspect ratio from the stream and supply it as part of the DOM? -r
Re: [whatwg] Proposal: target=_tab
From my brief testing, _tab opens a new window so it should be backwards compatible. - Original Message From: João Eiras [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Tuesday, 10 June, 2008 6:03:51 PM Subject: Re: [whatwg] Proposal: target=_tab This approach however has two problems: - user agent that don't support _tab which would have to interpret as _blank, or _self, so this case need to be predicted in the spec, if any - that value is not backwards compatible. I'd expect for an user agent that does not support tabs to open a new window, but a unknwon target opens in the same window, so you'll probably will have to make up something different. Na , Borek Bernard [EMAIL PROTECTED] escreveu: IMO, both _blank and _tab should always open in the same window, under a new tab. ... Browsers currently already support this. So, I think it's therefore redundant. As you stated, that is your user preference and my preference can be different. You are lucky that your preference fits in current browsers' feature set, I have argued in the forum post linked before [1] that I don't think it's reasonable to expect the required level of browser customizeability any time soon. [1] http://forums.whatwg.org/viewtopic.php?t=186 --- Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
From my brief testing, _tab opens a new window so it should be backwards compatible. It's deceptively close but not quite backwards compatible. _tab will cause the link to open in the frame called _tab and if it doesn't exist it creates it, as a new window. So the first link works perfectly and opens a new window but the second link you click will replace the first one since there is now a frame called _tab. Regards, Adrian Sutton. __ Adrian Sutton, CTO US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Opportunistic caching
On Tue, 10 Jun 2008, Honza Bambas wrote: Hi, I would like to ask for clarification of opportunistic caching spec in Offline Web Applications, the article 4.9.1.9. Adding a resource whom URI matches an opportunistic name space seems to be done only for top level documents according to the article 4.9.1.9, cite: If the resource was not fetched from... where the resource refers, as I understand, the top-level document being navigated. I didn't find any other place where a resource whom URI matched an opportunistic entry would be added to a cache as opportunistically cached. I would naturally expect it were part of the networking model, article 4.7.5.1 - Changes to the networking model, but I couldn't find it, at least not explicitly, expressed. Maybe I am missing something in the networking model spec: in article 4.7.5.1.4 when URI matches a name space it have to be fetched normally. Should implementers replace normal HTTP cache used for writing by offline cache to store the resource in it? Instead of normal HTTP cache? Resources can only be cached as opportunistically cached entries if a browsing context is navigated, but it doesn't have to be a top-level browsing context. The caching happens in the Otherwise clause of step 9 of the 4.9.1 Navigating across documents navigation algorithm. If by top-level you don't mean a window/tab, but mean any iframe or frame content document, as opposed to an image, a stylesheet, or some such, then you are correct. The use case was really just replacing pages, e.g. Flickr pages, when the whole site isn't cached. Do you think this should be changed to opportunistically cache anything accessed? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: target=_tab
On Tue, 10 Jun 2008, Simon Pieters wrote: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Use case for opening a new window with specified size: help popup. Use case for opening a new window without specified size: print page. Use case for opening a new tab: links in GReader for later reading. Demand for this feature: http://www.google.com/search?q=_tab In general, it's best to let users decide where the link should open. In cases where the author really wants to open a new top-level browsing context, _blank already provides that option. Help popups are probably better done using inline floating iframes inside aside. Browsers having tabs, windows, or any number of other UI constructs should not be an issue that Web authors need to deal with. Thus, I don't think _tab makes much sense. [snip a number of arguments much like the above] -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
