date:20090728

On Tue, Jul 28, 2009 at 9:44 PM, Peter Kasting wrote:
> On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson  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 didn't write systems enabling it on massive scales.

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 consequences of a malicious app that gets either permission are
dire.

Michael

Re: [whatwg] Installed Apps

On Tue, Jul 28, 2009 at 9:38 PM, Boris Zbarsky wrote:
> I don't think it is, no.  Taking a picture is a one-time activity; the user
> knows exactly what he's getting into.  And once the picture is taken, no
> more picture-taking until the user says so explicitly.

FYI, this is not the case. Flash camera control is per-site, not
per-use. (Gmail video chat does not request permission to use the
camera every time you do a chat.)

> Note that you could write a Firefox extension that outlives the browser
> today.  Just include a binary component that starts a separate process.

I didn't realize this. So you think that everything on
addons.mozilla.org is vetted enough to not include malware? Do you
think the existing FF install dialog gives enough warning that an
extension could outlive the browser process? A whitelist of domains
that are allowed to install apps without scary permission dialogs
would be okay with me. Vendors could decide whether mail.google.com is
trustworthy or not.

> Really, it sounds like you want something more akin to a Prism app [1] than
> anything else.  You don't _actually_ want to run gmail in a browser window.
>  You just want to deliver it over http:// and leverage a browser-like thing
> on the other end for rendering it, right?

We'd like to not have to maintain two Gmail codebases, one for
installed usage and one for everyone else. Ideally the same code can
be used in an internet cafe and on the machine of someone who agrees
to install Gmail as an app. Prism might be similar to what we'd like.

Michael

Re: [whatwg] Installed Apps

2009-07-28 Thread Peter Kasting

On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson  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 didn't write systems enabling it on massive scales.

PK

Re: [whatwg] Issues with Web Sockets API

2009-07-28 Thread Jeremy Orlow

On Tue, Jul 28, 2009 at 8:57 PM, Alexey Proskuryakov  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, but it definitely looks like an important feature
>>> to me, maybe something that needs to be in v1.
>>>
>>
>> What's the use case? Why does this need to be at the connection layer
>> rather than the application layer? (Why would we need this, when TCP
>> doesn't have it? Would you also need "redirect"-like functonality in IRC,
>> IMAP, SSH, and other such protocols?)
>>
>
> Just like with HTTP, redirects will make it possible to move services to a
> different location. I guess the use cases are exactly the same that tell us
> that we should allow redirects with cross-site XMLHttpRequest (but I can't
> enumerate those).
>
> Other protocols do not get accessed from Web pages, so transparent redirect
> support is not needed to keep web apps working after services they use move.
> The Web has redirects all over the place, and WebSocket has "Web" in its
> name :)
>
> Finally, since it's likely that WebSocket servers will share ports with
> HTTP ones, one can expect that returning a 307 for all requests (including
> those with Upgrade: WebSocket) will be enough to preserve application
> functionality.
>
> Redirects surely add a lot of complexity though.


They can be implemented at the application layer though, right?  I suppose
this does add complexity, but it doesn't seem like it'd add _that_ much.
 Especially if you're already doing authentication at the application level
as well.

I definitely agree these are good items for v2, but I think what's already
in the spec is a good start.

Re: [whatwg] Installed Apps

On Tue, Jul 28, 2009 at 9:34 PM, Peter Kasting 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 pictures of me in my underwear publicly placed on Facebook. I
suspect I'm not alone among the general internet-using population. ;)

What do you think about the idea of making a web app install have the
same look-and-feel as a native app install?

Michael

Re: [whatwg] Installed Apps

2009-07-28 Thread Boris Zbarsky


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
browser has closed.


I don't think it is, no.  Taking a picture is a one-time activity; the 
user knows exactly what he's getting into.  And once the picture is 
taken, no more picture-taking until the user says so explicitly.


I, personally, would be hard-pressed to describe the 
persistence-beyond-browser-lifetime issue to a typical user in a way 
that would allow him to make an informed decision on it.


Heck, I would be hard-pressed to explain it via a browser dialog or the 
like even to a very intelligent user who happens to not be intimately 
familiar with the way their computer and the internet happen to work. I 
could do it in 10-15 minutes of in-person conversation, probably.  Or 
several typed sheets of paper worth of text...



For browsers that do have extensions, having the
extension outlive the visible browser process doesn't seem like that
great a leap in functionality.


While this is true, extensions (at least in Firefox) are installed with 
the following user-facing caveats:


1)  You have to explicitly opt-in to the install source, unless it's
addons.mozilla.org.
2)  You are told that extensions can do anything they want to.

Item 1 above is very important.

Note that you could write a Firefox extension that outlives the browser 
today.  Just include a binary component that starts a separate process.



Perhaps the install UI could look and feel more
like the UI for installing a native app?


Really, it sounds like you want something more akin to a Prism app [1] 
than anything else.  You don't _actually_ want to run gmail in a browser 
window.  You just want to deliver it over http:// and leverage a 
browser-like thing on the other end for rendering it, right?


-Boris

[1] http://prism.mozilla.com/

Re: [whatwg] Installed Apps

2009-07-28 Thread Peter Kasting

On Tue, Jul 28, 2009 at 9:24 PM, Michael Davidson  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 developers to adapt to.

I don't know enough about this specific case to comment, but in general I am
scared of arguments like "Model A would be better, but right now people are
using something closer to model B" because it can enshrine for all eternity
something that browsers have to support, based on what people happen to be
good at at the moment.

- 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
> browser has closed.

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.

The rest of your argument may still be true, I'm just not convinced by this
analogy.

PK

Re: [whatwg] Installed Apps

On Tue, Jul 28, 2009 at 4:19 PM, Michael Nordman 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 gaurantee is that all directly scriptable pages (those from a
> given set of related browsing contexts) WILL share the same sharedContext
> (should the refer to it).

Best effort seems reasonable to me. Also, many large web apps
(including Gmail) don't allow themselves to run in an iframe, which
makes the problem much simpler. Only toplevel pages of the same domain
need to be in the same process.

Michael

Re: [whatwg] Installed Apps

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 extensions, and shouldn't require user permission beyond that
of extensions today. Extensions live as long as the browser, so
whatever UI browsers use for extensions should be sufficient.

On Tue, Jul 28, 2009 at 10:01 AM, Drew Wilson wrote:
> 1) Loading large amounts of Javascript is slow, even from cache.
> 2) Loading application state from the database is slow.
> 3) Sharing between pages requires going through the database or shared
> worker - you can't just party on a big shared datastructure.

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 developers to adapt to.

If your app is big enough to need the advantage of a shared page, a
user install doesn't seem too big a hoop to jump through.

- 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
browser has closed. For browsers that do have extensions, having the
extension outlive the visible browser process doesn't seem like that
great a leap in functionality. We could definitely live with
same-domain restrictions in hidden pages if it would allay some
concerns. Having some sort of desktop presence is important for parity
with desktop apps. Perhaps the install UI could look and feel more
like the UI for installing a native app?

Michael

Re: [whatwg] Access the Response Headers for the Current Document

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 knowing why he wanted that, it's hard to say what the right 
solution is.

> However, like Adam de Boor suggested, a use case could be detecting 
> proxies.

It's not clear to me why you would need to know that.

> The use case that I thought of was using custom headers to ensure 
> requests go to a certain server in a cluster, perhaps to maintain a 
> session with a reasonable cache.  But that isn't really compelling and 
> probably not very common.

That would be a use case for setting headers (not reading them). I'm not 
sure how that would work, really. There are many ways that pages get 
fetched, and it's not clear that we want to allow pages to affect future 
page loads... it's quite a complex can of worms I'd rather not open 
without a _really_ clear use case that can't be done any other way.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Access the Response Headers for the Current Document

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 spec.

When is it necessary?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] AppCache can't serve different contents for different users at the same URL

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, and the 
manifest would just say the name of the one it was setting up.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Issues with Web Sockets API

2009-07-28 Thread Alexey Proskuryakov



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 that needs to be in v1.


What's the use case? Why does this need to be at the connection layer
rather than the application layer? (Why would we need this, when TCP
doesn't have it? Would you also need "redirect"-like functonality in  
IRC,

IMAP, SSH, and other such protocols?)


