Re: [whatwg] Persistent and temporary storage
On Wed, Mar 18, 2015 at 1:38 AM, Krinkle krinklem...@gmail.com wrote: I'd like to share a use case and problem we have at Wikipedia with localStorage. Thanks, this is great feedback. I imagine HTTP2 might make it appropriate to phase out batches and just request modules individually (always) and let the network layer do the combining and separated caching in a more natural way. Yeah, hopefully. * A way to know if a url is cached or not (e.g. know whether a url will hit HTTP 304) without making the request. Maybe we can expose that same-origin, not sure. Depends a bit on the implementer feedback we get for fetch()' cache feature. But privacy-wise it's somewhat problematic to reveal what is in the cache as the cache is not unique per-origin. * A way to prioritise which entries should be kept in localStorage and allow for low-prio entries to be evicted if short on space. * A way to know how much localStorage is available in total. * Perhaps a way to create a limited store within localStorage or IndexDB that has limited/restricted capacity (with some unique identifier, capacity percentage-based, or a min/max byte size?). * A separate store for caching HTTP resources (the Service Worker's Cache API?) The current setup is basically a storage area per site with LRU semantics. It's not completely done yet as not all storage features share the same store, but they will eventually. Persistence is planned as per OP. We have two other ideas roughly along the lines of what you ask for: 1) Allow a site to mint new storage areas. If we keep doing LRU on storage areas rather than sites that would allow for e.g. a game engine staying preserved while the initial set of levels (one per storage area) that are no longer played are cleared. 2) A storage area that acts like a cache. Resources that are not frequently used get deleted before those that get frequently used get deleted. -- https://annevankesteren.nl/
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby, the major criticism you have received about your proposal is that you aren't considering at all any other party involved in this subject. Correct me if I'm wrong, you cite no user agent responsible for support, nor working groups or anything loosely resembling to that. You are providing a very useful insight on how *you* see the web. And you also provide a feedback based on the experience of high-school Tumblr girls (why should she learn how to use Angular? However, there's nothing bad if she learns something new). The fact is, your proposal cannot be labeled as HTML6 Web needs something new. And however your last messages do show that the proposal itself is not strictly related to read/write Web as you claim. In fact, the main reasons you cite behind your proposal are responsiveness and full-page reload latency. Which are real problems, for sure, but not in the sense of read/write, they're rather a matter of UX. A relative matter which does not make the Web largely unusable, and if you have doubt about it just have a look at ChromeExperiments and see what can be done with current poor methods. If what you need is localised content load, you have some features you can use as of now. For example, you can use nested browsing contexts, which also offer a layer of protection in the form of CORS restrictions, sandboxing and MIME type declaration. You want to get rid of these things? Use XHR, its support is native. As you said, you are not against JS itself, but against writing more Javascript than necessary. If you have the means, push towards a more pervasive standardisation of current JS implementation, so that there will be decreasing need for polyfills and syntax standardisers (with your proposal, there'd be a need for a polyfill as well until it doesn't become supported on new UA versions *and* new UA versions completely or substantially replace legacy versions). You still want more? Don't focus on changing a web page content. HTML is still a declarative language after all, and there's nothing bad with it. It's the purpose which originated it. Of course there's more now, but the examples of websites or web apps you cited don't generally change the content of a page, they integrate it, adding more items to the page as time passes and events happen. So, as I said some messages ago, why not focusing on template? It can add new elements to the existing document, it's HTML5 so you will have no chance of proposing your language, but you can still work fairly well with it and with its margins for improvement. Current spec suggests how to use it with a JS framework, why don't you elaborate a proposal where template is able to load and parse its own content-to-be? (Of course you can even imagine loading a page which is initially empty, with just a declaration for a template, which adds content at runtime. But it is different from altering current content, a kind of operation that no web designer would desire to be natively executed). And finally, consider that JS complexity and JS memory load are 2 different aspects you will have to face with a brand-new language or featureset: - complexity deals with richness of use cases. When dealing with external content load you have to consider its origin, format, language, connection delay time (you focus on mobile experience, so you know what I mean), its parsing. You have your mind standards, but you can't think things go always ideally, nor you can consider that everybody uses the same structure you have in mind. JS is flexible in this, as it manipulates current DOM structure. Would your native implementation be flexible as well? (side note: if you look at template, its content is really flexible, as it allows as content model lists, tables, subsets of tables, menus and definitely all flow content subsets you can imagine.) It also deals with security. HTML cannot be stretched to execute direct SQL commands (what if those commands are maliciously altered? Do you guarantee instructions integrity? Or perhaps you provide a level of abstraction between HTML6 instruction and DB instruction? This only translates complexity from one language to another, you see), nor to directly respond to server-triggered events (you can imagine the issues of maintaining an open channel with the server in order for it to fire content loading events, both on the side of performance and security). - memory load is a completely different case. Yes, in order for a framework to work, you have to deal with downloading and compiling it, then it has to be executed. A native feature doesn't need downloads, but it makes UAs heavier when they have to deal with all the subtleties of content handling. You are suggesting that a UA behaves as a client for a specific server of your web app, in a 2-way interaction (you can talk about page and all, but the actor in a MVC as view and controller is the browser itself). Can you guarantee that the additional work managed by the user agent does not
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
You’re making this more complicated than it needs to be. Simplify the problem domain. I think we can all agree, we don't want another App Cache on our hands for a standard. Sorry you feel an idea can be thrown out, immediately accepted and pushed through simply because it seems obvious. In the real world, things aren't always boiled down to the simplest solutions. Sometimes, we need to have a bit of complexity and extra overhead in setting something up to make sure it is robust and effective in as many situations as possible. As has been said before, build a polyfill to show off your idea. I don't think many vendors want to spend time building this out in-browser to test when it is easily done in existing JS to get the idea down. We also need to stop thinking purely about how things were built two years ago. ES6 and Web Components introduce a lot of ground-breaking changes in this area, we should see how they play out with framework vendors before jumping into throwing it all into HTML and hoping it works well. So saying this is a “hard problem” just reeks of Javascript developer laziness This sounds very disrespectful. You're telling the people who are, writing the standards, paying attention to give input to new standards and modifying existing ones that they are lazy. They do this for a reason, most have been bitten by some poorly thought out standard. This could end up just another one. This kind of response does not encourage people to continue to have a conversation on the proposal with you. On Mon, Mar 30, 2015 at 9:08 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Bobby, the major criticism you have received about your proposal is that you aren't considering at all any other party involved in this subject. Correct me if I'm wrong, you cite no user agent responsible for support, nor working groups or anything loosely resembling to that. You are providing a very useful insight on how *you* see the web. And you also provide a feedback based on the experience of high-school Tumblr girls (why should she learn how to use Angular? However, there's nothing bad if she learns something new). The fact is, your proposal cannot be labeled as HTML6 Web needs something new. And however your last messages do show that the proposal itself is not strictly related to read/write Web as you claim. In fact, the main reasons you cite behind your proposal are responsiveness and full-page reload latency. Which are real problems, for sure, but not in the sense of read/write, they're rather a matter of UX. A relative matter which does not make the Web largely unusable, and if you have doubt about it just have a look at ChromeExperiments and see what can be done with current poor methods. If what you need is localised content load, you have some features you can use as of now. For example, you can use nested browsing contexts, which also offer a layer of protection in the form of CORS restrictions, sandboxing and MIME type declaration. You want to get rid of these things? Use XHR, its support is native. As you said, you are not against JS itself, but against writing more Javascript than necessary. If you have the means, push towards a more pervasive standardisation of current JS implementation, so that there will be decreasing need for polyfills and syntax standardisers (with your proposal, there'd be a need for a polyfill as well until it doesn't become supported on new UA versions *and* new UA versions completely or substantially replace legacy versions). You still want more? Don't focus on changing a web page content. HTML is still a declarative language after all, and there's nothing bad with it. It's the purpose which originated it. Of course there's more now, but the examples of websites or web apps you cited don't generally change the content of a page, they integrate it, adding more items to the page as time passes and events happen. So, as I said some messages ago, why not focusing on template? It can add new elements to the existing document, it's HTML5 so you will have no chance of proposing your language, but you can still work fairly well with it and with its margins for improvement. Current spec suggests how to use it with a JS framework, why don't you elaborate a proposal where template is able to load and parse its own content-to-be? (Of course you can even imagine loading a page which is initially empty, with just a declaration for a template, which adds content at runtime. But it is different from altering current content, a kind of operation that no web designer would desire to be natively executed). And finally, consider that JS complexity and JS memory load are 2 different aspects you will have to face with a brand-new language or featureset: - complexity deals with richness of use cases. When dealing with external content load you have to consider its origin, format, language, connection delay time (you focus on mobile experience,
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby, The burden of proof is on you. This is how argumentation and debate works. Many rebuttals have been made that you simply ignore or fail to address. You continue to make conflated statements that only distort the conversation more. Like I said before, I'm not opposed to you sharing an opinion but it should not belittle other voices. I have no idea why people say this is a “hard problem.” You’re making this more complicated than it needs to be. Simplify the problem domain. We just need a declarative, native MVC framework in the browser. Think about these larger level questions first. Why should MVC be a standard and why is your version the correct one? There is no agreed upon design pattern, yes MVC is popular but it takes many different forms. Some people prefer MVVM, MVP, MVA, PAC, RMR or even Naked Objects. And there are many more like event driven pipelines. My point is MVC is far from being an agreed upon solution, so why should we adopt your proposal? How do you handle internationalization or localization? Start there, there are numerous more issues. I gave a solution that’s optimal in every case. You have failed to demonstrate this. Make a polyfill. There is no case where using Angular or Ember or React would be a better solution than having a native MVC framework in HTML. Statements like this only exacerbate your ignorance on the subject matter. Do you even understand these frameworks? What makes your opinionated version a standard and not a framework? All of the above don't claim to solve every problem but offer a pathway for extensibility, How would we extend your proposal for domain specific problems? It’s easier (declarative syntax), it’s responsive (no need to download large Javascript frameworks), and uses less power (uses native code). Maybe for you. Your opting for configuration over convention approach. Many developers despise this approach. Verbosity killed XML / XSLT how would this not suffer the same fate? Again show how downloading large javascript frameworks are a burden. Provide some numbers. Most of the issues around the current frameworks are due to Javascript itself and its interaction with the DOM. React’s framework has a virtual DOM implementation to help speed things and other frameworks are being rewritten to do the same. A user doesn’t have to worry about this. They’re experimenting and redesigning because they’re solving Javascript problems. No, they are using Javascript to solve state problems. HTTP/HTML is inherently stateless. How do you solve for state? Maybe we need to define the authentication mechanism first? Do you not see the fallacy of your proposal? Things should not have feature creep and require redefining every aspect of what exists. Break this down into small pieces. Like others said, this is a losing battle. Focus on templates first. That piece could have merit if properly defined and contained. The web is based on small pieces loosely joined, your trying to change the whole paradigm in one fail swoop. Tight coupling of many specifications. And we already serve JSON API endpoints, so I don’t know why you feel this adds more work to the server? This proposal would use the same data that API servers already provide. And if you need backwards compatibility, it’s there as well. Your inherently encoding more information about the server, hence pushing a larger burden and tighter coupling to the server. This is fine for frameworks but not standards. I’d like to see where this solution causes something to break. Or where Angular or Ember or React would be a better solution than this. With this proposal, you can still use Javascript for more advanced applications, you just don’t have to worry about loading in another MVC framework. Again the burden is on you. Angular, Ember and React are frameworks and not trying to become standards. Why is your proposal different, how is it not a framework? So saying this is a “hard problem” just reeks of Javascript developer laziness, stuck in local-minima comfort-zone. But this comfort zone doesn’t matter to non-Javascript people. (note that i’ve written thousands of lines of Javascript, but have no desire to write more Javascript than necessary.) Your oversimplifying the problem. Show a proof of concept. Make that polyfill. My suggestion would be to implement something like http://todomvc.com/ so others have a place to compare to what already exists. - Nathan White -bobby On Mar 28, 2015, at 1:19 PM, n...@nwhite.net wrote: Bobby, I think your enthusiasm to question and challenge the status quo is great. Many individuals like you challenge the standards in this mailing list. I'm constantly learning from the discussions that takes place from such proposals and I value it immensely. However, I'm kinda pissed off on how you went about sharing your insight. Unlike you everyone has encouraged discourse while respecting
[whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden. Right now, the visibility of an iframe is the same as that of the top level browsing context it’s embedded in. Here are the details: http://www.w3.org/TR/page-visibility/ http://www.w3.org/TR/page-visibility/ This design doesn’t do much for iframes which may be doing significant work, though. The most obvious example is HTML5 ads. These ads may be performing significant work - computation, network IO, rendering, etc. Some or all of that work is often unnecessary when the ad is outside the viewport. Having an API that would allow those ads to throttle back their work when they’re not visible could have significant positive effects on performance and battery life. We could get these benefits through a very simple modification of the Page Visibility spec. We should make the visibility of iframes independent of the top-level browsing context, and instead let UA’s take the actual visibility of the iframes into account. If an iframe has been scrolled out of the viewport, has become occluded, or has otherwise been rendered non-visible, we should regard the iframe as hidden and dispatch a visibilitychange event to let the iframe throttle itself. I think it’s worth noting that requestAnimationFrame could cover some of the rendering-related part of this issue, but it’s frequently the case that iframes are performing a good deal of computation and IO that isn’t tied to requestAnimationFrame. Even for the rendering case, the requestAnimationFrame API doesn’t give iframes any way to detect this kind of transition between a state where fast rendering is important and a state where it’s not useful, so in practice extending the Page Visibility spec in this way will often be useful even for iframes which rely mostly on requestAnimationFrame. I think we should view this change as complementary to the benefits that requestAnimationFrame can give us. If there’s willingness to change the spec, this is a change we’d be interested in making in Gecko in the near term. Sound good? Thanks, - Seth
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
A coworker pointed me to this thread on public-web-perf where exactly this proposal has been made before: https://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0047.html https://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0047.html Reading through the posts there has given me an idea of the challenges here, which is what I was hoping for when I sent the original email. It looks like we will need to gather some data about web compatibility before going forward, especially since other specs like the Vibration API reference the Page Visibility spec. I do want to clarify one other thing: we’re definitely not yet at the point of implementing this in Gecko, especially not in a release version. We think this functionality is important, and modifying the Page Visibility spec is one way to make it accessible to the web. It’s probably even the nicest way to make it accessible to the web, if it’s feasible. But it’s not certain that it’s web compatible or that everyone agrees this is the best way to go; we’re at the starting point of the process here. I’d be interested to hear any comments that others may have! Thanks, - Seth On Mar 30, 2015, at 3:47 PM, Seth Fowler s...@mozilla.com wrote: I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden. Right now, the visibility of an iframe is the same as that of the top level browsing context it’s embedded in. Here are the details: http://www.w3.org/TR/page-visibility/ http://www.w3.org/TR/page-visibility/ This design doesn’t do much for iframes which may be doing significant work, though. The most obvious example is HTML5 ads. These ads may be performing significant work - computation, network IO, rendering, etc. Some or all of that work is often unnecessary when the ad is outside the viewport. Having an API that would allow those ads to throttle back their work when they’re not visible could have significant positive effects on performance and battery life. We could get these benefits through a very simple modification of the Page Visibility spec. We should make the visibility of iframes independent of the top-level browsing context, and instead let UA’s take the actual visibility of the iframes into account. If an iframe has been scrolled out of the viewport, has become occluded, or has otherwise been rendered non-visible, we should regard the iframe as hidden and dispatch a visibilitychange event to let the iframe throttle itself. I think it’s worth noting that requestAnimationFrame could cover some of the rendering-related part of this issue, but it’s frequently the case that iframes are performing a good deal of computation and IO that isn’t tied to requestAnimationFrame. Even for the rendering case, the requestAnimationFrame API doesn’t give iframes any way to detect this kind of transition between a state where fast rendering is important and a state where it’s not useful, so in practice extending the Page Visibility spec in this way will often be useful even for iframes which rely mostly on requestAnimationFrame. I think we should view this change as complementary to the benefits that requestAnimationFrame can give us. If there’s willingness to change the spec, this is a change we’d be interested in making in Gecko in the near term. Sound good? Thanks, - Seth
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 30, 2015, at 2:06 PM, Nathan White n...@nwhite.net wrote: Think about these larger level questions first. Why should MVC be a standard and why is your version the correct one? There is no agreed upon design pattern, yes MVC is popular but it takes many different forms. Some people prefer MVVM, MVP, MVA, PAC, RMR or even Naked Objects. And there are many more like event driven pipelines. My point is MVC is far from being an agreed upon solution, so why should we adopt your proposal? Because the overall MVC won. This proposal optimizes what people do, not what they can do. This proposal isn’t a computer science project. How do you handle internationalization or localization? What’s the issue there? HTML has LANG attributes for every element. The proposal already allows you to assign model values to any attribute, including LANG attributes. Start there, there are numerous more issues. If you can, list them, preferably in the Github so I can track the issues. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com mailto:mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com http://www.futureclaw.com/ twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder http://www.linkedin.com/in/mozumder I gave a solution that’s optimal in every case. You have failed to demonstrate this. Make a polyfill. There is no case where using Angular or Ember or React would be a better solution than having a native MVC framework in HTML. Statements like this only exacerbate your ignorance on the subject matter. Do you even understand these frameworks? What makes your opinionated version a standard and not a framework? All of the above don't claim to solve every problem but offer a pathway for extensibility, How would we extend your proposal for domain specific problems? It’s easier (declarative syntax), it’s responsive (no need to download large Javascript frameworks), and uses less power (uses native code). Maybe for you. Your opting for configuration over convention approach. Many developers despise this approach. Verbosity killed XML / XSLT how would this not suffer the same fate? Again show how downloading large javascript frameworks are a burden. Provide some numbers. Most of the issues around the current frameworks are due to Javascript itself and its interaction with the DOM. React’s framework has a virtual DOM implementation to help speed things and other frameworks are being rewritten to do the same. A user doesn’t have to worry about this. They’re experimenting and redesigning because they’re solving Javascript problems. No, they are using Javascript to solve state problems. HTTP/HTML is inherently stateless. How do you solve for state? Maybe we need to define the authentication mechanism first? Do you not see the fallacy of your proposal? Things should not have feature creep and require redefining every aspect of what exists. Break this down into small pieces. Like others said, this is a losing battle. Focus on templates first. That piece could have merit if properly defined and contained. The web is based on small pieces loosely joined, your trying to change the whole paradigm in one fail swoop. Tight coupling of many specifications. And we already serve JSON API endpoints, so I don’t know why you feel this adds more work to the server? This proposal would use the same data that API servers already provide. And if you need backwards compatibility, it’s there as well. Your inherently encoding more information about the server, hence pushing a larger burden and tighter coupling to the server. This is fine for frameworks but not standards. I’d like to see where this solution causes something to break. Or where Angular or Ember or React would be a better solution than this. With this proposal, you can still use Javascript for more advanced applications, you just don’t have to worry about loading in another MVC framework. Again the burden is on you. Angular, Ember and React are frameworks and not trying to become standards. Why is your proposal different, how is it not a framework? So saying this is a “hard problem” just reeks of Javascript developer laziness, stuck in local-minima comfort-zone. But this comfort zone doesn’t matter to non-Javascript people. (note that i’ve written thousands of lines of Javascript, but have no desire to write more Javascript than necessary.) Your oversimplifying the problem. Show a proof of concept. Make that polyfill. My suggestion would be to implement something like http://todomvc.com/ so others have a place to compare to what already exists. - Nathan White -bobby On Mar 28, 2015, at 1:19 PM, n...@nwhite.net wrote: Bobby, I think your enthusiasm to question and challenge the status quo is great. Many
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 30, 2015, at 9:23 AM, Jonathan Garbee jonat...@garbee.me wrote: You’re making this more complicated than it needs to be. Simplify the problem domain. I think we can all agree, we don't want another App Cache on our hands for a standard. Sorry you feel an idea can be thrown out, immediately accepted and pushed through simply because it seems obvious. In the real world, things aren't always boiled down to the simplest solutions. Sometimes, we need to have a bit of complexity and extra overhead in setting something up to make sure it is robust and effective in as many situations as possible. I expect this process to take years. Not sure where anyone thought that it was going to be immediately accepted? One thing I’m interested in is to see more technical discussions around this idea. Like, very specific issues that show a design or concept flaw. It’s only been about 10 days since I proposed this and I haven’t received much in that area. (I did change one thing to split MREF from HREF based on feedback about people wanting backwards compatibility.) Instead, I’m mostly getting a lot of “I’m scared!” or “Everyone should get a PhD in Javascript like I did!” which obviously isn’t going to happen. So, if there are technical faults with the proposal here, definitely list them. (or preferably in the Github, where I can keep track of issues directly) We need to be able to advance the web without going through Javascript. It’s a mistake to assume that JS is a fundamental part of the web. The web is optimized for hypertext document processing, and most people use it to read content online. This proposal fixes a remaining issue with that. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com mailto:mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com http://www.futureclaw.com/ twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder http://www.linkedin.com/in/mozumder
