Re: [whatwg] Microdata feedback
On Wed, 14 Oct 2009 13:53:46 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Aug 2009, Philip Jägenstedt wrote: Shouldn't namedItem [6] be namedItems? Code like .namedItem().item(0) would be quite confusing. [6] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dom-htmlpropertycollection-nameditem I don't understand what this is referring to. I was incorrectly under the impressions that .namedItem on other collections always returned a single element and arguing that since HTMLPropertyCollection.namedItem always returns a PropertyNodeList namedItems in plural would make more sense. Now I see that some other namedItem methods aren't as simple as I'd thought, so I'm not sure what to make of it. Is there a reason why HTMLPropertyCollection.namedItem unlike some other collections' .namedItem don't return an element if there is only 1 element in the collection at the time the method is called? Perhaps this is legacy quirks that we don't want to replicate? On Tue, 25 Aug 2009, Philip Jägenstedt wrote: There's something like an inverse relationship between simplicity of the syntax and complexity of the resulting markup, the best balance point isn't clear (to me at least). Perhaps option 3 is better, never allowing item+itemprop on the same element. That would preclude being able to make trees. Given that flat items like vcard/vevent are likely to be the most common use case I think we should optimize for that. Child items can be created by using a predefined item property: itemprop=com.example.childtype item. The value of that property would then be the first item in tree-order (or all items in the subtree, not sure). This way, items would have better copy-paste resilience as the whole item element could be made into a top-level item simply by moving it, without meddling with the itemprop. That sounds kinda confusing... More confusing than item+itemprop on the same element? In many cases the property value is the contained text, having it be the contained item node(s) doesn't seem much stranger. Based on the studies Google did, I'm not convinced that people will find the nesting that complicated. IMHO the proposal above is more confusing, too. I'm not sure this is solving a problem that needs solving. If the parent-item (com.example.blog) doesn't know what the child-items are, it would simply use itemprop=item. I don't understand this at all. This was an attempt to have anonymous sub-items. Re-thinking this, perhaps a better solution would be to have each item behave in much the same way that the document itself does. That is, simply add items in the subtree without using itemprop and access them with .getItems(itemType) on the outer item. How would you do things like agent in the vEvent vocabulary? Comparing the current model with a DOM tree, it seems odd in that a property could be an item. It would be like an element attribute being another element: outer foo=inner//. That kind of thing could just as well be outerfooinner//foo/outer, outerinner type=foo//outer or even outerinner//outer if the relationship between the elements is clear just from the fact that they have a parent-child relationship (usually the case). Microdata's datamodel is more similar to JSON's than XML's. It's only in the case where both itemprop and item have a type that an extra level of nesting will be needed and I expect that to be the exception. Changing the model to something more DOM-tree-like is probably going to be easier to understand for many web developers. I dunno. People didn't seem to have much trouble getting it once we used itemscope= rather than just item=. People understand the JSON datamodel pretty well, why would this be different? After http://blog.whatwg.org/usability-testing-html5, the recent syntax changes, the improved DOM API and the passage of time I'm not very worried about the things I was worrying about above. If there's any specific point that seems valid after another review I'll send separate feedback on it. Thanks for all the other fixes! -- Philip Jägenstedt Opera Software
Re: [whatwg] framesets
Wow, what a tour de force; 78 messages and no progress. Peter, I believe the only reason the discussion has carried so far is because you are, actually, on to something. You just don't seem very aware that people are actually trying to pin down and solve the something and keep banging on about framesets being the cure-all, whilst ignoring other points. Here's (yet another) summary: 1) Framesets have been deprecated for quite a long time. The reasons for the deprecation have been repeated ad nauseam, and very solid. 2) There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panels (this is, I believe, the something you're getting at). 3) There are HTML5-conformant solutions available right now that allow you to replicate the above scenario with a little more work. The iframes solution with a bit of JS [1] [2] for handling the resizing is probably the easiest to implement, although an analogous solution with AJAX is probably the best available (which allows for deep-linking when this is desirable and doesn't automatically break bookmarking). You can also (if you wish) break bookmarking/the back button with these solutions, especially the AJAX one. There is also the CSS position: fixed solution that will be adequate for a large number of scenarios, or can complement the other two. 4) As repeated many times, you don't have to use HTML5. Keep using HTML 4 Frameset [3] if you insist on using the frameset solution and care about validation. The documents within each frame can be HTML5. Or use HTML5 with framesets -- it won't validate but is guaranteed (by the spec) to work. Do expect to run into the usability problems inherent to frames, though. 5) There is a known need for CSS to handle the above panel resizing use-case. That is a first-class CSS problem; don't expect the HTML spec to address that, especially not with a mechanism (framesets) that has many drawbacks and is deprecated for good reasons. For immediate solutions, see 3) and 4) above. 6) For clarity sake, I'll repeat the point made several times:the bookmarking/navigation/security issue is *not* solved by framesets, and the slight hack to make this work (javascript's replace) as you suggest is neither exclusive to framesets nor (in the case of security) acceptable. As an aside, there is a reason why AJAX has become so popular over the past few years: it solves the specific UI-reset issue that is inherent in full-page refreshes. Maybe there is room for a better, standard-based approach to solving this issue, but framesets ain't it. [1] http://methvin.com/splitter/4psplitter.html [2] http://developer.yahoo.com/yui/examples/layout/page_layout.html [3] http://www.w3.org/TR/html4/sgml/framesetdtd.html Nelson Menezes http://fittopage.org 2009/10/14 Peter Brawley p...@artfulsoftware.com Rimantas, Maybe there are not many sites because nobody wants this type of sites? You think nobody wants Javadoc? Javadoc has been shipping with an read-only version of this use case for years. The full use case is treeview database maintenance. Tree logic has been slow to mature in SQL, is non-trivial in HTML as we see, and is hard to generate from PHP/Ruby/whatever. I hate this type of documentation sites personally. Fine, you've no need for website maintenance of data-driven trees. That's not a rationale for excluding framesets from HTML5. And to me this use case looks built around the chosen implementation, Wrong. Frameset was chosen because it provides the most efficient available implementaiton. while I prefers solutions built around solving the real need. Which this is. So you want HTML5 spec tailored for this particular case of yours? Can I have dancinghampsters tag, please? May I have rational responses please? This is not a request for a new feature. I want HTML5 to continue support for useful HTML. Nobody forbids you from using previous versions of HTML. Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. PB - Rimantas Liubertas wrote: So it does not answer the question: if framesets are as you claim not needed for the full spec, there should be lots of non-frameset sites which meet this spec as efficiently as ours does. Maybe there are not many sites because nobody wants this type of sites? I hate this type of documentation sites personally. And to me this use case looks built around the chosen implementation, while I prefers solutions built around solving the real need. If that blocks a use case, by all means don't use a frameset for it. For this use, the above poses no problem at all. And if CSS were actually as efficient for this spec as framesets, surely some developers would have taken
Re: [whatwg] framesets
pine.lnx.4.62.0910130924420.25...@hixie.dreamhostps.com 4ad4a1eb.8080...@artfulsoftware.com pine.lnx.4.62.0910132224110.6...@hixie.dreamhostps.com 4ad5438d.3090...@artfulsoftware.com 98038259-77f7-42fd-8a4a-097bb3e9e...@dartmouth.edu 4ad57761.4060...@artfulsoftware.com 5ccfb3340910140023s65dbb96bq988b96b55707a...@mail.gmail.com 4ad5f4a5.2040...@artfulsoftware.com a440ea080910150049t42482beav46a76a597ba29...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Nelson wrote: There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panel As an aside, there is a reason why AJAX has become so popular over the past few years: it solves the specific UI-reset issue that is inherent in full-page refreshes. Maybe there is room for a better, standard-based approach to solving this issue, but framesets ain't it. I totally agree. I think the described case is the main flow in web applications. I think most web applications have exactly this panel based layout, where navigation loads only a some of the panels. I think they all use AJAX. Iframes are very unpopular, and as you say AJAX is the best current solution. I think there should be a standard based solution because: 1.Even when using libraries like prototype, AJAX does take some coding. Why should I use so much code for such a simple, main flow use case? 2.By looking at browsers code I see there is a lot of clever stuff going on when loading/unloading a document. In the AJAX based solution this happens only once in the application life cycle. It seems to me that dedicating a special syntax to navigation would help browsers to test the application main flow. Tali From: flying.mushr...@gmail.com Date: Thu, 15 Oct 2009 09:49:58 +0200 To: p...@artfulsoftware.com CC: wha...@whatwg.org Subject: Re: [whatwg] framesets Wow, what a tour de force; 78 messages and no progress. Peter, I believe the only reason the discussion has carried so far is because you are, actually, on to something. You just don't seem very aware that people are actually trying to pin down and solve the something and keep banging on about framesets being the cure-all, whilst ignoring other points. Here's (yet another) summary: 1) Framesets have been deprecated for quite a long time. The reasons for the deprecation have been repeated ad nauseam, and very solid. 2) There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panels (this is, I believe, the something you're getting at). 3) There are HTML5-conformant solutions available right now that allow you to replicate the above scenario with a little more work. The iframes solution with a bit of JS [1] [2] for handling the resizing is probably the easiest to implement, although an analogous solution with AJAX is probably the best available (which allows for deep-linking when this is desirable and doesn't automatically break bookmarking). You can also (if you wish) break bookmarking/the back button with these solutions, especially the AJAX one. There is also the CSS position: fixed solution that will be adequate for a large number of scenarios, or can complement the other two. 4) As repeated many times, you don't have to use HTML5. Keep using HTML 4 Frameset [3] if you insist on using the frameset solution and care about validation. The documents within each frame can be HTML5. Or use HTML5 with framesets -- it won't validate but is guaranteed (by the spec) to work. Do expect to run into the usability problems inherent to frames, though. 5) There is a known need for CSS to handle the above panel resizing use-case. That is a first-class CSS problem; don't expect the HTML spec to address that, especially not with a mechanism (framesets) that has many drawbacks and is deprecated for good reasons. For immediate solutions, see 3) and 4) above. 6) For clarity sake, I'll repeat the point made several times:the bookmarking/navigation/security issue is *not* solved by framesets, and the slight hack to make this work (javascript's replace) as you suggest is neither exclusive to framesets nor (in the case of security) acceptable. As an aside, there is a reason why AJAX has become so popular over the past few years: it solves the specific UI-reset issue that is inherent in full-page refreshes. Maybe there is room for a better, standard-based approach to
Re: [whatwg] Workers and addEventListener
On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson i...@hixie.ch wrote: There's no start() to call, since there's no explicit pointer to the MessagePort in dedicated workers. The example in the worker spec refers to shared workers, which *do* have an explicit port, and do not automatically start the port. Search for addEventListener in this document: http://www.whatwg.org/specs/web-workers/current-work/#shared-workers And you'll see what I mean. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers and addEventListener
To be absolutely clear (since there's some confusion about whether we are
talking about explicit MessagePorts, or about implicit ports for dedicated
workers).
Are you saying that this:
var channel = new MessageChannel();
channel.port1.postMessage(hi mom);
channel.port2.addEventListener(message, function(event)
{alert(event.data); }, false);
Should result in an alert dialog being fired? Because that does not match my
reading of the spec at all - the spec explicitly states that a port's
message queue is only enabled via start() or via setting the onmessage IDL
attribute.
I would not be opposed to changing the spec to include enabling a port's
message queue when addEventListener(message) is invoked.
-atw
On Wed, Oct 14, 2009 at 3:32 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 29 Sep 2009, Zoltan Herczeg wrote:
In WebKit implementation of MessagePort the addEventListener(message,
...) does not enable the transmitting of messages. All messages are
actually discarded until a dummy function is assigned to onmessage.
That is a bug. The port message queue is explicitly enabled during the
creation of the dedicated worker (step 12).
And in the normative text, it is not mentioned that addEventListener
should also enable message transmitting.
The normative text just says to fire an event; the DOM Events spec makes
it clear that events can be handled using addEventListener()-added
handlers.
Anyway, my qestion is:
- should addEventListener enable message transmitting?
Yes.
- Should it do it in all cases, or only when message is passed as the
first argument
It should only receive 'message' events if you say 'message' as the first
argument.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers and addEventListener
On Thu, 15 Oct 2009 19:54:23 +0200, Drew Wilson atwil...@google.com wrote: I would not be opposed to changing the spec to include enabling a port's message queue when addEventListener(message) is invoked. FWIW, I would be opposed to any change to addEventListener() that makes it do something more than just registering an event listener for the given event. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Storage events
I'd like to propose we remove the source attribute from storage events. ( http://dev.w3.org/html5/webstorage/#the-storage-event) In Chrome, we cannot provide access to a window object unless it's in the same process. Since there's no way to guarantee that two windows in the same origin are in the same process, Chrome would need to always set it to null in order to avoid confusing developers (since what process a page is in is really an implementation detail). But, as far as I can tell, Safari is the only browser that currently provides this. I suspect that as other multi-process implementations are developed, they'll run into the same issue. And, even if they can technically provide synchronous access to another processes Window object, there are _very_ strong arguments against it. So, can we please remove the source attribute from storage events? One other question: is the URL attribute supposed to be the same as documentURI or location.href? I ask because WebKit currently uses the documentURI but if this were the correct behavior, I would have expected the spec to make that more clear.
[whatwg] window.setInterval if visible.
I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. Here's the issue that seems like it needs to be solved. Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is using setInterval. That's great but it has the problem that even when the window is minimized or the page is not the front tab, JavaScript has no way to know to stop animating. So, for a CPU heavy animation using canvas 2d or canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does not copy the bits from the canvas to the window but JavaScript is still drawing hundreds of thousands of pixels to the canvas's internal image buffer through canvas commands. To see an example run this sample in any browser http://mrdoob.com/projects/chromeexperiments/depth_of_field/ Minimize the window or switch to another tab and notice that it's still taking up a bunch of CPU time. Conversely, look at this flash page. http://www.alissadean.com/ While it might look simple there is actually a lot of CPU based pixel work required to composite the buttons with alpha over the scrolling clouds with alpha over the background. Minimize that window or switch to another tab and unlike HTML5 + JavaScript, flash has no problem knowning that it no longer needs to render. There are probably other possible solutions to this problem but it seems like the easiest would be either *) adding an option to window.setInterval or only callback if the window is visible *) adding window.setIntervalIfVisible (same as the previous option really) A possibly better solution would be *) element.setIntervalIfVisible Which would only call the callback if that particular element is visible. It seems like this will be come an issue as more and more HMTL5 pages start using canvas to do stuff they would have been doing in flash like ads or games. Without a solution those ads and games will continue to eat CPU even when not visible which will make the user experience very poor. Am I making an sense? -gregg
Re: [whatwg] Storage events
On Oct 15, 2009, at 11:37 AM, Jeremy Orlow wrote: I'd like to propose we remove the source attribute from storage events. (http://dev.w3.org/html5/webstorage/#the-storage-event) In Chrome, we cannot provide access to a window object unless it's in the same process. Since there's no way to guarantee that two windows in the same origin are in the same process, Chrome would need to always set it to null in order to avoid confusing developers (since what process a page is in is really an implementation detail). I would guess the main use case for this is to distinguish changes from *this* window (the one receiving the event) and changes from other windows. Perhaps a boolean flag to that effect could replace source. - Maciej But, as far as I can tell, Safari is the only browser that currently provides this. I suspect that as other multi-process implementations are developed, they'll run into the same issue. And, even if they can technically provide synchronous access to another processes Window object, there are _very_ strong arguments against it. So, can we please remove the source attribute from storage events? One other question: is the URL attribute supposed to be the same as documentURI or location.href? I ask because WebKit currently uses the documentURI but if this were the correct behavior, I would have expected the spec to make that more clear.
Re: [whatwg] window.setInterval if visible.
On 10/15/09 3:35 PM, Gregg Tavares wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You might be interested in http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/527d0cedb9b0df7f/57625c94cdf493bf for some more discussion about approaches to this problem. In particular, that proposal tries to address overeager animations in visible windows as well. Note, by the way, that testing whether a window is visible is not cheap; testing whether an element is visible is even less cheap -Boris
Re: [whatwg] window.setInterval if visible.
On Thu, 15 Oct 2009 21:35:03 +0200, Gregg Tavares g...@google.com wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You're trying to solve a real problem with a very specific API. You might use setInterval, but someone else might use a worker or setTimeout. The best way would be an attribute on the window, like window.isVisible returning either true of false which would return true if the document is partially or totally visible. This way, all other possible use cases to prevent animations or other complex and heavy dom/layout operations could be postponed just by checking that value. I personally think it's a good idea to have that info available.
Re: [whatwg] window.setInterval if visible.
On Thu, Oct 15, 2009 at 12:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/15/09 3:35 PM, Gregg Tavares wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You might be interested in http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/527d0cedb9b0df7f/57625c94cdf493bffor some more discussion about approaches to this problem. In particular, that proposal tries to address overeager animations in visible windows as well. Note, by the way, that testing whether a window is visible is not cheap; testing whether an element is visible is even less cheap I'd imagine that UAs could use an overly conservative metric of when things are visible to make things cheaper if/when this is a concern. All that really matters is that the UA never say it isn't visible when any part of the window is visible. I agree that some mechanism to know when things aren't visible would be very useful.
Re: [whatwg] Storage events
On Thu, 15 Oct 2009 20:37:48 +0200, Jeremy Orlow jor...@chromium.org wrote: I'd like to propose we remove the source attribute from storage events. ( http://dev.w3.org/html5/webstorage/#the-storage-event) In Chrome, we cannot provide access to a window object unless it's in the same process. Since there's no way to guarantee that two windows in the same origin are in the same process, Chrome would need to always set it to null in order to avoid confusing developers (since what process a page is in is really an implementation detail). The specification tells source is a WindowProxy, so if the underlying window is deleted, or inaccessible, accessing any member of source could just throw an INVALID_STATE_ERR. The problem is there also if a storage event is queued and the originating window is deleted meanwhile, or the document with the listener keeps a reference to the originating window for a long time, and that window is closed, unless the user agent keeps the originating window live while it's WindowPRoxy is not garbage collected, which is not desirable. So, I support Jeremy's suggestion. source should probably be removed from the spec. Which are its use cases anyway ?
Re: [whatwg] window.setInterval if visible.
Gregg Tavares schrieb: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. Here's the issue that seems like it needs to be solved. Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is using setInterval. That's great but it has the problem that even when the window is minimized or the page is not the front tab, JavaScript has no way to know to stop animating. So, for a CPU heavy animation using canvas 2d or canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does not copy the bits from the canvas to the window but JavaScript is still drawing hundreds of thousands of pixels to the canvas's internal image buffer through canvas commands. [...] There are probably other possible solutions to this problem but it seems like the easiest would be either *) adding an option to window.setInterval or only callback if the window is visible *) adding window.setIntervalIfVisible (same as the previous option really) A possibly better solution would be *) element.setIntervalIfVisible Which would only call the callback if that particular element is visible. From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. If you provide methods to check the visibility of a window or element, you leave it up to the author to use them or not. I think performance issues should rather be up to the UA.
Re: [whatwg] window.setInterval if visible.
On 10/15/09 4:14 PM, Jeremy Orlow wrote: I'd imagine that UAs could use an overly conservative metric of when things are visible to make things cheaper if/when this is a concern. It's a concern any time someone's checking it every 10ms interval invocation. For example, I'm right now looking at a browser window where the check would probably take longer than that (ping time from the X client to the X server is 50ms in this case). I agree that some mechanism to know when things aren't visible would be very useful. What are the use cases? Are they addressed by roc's proposal? If not, is an explicit script-triggered visibility check the only way to address them? -Boris
Re: [whatwg] Workers and addEventListener
On Thu, 15 Oct 2009, Drew Wilson wrote: On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson i...@hixie.ch wrote: There's no start() to call, since there's no explicit pointer to the MessagePort in dedicated workers. The example in the worker spec refers to shared workers, which *do* have an explicit port, and do not automatically start the port. Search for addEventListener in this document: http://www.whatwg.org/specs/web-workers/current-work/#shared-workers And you'll see what I mean. Ah, yes, for shared workers you need to call start() (or use .onmessage). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers and addEventListener
On Thu, 15 Oct 2009, Drew Wilson wrote:
To be absolutely clear (since there's some confusion about whether we
are talking about explicit MessagePorts, or about implicit ports for
dedicated workers). Are you saying that this:
var channel = new MessageChannel();
channel.port1.postMessage(hi mom);
channel.port2.addEventListener(message, function(event)
{alert(event.data); }, false);
Should result in an alert dialog being fired?
Nope, this case should not get an event fired.
I would not be opposed to changing the spec to include enabling a port's
message queue when addEventListener(message) is invoked.
I'm reluctant to make addEventListener() do magic.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Application cache feedback and application local storage features feedback
On Wed, 23 Sep 2009, Anne van Kesteren wrote: If you use a fallback namespace it will always try to do a network fetch before using the fallback entry so why is there a need for a NETWORK entry in the cache manifest? On Wed, 23 Sep 2009, Michael Nordman wrote: For cases where you don't want to, or can't, 'fallback' on a cached resource. ex 1. http://server/get/realtime/results/from/the/outside/world ex 2. http://server/change/some/state/on/server/side?id=xnewValue=y Creating a fallback resource with a mock error or empty response is busy work. What Michael said. On Thu, 24 Sep 2009, Anne van Kesteren wrote: You could fallback to a non-existing fallback or some such. No, that would prevent the application cache ever getting cached, IIRC. But if it is really needed NETWORK should get priority over FALLBACK in my opinion (or at least the subset of NETWORK that is not a wildcard) Done. Resources that are actually in the cache still win over the offline whitelist namespace. On Wed, 23 Sep 2009, Mike Hearn wrote: I read the threads on whether local storage should be managed by the browser or user with interest. I'm not sure if there was agreement on this or not (didn't read the whole thing), but had an idea for one solution. Namely, that local storage is indeed managed by the browser automatically and can be purged at any time long-term client persistence of web app data is instead done by letting webapps handle the file-save menu item that exists in nearly every browser except smartphones (see below). The advantages of providing onfilesave= and onfileload= event handlers are: 1) It does not add complexity, because the user isn't expected to do any more than they are today (no new ui to manage local storage etc) 2) It is 100% compatible with users existing mental model for how they export data from an application that they wish to save, back up to disk etc 3) It fixes the existing behavior of file|save for web apps which is pretty useless and not what the user expects, unlike for regular web pages where it does work 4) It solves the problem of client-side backups How could it work? In response to an onsave event, the app could return a Storage object that contains the data that makes sense to persist (ie, not big data files). There could be a few reserved keys for things like the icon, default file name and URL to open in conjunction with that web bundle. If the user double clicks or uses file|open on such a file, the browser would load the URL named in the bundle file and fire the onfileload handler with that storage object. This seems like a decent compromise between the two positions, in that it'd let you make traditional desktop-style apps written in HTML as Apple want, but for pure cloud apps that happen to just need more local storage, the user isn't asked to do more than they are today - which I personally consider vital for the evolution of the web. What about clients where there is no user-accessible file system, like smartphones or perhaps ChromeOS? Then onfilesave/onfileload can be integrated with whatever other UI is wanted - for instance, perhaps starring/bookmarking should trigger a save to local storage, or a basic documents associated with this web site list could be used. What do you think? Applications want to save state continually, not just at user checkpoints. Applications want to save state without the user really knowing that it is state. So I don't think this really solves the problem. Also at this point IE8 has shipped the localStorage API, so I think we're basically stuck with it. On Wed, 23 Sep 2009, Mike Hearn wrote: 3) Doesn't solve the fact that file|save doesn't work for web apps I think it's wrong to think of Web Apps as distinct from Documents. Is a Google Search results page an Application or a Document? It might want to save state, e.g. to remember whether you want Safe Search enabled or not. Should you have to do File | Save to save that state? What about if you want to save the results of a search to a file? On Wed, 23 Sep 2009, Michael Nordman wrote: Food for thought around the AppCache feature which can be similarly affected i think. -- Forwarded message -- From: emu emu.hu...@gmail.com Date: Sun, Sep 20, 2009 at 8:31 AM Subject: [gears-users] Version in manifest is not enough To: Gears Users gears-us...@googlegroups.com Some times the response of the web server be changed by some proxy servers or even the ISPs(some times they try to add some ads or filter something), and google gears will cache the changed content an will not check before the manifest file change again, and some times the manifest files change before the files they list changed because of the CDN problem. When these happends, wrong captured files becomes a disaster. It's very hard to findout what happends to the clients'
Re: [whatwg] Canvas Proposal: aliasClipping property
On Sat, 3 Oct 2009, Charles Pritchard wrote: In some implementations: when drawImage is used along with a clipping path, feathering is applied. This shows up in several projective transformation demos contrasting Firefox with Chrome. [...] On Sun, 4 Oct 2009, Marius Gundersen wrote: [...] it could perhaps include all the other drawing options, like stroking and filling paths created with lineTo, arc, etc. On Thu, 8 Oct 2009, Charles Pritchard wrote: [...] it would work with other things; use a fillRect across the extent of your clipping path. And there you go, aliased paths. On Sun, 4 Oct 2009, Robert O'Callahan wrote: I would just have boolean property named antialias. On Thu, 8 Oct 2009, Charles Pritchard wrote: There are two completely different renderings for various compositon modes in Chrome and Firefox. Chrome developers have certainly posted as to why they chose their method. Firefox devs have certainly taken their stand. I think they're both valid operations, but I'd like to have some unity. [...] On Fri, 9 Oct 2009, Robert O'Callahan wrote: I agree it would be good for canvas users to be able to turn off antialiasing in canvas. But your syntax is not the best way to do that. In particular, this really has nothing to do with clipping, it's all about antialiasing, and a boolean property would be just fine here IMHO. It doesn't matter if canvas currently has no boolean properties, lots of other elements do. Turning off anti-aliasing just trades one problems for another. IT seems like what we should really do is either have UAs oversample without antialiasing and then downsample for rendering, or, if that is considered too expensive, provide primitives that make this a non-problem. For example, instead of just having the ability to draw rectangles, maybe we need the ability to specify a number of rectangles, and then have them all drawn at once, so that if they are adjacent, the UA can render them without the anti-aliasing artifacts between them. In either case, it seems like something best handled in a future version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas Proposal: aliasClipping property
On 10/15/09 6:37 PM, Ian Hickson wrote: On Sat, 3 Oct 2009, Charles Pritchard wrote: I agree it would be good for canvas users to be able to turn off antialiasing incanvas. But your syntax is not the best way to do Turning off anti-aliasing just trades one problems for another. I'm not sure I understand what that trade is -- isn't that something that the individual user of Canvas would take into account when flipping the switch? I'd thought that implementers would get something of a break, if this toggle were only applied to clip(), as its somewhat rarely used in the wild (unlike say, fill, and everything around it). Robert has pointed out that it's the anti-aliasing method that causes issues. IT seems like what we should really do is either have UAs oversample without antialiasing and then downsample for rendering, or, if that is considered too expensive, provide primitives that make this a non-problem. For example, instead of just having the ability to draw rectangles, maybe we need the ability to specify a number of rectangles, and then have them all drawn at once, so that if they are adjacent, the UA can render them without the anti-aliasing artifacts between them. As far as I've seen, this issue has only been noticed [in the wild] and scorned those attempting to use clip() in various ways. Though you have put forward a novel alternate proposal. The setTimeout/setInterval loop (intrinsic to Canvas, via Window... and intrinsic to its double-buffering properties) appropriately segments one set of primitive drawings from another set (drawing them all at once). That particular loop is already setup, browser vendors within the current standard could make appropriate adjustments (turning off coverage based anti-aliasing for adjacent lines). They would have to buffer the fill / fillRect / drawImage commands though, to identify when lines are adjacent. In either case, it seems like something best handled in a future version. It seems like something that won't be handled in this version. Double buffering seems to be implicit in the docs (certainly talked about on this list) though not explicitly mentioned, so we can't build on it. ... Having gone back and forth with Robert a bit: I was able to recall the whys of a particular issue that could be handled in this version of the spec, regarding compositing. As far as I can tell; the area (width and height, extent) of source image A [4.8.11.13 Compositing] when source image A is a shape, is not defined by the spec. And so in Chrome, when composting with a shape, the extent of image A is only that width and height the shape covers, whereas in Firefox, the extent of image A is equivalent to the extent of image B (the current bitmap). This led to an incompatibility between the two browsers. Best as I can tell, Chrome takes the most efficient approach. For a very visible example, see the Moz page below in both browsers: https://developer.mozilla.org/en/Canvas_tutorial/Compositing
Re: [whatwg] Canvas Proposal: aliasClipping property
On Fri, Oct 16, 2009 at 2:37 PM, Ian Hickson i...@hixie.ch wrote: IT seems like what we should really do is either have UAs oversample without antialiasing and then downsample for rendering, or, if that is considered too expensive, provide primitives that make this a non-problem. For example, instead of just having the ability to draw rectangles, maybe we need the ability to specify a number of rectangles, and then have them all drawn at once, so that if they are adjacent, the UA can render them without the anti-aliasing artifacts between them. The latter approach often is not usable in practice when you don't know much about the scene that's being drawn, for example when you're using canvas to implement another drawing API. 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: [whatwg] framesets
Nelson, 1) Framesets have been deprecated for quite a long time. The reasons for the deprecation have been repeated ad nauseam, and very solid. Which solid objections did I not knock down? 2) There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panels (this is, I believe, the something you're getting at). OK. 3) There are HTML5-conformant solutions available right now that allow you to replicate the above scenario with a little more work. Can't tell without a lotta work on it, I've solved the problem once, I'd rather spend development time on unsolved problems. 6) For clarity sake, I'll repeat the point made several times:the bookmarking/navigation/security issue is *not* solved by framesets, OK and for clarity's sake I'll again repeat framesets don't solve the navigation problem, they just make it easier to solve than any other available proved solution, and this wee problem is that browsers own bookmarks, database users own database table rows, so usually you shouldn't bookmark database table rows, and much follows from that, therefore saying server issues don't bear on this issue is IMO astonishingly quite wrongly blinkered. As an aside, there is a reason why AJAX has become so popular over the past few years: it solves the specific UI-reset issue that is inherent in full-page refreshes. Maybe there is room for a better, standard-based approach to solving this issue, but framesets ain't it. Indeed, and as you also know in some contexts AJAX is not the most desirable refresh solution. Thanks for the links to two alternative possibilities. PB - Nelson Menezes wrote: Wow, what a tour de force; 78 messages and no progress. Peter, I believe the only reason the discussion has carried so far is because you are, actually, on to something. You just don't seem very aware that people are actually trying to pin down and solve the something and keep banging on about framesets being the cure-all, whilst ignoring other points. Here's (yet another) summary: 1) Framesets have been deprecated for quite a long time. The reasons for the deprecation have been repeated ad nauseam, and very solid. 2) There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panels (this is, I believe, the something you're getting at). 3) There are HTML5-conformant solutions available right now that allow you to replicate the above scenario with a little more work. The iframes solution with a bit of JS [1] [2] for handling the resizing is probably the easiest to implement, although an analogous solution with AJAX is probably the best available (which allows for deep-linking when this is desirable and doesn't automatically break bookmarking). You can also (if you wish) break bookmarking/the back button with these solutions, especially the AJAX one. There is also the CSS position: fixed solution that will be adequate for a large number of scenarios, or can complement the other two. 4) As repeated many times, you don't have to use HTML5. Keep using HTML 4 Frameset [3] if you insist on using the frameset solution and care about validation. The documents within each frame can be HTML5. Or use HTML5 with framesets -- it won't validate but is guaranteed (by the spec) to work. Do expect to run into the usability problems inherent to frames, though. 5) There is a known need for CSS to handle the above panel resizing use-case. That is a first-class CSS problem; don't expect the HTML spec to address that, especially not with a mechanism (framesets) that has many drawbacks and is deprecated for good reasons. For immediate solutions, see 3) and 4) above. 6) For clarity sake, I'll repeat the point made several times:the bookmarking/navigation/security issue is *not* solved by framesets, and the slight hack to make this work (javascript's replace) as you suggest is neither exclusive to framesets nor (in the case of security) acceptable. As an aside, there is a reason why AJAX has become so popular over the past few years: it solves the specific UI-reset issue that is inherent in full-page refreshes. Maybe there is room for a better, standard-based approach to solving this issue, but framesets ain't it. [1] http://methvin.com/splitter/4psplitter.html [2] http://developer.yahoo.com/yui/examples/layout/page_layout.html [3] http://www.w3.org/TR/html4/sgml/framesetdtd.html Nelson Menezes http://fittopage.org 2009/10/14 Peter Brawley p...@artfulsoftware.com Rimantas, Maybe there are not many sites because nobody wants this type of sites? You think