Just like with HTTP, redirects will make it possible to move services  
to a different location. I guess the use cases are exactly the same  
that tell us that we should allow redirects with cross-site  
XMLHttpRequest (but I can't enumerate those).


Other protocols do not get accessed from Web pages, so transparent  
redirect support is not needed to keep web apps working after services  
they use move. The Web has redirects all over the place, and WebSocket  
has "Web" in its name :)


Finally, since it's likely that WebSocket servers will share ports  
with HTTP ones, one can expect that returning a 307 for all requests  
(including those with Upgrade: WebSocket) will be enough to preserve  
application functionality.


Redirects surely add a lot of complexity though.

10) Web Socket handshake uses CRLF line endings strictly. Does this  
add
much to security? It prevents using telnet/netcat for debugging,  
which
is something I personally use often when working on networking  
issues.


If there is no practical reason for this, I'd suggest relaxing this
aspect of parsing.


Do you mean client->server or server->client?


Originally, I meant both, but now I've been told that telnet on Mac OS  
X translates line breaks to CRLF by default (even though it's not  
telnet's own default, according to man page). Netcat doesn't perform  
such translation, so simulating a server with netcat won't work unless  
plain CR is allowed.


Other platforms and tools commonly used for HTTP debugging may have  
different defaults and limitations. This is not a huge deal, of course.


11) There is no way for the client to know that the connection has  
been

closed. For example:
- socket.close() is called from JavaScript;
- onclose handler is invoked;
- more data arrives from the server, and onmessage is dispatched  
(which I

think is correct, and it matches what TCP does);
- finally, a TCP FIN arrives, indicating that there will be no more  
data from
the server (the underlying TCP connection is in TIME_WAIT state  
after that);

- the client never learns that the server is done sending data.


The onclose only fires once the connection has closed, which is  
after the

TCP FIN, so it happens after the last 'message' event.


Maybe this could be clarified in the spec. The current text is:

"The close() method must close the Web Socket connection or connection  
attempt, if any. If the connection is already closed, it must do  
nothing. Closing the connection causes a close event to be fired and  
the readyState attribute's value to change, as described below."


I was reading it as a requirement to immediately change readyState to  
CLOSED, and to fire a close event. If all this happens asynchronously  
after the server agrees to close the connection, then my example will  
work fine, of course.


- WBR, Alexey Proskuryakov

Re: [whatwg] Access the Response Headers for the Current Document

2009-07-28 Thread Joseph Pecoraro


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, for now. It's  
really

clear what the use cases would actually be in practice.


True, but that feels like a hack. If the HTTP protocol contains the  
data you need, then a server-side script may try to provide the data  
and may possibly provide an incorrect value. Likewise at the very  
least its a duplication of data being sent.  This is certainly better  
then the current method, but not optimal.



Come up with a clear description of the problem that needs to be  
solved:

Cannot access the Response Headers for the current document in
Javascript.

Any there Browser Implementors out there that agree with this?  If  
so,

any thoughts on the best ways to expose the current page's request
headers to Javascript?  Certainly they are readonly, modifying them
seems to be useless. How about keeping consistent with the XHR  
interface

with something like:

 document.getAllResponseHeaders() and  
document.getResponseHeader(header)


This is something that might make sense for a future version, but in  
the
absence of a compelling need for this, I'm going to skip adding this  
in

this version.


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.


However,  like Adam de Boor suggested, a use case could be detecting  
proxies.  The use case that I thought of was using custom headers to  
ensure requests go to a certain server in a cluster, perhaps to  
maintain a session with a reasonable cache.  But that isn't really  
compelling and probably not very common.

Re: [whatwg] Access the Response Headers for the Current Document

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 Hickson  wrote:

> 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, to find that out [1].
> >
> > 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, for now. It's really
> clear what the use cases would actually be in practice.
>
>
> > Come up with a clear description of the problem that needs to be solved:
> > Cannot access the Response Headers for the current document in
> > Javascript.
> >
> > Any there Browser Implementors out there that agree with this?  If so,
> > any thoughts on the best ways to expose the current page's request
> > headers to Javascript?  Certainly they are readonly, modifying them
> > seems to be useless. How about keeping consistent with the XHR interface
> > with something like:
> >
> >   document.getAllResponseHeaders() and document.getResponseHeader(header)
>
> This is something that might make sense for a future version, but in the
> absence of a compelling need for this, I'm going to skip adding this in
> this version.
>
> Cheers,
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
Adam de Boor

Google

Re: [whatwg] AppCache can't serve different contents for different users at the same URL

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  wrote:

> If the application code (HTML, JS, CSS) is all the same for two users,
> then appcache works for multiple users by just having the data for the
> users separate from the logic.
>
> This is the expected model for most apps. For example, your typical blog
> has just one set of CSS for all users.
>
> For systems where the user affects what HTML, JS, and CSS is served back,
> the spec as written pretty much requires that there be one app per user,
> and one generic "login" app that then redirects to one of those other apps
> -- and where each app has a different base URL, separate manifest, etc.
>
> I think conceptually that's actually not a bad idea anyway, to be honest.
> However, I could see that it might not be the preferred model.
>
> An alternative that we could explore in a future version is to have the
> manifest include a manifest name, and then have script that allows you to
> "activate" a particular manifest name for a given appcache.
>
> So each appcache group would be futher subdivided into named subgroups,
> and for a given manifest URL with such a group of subgroups, one subgroup
> would be the default one at a time. The inactive ones would just lie
> dormant, but and the active ones would act like now, but there'd be a
> scripted way to change the default (and maybe query what available
> variants exist for the current appcache), so that you could log back in as
> someone else by just making the script pick the other user's variant, and
> then reloading.
>
> I've noted this in the spec as a possible v2 feature.
>
>

Re: [whatwg] Access the Response Headers for the Current Document

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, to find that out [1].
> 
> 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, for now. It's really 
clear what the use cases would actually be in practice.


> Come up with a clear description of the problem that needs to be solved: 
> Cannot access the Response Headers for the current document in 
> Javascript.
> 
> Any there Browser Implementors out there that agree with this?  If so, 
> any thoughts on the best ways to expose the current page's request 
> headers to Javascript?  Certainly they are readonly, modifying them 
> seems to be useless. How about keeping consistent with the XHR interface 
> with something like:
> 
>   document.getAllResponseHeaders() and document.getResponseHeader(header)

This is something that might make sense for a future version, but in the 
absence of a compelling need for this, I'm going to skip adding this in 
this version.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] r3416 - [] (0) Define that document.bgcolor et al don't reflect for .

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/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] r3411 - [e] (0) Add an example of a script moving nodes the parser is parsing.

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/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] AppCache can't serve different contents for different users at the same URL

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 
> choice of AppCaches or the contents of a response returned by the cache.
> 
> This makes it a lot harder, but not impossible, for developers of 
> existing apps to start using AppCache, while still supporting multiple 
> users per browser or browser profile.
> 
> Without changing the user-visible URL structure of an app, developers might
> support multiple users, by replacing their server-generated user-specific
> main page, with a generic cacheable JS app that does this:
>
> 1) Establish the user's identity using a cookie, or a database record, 
> or a session key-value store.
>
> 2) If the user can be identified, load the user-specific resources (JS, 
> CSS, data, etc.) from the network and/or local storage, possibly 
> including a separate AppCache with user-specific or fingerprint-specific 
> URLs. Otherwise, load the unknown-user version or a login page.
> 
> That'd be a complete restructuring of the main page, but it's possible.  
> I suspect that this is the model the AppCache was designed to support.
> 
> A more radical change to existing apps, and app design in general, would 
> be to include account-identifying information in the user-visible URL.  
> The main page could redirect users to their user-specific page or the 
> unknown-user page.

On Tue, 14 Jul 2009, Adam de Boor wrote:
>
> I guess in the double-AppCache model, where there's a generic cached 
> redirect page, one could make it so all user-specific accesses use a URL 
> with a user-specific prefix, so it can prefix-match against an entry in 
> the NETWORK section of the generic cached app manifest.
>
> still, given how many apps on the web identify the user using an ID in a 
> cookie, it'd be nice if apps wanting to use AppCache didn't have to go 
> through these gyrations.

On Wed, 22 Jul 2009, Anne van Kesteren wrote:
> 
> Why not? I cannot find anything like that in the specification. It seems 
> to me that the generic fetching algorithm is used which does not forbid 
> sending cookies and even explicitly calls out setting them.

On Wed, 22 Jul 2009, Drew Wilson wrote:
>
> Not sure what you are suggesting, Anne - it sounds like they want to tie 
> the AppCache to a specific cookie/value combination, which I don't 
> believe is supported by the current spec.

