Re: [whatwg] Offline Web Apps
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
On Thu, 13 Sep 2007 11:22:59 +0200, Robert O'Callahan [EMAIL PROTECTED] wrote: 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 :-). I'm not sure I understand the query parameter use case. If you have a web page foo.cgi?page=x wouldn't that page also be simply the offline page? What exactly is the scenario in some more detail? (Note that with history.pushState() you can set the URI of the current page so the fragment identifier bookmarking argument is no longer very relevant.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] Persistent Scripting Context, was: Offline Web Apps
I've been sitting on this thought for almost a week, and with no time
in sight to formalize it into some sort of a proposal, I believe it'd
be better just to blurt it out here. Alex Russell's post was the
proverbial straw (http://alex.dojotoolkit.org/?p=623#more-623).
Overall, I think Ian's latest proposal is good. I am still trying to
wrestle understanding the specifics of Updaters and use cases, but it
looks like a pretty good way to implement offline storage.
Additionally, it appears to be a very elegant way to add an extra
level of scope that is much needed for Web applications. So, here is
the idea:
1. Instead of using application attribute, move the declaration into
a separate head element, like link rel=application. This provides
the ability to reference multiple applications and also name each
reference:
link rel=application type=text/html id=dojo
href=http://dojotoolkit.org/files/manifests/dojo-0-9-0.html;
(I am implicitly suggesting that the manifest is in XOXO format, but
that's another topic for another day)
2. All offline storage rules, outlined in Ian's proposal apply.
3. For each declared application, a scripting context exists. The
context is a JS object and can be accessed by querying
document.application[id], where id is the value of the id attribute
on the link element (a bit kludgy, better idea needed here). For
instance:
document.application.dojo.parser = function() { ... }
alert(document.application.dojo.version);
4. The scripting context is persistent for the duration of the browser
session. In other words, it retains scope and values of the context
members across documents, being initialized when the application is
first encountered during a browsing session and shutting down when the
browser session is terminated. I realize how complex this is
implementation-wise.
5. If the document is explicitly mentioned in the manifest of the
application, the context is read/write for this document. Otherwise,
the context is read-only. This allows any developer to use the
application without actually being part of it.
6. In addition to Updater, there are Constructor and Destructor
manifest entries. Their purpose is to initialize scripting context
when the application is encountered for the first time during the
browser session and tear down the context when the session ends.
Obviously, this is very sketchy, but I wanted to capture this in
writing, hoping that it will inspire more concrete ideas.
:DG
Re: [whatwg] Offline Web Apps
On Sep 13, 2007 4:44 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: I'm not sure I understand the query parameter use case. If you have a web page foo.cgi?page=x wouldn't that page also be simply the offline page? What exactly is the scenario in some more detail? I feel like me and the other querystringers are missing some critical detail that would make omitting querystring support work. So here is how I see it. Please tell me what is missing. The bugzilla scenario is a good one. Someone wants to offline-enable bugzilla. They could rewrite bugzilla to use fragment identifiers instead of querystrings, but then bug shortcuts on the web would not work with the offline-enabled application. They couldn't really cache all possible pages (there are lots of bugs, and that would be really inefficient). I suppose you could have each bug page be a separate application, and cache each one as it is viewed online, but this is really wasteful, and more importantly, bug shortcuts won't work offline unless you have previously visited them. - a
Re: [whatwg] Offline Web Apps
On Sep 13, 2007, at 8:30 AM, Aaron Boodman wrote: They could rewrite bugzilla to use fragment identifiers instead of querystrings, but then bug shortcuts on the web would not work with the offline-enabled application. If you're designing a new application, even one that works both online and offline, it's not so helpful. But if you're trying to transition an existing application, with lots of existing URLs, then you might wish for some way to handle these URLs with query strings. I could imagine a similar issue if YouTube was creating the offline mode for YouTube. However, it may be asking too much of the offline design to accommodate this. The query string is part of the URL, a part normally parsed only by the server, and it's hard to see how to fit this in. -- Darin
Re: [whatwg] Offline Web Apps
On 9/13/07, Aaron Boodman [EMAIL PROTECTED] wrote: The bugzilla scenario is a good one. Someone wants to offline-enable bugzilla. They could rewrite bugzilla to use fragment identifiers instead of querystrings, but then bug shortcuts on the web would not work with the offline-enabled application. They couldn't really cache all possible pages (there are lots of bugs, and that would be really inefficient). I suppose you could have each bug page be a separate application, and cache each one as it is viewed online, but this is really wasteful, and more importantly, bug shortcuts won't work offline unless you have previously visited them. - a This kind of puts us at crossroads as to whether keep treating a URL as an opaque identifier or attempt to break it down to determine whether a page belongs to a given set. Another, less cool path would be to use regular expressions or somesuch instead of explicit list. What if an application could be given an event when the link, clicked on a document that is part of the application leads to a page that is not present in cache? This way, the app could potentially manage the fallback. :DG
Re: [whatwg] Offline Web Apps
The following has a rant flavor to it, but I am hoping you'll find it helpful in the thought process. Distinct, server-reaching URLs (no fragment identifiers) for each page in an web application are a _good_thing_. Packing the whole application into one document and managing history with id hashes and other hacks is not. It's a necessary kludge that you have to do in order to avoid browser context re-initializing, re-parsing scripts, and re-requesting all accompanying graphical and stylistic overhead every time the user clicks on anything. I would've loved it if Google Reader had a distinct URL for each click I make on the page, and I am sure Google Reader devs would've loved it too. Except they also would've loved not having to worry about the browser/scripting context change. Instead, they have to essentially reinvent the way web works (http://www.tbray.org/ongoing/When/200x/2006/03/26/On-REST) by overloading fragment identifier with an entire URI management system. I applaud the effort and the result is awesome, but it doesn't make a good bedtime story. I guess the vision is that application context transcends and encompasses browser/scripting context somehow. :DG
Re: [whatwg] Offline Web Apps
On Thu, 13 Sep 2007 18:21:21 +0200, Dimitri Glazkov [EMAIL PROTECTED] wrote: I would've loved it if Google Reader had a distinct URL for each click I make on the page, and I am sure Google Reader devs would've loved it too. Except they also would've loved not having to worry about the browser/scripting context change. You seem to have missed what I pointed out earlier: http://www.whatwg.org/specs/web-apps/current-work/#pushstate This allows applications to make distinct URIs while keeping all the other benefits. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Offline Web Apps
On Sep 6, 2007 5:46 PM, Ian Hickson [EMAIL PROTECTED] wrote:
We provide an API that can add files to the cache, and that can be queried
to determine if we are in upgrader mode or not, and that can swap in a
new cache without reloading the page, during the 'upgrading' event.
Given this, and the hidden context that is used while upgrading (not
the 'upgrader context', just the one that the page you are viewing is
loaded into), isn't it possible to simplify by just doing something
like this?
addFileToCache(otherTopLevelPage.html);
addFileToCache(yetAnotherTopLevelPage.html);
addFileToCache(imageThatWasntReferenced.png);
Then you don't need the manifest anymore, do you?
Upgrader:
Create a hidden browsing context.
Load the upgrader in it.
Just before onload, fire an 'upgrading' event to every instance of a
top-level page using a cache with the same identifier.
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.
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've been thinking about this, and it seems like an interesting idea,
but to me it creates more complexity than it's worth. Here are some of
the questions around it:
* Is an update marked as successful before or after an update runs?
If before, the new version of the app must be prepared for the
scenario that the updater did not run completely, in which case you
may as well put the upgrade logic in the new version and be done with
it.
If after, how do you track success/failure of the update? Keep in
mind that an update may require asynchronous server access to retrieve
data. If you allow for this, you just add lots of API for a relatively
small case. If you don't allow for it, then in some cases upgrading
will have to be done by the new version of the app.
* I like the idea of app instances being able to talk to each other
during upgrade, but it seems to conflate several goals:
Prevent two apps from trying to upgrade at the same time
Prevent instances of an app that are old from accessing a newer local schema
Allow multiple instances of an app to talk to each other
Separate application logic from UI logic and share the application
logic between multiple views (Dimitri and Alex Russell's point)
For the first two problems in gears, we have been kicking around the
idea of versioning the database connections. So you could do:
db.open(mydb, 1);
db.execute(...);
db.execute(...);
..etc..
But as soon as somebody in another window did:
var db.open(mydb, 1);
db.setVersion(2);
The previous connection starts throwing errors. This assumes that the
database has transaction support and a few other things though. From
my point of view this is simpler, but I understand that it relies on
some bits that are not in whatwg's current database proposal.
For the long term, I agree with Dimitri that what is really needed is
a shared JS context between all instances of an application.
Otherwise, anybody that is doing significant synchronization, for
example, will have to somehow organize through all the instances of an
app which page is doing the work. It's silly. We need the ability to
separate an app into the ui bits and the application bit, and have a
one-to-many relationship between them.
If a future version of the spec had something like a gears worker, one could do:
// If the named worker already exists (namespaced to the current
origin I suppose), then a
// reference to it will be retrieved. Otherwise, one will be created.
var worker = getOrCreateWorker(app-logic, app.js);
worker.sendMessage(load_customers, {account_id: 42}, function(result) {
result.customers.forEach(function(customer) {
console.log(Got customer name: %s, id: %d, customer.name, customer.id);
});
});
- a
Re: [whatwg] Offline Web Apps
On Thu, 13 Sep 2007, Aaron Boodman wrote: The bugzilla scenario is a good one. Someone wants to offline-enable bugzilla. They could rewrite bugzilla to use fragment identifiers instead of querystrings, but then bug shortcuts on the web would not work with the offline-enabled application. They couldn't really cache all possible pages (there are lots of bugs, and that would be really inefficient). I suppose you could have each bug page be a separate application, and cache each one as it is viewed online, but this is really wasteful, and more importantly, bug shortcuts won't work offline unless you have previously visited them. Ok, but what are you proposing to _solve_ this? There's no difference between the following two models as I see it: * Download an HTML page for each bug * Download a single page to generate the bug pages plus one data page per bug ...except that the former will mean there's no difference between online and offline, and the latter will mean there _is_ a difference between online and offline, which will bring in its associated sets of bugs. I don't understand how you would expect the client-side server idea (the parsing of server-side URIs on the client) to work. It would be helpful to see actual sample code, maybe. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Offline Web Apps
On Sep 13, 2007 1:59 PM, Ian Hickson [EMAIL PROTECTED] wrote:
Ok, but what are you proposing to _solve_ this? There's no difference
between the following two models as I see it:
* Download an HTML page for each bug
* Download a single page to generate the bug pages plus one data
page per bug
By 'data page' you mean a row of data representing that page? I
presume that downloading a single row of data will be more efficient
than downloading an entire web page plus rechecking all its resources.
It also has the advantage of not making update take as long as
refetching a resource from the server for every possible bug.
...except that the former will mean there's no difference between online
and offline, and the latter will mean there _is_ a difference between
online and offline, which will bring in its associated sets of bugs.
I don't understand how you would expect the client-side server idea (the
parsing of server-side URIs on the client) to work. It would be helpful to
see actual sample code, maybe.
Most AJAX libraries already have code to parse querystrings. It comes
up a lot and it isn't that hard:
http://trac.mochikit.com/browser/mochikit/trunk/MochiKit/Base.js#L1140
Basically, what I'm saying is that an application like Bugzilla has
thousands of possible entry points. These URLs are spread all over the
web and they should continue to work with the offline-enabled version
of Bugzilla. I don't see any way to make this possible efficiently
other than having something like the ability to ignore querystrings.
Something to do more flexible matching would be better, but we thought
this was a good happy medium for gears.
Maybe you were asking how you could keep querystring-based urls in the
offline version of Bugzilla? One option would be to go ahead and keep
using them. In the offline version you could do:
function gotoBug(bugId) {
location.href = ?b= + bugId;
}
This would cause a refresh, but since the page is captured and ignores
querystrings, it is fast.
In your initialization you have something like:
window.onload = function() {
var bugData = db.execute(select * from bugs where id = ?,
parseQueryString()[b]);
}
- a
Re: [whatwg] Offline Web Apps
On Thu, 13 Sep 2007, Aaron Boodman wrote: Ok, but what are you proposing to _solve_ this? There's no difference between the following two models as I see it: * Download an HTML page for each bug * Download a single page to generate the bug pages plus one data page per bug By 'data page' you mean a row of data representing that page? I presume that downloading a single row of data will be more efficient than downloading an entire web page plus rechecking all its resources. We're talking about Bugzilla here. There's a LOT of data to send per bug. All the metadata, all the comments, the entire changelog, it adds up to probably not much less than the actual page as generated by the server. Maybe you were asking how you could keep querystring-based urls in the offline version of Bugzilla? There isn't an offline version. There's just one version, it just happens to support being online and offline. By doing this we're basically saying that the query string never gets sent to the server anymore. That seems like a huge violation of the URI semantics. I think the problem here isn't necessarily just the query parameters though. The problem is more that the application has an open-ended URI space, and we want to capture the whole thing, without actually downloading a near-infinite amount of data per user. Another example would be flickr, where there are bazillions of images, each with their own permalink. Those, though, aren't query parameters. The core problem though is that having an offline mode URI remapping script, as it were, only makes sense if there are separate online and offline apps. The model we're looking at here doesn't have separate online and offline apps. There's just one app, and it works as if it was offline all the time, with two differences: 1. It can atomically update all the infrastructure (markup, scripts, styles, database schema). 2. It can communicate with the server using an out-of-band communication channel while the client is online. To me this means that we either want apps to have a finite URI space, or we want apps to have a way of passing information to pages via URIs that doesn't screw with the existing URI infrastructure. Or both. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Web Forms: SELECT, OPTION, and defaultSelected
Section 2.3 I didn't get any responses on this. It doesn't have any cool like ajax offline; it is a more fundamental (basic) requirement. There is a shortcoming in the specification. 2.3. Extensions to the select element Previous versions of Web Forms were inconsistent about whether the first option element of a single-select select element with no otherwise-selected items should be automatically selected. According to [RFC1866], it should be, and according to [HTML4] it was undefined. User agents implementing this specification must select the initial option element of a single-select select element with no otherwise-selected items. I would like the defaultSelected for this behavior to be true. Currently there is a problem in at least Firefox, and I can't remember about IE. If no OPTION has selected attribute, then Firefox will select the first option in the list. If the first option is selected, it's selected attribute will be true and the defaultSelected will be false. This is because defaultSelected is required to return the value of the HTML selected attribute. The negative result this has is that it causes the form to appear dirty. Form dirty notification is quite useful in modern Ajax applications. In fact, it is useful to broadcast a custom dirty event from a FORM wrapper class (ES). That way, subscribers can listen for the event and enable a submit button, for example. I have implemented this particular example use-case and run into the very problem. The solution was to require the clients (other developers using the FORM wrapper code) to explicitly use the selected attribute. My proposal is to change the text as follows: 2.3. Extensions to the select element Previous versions of Web Forms were inconsistent about whether the first option element of a single-select select element with no otherwise-selected items should be automatically selected. According to [RFC1866], it should be, and according to [HTML4] it was undefined. User agents implementing this specification must select the initial option element of a single-select select element with no otherwise-selected items ***and set its defaultSelected value to true.*** Garrett http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-August/012445.html -- Programming is a collaborative art.
[whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
Regarding the [type] attribute:
interface HTMLTextAreaElement : HTMLElement {
attribute DOMString defaultValue;
readonly attribute HTMLFormElement form;
attribute DOMString accessKey;
attribute longcols;
attribute boolean disabled;
attribute DOMString name;
attribute boolean readOnly;
attribute longrows;
attribute longtabIndex;
readonly attribute DOMString type;
What does the |type| attribute do?
--
Programming is a collaborative art.
Re: [whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
On Thu, 13 Sep 2007, Garrett Smith wrote:
Regarding the [type] attribute:
interface HTMLTextAreaElement : HTMLElement {
attribute DOMString defaultValue;
readonly attribute HTMLFormElement form;
attribute DOMString accessKey;
attribute longcols;
attribute boolean disabled;
attribute DOMString name;
attribute boolean readOnly;
attribute longrows;
attribute longtabIndex;
readonly attribute DOMString type;
What does the |type| attribute do?
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#HTML-HTMLTextAreaElement-type
(WF2 is just a delta spec, it doesn't define anything that is already in
HTML4 and DOM2 HTML. When WF2 is merged with the rest of HTML5, it will be
turned into a real spec.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] successful form controls
I found a few mistakes in the spec. === 5.1. Successful form controls The controls that are successful are those that are included in the submission (in the form data set) when their form is submitted. All form controls are successful except: Controls with no associated form. Controls that are inside repetition templates (those that are in their forms' templateElements list). Controls that are inside datalist elements. Controls with no name, except if they are image controls. Disabled controls. Checkboxes that are not checked. Radio buttons that are not checked. Submit buttons (including image buttons) that did not initiate the current submission process. Buttons of type button, reset, add, remove, move-up, or move-down. Output controls. File upload controls with no value selected, or with only values that point to non-existent files. Controls do not have to have a value to be successful. === missing: * Readonly controls (just like how it works in HTML 4) * controls within a fieldset that is disabled * controls whose associated FORM (either FIELDSET or FORM element) is either disabled or readonly. The WF2 spec does include the attribute disabled for a fieldset, but does not say that disabling a fieldset has *any* effect whatsoever. This, to me, seems to be an oversight. posted last month: http://lists.w3.org/Archives/Public/public-html/2007Aug/0638.html Garrett -- Programming is a collaborative art.
Re: [whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
On 9/13/07, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Sep 2007, Garrett Smith wrote: snipola (WF2 is just a delta spec, it doesn't define anything that is already in HTML4 and DOM2 HTML. When WF2 is merged with the rest of HTML5, it will be turned into a real spec.) There isn't any type attribute on Textarea though, is there? http://www.w3.org/TR/html4/interact/forms.html#h-17.7 Boy will I feel dumb if I've been missing something all this time :/ -g -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Programming is a collaborative art.
Re: [whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
It appears that there is a _DOM_ attribute type [1], but not a _content_ attribute type [2]. [1] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#HTML-HTMLTextAreaElement-type [2] http://www.w3.org/TR/html4/interact/forms.html#h-17.7 On 9/13/07, Garrett Smith [EMAIL PROTECTED] wrote: On 9/13/07, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Sep 2007, Garrett Smith wrote: snipola (WF2 is just a delta spec, it doesn't define anything that is already in HTML4 and DOM2 HTML. When WF2 is merged with the rest of HTML5, it will be turned into a real spec.) There isn't any type attribute on Textarea though, is there? http://www.w3.org/TR/html4/interact/forms.html#h-17.7 Boy will I feel dumb if I've been missing something all this time :/ -g -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Programming is a collaborative art.
Re: [whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
On Thu, 13 Sep 2007, Garrett Smith wrote: On 9/13/07, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Sep 2007, Garrett Smith wrote: snipola (WF2 is just a delta spec, it doesn't define anything that is already in HTML4 and DOM2 HTML. When WF2 is merged with the rest of HTML5, it will be turned into a real spec.) There isn't any type attribute on Textarea though, is there? http://www.w3.org/TR/html4/interact/forms.html#h-17.7 Boy will I feel dumb if I've been missing something all this time :/ You snipped the URL I included in my original reply: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#HTML-HTMLTextAreaElement-type On Thu, 13 Sep 2007, Weston Ruter wrote: It appears that there is a _DOM_ attribute type [1], but not a _content_ attribute type [2]. [1] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#HTML-HTMLTextAreaElement-type [2] http://www.w3.org/TR/html4/interact/forms.html#h-17.7 Right. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
