On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp <ga...@gavinsharp.com> wrote: > What does it mean to "save your <complex web app> for later viewing"?
In gmail it would mean saving the set of emails that you are currently looking at. For facebook it would mean the news-feed content that's currently on the screen, or the event invitation details that you are currently looking at. That's what we would get if we serialized the current DOM+CSS+images to disk without any additional smarts. And all of these seem useful for users. > I don't think there's a lot of overlap between sites that would use > the functionality roc is proposing, and sites that make sense to "save > for later viewing". I don't think that's true. Websites like nytimes often want a more beautiful layout than what CSS can offer today. And once you create a library for handling popular layout systems I have no doubt that various tumblr templates or blogs will adopt UIWorker. When a better alternative to the DOM appeared in the form of jQuery, they adopted that. So when a better alternative to CSS appears though UIWorker, I would expect to see a lot of adoption of that as well. And, in a sense, broad adoption is what we *should* hope for with most platform features that we implement. / Jonas > On Mon, Feb 23, 2015 at 10:36 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> On Sun, Feb 22, 2015 at 3:45 AM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >>> On Fri, Feb 20, 2015 at 9:11 PM, Jonas Sicking <jo...@sicking.cc> wrote: >>>> >>>> On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan <rob...@ocallahan.org> >>>> wrote: >>>> > Should UIWorkers have access to the full Worker API? It seems like >>>> > there's >>>> > no reason not to give them that. >>>> >>>> There's two use-cases that I think argues against that. >>>> >>>> First off I'd like to enable saving a webpage for later viewing. Right >>>> now the best we can do is to save a pdf which means that all >>>> scrollable areas are lost. >>>> >>>> Saving a full page with all scripts is rarely going to work result in >>>> the user seeing the page they did when saving the page. >>>> >>>> What I'd like to be able to do is serialize the DOM, strip all script, >>>> save all linked stylesheets, images and media and change the >>>> references to them to use the correct relative URLs. >>>> >>>> However this would require also saving the UIWorker and enabling it to >>>> run in a reliable way. Otherwise the saved page won't have a working >>>> layout. >>>> >>>> Second, when printing, I'd like to enable the user to change page >>>> layout and margins and have that reflow the page and generate a >>>> correct layout. This means that we need to enable the UIWorker to work >>>> on the cloned document in a reliable way. >>>> >>>> I think both these usecases would work much better if we ensured that >>>> the UIWorker couldn't "interact with the outside world". >>> >>> Your use-cases already fail today because many Web pages use scroll event >>> handlers and JS custom layouts. UIWorkers won't make the problem any worse. >> >> I agree that it's not making the problem worse. However #1 is making >> the problem better, so unless we can address this, this becomes an >> argument for #1 over #2. >> >>> Furthermore, I think facilitating expressive performant mobile Web apps is >>> much more important than those use-cases, and preventing UIWorkers from >>> interacting with the outside world (including, I assume, the application >>> main thread) would severely limit their usefulness. >>> >>> Personally I think it's futile to try to save a complex app "for later >>> viewing" and expect anything useful to happen unless the whole app is >>> captured and able to operate offline. >> >> The lack of ability to save for later viewing is a big problem on mobile. >> >> The fact that native is so much better at retaining content to make it >> available later when the user is offline is one of the big reasons >> that the web is having a hard time competing with native. >> >> So I do think that this is an important problem to solve. >> >> / Jonas >> _______________________________________________ >> dev-servo mailing list >> dev-se...@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