On Wed, 22 Jul 2009, Anne van Kesteren wrote:
> 
> Well, as far as I can tell cookies are part of the request to the 
> manifest file so you could serve up a different one from the server 
> based on cookie data.
> 
> Is the problem supporting multiple users completely client-side? I can 
> see how that might not work very well.

On Wed, 22 Jul 2009, Drew Wilson wrote:
> 
> That's an interesting idea (send down a different manifest), although I 
> don't see how you'd leverage that technique to support two different 
> users/manifests and use the appropriate app cache depending on which 
> user is logged in.
> 
> I think this boils down to "the Gears 'requiredCookie' attribute was 
> really useful".

On Wed, 22 Jul 2009, Aaron Whyte wrote:
>
> Imagine two users of fancyapp.com, with their own logins and data and 
> custom skins and whatnot.  The contents of the main page are uncacheable 
> and are totally different depending on the cookies in the request, which 
> tell the server who is logged in.  This is the way nearly every web app 
> works today, and this is also the way a lot of people share a single 
> computer.
> 
> Without any offline support, they can share one browser, if one logs out 
> of fancyapp, and the other logs in.
> 
> If fancyapp supports offline use with Gears, then one of the users can 
> install an offline client, without affecting the other user, because of 
> requiredCookie.
> 
> But if fancyapp supports offline use with HTML5's app cache, then if one 
> user installs an offline client, fancyapp will keep working for that 
> user, but not for the other user, who will have to go get their own 
> computer, browser, profile, or whatever they need to avoid hitting the 
> other user's app cache.
> 
> The engineers at fancyapp could rewrite their mail page so it's just a 
> little router that looks at cookies and makes subsequent requests to 
> user-specific URLs to really load the app.  But that's an inferior user 
> experience, because it introduces an extra round trip to get the initial 
> page properly rendered.  So they'll probably have to support both.

If the application code (HTML, JS, CSS) is all the same for two users, 
then appcache works for multiple users by just having the data for the 
users separate from the logic.

This is the expected model for most apps. For example, your typical blog 
has just one set of CSS for all users.

For systems whe

Re: [whatwg] Error handling for MIME type parsing (canPlayType)

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 of quirks:
> 
> (Ignore "no" vs "" here, it's not relevant)
> 
> Firefox:
> 
> AUDIO/X-WAV: "no"
> audio/x-wav codecs: "maybe"
> audio/x-wav; codecs=: "probably"
> audio/x-wav; codecs=,: "no"
> 
> Safari:
> 
> AUDIO/X-WAV: "no"
> audio/x-wav codecs: "no"
> audio/x-wav; codecs=: "probably"
> audio/x-wav; codecs=,: "maybe"
> 
> Opera internal:
> 
> AUDIO/X-WAV: ""
> audio/x-wav codecs: ""
> audio/x-wav; codecs=: "maybe"
> audio/x-wav; codecs=,: "maybe"
> 
> Chrome ignores codecs, so I can't get meaningful results.
> 
> I believe the correct answers are:
> 
> AUDIO/X-WAV: same as for audio/x-wav (by RFC 2045, but we could ignore it
> because it looks ugly)
> audio/x-wav codecs: the same as audio/x-unknown-type (i.e. "no" for Firefox)
> audio/x-wav; codecs=: same as audio/x-wav (unless we want this to mean "no
> codecs", in which case "no" would be more appropriate)
> audio/x-wav; codecs=,: same as audio/x-wav (i.e. ignore broken codecs
> parameter)
> 
> Has there been any work done on defining error handling for Content-Type 
> parsing or the like? It wouldn't be fun to get cross-browser bugs as 
> soon as someone forgets a semicolon...

On Wed, 15 Jul 2009, Robert O'Callahan wrote:
> 
> In Firefox I just reused our existing MIME type parser. I'm not sure how
> tightly that parser is constrained by Web compatibility quirks issues.
> 
> audio/x-wav codecs: the same as audio/x-unknown-type (i.e. "no" for Firefox)
> 
> 
> Yes, that seems like a bug.
> 
> audio/x-wav; codecs=: same as audio/x-wav (unless we want this to mean "no
> > codecs", in which case "no" would be more appropriate)
> 
> 
> I interpret this as "no codecs". In that case, "probably" is correct, since
> we support every codec in the list.
> 
> audio/x-wav; codecs=,: same as audio/x-wav (i.e. ignore broken codecs
> > parameter)
> 
> 
> I interpret this as two codecs, both whose name is the empty string. We
> don't support that codec.
> 
> Has there been any work done on defining error handling for Content-Type
> > parsing or the like?
> 
> 
> That's a very good question, but I don't know the answer.

HTML5 has some rules for parsing Content-Type that are designed for 
particular cases where it is constrained, but I don't think this is such a 
case. I would recommend asking the relevant working group (HTTP?) for 
guidance on how to parse these headers when they have bogus values.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Codecs for and

On Tue, 14 Jul 2009, Mike Shaver wrote:
> On Tue, Jul 14, 2009 at 2:19 PM, Peter Kasting 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  needs to be,
> > it is only relevant as additional info for vendors deciding whether to
> > support H.264.
> 
> Yes, I concur --  I couldn't think of any reason for that to be
> relevant to the discussion of baseline codecs at first, so I tried to
> make it fit (and asked questions about the details of it).
> 
> I will patiently await the details. :-)

It wasn't directly relevant, I was just listing what I knew about the 
landscape. The only truly relevant point is that Apple isn't implementing 
Theora, at this point (and Microsoft don't have any  support at 
all). Since Mozilla, Opera, and Google all do Theora, if Apple (or 
Microsoft) implemented Theora, then there'd be enough of a critical mass 
to make it the baseline codec. As it stands, it's more of an even split 
than I feel confortable with in terms of making the spec take a stand.

Anyway, I don't want to respark this thread, since no new information is 
forthcoming at this point. I hear Apple are studying this in more detail 
again; maybe they will change their mind. We'll see.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] hasFeature() When Only 1 Syntax is Supported

On Tue, 14 Jul 2009, Simon Pieters wrote:
> On Tue, 14 Jul 2009 07:44:25 +0200, Ian Hickson  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 this specification are not always 
> > > supersets of the interfaces defined in DOM2 HTML; some features that 
> > > were formerly deprecated, poorly supported, rarely used or 
> > > considered unnecessary have been removed. Therefore it is not 
> > > guaranteed that an implementation that supports "HTML" "5.0" also 
> > > supports "HTML" "2.0"."
> > > 
> > > I'm thinking that the spec should maybe just use "2.0" instead of 
> > > "5.0", since it's what browsers do and there might be pages that 
> > > check for this.
> > > 
> > > Meanwhile it seems useful to return false as appropriate if the UA 
> > > only allows one of the syntaxes, as Smylers points out.
> > 
> > I've removed everything but HTML/2.0.
> 
> I'm pretty sure Web compat requires HTML/1.0 to return true, too.

Good point, added that one too.


> Gecko, WebKit and Opera return true for XHTML/2.0. WebKit and Opera also 
> return true for XHTML/1.0. I don't know what the Web compat situation is 
> with the XHTML values.

I've added these, but would be very willing to drop any that end up only 
supported in at most one browser.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] r3306 - [] (0) Define interaction with CSS case-sensitivity rules.

On Tue, 14 Jul 2009, Simon Pieters wrote:
> On Tue, 14 Jul 2009 08:26:37 +0200, Ian Hickson  wrote:
> > > and presumably the new attributes in HTML5: [...]
> > 
> > Why would we want to add anything to this list?
> > 
> > I'd rather keep this list as small as possible.
> 
> Hmm. In that case maybe we can remove it altogether? I think it was only 
> implemented for compliance with CSS2 and HTML4 when Niels Leenheer wrote 
> a Selectors test suite back in 2006.

On Wed, 22 Jul 2009, Anne van Kesteren wrote:
> 
> Yeah, and IE7 did not support this. Killing this useless list seems like 
> the best way forward. As far as I know there is no compatibility reason 
> for having it other than that test suite and having it be an arbitrary 
> number of attributes is just confusing and slightly increases code 
> complexity and testing.

I'm willing to remove it if the browsers drop support for it.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Should target '_search' be taken as part of HTML 5 spec?

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 bookmark, marking it as to open in a 
> sidebar, use (click) that bookmark.
> 
> So, there are tendencies and voices to open web content in a sidebar in 
> all browsers but it is not taken as a standard. I would really like this 
> feature to be available in all browsers.

HTML5 supports this use case using rel=sidebar.


On Tue, 14 Jul 2009, Gavin Sharp wrote:
> 
> Firefox used to have this behavior, but it was accidentally broken prior 
> to 3.0 (opened a new tab instead). We then removed it in 3.0.2 because 
> only one person had noticed the change in behavior, and it didn't seem 
> worth the code complexity or maintenance cost.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=438526 has more details. 
> Comment 7 in that bug implies that IE 7 only supports if you enable a 
> non-default preference option.

I haven't added target=_search since it does not seem browser vendors want 
to implement it.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Issues with Web Sockets API

2009-07-28 Thread Michael Nordman

On Tue, Jul 28, 2009 at 4:40 PM, Ian Hickson  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 anyway.
> > >
> > > The attribute is mostly present for debugging purposes. I wouldn't
> > > expect anyone to actually use it for production work.
> >
> > Is there precedent for other portions of the API that are mostly for
> > debugging purposes?  (I can't think of anything off the top of my head.)
>
> readyState on Document and  aren't realy useful for anything but
> debugging either, as far as I can tell.
>
>
> > Also, maybe it should be noted as such in the spec?
>
> I don't really see much benefit to including such a statement; if someone
> wants to use it for a non-debugging reason, why not do so?
>
>
> > 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 trying to solve by
> changing that.
>
>
> > One other random question:  in the IDL for WebSockets, the three
> > constants for ready state are all defined as shorts but the value of
> > ready state is a long.  Is this an oversight?
>
> Fixed.
>
>
> On Mon, 27 Jul 2009, Alexey Proskuryakov wrote:
> >
> > I agree with Michael that send() should not silently drop data that
> > could not be sent. It is very easy to fill send buffers, and if bytes
> > get silently dropped, implementing app-level acks becomes quite
> > difficult.
>
> I've made it clear that if bytes can't be sent, the connection must be
> closed.
>
>
> > However, I do not think that raising an exception is an appropriate
> > answer. Often, the TCP implementation takes a part of data given to it,
> > and asks to resubmit the rest later. So, just returning an integer
> > result from send() would be best in my opinion.
>
> I think we are best off abstracting away this level of complexity from
> authors, especially since we'd need to make sure that data was not sent
> half-way through a UTF-8 sequence, and since the framing is under the
> control of the UA, not the application. There's no way to retry a
> partially-successful send() from the API here.
>
>
> > 1) Web Sockets is specified to send whatever authentication credentials
> > the client has for the resource. However, there is no challenge-response
> > sequence specified, which seems to prevent using common auth schemes.
> > HTTP Basic needs to know an authentication realm for the credentials,
> > and other schemes need a cryptographic challenge (e.g. nonce for Digest
> > auth).
>
> I expect to address this in more detail in a future version. For now, use
> in-band authentication in the WebSocket once you are connected. We may
> find that that is actually enough.
>
>
> > 2) It is not specified what the server does when credentials are
> > incorrect, so I assume that the intended behavior is to close the
> > connection. Unlike HTTP 401 response, this doesn't give the client a
> > chance to ask the user again. Also, if the server is on a different
> > host, especially one that's not shared with an HTTP server, there isn't
> > a way to obtain credentials, in the first place.
>
> How we address this will likely depend on how we address the earlier
> point.
>
>
> > 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 that needs to be in v1.
>
> What's the use case? Why does this need to be at the connection layer
> rather than the application layer? (Why would we need this, when TCP
> doesn't have it? Would you also need "redirect"-like functonality in IRC,
> IMAP, SSH, and other such protocols?)
>
>
> > 4) "If the user agent already has a Web Socket connection to the remote
> > host identified by /host/ (even if known by another name), wait until
> > that connection has been established or for that connection to have
> > failed."
> >
> > It doesn't look like "host identified by /host/" is defined anywhere.
> > Does this requirement say that IP addresses should be compared, instead
> > of host names?
>
> Right. I've tried to clarify this.
>
>
> > I'm not sure if this is significant for preventing DoS attacks, and
> > anyway, the IP address may not be known before a request is sent. This
> > puts an unusual burden on the implementation.
>
> Without this requirement, you can just have a DNS server return the victim
> IP for a wildcard DNS entry, and then just have attackers open connections
> to thousands of "hosts".
>
>
> > 5) We probably need to specify a keep-alive feature to avoid proxy
> > connection timeout. I do not have factual data on whether common proxies
> > implement connection timeout, but I'd expect t

