Re: [whatwg] Installable web apps
On Sat, Aug 21, 2010 at 5:48 PM, Aaron Boodman wrote: > Reviving ancient thread... > > To get a feel for the different approaches and tradeoffs, I've > implemented a prototype of this using the two of the approaches that > were discussed in this thread: > > 1. Embed metadata in the page, building off the existing support for, > > 2. Link to a separate metadata document: > > As I see it, here are the advantages of the two approaches: > > 1: > - a bit simpler > - builds off the existing features in the platform > - blends with other concepts too. Like the favicon sizes could be used for other, non-webapp uses. > > 2: > - DRY-er (doesn't repeat the same information on multiple pages of the > application) > - Easier for third-party agents (eg search engines) to consume > (doesn't require an HTML parser) > - The browser doesn't have to load a page to consume > > Based on this, I'm liking #2 better as a path forward and am going to > push to get an implementation of this working in Chromium. > > Are there any other vendors interested in doing something similar? If > so, I'd like to hash out the details so we end up with > interoperability. > We are planning a similar feature for the next release of Mozilla's mobile Firefox. See: https://wiki.mozilla.org/Mobile/Projects/WebApp_Support Some of our current implementation leans more toward #1, but we could look at #2 for a lightweight, installed webapp design.
Re: [whatwg] Proposed additions to ClientInformation interface
On Mon, Jul 21, 2008 at 10:10 PM, Ian Hickson wrote: On Mon, 7 Jul 2008, Mark Finkle wrote: > > > > The only reason I can see for such an API is to get the user's > > permission to use features that _may_ be a bit of a security risk to > > normal webapps. Clipboard, dock badging, local file drag-n-drop, even > > offline cache are some examples. > > Clipboard, drag and drop, and offline caching are all available to all > applications in HTML5, since the APIs are intended to be designed in a way > that doesn't expose the user to risk that requires user permission. > Then why would a button be needed to "activate" standalone mode? What is the actual webapp doing differently? Shouldn't the webapp be acting the exact same? Sounds like it's the UA that would act differently. > > Dock badging could be equally made available safely, IMHO. The main reason > I haven't made dock badging available so far is that it doesn't really > make sense for most environments -- in fact as far as I know only Mac OS X > has this feature. > Great to know. Prism has code that allows and elements to be used to add menuitems to the Dock (Trayicon on Windows) menu as well. We could even support something like ... for this too. Ignored by UAs that don't support it. > > > > > * Sites want this mechanism to be inline so that they can position it > > >on their page. > > > > on the page? not sure it is as trustworthy there. > > > > > * It shouldn't be something that appears in the browser's UI, since > > > browsers have basically run out of room. > > > > disagree. it will depend in browser UI anyway for the confirm prompt > > This isn't something we get to disagree with. When a browser vendor says > "we would like to offer X and our requirement is Y", where Y in this case > is "it doesn't appear as a permanent feature of our UI", then that's what > we have to provide, otherwise they'll just ignore us and do their own > thing. > > > > > * It would be better if this mechanism could integrate with the menu/ > > > command feature in HTML5. > > > > why isn't this "feature" skipped and the menu/command used instead (when > > needed)? when the app tries to use the menu/command the browser can > > prompt and remember response. > > I don't understand what you are suggesting here. > I am suggesting that an explicit "push to make a standalone app" button isn't needed. Any webapp is already able to run standalone. _If_ there is some reason, for security or code privilege, that an explicit action or confirmation is needed on the part of the user, such confirmation should be enforced at the point of execution, when the user attempts to do something that might be dangerous. > > > > > One possibility for addressing these requirements would be an element > > > that acts as a link, button, or icon, or some such, and which invokes > > > user agent features. Something like: > > > > > > > > > > > > ...where "type" has a value to provide the page as a standalone Web > > > app, a value to make the browser perform feed autodetection on the > > > page and subscribe to the relevant feed, a value to print the page, > > > etc. > > > > overengineered overkill . let's just stick to the real features that > > webapps need to act more standalone and worry less about in-page badges > > I'm not really sure how this resolves the problem of offering the page to > the user as a "download" for turning it into a standalone application. > IMO, it's a problem that doesn't need to be solved. Any webapp (or webpage) can be turned into a standalone application without any effort on the part of the webapp (or webpage).
Re: [whatwg] Proposed additions to ClientInformation interface
On Tue, Jul 8, 2008 at 1:01 PM, Krzysztof Żelechowski <[EMAIL PROTECTED]>
wrote:
> Tuesday 08 of July 2008 05:10:46 Mark Finkle napisał(a):
> > On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > > On Fri, 27 Jun 2008, Brady Eidson wrote:
> > > * Sites want to offer a way for users to opt into a standalone mode
> > > ("can we offer a link to download one of these standalone Web
> apps?").
> > > Basically, to offer a way to bookmark the page as a standalone app
> > > instead of as a bookmark that opens in the browser.
> >
> > link rel ?
>
> Not really, it would abuse the LINK element.
>
define abuse
>
> > > * It shouldn't be something that appears in the browser's UI, since
> > > browsers have basically run out of room.
> >
> > disagree. it will depend in browser UI anyway for the confirm prompt
>
> The prompt would be presented in a modal window, therefore it would not use
> chrome space.
>
I hope no modal windows will be used in the making of this UI. Firefox
currently doesn't use modal UI for permission prompts.
Re: [whatwg] Proposed additions to ClientInformation interface
On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Fri, 27 Jun 2008, Brady Eidson wrote:
> >
> > There is one aspect to this notion of "Web Applications" that is being
> > explored by multiple vendors but hasn't been explicitly addressed in
> > HTML5 quite yet: the "stand alone web application."
>
> Actually there are a number of features that cater for this use case
> already, like the sizes="" attribute on rel=icon, and one of the
> names. In general, though, the idea is to make these kinds of applications
> as indistinguishable from other Web pages as possible, for a variety of
> reasons.
>
Agreed, there are more than a few features in HTML5, and some in other
working implementations, that cater to standalone webapps.
> In support of this new area of interest, I propose two new additions to
> > the ClientInformation interface as follows:
> >
> > First: "readonly attribute boolean standalone;"
> >
> > This is in the same vein as the window.navigator.onLine property which
> > gives authors a great hint on how to change the behavior of their web
> > application based on the existence of a network connection. The
> > standalone property would give web application developers a powerful
> > hint as to whether or not they are running in a full browser or in a
> > more minimalistic, dedicated user agent. There's a number of things they
> > might customize based on this situation such as look, feel, and
> > available feature set.
>
> I am very concerned about Web authors doing exactly this, and would in
> fact strongly like to encourage authors not to do this. Can you give an
> example of a use case where there would be a difference?
>
IMO, navigator.onLine is a bit less vague than window.standalone with regard
to context. The web author has no idea what feature set impact standalone
really means for different UA.Being a bit more specific in the feature set
support would be better and isn't JS good enough at discovering API
existence?
> > Second: "void makeStandalone();"
> >
> > Web applications that have been fully designed to behave as stand alone
> > applications should be able to announce this fact. Currently web
> > applications would have to state in their page that they are "standalone
> > aware" and to instruct users on how they might go about creating a
> > standalone version of the page. I've seen and heard buzz that web
> > authors would like a better way.
>
IMO, webapps should not have to be "fully" designed to behave standalone to
in fact be run as standalone. Documentation sites are a good example of a
nice standalone webapp that needs no real internal support.
> >
> > This is what the makeStandalone() call is about. The intention behind
> > the call is that the user agent would prompt the user about creating a
> > standalone application from the current page. Of course user agents
> > would have full flexibility in how they respond to the call such as
> > choosing to do nothing, prompting only once for a given domain or URL,
> > or prompting only when the user prefers to be prompted. I imagine most
> > user agents would tie the workings of this method to a user action, much
> > like popup blocking works currently, so the page could only enact the
> > prompt when the user clicks on some control. I just think it's quite
> > valuable to get the tool out there for web applications to use.
> >
> > The exact naming of this method call is up for debate, but I think my
> > point is clear.
>
The only reason I can see for such an API is to get the user's permission to
use features that _may_ be a bit of a security risk to normal webapps.
Clipboard, dock badging, local file drag-n-drop, even offline cache are some
examples.
Instead of a single API call, why not just ask the user whenever one these
"security risk" features is attempted, and remember the response on a per
site/domain/whatever basis?
> I'm not sure a method is the best solution here.
>
> As I see it, based on discussions and other e-mails, here are the use
> cases and requirements:
>
> * Sites want to offer a way for users to opt into a standalone mode
> ("can we offer a link to download one of these standalone Web apps?").
> Basically, to offer a way to bookmark the page as a standalone app
> instead of as a bookmark that opens in the browser.
>
link rel ?
>
> * Sites want this mechanism to be inline so that they can position it on
> their page.
>
on the page? not sure it is as trustworthy there.
>
> * It would be better if this mechanism could use user-agent specific
> iconology instead of site-specific iconology, so that users could learn
> to look for particular icons, as they have with RSS.
>
which has moved to browser UI
>
> * Authors should be able to customise the look, though.
>
well, not if it is in the browser UI
>
> * This mechanism shouldn't be visible in user agents where the feature
> isn't available.
>
agree
>
> * This mechanism shouldn't be visi
Re: [whatwg] [canvas] imageRenderingQuality property
On Mon, Jun 30, 2008 at 7:30 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 30 Jun 2008, Vladimir Vukicevic wrote: > > On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote: > > > On Mon, 2 Jun 2008, Vladimir Vukicevic wrote: > > > > > > > > I'd like to propose adding an imageRenderingQuality property on the > > > > canvas 2D context to allow authors to choose speed vs. quality when > > > > rendering images (especially transformed ones). > > > > > > How can an author know which is appropriate? > > > > Erm, presumably because they're the author -- it seems quite valid to > > for an author to be able to say "Just make this happen quickly, I don't > > care about the quality" or "Take extra time to make this the highest > > quality you can". > > It seems better for the browser to simply detect when the graphics burden > being placed on the hardware by the page is too much to be done at high > quality given the current load on the CPU, and for the browser to > automatically drop down to a lower fidelity, higher speed rendering on the > fly when appropriate. > So now we need to define levels of graphic burden? and at what level of burden does the quality suffer? Seems just as hard to define. Having the author explicit say "this has to be as high quality as possible" or "less can be low quality" seems better and we have examples of other specs offering the same kind of control.
