Re: Feedback on "Offline Web Applications" (Editor's Draft 17 November 2007)

On Sun, 18 Nov 2007 19:54:35 +0100, Julian Reschke <>  
> below is some feedback on "Offline Web Applications" (Editor's Draft 17  
> November 2007) (<>).


Since there was some interest in this draft I got ACTION-58 to address the  
feedback given in this e-mail.

> Summary: if the intent of this is to make people aware of the presence  
> of these new things in HTML5, it's working. However, in it's current  
> state it really requires the reader to go to the real spec to understand  
> what's going on -- that may be ok, but in this case it would be helpful  
> if it could point directly to the section of HTML5 containing the full  
> details.

I added the two relevant pointers to the introduction section:

> Content:
> 2. SQL -- Not being familiar with what is being defined, I found the  
> example a bit confusing. If this is meant to be an introduction, I think  
> it would make sense to (1) show the DB creation first and (2) add a few  
> sentences about how the API exactly looks like. So what elements does  
> openDatabase() take(), why does db.transaction take a function argument,  
> what exactly does the executeSQL function expect parameter-wise?


> 3. Offline Application Caching APIs -- seems the spec defines a new text  
> format for defining the application caching. Is there a MIME type being  
> defined? Any grammar for the format? Turns out this is defined in  
> <>, so it's probably fine to  
> leave it out here. However, *what* is defined over there ("Note: This is  
> a willful double violation of RFC2046.") makes me nervous. Not sure why  
> this isn't simply an XML format; instead of defining yet another special  
> text format with (IMHO) quite obscure parsing rules (CR only as line  
> delimiter???)

This seems to be feedback on HTML 5 rather the note so I'm unable to  
address this.

> 3. Offline Application Caching APIs -- not sure that using "server.cgi"  
> as a name is a good idea over here; my understanding was that Cool URIs  
> Do Not Change, thus encoding some technology-specific extension into an  
> URI generally is not a good idea. Suggest to simply use something like  
> "events".

I think "server.cgi" more accurately indicates it takes a URI than if we  
just used the "events" so I left at is. (If the technology changes a  
permanent redirect can be used or you simply change the type using a  
ForceType directive or something like that. Should not be much trouble.)

> Editorial:
> - The Javascript examples do not terminate statements with a semicolon.  
> My understanding is that although it's legal, it's discouraged (see  
> <>). Minimally, it's confusing to read  
> for people who have grown up with C and Java.

I like writing JavaScript that way, but I got another example that  
included them. So this is addressed now.

> - "...that takes up one mebibyte of storage." -- Typo?

This no longer appears in the draft. (It was not a typo though, a mebibyte  
is the "official" name for 1024^2 bytes.)

Anne van Kesteren

Received on Tuesday, 22 April 2008 13:42:12 UTC