Re: [whatwg] HTML 5 video tag questions

On Tue, 14 Jul 2009, Philip Jägenstedt wrote:
> 
> Ian: can you make nested  elements non-conforming so that 
> validators will flag it? This would be helpful regardless of the 
> fallback discussion.

Done.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Issues with Web Sockets API

2009-07-28 Thread Jeremy Orlow

On Tue, Jul 28, 2009 at 4:40 PM, Ian Hickson  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 trying to solve by
> changing that.

I was just suggesting that perhaps the model could be simplified and that
this might make it less confusing to web and UA developers.  I haven't
studied this issue in detail though, so if you think it's a silly idea,
there's a good chance it is.

As for the rest of your changes, I think they should work well.

Re: [whatwg] HTML 5 video tag questions

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. If we fix that bug, then unless we do 
> some special magic, plugin-based video fallback will run and play audio 
> while the  element plays --- very bad.

Fixed.

Note: s as  descendants still load, and if those pages 
contain , , or s, they will load. Also, nested 
s or s will load, including when in the fallback content of 
. All I stopped is , , and , when 
descendants of , , or active s.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Plus Signs in Signed Integers

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:

TEST => 2
TEST => 2
TEST => -2
TEST => 1
TEST => 1
TEST => 1

This matches the spec.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Issues with Web Sockets API

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 wouldn't 
> > expect anyone to actually use it for production work.
> 
> Is there precedent for other portions of the API that are mostly for 
> debugging purposes?  (I can't think of anything off the top of my head.)

readyState on Document and  aren't realy useful for anything but 
debugging either, as far as I can tell.

> Also, maybe it should be noted as such in the spec?

I don't really see much benefit to including such a statement; if someone 
wants to use it for a non-debugging reason, why not do so?

> 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 trying to solve by 
changing that.

> One other random question:  in the IDL for WebSockets, the three 
> constants for ready state are all defined as shorts but the value of 
> ready state is a long.  Is this an oversight?

Fixed.

On Mon, 27 Jul 2009, Alexey Proskuryakov wrote:
> 
> I agree with Michael that send() should not silently drop data that 
> could not be sent. It is very easy to fill send buffers, and if bytes 
> get silently dropped, implementing app-level acks becomes quite 
> difficult.

I've made it clear that if bytes can't be sent, the connection must be 
closed.

> However, I do not think that raising an exception is an appropriate 
> answer. Often, the TCP implementation takes a part of data given to it, 
> and asks to resubmit the rest later. So, just returning an integer 
> result from send() would be best in my opinion.

I think we are best off abstracting away this level of complexity from 
authors, especially since we'd need to make sure that data was not sent 
half-way through a UTF-8 sequence, and since the framing is under the 
control of the UA, not the application. There's no way to retry a 
partially-successful send() from the API here.

> 1) Web Sockets is specified to send whatever authentication credentials 
> the client has for the resource. However, there is no challenge-response 
> sequence specified, which seems to prevent using common auth schemes. 
> HTTP Basic needs to know an authentication realm for the credentials, 
> and other schemes need a cryptographic challenge (e.g. nonce for Digest 
> auth).

I expect to address this in more detail in a future version. For now, use 
in-band authentication in the WebSocket once you are connected. We may 
find that that is actually enough.

> 2) It is not specified what the server does when credentials are 
> incorrect, so I assume that the intended behavior is to close the 
> connection. Unlike HTTP 401 response, this doesn't give the client a 
> chance to ask the user again. Also, if the server is on a different 
> host, especially one that's not shared with an HTTP server, there isn't 
> a way to obtain credentials, in the first place.

How we address this will likely depend on how we address the earlier 
point.

> 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 that needs to be in v1.

What's the use case? Why does this need to be at the connection layer 
rather than the application layer? (Why would we need this, when TCP 
doesn't have it? Would you also need "redirect"-like functonality in IRC, 
IMAP, SSH, and other such protocols?)

