Re: DOM collections index out of bounds and JavaScript.
Seems to me that when you access a slot that in some sense doesn't exist it should return undefined, not null. There are plenty of semantic cases (is this attribute defined but currently unset, or not defined at all) where the difference can be significant. I realize not all languages support the distinction, but JS does and it's actually a useful feature. ss On Tue, Oct 19, 2010 at 11:06 AM, Erik Arvidsson a...@chromium.org wrote: On Tue, Oct 19, 2010 at 09:50, Garrett Smith dhtmlkitc...@gmail.com wrote: ... CSSStyleDeclaration. What about the other collection objects? HTML5 says that collections are now callable and specifies that indexed property access on collections returns null. But what about other APIs such as NodeList, NamedNodeMap, CSSRuleList, and StyleSheetList? Almost all of them are defined to return null. Actually CSSStyleDeclaration is the only exception I could find in WebCore sources. Changing the wording for each collection would be painfully repetitious, involving a spec author for each spec. There is not any super interface collection defined that also defines `item`, callability, property access, etc. though if there were then all collection type objects inherit from that and would avoid shotgun surgery. That would seem to be something for DOM 4 core, if such a thing is to be written. WebIDL has a section for sequence but it is not fleshed out yet. erik
Re: Web Storage SQL
SQLite wasn't the first browser-accessible DBMS, nor is it the most ubiquitous choice of target. IE's Jet database engine, which is the underlying engine for Access, would seem to be the most useful target specification. After all, the overwhelming majority of what I've heard over the past decade when discussing database support in a web browser can be paraphrased as I want to port my Access application to the browser. Can I do that? Changing the storage model or semantics away from those supported by Access would seem to be a great way to throw another roadblock in front of customers whose prior desktop applications have typically relied on Access, not Oracle, and certainly not Versant et. al. ss
Re: [cors] security issue with XMLHttpRequest API compatibility
Using a variation on the example in the spec...
var password = ... // global variable holds user's password
function deleteItem(itemURL, updateUI) {
var client = new XMLHttpRequest()
client.open(DELETE, itemURL)
client.onload = updateUI
client.onerror = updateUI
client.onabort = updateUI
client.send(password= + password)
}
Well, if a script can rely on someone being as foolish as to store
their username and password as globals then why bother working that
hard...just ping a url with them. I can't see how this is relevant to
the spec in terms of a specific vulnerability.
ss
Re: Required support for SVG in widgets
On Feb 3, 2009, at 4:22 PM, Jonas Sicking wrote: Is there a reason to require any formats? In very few places we do this. For example the HTML and CSS specs don't require support for JPEG, GIF or PNG. Neither HTML or SVG require support for javascript. Is there a reason for the widget spec to be different? From the SVG Specification, Section G.7 Conforming SVG Viewers ... Specific criteria that apply to only Conforming Dynamic SVG Viewers: In Web browser environments, the viewer must have the ability to search and select text strings within SVG content. If display devices are supported, the viewer must have the ability to select and copy text from SVG content to the system clipboard. The viewer must have complete support for an ECMAScript binding of the SVG Document Object Model. ss
