Ian, the heart of this one seems to ve media delivery progress. as Dennis points out, the content must be transferred and than rendered. it is the rendering progress that I think we are trying to capture here and we must also be certain to capture other progresses as well such as progress of page transfer and progress through a page as it is being scrolled. Thanks! Ian Jacobs wrote: > > Denis, > > Basically, I don't know what "to load" means. The HTML spec > says: "The onload event occurs when the user agent finishes > loading a window or all frames within a FRAMESET." That doesn't > help me. > > I am much more comfortable with the terms > "transfer" (one "T" in HTTP) or"render" (HTML + CSS), both of > which require time. I think you are correct in that the > intention of the checkpoint was more about transfer status > than rendering status. Furthermore, checkpoint 9.5 covers > the case of position within rendered content. > > I therefore propose changing "loading" to "transferring" > > <NEW> > 9.4 When transferring content (e.g., document, image, audio, video, > etc.) indicate what proportion of the content has been > transferred > and whether the transfer has stalled. [Priority 3] > </NEW> > > Denis wrote: > > I'm not sure this works for multimedia content. When a video, for example, > > is downloaded, isn't loaded into a buffer somewhere, then rendered a frame > > at a time? > > > As I understand it, the goal is to find out how much longer I'll have to > > wait before I can access the information. > > In streaming media, this isn't an > > issue, because the data-stream might be essentially endless. But for sound > > files, videos, or even animations, the rendering might not begin until the > > entire file is available, and the new wording really doesn't seem to capture > > that. Or, I might not be using "render" the same way you are. > > > > Denis > > > > -----Original Message----- > > From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf > > Of Ian Jacobs > > Sent: Friday, May 05, 2000 7:40 PM > > To: w3c-wai-ua@w3.org > > Subject: Proposed clarification of checkpoint 9.4 > > > > Hello, > > > > Checkpoint 9.4 of the Proposed Recommendation [1] reads: > > > > 9.4 When loading content (e.g., document, image, audio, > > video, etc.) indicate what proportion of the content has > > loaded and whether loading has stalled. [Priority 3] > > > > We do not have a definition of "load". I believe that > > this means "to put in the viewport", i.e., to render, rather > > than retrieve (although delays in loading may be due > > to delays in retrieval initially). I therefore propose > > the following restatement of the requirement: > > > > <NEW> > > 9.4 When rendering content (e.g., document, image, audio, > > video, etc.), indicate what proportion of the content has > > been rendered and whether rendering has stalled. [Priority 3] > > </NEW> > > > > We do have a definition of "rendered content". > > > > Note: > > There is still a slight ambiguity, but I propose to not worry > > about it. The proportion (e.g., percentage) should probably > > represent the proportion of currently rendered content to the > > total rendered content. However, user agents that render > > incrementally may not know how much total rendered content > > there will be. An approximation based on the byte-size of > > the document source would be adequate. Document entity > > length may be known in advance (e.g., through the > > "Content-Length entity-header field in HTTP/1.1 [2], > > section 14.13). If I've misquoted the HTTP spec, please let > > me know. > > > > - Ian > > > > P.S. I am proposing this change in an effort to harmonize our > > use of "content" in the document. > > > > [1] http://www.w3.org/TR/2000/PR-UAAG10-20000310 > > [2] http://www.ietf.org/rfc/rfc2616.txt > > -- > > Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs > > Tel: +1 831 457-2842 > > Cell: +1 917 450-8783 > > -- > Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs > Tel: +1 831 457-2842 > Cell: +1 917 450-8783 -- Hands-On Technolog(eye)s ftp://ftp.clark.net/pub/poehlman http://poehlman.clark.net mailto:poehlman@clark.net voice 301-949-7599 end sig.Received on Saturday, 6 May 2000 11:44:16 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:03 GMT