> 4) "If the user agent already has a Web Socket connection to the remote 
> host identified by /host/ (even if known by another name), wait until 
> that connection has been established or for that connection to have 
> failed."
>
> It doesn't look like "host identified by /host/" is defined anywhere. 
> Does this requirement say that IP addresses should be compared, instead 
> of host names?

Right. I've tried to clarify this.

> I'm not sure if this is significant for preventing DoS attacks, and 
> anyway, the IP address may not be known before a request is sent. This 
> puts an unusual burden on the implementation.

Without this requirement, you can just have a DNS server return the victim 
IP for a wildcard DNS entry, and then just have attackers open connections 
to thousands of "hosts".

> 5) We probably need to specify a keep-alive feature to avoid proxy 
> connection timeout. I do not have factual data on whether common proxies 
> implement connection timeout, but I'd expect them to often do.

This seems like something that would be easy to deal with at the 
application layer, if desired.

> 6) The spec should probably explicitly permit blocking some ports from 
> use with

Re: [whatwg] Installed Apps

2009-07-28 Thread Michael Nordman

On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking  wrote:

> On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak 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.
> > However, the first part sounds like it alone would be useful to web
> > applications like GMail:
> >
> > The first, which should begenerally useful, is the ability to have a
> hidden
> > HTML/JS page running
> > in the background that can access the DOM of visible windows. This
> > page should be accessible from windows that the user navigates to. We
> > call this background Javascript window a "shared context" or a
> > "background page". This will enable multiple instances of a web app
> > (e.g. tearoff windows in Gmail) to cleanly access the same user state
> > no matter which windows are open.
> >
> > + restrict things to the same security origin.
> > It sounds similar in concept to a share worker except that it runs in the
> > main thread and is more concerned with dom manipulation/state while
> workers
> > have typically been thought of as allowing background processing.
> > It seems that the lifetime of this could be scoped, so that it dies when
> it
> > isn't referenced (in a similar way to how shared worker lifetime is
> scoped).
> >
> > This idea actually sounds reasonably ok, and I think I once proposed
> > something like this as an alternative to shared workers as the way for
> > multiple app instances to share state and computation.
> > It's really the bit about invisibly continuing to run once all related
> web
> > pages are closed that I would worry about the security issues.
>
> 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, then a browser could if it
> so wished use separate processes to run those two pages. If we enabled
> this API the two pages would have to run in the same process, even if
> neither page actually used this new API.
>
> / Jonas


There are conflicting requirements along these lines that would need to be
resolved...

1) A nested iframe needs to run in the same process as its containing page.
2) A shared context needs to run in the same process as its client pages.

... but what if a nested iframe document in processA connects to a
sharedContext that has already been loaded into processB. Somethings gotta
give.

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 gaurantee is that all directly scriptable pages (those from a
given set of related browsing contexts) WILL share the same sharedContext
(should the refer to it).

Re: [whatwg] Installed Apps

2009-07-28 Thread Michael Nordman

On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak  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.
>
> However, the first part sounds like it alone would be useful to web
> applications like GMail:
>
> The first, which should begenerally useful, is the ability to have a
> hidden HTML/JS page running
> in the background that can access the DOM of visible windows. This
> page should be accessible from windows that the user navigates to. We
> call this background Javascript window a "shared context" or a
> "background page". This will enable multiple instances of a web app
> (e.g. tearoff windows in Gmail) to cleanly access the same user state
> no matter which windows are open.
>
>
> + restrict things to the same security origin.
>
> It sounds similar in concept to a share worker except that it runs in the
> main thread and is more concerned with dom manipulation/state while workers
> have typically been thought of as allowing background processing.
>
> It seems that the lifetime of this could be scoped, so that it dies when it
> isn't referenced (in a similar way to how shared worker lifetime is scoped).
>
>
> This idea actually sounds reasonably ok, and I think I once proposed
> something like this as an alternative to shared workers as the way for
> multiple app instances to share state and computation.
>
> It's really the bit about invisibly continuing to run once all related web
> pages are closed that I would worry about the security issues.
>
> Regards,
> Maciej
>
>
+1 seperating the "load-at-startup" and
"persist-beyond-connected-page-close" from the more generally applicable
feature to "connect to a directly scritable shared context from multiple
pages". Minus the lifetime questions, I don't think there's anything
terribly controversial about this... very similar to an invisible iframe
that's must be from the same-origin as the referencing page. I think this
could be a very valuable feature in general.

Gmail does really want permissions to run in the background... but I think
that could be layered on top of the more primitive "shared context" feature.

* one way to 'extend' things could be to allow a persistent worker (which
has permissions to run in the background) to load a shared context and hold
a refernce to it to prevent the shared context from closing (note: the
persistent worker wouldn't be able to directly script that shared context,
just bootstrap it and keep it alive).

* another way to extend things could be to allow an appcache manifest to
indicate which resources should be loaded into a shared context

Re: [whatwg] Installed Apps

2009-07-28 Thread Ojan Vafai

On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson  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 application state from the database is slow.
>

Do we know why 1 and 2 are true? Can it be fixed?

> 3) Sharing between pages requires going through the database or shared
> worker - you can't just party on a big shared datastructure.
> 4) There's no way to do things like new mail notifications, calendar
> notifications, local updates of your email inbox, etc when the browser is
> not open. Currently, even the most brain-dead shareware desktop calendar app
> can display an event notification, while web-based calendars are forced to
> rely on the user remembering to keep a browser window open.
>
> Am I missing any other issues that hidden page is supposed to address?
>
> A persistent worker could address #4 (perhaps with some limitations on
> network access to address security concerns). For #1/#2/#3, are we saying
> that web applications *must* install themselves (with the requisite user
> flow) just to get fast load times? That seems unfortunate - if I don't care
> about #4, I'd really like to be able to get the benefits of #1/2/3 without
> jumping through a user install.
>

Yes, but a background page keeps a lot of state in memory semi-permanently.
It's not acceptable for any web page to have the power to use significant
system resources even after it's been closed.

The most contentious part of this proposal is keeping the page open after
all it's parent pages have been closed. #3 only needs background pages to be
open as long as it's parent pages are open. #4 can be somewhat solved by
this, but there are other less resource intensive solutions to that as well.

Something like Aaron's proposal where "the lifetime of the page could be
refcounted by pages referencing it" seems reasonable though. It doesn't
solve the initial startup problem, but it does solve #3, which would allow
for making things like popping out an email to it's own window fast.

In addition, putting this behind an install UI like extensions seems fine to
fix the startup case and #4, although I agree that you shouldn't need to
"install gmail" for it to load quickly.

I'd like to understand the underlying reasons for #1 and #2. As Jonas said,
there may be alternative solutions that are less prone to abuse of system
resources. For example is loading cached JS so slow because it needs to hit
disk? That could be solved by an AppCache extension that pins resources in
memory if possible.

Ojan

-atw
>
>
> On Mon, Jul 27, 2009 at 6:39 PM, Maciej Stachowiak  wrote:
>
>>
>> On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote:
>>
>>  I'm not clear how the UI requirements here are different from
>>> persistent workers, though.  Those also persist after the user
>>> navigates away, right?
>>>
>>
>> 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 rebooted. Persistent workers should be renamed to "BotNet
>> Construction Kit".
>>
>> Regards,
>> Maciej
>>
>>
>

Re: [whatwg] Installed Apps

On Tue, Jul 28, 2009 at 2:23 PM, Adam de Boor wrote:
>
>
> 2009/7/28 Jonas Sicking 
>>
>> 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, then a browser could if it
>> so wished use separate processes to run those two pages. If we enabled
>> this API the two pages would have to run in the same process, even if
>> neither page actually used this new API.
>>
> This is one of the arguments for layering on the AppCache: the app would
> have to take action, through an attribute in the manifest, at a level where
> the browser could make the decision whether to join two windows into the
> same process.

Though I think in most implementations, even by the time you realize
that there even is an AppCache manifest, you've already chosen which
process to use to run the page.

But I agree that it's at least theoretically possible to solve this if
you use an AppCache solution.

/ Jonas

Re: [whatwg] .tags on HTMLCollections

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 does 
> not.  I was wondering whether any of the Webkit or Opera folks could 
> comment on _why_ they implement this?  I haven't seen any uses of this 
> in the wild (outside document.all.tags, but document.all doesn't behave 
> like a normal HTMLCollection in all sorts of other ways either).
> 
> I'd rather be specifying (and implementing) a smaller DOM API, if that's 
> all that's needed for actual web compat

