On Mon, Jul 27, 2009 at 9:51 PM, David Levinle...@chromium.org wrote:
It sounds like most of the concerns are about the 2nd part of this proposal:
allowing a background page to continue running after the visible page has
been closed.
However, the first part sounds like it alone would be useful
On Mon, Jul 27, 2009 at 5:53 PM, Maciej Stachowiakm...@apple.com wrote:
On Jul 27, 2009, at 6:42 PM, Robert O'Callahan wrote:
On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson m...@google.com wrote:
As mentioned in earlier discussions about persistent workers,
permissioning UI is a major
On Tue, 28 Jul 2009 02:39:46 +0200, Andrew Scherkus scher...@google.com
wrote:
On Sun, 12 Jul 2009, Philip Jägenstedt wrote:
Not that I except this discussion to go anywhere, but out of
curiosity I
checked how Firefox/Safari/Chrome actually implement canPlayType:
On Jul 27, 2009, at 10:51 PM, David Levin wrote:
It sounds like most of the concerns are about the 2nd part of this
proposal: allowing a background page to continue running after the
visible page has been closed.
However, the first part sounds like it alone would be useful to web
Manu Sporny wrote:
Cameron McCormack wrote:
Manu Sporny:
3. Running the Anolis post-processor on the newly modified spec.
Geoffrey Sneddon:
Is there any reason you use --allow-duplicate-dfns?
I think it’s because the source file includes the source for multiple
specs (HTML 5, Web Sockets,
On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiakm...@apple.com wrote:
On Jul 27, 2009, at 10:51 PM, David Levin wrote:
It sounds like most of the concerns are about the 2nd part of this proposal:
allowing a background page to continue running after the visible page has
been closed.
On Tue, Jul 28, 2009 at 3:02 AM, Jonas Sickingjo...@sicking.cc wrote:
Google Chrome (and I think other browsers) allow pages to be
installed as web applications which run in a separate window. It
would be interesting to look at the UI for that feature. However
installApp allows something even
Minimizing to the notification area is about the only thing, I think, that
we can't already do in a modern browser. If the page persists, it must be
visible (maybe with a user option to make it completely invisible). This
way, the user could at any time click the weblication and choose the
audio data, src and codecs testcases
looking for a reasonable middle ground, having read some of the
lengthy correspondence:
audio xmlns=http://www.w3.org/1999/xhtml;
data=hm.ogg
src=hm.mp3
controls=1 autoplay=1/
apologies if data and src might need swapping...
are there
On Tue, Jul 28, 2009 at 5:52 AM, Jonas Sickingjo...@sicking.cc wrote:
By the way, preserving duplicates shouldn't be much code complexity if
I'm not mistaken.
I take it you mean *removing* duplicates here, right?
Oops, yes.
The only required code change would be to use a hashset when
Michael Davidson wrote:
...
WHY NOT SHARED WORKERS
Shared workers and persistent workers are designed to solve similar
problems, but don't meet our needs. The key difference between what
we're proposing and earlier proposals for persistent workers is that
background pages would be able to
I've been kicking around some ideas in this area. One thing you could do
with persistent workers is restrict network access to the domain of that
worker if you were concerned about botnets. That doesn't address the I
installed something in my browser and now it's constantly sucking up my CPU
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilsonatwil...@google.com wrote:
I've been kicking around some ideas in this area. One thing you could do
with persistent workers is restrict network access to the domain of that
worker if you were concerned about botnets.
How would that work for
To clarify - I said that *persistent workers* could restrict x-domain
network access. I didn't mean to imply that you could apply this same
reasoning to hidden pages - I haven't thought about hidden pages enough to
comment about the implications of that, since as you mention there are many
more
On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidsonm...@google.com wrote:
Hello folks -
I'm an engineer on the Gmail team. We've been working on a prototype
with the Chrome team to make the Gmail experience better. We thought
we'd throw out our ideas to the list to get some feedback.
THE
On Mon, 13 Jul 2009, Christian Nygaard wrote:
What if one included hash sums of every binary file in html tags, plus
embedded hash sums in streaming file blocks, then the client would never
need to look at time stamps/expire headers to determine if it could
cache the objects. That would
2009/7/28 Jonas Sicking jo...@sicking.cc
The only concern I see with this is that it permanently forces all
windows from the same domain to run in the same process. As things
stand today, if the user opens two tabs (or windows) and navigates to
the two different pages on www.example.com,
could the botnet concern be addressed by restricting network access from the
background page when there is no foreground page referencing it? e.g.
restrict it to requests to the same origin, no matter how those requests are
made? wouldn't let gmail precache linked images, when fetching new mail,
On Mon, 13 Jul 2009, James Ide wrote:
Currently rel=canonical (
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html)
is not in the allowed set of link types listed at
http://www.whatwg.org/specs/web-apps/current-work/#linkTypes . Looking
back through archived
On Tue, 14 Jul 2009, Old�ich Vete�n�k wrote:
Dne Tue, 14 Jul 2009 02:52:22 +0200 Aryeh Gregor simetrical+...@gmail.com
napsal/-a:
On Mon, Jul 13, 2009 at 8:29 PM, Aen Tanhe...@aentan.com wrote:
I was specifically referring to the LEGEND element.
That seems to work less. WebKit just
On Mon, 13 Jul 2009, Boris Zbarsky wrote:
Ian just pointed out to me that his current draft requires
HTMLCollections to implement a tags() method (which seems to do a filter
by tagName on the contents of the collection).
As far as I can tell, IE, Webkit, and Opera implement this; Gecko
On Tue, Jul 28, 2009 at 2:23 PM, Adam de Booradeb...@google.com wrote:
2009/7/28 Jonas Sicking jo...@sicking.cc
The only concern I see with this is that it permanently forces all
windows from the same domain to run in the same process. As things
stand today, if the user opens two tabs (or
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson atwil...@google.com wrote:
So (and forgive me for restating), it seems like hidden page addresses the
following problems that gmail and other large web apps are having:
1) Loading large amounts of Javascript is slow, even from cache.
2) Loading
On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiakm...@apple.com wrote:
On Jul 27, 2009, at 10:51 PM, David Levin wrote:
It sounds like most of the concerns are about the 2nd part of this
proposal:
allowing a
On Tue, 14 Jul 2009, Jeremy Orlow wrote:
I think 'readyState' should just go away since an application will
have to keep track of state updates through the fired events and use
try/catch blocks around all API calls anyway.
The attribute is mostly present for debugging purposes. I
On Tue, 14 Jul 2009, Jonas Sicking wrote:
What does IE do in these two examples? It appears webkit treats the
first one as start=4 and the second as start=0.
In IE:
ol start= 2liTEST/ol = 2
ol start=+2liTEST/ol = 2
ol start=-2liTEST/ol = -2
ol start=H2liTEST/ol = 1
ol start=.2liTEST/ol = 1
On Tue, 14 Jul 2009, Robert O'Callahan wrote:
There's actually a fairly major related problem here. We hide the
fallback content by treating it as display:none. Currently Gecko has a
huge bug where a display:none plugin does not load/run. This works out
well for the video fallback case.
On Tue, Jul 28, 2009 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jul 2009, Jeremy Orlow wrote:
If it's only for debugging purposes, maybe a cleaner way to define it is
to simply be the last event fired on a given WebSocket?
I don't really understand what problem we would be
On Tue, 14 Jul 2009, Philip Jägenstedt wrote:
Ian: can you make nested video elements non-conforming so that
validators will flag it? This would be helpful regardless of the
fallback discussion.
Done.
--
Ian Hickson U+1047E)\._.,--,'``.fL
On Tue, Jul 28, 2009 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jul 2009, Jeremy Orlow wrote:
I think 'readyState' should just go away since an application will
have to keep track of state updates through the fired events and use
try/catch blocks around all API calls
On Tue, 14 Jul 2009, Honza Bambas wrote:
Target '_search' makes a link open in a sidebar (Opera) or sidebar-like
window (IE). For some offline web apps would be cool to open sidebar by
just one click. In other browsers (Firefox) web content could be open in
a sidebar only by creating a
On Tue, 14 Jul 2009, Simon Pieters wrote:
On Tue, 14 Jul 2009 07:44:25 +0200, Ian Hickson i...@hixie.ch wrote:
On Wed, 24 Jun 2009, Simon Pieters wrote:
The spec is now gaining all the remaining stuff from DOM2 HTML, so
this note is incorrect:
Note: The interfaces defined in
On Tue, 14 Jul 2009, Mike Shaver wrote:
On Tue, Jul 14, 2009 at 2:19 PM, Peter Kastingpkast...@google.com wrote:
It makes sense if you think about it -- whether YouTube sends videos encoded
as H.264 is irrelevant to what the _baseline_ codec for video needs to be,
it is only relevant as
On Tue, 14 Jul 2009, Philip J�genstedt wrote:
While implementing canPlayType I've found that Firefox/Safari/Chrome (and now
Opera) all have different error handling in parsing the MIME types. RFC
2045[1] gives the BNF form, but it appears that no browser gives much weight
to this.
Sample
On Tue, 14 Jul 2009, Aaron Whyte wrote:
Most apps provide different contents for the same uncacheable main-page
URL, depending on the identity of the user, which is typically stored in
a cookie and read by the server.
However, the HTML5 AppCache spec doesn't allow cookies to influence the
On Wed, 15 Jul 2009, Simon Pieters wrote:
[...] But it doesn't discuss error handling, just a weird case. Maybe
the section title should say error handling and edge cases or
something.
Done.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/
On Wed, 15 Jul 2009, Simon Pieters wrote:
I think it is now undefined what document.bgColor does when
document.body *is* a frameset.
Fixed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
On Wed, 15 Jul 2009, Joseph Pecoraro wrote:
It seems like an oversight that Javascript can read response headers off
of XHR but not for the current document. So in order to find out the
headers for the current document you would need to make another request,
refetching the current page,
the difficulty with a named-section option is that the manifest generation
for an application would have to know which users use a particular machine,
which is pretty much a non-starter.
a
On Tue, Jul 28, 2009 at 6:08 PM, Ian Hickson i...@hixie.ch wrote:
If the application code (HTML, JS, CSS)
one of the biggest use cases is for an app to understand whether its pages
are coming through a proxy. in theory this shouldn't be necessary, but in
practice it sometimes is. perhaps not a large enough use case to justify
adding the capability to the spec.
a
On Tue, Jul 28, 2009 at 6:21 PM, Ian
On Jul 28, 2009, at 9: 21PM, Ian Hickson wrote:
Use Cases:
Any that apply to XHR accessing their response headers would
certainly
apply here. Some thoughts are accessing the Content-Type header or
Custom Headers and acting accordingly.
You can just include the data straight into the page,
28.07.2009, в 16:40, Ian Hickson написал(а):
3) A Web Sockets server cannot respond with a redirect to another
URL.
I'm not sure if the intention is to leave this to implementations,
or to
add in Web Sockets v2, but it definitely looks like an important
feature
to me, maybe something
On Tue, 28 Jul 2009, Adam de Boor wrote:
the difficulty with a named-section option is that the manifest generation
for an application would have to know which users use a particular machine,
which is pretty much a non-starter.
I meant that each named appcache would have a separate manifest,
On Tue, 28 Jul 2009, Adam de Boor wrote:
one of the biggest use cases is for an app to understand whether its pages
are coming through a proxy. in theory this shouldn't be necessary, but in
practice it sometimes is. perhaps not a large enough use case to justify
adding the capability to the
On Tue, 28 Jul 2009, Joseph Pecoraro wrote:
I originally helped someone in an IRC channel with this question. He
wanted to check a Date header being sent from his server, via
Javascript. I don't know what his exact reason was. We provided him
the same solutions mentioned here.
Without
Sorry for starting and then dropping out of the discussion for a few days.
- I agree with everyone else that there are two parts to the proposal.
The first, less controversial part is a shared context that lives
inside of the browser. As Aaron points out, this is very similar to
Chromium
On Tue, Jul 28, 2009 at 4:19 PM, Michael Nordmanmicha...@google.com wrote:
What if a sharedContext isn't gauranteed to be a singleton in the browser. A
browser can provide best effort at co-locating pages and sharedContexts, but
it can't gaurantee that, and the spec respects that.
The lesser
On Tue, Jul 28, 2009 at 9:24 PM, Michael Davidson m...@google.com wrote:
These are true, but leave out the part that rewriting large apps to
the worker API is nontrivial. A major advantage of a hidden page (as
you mention below) is that the programming model is well known, and
easy for web
Michael Davidson wrote:
- As for persistence beyond browser lifetime, I understand the
reticence. However, similar problems have been solved in the past.
Flash asks the user for access to hardware like cameras. Surely being
able to take pictures of users is as scary as running code after the
On Tue, Jul 28, 2009 at 9:34 PM, Peter Kastingpkast...@google.com wrote:
Not at all. Malware can't set up a darknet using cameras. Your CPU, disk
and RAM are much more valuable to a malicious coder than your camera.
Personally, I'd rather have my CPU and RAM used to send spam than to
have
On Tue, Jul 28, 2009 at 8:57 PM, Alexey Proskuryakov a...@webkit.org wrote:
28.07.2009, в 16:40, Ian Hickson написал(а):
3) A Web Sockets server cannot respond with a redirect to another URL.
I'm not sure if the intention is to leave this to implementations, or to
add in Web Sockets v2,
On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson m...@google.com wrote:
Personally, I'd rather have my CPU and RAM used to send spam than to
have pictures of me in my underwear publicly placed on Facebook.
The rest of the world would rather not receive that spam, and would probably
rather we
On Tue, Jul 28, 2009 at 9:44 PM, Peter Kastingpkast...@google.com wrote:
On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson m...@google.com wrote:
Personally, I'd rather have my CPU and RAM used to send spam than to
have pictures of me in my underwear publicly placed on Facebook.
The rest of
Michael Davidson wrote:
I didn't realize this. So you think that everything on
addons.mozilla.org is vetted enough to not include malware?
We try... Note that given the extension model you don't have to put a
binary blob in the extension either, since extensions can make HTTP
requests and
On Tue, Jul 28, 2009 at 9:47 PM, Michael Davidson m...@google.com wrote:
I agree 100%. I'm only trying to argue that from a user perspective,
access that we currently have acceptable UI for, e.g. camera hardware,
is about as scary as agreeing to let a web app run in the background.
The whole
On Wed, Jul 29, 2009 at 4:47 PM, Michael Davidson m...@google.com wrote:
I agree 100%. I'm only trying to argue that from a user perspective,
access that we currently have acceptable UI for, e.g. camera hardware,
is about as scary as agreeing to let a web app run in the background.
The
It feels like this has become a discussion of which dangerous feature is
more dangerous
Several browsers (or browser like things) have mechanisms for allowing the
installation of potentially dangerous things.
For example, FireFox has the extension install mechanism. Google Chrome
has/must
On Jul 27, 2009, at 8:23 PM, Aryeh Gregor wrote:
On Mon, Jul 27, 2009 at 9:39 PM, Maciej Stachowiakm...@apple.com
wrote:
Persistent workers are even more of a security risk, since they are
supposed
to persist even after the browser has been restarted, or after the
system
has been
On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote:
I've been kicking around some ideas in this area. One thing you
could do with persistent workers is restrict network access to the
domain of that worker if you were concerned about botnets. That
doesn't address the I installed something in
59 matches
Mail list logo
