Re: Steps to creating a browser standard for the moz-icon:// scheme
On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
localStorage Event
Hi, I have a concern about the web storage event spec ( http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. Thanks for your time. -Jared
Re: localStorage Event
On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
Perhaps I am mistaken, but I believe you would still have to go around and add that trigger to all the places the value is changed from. -J On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
[widgets] TWI: Fixes to test cases
Hi everyone, Just a quick heads up that I've checked in some fixes to bugs in the Widget Interface test cases in CVS. I also noticed an issue with the WebIDL test case that I wasn't willing to dive into as I believe it is auto-generated from the documentation (?) - this is a misinterpretation of the WindowWidget abstract interface; the test checks for a WindowWidget interface even though the spec doesn't require one - it just requires the window interface to have a widget object. S smime.p7s Description: S/MIME cryptographic signature
Re: localStorage Event
On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse jarc...@gmail.com wrote: Perhaps I am mistaken, but I believe you would still have to go around and add that trigger to all the places the value is changed from. That is true. Can you give some clear examples of when having local storage events being fired in your frame would be useful? Bonus points if they're something that can't be handled by simply creating an iframe within your doc and using it to monitor events (which is the obvious work-around). J On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
On 1/29/10 12:22 AM, Jared Morse wrote:
Perhaps I am mistaken, but I believe you would still have to go around
and add that trigger to all the places the value is changed from.
Well you could do something like
Storage.prototype.setItemAndNotify =
function (key, data) {
this.setItem(key, data);
var e = document.createEvent(StorageEvent);
e.initStorageEvent(...);
window.dispatchEvent(e);
}
and use that when you set some item.
Or just replace setItem method using prototype.
That way you get the behavior you want, but still allow the
other behavior.
-Olli
-J
On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 1/28/10 11:57 PM, Jared Morse wrote:
Even though it occurs on the same document, doesn't mean loosely
coupled
code can't benefit from it.
Imagine if each time you added a feature to a web app that
depended on
knowing a current value from the storage, you'd have to go
around to all
the places that value is changed and add some code to alert your new
code. If storage events triggered on the same document, all you
would
have to do is set a listener.
If you really need this behavior, you can always dispatch your own event
to the window when you change the data.
-Olli
-J
On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay
olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 1/28/10 9:34 PM, Jared Morse wrote:
Hi, I have a concern about the web storage event spec
(http://dev.w3.org/html5/webstorage/).
The spec states:
When the setItem(), removeItem(), and clear() methods are
called on a
Storage object x that is associated with a local storage
area,
if the
methods did something, then in every HTMLDocument object
whose
Window
object's localStorage attribute's Storage object is
associated
with the
same storage area, other than x, a storage event must be
fired...
My concern lies with the other than x part. Unless
I'm missing
something, these events would be even more useful if
they also
fired in
the HTMLDocument that initially made the storage call.
The page which is changing storage object knows already that the
storage object is being changed. Why would it need explicit
notification (event) about that?
-Olli
Thanks for your time.
-Jared
Re: Steps to creating a browser standard for the moz-icon:// scheme
It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
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 for not making it clearer. What I meant is having a explicit list
of elements
makes sense. script is an interesting one. It might warrant its own
properties like
execution time.
You got a good point about some properties are meaningless in some cases
and I've
been figuring how to make the interfaces better. Some suggested a free-form
key-value
type but I am not sure how much different it makes in terms of conformance
testing. Any
suggestion?
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.
We are actively working with some browser developers to have these
interfaces
implemented but I suspect the implementation complexity varies in different
browsers.
We will get some more idea once we step further. On the other hand, these
timing info
are very valuable in benchmarking page performance. Right now developers are
either
getting only partial data or have to relying on their own plug-in to get to
these info.
Not all the developers are doing the measurements right now probably because
these
interfaces are not available to everyone. :-)
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.
window.timing property keeps timing info of previous navigation as well
so the Tick
interface also provides a way to pass custom POI to the next page. Some
security
measure need to be added later though.
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.
I meant these properties are in the latency critical path of the element
it belongs to...
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 :)
Good to know. :-) Having more data exported in the progress events will
be
good news to those performance
