On Tue, 08 Jun 2010 21:26:12 +0200, Atul Varma wrote:
For what it's worth, I think that giving developers tools to easily
define more granular security mechanisms without resorting to subdomains
is a win in terms of usability, as it's quite difficult to figure out
how to create subdomains and do
On Tue, Jun 8, 2010 at 1:17 PM, Adam Barth wrote:
> Yes, doing this correctly is quite subtle. I'd pitch the feature more
> as developer connivence rather than for security. Apps that are
> hosted in the same origin need to trust each other.
That is what we were planning on.
- a
On Tue, Jun 8, 2010 at 12:26 PM, Atul Varma wrote:
> On 6/8/10 10:47 AM, Adam Barth wrote:
> On Tue, Jun 8, 2010 at 4:17 AM, Henri Sivonen wrote:
> "Aaron Boodman (劉)" wrote:
> If we add paths to the mix, we can do this. Applications on the same
> origin can circumvent it if they want, but why w
On 6/8/10 10:47 AM, Adam Barth wrote:
On Tue, Jun 8, 2010 at 4:17 AM, Henri Sivonen wrote:
"Aaron Boodman (劉)" wrote:
If we add paths to the mix, we can do this. Applications on the same
origin can circumvent it if they want, but why would they? SOP
already
guarantees that apps on the same o
On Tue, Jun 8, 2010 at 4:17 AM, Henri Sivonen wrote:
> "Aaron Boodman (劉)" wrote:
>> If we add paths to the mix, we can do this. Applications on the same
>> origin can circumvent it if they want, but why would they? SOP
>> already
>> guarantees that apps on the same origin are friendly and cooper
I can't remember any discussion (and searching my email returns no
results), The idea seems interesting and useful.
Have you thought about how it will work on mobile platforms (will the
touch screen act as the "pad"?).
I'm guessing that the browser could save an image of the coordinates
plotted t
Has there been prior discussion about an input type="ink" form element?
This element would simply capture coordinates from a mouse (or touch/pen
input device),
allowing the user to reset the value of the element at their discretion.
InkML is in last call:
http://www.w3.org/TR/InkML/
We could
> My understanding of the proposal is that given this particular control, the
> browser would provide an interface for either selecting a local file or
> entering a URL. If a file is selected, the file is uploaded as normal,
> equivalent to .
>
> Otherwise, if a URL is entered, the field is instea
On Tue, 2010-06-08 at 11:13 -0400, Mike Shaver wrote:
> On Tue, Jun 8, 2010 at 11:02 AM, Ashley Sheridan
> wrote:
>
> Yes, and the rest of my email said that.
>
>
> Sorry, I am not familiar with KIO, and didn't see the need for OS
> support.
>
> KIO slaves on KDE work
On Tue, Jun 8, 2010 at 11:02 AM, Ashley Sheridan
wrote:
> Yes, and the rest of my email said that.
>
Sorry, I am not familiar with KIO, and didn't see the need for OS support.
> KIO slaves on KDE work just like that. It's not something that I think a
> user agent can easily just add in, but so
On Tue, 2010-06-08 at 10:58 -0400, Mike Shaver wrote:
> On Tue, Jun 8, 2010 at 10:47 AM, Ashley Sheridan
> wrote:
>
>
> On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton
> wrote:
>
> > Are you wanting the user to manually enter the filename, inclu
On 2010-06-08 16:37, Simpson, Grant Leyton wrote:
Are you wanting the user to manually enter the filename, including
the file:// scheme? If not, are you envisioning the file dialog box
to provide a choice between selecting local files and entering an
http/ftp url?
My understanding of the propos
On Tue, Jun 8, 2010 at 10:47 AM, Ashley Sheridan
wrote:
> On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton wrote:
>
> Are you wanting the user to manually enter the filename, including the
> file:// scheme? If not, are you envisioning the file dialog box to provide a
> choice between se
O.K. Just wanted to clarify. With this sort of dialog in mind, I like your
proposal. (I find it unrealistic to think that the average user would write out
"file://..." but maybe I am mistaken.)
However, I see one possible issue. Some apps provide the means to work with
local files, URLs, and d
On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton wrote:
> Are you wanting the user to manually enter the filename, including the
> file:// scheme? If not, are you envisioning the file dialog box to provide a
> choice between selecting local files and entering an http/ftp url?
>
> On Jun
On Tue, Jun 8, 2010 at 5:37 PM, Simpson, Grant Leyton
wrote:
> Are you wanting the user to manually enter the filename, including the
> file:// scheme? If not, are you envisioning the file dialog box to provide a
> choice between selecting local files and entering an http/ftp url?
>
> On Jun 8,
Are you wanting the user to manually enter the filename, including the file://
scheme? If not, are you envisioning the file dialog box to provide a choice
between selecting local files and entering an http/ftp url?
On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:
> It would then be the server's
A lot of websites let you upload either from a file on your hard drive
or from a link on the web.
Most of the time this is done by having two different inputs: One for
a file and the other for a URL.
If there were some type of input like "upload' which will allow for
any complete input.
Something
Hi,
According to the HTML5 specification, an IDL attribute reflecting an
enumerated attribute will have the default reflecting behavior (ie.
return the content attribute on getting and setting it on setting)
except if the attribute is "limited to only known values" [1]. There are
three attributes
"Aaron Boodman (劉)" wrote:
> Every crx file is signed. The signature and public key are part of
> the
> zip file itself, just after the signature. The zip format allows
> extra
> data there. When you took apart those crx files, if you used 'unzip'
> from the command line, you may have seen 'Ignor
20 matches
Mail list logo
