Re: [whatwg] Mathematics in HTML5

[Robert O'Callahan]

I'll speak up as one of the Mozilla layout developers, but speaking only for myself.Since we already have a MathML implementation --- which works fairly well in my experience --- I think it makes more sense from our point of view to fix/improve MathML than to deal with new CSS extensions to get decent rendering. MathML's purported incompatibilities with DOM and CSS are not serious from an implementor's point of view, at least no worse than lots of other CSS-unfriendly content we have to deal with. I hope that the fonts issue gets better when comprehensive STIX fonts are freely available online and we can automatically download them whenever they're needed.
I strongly agree with Hixie and others that a new math dialect for HTML needs to be proven before it can be standardized as *the* preferred solution for mathematics in HTML. If MathML is as bad --- and CSS2.1 as adequate --- as some say, then it should be easy to create a microformat that becomes more popular than MathML. At that point there is a much stronger case for inclusion. I would also like to see a complete description of the CSS extensions required for real high-quality rendering.
From my point of view, a  element that can be
implemented using inline-block in the UA style sheet seems like a reasonable thing to support in HTML5, since it's basically no effort and is a small increment over existing  etc.
Rob-- "[But] he was pierced for our transgressions, he was crushed for ouriniquities; the punishment that brought us peace was upon him, andby his wounds we are healed. Isaiah 53:5]

[whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)

[Robert O'Callahan]

- As mentioned above, some devices may have a much harder time
implementing Ogg than other codecs. Although a SHOULD-level
requirement would excuse them, I'm not sure it's appropriate to have
it if it might be invoked often.

OK, let's assume Theora is a bad format for some devices. If someone wants

to target those devices with a better codec, they can do so, and use Theora
as the fallback. If they don't care, they use Theora and at least the
content is still playable on the devices. What's the problem here? It's
still a net win over the no-standard-codec alternative.


- Although the Ogg codecs don't have known patents that aren't RF
licensed, it's not completely clear that none of the patents out
there on video/audio encoding apply. Often, parties holding a
submarine patent wait for a company with very deep pockets (like
Apple, or Microsoft, or Google) to infringe on the patent before they
sue. On the other hand, MPEG codecs have been implemented by many
large corporations already, and no patents have appeared besides the
ones that can be licensed from MPEG-LA for a fee. So, ironically, for
a large company that has no problem the patent fees, Ogg may carry
more patent risk than MPEG.

Just because no patents have appeared against MPEG doesn't mean there

aren't any outside the MPEG-LA pool. Submarines can surface at any time. See
Forgent.


- Placing requirements on format support would be unprecedented for
HTML specifications, which generally leave this up to the UA, with de
facto baseline support being decided by the market.

Just because previous HTML specifications have been deficient in this

regard doesn't mean we have to repeat the mistake.

I think having a single baseline codec will make  immensely more
attractive to authors than it otherwise would be. I also believe from the
point of view of Mozilla (or any other open source project) Theora is vastly
more attractive than MPEG. If we don't ship MPEG and other vendors don't
ship Theora, then the  element will be hobbled from the start.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

[whatwg] Google Gears and HTML5

[Robert O'Callahan]

*Maciej Stachowiak wrote:*


Now that Google Gears  has been announced,
I'd like to see the features in it added to the HTML5 spec, since
these are features that should ultimately be a part of basic web
technology, not an extension.

Agreed...



Ian has already added a SQL API which is functionally more or less
equivalent to the Database module  to the HTML5 spec, here: 

That is sudden :-). Specifying the SQL dialect precisely will be very

important here. Someone also has to investigate carefully the issues around
exposing SQL to untrusted content. Could be some fun denial of service
attacks there.


Conversely maybe something can be done to make them integrate better,
perhaps the Storage items appear as a table via the SQL API, in which
case most of the Storage calls are just a convenience interface, but
you can still do queries on the same data.

Sounds reasonable.



I know Mozilla has considered other approaches to offline web apps,
but I think the LocalServer type approach seems cleaner than
Mozilla's JAR file plan, since it is much more transparent and allows
local resource caching to be decoupled from the rest of the web app.

JAR files can be fairly transparent ... you can redirect from

http://foo.com/foo/index.html to http://foo.com/foo.jar!/index.html, if
appropriate, and use relative URIs in your app so the same versions work in
both cases. On the server side, maintaining a manifest isn't much different
from maintaining a JAR. True, having different URLs for different browsers
--- or for the same browser, in different modes --- could be a hassle. On
the plus side, JAR files make versioning and and consistency incredibly
simple. It's not clear what the Gears ManagedStore does if it gets a 404 or
some other error during an update.

Other issues with the Gears API:
-- The ManagedStore approach seems to have a problem in the following
situation: Suppose an app is updated on the server overnight and I visit the
main page in the morning. It starts loading other resources.  ManagedStore
is going to check the manifest, find that the app needs to be updated, pull
down the new resources, and flip to the new version --- more than likely
while the app is in the middle of loading. Sure, this could happen normally
if I hit the site in the middle of the night at the switchover, but
ManagedStore makes this uncommon case common. (This is Dave Camp's example.)
-- I think making ResourceStore writable by clients is unnecessary
complexity. It's much simpler to maintain the model that the
LocalServer/offline cache is really just a cache of the Web. Then there are
no issues with enabling/disablings stores, there is no need to add domain
restrictions or requiredCookie (i.e. potential security holes) so that
different apps can't tread on each other's resources. (So apps that want to
refer to a canonical source for JS library files or whatever can still
work.) For file uploads, I think we should just have a DOM API on form
control elements that reads the file data into a binary blob of some sort
which can then be stored in Storage or SQL.

I think we're still willing to alter our API, but we want to stick with the
simple conceptual model we currently have: a single read-only offline cache
that requires minimal management. Perhaps we could figure out how to get
versioning and consistency without using JARs. E.g., we might be able to add
an API that reads a Gears-style manifest and does an atomic update of the
offline cache from it.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Google Gears and HTML5

[Robert O'Callahan]

On 5/31/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:


On May 30, 2007, at 8:32 PM, Robert O'Callahan wrote:

On the plus side, JAR files make versioning and and consistency incredibly
simple. It's not clear what the Gears ManagedStore does if it gets a 404 or
some other error during an update.

I believe the update is made atomic to the web app:

<
http://code.google.com/apis/gears/api_localserver.html#ManagedResourceStore
>

"While an update is in progress, resources from the previous version (if
any) will continue to be served locally. After all resources have been
downloaded, the currentVersion property will be updated to indicate that the
new set of a resources are now being served locally and the previous version
has been removed."



Yeah, but that doesn't say what happens if one or more of the resources
fails to load.


Other issues with the Gears API:
-- The ManagedStore approach seems to have a problem in the following
situation: Suppose an app is updated on the server overnight and I visit the
main page in the morning. It starts loading other resources.  ManagedStore
is going to check the manifest, find that the app needs to be updated, pull
down the new resources, and flip to the new version --- more than likely
while the app is in the middle of loading. Sure, this could happen normally
if I hit the site in the middle of the night at the switchover, but
ManagedStore makes this uncommon case common. (This is Dave Camp's example.)


We've brought up the same problem. I thought more about this though - the
update can only happen while you're online, in which case you could do all
loads directly from the net (or at least revalidating per normal cache
policy) while at the same time checking for an update.



Then if you go offline while the app is running, you're in bad shape. (I
think brief periods of connectivity are a common scenario...)

Or else the manifest could be checked before serving from the local store

and if the version changed in that case let the page load live and cache
those copies.



That could work.

The transparency of the cache from the URI point of view actually helps with

solving this, I think. I don't think this problem is fundamental.



Neither do I, but it's something to think about.


-- I think making ResourceStore writable by clients is unnecessary
complexity. It's much simpler to maintain the model that the
LocalServer/offline cache is really just a cache of the Web. Then there are
no issues with enabling/disablings stores, there is no need to add domain
restrictions or requiredCookie ( i.e. potential security holes) so that
different apps can't tread on each other's resources. (So apps that want to
refer to a canonical source for JS library files or whatever can still
work.) For file uploads, I think we should just have a DOM API on form
control elements that reads the file data into a binary blob of some sort
which can then be stored in Storage or SQL.

I don't think requiredCookie feature is there solely for writeability
reasons, but rather to make the LocalServer cache work even when in normal
use they might get different versions of a resource from the server at
different times. For example, suppose you have two different gmail accounts
with preferences set to different languages.



That could be handled other ways, perhaps by restructuring the app to use
URI query parameters. I think requiredCookie is an example of something we
don't need in an initial spec. (BTW the Gears docs don't say what happens
when a load matches in multiple stores, possibly by having multiple
cookies...)

There is one related feature that Gears is missing that we thought app
writers might need. Web pages can load other pages and pass parameters to
them via URI query params or POST. When you're offline that won't work. Our
solution to this is that query parameters in JAR URIs are ignored, so jar:
http://foo.com/foo.jar!/query.html?bar=baz just loads jar:
http://foo.com/foo.jar!/query.html, but script in query.html can access the
query parameters via document.location, and dynamically generate content
that the server would otherwise have provided. I think an WHATWG solution
should cover this case somehow.

I am not sure what you mean by the resource store being writeable. It lets

you tweak the set of items stored, but you can't construct an item with
headers and data and all by hand.



You can copy, delete and rename items in the cache. I guess I should have
said "mutable" instead of "writable".

It does overload file insertion into the local store, which is perhaps

needlessly complex, but you do want a way to access a file picked by an
HTMLInputElement without having to round-trip it to the server. Perhaps that
feature would be better served by API on HTMLInputElement instead.



Agreed. That would be very useful for regular Web apps as well.

[whatwg] Offline Resources

[Robert O'Callahan]

*Maciej Stachowiak wrote:
*


I think the
Google Gears design for this works better than the Mozilla design,
because it lets offline mode use all the same URIs as regular mode,
so the offline support can be cleanly factored from the rest of the
web app.

It's not that bad, if your app avoids using URIs with protocol or domain

in them. As a proof of concept we modified Zimbra to use our API; we just
put its files into a JAR and things worked.

Having said that, it would certainly be nice to be able to get some kind of
consistency without JARs.


I think we should discuss the right standards approach
further, though I'm somewhat surprised that Mozilla hasn't brought
their work so far to the standards process before now.

Sorry ... first we wanted to get some experience with the API, then we

were busy. So do you have any comments on Dave's doc?

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

[whatwg] Google Gears and HTML5

[Robert O'Callahan]

Chris Prince wrote:


Gears returns an error when you first try to setup an ambiguous
capture.

How do you do that when an ambiguity is discovered during a manifest

update?

Since you're here, I'm curious about the motivation for a few of the Gears
features. In particular, what's the use case for "remove", "rename" and
"copy"  in ResourceStore? Also, what motivates the provision of multiple
named stores with independent enable/disable control? What about opening
stores --- is that some sort of approximation to "logging in"? What does it
actually do, given that "the URLs contained in a store are eligible for
local serving without requiring the application to open the store"? When are
stores closed?

Thanks!!

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Google Gears and HTML5

[Robert O'Callahan]

On 6/12/07, Chris Prince <[EMAIL PROTECTED]> wrote:


> what's the use case for "remove"

Without it, once you put a given URL in the ResourceStore, it would be
served from there forever.  Also, remember that the ResourceStore
doesn't auto-update URL contents like the ManagedResourceStore does.

> what's the use case for ... "rename" and "copy"

Sometimes you want to return the contents of one real-world URL (like
http://example.com/) in response to a different URL request (like
http://example.com/?offline=1).  The "rename" and "copy" methods let
you do that.



Why can't the app just request the resource from the server with the correct
URI to start with?

I'm a bit fuzzy on the use cases you have in mind for ResourceStores in
general.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Google Gears and HTML5

[Robert O'Callahan]

On 6/12/07, Aaron Boodman (Google) <[EMAIL PROTECTED]> wrote:


On 6/11/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> Chris Prince wrote:
> How do you do that when an ambiguity is discovered during a manifest
update?

That's a good point, i think all we could do there is throw into the
environment, which isn't particularly useful, but would at least
prevent the ambiguity.



What do you mean "throw into the environment"? The update might occur
automatically in which case I'm not sure where an exception would go. And it
seems that preventing the update might lead to the app being unrecoverably
"stuck".

* Rename/copy were motivated by a particular problem we had with an

internal app that we were playing with. When you would capture files
using the file upload api while offline, you would need to rename them
after you found out the primary key of the entity on the server
because the application would build the URIs based on these PKs. This
probably could have been solved other ways on the server.



I think the best way to handle file uploads (in an HTML5 context) is to
provide an API that any Web app can use to directly read the contents of a
file input control. That seems conceptually simple and also potentially
useful to all kinds of Web apps, online and offline.

I agree that having overlapping URLs is a pain with the current

design. It would be nice if URLs were unique. What we found is that in
many applications, URLs aren't unique. Localization is one example of
this, but there are many. I think it may not be necessary to have both
enable/disable *and* requiredCookie, but we probably need something.
requiredCookie just removes some of the legwork of toggling a bunch of
stores on and off on each login.



What are the other uses? Are they all situations where the content for a
given URI is stable within a given "logon session"? (As you would expect if
cookies are sufficient to discriminate between the different contents...)

I think restricting URIs to map to just one resource simplifies things a
lot. Another simplification that our model has is that offline resources are
never directly mutated by the client; they are always just a snapshot of
server state. These two properties are very appealing... We can also safely
support cross-domain offline loads (e.g. to get canonical library scripts,
or looking forward to WHATWG-style messaging APIs, cross-domain
communication) which I think is hard to do without the latter property.

I think we can extend our model to support Gears-style consistency without
JARs by adding support for manifests somehow (e.g. ), and then requiring that all offline resources in a
domain (that are used by apps in the same domain*) be updated atomically
roughly the same way Gears does it. But I need to talk to Dave about it...
(* Applications using cross-domain loads don't get any consistency
guarantees for those loads. For example we don't want someone randomly
referencing a missing file under example.com and breaking updates of
example.com's own applications.)

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

[whatwg] Gears design goals

[Robert O'Callahan]

Aaron Boodman wrote:


* To support seamless (non-modal) transitions between online, offline,
and the browser-is-confused-and-thinks-you're-online-but-really-you're-not
(wireless that you have to login to, slow DNS, and crashed servers
that are serving 500s are all good examples of this last situation).
* To allow users to access the application from the same URL whether
they are online or offline.
* To support atomic updates of applications so that you always have a
consistent version when you go offline.
* To allow the capture of arbitrary URLs. The canonical example would
be attachments in web mail.
* To allow the capture of file uploads for later re-posting to the
server. Again, think web mail.
* Good, webby, autoupdating characteristics. We didn't want it to be
possible for web developers to push a broken version of their app
which could never get unbroken. In fact, we would love this to be as
close to webby as possible, without sacrificing the goal of always
being in a consistent state.
* Simple enough to use without sophisticated server-side
infrastructure (again, you can think of this as webbiness -- we want
developers to be able to author this with Notepad).
* To make it as simple as possible to migrate existing AJAX
applications to be offline-enabled.

Agree on all those.



- One major issue that we found here was that lots of existing
applications serve different resources at the same URI depending on
who is logged in. We could ask these applications to redesign so that
they don't do that, but we would prefer to not have to.

Understood, but this seems to add substantial complexity to the model. Is

it really a big deal to restrict users to one login available offline? A
browser can of course support multiple profiles or something similar to
address that use case without complicating the development model.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] The issue of interoperability of the element

[Robert O'Callahan]

On 6/27/07, Jerason Banes <[EMAIL PROTECTED]> wrote:


The question that I hate to ask (because it goes against my own grain to
ask it) is, which is more useful to the web market: Asking Windows users to
install Ogg/Theora codecs



Actually, we just ask them to install Firefox :-)

or asking Linux users to install H.263 codecs?




If they can't do it legally, that is a tough thing to ask for.

The bottom line is what Maik said in another message: Theora is the only
option right now for implementation by free software, so that's what Mozilla
will push as the best format for an open Internet.

I hope we will also support codecs installed on the user's OS, thereby
getting pretty wide (but not universal) support for MPEG4 etc, but we don't
have the resources to implement that for Firefox 3.

This discussion is not really adding anything new...

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/27/07, Aaron Boodman <[EMAIL PROTECTED]> wrote:


Great! So where do we differ on the implementation of those goals? Is
there an up-to-date spec I can read?



http://www.campd.org/stuff/Offline%20Cache.html

Right now I think we're missing just one thing from your list of goals
(excluding the vexatious "multiple resources for one URI" goal): a way to
get consistent updates without relying on JAR files (and hence changing
URIs). As I mentioned earlier, I think we can get that by simply stating
(and implementing!) that updates to all offline-cached resources in a domain
--- that were requested by pages in the same domain ---  occur atomically as
a group, similar to what Gears does. That leaves one issue, which is the
ability to add new resources as part of such an atomic update; to get that,
we probably should add an offline-manifest DOM API or  type, which
pulls in a JSON manifest and requests all the resources in it.


> - One major issue that we found here was that lots of existing
> > applications serve different resources at the same URI depending on
> > who is logged in. We could ask these applications to redesign so that
> > they don't do that, but we would prefer to not have to.
> >
> Understood, but this seems to add substantial complexity to the model.
> Is it really a big deal to restrict users to one login available
> offline? A browser can of course support multiple profiles or
> something similar to address that use case without complicating the
> development model.

If apps are to be able to transition between online and offline
seamlessly, that implies that the browser always serves the cached
version and revalidates in the background, right?



Yes.

If so, that means apps can't serve different resources at the same

URL, even when a connection is available, which seems like a big
constraint.



Sure they can. The user can only have one active login per browser session
anyway, so the app just swaps in a whole new set of resources when the user
logs in with a different ID.  The only restriction is that when the user's
offline, they'll only be able to use the last ID that they logged in as.

OTOH, I believe that if I were creating a new Gears-enabled app from

scratch, I would not use requiredCookie. In fact, I didn't for
Gearpad. There is only one version of Gearpad for all users, and it
pulls in the required user-specific resources dynamically.



Let me put the strongest spin on this that I can :-) --- I'm reluctant to
substantially complicate the API for implementors and developers for all
time, just so that some legacy apps can have an easier transition for the
specific case of supporting multiple logins while the user is offline.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] The issue of interoperability of the element

[Robert O'Callahan]

On 6/27/07, Nicholas Shanks <[EMAIL PROTECTED]> wrote:


On 27 Jun 2007, at 09:28, Maik Merten wrote:
> Browsers don't rely on the OS to decode JPEG or PNG or GIF either

In my experience that seems to be exactly what they do do—rely on the
OS to provide image decoding (as with other AV media).
I say this because changes that had occurred in the OS (such as
adding JPEG-2000 support) are immediately picked up by my browsers.



You do not know what you are talking about. Firefox does not use OS image
decoders.

likely to be slower and buggier than the free decoding

component written by the codec vendor themselves



We use official Ogg Theora libraries.

and detracts from the time available for implementing other browser changes.


No-one's suggesting reimplementing codecs. We're talking about integrating
existing codecs into the browser, and shipping them with the browser.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] The issue of interoperability of the element

[Robert O'Callahan]

On 6/28/07, Nicholas Shanks <[EMAIL PROTECTED]> wrote:


For your future reference, Robert, the browsers I am familiar with and was
referring to in my statement about image decoders are WebKit-based browsers,
OmniWeb 4.5 (historically), Camino and iCab 3. I avoid FireFox and Opera
due to their non-native interfaces and form controls.Given your statement
I may be incorrect about Camino though.



You are.

If we're going to make sweeping statements about how browsers work, let's
make sure we include IE, Firefox and Opera in our data.


We use official Ogg Theora libraries.
No-one's suggesting reimplementing codecs. We're talking about integrating
existing codecs into the browser, and shipping them with the browser.

This is only possible if the codec is free. I thought we were talking
about the problem of adding non-free codecs (namely WMV and MPEG4) to free
software, (possibly also involving reverse-engineering the codec).



No-one's suggesting that. As Maik points out, reverse engineering is a dead
end. Shipping a binary codec with, say, Firefox is a theoretical
possibility, but for many reasons it's very unlikely to happen.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/30/07, Andy Palay <[EMAIL PROTECTED]> wrote:


So I don't know why one would want to maintain atomicity at the domain
level as opposed to the application level. When I run an application I want
to make sure I get the latest version of the application. Not sure why it
would mean that I want to make sure that I update all the applications from
that domain.



Simplicity, mainly. Scoping updates (and the offlineResources list) to the
domain level means we don't have to define a new abstraction that delimits
application boundaries. And it lets us avoid any issues with partially
overlapping applications.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/30/07, Andy Palay <[EMAIL PROTECTED]> wrote:


On Jun 26, 2007 4:26 PM, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> Sure they can. The user can only have one active login per browser
session
> anyway, so the app just swaps in a whole new set of resources when the
user
> logs in with a different ID. The only restriction is that when the
user's
> offline, they'll only be able to use the last ID that they logged in as.


The problem with this is what happens when two users share the same
machine.  Not unusual with families and laptops.

So my kid and I both have an offline enabled version of a application X.
My kid was the last one runing X before leaving on a trip. I open the laptop
and fire up X. From what I believe you said, I can't see my version of X.
This is a problem if the versions are actually different.



For this scenario people can use OS user switching or browser profiles ---
or, of course, the Web app can be modified to avoid giving multiple
resources the same URI.

(My eldest son is five years old and already I can see that letting him
share my browser session is a bad idea :-) )

One could (as Aaron did for Gearpad) down load all the code and dynamically

use it depending on the user, but that can be expensive to do, especially as
applications grow in size. For example in our initial tests it bacame clear
that we would download different resources depending on the language setting
for the user. You would not want to download all the languages for the
application. If the user changed languages then we would recapture the
application. Yes this does limit the user from changing languages when
offline, but changing languages is a rare event and forcing the user to be
online seemed to be a reasonable tradeoff.



I'm not quite sure what you're getting at, but let's suppose a Web app does
want to support multiple users sharing a single offline browser profile and
those users need different languages. (I think this is already a rather
narrow scenario, FWIW.) We'd ask the app author to give user-specific
resources user-specific URIs. For resources, such as help pages, that are
language specific but not user specific, we'd ask the author to give them
language-specific URIs (e.g. including /en/ or whatever). Each user's
manifest pulls in the appropriate resources, and precisely the required
language resources are downloaded.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote:


On 6/26/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> Right now I think we're missing just one thing from your list of goals
> (excluding the vexatious "multiple resources for one URI" goal): a way
to
> get consistent updates without relying on JAR files (and hence changing
> URIs). As I mentioned earlier, I think we can get that by simply stating
> (and implementing!) that updates to all offline-cached resources in a
domain
> --- that were requested by pages in the same domain ---  occur
atomically as
> a group, similar to what Gears does. That leaves one issue, which is the
> ability to add new resources as part of such an atomic update; to get
that,
> we probably should add an offline-manifest DOM API or  type, which
> pulls in a JSON manifest and requests all the resources in it.

That sounds good. Gears team has also considered that you could get
consistent versions without the hard version number we currently have
in the manifests.

It seems like right now, all items in a domain implicitly form an
atomic group. Is that right?



"Right now" as in what I've proposed, yes. Not "right now" as in what's
implemented on Firefox trunk :-)

A slight twist is needed actually: an atomic group consists of all resources
in a domain that are used by pages in the same domain. We allow cross-domain
references but we do not allow them to create consistency requirements.

A couple issues some Gears people brought up with this:


* It's likely to significantly slow down revalidation. There could be
many, many resources linked with the programmatic api (again, think of
attachments). All these would have to be revalidated each time the app
is viewed.



For the specific case of attachments, in our model those could be placed in
their own domain. For resources where you actually want to access the
contents on the client, wouldn't work.

* It seems like atomic groups and domains are not 1-to-1. Lots of

times separate applications are hosted on the same domain but in
different directories. I guess it's not dangerous to revalidate all
apps under a domain when any are viewed, but it seems like a waste.

You could mitigate the first issue by allowing the developer to say
whether a certain resource should be part of the domain's atomic
group. I am not sure how to mitigate the second issue except for by
telling developers to use separate domains for separate applications.



That's what I would suggest, yes.

Another thought that we had was that it would be good if whatever you

can do with the  tag syntax, you can also do programmatically.
It may be difficult to hook into IE deep enough to implement the link
tag syntax.



I think we're there already (although in our proposal, all you'd have to do
is traverse the  tags on onload, dynamic changes to the link tags
after that have no effect).

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote:


I think as you tried more and more languages, you'd get more resources
associated with the domain. And so the number of resources that would
need to get revalidated on each view of the app would get larger.



I don't think so --- just serve a manifest for each user that lists the
resources for that user's language only. Is there a problem with that I'm
not seeing?

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote:


On 6/29/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote:
> > I think as you tried more and more languages, you'd get more resources
> > associated with the domain. And so the number of resources that would
> > need to get revalidated on each view of the app would get larger.
>
> I don't think so --- just serve a manifest for each user that lists the
> resources for that user's language only. Is there a problem with that
I'm
> not seeing?

Manifest? I thought we were talking about the Mozilla proposal.



I mentioned earlier that to get consistent updates without JARs, we have to
add manifest support. Dave is working on it. I think he's following the
Gears manifest format. Speak up Dave :-)

If you visit http://a.com and it serves you a page linking to:

base.js
en/1.html

And then later you come back and it serves you a page linking to:
base.js
fr/1.html

You have to revalidate all three files, right? You don't know whether
en/1.html depends on base.js.



You mean the other way around?

In this case http://a.com would have to list all resources used by the
application. If en/1.html is no longer listed, it is not used by the
application (i.e. not used by base.js) and will not be revalidated.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/30/07, Andy Palay <[EMAIL PROTECTED]> wrote:


But it does place a very large burdon on the servers. Google would expect
to have quite a few applications and my guess is the last thing we would
want is to keep pinging every application to see if it up to date whenever
any application is used.



My Google apps currently use mail.google.com, docs.google.com,
picasaweb.google.com ... Calendar uses www.google.com, I don't know why :-)
So most of these apps have their own domains, and won't face a problem here.
Is it overly burdensome to put separate apps in their own domains?

If it is, then I would suggest simply allowing consistency to be partitioned
by directory as well. I'm not sure of the best way for the server to
configure that, though.

In fact while we want to make sure the user has the most up to date version

we don't need to check on every use. In most cases the current captured
version will be fine. The only time that is not the case is when the old
version has been made obsolete by a newer version. Unfortunately this can
occur at anytime, including when the application is running. So in that case
the server needs to tell the client application that it has to force an
immediate reload. So the client can always run the currently saved app,
check for updates at a convenient time (and in reality not too often).



Yep.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 6/30/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:


If it is, then I would suggest simply allowing consistency to be
partitioned by directory as well. I'm not sure of the best way for the
server to configure that, though.



One option would be to use an HTTP header to allow each resource to say what
consistency group it belongs to. Say "X-Consistency-Group:
http://www.google.com/calendar";. When the header is omitted the default is
just the scheme + domain.

This would have the nice property that if a browser doesn't implement
support for the header, everything still works, revalidation is just slower.

For resources like attachments where you don't want consistency, you could
just set X-Consistency-Group to the resource's own URI.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 7/1/07, Aaron Boodman <[EMAIL PROTECTED]> wrote:


On 6/29/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> > Manifest? I thought we were talking about the Mozilla proposal.
>
> I mentioned earlier that to get consistent updates without JARs, we have
to
> add manifest support. Dave is working on it. I think he's following the
> Gears manifest format. Speak up Dave :-)

Ok, then I believe we have gotten out of sync. Can you update the spec
that you pointed me to earlier with your latest thoughts (I don't see
the word 'manifest' in there)?



I'm sure Dave will update it with his ideas and let us know when that
happens...

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears design goals

[Robert O'Callahan]

On 7/1/07, Andy Palay <[EMAIL PROTECTED]> wrote:


As for the burden to put apps in their own domain -  First it seems to be
an unnecessary requirement. I build an app, I choose a URL as I normally
would and I would hope everthing would work out fine. Second it doesn't work
well for environments where access to the domain is not possible. Consider
the case of internal corporate apps. People post new web apps using their
'individual' internal corporate web server. They can choose whatever name
they want. What they don't have is access to the domain in order to do
this.  I grant that this scenario is currently not well supported by the
Gear's security model (something that I believe will need to change), but it
is a real use of technology.



I'm not really sure what this scenario entails, perhaps because I don't know
what you mean by "individual internal corporate web server" ... can you be
more specific?

If it is, then I would suggest simply allowing consistency to be partitioned

> by directory as well. I'm not sure of the best way for the server to
> configure that, though.
>

I'm still not sure why not have consistency enforced at the application
level. This way an application can pull code from whereever it needs to
regardless of the directory structure.



Because it's more complex: we need new APIs to define what an application
boundary is, those APIs have to be interoperably implemented, and we have to
make sure that overlapping boundaries are not allowed, or if they are
allowed, we have to define how that overlap is handled in a sensible way.
We've already seen an unanticipated problem arise because a manifest update
can create overlap.

I appreciate that providing flexibility to application developers is a good
thing. But reducing complexity is also a good thing, for implementors and
actually for application developers too. This is the tradeoff we must
wrestle with.

(I quite like my X-Consistency-Group suggestion because it can be ignored by
Web authors and/or browser implementors without breaking anything, and by
design it cannot lead to overlapping consistency boundaries.)

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears caching at identical URIs (was: Gears design goals)

[Robert O'Callahan]

On 7/2/07, Robert Sayre <[EMAIL PROTECTED]> wrote:


Basically, I think offline caches should respect the Vary: HTTP
header, and maybe more. Applications will need to do this right
anyway, if they want to function correctly in the presence of ISP HTTP
proxies (AOL, TMobile, etc),  corporate firewalls, and server-side
stuff like Citrix Netscalers.



No they don't. For example, they can just use Cache-Control:private to
bypass those caches. That's what GMail does.

To me, it looks like the caching mechanisms in HTTP 1.1 can satisfy

this requirement. I think Rob is correct that it adds substantial
complexity, but it is already required.



In what way is it already required? Browsers are not required to store
multiple resources for the same URI. We don't; we just use Vary to help
(in)validate the resource we've got.

So how would you use Vary here, anyway? Serve pages with "Vary: Cookie"? I
guess that could work, but app authors would have to pass no cookies except
for the session cookie. That could be difficult.

Using an HTTP response header to specify how a URI can map to multiple
resources is a good idea, though. It avoids ambiguities and offers a simple
default. If we have to have that feature, this seems like a good way to do
it.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears caching at identical URIs (was: Gears design goals)

[Robert O'Callahan]

On 7/3/07, Robert Sayre <[EMAIL PROTECTED]> wrote:


On 7/2/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> On 7/2/07, Robert Sayre <[EMAIL PROTECTED]> wrote:
>
> > Basically, I think offline caches should respect the Vary: HTTP
> > header, and maybe more. Applications will need to do this right
> > anyway, if they want to function correctly in the presence of ISP HTTP
> > proxies (AOL, TMobile, etc),  corporate firewalls, and server-side
> > stuff like Citrix Netscalers.
>
> No they don't. For example, they can just use Cache-Control:private to
> bypass those caches. That's what GMail does.

Yes, I should have mentioned that I don't think an Offline API will be
able to handle Cache-Control:private stuff better than other proxies
unless it reinvents other HTTP caching mechanisms.



I don't know what you mean. Offline storage is a private cache and can
ignore Cache-Control:private.


> To me, it looks like the caching mechanisms in HTTP 1.1 can satisfy
> > this requirement. I think Rob is correct that it adds substantial
> > complexity, but it is already required.
>
> In what way is it already required? Browsers are not required to store
> multiple resources for the same URI. We don't; we just use Vary to help
> (in)validate the resource we've got.

I mean that it is required for web application authors that want to
scale cheaply and have personalized pages. I don't think you agree
with me.



The first app I checked (GMail) doesn't use Vary. If people aren't using it,
it can hardly be a requirement. Actually I'm skeptical that Vary helps much
with scalability, even if it works interoperably across browsers and caches:
presumably most content is going to have one global instance
(Cache-Control:public), or one instance per user (Cache-Control:private).
"Vary" only helps you cache content that falls in between. Do you know of
any examples of such content in existing apps?


So how would you use Vary here, anyway? Serve pages with "Vary: Cookie"? I
> guess that could work, but app authors would have to pass no cookies
except
> for the session cookie. That could be difficult.

Or you could standardize the cookie value in some way.



I thought about just specifying a standard session cookie name which always
becomes part of the cache key along with the URI ("HTML5-Session" or
something). But that doesn't work well, e.g. if you want some content to be
indexed by user and some content to be indexed by language.

A simple alternative would be a new server response header, say
X-Vary-Cookie: , which essentially means "Vary" for that
particular cookie (and offline storage uses it as a cue to cache one
resource per cookie value).


Using an HTTP response header to specify how a URI can map to multiple
> resources is a good idea, though. It avoids ambiguities and offers a
simple
> default. If we have to have that feature, this seems like a good way to
do
> it.

Etag and Content-Location could be used.



I think they're unnecessary given the above proposal.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Gears caching at identical URIs (was: Gears design goals)

[Robert O'Callahan]

On 7/3/07, Robert Sayre <[EMAIL PROTECTED]> wrote:


On 7/2/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> On 7/3/07, Robert Sayre <[EMAIL PROTECTED]> wrote:
> > On 7/2/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> > > On 7/2/07, Robert Sayre <[EMAIL PROTECTED]> wrote:
> > >
> > > > Basically, I think offline caches should respect the Vary: HTTP
> > > > header, and maybe more. Applications will need to do this right
> > > > anyway, if they want to function correctly in the presence of ISP
HTTP
> > > > proxies (AOL, TMobile, etc),  corporate firewalls, and server-side
> > > > stuff like Citrix Netscalers.
> > >
> > > No they don't. For example, they can just use Cache-Control:private
to
> > > bypass those caches. That's what GMail does.
> >
> > Yes, I should have mentioned that I don't think an Offline API will be
> > able to handle Cache-Control:private stuff better than other proxies
> > unless it reinvents other HTTP caching mechanisms.
>
> I don't know what you mean. Offline storage is a private cache and can
> ignore Cache-Control:private.

Seems to me that if you are worried about users seeing content
intended for other users, it isn't a private cache.



It's private as far as HTTP is concerned: private to one client application.
The fact that Web applications are supporting multiple "users" sharing the
browser cache isn't relevant.

Rob
--
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On 8/24/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> * Do we really need a way to ignore the query parameters when
>fetching and serving from cache when offline? (The idea below assumes
>not. I don't really understand the use case if the answer is yes.)


Yes. Suppose Bugzilla had offline support. The Bugzilla UI has a bunch of
links it with with different query parameters (e.g., bug numbers). Bugzilla
running offline could take those parameters and use them to look up a local
database and populate the DOM.

Maybe if we force offline apps to all be single-page then this isn't an
issue but I don't think that's a good idea.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On 9/8/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> Given that you'd have to radically rewrite the app anyway to use an
> offline database instead of just using HTTP, why would we reuse the URI
> query syntax feature? It seems like it'd be better (from a consistency
> with existing specs point of view) to use the fragment identifer. No?


That's an option, but then you can't use the fragment identifier for its
scroll-to behaviour when you use it to pass parameters. Also, when
retrofitting an existing app, this requires changing the sources of links as
well as the destination pages.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On 9/10/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> On Mon, 10 Sep 2007, Robert O'Callahan wrote:
> > That's an option, but then you can't use the fragment identifier for its
> > scroll-to behaviour when you use it to pass parameters.
>
> You can just pass the scroll position as one of the parameters.


Hmm...

Here's a real-life example:
https://bugzilla.mozilla.org/show_bug.cgi?id=389437#c3
Now if we refit Bugzilla for offline support, this will become something
like
https://bugzilla.mozilla.org/show_bug.cgi#id=389437,c3
If we want the same URIs used both offline and online (which I strongly
believe is required), then for things to work when script is disabled, the
query parameters have to be stuffed into the "name" attributes. I guess
that's OK although it's a bit annoying.

> Also, when retrofitting an existing app, this requires changing the
> > sources of links as well as the destination pages.
>
> That seems like a minor issue, compared to the scale of the effort.
>
> I'd be interested in studying an actual example of what this would entail.
> Do people feel strongly about wanting this dichtomy between the online
> version and the offline version? Fundamentally, I feel quite strongly that
> we'd want them to use the exact same code all the time.


I'm just saying these are extra things that would have to be changed when
making an existing app offline-capable.

This isn't a big deal to me, authors can use the fragment identifier, it's
just ugly.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On 9/10/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> Why wouldn't you just offline-cache the
>https://bugzilla.mozilla.org/show_bug.cgi?id=389437
> ...file?


I might be storing its data in a local database so I can make changes to it
locally while I'm offline.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On 9/11/07, Dimitri Glazkov <[EMAIL PROTECTED]> wrote:
>
> Since, AFAIK, the fragment identifier is not passed onto the server by
> the UA, I can't see how an application could be designed with proper
> noscript degradation and reliance frament ids for query communication.
>
> Besides, using query parameters is much more natural for HTML: forms
> with method=get are the way to build it.


Those are good points that I should have thought of :-).

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps with Open-Ended URI Spaces (was Re: Offline Web Apps)

[Robert O'Callahan]

On 9/20/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> 2) Many offline web apps will let you want to make changes, including
> not just changing existing items, but also creating new items. To do
> this, at minimum there needs to be an API to inject a new resource
> into the offline cache programatically, with the data explicitly
> provided.


This violates the principle that the offline cache is a cache. It creates
the issue of how to reconcile server pages with client-stored pages.

6) It's potentially costly to download data mulltiple times, so if you
> pull the remote data into a local database, you won't also want to
> pull every page reflecting that data, instead you will want to
> generate templates client-side and insert them into the offline cache.
> However, it seems like a relatively small step from there to having a
> single fallback page to be used for all URIs that are part of the app
> but haven't gotten downloaded in the course of normal use. And this
> would be a huge optimization, since it would save the client the need
> to manually generate each page for a resource of interest that has not
> yet been visited.
>
> Given point #1, I think this should be based on textual prefix
> matching of the URI, not just dropping the query (the scheme and
> authority sections should be treated specially, of course, it should
> not be allowed to have a fallback page in someone else's security
> domain). This will allow matching paths and also matching only
> specific kinds of queries (where the first parameter is set to some
> specific value, say). However, to make offline and online mode diverge
> as little as possible, I think perhaps such fallback pages should
> apply only when offline. When online, the UA should go to the real
> page. With the prefix-based fallback page solution, I'm not sure it
> will be necessary to also support individual client-generated pages.

Thoughts?


It sounds reasonable to me, a lot better than option 2).

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

I haven't had time to study Ian's proposal properly yet, sorry. But some
easy comments:

On 9/20/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> > Upgrader:
> > Create a hidden browsing context.
> > Load the upgrader in it.
>
> I don't like this whole upgrader idea. Parsing HTML and CSS and
> executing JavaScript seems like an inefficient way to do an app
> update. I think it is reasonable to require a manifest file for
> multipage apps, and writing an HTML/CSS/JS upgrader that can cover all
> pages of a multipage app does not seem significantly easier than
> creating a manifest file. The implicit manifest idea seems handy as a
> quick way to handle one-page apps but it does not seem reasonable for
> the multipage case, and this would obviate the need for an upgrader.


I totally agree with this.

> Just before onload, fire an 'upgrading' event to every instance of a
> >  top-level page using a cache with the same identifier.
>
> Whether or not there are upgraders though, I think events should
> dispatch when a manifest-based upgrade either completes or fails (and
> perhaps also when the upgrade starts).


Agree...

> The event has a handle to the Window object of the hidden browsing
> >  context.
> > After every 'upgrading' event has been fired, the 'load' event must be
> >  fired on the upgrader.
> > After that happens, if any of the aforementioned instances are still
> >  using old versions of the cache, then the user agent may inform user
> >  they can reload to update.
>
> I think it would be preferable to let the apps upgrade themselves
> instead. They could choose to use location.reload() if they are not
> holding any interesting state, or they could offer to save the user's
> state before doing this, or they could make some alternate call that
> requests all new resource loads for this instance should come from the
> freshly upgraded cache, which would let it perform an upgrade manually
> preserving current state if feasible.


Agree.

> The Upgrader can do such things as updating the database schema
> > between
> > versions, and when there are multiple instances running, it allows
> > them to
> > negotiate who will do that work instead of it happening several times.
>
> I would suggest instead that the instance that triggered the upgrade
> be given a special event so that it can do this and could optionally
> present in-page UI while doing so. This seems simpler than adding a
> hidden browsing context. Changing the schema may require pausing other
> instances, however, if there is no way to lock the database.


Agree.

> Modal alerts (window.alert, .prompt, etc) in the background page can
> > either raise an exception, be ignored, drop a message to a console, or
> > possibly display a message over the top of the foreground app's
> > browsing
> > context.
>
> To avoid such complexities it would be better to avoid the idea of a
> hidden upgrader. And in-page UI could be more tasteful than prompts or
> alerts.


Agree.

I'm not sure if an API to introspect what is currently in the cache is
> needed. I can't think of a use case off hand. But both the Google
> Gears LocalServer API and the Mozilla offline API have this.


Two different use cases:
-- If you can programmatically force URIs into the offline cache, then you
want to be able to enumerate the resources in the offline cache, otherwise
there is no way to reliably remove unneeded resources (especially if there
was an older, buggy version of the app that may have loaded resources from
unexpected URIs).
-- Several Web app authors have asked for the ability to test whether a
resource is cached, for their online apps. For example, when you're zooming
in and out of a map, the application could choose which tile(s) to use for
the animation by scaling them up or down. This would also be convenient for
offline use, where a resource might not necessarily be in the offline cache
but you could use it if it happened to be available.

A la the Google Gears API, I also think a feature is needed to do
> something useful with  when offline, to save a
> resource for later upload to the server. Preferably this should not
> require round-tripping the data through an ECMAScript string or number
> array, or it will be too inefficient to work for large files.


Actually we have an experimental API for this now. See here:
http://mxr.mozilla.org/seamonkey/source/dom/public/idl/html/nsIDOMNSHTMLInputElement.idl#55
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFileList.idl
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
The core is:

  readonly attribute DOMString fileName;
  readonly attribute unsigned long long fileSize;

  DOMString getAsText(in DOMString encoding);
  // raises(FileException) on retrieval
  DOMString getAsDataURL();
  // raises(FileException) on retrieval
  DOMString getAsBinary();
  // raises(FileExceptio

Re: [whatwg] Latest proposal for offline web app API

[Robert O'Callahan]

On 9/21/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> Provide methods and/or properties for the following:
>
> * Add a resource to the cache. The resource persists (it's a
>permanent addition to the manifest.)


So if an update retrieves a new version of the manifest from the server,
what will happen to dynamically added resources?

Nondeterminism about which cache might be used to serve a given URI seems
highly undesirable to me. This could easily lead to interoperability
problems.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On 9/23/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> Obviously, if the way to get the contents as text requires providing
> the encoding, then it has to be a method. My comment was about the no-
> argument methods. But you have a point that reading from disk is not a
> simple get operation. Probably the methods should have names based on
> read or the like (read(), readAsText(), etc) to indicate this. Also,
> they should arguably be asynchronous since reading from the disk can
> be slow, especially for large files, and it is undesirable to block
> the main thread.


For small files, synchronous reading is OK. Perhaps there should be a
separate whiz-bang asynchronous API ... it could support partial reads too.

Also, I'm not sure how a web app can be expected to know the encoding
> of a text file on disk.


The same way that any other app does --- guess based on the extension and
expected usage? --- now that we've all standardized on meta-data-less file
systems :-(. I suppose an app could examine the first chunk of the file and
then re-read the file with a better guess.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

Ooops

On 9/25/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> On Sep 24, 2007, at 10:45 PM, Robert O'Callahan wrote:
> So I suspect that, much like synchronous XMLHttpRequest, synchronous file
> reads will lead to excessive UI lockups in bad circumstances unanticipated
> by the app author.
>

The file size is accessible to the app author. But OK, lets add an
asynchronous API.

What's the best way to do that?  Add an onread event to File and, say, "void
read(long offset, long length)"? Or something with an explicit callback such
as setTimeout has? (Although I'm not sure how we write such things in
standard IDL.)

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On 10/10/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

> On Fri, 21 Sep 2007, Robert O'Callahan wrote:
>
> -- Several Web app authors have asked for the ability to test whether a
> > resource is cached, for their online apps. For example, when you're
> > zooming in and out of a map, the application could choose which tile(s)
> > to use for the animation by scaling them up or down. This would also be
> > convenient for offline use, where a resource might not necessarily be in
> > the offline cache but you could use it if it happened to be available.
>
> Interesting. This isn't covered yet, should we add it immediately?


I think it should be added *somewhere*, but it doesn't have to be part of
the offline spec itself (although it is particularly useful when you're
offline).

We have an experimental implementation:
http://mxr.mozilla.org/seamonkey/source/dom/public/idl/base/nsIDOMClientInformation.idl#55
That's ... underdocumented ... but the idea is this:

boolean <http://mxr.mozilla.org/seamonkey/ident?i=boolean>
isLocallyAvailable
<http://mxr.mozilla.org/seamonkey/ident?i=isLocallyAvailable>(in
DOMString <http://mxr.mozilla.org/seamonkey/ident?i=DOMString> uri
<http://mxr.mozilla.org/seamonkey/ident?i=uri>, in boolean
<http://mxr.mozilla.org/seamonkey/ident?i=boolean> whenOffline);

It should return true when the browser will load the resource given by the
URI without contacting the network. If 'whenOffline' is true then this
putative load is assumed to happen while the browser is offline/using its
offline caching functionality, if any. This is intended to allow an app to
predict, while the user is online, what loads will succeed when the user
goes offline, and in Gecko, for example, we do not perform HTTP cache
validation while the browser is in offline mode, so a page might be locally
available in offline mode but not in online mode. But we could probably get
rid of this parameter if people think it doesn't make sense.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On Oct 12, 2007 12:53 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> The problem with isLocallyAvailable() -- as noted by Maciej on IRC -- is
> mostly one of race conditions. What if the resource was removed in between
> you asking for it and using it? Or added?
>

In the contexts for which it was requested, race conditions are tolerable.
For example in a mapping application, if you choose the wrong tile as a
template for zooming, then you get an ugly transition but that's all. Or you
might have a button that opens another offline application, and you want to
disable the button if you think that application is not available; here a
race condition would probably mean that the button is enabled but pressing
it gives you an error page. In these cases isLocallyAvailable can be a
useful hint even if it's occasionally wrong.

Or what if you go offline (thus
changing the rules) in between checking for and using the resource?

That's why we have the 'whenOffline' parameter.

I'm going to punt on this for now, pending implementation and author
> experience. I'm certainly open to suggestions though.
>

That's fine.

A race-free API seems difficult to design. Because loads are typically
asynchronous, I doubt you can do much better than start a regular load, and
set a timer to go off and cancel the load and take other action if the load
doesn't complete "fast enough". Overkill if all you want is the hint, and
since authors can already do that but there's still demand for
isLocallyAvailable, I suspect that's not really what's wanted.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Offline Web Apps

[Robert O'Callahan]

On Oct 12, 2007 9:39 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> On Oct 11, 2007, at 6:47 PM, Robert O'Callahan wrote:
>
> On Oct 12, 2007 12:53 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> > The problem with isLocallyAvailable() -- as noted by Maciej on IRC -- is
> > mostly one of race conditions. What if the resource was removed in
> > between
> > you asking for it and using it? Or added?
> >
>
> In the contexts for which it was requested, race conditions are tolerable.
> For example in a mapping application, if you choose the wrong tile as a
> template for zooming, then you get an ugly transition but that's all.
>
> Seems like wrongly choosing one that is not actually locally available
> would leave a hole in your map.
>

This case was for an online app. The assumption is that either tile chosen
would load "eventually"; the app would choose to base its transition effect
on whichever tile was most likely to be available. I'm told that right now,
they use heuristics based on a completely naive model of the browser cache!

Or what if you go offline (thus
changing the rules) in between checking for and using the resource?

That's why we have the 'whenOffline' parameter.

I don't see how the whenOffline parameter addresses that problem that your
> online/offline state may change between the time you do the check and the
> time you try to load the resource. In fact, I'm not really sure how it is
> helpful, compared to just basing the check on the current online/offline
> state always.
>

Some apps may find it helpful to be able to predict their offline
capabilities even while they're online. For example, an app might want to
indicate what the user will be able to do if they go offline right now.

> A race-free API seems difficult to design. Because loads are typically
> asynchronous, I doubt you can do much better than start a regular load, and
> set a timer to go off and cancel the load and take other action if the load
> doesn't complete "fast enough".
>
> The race-free approach would be to provide APIs to load resources only
> from the cache and to error out immediately if the the request can't be
> served locally. The problem with this is that there are a huge number of
> APIs to trigger a load: frame src, iframe src, window.location assignment,
> window.location.replace, img src, script src, link for a stylesheet,
> XMLHttpRequest, and that's just the obvious ones.
>

Indeed.

Another problem is that if you want to offer a hard guarantee that the
resource will load, you probably want to check not just whether it's in the
cache but also that no other error will occur before the load completes (e.g.
due to a change in the browser state during a load). This might be simple,
or it might not, depending on the browser implementation. In other words,
the race window doesn't end when the load starts, it actually ends when the
load ends IMHO.

I think a way to do an XMLHttpRequest that will only succeed if the data is
> cached would cover many cases, and is probably a reasonable extension to XHR
> (given the text of an html document, script or stylesheet, you can insert it
> into an appropriate element for use). The problem is binary formats, since
> XHR has no good way of returning the data yet and the elements that would
> consume them (img, video, audio, object) have no way to pass in raw bytes
> (using a data: URL to encode it would be poor form for image and probably
> unworkable for video). However, if those elements were extended with some
> way to set raw data then such an approach could work.
>

Yes, but I think you'd want this API to be synchronous for the above
reasons.

>
> At that point, isLocallyAvailable might possibly be useful solely as a UI
> hint, much as the POSIX access() / stat() calls are only useful as UI hints
> for openability. In fact, this is pretty much analogous to the potential
> pitfalls of access() vs. open(). You need to check whether open() succeeds,
> and pass it the right parameters to make sure it will fail if it shouldn't
> succeed, rather than trusting a pre-check with access() or stat().
>

Agreed.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] When to stop elements from playing

[Robert O'Callahan]

On Oct 20, 2007 1:46 PM, fantasai <[EMAIL PROTECTED]> wrote:

> Robert O'Callahan wrote:
> > A related question is whether display:none audio and video elements
> > should produce sound.
>
> No. "display: none" is defined to affect all media, and that certainly
> should not change for  and .
>

I was sympathetic to that, but it may not compatible with playing elements
that aren't in the document. And Jonas was arguing that it's lower overhead
to not create a presentation for  elements, although I think that's a
very minor issue. I don't recall who else was pushing audibility of
display:none elements.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] When to stop elements from playing

[Robert O'Callahan]

On Oct 20, 2007 1:36 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote:

> Robert O'Callahan wrote:
> > After some discussion on IRC, I think Jonas, Hixie and I agreed that
> > we're OK with the following approach:
> > -- sound is produced for display:none elements and elements not in the
> DOM
> > -- removing an element from the DOM automatically calls stop() on that
> > element
>
> Actually, shouldn't that be pause()? Might be good to retain the
> position in case you want to insert the element elsewhere and resume it.
>

Yes sorry.


> > -- tearing down the owner document always stops the element playing (so
> > navigating away from the page always stops sound)
>
> This shouldn't be "tearing down", but rather "leaving", right? A
> document can stay alive long after the user has navigated away from it
> since other frames can be holding it alive.


Yes, well, I was being vague about "tearing down". In Gecko we want bfcached
documents to pause their elements too.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] When to stop elements from playing

[Robert O'Callahan]

After some discussion on IRC, I think Jonas, Hixie and I agreed that we're
OK with the following approach:
-- sound is produced for display:none elements and elements not in the DOM
-- removing an element from the DOM automatically calls stop() on that
element
-- tearing down the owner document always stops the element playing (so
navigating away from the page always stops sound)

Therefore
myAudio = new Audio("foo.wav");
myAudio.onload = function () {
  this.play();
  myAudio = null;
}
will work, and will play until the sound ends or the user leaves the page.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

[whatwg] When to stop elements from playing

[Robert O'Callahan]

Suppose a script creates a  element, adds it to the document, starts
it playing, then removes the element from the document and drops all
references to it. When should the element stop playing?
-- when the element leaves the document?
-- when all JS references to the element have been dropped (and garbage
collection runs)?
-- when the user leaves the page?
-- when the end of the stream is reached? (which could be "never")

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] When to stop elements from playing

[Robert O'Callahan]

On Oct 19, 2007 11:55 AM, Geoffrey Garen <[EMAIL PROTECTED]> wrote:

> > Suppose a script creates a  element, adds it to the document,
> > starts it playing, then removes the element from the document and
> > drops all references to it. When should the element stop playing?
>
> > -- when the element leaves the document?
>
> Probably. Since you can't see the video any more, it would be really
> weird to hear audio from it, or waste computer resources on a mute and
> invisible video. Moreover, there's a lot of precedent for DOM elements
> not loading when they're not in the document. This is true of iframe,
> script, img, etc.


It's not true of . Javascript image preloading tricks rely on it.

And as Maciej mentioned, it would be useful to be able to play audio outside
the document, and to be consistent, 's behaviour should match.


> > -- when all JS references to the element have been dropped (and
> > garbage collection runs)?
>
> No. The time at which garbage collection will reclaim an object is
> unpredictable, so relying on garbage collection for behavior is a bad
> idea.


Agreed.


> > -- when the user leaves the page?
>
> Certainly. But you might want to stop the video sooner.


Agreed.


> > -- when the end of the stream is reached? (which could be "never")
>
> Certainly. (How can you play past the end of the stream?) But you
> might want to stop the video sooner.
>

Agreed.

A related question is whether display:none audio and video elements should
produce sound.

My current opinion is that  and  elements should behave like
 and load/play whether or not they're in a document, but they should
only emit sound if they're in a document with a presentation and are not in
a display:none subtree. Then to play a sound you'd have to insert the
element into your document somewhere with size 0x0 (which should be the
default for ).

But it's a rather tangled issue.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] When to stop elements from playing

[Robert O'Callahan]

On Oct 19, 2007 9:03 PM, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

>   var soundeffect = new Audio("sound.wav")
>   soundeffect.onload = function() { this.play() }
>
> which is what was possible with the old Audio API (became ) Opera
> implemented.
>

When would the Opera stop playing that sound? When the user left the page?
Only when the sound finished?

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] When to stop elements from playing

[Robert O'Callahan]

On Oct 23, 2007 10:02 AM, Geoffrey Garen <[EMAIL PROTECTED]> wrote:

> > -- sound is produced for display:none elements and elements not in
> > the DOM
>
> Does this statement imply that elements producing sound must be
> explicitly protected from garbage collection?
>

Yes.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] Full screen for the element

[Robert O'Callahan]

On Oct 30, 2007 9:20 PM, Dave Singer <[EMAIL PROTECTED]> wrote:

> I think if you can collect keystrokes then phishing is also on the cards,
> alas.
>

FWIW, Flash and Silverlight try to address this by leaving full-screen mode
when keys are pressed.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] several messages regarding Ogg in HTML5

[Robert O'Callahan]

On Dec 12, 2007 9:47 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> > The way i see it there are 3 possibilities so far:
> > - use ogg, possible (but negligable) risk of submarine patents
>
> This is basically as acceptable to companies like Apple as H.264 is to the
> free software community.
>

I don't think so. At any time Apple could make a business decision to assume
the patent risk without changing the way they do business. For the free
software community to accept H.264 we'd need either an appropriate
royalty-free patent license (which would be fantastic, but seems highly
improbable), or we'd have to give up on free software.

Ogg isn't a choice, unfortunately.


That sounds more immutable than it is. Apple and Nokia and others could
change their minds at any time, for example if a large enough quantity of
Theora content emerged that the value to their users balanced the perceived
risk.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]

Re: [whatwg] More random comments on the putImageData definition

[Robert O'Callahan]

On Jan 26, 2008 11:57 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote:

> Another thing that we need is some way to determine what the device
> pixel->css pixel ratio is.  Currently there's isn't even a real way to
> tell that it's 1:1 -- you would have do do a fillRect(width-1,
> height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see
> if they match.  Conceivably you could do this multiple times to
> estimate the ratio, but it would be non-trivial.
>

I think we have to be careful exposing that ratio to Web developers. With
the current ImageData spec it seems too easy for developers to assume a 1:1
ratio, notice that everything works in their tests, and deploy lots of
content which breaks when a browser tries to Do The Right Thing on some
other device, so we'll all just end up having to fix the ratio at 1:1 (or at
least do something equivalent for ImageData).

(Gecko 1.9 allows the ratio to vary in general for Web content, either due
to a high-DPI display device or due to user zooming, and things work pretty
well because there is no way for Web content to detect, or depend on, the
ratio. Unfortunately  doesn't currently change its internal buffer
size to match.)

So for ImageData, how about making the image data array have, by default,
one pixel value per canvas coordinate unit? If we really need to expose a
higher-resolution underlying buffer, then add an API to get the device-pixel
per canvas-coordinate-unit ratio, and extend createImageData and
getImageData so the ImageData array dimensions can be given as optional
extra parameters. Then it would be hard for an author to be surprised by an
unexpected ImageData array size.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] More random comments on the putImageData definition

[Robert O'Callahan]

On Feb 10, 2008 10:07 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote:

> That said, basically what you're saying is that canvas should not support
> hidpi.  At all. There is no need to request the dpi of a canvas, but (and
> here's the critical bit) you can't have get/putImageData work at a different
> resolution from the backing buffer.
>

Why not?

Their sole purpose is to be a 1:1 mapping to the canvas backing store, so
> saying get/putImageData should work in canvas pixels and not device pixels
> seems to defy the whole reason for this API existing.
>

It seems to me the API would still be useful even if it downsampled the
backing store.

I guess we'll just cross our fingers and hope Web developers get it right.
We could implement a higher-resolution canvas backing store for Firefox, but
that wouldn't really help since most developers won't test with a setup that
would trigger it.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] More random comments on the putImageData definition

[Robert O'Callahan]

On Feb 11, 2008 11:37 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote:

>
> On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote:
>
> On Feb 10, 2008 10:07 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote:
>
> > That said, basically what you're saying is that canvas should not
> > support hidpi.  At all. There is no need to request the dpi of a canvas, but
> > (and here's the critical bit) you can't have get/putImageData work at a
> > different resolution from the backing buffer.
> >
>
> Why not?
>
> Because the purpose of get/putImageData *is* to get to the device pixels,
> that's their purpose, making them not do that is both bizarre, breaks the
> semantic that putImageData(getImageData(x,y,w,h), x, y) will leave the
> canvas unchanged
>

Yeah, that makes sense...


> and the cost of sub-/super-sampling removes the whole "speed" thing that
> the API was originally added for.
>

Not so sure about this. Script manipulation of pixel data probably isn't
going to be faster than native, probably hardware-assisted resampling.


>
> Yeah, unfortunately we all know the web authors tend to favour the "it
> works now, so must be correct" philosophy -- it's looking more and more like
> i will be forced to convert the canvas from hidpi to 1:1 the moment any of
> the imagedata/toDataURL routines are used.  *sigh*
>

That would break your sensible invariant that
putImageData(getImageData(x,y,w,h),
x, y) leaves the canvas unchanged.

It would really suck to lock canvas into a 1:1 device-to-CSS pixel ratio
forever. Seems to me putImageData/getImageData isn't worth that risk. Maybe
we should introduce it later when developers are more likely to encounter
the DPI issues for themselves.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] createImageData -> new ImageData() ?

[Robert O'Callahan]

On Feb 10, 2008 11:14 PM, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

> That would mean that passing ImageData around between two 
> elements doesn't always work as expected. I think that's highly
> undesirable. Is there any implementation where we know this will the case?
>

Not yet, but in Gecko when we get around to implementing variable-resolution
canvas backing stores, I expect it would happen because different documents
--- even different documents that can reference each other --- can be zoomed
different amounts, which affects the device-pixels-per-CSS-pixel ratio we
use internally.

It's actually worse than that, because we respond to dynamic DPI changes
(due to zooming or changes in preferences; I'm not sure if we actually
support detection of hardware DPI changes, e.g. due to screen mode
switching, but we easily could). So we might want to dynamically rescale the
canvas backing store.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] More random comments on the putImageData definition

[Robert O'Callahan]

On Feb 11, 2008 11:49 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> If we have one API, high-res only:
>
>   People who use it correctly:
>  get good results both today and tomorrow.
>   People who use it wrongly:
>  get good results today.
>  will get cropped or visibly wrong results tomorrow.
>
> If we have two APIs:
>
>   People who use it correctly:
>  get good results today.
>  may get either ugly results tomorrow, or good results tomorrow.
>   People who it wrongly:
>  get good results today.
>  get ugly results tomorrow.
>   More people will use it wrongly, since it's more complex.
>
> So we trade cropped or visibly wrong results for ugly results, and good
> results for possibly ugly results.
>

Well, "ugly" here actually means "visually just as good as today, but not as
good as the results could be on a high-DPI device".

Whereas "will get cropped or visibly wrong results tomorrow" could be so
serious that browsers simply have to lock in to "ugly mode" forever to avoid
them. Apparently I'm not the only one worried about that.

Maybe the least sucky option is to leave the API as-is, hope nothing bad
happens, and if it does then we do what Oliver suggested and make
getImageData downsample to ensure a 1:1 ratio, breaking the
getImageData/putImageData invariant but oh well. Then later when the world
is ready, introduce getImageDataReallyThisTime

(Alternatively: if the user is a Web developer, i.e. has Firebug installed,
always make Gecko's canvas backing store 2 pixels per canvas unit! Just
kidding. I think.)

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] More random comments on the putImageData definition

[Robert O'Callahan]

On Feb 11, 2008 1:05 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote:
>
> i was thinking having a style property, say, canvas-dpi: auto|device or
> something, where the default auto value automagically does the evil
> downsampling the moment a data routine is used, and device would result in
> the right thing.  That said neither of these are particularly nice. OTOH it
> would allow those who use get/putImageData to implement a basic video buffer
> (eg. the msx demo, etc) to continue to do so.
>

Wouldn't it be equivalent, yet simpler, to just define get/putImageData to
do the evil 'auto' thing, and have additional methods to do the right
'device' thing?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] More random comments on the putImageData definition

[Robert O'Callahan]

On Feb 11, 2008 12:51 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote:

>
>
> >  and the cost of sub-/super-sampling removes the whole "speed" thing
> > that the API was originally added for.
> >
>
> Not so sure about this. Script manipulation of pixel data probably isn't
> going to be faster than native, probably hardware-assisted resampling.
>
> Why would the sub/super sampling be done in a script?  one of the use
> cases for get/putImageData is applying filters to an image -- in that case
> you just process each pixel, no subsampling needed.
> The problem comes from things like
> http://jsmsxdemo.googlepages.com/jsmsx.html which are not using
> get/putImageData for image manipulation, but rather for just blitting to the
> screen.
>
> In terms of performance, a simple testcase a wrote a while ago (
> http://nerget.com/jstests/mandelbrot.html ) shows that putImageData is
> around 200x faster than the alternative of lots and lots of 1x1rect fills
> (at least in ffx), in real world terms that means you can easily get to the
> point that just filling the canvas takes longer than generating the data for
> the fill.
>

Sorry, I wasn't clear.

I'm just saying that the cost of resampling in getImageData/putImageData
would not be significant compared to the cost of script actually
manipulating the image data, so "performance" is not a compelling reason to
avoid such resampling.


>
> Yeah, unfortunately we all know the web authors tend to favour the "it
> > works now, so must be correct" philosophy -- it's looking more and more like
> > i will be forced to convert the canvas from hidpi to 1:1 the moment any of
> > the imagedata/toDataURL routines are used.  *sigh*
> >
>
> That would break your sensible invariant that
> putImageData(getImageData(x,y,w,h), x, y) leaves the canvas unchanged.
>
> But only the first time ther imagedata methods were touched, from that
> point on the canvas would be permanently locked at the 1:1 ratio, so it
> wouldn't result in a continual flip-flop between high and low resolution
> that would occur if you just sub/super-sampled on access.
>

Right, so it's not pessimal, but it's not great either. It may end up being
the best of a bad set of choices.


> It would really suck to lock canvas into a 1:1 device-to-CSS pixel ratio
> forever. Seems to me putImageData/getImageData isn't worth that risk. Maybe
> we should introduce it later when developers are more likely to encounter
> the DPI issues for themselves.
>
> I'm not sure what you mean here?
>

If, 5 years from now, most Web developers have 200dpi screens so browsers
are using at least a 2:1 ratio for their canvas backing stores, then
putImageData and getImageData could be safely introduced with the current
spec, because an assumption that device pixels are the same as canvas units
would break immediately in testing.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] More random comments on the putImageData definition

[Robert O'Callahan]

On Feb 11, 2008 2:57 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote:

>
> On Feb 10, 2008, at 5:44 PM, Robert O'Callahan wrote:
>
> On Feb 11, 2008 1:05 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote:
> >
> > i was thinking having a style property, say, canvas-dpi: auto|device or
> > something, where the default auto value automagically does the evil
> > downsampling the moment a data routine is used, and device would result in
> > the right thing.  That said neither of these are particularly nice. OTOH it
> > would allow those who use get/putImageData to implement a basic video buffer
> > (eg. the msx demo, etc) to continue to do so.
> >
>
> Wouldn't it be equivalent, yet simpler, to just define get/putImageData to
> do the evil 'auto' thing, and have additional methods to do the right
> 'device' thing?
>
> Not really -- a developer would need to do work to handle browsers that
> did not support the newer hidpi apis. The alternative (a css property or
> whatever) would allow a developer to use a single API, but tell the browser
> that they were aware that there may not be a 1:1 ratio between the requested
> region and the amount of data returned -- effectively it would be a flag to
> say "hey i actually do know the spec, and am not blindly expecting this to
> work on everyone else's computer just because it works on mine"
>

OK, but I wouldn't use a property, I'd use a content attribute, because you
want to be able to work with  elements that aren't in a document and
thus don't really have style.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Workers in HTML5

[Robert O'Callahan]

On Wed, Feb 20, 2008 at 3:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> If XMLHttpRequest is one of the APIs available on background threads,
> does that include its XML parsing/serialization features (responseXML
> and the ability to pass a Document as the post data)? If so, then
> effectively the whole DOM API has to be available on the background
> thread, which may increase the implementation complexity a fair bit
> over having only selected APIs available.
>

Having the DOM be available on other threads would be a pretty big
implementation burden for us too. Then there are are DOM APIs like ,
SVG APIs, etc ... each of those would either have to be disabled on worker
threads or take additional work to make thread-safe (even if the additional
work is just checking code). There's also styles and subresource loading,
which we already disable on XHR data documents but I'm not sure if that's
defined in any spec. Basically this is a very big can of worms you're
opening here...

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Usemap and ismap for canvas tag

[Robert O'Callahan]

Wouldn't it make more sense just to use SVG?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Some questions

[Robert O'Callahan]

On Thu, May 15, 2008 at 12:43 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:

>
> > Here's a precise scenario:  A user creates an HTML5 page, and of course
>
> uses the  element to embed their Windows Media content.  They're
> > rude, and could care less about Mac or Linux support.
> >
> > Will Safari provide an API that allows Microsoft to support this
> > scenario [...]
>
> Yes, the Windows Safari browser would just use DirectShow to render the
> videos, and DirectShow allows Microsoft to register a new codec to handle
> the Windows Media content.
>

FYI Safari on Windows uses Quicktime for . Your answer "yes" is still
correct, however.


Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] WebIDL vs HTML5 storage changes

[Robert O'Callahan]

If "storage.keyName = 'value';" can create a new storage item
(persistently), won't authors expect "delete storage.keyName;" to remove it
(persistently), as a matter of consistency?

If overloading "delete" is too quirky or too hard to implement, then it
seems none of the other shorthands should be allowed either.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] WebIDL vs HTML5 storage changes

[Robert O'Callahan]

On Tue, May 20, 2008 at 3:50 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

>
> On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote:
>
>  If "storage.keyName = 'value';" can create a new storage item
>> (persistently), won't authors expect "delete storage.keyName;" to remove it
>> (persistently), as a matter of consistency?
>>
>> If overloading "delete" is too quirky or too hard to implement, then it
>> seems none of the other shorthands should be allowed either.
>>
>
> Many objects in the DOM implement custom name getters (for instance
> NodeList) and a few even implement custom name setters (CSSStyleDeclaration,
> at least the way it is done in WebKit) but no one has clamored for a custom
> deleter or expected delete to work "as a matter of consistency" or been
> confused that "style.opacity = 0" is allowed but "delete style.opacity" is
> not. So I would say the available evidence argues against your conclusions.
>

I think 'style' does not bear on my conclusions, since 'style' has custom
property getters and setters, but not *adders* --- "style.foobar = ...;"
does not trigger any DOM API. Storage is different, it is something new.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] WebIDL vs HTML5 storage changes

[Robert O'Callahan]

On Wed, May 21, 2008 at 10:34 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> style.opacity = ... certainly triggers DOM API even if opacity was not
> previously set on that style.
>

The property was always there, though, from the JS point of view.

And there is even a plausible mapping for delete (style.removeProperty).
> It's not completely open-ended but you can certainly have properties added
> to and removed from a style declaration.
>

style.removeProperty does not remove the JS property, so from the JS point
of view it's a misnomer.

Ultimately the conclusion I question is that having obj.foo and obj.foo =
> ... work, but not delete obj.foo, will create confusion or is somehow
> illogical. I don't believe it will create confusion, and I think style is a
> relevant example of a case where it has not.
>

FWIW, I see "style.opacity = '';" far more often than removeProperty. I
don't think authors don't think of 'style' as a container to which they can
add and remove arbitrary properties, so I continue to maintain it's not
relevant to their expectations for storage.

I don't care all that much. But since it's convenience with some use, and
we've already implemented it and so has IE, I think we'd want a pretty
strong argument to remove it.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] [canvas] imageRenderingQuality property

[Robert O'Callahan]

On Tue, Jun 3, 2008 at 9:34 AM, Vladimir Vukicevic <[EMAIL PROTECTED]>
wrote:

>
> Yeah, I agree -- I thought that there was some plan somewhere to uplift a
> bunch of these SVG CSS properties into general usage?  I know that Gecko
> uplifted text-rendering, we should figure out what else makes sense to pull
> up.


Sort of off topic, but as you said, we uplifted 'text-rendering' in Gecko
1.9. I'm experimenting with 'clip-path', 'mask' and 'filter'. We're also
looking at uplifting 'pointer-events'. For the non-hint properties we have
to be more careful because it needs to be specified what they mean for
non-SVG content; uplifting the hint properties is a lot easier.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] [canvas] imageRenderingQuality property

[Robert O'Callahan]

On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote:

> That's exactly what i would be afraid of people doing.  If I have a fast
> system why should i have to experience low quality rendering?  It should be
> the job of the platform to determine what level of performance or quality
> can be achieved on a given device.


Right, it is. The user-agent is free to map all property values to "maximum
quality".


> Typically such a property would be considered a "hint", and as such would
> likely be ignored.


Ignored by who?

Neither of these apply if the property were just a hint, but now you have to
> think about what happens to content that uses this property in 18 months
> time.  You've told the UA to use a low quality rendering when it may no
> longer be necessary, so now the UA has a choice it either always obeys the
> property meaning lower quality than is necessary so that new content
> performs well, or it ignores the property in which case new content performs
> badly.


If the quality knob is no longer necessary, why would new content perform
badly?

These hint properties are opt-in for UAs. If you don't like the idea, just
treat all values as "auto".

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] [canvas] imageRenderingQuality property

[Robert O'Callahan]

On Wed, Jun 11, 2008 at 10:34 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> Why not just have the UA run in a high quality mode the first time it is
> painted on, but if the script tries to paint again within a certain amount
> of time, switch to high speed?
>

This makes sense.

However, there is still a potential use case for speed vs quality hints:
when the author wants to treat some content on the page as visually more
important than other content. For example, you might have a gallery page
with a bunch of unimportant bling around the actual image/canvas you care
about.

I'm unsure whether that's realistic enough to justify supporting hints.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] more drag/drop feedback

[Robert O'Callahan]

On Thu, Jun 19, 2008 at 9:31 AM, Thomas Broyer <[EMAIL PROTECTED]> wrote:

> On Wed, Jun 18, 2008 at 4:46 PM, Neil Deakin wrote:
> > We have a need to be able to support both dragging multiple items, as
> well
> > as dragging non-string data, for instance dragging a set of files as a
> set
> > of File objects (see http://www.w3.org/TR/file-upload/) from the file
> system
> > onto a page.
>
> That would be new data formats.
> That's how Adobe AIR solved the problem. They added a Bitmap and File
> list data formats, for which getData returns AIR-specific objets (a
> BitmapData and an array of File objects respectively)
>
> http://help.adobe.com/en_US/AIR/1.1/jslr/flash/desktop/ClipboardFormats.html
> http://livedocs.adobe.com/air/1/devappshtml/DragAndDrop_2.html#1048911


Creating a new data format for each kind of collection seems suboptimal. And
it breaks completely if you want heterogeneous collections.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Proposed additions to ClientInformation interface

[Robert O'Callahan]

On Tue, Jul 8, 2008 at 10:04 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> One possibility for addressing these requirements would be an element that
> acts as a link, button, or icon, or some such, and which invokes user
> agent features. Something like:
>
>   
>

It's an interesting idea. You'd have to remind authors and implementors that
the user can easily be tricked into activating this button so standard
confirmation UI is still required.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Proposed additions to ClientInformation interface

[Robert O'Callahan]

On Tue, Jul 8, 2008 at 11:06 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> Indeed. (This isn't unique to this proposal; the original idea of an API
> would be even more vulnerable to this, since scripts could just invoke it
> at any time they please.)
>

Of course, but that can be seen as an advantage since it's obvious to
everyone that confirmation UI is needed.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

The offline app cache can be used to accelerate online apps this way.

The jar: protoocol works pretty well too. However, any mechanism that lets
you reference the contents of a ZIP file requires care to avoid XSS attacks.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Mon, Jul 28, 2008 at 7:55 PM, Adam Barth <[EMAIL PROTECTED]> wrote:

> I suspect
> the reason the Firefox developers chose ! to separate the URL to the
> JAR from the path within the JAR is that ! is not a valid URL
> character.
>

I think Java invented the syntax, actually.

The main value of using the packaged archive is
> that the content author can sign the archive.  For example, this is
> the mechanism used for Firefox extensions.
>

And signed Java applets. Just to clarify --- extensions don't usually use
jar: URLs.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Mon, Jul 28, 2008 at 8:56 PM, Adrian Sutton <[EMAIL PROTECTED]>wrote:

> It's also worth noting that the jar: scheme will allow you to target
> anchors
> in a HTML document that's within the archive where as the fragment
> identifier syntax would not, unless you used two fragment identifiers:
> http://www.example.com/site.jar#/path/inside/foo.html#heading1
>

URL parsing doesn't support multiple fragment identifiers so that doesn't
work. Any way of referencing the contents of archives at arbitrary locations
is likely to require an extension to URL parsing.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer <[EMAIL PROTECTED]> wrote:

>
> c) that the contents of the container, once fetched and un-packed,
> logically 'shadow' the directory where the container came from.
>

It sounds like that affects all loads, which leads to issues:

So if I load 
http://www.example.com/x.m21#y.htmland
(in the same document, or in another tab?) load
http://www.example.com/z.html, and x.m21 contains a z.html but the server
also responds to http://example.com/z.html, does the second load (z.html)
come from the server or the container? Does it depend on whether the second
load starts before the first load finishes?

The same questions apply to Russell's proposal.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 6:21 AM, Kristof Zelechovski
<[EMAIL PROTECTED]>wrote:

>  My complaint was about how the jar URL scheme wannabe conceptually
> differs from the schemes we already officially have, not about how ugly it
> is to have two consecutive colons.  It is ugly but it does not matter.  What
> matters is that a scheme is being promoted that is specific to one content
> type, just as the APPLET element is discouraged for the same reason.
>

Suppose it was called "archive:" instead of "jar:" and the spec was made
open-ended so that other archive types other than ZIP files were permitted.
Would your objection still apply?


> Anyway, it is not obvious at all that linking inside a packaged HTML
> application should be supported.
>

Multiple entry points to a single application are common.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett
<[EMAIL PROTECTED]>wrote:

> Yes, the one major hang up that I foresee is how a browser should handle
> asynchronous loading. How would it know the contents of the archive before
> it loaded the archive so it did not try to load the same files directly? The
> simple answer would be to load the archive(s) synchronously.
>

That is a performance killer.

As for references in a different tab, if the separate tab/document did not
> reference the zip archive first, it would operate as normal. It would check
> the cache and then attempt to load. If the zip had been loaded from the
> first page already, the file would be present in the cache, and if not, then
> the browser would attempt to retrieve it from the server.
>

So you get nondeterministic load behaviour anyway. This is not good.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 2:52 AM, Kristof Zelechovski
<[EMAIL PROTECTED]>wrote:

>  Archive: is not generic enough but perhaps you could bend the URL
> notation to embrace something like inside:.  I still would not recommend it
> but it would not make me that sore.
>
> How about http://www.site.com/app.jar>?
>
> The user agent would be required to append a query string to local
> hyperlinks and that parameter would be reserved (or rename it to
> h809370dfwhbwa0r92347090).
>
>
That query string would have to be appended everywhere you do baseURI +
relativeURI -> absoluteURI conversion. So you're really just messing with
relative URI syntax for this particular scheme. That's not cleaner than the
URI extension for jar:/archive: (or whatever you want to call it), IMHO.

OTOH, you can simulate several entry points by having all supported entry
> points on the start page (à la Microsoft Access) and have the user navigate
> to what she needs.  I do not think this would be prohibitive from the
> customer's point of view.  And I am sure there is no need to publish each
> local address.
>
That breaks bookmarks and similar navigation mechanisms such as intelligent
URLbar autocompletion. Also note that an entry point can be a particular
document hosted in a Web application, or even a particular email message, so
you can't always offer one-click navigation.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 11:20 AM, Dave Singer <[EMAIL PROTECTED]> wrote:

> Caching is on a full URL basis, of course.  Once that is decided, then yes,
> I think that pre-cached items for a given URL are in the general cache for
> that site.
>

A site that uses this feature is likely to be fragile. It will have to have
z.html both in the archive and available directly from the server, in case
z.html is requested before the load of the archive has finished. And if
those copies ever get out of sync you're in very big trouble, because
depending on the context, either the archive version or the direct version
is likely to consistently win the load race, so just occasionally some
clients will get the wrong version. This seems like a highly error-prone
design.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

[whatwg]

[Robert O'Callahan]

Currently the spec doesn't say anything about the rendering of the 
element. Webkit makes  without "controls" display:none by default,
which seems reasonable, but it would be nice if spec recommended this
behaviour. When "controls" is added, the element needs to be visible, so it
will need an intrinsic size. Since the spec specifies the intrinsic size for
, shouldn't it do so for  as well?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted querying of capabilities

[Robert O'Callahan]

That would be nice to have. Unfortunately DirectShow and Quicktime do not
seem to expose the ability to enumerate supported codecs, so it might be
hard to implement for some browsers.

As things stand, you can use  elements to offer different formats,
and you can try to play a stream and use script to detect if it fails to
play.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

[whatwg] Setting the "title" attribute

[Robert O'Callahan]

http://www.w3.org/html/wg/html5/#dom-tree

>
>1. If the title element is 
> null, then a new
>title  element must be created
>and appended to the head 
> element.
>
>2. The children of the title 
> element(if any) must all be 
> removed.
>3. A single Text node whose data is the new value being assigned must
>be appended to the title 
> element.
>
>
>
Steps 1 and 2 can fire mutation events and cause "the title element" to
become null again. I suppose if that happens, the algorithm should stop, but
the spec should say so.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Setting the "title" attribute

[Robert O'Callahan]

On Thu, Aug 7, 2008 at 10:43 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote:

> Actually, if we make the changes discussed to the mutation events spec, we
> can consider setting the title a compound operation. This means that
> mutation events won't fire until the above algorithm is fully done, so any
> changes to the title element or attribute can simply be considered a
> separate operation.
>

Yeah, this pretty much what Hixie said on IRC. Suits me.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted querying of capabilities

[Robert O'Callahan]

On Thu, Aug 7, 2008 at 6:53 PM, Tim Starling <[EMAIL PROTECTED]>wrote:

> DirectShow and QuickTime can add those interfaces at a later date. When
> the backends develop this capability, there should be a standard way to
> go the next step and expose it to JavaScript. Otherwise every
> implementor will develop their own interface.


Sure. But the interface has to be able to say "I don't know". And then we're
relying on authors to do the right thing if they get that answer ... which
is always a worry.

In fact, QuickTime already has enough query capabilities for Wikimedia's
> purposes.


Probing for a particular component is a different problem from listing all
supported codecs, which is what I thought you were asking for. I suppose we
could hardcode a list of well-known components along with the codecs they
support and then probe for them to estimate what codecs are supported. But,
yuck.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Active workers when user leaves the page

[Robert O'Callahan]

On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking <[EMAIL PROTECTED]> wrote:

> I do want to be agressive with killing workers when the user leaves a page
> since that makes for better user experience. However I'm also worried about
> stopping scripts halfway through breaking things and leaving the site with
> half-finished operations that are stored in databases or localStorage.
>

Aggressive killing of workers without warning when the user navigates away
would actually be a good feature.

There are various reasons outside anyone's control that a worker might die
abruptly. For example, power failure, browser crash, or "slow-script" style
timeout. Applications need to be able to handle those cases, for example by
using database transactions or careful use of atomic operations. But that's
hard to test and authors probably won't design or test well for those cases
since they're relatively uncommon. Expanding abrupt termination scenarios to
include navigate-away makes abrupt termination much easier to test, forces
authors to design for it early, and will ultimately simplify the application
design by reducing the different ways a worker can terminate.

This may sound a bit radical, but it's not a new idea. It's a principle
sometimes called "crash-only software". See e.g.
http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] WebWorkers vs. Threads

[Robert O'Callahan]

On Thu, Aug 14, 2008 at 10:06 PM, Shannon <[EMAIL PROTECTED]> wrote:

> On second thoughts I withdraw these claims. I don't have the statistics to
> know one way or the other why "portable threads" are more prevalent than
> "share nothing" ones. There may be many reasons but latencies probably isn't
> one of them. It could just be fashion or convenience.
>

Excuse my rant:

Shared-memory threads and locks are a relatively easy model to implement,
they *appear* to be a straightforward extension to existing platforms and
programming languages, and they don't require much implementation wizardry
to provide good performance in simple apps written by really smart people.
So they're the natural concurrency extension that everyone adds to their
platform first. Then people build really complicated apps that don't scale
well and have strange problems with intermittent race conditions and
deadlocks and everyone wishes they had a better model, but by then it's too
late.

This isn't the right forum to have a big discussion about concurrent
programming models. But for the record, here are some of the problems with
the shared-memory, threads-and-locks model:

1) Choosing the scope of locks in time (when you lock and for how long) and
space (how much data is covered by each lock) is hard. Mistakes in one
direction lead to race conditions where unexpected thread interleavings
produce errors, and these are basically impossible to test for. Mistakes in
another direction lead to deadlocks which are also very difficult to test
for. There are tools that can help detect potential errors but they're no
panacea (I did research in this area at IBM).

2) Locks actually scale poorly. It's very hard to achieve high levels of
parallelism because you keep hitting lock contention and have to refine lock
granularity and then implement various esoteric optimizations to eliminate
false sharing etc.

3) It's really hard to do basic stuff well. Maurice Herlihy uses an example
of implementing a double-ended queue with concurrent access to both ends;
getting it to work correctly for lengths 0, 1, and > 1 is rocket science.

4) Threads and locks just don't support compositional reasoning about
programs. To avoid deadlocks and races you have to expose a lot of
information about the internals of functions --- what locks they might take,
what they might wait for, and what data they might access. For specific
domains like OS kernels you can impose rigid rules across the code and get
away with it. For more complex apps, especially ones with dynamic
extensiblity, that doesn't work well. Especially when not everyone on your
team is a genius.

Shared-nothing message passing systems like Workers have problems too and
won't be a good fit for some applications, but for the applications that
fit, they avoid a lot of problems, and they're really easy to implement.

There are other models, like replacing locks with a notion of atomic code
blocks --- gets rid of many problems, but a much harder model to implement
efficiently so you don't see it in production systems yet. A related popular
idea is adding transactions and transactional memory to the programming
language, but again, hard to implement well.

So for the programming model problem, we don't know what the right answer is
for all applications, but we do know that threads and locks are the wrong
answer.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] WebWorkers vs. Threads

[Robert O'Callahan]

On Fri, Aug 15, 2008 at 7:54 AM, Maksim Orlovich <[EMAIL PROTECTED]> wrote:

> It's actually a lot worse in this case, since the ECMAScript runtime must
> be able to enforce the sandbox properly even in face of incorrectly
> threaded programs.
> In particular, if two threads are accessing properties of the same object
> at the same time w/o proper locking, the invariants of the property map
> data structure should not be violated, which means perhaps the most basic
> and hottest data structure in the language runtime has to be thread-safe
> (or, at the very least guarantee that whatever happens won't result in a
> crash). This is a heavy burden both on the performance and complexity of
> the implementation.  And, actually, all of the above would apply to
> concurrent DOM calls, too.
>

That is a very good point in general; defining and enforcing language
semantics in the presence of data races is very hard. Just check out the
"Java memory model" work.

For JS in particular, though, it's possible to be fast and thread-safe ---
Spidermonkey is. I'm not saying it's a good idea :-).

In contrast, a worker implementation, as far I can see, just requires
> thread safety of the message passing implementation --- hardly a
> challenge; and somewhat trickier but more localized safety of the GC heap.
>

AFAIK the workers use logically separate heaps, so the implementation can
physically separate the heaps if necessary.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

[whatwg] whitespace compression in document.title

[Robert O'Callahan]

IE7, FF3 and Opera 9.51 compress whitespace when getting document.title. \t
and \n (at least) are converted to spaces, runs of consecutive spaces are
compressed to a single space, and leading and trailing spaces are stripped.
Safari 3.1 follows the spec and does none of this.

We've got a report that not doing this processing messes up page titles on
last.fm. Of course we can fix page titles in tab and window decorations by
doing the processing in user interface code, but at first glance, it would
make more sense to change the spec to follow dominant UA behaviour.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] whitespace compression in document.title

[Robert O'Callahan]

On Mon, Aug 18, 2008 at 2:19 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> >
> > IE7, FF3 and Opera 9.51 compress whitespace when getting document.title.
> > \t and \n (at least) are converted to spaces, runs of consecutive spaces
> > are compressed to a single space, and leading and trailing spaces are
> > stripped. Safari 3.1 follows the spec and does none of this.
>
> Do you mean for the purposes of the interface? Or in the API?
>

The API, if I understand your question correctly. To be precise: the
rendering of this tescase:


  
Hello   Kitty
Kitty


Title: 

document.getElementById("s").innerHTML = document.title;


Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] overflow of seamless iframes

[Robert O'Callahan]

On Fri, Aug 1, 2008 at 9:11 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> My original idea (apparently not well conveyed in the spec) is that it
> doesn't actually affect the rendering model at all -- it's still an
> , it just doesn't have a border, and the CSS style sheets cascade
> into it and properties inherit into it. So the answer would be "do the
> same as with regular iframes", which I guess is to only support overflow:
> hidden and overflow: visible (and 'auto' mapping to one of those
> dynamically), as derived from the viewport as for any browser context.


I'm not sure what you meant by that. Regular iframes always clip their
contained documents, setting "iframe { overflow:visible; }" won't do
anything. Well, it won't in Gecko; I haven't tested it in other browsers,
but I'd be surprised if they were different.

Note that the default width and height are adjusted for seamless iframes
> to match the width that the element would have if it was a non-replaced
> block-level element with 'width: auto', and the height of the bounding box
> around the content rendered in the iframe at its current width,
> respectively.
>

"The bounding box" is a bit ambiguous. If the content overflows vertically
above the iframe's viewport, does that contribute to the height of the
bounding box?

For greater seamlessness, I'd prefer to make the intrinsic height be the
height of the iframe's root element. Plus, as dbaron suggested, we'd like
'overflow' to apply to the content of seamless iframes so that horizontal
and vertical overflowing content can be rendered as if the iframe was a
regular overflow:visible block. (We might want to recommend that the UA
style sheet contain "iframe { overflow:hidden; }" to make it easier for
authors to avoid spoofing attacks via seamless sandboxed iframes using
clever positioning.)

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] overflow of seamless iframes

[Robert O'Callahan]

On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> > > Note that the default width and height are adjusted for seamless
> > > iframes to match the width that the element would have if it was a
> > > non-replaced block-level element with 'width: auto', and the height of
> > > the bounding box around the content rendered in the iframe at its
> > > current width, respectively.
> >
> > "The bounding box" is a bit ambiguous. If the content overflows
> > vertically above the iframe's viewport, does that contribute to the
> > height of the bounding box?
>
> As far as I can tell there is no ambiguity to the concept of the bounding
> box of the content in the canvas, especially given the way the initial
> containing block is forced to zero height.


What's the answer to my question then? Should I have been able to derive it
somehow?

> For greater seamlessness, I'd prefer to make the intrinsic height be the
> > height of the iframe's root element.
>
> Why would that be more seamless? Surely that would be less seamless if
> there were things like negative margins, since then you'd have unsightly
> scrollbars appearing.


You mean the scrollbars associated with the iframe viewport?

Well, viewport scrollbars are already a bit magical. The CSS initial value
of 'overflow' is 'visible', yet all browsers use 'auto' for viewport
scrollbars unless another value is propagated up from the root element or
HTML . So I'd suggest that for seamless iframes, the viewport overflow
be 'visible' unless another value propagates up.

I just realized that using the height of the root element won't make much
sense if the root element is positioned. I'm not sure how much to care about
that.

> Plus, as dbaron suggested, we'd like 'overflow' to apply to the content
> > of seamless iframes so that horizontal and vertical overflowing content
> > can be rendered as if the iframe was a regular overflow:visible block.
> > (We might want to recommend that the UA style sheet contain "iframe {
> > overflow:hidden; }" to make it easier for authors to avoid spoofing
> > attacks via seamless sandboxed iframes using clever positioning.)
>
> Well, I guess I'm ok with that, but that will presumably require
> significantly changes to the CSS spec to define how it all works (e.g.
> with compositing and so forth).


We can make the iframe a stacking context. Then I don't see any problems
with compositing.


> The current definition is intended to be
> really easy to implement without needing any changes to the CSS model.
>

I think that's a good goal, but we also want it to be reasonably "seamless".

I'm concerned about the use case of very wide content in the iframe (i.e.
content overflowing the root element horizontally); for example a forum with
many wide messages, each of which is a seamless iframe. Right now it seems
the choices are to either have a horizontal scrollbar in each message or
clip each message horizontally, there's no way to make it work like a forum
page.

Actually I'm not 100% sure you mean by "the width that the element would
have if it was a non-replaced block-level element with 'width: auto'". You
mean if it was such a block-level element containing the root element of the
iframe's document?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] overflow of seamless iframes

[Robert O'Callahan]

On Mon, Aug 18, 2008 at 6:45 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> > On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > > On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> > > > > Note that the default width and height are adjusted for seamless
> > > > > iframes to match the width that the element would have if it was a
> > > > > non-replaced block-level element with 'width: auto', and the
> > > > > height of the bounding box around the content rendered in the
> > > > > iframe at its current width, respectively.
> > > >
> > > > "The bounding box" is a bit ambiguous. If the content overflows
> > > > vertically above the iframe's viewport, does that contribute to the
> > > > height of the bounding box?
> > >
> > > As far as I can tell there is no ambiguity to the concept of the
> > > bounding box of the content in the canvas, especially given the way
> > > the initial containing block is forced to zero height.
> >
> > What's the answer to my question then? Should I have been able to derive
> > it somehow?
>
> I don't understand the question. How does the viewport affect the bounding
> box?


Suppose the iframe's document is

What's the height of the bounding box? 400px or 500px?

I just thought of another problem with allowing the contents of a
> "seamless" iframe to overflow outside the iframe box.
>
> One of the main uses for this will be to sandbox blog comments, using the
> yet-to-be-defined doc="" attribute, as in:
>
>  seamless sandbox="allow-same-origin">
>
> If we allow the contents to flow out of the box, then we also allow blog
> comments to start overlapping other content on the page.


Yeah, although setting overflow:hidden on the iframe could be used to
prevent that.

> I'm concerned about the use case of very wide content in the iframe
> > (i.e. content overflowing the root element horizontally); for example a
> > forum with many wide messages, each of which is a seamless iframe. Right
> > now it seems the choices are to either have a horizontal scrollbar in
> > each message or clip each message horizontally, there's no way to make
> > it work like a forum page.
>
> The way forum pages work now is that the content ends up screwing up the
> rest of the page, so I think that's a good thing. :-) People work around
> this now by forcing line break opportunities to exist in long URLs, etc,
> or by setting overflow:auto on user-submitted content.


Yes, although it would be nice to offer authors a choice. Oh well, I suppose
it doesn't matter too much.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

[whatwg] Using as a source for canvas.drawImage

[Robert O'Callahan]

Thanks to Anne for pointing this out...

We've implemented using  elements as an image source in
canvas.drawImage:
https://bugzilla.mozilla.org/show_bug.cgi?id=448674
The extension is very obvious. Unlike animated images, which always draw the
first or poster frame, we draw the current frame of the video. This lets you
do things like make a thumbnail timeline.

It'd be nice to have this in the spec.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Using as a source for canvas.drawImage

[Robert O'Callahan]

On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote:

> Cool -- I wonder though if it would be better if it were placed in a
> different method, drawFrame or something (very much an up in the air sort of
> question)
>

drawImage is already overloaded, so why not carry on with that, unless we
change the API as you suggest below.

One other thing that I would consider would be requiring the frame# to be
> specified explicitly as that would make things like "chapter" previews (or
> whatever) work in a way that is perhaps cleaner.  Otherwise you have to
> record the current location in the video stream, then scan to each location
> you want to blit, draw, and then return to the original position.  Which
> could easily result in weird visual behaviour for the user (as the video
> element flickers a few random frames while you do your previews or
> whatever).
>

AFAIK we'd basically have to implement that by creating a second video
stream, seeking it and then capturing the frame, and you really don't want
to do that synchronously! Then we'd want to cache that stream so that
another drawFrame with a nearby frame index was efficient ... ick. So I
suggest not offering that API. Authors can always use a second, hidden video
element to achieve the same effect.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] overflow of seamless iframes

[Robert O'Callahan]

On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> >
> > Suppose the iframe's document is
> > 
> > What's the height of the bounding box? 400px or 500px?
>
> 500px.
>

That's a little weird since only 400px of content will be displayed, but OK
as long as it's clear :-).

> > If we allow the contents to flow out of the box, then we also allow
> > > blog comments to start overlapping other content on the page.
> >
> > Yeah, although setting overflow:hidden on the iframe could be used to
> > prevent that.
>
> Fair enough. In that case I'd rather we had this in the UA stylesheet:
>
>   iframe[seamless][sandbox] { overflow: hidden ! important; }
>

I'd suggest having that except without !important.

But never mind about this issue anyway. I think we can live without it.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] overflow of seamless iframes

[Robert O'Callahan]

On Tue, Aug 19, 2008 at 1:05 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote:

> On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
>> >
>> > Suppose the iframe's document is
>> > 
>> > What's the height of the bounding box? 400px or 500px?
>>
>> 500px.
>>
>
> That's a little weird since only 400px of content will be displayed, but OK
> as long as it's clear :-).
>

Hmm ... does the "bounding box" take into account scroll positions? Because
if it does, then scrolling in the iframe's document can change the intrinsic
height of the iframe (for example if there's also fixed-pos content in the
iframe). That doesn't sound good.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted querying of capabilities

[Robert O'Callahan]

On Wed, Aug 20, 2008 at 9:53 PM, Henri Sivonen <[EMAIL PROTECTED]> wrote:

> Do you mean trying to download each video, giving it to GStreaming and
> seeing if an error code comes back?
>

That might be what we have to do, yes.

But at least that can be done asynchronously. You couldn't implement a
synchronous JS query API that way of course.

Hmm, I suppose you could implement a synchronous API by making a collection
of videos, one in each known format, and on startup trying to play them all,
and recording which ones were successful. But "ugly" doesn't even begin to
describe that solution.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted query proposal

[Robert O'Callahan]

On Fri, Aug 22, 2008 at 1:56 PM, Tim Starling <[EMAIL PROTECTED]>wrote:

> interface HTMLMediaElement {
>...
>boolean supportsType(in DOMString type);
>...
> }
>
> The supportsType() method must return false if the user agent is sure it
> cannot support the given type, and true if the user agent either can
> support the given type, or cannot determine whether it can support the
> given type.
>

Wouldn't it be better to return three possible values: "yes", "no" and
"don't know"?

Any browser that supports integration with an extensible framework like
GStreamer, Quicktime or Direct Show is going to have a hard time ever
reporting "false". Apparently there was a conversation today in #theora that
you might have seen whcih explains why this is so, at least for GStreamer.

With a three-value return, at least Firefox with both Ogg Theora and
Quicktime support could return "yes" for Ogg and "maybe" for other types.
But I think Safari is going to have to return "maybe" all the time ---
except perhaps for codecs built into Quicktime. That doesn't help you.

It still seems to me that the best approach would be to try to play the
stream using , catch the error if that fails and then instantiate
fallback. This is really what the media frameworks want you to do; the
browser is just the meat in the sandwich.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted query proposal

[Robert O'Callahan]

On Fri, Aug 22, 2008 at 2:57 PM, Eric Carlson <[EMAIL PROTECTED]>wrote:

> It is possible to build a list of all types supported by QuickTime
> dynamically. WebKit does this, so Safari knows about both the built in types
> and those added by third party importers.
>

You mean this
http://trac.webkit.org/browser/trunk/WebCore/platform/graphics/mac/MediaPlayerPrivateQTKit.mm#L815
which calls this?
http://developer.apple.com/documentation/QuickTime/Reference/QTKitFramework/Classes/QTMovie_Class/Reference/Reference.html#//apple_ref/occ/clm/QTMovie/movieFileTypes
:

Does that actually enumerate all supported codecs? Looking at the Webkit
code and the Quicktime docs, it looks like it's just enumerating
file/container types.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted query proposal

[Robert O'Callahan]

On Sat, Aug 23, 2008 at 1:46 AM, Eric Carlson <[EMAIL PROTECTED]>wrote:

>
> On Aug 21, 2008, at 8:56 PM, Robert O'Callahan wrote:
>
> Does that actually enumerate all supported codecs? Looking at the Webkit
> code and the Quicktime docs, it looks like it's just enumerating
> file/container types.
>
>   Indeed the code enumerates movie importers and just builds a list of the
> MIME types supported by QuickTime, so it can not yet deal with a type string
> with an RFC4281 "codecs" parameter. We are working on that requirement, but
> the current approach is still useful because the "codecs" parameter is not
> yet widely used.
>

That will require extensions to Quicktime, right?

So using your current approach implement Tim's proposed API, we can use this
to answer "yes" or "no" if the MIME type contains no codec string, and if
the MIME type does contain a codec string we can either answer "no" (if the
container is not supported) or "maybe".

I suppose if Tim's willing to assume that anything supporting the Ogg
container supports Theora and Vorbis, that's good enough for now ... for
Quicktime. We'll have to look into whether something similar is possible
with GStreamer and DirectShow. But I guess even if it isn't, a 3-value
version of Tim's proposed API is better than nothing.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted query proposal

[Robert O'Callahan]

On Sat, Aug 23, 2008 at 11:21 AM, Eric Carlson <[EMAIL PROTECTED]>wrote:

>
>   A three state return is an interesting idea, but wouldn't you then be
> required to return "maybe" for MIME types that can describe multiple
> formats? For example, "video/mpeg" can be used to describe a video
> elementary stream, an MPEG-1 system stream, an MPEG-2 program stream, or an
> MPEG-2 transport stream. "application/ogg" can include dirac, flac,
> theora, vorbis, speex, midi, cmml, png, mng, jng, celt, pcm, kate, and/or
> yuv4mpeg. And then there is "video/quicktime"...
>
>   I think it makes more sense to leave it as a boolean, where "no" means
> the UA does not support the type, and "yes" means that the UA implements
> some support for the type but errors can occur during loading and/or
> decoding.
>

OK, for extensible container types with no codec information supplied, the
browser would have to return "maybe". But how is that worse than defining
"yes" to mean "maybe"?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Scripted query proposal

[Robert O'Callahan]

On Sat, Aug 23, 2008 at 2:17 PM, Tim Starling <[EMAIL PROTECTED]>wrote:

> With this proposal, I'm trying to find a compromise between the opinions
> put forward on this list. Personally I'd be happy either way, as long as
> the interface gets added in some form.
>
> The yes = maybe definition pre-empts the tendency of user agents to lie
> about their capabilities.
>

If you're worried about that, feel free to treat "maybe" as "yes". I don't
think we should forclose the possibility that user-agents might make a
correct distinction between "yes" and "maybe".

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] A slightly different use-case for shared workers

[Robert O'Callahan]

On Thu, Aug 28, 2008 at 9:59 AM, Aaron Boodman <[EMAIL PROTECTED]> wrote:

> I encounter sites frequently that want to "pop out" part of their
> application free of the page, into a smaller window. For example,
> Pandora radio (http://pandora.com) does this. The player starts out
> embedded in the normal content area, but users have the option to pop
> it out into a smaller, separate window.
>
> One problem with these apps is that they have to shutdown and restart
> in the popup window. So if I'm playing a song in Pandora, it loses
> tracks of where I am and restarts in the pop out player.
>
> It seems like shared workers could help with this problem. If some
> future version of workers had access to the Audio API, the base
> pandora.com page would start a shared worker, which would be used to
> play the audio. If the user opted to open the "player" in a popup, the
> popup would simply obtain a reference to the existing worker. The
> music wouldn't have to restart. If the user navigated away from
> pandora.com, the popup would keep the worker alive until it was
> closed.
>

Why not just open new window and move the playing  element from the
old window into the new window? You might need to call play() on it again in
the new window, but you shouldn't lose your place in the stream.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] A slightly different use-case for shared workers

[Robert O'Callahan]

On Thu, Aug 28, 2008 at 12:30 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:

> Hm, that is a good point. I didn't consider the the audio object would
> keep playing smoothly when moved between documents. That seems
> unlikely to be reliable across implementations, but I'll keep my
> fingers crossed :).
>

Works on Firefox trunk :-). Testcase attached. (The Vorbis file takes a
while to download so you should probably let it play through once before
trying the test.)

I have to confess I'm not completely unsurprised :-).

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]



  

Start playing
Move to new window