On Tue, May 27, 2014 at 11:01 AM, Robin Berjon ro...@w3.org wrote:
On 25/05/2014 20:40 , Piotr Koszuliński wrote:
Making some things unselectable might also be useful. IE has
unselectable, there's also -moz-user-select and friends. But this is
small fries for later I'd reckon.
As per our conversation in IRC, something else I'd like to highlight is the
fact that in the current version of the spec any web site can host an app
manifest for any web app. That means for example that I could create my own
app store for web apps and provide a listing for a GMail app which users
On Tue, May 27, 2014 at 5:11 PM, Marcos Caceres w...@marcosc.com wrote:
The only way one could do what you describe would be for my own app
store to host its own manifests. So:
http://myownappstore.com/gmail/index.html
Would contain:
link rel=manifest
On Mon, May 26, 2014 at 8:18 PM, Marcos Caceres w...@marcosc.com wrote:
Quick update: the Editors have closed off all V1 bugs for [manifest] and
implementations in Blink and Gecko are underway. A thorough review of
[manifest] by interested parties would be greatly appreciated! You can file
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25908
Bug ID: 25908
Summary: Is element editable if it's hidden
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
On Tue, May 27, 2014 at 9:53 PM, Marcos Caceres w...@marcosc.com wrote:
On May 27, 2014 at 3:31:15 PM, Ben Francis (bfran...@mozilla.com) wrote:
One risk of allowing cross-origin manifests might be that these
tailored app experiences are perceived by the actual app author
and/or end users as a
On Tue, May 27, 2014 at 3:25 PM, Ben Francis bfran...@mozilla.com wrote:
As per our conversation in IRC, something else I'd like to highlight is the
fact that in the current version of the spec any web site can host an app
manifest for any web app. That means for example that I could create my
On Wed, 28 May 2014, at 8:59, Jonas Sicking wrote:
On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres w...@marcosc.com wrote:
On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote:
On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
The only way that gmail would allow
On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri mou...@lamouri.fr wrote:
Then, it might make sense to have the manifest same origin as the web
page because obviously making start_url same origin as the manifest
would be moot if the manifest doesn't have to be same origin with the
web page ;)
On Wed, May 28, 2014 at 9:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
I don't understand this. That would you mean you'd have to modify the
content of Gmail to point to this manifest. That sounds bad.
To quote Marcos:
The only way one could do what you describe would be for my own app
On Wed, May 28, 2014 at 12:43 PM, Ben Francis bfran...@mozilla.com wrote:
This is the scenario I was describing. Allowing this to happen has both
benefits (easy to build huge app stores!) and risks (easy to build fake
apps).
That seems very confusing UI-wise. Also, this is the web, we don't
On Wednesday, May 28, 2014, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri
mou...@lamouri.frjavascript:;
wrote:
Then, it might make sense to have the manifest same origin as the web
page because obviously making start_url same origin as the
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338
Bug 24338 depends on bug 25081, which changed state.
Bug 25081 Summary: Make read operation really async
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081
What|Removed |Added
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081
Arun a...@mozilla.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25713
Arun a...@mozilla.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998
Arun a...@mozilla.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338
Bug 24338 depends on bug 24998, which changed state.
Bug 24998 Summary: What is the origin of a blob: URL?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998
What|Removed |Added
Great idea! If Intention Events (Clipboard, Selection, Command) cover all of
the editing operations that a site would want to handle themselves, we don’t
need CE Min as a feature, only a concept that can achieved with
preventDefault().
From: Julie Parent [mailto:jpar...@gmail.com]
Sent:
Be careful with having events fire before the DOM is updated—at a minimum
you’ll want to consider whether you will allow dangerous situations like the
legacy MutationEvents could cause (start a change - pre-change notification -
make another change - pre-change notification … unexpected things
But what is the default behaviour then? What will we be preventing?
There's no accepted specification for current contentEditable=true AFAIK,
so I thought that the goal of contentEditable=minimal is to avoid the need
to write a specification for contentEditable=true. Otherwise, developers
may
On May 22, 2014, at 4:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
Thanks, I'm convinced.
So now I'd like to know what policy we want so we can carefully define it.
The lastest editor’s draft of the File API specifies what we discussed in this
email thread as syntax for Blob URLs:
[ Bcc public-webapps; please Reply-to: www-dom]
Two bugs were raised against the May 1 LCWD of DOM Parsing and
Serialization [LC]. Travis created a tracking document for these Bugs
[Track] and considers the two patches ([P1] and [P2]) that address the
comments as non-substantive. As such, he
I don’t think we need to specify the default behavior. We can instead just say
that all editing behaviors must fire Intention events that are cancellable. Any
events that are already defined (like Clipboard) will continue to work, and
others should fire CommandEvents as necessary.
We will
23 matches
Mail list logo
