[whatwg] sticky css hover state on touch devices
on touch devices, there is a problem with sticky hover states https://bugs.webkit.org/show_bug.cgi?id=158517 https://bugs.chromium.org/p/chromium/issues/detail?id=370155 one workaround it to clone, remove and re-insert the element http://stackoverflow.com/a/31691425 my question is, should an element retain it's hover state when hidden? if it didn't, an easy workaround for this problem is to set display:none; and then display:block;... aka jquery $(el).hide().show() -- Zac Spitzer +61 405 847 168
Re: [whatwg] window.opener security issues (Was: WhatWG is broken)
how about rather than requiring this on every why not support a base tag directive for the whole document i.e. , similar to ? On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola wrote: > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian > Hickson > > > I believe that's a bit of an overstatement. There are certainly risks > involved in window.opener (they're briefly discussed in the spec itself), > but it doesn't remove the origin checks. > > This is the crucial point. > > Whenever you are discussing a supposed security issue, you need to make > clear what the threat model is. That is: > > - What would be the impact on the victim if the security hole is taken > advantage of? > - Is this something we are trying to prevent on the web platform? > > In this case, the impact on the victim (a user of a web browser) is that > they could click a link from page A to page B, which opens in a new tab > (tab B). Then, tab A could be navigated to a new URL, instead of staying on > page A. > > This is not a big impact. Notably, page B is not able to read any of the > content of page A, which might be sensitive. Page B is not able to > interfere with the operation of any of page B's scripts. And crucially, > when page B navigates tab A to another page, the URL bar of tab A changes > to indicate that. > > There is no desired security guarantee on the platform that we want to > prevent pages from directing users to "bad" sites. We count on users > inspecting the URL bar to understand what page they are interacting with in > a given tab. > > So, while it might be a bit surprising that suddenly tab A is navigating > somewhere else, there is no security issue here, and users are not > endangered in any way---at least, not in any more danger than they already > are from browsing the web without looking at their URL bar to see where > they've ended up at. > -- Zac Spitzer +61 405 847 168
Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)
But what do end users or developers expect in terms of browser behavior in this situation? The history api (or saving state to indexedDB) aren't going to solve the problem of reinitialization everytime the user switches back to a web app. Users expect them to behave like a native app. The early iPads were low powered devices and many app developers used to ship content as images because they couldn't render complex layouts quickly, but newer tablets are far more powerful and can handle this. Chrome handles this as users and developers expect, web apps get paged out and require a reload depending on memory etc. Safari does it every single time This is a massive barrier against web apps competing against native apps. On 10 Jun 2015 6:21 am, "Domenic Denicola" wrote: > I'm pretty sure it's out of scope. That's really asking to specify how > OS-level task switching works. I imagine that Safari-wrapper or whatever > has decided that when the OS switches back to it it will do a reload, just > like when I switch back to my mail app it does a sync, and other stuff like > that. > > > -Original Message- > > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zac > > Spitzer > > Sent: Monday, June 8, 2015 21:10 > > To: wha...@whatwg.org > > Subject: [whatwg] Persistent state for homescreen web apps (without > > reloading each time) > > > > Is it within the scope of the spec to specify whether home screen web > apps > > should retain their loaded state when switching from foreground to > > background and back to foreground again? > > > > Chrome behaves exactly as expected, however, iOS reloads the web app > > each time > > > > http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from- > > ios-home.html > > > > -- > > Zac Spitzer > > +61 405 847 168 >
[whatwg] Persistent state for homescreen web apps (without reloading each time)
Is it within the scope of the spec to specify whether home screen web apps should retain their loaded state when switching from foreground to background and back to foreground again? Chrome behaves exactly as expected, however, iOS reloads the web app each time http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-ios-home.html -- Zac Spitzer +61 405 847 168
[whatwg] console API improvements
console currently lacks the ability to access the console log history from javascript, it's not possible to wrap console.log and store a local buffer of log messages without then losing the original line reference . you can throw an error and catching it to get a strack trace, but this is isn't very performance friendly ideally we should be able to both access the console log history and also wrap log messages whilst maintaining line references -- Zac Spitzer +61 405 847 168
Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry
any thoughts about minimising the security implications on this? it makes it extremely easy to jump on a machine, open a browser page, select a sensitive folder and upload it all to a remote server z On Wed, Nov 16, 2011 at 1:06 PM, Glenn Maynard wrote: > On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda wrote: > >> The async nature of DirectoryEntry makes the code longer, >> but webapps can work on the files incrementally and can show >> progress UI while enumerating. For the apps that may deal with >> potentially huge folders providing such a scalable (but slightly >> more cumbersome) way sounds reasonable to me. >> > > Entry (and subclasses) should also be supported by structured clone. That > would allow passing a DirectoryEntry received from file inputs to be passed > to a worker. This is something for later, of course, but combined with an > API to convert between Entry and EntrySync (and DE/DESync), this would > allow using the much more convenient sync API in a worker, even if the only > way to retrieve the Entry in the first place is in the UI thread. > > I think this is a better solution to the inconvenience of async APIs than > falling back to exposing unscalable sync interfaces in the main thread. > This is one of the reasons we have workers. > > -- > Glenn Maynard > -- Zac Spitzer Solution Architect / Director Ennoble Consultancy Australia http://www.ennoble.com.au http://zacster.blogspot.com +61 405 847 168
Re: [whatwg] Client-side includes proposal
It sounds like a request for which would end up like an inline IFRAME This is such a common use case and just because you can do it with SSI means zlich, it presents challenges which sure, you can work around, but everyone will do it with a different way whether via javascript or a server side approach When it's so common, it's a good case for being standardised into some thing simple. XML or XLST is too heavy, simple problem, simple solutions this also has potential for significant page speed improvements and for reducing overall page sizes z On Tue, Aug 19, 2008 at 10:55 PM, Elliotte Harold <[EMAIL PROTECTED]> wrote: > Ian Hickson wrote: > >> Server-based offline Web apps are applications that are served by a remote >> server and then cached locally; this is very different from non-Web cases >> such as documentation on a local filesystem or on CD-ROMs. In the case of >> non-Web content, the use of HTML is an academic point, since any format >> would work as well. > > Really? Why? and how? That's certainly not self-evident. > > Aside from embedded links, which can point into the file system and are > usually relative anyway, there's very little web-specific about HTML. It's > just one format that can be served over HTTP or read from a disk, just like > PDF or text/plain or OpenDocument. > > HTML has some nice characteristics like resolution independence, direct > editability as text, and automatic reflow; but these are in no way limited > to network transfers. For many use cases, especially cross-platform ones, > HTML is the formatted text format of choice. > > A properly designed HTML spec should not require, prohibit, or preference a > document being read from the network or from a local file system or via any > other protocol. HTML 1 through 4 and XHTML 1 and 2 had this important > characteristic. I hope HTML 5 does as well. > > -- > Elliotte Rusty Harold [EMAIL PROTECTED] > Refactoring HTML Just Published! > http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA > -- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168
[whatwg] 5.4.3. The StorageItem interface - Cache flag
how does adding a flag for a storage item which indicates this item can be flushed from the session storage (ie cache) if the allocated space for client side storage is full. This would allow developers to use the storage more efficently and simply -- Zac Spitzer +61 405 847 168