On Tue, 14 Jul 2009, Maciej Stachowiak wrote:
> 
> Support for HTMLCollection.tags() in WebKit predates the fork from 
> KHTML. So we don't know why it was originally added.

On Tue, 14 Jul 2009, Boris Zbarsky wrote:
> 
> I guess the other question is whether you feel it's worth keeping...

On Tue, 14 Jul 2009, Maciej Stachowiak wrote:
>
> I don't know of a reason it's needed for collections other than 
> document.all. But it also doesn't seem harmful and I can't say 
> definitively whether it helps anything. I wouldn't object to removing it 
> from the spec, but we probably wouldn't remove it from WebKit short of 
> evidence that it's actually harmful.
> 
> Perhaps Opera people can shed more light on the matter.

On Thu, 23 Jul 2009, Anne van Kesteren wrote:
> 
> From what I heard so far it is there because of document.all. If 
> document.all does indeed need to return a separate object as HTML5 
> suggests we can probably remove it from HTMLCollection in due course.

I haven't removed HTMLCollection.tags yet, since it appears to be 
implemented by most browsers. If we can get Opera and WebKit to remove 
support, then I'll remove it from the spec.


On Thu, 23 Jul 2009, Boris Zbarsky wrote:
> 
> Given that the namedItem behavior of document.all is different from the 
> namedItem behavior of HTMLCollection, I don't see how document.all could 
> possibly be a general HTMLCollection

On Fri, 24 Jul 2009, Anne van Kesteren wrote:
> 
> They are indeed distinct, but do share the same interface name in Opera 
> the moment, as far as I can tell... In any case, my point was that we'd 
> be ok with removing the tags member from HTMLCollection in due course.

On Fri, 24 Jul 2009, Boris Zbarsky wrote:
> 
> Oh, the _name_ is shared in Gecko too.  Just not anything else.  ;)

Right now the HTML5 spec calls the document.all HTMLCollection 
"HTMLAllCollection", since I have no way to override the name, and I can't 
have two names the same. I'm not sure what the prototype of document.all 
is if it's not the same as document.images... in fact this whole area is 
quite confusing to me. So I haven't done any the confusingness and just 
made them distinct.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [html5] Image captions in FIGUREs

On Tue, 14 Jul 2009, Old�ich Vete�n�k wrote:
> Dne Tue, 14 Jul 2009 02:52:22 +0200 Aryeh Gregor 
> napsal/-a:
> > On Mon, Jul 13, 2009 at 8:29 PM, Aen Tan wrote:
> > > I was specifically referring to the LEGEND element.
> > 
> > That seems to work less.  WebKit just removes it from the DOM.  Are 
> > you suggesting that for compatibility, it should be named something 
> > else so that it works at least as well as the other elements?
> 
> Indeed, unless browsers let us style  any way we want (let's say 
> like  element), people won't use it (in figures) because it 
> wouldn't be flexible enough.

On Wed, 15 Jul 2009, Aryeh Gregor wrote:
> 
> The element can't be styled in either Firefox 3.5 or recent WebKit 
> because, according to my testing, it simply doesn't exist in the DOM. 
> Any  that's not in a  is just ignored during parsing, 
> apparently.

On Wed, 15 Jul 2009, Tab Atkins Jr. wrote:
> 
> On the note of  styling, currently a legend-in-fieldset isn't
> handled by the standard CSS renderer *at all* in FF, last I heard, due
> to the magic inherent in its display:
>   * automatically positioning itself on top of the 's border
> without using abspos (the fieldset would need to be relpos or similar
> to allow this to work) regardless of where in the  the
>  appears (this precludes use of margin to pull it upwards,
> because it might not appear as the first child).
>   * hiding the border of the fieldset behind it without hiding the
> background of the fieldset, or any borders or padding of any
> lower-layer elements.

On Wed, 15 Jul 2009, Aryeh Gregor wrote:
> 
> I may have misremembered the results.  I get that in Firefox 3.5 too. In 
> Chrome (Linux dev channel -- presumably applies to recent Safari builds 
> too), I get the legend element simply not appearing in the DOM.

On Thu, 16 Jul 2009, Boris Zbarsky wrote:
> 
> Just as a note, I believe we consider both of these bugs, and plan to 
> change behavior there.

On Thu, 16 Jul 2009, Boris Zbarsky wrote:
> 
> More precisely it's handled as having a special "position" value that 
> you can't override, more or less, and that position value forces 
> float:none and display:block and certain sizing behavior, more or less.  
> All of this is expressed in CSS.  After that you use the CSS renderer...  
> On the other hand,  itself is pretty weird in terms of the way 
> it renders; it doesn't use any of the standard CSS box types.  The box 
> type it does use makes certain assumptions about the styling of the 
> .  All that might get changed, but it only matters for  
> in .  Current trunk Gecko handles  outside  
> as just another block, in terms of the renderer. How you get such a DOM 
> is a separate issue.  Firefox 3.5 and earlier does weird things for 
>  outside .

My plan here is to continue to wait for a while longer to see if the 
parsing issues can get ironed out (the HTML5 parser in Gecko for instance 
solves this problem for Firefox). If we really can't get past this, we'll 
have to introduce a new element, but I'm trying to avoid going there.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Adding "canonical" to the list of allowed link types

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 posts, it seems that it was once briefly mentioned 
> in passing but there was no discussion regarding its addition to the 
> spec. Considering its usefulness, are there plans to add "canonical" to 
> the official list of accepted values?

On Tue, 14 Jul 2009, Aryeh Gregor wrote:
> 
> I'd support this.  There are many cases with web apps when you want to 
> present slightly different versions of the same content, where the 
> differences are convenient to regular users but immaterial to first-time 
> users, such that search engines should treat them interchangeably or 
> present a single canonical version to new visitors rather than treating 
> them as separate pages.  In principle you might think search engines 
> could figure this out themselves heuristically, but the three biggest 
> have apparently decided they could use some help, so it seems like a 
> valuable feature.
> 
> Of course, the way the new value was developed and introduced was 
> certainly not ideal.  But the same is true for a lot of the things that 
> go into the HTML 5 spec.

On Wed, 15 Jul 2009, Bil Corry wrote:
> 
> It's is currently listed on the RelExtensions wiki page as referenced by 
> the HTML5 draft:
> 
>   http://wiki.whatwg.org/wiki/RelExtensions

What Bil said. To go further, it will need a formal spec.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Installed Apps

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, but
that's not a huge concern.

a

2009/7/28 Aryeh Gregor 
>

> There's not really a whole lot that a malicious or incompetent
> persistent page could do to the user's computer.  At worst, it could
> interfere with the browser.  I guess the botnet concern is justified,
> though (for use in DDoS or something).  Not sure how to avoid that.
>

Re: [whatwg] Installed Apps

2009/7/28 Jonas Sicking 

>
> 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, then a browser could if it
> so wished use separate processes to run those two pages. If we enabled
> this API the two pages would have to run in the same process, even if
> neither page actually used this new API.
>
> This is one of the arguments for layering on the AppCache: the app would
have to take action, through an attribute in the manifest, at a level where
the browser could make the decision whether to join two windows into the
same process.

a

Re: [whatwg] hash sum tags of binary files and code blocks?

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 make caching very easy on mobile devices 
> with slow datalinks, make it possible for service providers to cache 
> objects globally for their customer base. One could also augment whole 
> code blocks with hash sums for example css this could possibly be more 
> efficient than time expire.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  md5="dee0b8572297fe4e3b004cfe188ecad3"/>
> no need to load that style sheet ever again if it's contents has not
> changed.

As others have said, it seems easier to just use the filename as the way 
to do this.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] audio data, src and codecs testcases

On Tue, 28 Jul 2009, "~:'' 
�~A~B�~B~J�~A~L�~A��~A~F�~A~T�~A~V�~A~D�~A��~A~W�~A~_" wrote:
>
> audio data, src and codecs testcases
> 
> looking for a reasonable middle ground, having read some of the lengthy 
> correspondence:
> 
> http://www.w3.org/1999/xhtml";
>   data="hm.ogg"
>   src="hm.mp3"
> controls="1" autoplay="1"/>
> 
> apologies if data and src might need swapping...

I don't understand your proposal.


> are there any cross-browser working testcases for audio support?
> with and without script?

