Re: [WebTiming] HTMLElement timing
On Tue, Jan 26, 2010 at 11:39 PM, Zhiheng Wang zhihe...@google.com wrote: Folks, Thanks to the much feedback from various developers, the WebTiming specs has undergone some major revision. Timing info has now been extended to page elements and a couple more interesting timing data points are added. The draft is up on http://dev.w3.org/2006/webapi/WebTiming/ Feedback and comments are highly appreciated. I take it the idea is that you can get when we for an img element start fetching the image, when image data starts arriving etc. I'd prefer if the spec had a comprehensive list of elements that this is expected to be implemented on. Extending this to elements introduces *significantly* more implementation cost. Is it really worth it? My concern is that this spec already had fairly high cost/benefit ratio since it doesn't add any new functionality to the web platform, it just lets devs do more accurate performance measurements. And it's far from easy to implement since much of the information isn't available outside of the networking code (and many times there only available on a different thread). Also, what is the use case for the Ticks interface? I would really encourage that this spec be reduced to the most important parts first and wait for browsers to catch up before adding nice to have features. If implementations implement progress events on the various elements it would seem like you would get most of the advantages from this spec. / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. Could you elaborate on the use cases for these icons? What sort of web applications would really benefit from emulating the native look and feel of the user's OS, and in particular, what sort of functionality would these icons be used to represent? My concern is that application developers will find it difficult for their app's own custom theme to visually integrate well with system specific icons. It seems much more likely that developers would want to have all icons used to be designed with a common style. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/26 Maciej Stachowiak m...@apple.com On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote: Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. To gain an interoperability benefit, we would presumably need to define the set of icons available, right? Why do you think that? Can you please elaborate? The icons should be the native icons for a particular file type. What possibly need to define is size, what to do if the filetype is unknown, whether we should include Browser specific stock image identifiers to allow the use of Browser themed icons, etc. Chromium currently has an internal scheme (chrome://fileicon/path) that it is using for internal HTML pages and Mozilla's moz-icon scheme is already exposed to web content. I am not sure if other browsers have similar schemes for providing icon resources internally. I am working on the Internet Draft for this and will be seeking feedback soon enough. If anyone has any thoughts on security issues, it would be most welcomed as a thorough security analysis is required for the draft. I would recommend not using // in URLs of this scheme unless they have an authority component. It is better for them not to look like a hierarchical URI in that case. Agreed. Regards, Maciej Thanks. 2010/1/26 Adam Barth w...@adambarth.com On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam -- Pierre. -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: The actual use case that triggered my want to have this was the FTP and file:// URI directory listings pages in Chromium. They currently are quite bland and without icons, as may be true for other browsers. Opera doesn't have icons for files, i think Safari uses 2 stock icons for folders and files. Firefox' equivalent pages use the moz-icon scheme and have the platform specific icons. Makes for very nice directory listing pages. OK, and I suppose the standard directory listing pages that Apache generates could also make use of them. It wasn't clear from your original mail that this was just about file type icons, based on the file extension. You also mentioned: stock-image is of the format: stock/icon-name icon-name is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'. It's not clear what the use cases for these are, but for these, it does seem like we would need to define a common set of icons that are available, unlike the file type icons that can load the system's associated icon. Have you considered using the existing about: URI scheme for this? This scheme is in the process of being standardised, and it is possible for specs to define URIs using it, which are then meant for resolving in application/platform specific ways. See the draft here. http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt The important part is defined in section 5, which has significant amendments described here, which have yet to be integrated into the draft. http://lists.w3.org/Archives/Public/public-html/2009Sep/0755.html http://lists.w3.org/Archives/Public/public-html/2009Sep/0767.html You could write a spec to define an about:icon URI to work like this like, e.g. about:icon?html;32 or about:icon?ext=htmlsize=32 (though, I think being shorter and avoiding '' is better, so authors don't have to bother escaping it in their HTML) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/27 Maciej Stachowiak m...@apple.com
On Jan 27, 2010, at 4:49 AM, Pierre-Antoine LaFayette wrote:
2010/1/26 Maciej Stachowiak m...@apple.com
On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote:
Yes, I wish to expose the platform and possibly Browser theme specific
icons to web content with the Icon URI scheme. The idea is to allow the Icon
URI scheme to be used anywhere an image is specifiable by a data URI in HTML
and JavaScript. This will allow web content to emulate the look and feel of
the native Operating System and of the Browser itself in the case of themed
icons. I believe this will benefit both content creators and consumers.
To gain an interoperability benefit, we would presumably need to define
the set of icons available, right?
Why do you think that? Can you please elaborate? The icons should be the
native icons for a particular file type. What possibly need to define is
size, what to do if the filetype is unknown, whether we should include
Browser specific stock image identifiers to allow the use of Browser
themed icons, etc.
For the stock images, how can you ever reasonably rely on them without
knowing which ones are available? Getting a generic unknown image in those
cases is not likely to be good fallback.
Yes, I was thinking that the stock image seems like something that should
not be standardized for that reason. Mozilla supposedly has things like: *
moz-icon://stock*/tab-new?size=menu. For example.
Side note on security: it has to be impossible to determine the contents of
any image retrieved via such a URL, or even to detect if any two are
different, or it becomes possible to probe the filesystem or probe the
user's set of file type bindings (if it varies per OS), both of which would
be privacy violations.
I've been looking into this. A web application should never be able to
download the contents of an icon URI. The main thing to prevent is the
canvas 2D context using getPixelData or toDataURL to retrieve the data of an
image with an icon URI that has been painted onto the canvas. This one is
known (
http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html
).
Another more subtle exploit was described to me by Chromium's Glen Murphy:
The only other attack I can think of off the top of my head (which
also exists for cross domain images) is super contrived as it exploits
vision and relies on user interaction:
1. Assume that the 'no app' icon has a pixel at 8,8 that is color A
(e.g the middle of a blank page icon).
2. Assume that the app you want to detect has an icon with a color B
pixel at 8,8.
3. Set it up so that there are two links of color A and B, each with
the 8,8 pixel of the icon stretched as a background.
4. This makes only one of the links visible, those links can then
entice the user to click.
div style=-webkit-border-image: url(icon://file.type) 7 7 8 8 repeat
repeat; width:200px; height:20px; border:1px;
a style=color:B; href=# onclick=alert('you do not have X
installed'); return false; /free pony!/a
/div
div style=-webkit-border-image: url(icon://file.type) 7 7 8 8 repeat
repeat; width:200px; height:20px; border:1px;
a style=color:A; href=# onclick=alert('AHAR! You have App XXX
installed! How embarassing for you!'); return false; /free pony!/a
/div
However this is a bit of a stretch. You could just as easily trick people
into telling you what applications they have installed through some sort of
interactive content, or simply by asking.
This implies a constraint that all icons (including unknown and missing
file) have to be the same size, which may not match the native look of all
operating environments. Probing file existence may also be doable via a
timing attack, but I am not sure that is solvable.
I'm not sure why you believe that the icons must be the same size. The web
application should not know anything about the icon displayed to the user
other than the URI it used to display it. If this is the case, then
filesystem probing won't occur. Can you give me an example of how one would
probe file existence of an icon URI? The only thing I can think of is if an
application used an icon URI with an arbitrary file path that whose
existence is probable and simply got the user to confirm that an icon (or a
pixel/color) is shown somehow.
Perhaps icons for specific existing files (rather than a file type) should
be retrieved using a File object rather than a path. If the Web app has a
File object then it already has access to the contents of the file, so there
is no probing risk. You could even give it access to the bitmap of the icon
in such a case (for example by making it usable on the canvas without
tainting).
How would the syntax work for img src=? / tags. Isn't the point that we
don't want the web application to have access to the contents of the file?
How does it obtain the File object? Wouldn't it have to probe for the File
object it wants? I'm not very
Re: Steps to creating a browser standard for the moz-icon:// scheme
Thanks again for the feedback! 2010/1/27 Lachlan Hunt lachlan.h...@lachy.id.au Pierre-Antoine LaFayette wrote: The actual use case that triggered my want to have this was the FTP and file:// URI directory listings pages in Chromium. They currently are quite bland and without icons, as may be true for other browsers. Opera doesn't have icons for files, i think Safari uses 2 stock icons for folders and files. Firefox' equivalent pages use the moz-icon scheme and have the platform specific icons. Makes for very nice directory listing pages. OK, and I suppose the standard directory listing pages that Apache generates could also make use of them. It wasn't clear from your original mail that this was just about file type icons, based on the file extension. You also mentioned: stock-image is of the format: stock/icon-name icon-name is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'. It's not clear what the use cases for these are, but for these, it does seem like we would need to define a common set of icons that are available, unlike the file type icons that can load the system's associated icon. So Mozilla has special stock image identifiers, e.g. *moz-icon://stock*/tab-new?size=menu, that I believe return themed icons. I'm not entirely sure what all the options are. There doesn't seem to be documentation for these, it is likely that it is something mostly intended for internal use. I've been thinking that including something like this would not be reasonable as we probably won't be able to agree on some set of stock icons and sizes or even simply which identifiers should be included. E.g. endless variants of: Do we really need separate icons for 'ok' and 'yes' ? Plus all Browsers have their own UIs and themes and as such have different icon sets. Have you considered using the existing about: URI scheme for this? This scheme is in the process of being standardised, and it is possible for specs to define URIs using it, which are then meant for resolving in application/platform specific ways. The only thing is that about URIs are more for providing users information (hence the name about) and perhaps offering configuration options. Such URIs have commonly been used by web browsers for providing access to built-in functionality, such as application information, preferences, settings, or easter eggs While it would be nice to piggy-back on the about: scheme, it does not seem appropriate. An icon: URI scheme is intuitive and concise. I think the only about: URL that Browsers make web accessible is about:blank (and about:mozilla in FF). You can have about:memory in an anchor tag in Chromium for example. Not that making about:icon web accessible would be that big of a deal but it may violate some design principles, at least on the Chromium side. Adam, could you provide your thoughts on using about:icon? See the draft here. http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt The important part is defined in section 5, which has significant amendments described here, which have yet to be integrated into the draft. http://lists.w3.org/Archives/Public/public-html/2009Sep/0755.html http://lists.w3.org/Archives/Public/public-html/2009Sep/0767.html You could write a spec to define an about:icon URI to work like this like, e.g. about:icon?html;32 or about:icon?ext=htmlsize=32 (though, I think being shorter and avoiding '' is better, so authors don't have to bother escaping it in their HTML) I like the shorter syntax as well. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ -- Pierre.
Re: [IndexedDB] Detailed comments for the current draft
On Tue, Jan 26, 2010 at 12:47 PM, Pablo Castro pablo.cas...@microsoft.comwrote: 2. Values a. 3.1.2: isn't the requirement for structured clones too much? It would mean implementations would have to be able to store and retrieve File objects and such. Would it be more appropriate to say it's just graphs of Javascript primitive objects/values (object, string, number, date, arrays, null)? If LocalStorage is able to store structured clones, then I'm not sure if there's too much of an additional burden on implementations. I think we should either change both to graphs of javascript primitives or leave both as structured clones. As a data point: does anyone currently plan on implementing the structured clone requirement of the WebStorage spec?
Re: [IndexedDB] Detailed comments for the current draft
On Wed, Jan 27, 2010 at 10:58 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Jan 26, 2010 at 12:47 PM, Pablo Castro pablo.cas...@microsoft.com wrote: 2. Values a. 3.1.2: isn't the requirement for structured clones too much? It would mean implementations would have to be able to store and retrieve File objects and such. Would it be more appropriate to say it's just graphs of Javascript primitive objects/values (object, string, number, date, arrays, null)? If LocalStorage is able to store structured clones, then I'm not sure if there's too much of an additional burden on implementations. I think we should either change both to graphs of javascript primitives or leave both as structured clones. As a data point: does anyone currently plan on implementing the structured clone requirement of the WebStorage spec? Yes, we do at mozilla. Storing File objects is definitely something that we get requests for and that we see useful for a number of use cases, such as offline mail, resumable background file upload, etc. / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 27, 2010, at 6:00 AM, Pierre-Antoine LaFayette wrote: I'm not sure why you believe that the icons must be the same size. Because you can get the width and height of an img element without any security checks. Even if the width and height properties of HTMLIamgeElement did not expose this (and they do), examining the layout would expose it. The web application should not know anything about the icon displayed to the user other than the URI it used to display it. If this is the case, then filesystem probing won't occur. Can you give me an example of how one would probe file existence of an icon URI? The only thing I can think of is if an application used an icon URI with an arbitrary file path that whose existence is probable and simply got the user to confirm that an icon (or a pixel/color) is shown somehow. Perhaps icons for specific existing files (rather than a file type) should be retrieved using a File object rather than a path. If the Web app has a File object then it already has access to the contents of the file, so there is no probing risk. You could even give it access to the bitmap of the icon in such a case (for example by making it usable on the canvas without tainting). How would the syntax work for img src=? / tags. Isn't the point that we don't want the web application to have access to the contents of the file? How does it obtain the File object? Wouldn't it have to probe for the File object it wants? I'm not very familiar with the File object so if you could elaborate it would be greatly appreciated. You get a File object through a file being explicitly selected by the user, via input type=file. There is no opportunity for any kind of probing attack. My suggestion is that you could get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. Alternately, the File object could give you an icon: URL that specifically identifies that file's icon. This is safer than letting Web applications get the icon for any file they can guess the path to. For the use of paths in icon URIs, I see it as not really useful for web applications but more for Browsers (FTP and file:// directory listings) and possibly user created local HTML pages. There's no need for interoperability in mechanisms that are only needed for features that are built-in to the browser. And I note that it's clearly not needed for FTP directory listings - you don't actually want such files to map to a real file path. The path thing is also a poor fit for operating systems that do not have a user-visible concept of file paths, such as iPhone OS. It could lead to writing inappropriately platform-dependent code given the path format differences and filesystem layout differences among operating systems. True. That is why I imagine that web applications would be using the icon:extension syntax (and maybe a Browser specific stock image syntax) whereas Browsers and local HTML pages would benefit from the file path syntax. I don't think there is a need to standardize features solely for the benefit of browsers and local HTML pages, particularly if they may be a security risk when used in remote Web pages. Regards, Maciej
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Wed, Jan 27, 2010 at 11:44 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 27, 2010, at 6:00 AM, Pierre-Antoine LaFayette wrote: I'm not sure why you believe that the icons must be the same size. Because you can get the width and height of an img element without any security checks. Even if the width and height properties of HTMLIamgeElement did not expose this (and they do), examining the layout would expose it. The web application should not know anything about the icon displayed to the user other than the URI it used to display it. If this is the case, then filesystem probing won't occur. Can you give me an example of how one would probe file existence of an icon URI? The only thing I can think of is if an application used an icon URI with an arbitrary file path that whose existence is probable and simply got the user to confirm that an icon (or a pixel/color) is shown somehow. Perhaps icons for specific existing files (rather than a file type) should be retrieved using a File object rather than a path. If the Web app has a File object then it already has access to the contents of the file, so there is no probing risk. You could even give it access to the bitmap of the icon in such a case (for example by making it usable on the canvas without tainting). How would the syntax work for img src=? / tags. Isn't the point that we don't want the web application to have access to the contents of the file? How does it obtain the File object? Wouldn't it have to probe for the File object it wants? I'm not very familiar with the File object so if you could elaborate it would be greatly appreciated. You get a File object through a file being explicitly selected by the user, via input type=file. There is no opportunity for any kind of probing attack. My suggestion is that you could get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. Alternately, the File object could give you an icon: URL that specifically identifies that file's icon. This is safer than letting Web applications get the icon for any file they can guess the path to. For the use of paths in icon URIs, I see it as not really useful for web applications but more for Browsers (FTP and file:// directory listings) and possibly user created local HTML pages. There's no need for interoperability in mechanisms that are only needed for features that are built-in to the browser. And I note that it's clearly not needed for FTP directory listings - you don't actually want such files to map to a real file path. The path thing is also a poor fit for operating systems that do not have a user-visible concept of file paths, such as iPhone OS. It could lead to writing inappropriately platform-dependent code given the path format differences and filesystem layout differences among operating systems. True. That is why I imagine that web applications would be using the icon:extension syntax (and maybe a Browser specific stock image syntax) whereas Browsers and local HTML pages would benefit from the file path syntax. I don't think there is a need to standardize features solely for the benefit of browsers and local HTML pages, particularly if they may be a security risk when used in remote Web pages. I agree with Maciej. I have a hard time seeing a use case that doesn't originate in File objects, so being able to get the icon directly there seems like a safer way to go. / Jonas
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A few comments I've been meaning to suggest: * count on KeyRange - Previously I had asked if there would be a way to get a count of the number of objects within a given key range. The addition of the KeyRange interface seems to be a step towards that, but the cursor generated with a KeyRange still only provides a count property that returns the total number of objects that share the current key. There is still no way to determine how many objects are within a range. Was the intent to make count return the number of objects in a KeyRange and the wording is just not up to date? Otherwise could we add such a count property (countForRange maybe, or have a count and countForKey, I think Pablo suggested something like that). * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises and a comment on this: On 1/26/2010 1:47 PM, Pablo Castro wrote: 11. API Names a. transaction is really non-intuitive (particularly given the existence of currentTransaction in the same class). beginTransaction would capture semantics more accurately. b. ObjectStoreSync.delete: delete is a Javascript keyword, can we use remove instead? I'd prefer to keep both of these as is. Since commit and abort are part of the transaction interface, using transaction() to denote the transaction creator seems brief and appropriate. As far as ObjectStoreSync.delete, most JS engines have or should be contextually reserving delete. I certainly prefer delete in preserving the familiarity of REST terminology. Thanks, - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktgtCkACgkQ9VpNnHc4zAwlkgCgti99/iJMi1QqDJYsMgxj9hC3 X0cAnj0J0xzqIQa8abaBQ8qxCMe/7/sU =W6Jx -END PGP SIGNATURE-
XHR
Hi, I'm have a question about the XmlHttpRequest, can I use the same instance for several requests? Currently I know frameworks that maintain a pool of those objects, and after every call, they invoke the abort method [1], that switch the state to UNSENT, and use the same XmlHttpRequest instance for other requests. The problem is that the error flag get true, and the devs tools report the request with error. Can it be done in other ways? [1] http://www.w3.org/TR/XMLHttpRequest/#the-abort-method -- Pedro Henrique Oliveira dos Santos
Re: [WebTiming] HTMLElement timing
Hi, Jonas, Thanks for the comments. pls find comments inline. On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jan 26, 2010 at 11:39 PM, Zhiheng Wang zhihe...@google.com wrote: Folks, Thanks to the much feedback from various developers, the WebTiming specs has undergone some major revision. Timing info has now been extended to page elements and a couple more interesting timing data points are added. The draft is up on http://dev.w3.org/2006/webapi/WebTiming/ Feedback and comments are highly appreciated. I take it the idea is that you can get when we for an img element start fetching the image, when image data starts arriving etc. I'd prefer if the spec had a comprehensive list of elements that this is expected to be implemented on. Right now only embedded content elementshttp://dev.w3.org/html5/spec/Overview.html#embedded-content-1 require these info. An explicit list might be better though, e.g., script is not classified as embedded content. Extending this to elements introduces *significantly* more implementation cost. Is it really worth it? My concern is that this spec already had fairly high cost/benefit ratio since it doesn't add any new functionality to the web platform, it just lets devs do more accurate performance measurements. And it's far from easy to implement since much of the information isn't available outside of the networking code (and many times there only available on a different thread). Certainly the overhead of implementing the specs should be evaluated. It should be done while we are looking into more browser-specific implementations. Right now I want to be as specific as possible in the specs. But much implementation overhead can be avoided if we can tune the specs to accept some slight inaccuracy, say, taking the time of the first callback from the data socket instead of the actual first byte time as responseStart. Also, what is the use case for the Ticks interface? The Ticks interface is a convenient way to store time measurements and retrieve it later on a page. I will have some example there. I would really encourage that this spec be reduced to the most important parts first and wait for browsers to catch up before adding nice to have features. Agree and we do keep that in mind. Most of the the properties specified right now are on the critical path of user perceived latency though. If implementations implement progress events on the various elements it would seem like you would get most of the advantages from this spec. The progress events are great, except that they mostly focus on downloading the content but not much about everything else, say, parseStart. cheers, Zhiheng / Jonas
Re: [WebTiming] HTMLElement timing
On Wed, Jan 27, 2010 at 5:30 PM, Zhiheng Wang zhihe...@google.com wrote:
Hi, Jonas,
Thanks for the comments. pls find comments inline.
On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jan 26, 2010 at 11:39 PM, Zhiheng Wang zhihe...@google.com
wrote:
Folks,
Thanks to the much feedback from various developers, the WebTiming
specs has undergone some
major revision. Timing info has now been extended to page elements and a
couple more interesting timing
data points are added. The draft is up
on http://dev.w3.org/2006/webapi/WebTiming/
Feedback and comments are highly appreciated.
I take it the idea is that you can get when we for an img element
start fetching the image, when image data starts arriving etc. I'd
prefer if the spec had a comprehensive list of elements that this is
expected to be implemented on.
Right now only embedded content elements require these info. An explicit
list
might be better though, e.g., script is not classified as embedded
content.
What do these properties measure on a figure? And why would you care
to measure downloading performance on link rel=icon? And why
wouldn't you care about script? That one seems more performance
critical than any other external resource.
Extending this to elements introduces *significantly* more
implementation cost. Is it really worth it? My concern is that this
spec already had fairly high cost/benefit ratio since it doesn't add
any new functionality to the web platform, it just lets devs do
more accurate performance measurements. And it's far from easy to
implement since much of the information isn't available outside of the
networking code (and many times there only available on a different
thread).
Certainly the overhead of implementing the specs should be evaluated. It
should be
done while we are looking into more browser-specific implementations. Right
now I want
to be as specific as possible in the specs. But much implementation overhead
can be
avoided if we can tune the specs to accept some slight inaccuracy, say,
taking the time
of the first callback from the data socket instead of the actual first
byte time as responseStart.
I'm not sure what you mean by more browser-specific implementations?
Implementation complexity vs. value should be looked at all the time
IMHO.
Also, what is the use case for the Ticks interface?
The Ticks interface is a convenient way to store time measurements and
retrieve it later on a page.
I will have some example there.
Why not just do:
myTimings = {};
myTimings.fooStart = new Date();
etc? Javascript has perfectly good ways to store values already.
I would really encourage that this spec be reduced to the most
important parts first and wait for browsers to catch up before adding
nice to have features.
Agree and we do keep that in mind. Most of the the properties specified
right now are
on the critical path of user perceived latency though.
That surprises me. See my first answer above.
If implementations implement progress events on the various elements
it would seem like you would get most of the advantages from this
spec.
The progress events are great, except that they mostly focus on
downloading the content but
not much about everything else, say, parseStart.
Specs can be changed, nothing is set in stone :)
/ Jonas
Re: [WebTiming] HTMLElement timing
On Wed, Jan 27, 2010 at 5:57 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jan 27, 2010 at 5:30 PM, Zhiheng Wang zhihe...@google.com wrote: Hi, Jonas, Thanks for the comments. pls find comments inline. On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jan 26, 2010 at 11:39 PM, Zhiheng Wang zhihe...@google.com wrote: Folks, Thanks to the much feedback from various developers, the WebTiming specs has undergone some major revision. Timing info has now been extended to page elements and a couple more interesting timing data points are added. The draft is up on http://dev.w3.org/2006/webapi/WebTiming/ Feedback and comments are highly appreciated. I take it the idea is that you can get when we for an img element start fetching the image, when image data starts arriving etc. I'd prefer if the spec had a comprehensive list of elements that this is expected to be implemented on. Right now only embedded content elements require these info. An explicit list might be better though, e.g., script is not classified as embedded content. What do these properties measure on a figure? And why would you care to measure downloading performance on link rel=icon? And why wouldn't you care about script? That one seems more performance critical than any other external resource. Sorry, my bad, it doesn't look like link is in this list. This still raises the question why this is specified for figure, embed and canvas, but not for script and link rel=stylesheet. I also wonder what these properties measure on svg? / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Thu, Jan 28, 2010 at 8:58 AM, Jonas Sicking jo...@sicking.cc wrote: I agree with Maciej. I have a hard time seeing a use case that doesn't originate in File objects, so being able to get the icon directly there seems like a safer way to go. It can still expose which application the user has handling that file type, if the icon data is somehow exposed via canvas.drawImage or whatever. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Wed, Jan 27, 2010 at 6:26 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jan 28, 2010 at 8:58 AM, Jonas Sicking jo...@sicking.cc wrote: I agree with Maciej. I have a hard time seeing a use case that doesn't originate in File objects, so being able to get the icon directly there seems like a safer way to go. It can still expose which application the user has handling that file type, if the icon data is somehow exposed via canvas.drawImage or whatever. Indeed. I think we should make these urls never be considered same-origin as any other origin. Thus a canvas would always get its taint bit set if an icon is drawn. We should also return some default-sized icon for unknown types, to make it somewhat harder to detect when no application is installed to handle a particular file type. That, in combination with the fact that pages only get access to icons for files where the user has exposed the full file contents to the page (through drag'n'drop or input type=file), makes me much less worried about privacy leaks. There's still some risk of privacy leak though, so i'm all ears if others have further ideas or in general don't think this is safe enough. / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
On 1/27/10 9:32 PM, Jonas Sicking wrote: Indeed. I think we should make these urls never be considered same-origin as any other origin. Thus a canvas would always get its taint bit set if an icon is drawn. Note that this is effectively the case in Gecko (since -moz-icon URIs have no host, so never test equal to anything else in terms of origin). -Boris
