[whatwg] Database storage API and argument type conversion
It would be a good thing to specify some standard way to convert argument types for the executeSql call. This question was first raised on public-html list (http://lists.w3.org/Archives/Public/public-html/2008Feb/0401.html), suggesting that the types, not directly supported by the database engine (SQLite seems to be the logical choice) are treated as strings. In other words, if the type of the argument is not null, string, double, or int, the argument is implicitly converted to to string. As an alternative, I would like to present a slightly different approach: if, during step 3 of the executeSql algorithm (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html#executing), an argument is found to be unpalatable for the underlying database implementation, the statement is marked bogus. Though a bit more stringent than the implicit conversion, this approach explicitly prevents any subtle coercion bugs and will probably lead to more debuggable code. What are your thoughts on this, oh wise WHATWG oracle? :DG
[whatwg] SQL storage API: optional name, version of the openDatabase()
Is there any reason not to make name and version of the openDatabase() method in the SQL storage spec optional (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html)? In some implementations, there may not be an opportunity to offer a UI where these parameters will be used. :DG
[whatwg] Moving openDatabase off the UI thread
In the current SQL storage spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html), all database operations can be nicely tucked onto a separate thread, so that they don't block the UI thread, except for one place: openDatabase has to query version information and open or create the database. This seems a bit out-of-sync (oh no, bad pun) with the rest of the spec, where everything is asynchronous. Would it be more logical/practical to explicitly (per spec) move the actual opening of the database off the main thread? Like so: Verifying database version and opening/creation of the database occurs at pre-flight of the transaction, unless the database is already open. Thus, no potential UI thread blockage by the database operations during openDatabase invocation, as well as no need to raise the INVALID_STATE_ERR exception. What do you think? :DG
Re: [whatwg] SQL storage API: optional name, version of the openDatabase()
Name and version is not just used for UI, it is used to specify what database to open and to prevent schema conflicts. But I assume you are talking about the display name. Just because an implementation wont present the display name in UI, other implementations will. Letting authors optionally leave out the display name will just give a bad experience is user agents that do show them. User agents that don't plan to show the display name could just ignore the argument. On Apr 10, 2008, at 4:36 AM, Dimitri Glazkov wrote: Is there any reason not to make name and version of the openDatabase() method in the SQL storage spec optional (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html)? In some implementations, there may not be an opportunity to offer a UI where these parameters will be used. — Timothy Hatcher
Re: [whatwg] Database storage API and argument type conversion
Converting an object to a string has a very defined path in JavaScript, toString is called. Perhaps the spec should mention toString. Marking the query as bogus seems wrong, since the JavaScript language is very lenient about types and implicit type conversions when needed. Implicit conversion to strings is what any proficient JavaScript author would expect to happen. I don't see any reason to make the storage spec behave differently. On Apr 10, 2008, at 4:32 AM, Dimitri Glazkov wrote: In other words, if the type of the argument is not null, string, double, or int, the argument is implicitly converted to to string. As an alternative, I would like to present a slightly different approach: if, during step 3 of the executeSql algorithm (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html#executing ), an argument is found to be unpalatable for the underlying database implementation, the statement is marked bogus. Though a bit more stringent than the implicit conversion, this approach explicitly prevents any subtle coercion bugs and will probably lead to more debuggable code. — Timothy Hatcher
Re: [whatwg] SQL storage API: optional name, version of the openDatabase()
Doh! I apologize. This has not been one of my shiniest moments. In addition to what Aaron says, I actually meant the reverse: only name and version being required (potentially with version optional, as he suggests), and display name and estimated size being optional. :DG On Thu, Apr 10, 2008 at 11:42 AM, Aaron Boodman [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 9:26 AM, Timothy Hatcher [EMAIL PROTECTED] wrote: Name and version is not just used for UI, it is used to specify what database to open and to prevent schema conflicts. Whoops, yeah. This request actually originally comes from me, and what I was referring to was the version parameter to open(). It can currently be the empty string, but it cannot be omitted. Any reason why not? Some (most?) applications will not need this field and it seems unfortunate to force them to pass an empty string. - a
Re: [whatwg] SQL storage API: optional name, version of the openDatabase()
On Thu, Apr 10, 2008 at 9:53 AM, Dimitri Glazkov [EMAIL PROTECTED] wrote: Doh! I apologize. This has not been one of my shiniest moments. In addition to what Aaron says, I actually meant the reverse: only name and version being required (potentially with version optional, as he suggests), and display name and estimated size being optional. I see. My original question doesn't even make sense given that displayName and estimatedSize are not optional. I guess I had gotten used to not thinking about those two parameters because Gears is not planning on using them. Our applications sometimes use multiple databases (because they are stretched across origins) and it does not make sense to put up a dialog for each one. But I don't have a proposal right now, so just ignore this thread. Sorry! - a
Re: [whatwg] Database storage API and argument type conversion
On Thu, Apr 10, 2008 at 9:34 AM, Timothy Hatcher [EMAIL PROTECTED] wrote: Converting an object to a string has a very defined path in JavaScript, toString is called. Perhaps the spec should mention toString. Marking the query as bogus seems wrong, since the JavaScript language is very lenient about types and implicit type conversions when needed. Implicit conversion to strings is what any proficient JavaScript author would expect to happen. I don't see any reason to make the storage spec behave differently. So, we have some experience with this, having built several large applications using an earlier version of the database API. Our current implementation does coerce to string (we had the same initial assumption as you), and having learned our lesson, we would like to fix this in v2. Here are a couple reasons why we would like to make this more strict: 1) There are lots of strange edge cases. SQLite does not support boolean. Would you coerce it to a string? That means that if you insert false and then select it, you get back something that evaluates to true. Similar problem for undefined. Maybe a more sensible coercion for these two types would be to int, but it seems weird to make arbitrary distinctions for some popular input types, and you're still losing information. 2) Permanence. Coercion is a nice convenience most of the time in JS, but I think with a permanent store, the damage you can do accidentally goes up and warrants more care. An author probably will not find out that he accidentally coerced undefined to string until long after the damage has been done. It may be difficult to fix the data retroactively. It doesn't seem worth the convenience to me. We actually tried to fix this bug a little while after launch and found non-Google applications in the wild accidentally storing undefined. So this is a real concern for us. 3) Forward compatibility. If an implementation allows all valid js types and coerces unsupported ones to supported ones, then it can never add supported types. This is bad for implementors. So for all these reasons, the Gears team will probably not be implementing coercion in our implementation of the HTML5 database spec. I'm not sure whether this belongs in the spec (it is tied to SQLite details), but I think it is something vendors should keep in mind, and it would be nice if we aligned on. - a
Re: [whatwg] several messages relating to the alt= attribute
The HTMLWG's ISSUE-31 is Should img without alt ever be conforming. It isn't clear from this issue what exactly the problem with the current spec text is. The current text in the spec requires alt= in all cases except when the page is generated in a manner where alternative text is not available, or when there is no possible way to provide text that is in any way a replacement for the image. Two examples are given, namely a photo upload site, and a Rorschach inkblot test. In the former case, the image is generated automatically and the program simply does not have enough information to provide alternative text. In the latter case, _any_ description would miss the point of the test (which is to see what descriptions people come up with). The spec contains very strong wording requiring alternative text in all manner of possible situations, and encouraging it even in the aforementioned cases. I'm not sure what else we can do short of just making it non-conforming to create bulk-upload image hosting sites or write documents that contain inkblot tests. If the issue's title is ever to be answered in the negative, it would be helpful for solutions to the two examples above to be provided. I've closed the issue, to indicate that I have examined it in detail and come to a tentative conclusion. Further input from anyone, but in particular the PFWG, is welcome and encouraged; if anyone disagrees with this issue they are of course encouraged to reopen the issue in the issue database, preferably at the same time as providing further information to help answer the issues given above. :-) Here are some answers to other issues raised on the topic: On Thu, 6 Jan 2005, James Graham wrote: Matthew Thomas wrote: For perhaps 95 percent of the images on the Web, the most appropriate alternate text is nothing at all. (In 2003 I did a survey of images in Wikipedia articles, where images aren't even used for decoration, and still found that alt= would be the most sensible choice for 77 percent of them.) So for that 95 percent, assuming that no alt is alt= would improve the user experience. Unfortunately, the other 5 percent would ruin the idea. When screenreaders are wading through inaccessibly-written pages, sometimes images are used for navigation (graphical menus, for example), so the user needs an indication that an image is there (whereupon they can guess its function by its URI). Assuming that all these images had alt= would make such pages completely unnavigable. Both this and the other point that Jim made (implied alt is hard to debug) strongly suggest that alt should be optional, not implied. The lack of an alt attribute would legitimize any inference about suitable alternative text that the web browser wanted to perform. Therefore it would remain best practice to explicitly declare alt= where the image is purely decorative. I expect many web developers would favor this approach since the validator complaining about a lack of alt= has been perceived as unnecessary nannying and so the requirement has widely been ignored. Making alt optional probably wouldn't damage accessibility as much as might be thought because a) bad alt text is at least as bad as missing alt text and b) there exist other tools that explicitly check documents for accessibility which could flag missing alt attributes. This is the reasoning behind the current wording of the specification. On Thu, 6 Jan 2005, Andrew Kirkpatrick wrote: Alt should be required on inputs of type=image, area elements, and perhaps on images within anchors (although images within an anchor that also contains text or another image with alt could be fine without alt also, so I'm not sure how to best handle that). The form control issues (input type=image) are pending a result from the forms task force (I don't want to write that part of the spec only to find the whole thing has to be rewritten). Omitted alt= attributes only make sense (and are only, reluctantly, allowed) when the site serving the image simply has no idea what the image is, but knows that it is important. One could easily imagine a situation where that is the case, but where the image is in a link. For example, any image on Flickr that doesn't have useful metadata falls into this category. Thus I don't think we can make that requirement, as it would only lead to nonsense alt text or the concept of validity being ignored altogether. As a person who works in the area of accessibility, I'm inclined to agree that alt doesn't really need to be required. What is unusual is that not only is this a solid idea theoretically, but the user agent base supports it already. That's good to know. Users can, and probably would continue to be able to, get their user agent to voice all images without regard to the presence of alt if they wanted. Having alt be required is an argument that assumes that
[whatwg] More Storage clarification
In 4.10.5, the description of the properties on the StorageEvent object mentions ...its newValue attribute set to the new value of the key in question, or null if the key was removed... So a web author can assume that when handling a StorageEvent whose newValue property is null that the event was the result of a removeItem(), and the key is no longer in the list. However in 4.10.2 in the discussion of setItem(), there is no mention that null is not an allowed value. Something like sessionStorage.setItem(key, null) is not forbidden, therefore it is allowed, and it would result in a StorageEvent with a null newValue. To resolve this case, I propose that we specify that the value in a key/value pair cannot be set to null. I see two clean ways to specify this: 1 - Throw an exception when setItem() is called with a null value. 2 - Specify setItem(key, null) to have the exact same effects as removeItem(key). I prefer #2. Thoughts? ~Brady
Re: [whatwg] More Storage clarification
On Fri, 11 Apr 2008 01:01:46 +0200, Brady Eidson [EMAIL PROTECTED] wrote: In 4.10.5, the description of the properties on the StorageEvent object mentions ...its newValue attribute set to the new value of the key in question, or null if the key was removed... So a web author can assume that when handling a StorageEvent whose newValue property is null that the event was the result of a removeItem(), and the key is no longer in the list. However in 4.10.2 in the discussion of setItem(), there is no mention that null is not an allowed value. Something like sessionStorage.setItem(key, null) is not forbidden, therefore it is allowed, and it would result in a StorageEvent with a null newValue. To resolve this case, I propose that we specify that the value in a key/value pair cannot be set to null. I see two clean ways to specify this: 1 - Throw an exception when setItem() is called with a null value. 2 - Specify setItem(key, null) to have the exact same effects as removeItem(key). I prefer #2. Thoughts? Euhm, setItem() takes two strings. Therefore I'd expect null, undefined, etc. to be stringified. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Image() constructor
On Sat, 4 Nov 2006, Anne van Kesteren wrote: Just so I don't forget to ask this. Are you sure the arguments are unsigned long? Just wondering because the height and width attributes can have percentages as values. Pretty sure, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element: downloading a resource
On Tue, 7 Nov 2006, Anne van Kesteren wrote: The definition of downloading a resource must be clear that even if the resource does not need to be downloaded (because it has been cached or something) the load event still needs to be dispatched (or the error event, in case it contains errors). Isn't this an HTTP issue? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element: downloading a resource
On Fri, 11 Apr 2008 02:03:45 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 7 Nov 2006, Anne van Kesteren wrote: The definition of downloading a resource must be clear that even if the resource does not need to be downloaded (because it has been cached or something) the load event still needs to be dispatched (or the error event, in case it contains errors). Isn't this an HTTP issue? I suppose you could call it that. The main issue is that people are confused with the current wording and assume it either doesn't cover cached images or that in case of images being cached the text does not apply. (The Opera browser has for some time not dispatched those events because of incorrect assumptions.) So a generic note somewhere that downloading can refer to retrieving it over the network or reading it from the cache, etc. would be good. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