I'm not aware of any tests yet; anyone?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Installed Apps

2009-07-28 Thread ~:'' ありがとうございました

On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson 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 PROBLEM
>
> We would like to enable rich internet applications to achieve feature
> parity with desktop applications. I will use Gmail and Outlook as
> examples for stating the problems we hope to solve.
>
> -- Slow startup: When a user navigates to mail.google.com, multiple
> server requests are required to render the page. The Javascript is
> cacheable, but personal data (e.g. the list of emails to show) is not.
> New releases of Gmail that require JS downloads are even slower to
> load.
> -- Native apps like Outlook can (and do) run background processes on
> the user's machine to make sure that data is always up-to-date.
> -- Notifications: Likewise, Outlook can notify users (via a background
> process) when new mail comes in even if it's not running.

It sounds like what you need for your use case is for some set of
resources to be immediately available when gmail starts. This set of
resources is a mixture of "static" resources like JS files (and
presumably HTML files), and "dynamic" resources like the list of
emails.

An alternative solution would be to tell the browser what resources
you need, and how to download them (to allow for incremental downloads
of just new emails for example). Then the browser can download these
resources as it sees fit. On a mobile device this could happen even if
the browser is not running, similar to the iPhone push mechanism.

This should be significantly easier to secure since you don't allow
the full power of the web platform to run in the background.

I would think that this can be done using extensions to the AppCache feature.

/ Jonas

Re: [whatwg] Installed Apps

2009-07-28 Thread Drew Wilson

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 network access methods for hidden pages.
You do have a good point, though, and that is that if hidden pages *or*
persistent workers need to be able to display UI to the user (for example,
to prompt the user to enter their gmail credentials when they first start up
their computer), it has some implications for popup spam.

-atw

On Tue, Jul 28, 2009 at 10:09 AM, Aryeh Gregor

> wrote:

> On Tue, Jul 28, 2009 at 1:01 PM, 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.
>
> How would that work for background pages, though?  It couldn't include
> any files from other domains in any form (image, script, style, etc.)?
>  But it could still spawn a regular tab and load whatever it wanted in
> that.  Have it spawn a popunder window, say, quickly open a bunch of
> things from foreign sites, and close it before the user notices
> anything more than a sudden odd flicker.  Or whatever.  Workers, if I
> understand right (I haven't read the spec . . .), can't do things like
> open new tabs, but it's been explicitly stated that these background
> pages should be able to do just that.
>

Re: [whatwg] Installed Apps

2009-07-28 Thread Aryeh Gregor

On Tue, Jul 28, 2009 at 1:01 PM, 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.

How would that work for background pages, though?  It couldn't include
any files from other domains in any form (image, script, style, etc.)?
 But it could still spawn a regular tab and load whatever it wanted in
that.  Have it spawn a popunder window, say, quickly open a bunch of
things from foreign sites, and close it before the user notices
anything more than a sudden odd flicker.  Or whatever.  Workers, if I
understand right (I haven't read the spec . . .), can't do things like
open new tabs, but it's been explicitly stated that these background
pages should be able to do just that.

Re: [whatwg] Installed Apps

2009-07-28 Thread Drew Wilson

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"
issue, but that makes us no different than Flash :-P
Anyhow, addressing some of the other comments - I don't think that there's
necessarily a problem with the async worker APIs as they stand, and I don't
think we can easily retrofit synchronous APIs on top of their current
execution model. The issue is that the core problem that Workers solve
(parallel execution in a separate context from the page) is different than
the problem that large web apps are trying to address (reduced latency).

SharedWorkers are overloaded to provide a way for pages under the same
domain to share state, but this seems like an orthogonal goal to "parallel
execution" and I suspect that we may have ended up with a cleaner solution
had we decided to address the "shared state" issue via a separate mechanism.

Similarly, the "hidden page" mechanism seems to address a bunch of issues at
once, and I'm wondering if we explicitly laid out the problems it's trying
to solve, whether we might find a set of distinct smaller solutions that
were more generally applicable. I just don't want to make the same design
choices that we did with SharedWorkers, and end up with a monolithic
solution that doesn't address the individual goals (i.e. cross-page sharing)
in a developer-friendly manner.

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 application state from the database is slow.
3) Sharing between pages requires going through the database or shared
worker - you can't just party on a big shared datastructure.
4) There's no way to do things like new mail notifications, calendar
notifications, local updates of your email inbox, etc when the browser is
not open. Currently, even the most brain-dead shareware desktop calendar app
can display an event notification, while web-based calendars are forced to
rely on the user remembering to keep a browser window open.

Am I missing any other issues that hidden page is supposed to address?

A persistent worker could address #4 (perhaps with some limitations on
network access to address security concerns). For #1/#2/#3, are we saying
that web applications *must* install themselves (with the requisite user
flow) just to get fast load times? That seems unfortunate - if I don't care
about #4, I'd really like to be able to get the benefits of #1/2/3 without
jumping through a user install.

-atw

On Mon, Jul 27, 2009 at 6:39 PM, Maciej Stachowiak  wrote:

>
> On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote:
>
>  I'm not clear how the UI requirements here are different from
>> persistent workers, though.  Those also persist after the user
>> navigates away, right?
>>
>
> 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 rebooted. Persistent workers should be renamed to "BotNet
> Construction Kit".
>
> Regards,
> Maciej
>
>

Re: [whatwg] Installed Apps

2009-07-28 Thread Patrick Mueller


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 launch visible windows and have full
DOM access.  This is different from the model of workers where all
interaction with the DOM has to be done through asynchronous message
passing. We would like background pages to be able to drive UI in a
visible window using the techniques (DOM manipulation, innerHTML) that
are common today. We believe that more apps would be able to take
advantage of a background page if they didn't require rewriting the
app in the asynchronous, message-passing style required by workers.


hmmm ... this is the worrying part to me.  Sounds like one of the 
presumed qualities of web workers, ease of use, isn't going to be met 
with the currently spec'd APIs.  Is there some way to framework-ize 
something around the current APIs to make this easier to use by 
developers?  Or would the addition of a synchronous API help (assuming 
some non-evil synchronous API)?  Or do we need a lot of head shaping 
around asynchronous message sending?


Futher question would be whether there are two issues: dealing with 
asynchronous messages, and direct DOM API.  If we could get over the 
hurdle of the async, do we still need the direct DOM API?


--
Patrick Mueller - http://muellerware.org

Re: [whatwg] DOMTokenList is unordered but yet requires sorting

2009-07-28 Thread Sylvain Pasche

On Tue, Jul 28, 2009 at 5:52 AM, Jonas Sicking 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 parsing
>> the attribute in order to only insert unique tokens in the token
>> vector. Then DOMTokenList.length would return the token vector length
>> and .item() get the token by index. I don't think anything actually
>> depends on keeping duplicate tokens in the token vector. Then there
>> would be a small perf hit when parsing attributes with more than one
>> token.
>
> It's certainly doable to do this at the time when the token-list is
> parsed. However given how extremely rare duplicated classnames are (I
> can't recall ever seeing it in a real page), I think any code spent on
> dealing with it is a waste.

Agreed.

>> The remove() algorithm is about 50 lines with whitespace and comments.
>> After all, that's not a big cost and I guess that preserving
>> whitespace may be closer to what DOMTokenList API consumers would
>> expect.
>
> The code would be 7 lines if we didn't need to preserve whitespace:
>
> nsAttrValue newAttr(aAttr);
> newAttr->ResetMiscAtomOrString();
> nsCOMPtr atom = do_GetAtom(aToken);
> while (newAttr->GetAtomArrayValue().RemoveElement(atom));
> nsAutoString newValue;
> newAttr.ToString(newValue);
> mElement->SetAttr(...);
>
> If you spent a few more lines of code you could even avoid serializing
> the token-list and call SetAttrAndNotify instead of SetAttr.

That's an interesting comparison. Less code and much more readable
than my remove() implementation I have to say.


Sylvain

[whatwg] audio data, src and codecs testcases


audio data, src and codecs testcases

looking for a reasonable middle ground, having read some of the  
lengthy correspondence:


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 any cross-browser working testcases for audio support?
with and without script?

a discussion with some examples using SVG that do work cross-browser:
http://tech.groups.yahoo.com/group/svg-developers/message/62680

regards

Jonathan Chetwynd

Re: [whatwg] Installed Apps

2009-07-28 Thread Michael Kozakewich

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 'close' 
option.


I'm not sure about the use of making it start automatically on computer 
restart, unless it was meant that the state of the application would be 
saved on the computer? It could use an offline-storage solution, and then 
close itself.

Re: [whatwg] Installed Apps

2009-07-28 Thread Aryeh Gregor

On Tue, Jul 28, 2009 at 3:02 AM, Jonas Sicking 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 more powerful than that, since it
> allows a hidden page that the user can't easily simply close, and so
> should probably have an even more restrictive UI.

I'm not sure what "an even more restrictive UI" means.  I don't think
"lots of scary warnings" is a good approach here.  (Or elsewhere, but
that's a separate issue.)  Better to do something like:

"https://mail.google.com/ would like to continue running a background
page permanently after you browse away.  This might make the site
faster if you use it a lot, but could use up your computer's
resources.  Would you like to allow this?  You can disable it later
from the Add-Ons menu."

Then try to think of some obvious forms of disruptive behavior, like
using too much CPU, and have some appropriately-calibrated
notification if that happens asking the user if he'd like to disable
the page.  Conceivably a background page could misbehave enough that
the user can't easily close it.  But this is already true for normal
pages, and those can already be persistent if the user has session
restore enabled and the tab somehow freezes or crashes the browser so
the user can't close it.  Browsers should be able to provide UI to
handle this (and do, for normal pages, if they provide session
restore).

There's not really a whole lot that a malicious or incompetent
persistent page could do to the user's computer.  At worst, it could
interfere with the browser.  I guess the botnet concern is justified,
though (for use in DDoS or something).  Not sure how to avoid that.

Re: [whatwg] Canvas context.drawImage clarification

2009-07-28 Thread Aryeh Gregor

On Tue, Jul 28, 2009 at 1:41 AM, Gregg Tavares wrote:
> It's ambiguous because images have a direction.  An image that starts at 10
> with a width of -5 is not the same as an image that starts at 6 with a width
> of +5 any more than starting in SF and driving 5 miles south is not the same
> as starting in Brisbane and driving 5 miles north.
>
> The spec doesn't say which interpretation is correct.

I think it's extremely clear.  The spec gives four points which
determine a rectangle, which are in no particular order.  The image is
rectangular, and is mapped into that rectangle.  Rectangles have no
orientation, and the operation "paint the source region onto the
destination region" couldn't possibly be interpreted as requiring
reorientation of any kind.

I think you got misled by the diagram, and now aren't reading the
normative text of the spec carefully enough -- it's *very* specific
(like most of HTML 5).

Re: [whatwg] Installed Apps

On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak 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.
> However, the first part sounds like it alone would be useful to web
> applications like GMail:
>
> The first, which should begenerally useful, is the ability to have a hidden
> HTML/JS page running
> in the background that can access the DOM of visible windows. This
> page should be accessible from windows that the user navigates to. We
> call this background Javascript window a "shared context" or a
> "background page". This will enable multiple instances of a web app
> (e.g. tearoff windows in Gmail) to cleanly access the same user state
> no matter which windows are open.
>
> + restrict things to the same security origin.
> It sounds similar in concept to a share worker except that it runs in the
> main thread and is more concerned with dom manipulation/state while workers
> have typically been thought of as allowing background processing.
> It seems that the lifetime of this could be scoped, so that it dies when it
> isn't referenced (in a similar way to how shared worker lifetime is scoped).
>
> This idea actually sounds reasonably ok, and I think I once proposed
> something like this as an alternative to shared workers as the way for
> multiple app instances to share state and computation.
> It's really the bit about invisibly continuing to run once all related web
> pages are closed that I would worry about the security issues.

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, then a browser could if it
so wished use separate processes to run those two pages. If we enabled
this API the two pages would have to run in the same process, even if
neither page actually used this new API.

/ Jonas

Re: [whatwg] New HTML5 spec GIT collaboration repository

2009-07-28 Thread Geoffrey Sneddon

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, etc.) which, when taken all together, have
duplicate definition. Manu’s Makefile will need to split out the
HTML 5 specific parts (between the and markers). The ‘source-html5 : source’ rule in
http://dev.w3.org/html5/spec-template/Makefile will handle that.

What a great answer, Cameron! I wish I had thought of that :)

Ah, that's true. I was assuming he was working on the split-up spec.

Yes, that will become an issue in time and was going to have a chat with
Geoffrey about how to modify Anolis to handle that as well as handling
what happens when there is no definitions when building the
cross-references (perhaps having a formatter warnings section in the file?).

Handle that in what way? The correct way, as far as I can see, is to do
what Ian does, which is to call Anolis on the already-split up spec.
What do you mean about warnings? Just if there's an instance of a term
which isn't defined? That can't be done, because it would mean that
every abbr, code, i, span and var element would have to be an instance
(whereas they can perfectly fine exist without being one).

It's probably worth throwing an error/warning when data-anolis-xref is
set and it is unknown, though. (But that will probably change to data-xref.)

I also spoke too soon, Geoffrey, --allow-duplicate-dfns is needed
because of this error when compiling Ian's spec:

The term "dom-sharedworkerglobalscope-applicationcache" is defined more
than once

I'm probably doing something wrong... haven't had a chance to look at
Cameron's Makefile pointer yet, so "--allow-duplicate-dfns" is in there
for now.

I expect you are doing something wrong, because that doesn't exist in
Ian's copy. :)

With regards to tracking Anolis, your free to pull it in if you want,
but you probably don't want to track it too closely (currently there
haven't been any major changes from 1.0, though they are coming soon, so
it may get a miss less stable). I tend to ping James (Graham) provided
it's stable, so he can update pimpmyspec.net, and I can try and remember
to ping you too.

--
Geoffrey Sneddon — Opera Software

Re: [whatwg] Installed Apps

2009-07-28 Thread Maciej Stachowiak



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  
applications like GMail:


The first, which should begenerally useful, is the ability to have a  
hidden HTML/JS page running

in the background that can access the DOM of visible windows. This
page should be accessible from windows that the user navigates to. We
call this background Javascript window a "shared context" or a
"background page". This will enable multiple instances of a web app
(e.g. tearoff windows in Gmail) to cleanly access the same user state
no matter which windows are open.

+ restrict things to the same security origin.

It sounds similar in concept to a share worker except that it runs  
in the main thread and is more concerned with dom manipulation/state  
while workers have typically been thought of as allowing background  
processing.


It seems that the lifetime of this could be scoped, so that it dies  
when it isn't referenced (in a similar way to how shared worker  
lifetime is scoped).


This idea actually sounds reasonably ok, and I think I once proposed  
something like this as an alternative to shared workers as the way for  
multiple app instances to share state and computation.


It's really the bit about invisibly continuing to run once all related  
web pages are closed that I would worry about the security issues.


Regards,
Maciej

Re: [whatwg] Serving up Theora in the real world

2009-07-28 Thread Simon Pieters

On Tue, 28 Jul 2009 02:39:46 +0200, Andrew Scherkus   
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:
>
> http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support
>
> Firefox is conservative and honest (except maybe for "audio/wav;
> codecs=0", what could you do with the RIFF DATA chunk?) Safari gets
> maybe/probably backwards compared to what the spec suggests. Chrome
> seems to ignore the codecs parameter, claiming "probably" even for  
bogus

> codecs. Authors obviously can't trust the distinction between "maybe"
> and "probably" to any extent.

That certainly is unfortunate.



Thanks for calling us out :)

We've addressed this in our latest builds.  We now fall somewhere between
Firefox and Safari in terms of conservativeness and honesty.

We still give bogus codecs a "maybe" if the container is supported, since
that seems to be what the spec suggests.


That doesn't match my reading of the spec...

The spec says

"The canPlayType(type) method must return the empty string if type is a  
type that the user agent knows it cannot render;"


and

"A type that the user agent knows it cannot render is one that describes a  
resource that the user agent definitely does not support, for example  
because it doesn't recognize the container type, or it doesn't support the  
listed codecs."




A "probably" is only for both a
container and codec match.


--
Simon Pieters
Opera Software

Re: [whatwg] Serializing HTML fragments (9.4)

2009-07-28 Thread Simon Pieters


On Mon, 13 Jul 2009, Simon Pieters wrote:


I think the spec currently matches what IE does.


On Mon, 13 Jul 2009, Boris Zbarsky wrote:


Does IE even support adding a child element to a

Re: [whatwg] Installed Apps