Re: [IndexedDB] blocked event should have default operation to close the connection
On Wed, 09 Oct 2013 17:06:13 +0200, Kyaw Tun kyaw...@yathit.com wrote: My suggestion is to make close method as default operation of blocked event. For that app, that require to save data should listen blocked event and invoke preventDefault() and finally close the connection. Hi. This was already discussed in length here http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0215.html TL,DR: the status quo of the implementations (still experimental in 2012) dictated that the behavior is to be preserved. Bye.
Re: Two years on and still no sensible web storage solutions exist
On Mon, 12 Nov 2012 19:27:33 +0100, Florian Bösch pya...@gmail.com wrote: The hard quota is not my idea. It's what those browsers who do implement WebSQL implement. Unlike IndexedDB which triggers a do you want to allow yadda yadda or whatever, at least sometimes, WebSQL is hard limited to 5mb. You're again confusing implementation details with the specification. User agents are free to implement whatever quota management they want, as long as it's transparent and respects the visible effects on the webpage side.
Re: Two years on and still no sensible web storage solutions exist
On Mon, 12 Nov 2012 19:50:20 +0100, Florian Bösch pya...@gmail.com wrote: On Mon, Nov 12, 2012 at 7:42 PM, João Eiras jo...@opera.com wrote: You're again confusing implementation details with the specification. User agents are free to implement whatever quota management they want, as long as it's transparent and respects the visible effects on the webpage side. That may be so, it still means WebSQL is universally hard limited without escape to 5mb. So it doesn't really matter if that's what's specced or not, it makes it equally unsuitable for data beyond 5mb. Again, not a spec issue. Go to your favorite browser bug tracker and make a feature request.
[IDB] Lifetime of IDB objects
Hi ! The specification does not specify in detail what happens to several of the object types once they have reached their purpose. For instance, IDBTransaction's abort and objectStore methods dispatch InvalidStateError. However, IDBRequest and IDBCursor have properties which return other objects like IDBRequest.source, IDBRequest.result, IDBRequest.transaction, IDBCursor.source, IDBCursor.key, IDBCursor.primaryKey which behavior, after the request has completed, is undefined or defined as returning the same value (for source only it seems). Having these objects keeping references to other objects after they have completed, can represent extra memory overhead, while not very useful, specially if the application is data heavy, like an offline main client with lots of requests, or long blobs are used, and it prevents the garbage collector from cleaning up more than it could, specially while a transaction is active. I suggest that after an IDBRequest, IDBTransaction or IDBCursor complete, all their properties are cleared (at least the non-trivial ones) so the garbage collector can do it work. However, since that would cause the properties to return later undefined/null, it is better if they just all throw InvalidStateError when accessed after the object has reached it's purpose. Btw, an error in http://www.w3.org/TR/IndexedDB/#widl-IDBCursor-source This function never returns null or throws an exception. Should be This property. Thank you.
Re: IndexedDB: undefined parameters
On Tue, 09 Oct 2012 20:37:36 +0200, Alec Flett alecfl...@chromium.org
wrote:
On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/9/12 1:52 PM, Joshua Bell wrote:
The IDB spec does not have [TreatUndefinedAs=Missing] specified on
openCursor()'s arguments (or anywhere else), so I believe Chrome's
behavior here is correct.
It looks correct as the spec is currently written.
It's not clear to me why the spec is written the way it is. It could
just
as easily define that if the any value is undefined, it's ignored.
Or it
could use [TreatUndefinedAs=Missing], indeed.
I have to say, as a developer it can be really frustrating to write
abstractions on top of APIs that behave this way, when you want to say
something like:
var direction;
var range;
if (condition1)
direction = 'prev';
else if (condition2)
direction = 'prevuniq';
if (condition3) {
range = range1;
else if (condition4)
range = range2;
return source.openCursor(range, direction);
According to the issue here, it would have to be written as
$ if (range direction) return source.openCursor(range, direction);
$ else if(range) return source.openCursor(range);
$ else return source.openCursor(range);
which is a bit annoying, specially if the parameters are being already
passed to a wrapper function, e.g.:
$ function open_cursor(range){
$ return os.openCursor(range, 'next');
$ }
$ open_cursor();
Re: [IndexedDB] blocked event could be an error
http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. The spec is still a working draft, all uses so far of IDB online are either html5 benchmarks or tutorials/examples. So, nothing of importance will be affected, Besides, this is a corner case.
Re: [IndexedDB] blocked event could be an error
I definitely think that we need to keep the blocked events as non-error events since it supports the use case of opening a connection and displaying UI to the user asking that other tabs are closed if the blocked event fires. That can very well be achieved by detecting the BlockedError, and adding a retry button which calls open() again. If you really want a open() and wait forever behavior, that should not be the default one.
Re: DOMParser Errors Should Be Exceptions
On Wed, 23 May 2012 21:08:32 +0200, Ms2ger ms2...@gmail.com wrote: On 05/23/2012 09:03 PM, Yehuda Katz wrote: In the current DOM parsing spec[1], errors in XML (or SVG) are handled as follows: Let root be a new Element, with its local name set to parsererror and its namespace set to http://www.mozilla.org/newlayout/xml/parsererror.xml;. At this point user agents may append nodes to root, for example to describe the nature of the error. In practice, browsers implement error handling in this way. The output for the following code is given below. (new XMLSerializer).serializeToString((new DOMParser).parseFromString(trhi, text/xml)); As a result, jQuery looks for a parserror tag and re-raises an error when parsing XML[2]. In my view, the DOMParser should throw an exception, and not insert a partially unspecified parserror tag. Thoughts? Opera has reported this is not web-compatible. Ms2ger Opera thrown an exception long time ago and since version 9.5 it changed the behavior to return the bogus parsererror tree because it caused yahoo mail to fail back them (among other things). While the current behavior of returning the parsererror document is inappropriate, I afraid it also unchangeable.
[IndexedDB] Synchronous access to object stores
Hi.
After a open database request, going from the IDBDatabase to the
IDBObjectStore's properties is synchronous, which means that either all
the metadata for every object store has to be preloaded, or that the
ecmascript engine needs to wait (therefore blocking the page) while the
request is done in the background.
The first issue raises the question: what if there are 10 000 object
stores ? Preloading everything is overkill. The second issues raises
another question: blocking for file IO ?
var r = indexedDb.open('foo');
r.onsuccess = function(){
r.transaction('o').objectStore('o').indexNames;
}
Supporting this is a trivial implementation detail, but the spec has the
issue nonetheless.
Re: [DOM4] Constructor for DOMException?
On Thu, 23 Feb 2012 00:57:54 +0100, Cameron McCormack c...@mcc.id.au wrote: João Eiras: DOMExceptions have both a code and a message. Perhaps the constructor should be extended to include both. Anne van Kesteren: code is legacy, but name would be good to expose. The constructor has the same signature as the standard ECMAScript Error constructors, so we are being consistent there. I think it's fine for code and name to be assigned after creating the object, if JS needs to create a DOMException object (which I don't expect to be a common thing anyway). Well, it does make # throw new DOMException(message) and bit more verbose: # var e = new DOMException(message); # e.code value; # throw e; Adding the code as a second optional argument would be ok.
[IndexedDB] IDBDAtabase.transaction clarification
Hi. It seems IDBDatabase.transaction in the working draft is poorly defined. IDBDatabase.transaction, according to the transaction creation algorithm, have a null callback, but then IDBDatabase.createObjectStore and IDBDatabase.deleteObjectStore say they should fail if not called from the transaction callback. I think it should be changed so they fail if there is not an active transaction, or that the current active transaction is not a VERSION_CHANGE one. Is this the intended behavior ? It tells IDBDatabase.transaction returns the IDBTransaction object. Shouldn't it be an IDBRequest object ? If not, then what the lifetime of the transaction ? When should it be commited ? IDBDatabase.transaction accepts either an array of strings or string as first argument, which are the name of the object stores. What should be used for the very first transaction of an empty database with no object stores ? Empty array ?
Re: [IndexedDB] IDBDAtabase.transaction clarification
IDBDatabase.transaction accepts either an array of strings or string as first argument, which are the name of the object stores. What should be used for the very first transaction of an empty database with no object stores ? Empty array ? When a database is created a VERSION_CHANGE transaction is automatically created. So there is no need to call IDBDatabase.transaction. Not entirely sure I understand the question here. Then how can one get a reference to that IDBTransaction object ?
Re: [DOM4] Constructor for DOMException?
On Wed, 22 Feb 2012 00:00:24 +0100, Cameron McCormack c...@mcc.id.au wrote: Marcos Caceres: So… given that one can fake create a DOMException, and unless there is a valid reason not to allow this that I don't know of…. It would be nice if DOMException just defined a public constructor. This would allow clean prototyping of various APIs in ECMAScript (and give us poor saps who don't know C a chance to implement some Web APIs :) ). Web IDL already requires exception interface objects like DOMException to be constructable, due to this: http://dev.w3.org/2006/webapi/WebIDL/#es-exception-call and them being Function objects. The constructor should take a single argument which is the message. DOMExceptions have both a code and a message. Perhaps the constructor should be extended to include both.
Re: XPath and Selectors are identical, and shouldn't be co-developed
On Tue, 29 Nov 2011 20:42:59 -, Tab Atkins Jr. jackalm...@gmail.com wrote: My stated goal was to argue that working on XPath is a bad idea You can argue that it's wasted effort or duplicated by CSS Selectors (although XPath is already specified, implemented and deployed unlike the new Selector features), but it goes a long way for you to claim it is a *bad* idea. I still think you are underestimating XPath. There are things possible in XPath today that will never be possible with Selectors in the unforeseeable future, like a parent selector, or doing a case insensitive substring match of a node's text content (from any descendant). If you're suggesting forking Selectors into the ones used in stylesheet, and the others used in the Selector API, then it is repeated effort and a *bad* idea because those use cases are already covered today with already deployed XPath and its DOM 3 XPath API, which is convoluted and hard to use, which is what people are trying to make friendlier. And it would definitely confuse everyone, because then developers would need to know which features they can use in stylesheets and which they cannot.
Re: XPath and find/findAll methods
On Tue, 22 Nov 2011 13:05:18 +0100, Simon Pieters sim...@opera.com wrote:
On Mon, 21 Nov 2011 20:34:14 +0100, Martin Kadlec bs-ha...@myopera.com
wrote:
Hello everyone,
I've noticed that the find/findAll methods are currently being
discussed and there is one thing that might be a good idea to consider.
Currently, it's quite uncomfortable to use XPath in javascript. The
document.evalute method has lots of arguments and we have to remember
plenty of constants to make it work. IE and Opera support selectNodes
method on NodePrototype, which is really useful, but what's the point
in using it when it doesn't work in FF/Chrome/Safari.
Maybe FF/Chrome/Safari should add support for selectNodes?
The way IE has implemented selectNodes/selectSingleNode doesn't make it
much XPath conformant, although their API is only available in XML
documents created using a xml element or an ActiveXObject.
By default IE does a prefix match. If you call
document.getProperty('SelectionLanguage') it returns 'XSLPattern'. You'd
need to do document.setProperty('SelectionLanguage', 'xpath') to use real
XPath and need you'd need to do
document.setProperty('SelectionNamespaces', 'xmlns:a=foo xmlns:b=bar')
to map the prefixes to a namespace.
Then the IE API looks like
* Element.selectNodes/selectSingleNode(expression)
* Document.selectNodes/selectSingleNode(expression, contextNode)
Opera has implemented the API with some clear differences.
* obviously, the expression are always XPath
* both Element and Document provide the contextNode
* namespace resolver in the second argument. It is of the same kind as
the one used in the DOM 3 XPath API
So it looks like
* Element.selectNodes/selectSingleNode(expression, namespaceResolver)
* Document.selectNodes/selectSingleNode(expression, namespaceResolver)
Neither Gecko nor Webkit have anything remotely related.
I think the API should steer in Opera's direction, with the remarks that
the namespace resolver should be supported, and that the API should return
other returns types than just Node, because XPath expressions can return
strings and integers.
Re: [Widgets] WidgetStorage interface
Yes. Simple rule: if you change the behaviour of an interface even slightly, sub-class it. Let me clarify a little bit here, because it's bugging me. Usually, an object can take an interface and implement new custom behavior without any problems (interfaces generally are supposed to decuple interaction from implementation… as it's done in Java… with, say implements Runnable). However, in this particular instance, it seems that it's not possible to reuse an interface in this way (maybe it's some C thing, or maybe Storage is not actually defined as an interface but as an object). Or then it's an implementation problem, and there is little point changing the specification ? I don't see how a new interface object would make programming its behavior more easy.
Re: XPath and find/findAll methods
On Tue, 22 Nov 2011 13:42:36 +0100, Robin Berjon ro...@berjon.com wrote: Such data is notoriously hard to come by, but just as a data point: I know that Opera recently introduced a regression in its XPath support Which regression ?
Re: XPath and find/findAll methods
On Tue, 22 Nov 2011 14:15:59 +0100, Robin Berjon ro...@berjon.com wrote: On Nov 22, 2011, at 14:03 , João Eiras wrote: On Tue, 22 Nov 2011 13:42:36 +0100, Robin Berjon ro...@berjon.com wrote: Such data is notoriously hard to come by, but just as a data point: I know that Opera recently introduced a regression in its XPath support Which regression ? I believe it's called DSK-350606 and/or CORE-42716. I don't believe I have access to check for this myself. Thank you. Seems it was caused by the new html parser but hardly something too serious.
Re: innerHTML in DocumentFragment
On Fri, 04 Nov 2011 00:48:29 +0100, Anne van Kesteren ann...@opera.com wrote: On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down timd...@gmail.com wrote: Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment That requires a context. Yehuda wants a way of parsing where you do not know the context in advance. This is something I've always wanted, so I always wrote my piece of code to make the task easier. But I do suggest a different solution: Instead of # var f = document.createDocumentFragment() # f.innerHTML = '...'; which is quite verbose, I would suggest a simpler API, like # var document_fragment_node = parseFragment(markup_fragment, Node contextNode, boolean safe); # var element_node = parseNode(markup_fragment, Node contextNode, boolean safe); # var document_node = parseDocument(markup_fragment, boolean safe); * markup_fragment is the html string, or xml depending on the type of document of the ownerDocument of contextNode. * contextNode is an Element for parsing context and to know the ownerDocument, or if context is not important, the Document which will be the ownerDocument of the resulting fragment * stripScripts is a boolean that tells the parser to strip unsafe content like scripts, event listeners and embeds/objects which would be handled by a 3rd party plugin according to user agent policy. - parseFragment parses a markup fragment which may not have a single root element, hence having siblings, with context. - parseFragment parses a markup fragment which must have a single root element, so the DocumentFragment can be spared. This is usually the most wanted use case. - parseDocument similar to DOMParser but for html. At least for me, an API with these features are everything that I've ever needed. Thanks.
Re: Proposal for a new Matrix API
On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira
igor.olive...@openbossa.org wrote:
Hello,
Currently CSSMatrix and SVGMatrix has an immutable API. None of the
method calls change the Matrix, instead, it creates a new Matrix with
the changed value. It can be a problem specially when CSSMatrix is
used together with WebGL. [1]
I would suggest that the matrix should not be a host object. Instead is
should be a pure ecmascript object so it can run closer to the metal (be
jitted easily).
I did suggest previously extending array a bit, like
{length: 6, height: 2, width:3, 0. ..., 1: ..., 2: ..., 3: ..., 4: ..., 5:
..., }
which represents a 2x3 matrix. The matrix would not have any kind of side
effects or limitations, possibly being of any arbitrary size, hence usable
not only by graphical APIs, but by any algebra you throw at it.
The methods you suggest, would then be on the prototype, or in the Math
object.
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
It'd be great if that were the case, but in my experience this is the level of annoyance that will irritate users, but not enough to make many of them stop using a site. This same discussion always pops up when a new feature might have implications beyond the browser window, like dd, file api, web gl, clipboard api, etc. Features are demanded and the specs need to be written in a way that supports most, if not all, of the valid use cases. If there are possibilities of those same APIs being used to hinder user experience, then the user agent must provide options for the user to control what the sites do, so it becomes an UI issue. And, such websites are few, slim, and have little users. Now, we can move forward :) Thank you.
Re: [Clipboard API] setData description
That second phrase is very confusing. Isn't it the objective of listening to cut/copy events, to possibly prevent the default action and set the data calling setData, therefore changing clipboard contents ? Yes, but not *paste* events. Pasting should never alter the data on the clipboard. How can I phrase it more clearly? Doh, my confusion. Perhaps paste should be emphasized :)
Re: [Clipboard API] Copy to clipboard
On Mon, 05 Sep 2011 12:47:28 +0200, Hallvord R. M. Steen
hallv...@opera.com wrote:
On Mon, 05 Sep 2011 02:14:10 +0200, João Eiras joao.ei...@gmail.com
wrote:
Hi !
The spec for setData [1] states that this method when calling from a
cut/copy event sets new data on the clipboard. Unfortunately, this is
insufficient to implement the typical copy to clipboard button
It is indeed. However, you already have things like
document.execCommand('copy') for that.
So lets say I have one of features which let me copy to the clipboard a
snippet of html to embed a video for instance, to paste somewhere.
A script needs to create an element, put the contents inside, wrap a
selection around it, call execCommand('copy'), remove the element and
shift focus back to the button.
Seems a bit overkill. Are you really sure it can't be made simpler ? The
feature is there already, theoretically.
Re: Copy prevention... up-and-running
On Mon, 05 Sep 2011 13:03:25 +0200, Paul Libbrecht p...@hoplahup.net wrote: While the discussion about preventing abuse in clipboards is happening, allow me to suggest something I recently found: In the page below is a fairly simple script that succeeds in preventing the user to select with the mouse, hence copy, in Firefox 6, Safari 5.1, and a few others. http://www.diakadi.com/guadeloupe/feroce_d_avocat.htm The workarounds include: use Camino, print-preview and select there, use select all. Can something be done to prevent this prohibition? Do we want that? paul Hi. The page abuses legitimate features to control selection, which have legitimate use cases. If users don't like it they can just use another website, or disable javascript.
Re: [DOM] Name
Given that the specification replaces most of DOM2 and DOM3 I suggest we name it DOM4, including for the upcoming WD (or alternatively a WD we publish a couple of weeks later). I propose calling it Web Core. WC1 (Web Core version 1). Without hesitation, I concur. +1 Jarred It needs DOM on the name, so it is really not suitable. I think DOM4 is definitely the way to go, kind like how html5 completely replaced html4.
[Clipboard API] setData description
Hi. The description for DataTransfer.setData [1] says: Calling setData() from a paste event handler must not modify the data that is inserted, and must not modify the data on the clipboard. That second phrase is very confusing. Isn't it the objective of listening to cut/copy events, to possibly prevent the default action and set the data calling setData, therefore changing clipboard contents ? Thank you. [1] http://dev.w3.org/2006/webapi/clipops/clipops.html#widl-clipboardData-setData-boolean-DOMString-type-DOMString-data
[Clipboard API] Copy to clipboard
Hi ! The spec for setData [1] states that this method when calling from a cut/copy event sets new data on the clipboard. Unfortunately, this is insufficient to implement the typical copy to clipboard button, or going even further, the clipboard toolbar with buttons for the 3 actions (copy, cut, paste) typically seen in text editors. Perhaps the spec should somehow include a way for a webpage, or origin, to request the user more privileges accessing the clipboard ? But this could somehow be abused, therefore such solution should not give direct access to the system clipboard that easily. [1] http://dev.w3.org/2006/webapi/clipops/clipops.html#widl-clipboardData-setData-boolean-DOMString-type-DOMString-data
Re: Element.create(): a proposal for more convenient element creation
On , Ian Hickson i...@hixie.ch wrote: On Mon, 1 Aug 2011, Ryosuke Niwa wrote: On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak m...@apple.com wrote: In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the following idea for convenient element creation: Element.create(tagName, attributeMap, children�) Can we alternatively extend document.createElement? Or was this intentionally avoided to associate new elements with documents? We could, but I'd much rather have the shorter name, personally. Having the name be so long really makes that API unusable. However, Nodes need a ownerDocument, and that needs to be supplied, even if optionally. Doing document.createElement implies the document, Element.create does not.
Re: Element.create(): a proposal for more convenient element creation
On , Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard ch...@jumis.com wrote:
Can we have it 'inherit' a parent namespace, and have chaining properties?
Element.create('div').create('svg').create('g').create('rect', {title: 'An svg
rectangle in an HTML div'});
Ooh, so .create is defined both on Element (defaults to HTML
namespace, just creates an element) and on Element.prototype (defaults
to namespace of the element, inserts as a child)? That's pretty
interesting. Presumably the new element gets inserted as a last child
of the parent.
I like it.
While the idea is interesting, create is a too simple name to add on
something as polluted as Element.
I wonder if there is enough demand for this kind of chained coding to actually
spec an API for this. I've rarely seen it being used, plus the notable
exception that is jquery code.
Perhaps createChild, would be better, but then one would need to differentiate
Elements from Text.
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote: Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. There are too many web apps with a Copy this to clipboard button, like dropbox. If a proxy clipboard is implemented, as I explained, then the privacy concerns are mostly handled.
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng dch...@chromium.org
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
getData and setData must work outside clipboard events, like when clicking
paste/copy/cut buttons on a toolbar. The clipboardData object needs to be
exposed on the window, like in IE.
To handle the getData case, I've thought of adding a proxy clipboard per
browsing context. Read operations read from the proxy clipboard, write
operations write to the proxy and system clipboards. User initiated actions
like dropping, or pasting would update the proxy clipboard with the system
clipboard contents, prior to the event being dispatched on the webpage.
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On , Paul Libbrecht p...@hoplahup.net wrote: Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml More generic - text/* (I've see in too many places mime-types like text/x-c-src, and text is text.) - application/*+xml - application/*script (ecmascript, javascript)
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 19 May 2011 09:11:56 +0900, João Eiras joao.ei...@gmail.com
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to access the clipboard contents. Or does execCommand
dispatch a synchronous event ? What if the event is prevented ? Does
execCommand return false ?
Re: clipboard events
On Tue, May 10, 2011 at 8:41 AM, timeless timel...@gmail.com wrote: I'm not really excited by the return of the attack on context menus. Allowing web sites to hold user's browsers hostage is a bad starting point. It might be ok if the user had to first opt into rich editing - maybe. Note that we only recently added protection for users against 'what you see is not what you copy' (serializers are now fairly css aware). Neither do I but it's a user agent issue to provide ways to override sites using this feature in a way that affects user negatively, because the feature and the use case is legitimate. Anyway, it would not introduce a new problem given that overriding clipboard contents is done already, although by a select few, using plugins, or if copy events are supported, after the copy event, using setData. So ignoring the use case just gives a false sense of security.
Re: clipboard events
I think you'd want to push the script-added data regardless of whether the event is canceled or not. Why would the script add the data otherwise? I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done.
Re: copy events and content from server
On , Paul Libbrecht p...@hoplahup.net wrote: Hello list, As noted in the thread about security started by Halvord: In many of the scenarios I have working for, the content to be put on the clipboard would come from a luxury knowledge structure on the server, one that has access to some semantic source and can infer useful representations out of it; these get put to the clipboard. An offline HTML would also be an example of it. but I am realizing that this is probably not possible to do because the only way to do obtain something from the server is to wait until a callback is called (and this is good so) at which time the copy event might be long gone already. Would it be thinkable to *lock* the copy event until either a timeout occurs or an unlock is called? This way the script in the client would be able to fetch rich transformations from the server. A synchronous XHR solves this use case and there are no magic locks.
Re: paste events and HTML support - interest in exposing a DOM tree?
On , Hallvord R. M. Steen hallv...@opera.com wrote:
Hi,
a question related to the evolving draft on
http://www.w3.org/TR/clipboard-apis/ (which actually is slightly better
styled on http://dev.w3.org/2006/webapi/clipops/clipops.html - I should
figure out why ;-))
We want to enable some sort of access to HTML code if the user pastes
formatted text from an application that places HTML on the clipboard.
However, the browser will have to implement some security restrictions
(see relevant section of the spec - though it's just a draft), and in some
cases process the HTML to deal with embedded data when there are sub-parts
on the clipboard.
To handle both security algorithms and any embedded data, the browser will
probably need to parse the HTML. So actually, when you call
event.clipboardData.getData('text/html') the browser will get HTML from
the clipboard, parse it, do any work required by security and data embeds
rules on the DOM, and then serialize the code (possibly after modifying
the DOM) to pass it on to the script. Of course the script will want to do
its own processing, which will probably at some point require parsing the
code again..
So, to make things more efficient - would it be interesting to expose the
DOM tree from the browser's internal parsing? For example, we could define
event.clipboardData.getDocumentFragment()
which would return a parsed and when applicable sanitized view of any
markup the implementation supports from the clipboard. Rich text editors
could now use normal DOM methods to dig through the contents and
remove/add cruft as they wish on the returned document fragment, before
doing an appendChild() and preventing the event's default action.
Thoughts?
This is already covered by doing x=createElement;x.innerHTML=foo;traverse x
Regarding simplifying the pasted html to remove stuff that could be malicious,
consider a rogue app that injects a script in the clipboard and expects the
user to hit paste on his bank site. There is little the user agent can do but
to provide quick and easy methods to sanatize this. There is already the
toStaticHTML API that IE implements.
I would suggest supporting and implementing it. Or even add a sister property
of innerHTML, innerStaticHTML which would not return scripts or event handlers
on reading, and would parse out those when setting.
API for matrix manipulation
Hi.
Given that a number of API are being developed that require complex
matricial calculations (transforms, device orientation, web gl), I
would suggest that perhaps an API with a big number of common
calculations could be made available ? And a proper way to represent
them. Perhaps, the best way to add this would be to extend the Math
object with things like.
Math.mAdd(m1, m2)
Math.mSub(m1, m2)
Math.mMult(m1, m2)
Math.mDiv(m1, m2)
Math.mInverse(m1)
Math.mGaussianReduce(m1)
Math.mRank(m1)
Math.mRank(m1)
Being the matrix an array like object like (could even be one of those
fast arrays like ArrayBuffer).
# {
# w: width,
# h: height,
# length: width * heigth
# 0: ...,
# 1: ...,
# 2: ...
# (...)
# }
Comments or is something already being worked on ?
Thank you.
Re: API for matrix manipulation
Comments or is something already being worked on ? There are already 2 such classes: SVGMatrix and CSSMatrix. The former is an affine transformation matrix (commonly misnamed a 2x3 matrix) and the latter is a 3D homogeneous transformation matrix (commonly correctly named a 4x4 matrix). Are those classes in their current implementations thread-safe ? Could a Web Worker easily do matrix calculations with them ? I would guess a basic physics engine in a worker would be a nice use case. And what about making something that is generic enough for both SVG and CSS, or even full blown algebra ? And then specify bindings of implicit conversions from those DOM classes into a basic ES matrix (if you would like to call it that) ?
Some additions to Web Workers
Hi. It seems Mozilla extended the interface WorkerUtils in their implementation with the atob/btoa functions. I find them quite useful in that context, and would also encourage adding escape, unescape, encodeURI, decodeURI, encodeURIComponent, decodeURIComponent and many of the other global functions in the DOM environment which don't have any specific bindings to the DOM itself or manipulate documents, as that was a concern due to globals that are internally used by the DOM in some browsers. Thank you.
Re: [DOMCore] fire and dispatch
On , Garrett Smith dhtmlkitc...@gmail.com wrote: On 2/25/11, Anne van Kesteren ann...@opera.com wrote: On Fri, 25 Feb 2011 04:05:44 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: OK. Why not expose a generic version of `fire` to the scripting environment? I do not know of any research (or have done any myself) as to how often such a feature might be useful for authors. While firing an event is currently a series of steps (using proposed optional arguments): var e = document.createEvent(Event) e.initEvent(test) dispatchEvent(e) ... it is not hugely complicated. (We could even make the argument to createEvent optional too and default it to Event.) I could imagine having something like EventTarget.fireEvent(name) but if you want to get a little beyond the basics you will remain stuck with creating the event yourself. Your example is simple. But some common cases of synth events are complicated. UI Events aren't so bad but MouseEvents and especially TouchEvents are a lot of work to synthesize. Most cases for synth events are for testing -- feature test or unit test. EventTarget.fireEvent(type[, options]); That's going into the Internet Explorer API.
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. That would be a hack in the implementation and a hack in the spec.
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote: The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. That would be a hack in the implementation and a hack in the spec. Why? And what are you suggesting instead? Don't have a solution, but expecting certain GC behavior on a specification is far from sane.
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
Unless by certain GC behavior mean I referred to # The only solution I can think of is to require (or recommend) that implementations run the garbage collector The GC is transparent and a spec cannot expect that it runs at specific times or demand it.
Re: Fullscreen API
On Tue, Feb 8, 2011 at 6:14 PM, Doug Schepers schep...@w3.org wrote: Hi, folks- (BCC public-webapps, public-html. Apologies for the cross-post) Various people in various groups (as well as the community at large) have been emphasizing the need for fullscreen functionality. In the SVG WG, we had discussed the ability to make the root element fullscreen (this was a request a few years ago), but I like the idea of making individual elements (including grouping elements) fullscreen instead. The Mozilla FullScreen API [1] looks like a good start on this, and WebKit has picked up on this as well. (...) [1] https://wiki.mozilla.org/Gecko:FullScreenAPI Without a reference spec and looking at the Mozilla spec, I have many comments. Detecting fullscreen is something that belong 100% to media queries. Opera for instance, applies the projection media when the web page is rendered fullscreen. So, the CSS stuff in the Mozilla spec should be replaced with proper media queries, and the fullscreenchange event replaced with media query events. There is also some work already done with the @viewport CSS rule proposed by Rune Lillesveen from Opera [1] which was based on Webkit's meta+viewport element support, which in tandem with its meta+apple-mobile-web-app-capable allows pages to go fullscreen. I would suggest keeping everything in CSS, therefore dropping the dependencies on overloading meta. [2] Regarding the web page requesting full screen access, I regard it as dangerous, disruptive and unnecessary. If element ought to be rendered fullscreen, they can be styled with position:fixed;top:0;left:0;width:100%;height:100%;z-index:1000. Then if the UA user wishes, he/she can toggle the browser to go fullscreen (F11 in any browser), else content just fits the viewport. Toggling fullscreen for inlines like images, video, canvas would work the same, although the user agent can provide the user more accessibility, like double clicking video to go fullscreen, as it already happens in any desktop media player. If this is acceptable, the same level of functionality is preserved, the user is not annoyed, no new APIs are needed to be specified, and the spoofing issues are minimized to irrelevance. So, to summarize, this is mostly work for CSS media queries, and its DOM bindings. [1] http://people.opera.com/rune/TR/css-viewport/ [2] http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
Re: Fullscreen API
On Tue, Feb 8, 2011 at 7:49 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Feb 9, 2011 at 7:53 AM, João Eiras joao.ei...@gmail.com wrote: Detecting fullscreen is something that belong 100% to media queries. Opera for instance, applies the projection media when the web page is rendered fullscreen. So, the CSS stuff in the Mozilla spec should be replaced with proper media queries, and the fullscreenchange event replaced with media query events. The :full-screen-document pseudo-class could be replaced with a media query, and that's probably a good idea. Thanks! The :full-screen pseudo-class cannot since it applies to the full-screen element, and media query state is per-document. That works just as fine if a class is used. Regarding the web page requesting full screen access, I regard it as dangerous, disruptive and unnecessary. If element ought to be rendered fullscreen, they can be styled with position:fixed;top:0;left:0;width:100%;height:100%;z-index:1000. Then if the UA user wishes, he/she can toggle the browser to go fullscreen (F11 in any browser), else content just fits the viewport. Like it or not (and I don't!), Web developers are used to having in-page fullscreen UI because Flash provides it, and users are used to finding it there. It's also generally more discoverable than F11 or whatever the browser UI is. So there does need to be a way for the page to request full-screen. Whether F11, double clicking, a context menu option, zooming or a gesture, are discoverable or not, it's a user agent UI issue, although a requestFullscreen() call could hint the UA that the webpage *suggests* going fullscreen, but then there is the spoofing/social engineering issue.
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
Howdy.
interface StorageInfo {
Should probably be QuotaInfo or even QuotaManager ? Storage can and
will be confused with Web Storage.
// storage type
const unsigned short TEMPORARY = 0;
const unsigned short PERSISTENT = 1;
Only two values seem not enough for me and I disagre with the
nomenclature. Would be betteer to have
LOCAL_STORAGE, SESSION_STORAGE, WEB_SQL_DBS, INDEXED_DB and so on. But
that would create artificial dependencies with the other specs, so it
would be better if type passed to the query and request functions to
just be an opaque string which would allow any offline storage spec to
refer to this one instead and specify a type of their own like
localStorage, sessionStorage, indexedDb.
// To query how much storage is available and currently in use.
void queryUsage(unsigned short storageType,
UsageCallback usageCallback);
Given that quota values are usually just preferences, hence
lightweight enough, this function should be sync for the sake of
simplicity.
General note: using bytes as measure is probably overkill. While I
doubt localStorage would even exceed a couple megabytes, making an
entire e-mail account available offline with indexedDb or web sql db
could easily climb to a couple GBs. Perhaps kilobytes is better ?
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
Should probably be QuotaInfo or even QuotaManager ? Storage can and will be confused with Web Storage. // storage type const unsigned short TEMPORARY = 0; const unsigned short PERSISTENT = 1; Only two values seem not enough for me and I disagre with the nomenclature. Would be betteer to have LOCAL_STORAGE, SESSION_STORAGE, WEB_SQL_DBS, INDEXED_DB and so on. But that would create artificial dependencies with the other specs, so it would be better if type passed to the query and request functions to just be an opaque string which would allow any offline storage spec to refer to this one instead and specify a type of their own like localStorage, sessionStorage, indexedDb. The point is that apps and users should be able to communicate about how much disk space should be used. Why would users care which API a web app is using for its storage? If google.com needs 10MB to store my email, why should I care whether it's in indexedDB, localStorage, or the FileSystem? Before storing X amount of data with an API, the code requests enough space for the storage area that API covers. That's how I understand the use case. Then it's up to the user agent to communicate that appropriately to the user, if applicable. APIs are web dev scope, not user scope, so storage areas need to be differentiated. I doubt that any browser ATM shares a single quota between all different storage types. Opera doesn't for instance. // To query how much storage is available and currently in use. void queryUsage(unsigned short storageType, UsageCallback usageCallback); Given that quota values are usually just preferences, hence lightweight enough, this function should be sync for the sake of simplicity. This doesn't request just the preference; it returns how much space is actually used. That might be an expensive operation, might require disk IO to fetch a value from an internal database, etc. Hum, right. But then my comment does apply to requestQuota no ? No need to ping data files to store a new value for the quota, which is usually just a pref.
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
Before storing X amount of data with an API, the code requests enough space for the storage area that API covers. That's how I understand the use case. Then it's up to the user agent to communicate that appropriately to the user, if applicable. Why would we need to have the app specify I want to store 5MB in indexedDB and 3MB in the FileSystem? The user won't care; at most, the user needs to know This app wants to use up 8MB of space. If the user doesn't care, why make the app make two requests? Because the user agent needs to differentiate which api will use each quota.
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
On , Shawn Wilsher sdwi...@mozilla.com wrote: On 2/3/2011 3:59 PM, João Eiras wrote: Because the user agent needs to differentiate which api will use each quota. But why does a user agent need to do that? It seems like that is adding unnecessary complication to the API. Or adding unnecessary complication to the implementation.
Re: [chromium-html5] LocalStorage inside Worker
Afaik, websql does not support blobs. If stored as strings, it does. sqlite treats TEXT as an opaque buffer.
Re: [chromium-html5] LocalStorage inside Worker
On Thursday 27 January 2011 20:39:50 you wrote:
On Thu, Jan 27, 2011 at 12:06 PM, Charles Pritchard
ch...@visc.usmailto:ch...@visc.us wrote:
FWIW: websql is mostly abandoned, though super handy on ios mobile devices.
It's been around for a while in everything other than FF and IE.
IndexedDB is live in Chrome, Firefox and the MS interop team released a
prototype for IE.
For the record, we haven't shipped it to stable yet, though we do have a
version in the dev channel. We're hoping to ship before long though (once we
get the API back up to date).
Moz and webkit both just implement IDB atop of their internal sqlite
processes. That is, thy create a simple websql schema.
For now, yes. It's actually pretty fast though!
On Thu, Jan 27, 2011 at 12:31 PM, João Eiras
joao-c-ei...@telecom.ptmailto:joao-c-ei...@telecom.pt wrote:
Afaik, websql does not support blobs.
If stored as strings, it does. sqlite treats TEXT as an opaque buffer.
Not all binary can be expressed at UTF16. Note that this is also a
limitation of LocalStorage as well.
UTF16 represents the character table user agents use when displaying a buffer
of text, because nothing prevents you from doing:
# localStorage.setItem('foobar', \0\xff\ufeff);
# alert(escape(localStorage.getItem('foobar')));
Works in Opera at least, including in web sql dbs.
Re: [chromium-html5] LocalStorage inside Worker
On , Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow jor...@chromium.org wrote:
public-webapps is probably the better place for this email
On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com wrote:
I know this has been discussed 1 year ago:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
I couldn't find the follow up, so I guess localStorage is still
inaccessible from Workers?
Yes.
I have one other option aside from what mentioned by Jeremy:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html
5: Why not make localStorage accessible from the Workers as read only ?
The use case is as following:
First, the user in the main window page (who has read/write access to
localStorage), dumps a big data to localStorage. Once all data has
been set, then the main page spawns Workers. These workers read the
data from localStorage, process it, and returns via message passing
(as they cannot alter the localStorage value).
What are the benefits?
1. No lock, no deadlock, no data race, fast, and efficient (see #2 below).
2. You only set the data once, read by many Worker threads (as opposed
to give the big data again and again from the main page to each of the
Workers via message).
3. It is very easy to use compared to using IndexedDB (i'm the big
proponent in localStorage).
Note: I was not following the discussion on the spec, and I don't know
if my proposal has been discussed before? or is too late to change
now?
I don't think it's too late or has had much discussion any time recently.
It's probably worth re-exploring.
Unfortunately this is not possible. Since localStorage is
synchronously accessed, if we allowed workers to access it that would
mean that we no longer have a shared-nothing-message-passing threading
model. Instead we'd have a shared memory threading model which would
require locks, mutexes, etc.
Making it readonly unfortunately doesn't help. Consider worker code like:
var x = 0;
if (localStorage.foo 10) {
x += localStorage.foo;
}
would you expect x ever being something other than 0 or 1?
Not different from two different tabs/windows running the same code. So the
same solution for that case would work for Workers.
Making the API async would make it more hard to use, which is, I believe, one
of the design goals of localStorage: to be simple.
If two consecutive reads of the same localStorage value can yield different
values, then that's something that developers have to cope with. If they do
code that is sensible to that issue, then they can take a snapshot of the
storage object, and apply it back later.
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
Both Firefox and Chrome offer users privacy features which will cause Web Storage to be non-persistent across browser restart. For example Firefox has a Never remember history option, and Chrome has a clear cookies and other data when I close my browser option. For an application developer, it would be helpful to know when such features have been enabled, so that the application can inform the user, assist in troubleshooting, or disable features that depend on persistent storage. Hi. Although I understand the reasoning, I strongly disagree with the request. When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. There should be no way for a webpage to sniff if private mode is enabled: an advertiser could block users because it wouldn't be able to set tracking cookies for instance, like many of those sites that say Enable cookies to continue, but in this case applied to Storage. Specifying that an API can change its behavior radically solely based on a user preference goes completely against the principle of interoperability: same code running everywhere unchanged. The last thing the user needs is the webpage breaking because there are unexpected exceptions being thrown. By mentioning private tabs, the same applies to other features that remove data. So, +1 to transparency.
Re: Structured clone in WebStorage
On , Darin Fisher da...@chromium.org wrote: I will also add that I think WebStorage (well LocalStorage) is terrible from a performance point of view because it is synchronous, and I'd be very happy if we could discourage its usage and give people more reasons to adopt a better API like IndexedDB. -Darin I don't understand how storing values in a hash map is performant terrible.
Re: A URL API
That would be different behavior than what Location and HTMLAnchorElement do; they unescape various componenents. Is the benefit worth the divergence? As a side note, an out-of-document HTMLAnchorElement already provides most of the functionality of this interface. Things it can't do: - Resolve a relative URL against no base at all (probably not very useful since the interface can only represent an absolute URL). - Resolve against an arbitrary base (maybe you could do it awkwardly using base tag tricks). - Read or write the lastPathComponent or origin without further parsing (should origin really be writable? That's kind of weird...) - Read search parameters conveniently without parsing. It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight. I idea too. I would rather extend Location to include these features, so they would be immediately available in links and the location object. And make Location into a constructor new Location(url, base)
Re: [DOMCore] Attr
Oh, another issue is what type the Node.attributes object should be.
It's currently a NamedNodeMap, but that won't work since those return
Nodes. We could either create AttrMap interface with the exact same
API, except that it returns Attrs instead of Nodes, or we can remove a
few of the functions.
I suggest we remove at least the mutating functions, leaving us with:
interface AttrMap {
Attr getNamedItem(in DOMString name);
Attr item(in unsigned long index);
readonly attribute unsigned long length;
Attr getNamedItemNS(in DOMString namespaceURI,
in DOMString localName);
};
Can't you reuse something like NamedMapAttr ?
Re: XBL2
Perhaps the spec should reference focusin/focusout instead of DOMFocusIn/DOMFocusOut ? http://dev.w3.org/2006/xbl2/Overview.html#the-focus-domfocusin-blur-and-domfocusou
Re: [XHR] Redirects
On , Anne van Kesteren ann...@opera.com wrote: On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras joao.ei...@gmail.com wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thank you. But there is one thing missing: the final url in case of a redirect chain. Currently that is not possible to guess for non xml requests or HEAD requests. My use case was about doing a HEAD and reading the Location header to know if was going to be redirected. Now I could set followRedirects to false and read it, but for cases where the redirection chain is followed, then new url is not available. Something like finalUrl which when readyState is = 1 it would have the value passed to open() and after, when the value is = 2 (headers received) it would have the value of the final url. Another issue that concerns me is redirect loops. The proposed API gives us know way to know that the application is following a redirect chain, which means that we have little way to know if the application is following an endless redirect chain. Following redirects is the default behavior, and user agents abort after N iterations regardless of whether it's XHR or a regular request. The new followRedirects feature is for opting into disabling it. If instead, we had an API for auditing redirects (perhaps an onredirect event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Quite an edge case, but setting followRedirects to false and then creating individual XHRs for each 302 response explicitly should work.
[XHR] Redirects
Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj.
Re: [XHR] Redirects
On , Anne van Kesteren ann...@opera.com wrote: On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras joao.ei...@gmail.com wrote: Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? Apart from document.responseXML.URL I do not think so. And I'm not sure if document.responseXML.URL is supposed to work. It might not be an xml file, hence resonseXML is not defined and that's no good. b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? We might add something like this at some point (probably by way of a followRedirects boolean) but so far the use cases have not been really strong so it has not been given much priority. In my specific case, I had an url to a media file which I needed to feed to a plugin. But the plugin did not handle redirects. So I needed to do a HEAD request, and check if it returned 302 and read the Location header. But due to the implicit redirecting handling, and no way to access the final url, that was impossible. So, two problems in one. Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill.
Re: XMLHttpRequest Priority Proposal
On Fri, 16 Apr 2010 07:00:56 +0100, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Apr 2010 01:13:46 +0900, Mike Belshe mbel...@google.com wrote: // Set the load priority for this request. void setPriority(unsigned short priority); Any reason this is not an attribute named priority? Other than that I wonder if we should maybe simply use string values to make it easier to extend this if we ever need to. How is it easier to extend ? Like, define an interval from, say, 1 to 10, 5 is normal, 10 is high then let the UA decide how to deal better with prioritization. Handling strings for such a simple use case is messy, and very different from all the other dom bindings that use integers already (e.g. nodeType, readyState).
Re: Extending CSSOM Views matchMedium with callback
On Tue, 11 May 2010 08:47:27 +0200, Anne van Kesteren ann...@opera.com wrote: On Mon, 10 May 2010 19:47:42 +0200, João Eiras jo...@opera.com wrote: Should be addEventListener(mediaChanged, listener, false); There is already an event model, and it would just require a new event type. A generic event is not a good idea in my opinion. The more media features we add the more often it will be dispatched. Authors may not anticipate that. Furthermore, dispatching a bunch of viewport resizing events when the author is only interested in orientation change would be waste. There was a misunderstanding on my part. My proposal, using addEventListener, is only for when media mode changes, like from screen to print. The other proposed API calls the listeners when a specific media query applies (which can include orientation and device width) and therefore not being quite implementable performantly. I would really like an event just for media change though, so we could deprecate onbeforeprint/onafterprint and therefore get a generic event that works for any media mode. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Extending CSSOM Views matchMedium with callback
On Mon, 10 May 2010 19:53:52 +0200, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Ola Joao, That would mean that the user would have to manually call all matchMedium queries the user is interested in to find out which one changed, without us being able to optimize this by not redoing the parsing of the queries etc. Hardly an issue given that media change is not a bottleneck neither frequent, but more like a developer feature, or a UI toggle in the user agent (change to print preview for instance). So, I really don't see the point in making an optimization like this, if you can actually call it that. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [IndexedDB] Granting storage quotas
On Tue, 13 Apr 2010 12:09:14 +0200, Mark Seaborn mseab...@chromium.org wrote: Is there any plan for involving the user in storage allocation decisions for IndexedDB? [1] For comparison, the WebStorage API [2] doesn't have any special support for the user to make allocation choices. My understanding is that browsers have a fixed storage limit per origin -- in Chromium, 5Mb per origin. The problem with this model is that it is both too permissive and too restrictive. Not really. The user agent can ask for quota from the user when the limit is being hit without the webpage even having to worry about it. Opera 10.50 does that.
Re: [web databases] SQLStatementErrorCallback
On Thu, 25 Mar 2010 01:39:42 +0100, Ian Hickson i...@hixie.ch wrote: For the record, when a callback defined in the IDL to return a boolean actually returns a non-boolean value, it is my understanding that WebIDL requires that ToBoolean() be applied to the return value. So returning nothing or undefined is equivalent to returning false. Oh, this is serious. Isn't this clarified in the WebIDL ? If not then it *must* be.
Re: [WebSQLDatabase] Adding a vacuum() call
On Wed, 17 Mar 2010 01:50:00 +0100, Dumitru Daniliuc d...@chromium.org wrote: shane, i was hoping you could clarify a few things about AUTO_VACUUM: Perhaps this is a bit out of scope of this mailing list ?
Re: [WebSQLDatabase] Adding a vacuum() call
On Fri, 12 Mar 2010 01:08:41 +0100, Dumitru Daniliuc d...@chromium.org
wrote:
joao,
it looks like we mostly agree on this feature, so i was wondering if we
could formally agree on a spec. here's what i propose:
1. name: vacuum. to the best of my knowledge, all current WebSQLDatabases
implementations use SQLite, and in SQLite the command is called VACUUM.
so
it seems to me that we might as well call the new function vacuum().
what do
you think?
I'm fine with it but...
2. spec: no need for an error callback.
interface Database {
// the methods and properties currently in the spec
void vacuum(in optional SQLVoidCallback successCallback);
};
3. what the call should do: the purpose of this call is to allow apps to
vacuum/compact/defragment/clean up their databases whenever they see
fit. a
call to vacuum() could take a considerable amount of time (especially on
larger or highly fragmented databases); therefore, it is not recommended
for
web apps to call this method during periods of high activity.
how to process a vacuum() call:
1. if the UA does not support this call (mobile browsers?), jump to
step
3.
2. queue up a task to vacuum/compact/defragment/clean up the database.
3. if the task succeeds, and a success callback is provided, queue up
a
task to invoke the success callback; in all other cases (the task
failed, or
no success callback was provided), do nothing: proceed to the next
task in
the queue.
does this seem acceptable? we (google engineers interested in this) feel
that UAs should either not implement the vacuum() call, or they should
respect it (rather than taking it as a hint). it is ok for UAs to keep
track
of things like system idleness or databases closing to do more vacuuming
that the apps asked for, if they want to. however, we feel that a
vacuum()
request by an app should not be postponed, simply because sometimes apps
know better than UAs when the best time to vacuum is (it might be nice to
give apps more information on how fragmented their databases are, but
that's
a separate discussion).
I unfortunately don't agree with this last sentence :) Web pages do not
have a way to know the level of fragmentation, and the last thing user
wants is a web page calling vacuum() before each transaction, *just to be
safe*, because of potential fragmentation.
But the API is good I think.
thanks,
dumi
Re: [WebSQLDatabase] Adding a vacuum() call
On Fri, 12 Mar 2010 04:07:21 +0100, Dumitru Daniliuc d...@chromium.org wrote: joao, if i understand correctly, you basically want to have an automated system implemented in the browser that decides when to vacuum databases (or at least make sure it doesn't happen too often). and the vacuum() calls would be just one of the parameters that the system takes into account. i think having such a system is fine, but doesn't need to be spec'ed. at the same time, i think it's worth having a spec'ed vacuum() call that gives the app some guarantees. in particular, i would like the completionCallback to be a signal that the database is in a good shape and ready for more work. so how about this: 1. if the UA doesn't support the vacuum() call, go to step 3. 2. queue up a task to vacuum the database. if the UA decides that vacuuming is not needed at this time, the vacuuming task scheduled in this step could be a no-op. 3. when the vacuuming task completes, queue up a task to invoke the completion callback, if one was specified. i think this spec should allow you to treat the vacuum() call as a hint, while also guaranteeing that: 1. the UA believes the database is in a good shape when the completion callback is called. 2. the completion callback is called as soon as UA believes the DB is in a good shape. what do you think? Looks better, and more flexible. I wonder if sqlite has a way to query the number of pages in the freelist ? Probably something like 10% of pages in the freelist would be a good threshold to allow a vacuum. thanks, dumi
Re: [WebSQLDatabase] Adding a vacuum() call
Looks better, and more flexible. I wonder if sqlite has a way to query the number of pages in the freelist ? Probably something like 10% of pages in the freelist would be a good threshold to allow a vacuum. Oh and btw, read only transactions should disallow vacuum, I think/hope :)
Re: [webstorage] deleting a database
Deleting all the data in the database (i.e. dropping all the tables) should be sufficient, no? There's nothing to store if you don't have any data in the database (in particular, there's no reason to store the version as far as I can tell -- you can just act as if the user deleted the database as soon as the database is empty). Well, I thought about that already, but that's an optimization that can be done by the user agent. Should a specification suggest low level optimizations ? Its also needed to delete views. Tables is not enough, and currently I'm not thinking of anything else. So developers need to be educated: drop all tables, drop all views. Would be much more simple to just delete the database explicitly, and should be straightforward for most implementations given that those also need to support their delete private data functionality.
Re: [webstorage] deleting a database
Would be much more simple to just delete the database explicitly
Yes, but is this something that will happen often enough to matter?
Unfortunately, that question has two answers. It should happen often, but
I doubt web developers will ever bother to clean up the data they don't
need :)
From my personal experience, it's good to do quick synchronous cleanup
during testing. An heuristic like delete database if data file is empty
would need to be implemented when the database is no longer in use by any
webpage, so the dom object is garbage-collected and the underlying
database deleted.
Still on the same topic, why not also allow database names to be listed
somewhere ? It fits really nicely the use case of developer tools with web
UIs. Something like
interface Window {
readonly DOMStringList databases;//or databaseNames
}
should be enough IMO.
Re: [webstorage] deleting a database
During testing you can do it manually (why would you do it from code?). Unit tests.
[webdatabase] Handling of the query arguments
Hi everyone. Neither the web database specification, nor the IDL, specify the fine grained handling that implementation must do of the several possible values that can be passed in the 2nd argument to executeSql, considering that those ecmascript values need to be handled by the SQL engine, and therefore converted into a database compatible value. The only reference to the arguments is the paragraph that tell that the arguments should be replaced, but I've already asked that paragraph language to be reviewed in http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1329.html Handling of ecmascript to database types could be done the following way: - numerical values would be converted to REAL - strings would be converted to TEXT, including the empty string - booleans would be converted to lowercase TEXT false or true - null and undefined would be handled as NULL - functions would be converted to TEXT Objects, which do not fit the primitive types about, can be handled in two ways. 1) The quick cheap way, which was already hinted, would be to convert them to string. However, that's not very helpful, if the object is a native type wrapper like: new String(aa); new Number(1); new Boolean(true) 2) We can define, in the Web IDL, how an object can be converted to a primitive type. Specifically, in an ecmascript binding we can do the following (note: returns means to stop the steps): - if object is null, return null - if object has a member function called valueOf, invoke valueOf in the context of object - if the returned value is a primitive type, return the value, - if object has a member function called toString, invoke toString in the context of object - if the returned value is a primitive type, return the value, - return Object.prototype.toString.call(object), so we get [object Class] The returned primitive type would then go through the ecmascript to database type steps above. However, the Web IDL need to be language agnostic, so I'll leave for the Web IDL maintainers to decide if this is of its scope and specifiable. There might need to be clarification on how to define what is a numerical value, a string, a boolean, null and undefined, and functions. We could say that a numerical value is just a number, but ideally, it should also include Number() instances, despite these could return non numerical values from their valueOf, but then we would go into the object-to-primitive steps. The complete, we need the specification to tell how to convert database types back into ecmascript object, but this is easier: - TEXT, and other text types are converted to DOMString - REAL and other number types are converted to double - NULL is converted to null - DATE/TIMESTAMP types should be converted to Date objects, if supported Thank you for your time. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [webdatabase] Handling of the query arguments
2) We can define, in the Web IDL, how an object can be converted to a primitive type. Specifically, in an ecmascript binding we can do the following (note: returns means to stop the steps): - if object is null, return null - if object has a member function called valueOf, invoke valueOf in the context of object - if the returned value is a primitive type, return the value, - if object has a member function called toString, invoke toString in the context of object - if the returned value is a primitive type, return the value, - return Object.prototype.toString.call(object), so we get [object Class] ECMAScript defines a ToPrimitive conversion (Section 9.1 of ECMA-262 5th edition). I think the right thing to do would be for some spec to point to those steps. Probably it has to be Web Database, because in many cases where a Web IDL method takes an any type, it's not appropriate to do ToPrimitive conversion. Indeed ! -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Touch and gestures events
We seem to come from different angles, and our objective may not the same as yours. This is not an official statement, but I could formulate our objective like this: How do I enable richer web applications in a touch-aware browser while still retaining the possibility to interact with existing (mouse-aware) web applications. We all agree to that, but we disagree how to get there. A touch events API would be something completely new that would have any kind of backwards compatibility with existing content, meaning, one would need to code for the new API and older ones, and would have touch device bias. This means duplicate effort for everybody: spec writers, implementors, web authors. The most important is the possibility to track multiple touches individually, and above I have been trying to communicate the problems in just adding that to the existing mouse events. Second, touch-specific parameters are missing. Such include the pressure and bounding box of the touch. But do we need a new API and event model for this ? Can't this be solved already in mouse events ? Can't mouse events have the streamId (which would reference a pointing device), a pressure attribute and the geometry of the pointing device ? Currently, the mouse events API only supports single pixel pointing devices, but adding finger support would just require for all the coordinate properties of the event object to be means, and have the geometry somewhere globally accessible. Again, we don't need a completely new API and events model for this. Third, an input device independent way to do basic manipulation (pan/scale/rotate) to objects. It is well possible to implement just raw touch events, and do the gesture recognition in JavaScript, but then the actual gestures would follow the web site style, instead of the style introduced by operating system, and if your input device doesn't support multi-touch, it simply doesn't work on web content, no matter how clever way to manipulate the objects you have on your device/OS. Pan is scrolling for which browsers already fire events. The behavior for the scroll event would need to change though, so it would be fired before the event, and be cancelable. Scale is the zooming feature which is also supported in many desktop browsers and mobile browsers, but lacks events. Rotation of the entire viewport is a UI feature, like when you tilt the device. These are all UI events, like focus and blur, and none of them are tied to gestures or mouse events. Therefore they should be completely separate from any kind of mouse event feature. Obviously, the scroll and zoom events would need a target which would be the element with focus, but then, element can gain focus not only by using some pointing device. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Touch and gestures events
Pan is scrolling for which browsers already fire events. The behavior for the scroll event would need to change though, so it would be fired before the event, and be cancelable. Well, scroll event indicates that something has been scrolled. So we shouldn't change its behavior. Pan is closer to wheel events. Probably changing the behaviour for scroll would not be the best idea. But then we could have a beforescroll event. Pan can easily be confused with scroll itself. Scale is the zooming feature which is also supported in many desktop browsers and mobile browsers, but lacks events. Rotation of the entire viewport is a UI feature, like when you tilt the device. These are all UI events, like focus and blur, and none of them are tied to gestures or mouse events. But web page should be able to capture zoom etc. For example Google maps might want to use it, if zooming happens above the map. So it is in a way related to mouse or whatever pointer. Yes, hence the part where I said UI events. Therefore they should be completely separate from any kind of mouse event feature. Obviously, the scroll and zoom events would need a target which would be the element with focus, Why the element with focus? Why not the element under cursor or something? (Similar to mouse wheel, which can be used to zoom, at least in Firefox) I'm not going to write a detailed spec in each reply, you understood the context :) The event needs a target.
Re: Touch and gestures events
I am aware that Apple has rotation and scaling. Must these necessarily be coupled to the input device (touch)? Could the rotation/scale be independent of that (much like a contextmenu event is independent of the input device or method that that device triggers it (recall old mac IE, where click-hold caused a context menu to appear). Is it possible to, as RIM does, map mouse events to touch events? If so, I would like to propose that if finger movements are mapped to scroll the document, that this is mapped to the default action for a mousemove event. For example:- I've outlined this my previous email. Example: if you press, drag and lift your finger, you produce a set of events. If you get panning, a text selection, or a drag drop action, that just the default action of that gesture that the user agent implements regarding its use cases and target devices. Gestures themselves are not what should be specified, because gestures are like keyboard shortcuts, there are almost infinite possibilities. What you want are the UI events for panning and zooming, and other UI actions that might be triggered by gestures. Those events should indeed be supported, just like focus blur for instance, but completely decoupled from a touch screen device, because those can be triggered by other means. For instance, desktop browsers allow you to scroll a document obviously, and that scroll event can be extended to the panning action one gets on mobile browsers, because panning and scrolling are the same thing. Many popular desktop browsers also support full page zooming but I doubt they fire events when the user chooses a different zoom level. Opera for desktop has always had mouse gestures, and there are many Firefox extensions that add gestures support. Safari on Mac OSX 10.6 also support gestures I think. So, all these features should not be bound in any way to touch devices alone.
Re: Touch and gestures events
Hi, I suppose that the interest Olli mentioned was ours (Nokia). Unfortunately there was a long delay before we were able to participate the discussion and release our implementation, but yes, we have previously discussed touch events with Olli. We would be interested in participating standardization of touch and gesture events. Hi. My personal opinion is that such API is an extremely bad idea. First, it's semantically biased towards devices with a touch input device, therefore not applicable to other devices with many mice or joystick peripherals. Differentiating too much between different input devices has shown that it's very bad for cross device compatibility and accessibility. Look for instance what happens if you have a button with an onclick event handler and use the keyboard instead to press it, or if you have a textarea with a keypress event handler and use an IME. Second, it's a reinvention of the wheel. Most of the stuff covered in such API is already available in the mouse events model. touchdown, touchmove, touchup, touchover, touchout are just duplications of the corresponding mouse events. Thirdly, to solve the gaps the current mouse events API has, we can easily extend it while remaining backwards compatible. The MouseEvent object can be overloaded with the extra properties that would be found on touch events, like streamId, pressure and so on. As a side note, the API lacks an event for variations in pressure while the finger does not move. Forth, someone hinted at the possible violation of a patent. Regardless of it being applicable or not, it might be necessary to workaround it. Fifth, gesture themselves are not touch, or mouse events. Gestures are complex input events, comparable to what you get with keyboard shortcuts on a keyboard. In a keyboard, you can press any set of keys consecutively, or sequentially to trigger a keyboard shortcut. With gesture events one would move the pointing device, being it a mouse, finger, or whatever, following a specific path, like a line from left to right, a circle, or the letter M. Therefore trying to specify something that has infinite amounts of combinations is an extreme undertaking. Eventually, gestures will most likely be implemented using libraries anyway. The API first needs to solve the low level matters, which are singular events for multiple pointing devices. Sixth, the tap on two spots without intermediate mousemoves is not an issue. This already happens on desktop computers if you tab back and forth to a webpage and in between you change the mouse position. Also, taping in two spots, can just be considered as a mousemove with a bigger delta. This limitation of touch input devices, is something that needs to be solved on the implementation level in a way that can be mapped to the mouse events API. The problems touch enable devices face currently, is not about a lack of an API that detects the finger moving around, but about webpages that are biased towards mouse users and expect mousemove/over/out events to happen, which means they lack much of the accessibility they should have for users with other input devices, like a keyboard. If they relied on mousedown/up alone, or click, they would be much more foul-proof. To conclude: we should be focusing on extending the mouse events API to provide the information that is lacking currently. This puts much less burden on spec writers, implementors, and web developers. Cheers. PS: this is my personal opinion, not an official Opera position. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
[webdatabase] wording on Parsing and processing SQL statements section
Hi. In section 4.2 Parsing and processing SQL statements, point 2 starts as Replace each ? placeholder but then says later Note: Substitutions for ? placeholders are done at the literal level, not as string concatenations. By using the word replace, that execution step may cause confusion, as I've seen, about people thinking it might be related to some sort of concatenation, although the specification clearly clarifies that's not the intended result. I would reword step 2 and the clarification as: Bind each ? placeholder with the value of the argument in the arguments array with the same position. (So the first ? placeholder is bound the first value in the arguments array, and generally the nth ? placeholder gets bound by the nth value in the arguments array.) By binding, the result of the query must be the same as if the arguments had been literally replaced on the sql string, although this later practice is not recommended because it may risk SQL injection attacks. Using Bind for Replace makes it much more clear. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
[web databases] changeVersion error reporting
Hi! Database.changeVersion expects oldVersion and newVersion arguments. The Database also specifies a version attribute. The transaction steps tell to fail the transaction due to the failed preflight condition if oldVersion does not match the current database version. Meanwhile, the callbacks have been made optional, and rightly so. So: - if the author does not use the callbacks, there no error reporting that the preflight condition failed - the version check can be done synchronously when changeVersion is called because the Database object has immediate access to that value, and it's much more convenient for the author to just get an exception (like INVALID_STATE_ERR) than to have to go through the entire callback process just to realize later that the transaction failed due to the mismatched version. It also spares the user agent from creating and executing a transaction that WILL fail. To solve these issues, I would suggest doing immediate synchronous validation of the version when changeVersion is called, throwing an exception on error, and drop that step from the preflight operations. Thank you.
Re: [web databases] changeVersion error reporting
So that was one of the motives to add the creation callback on openDatabase I presume. In either case, before the script gets a Database object, a version check needs to be made during openDatabase, so the value can be cached inside the Database object, to be used for changeVersion, the version property and subsequent transactions. On Fri, 04 Sep 2009 03:06:37 +0200, Michael Nordman micha...@google.com wrote: If the version is stored in the database file itself, as is with webkit's impl for example, the database object does not have immediate access to that value. On Thu, Sep 3, 2009 at 5:57 PM, João Eiras jo...@opera.com wrote: Hi! Database.changeVersion expects oldVersion and newVersion arguments. The Database also specifies a version attribute. The transaction steps tell to fail the transaction due to the failed preflight condition if oldVersion does not match the current database version. Meanwhile, the callbacks have been made optional, and rightly so. So: - if the author does not use the callbacks, there no error reporting that the preflight condition failed - the version check can be done synchronously when changeVersion is called because the Database object has immediate access to that value, and it's much more convenient for the author to just get an exception (like INVALID_STATE_ERR) than to have to go through the entire callback process just to realize later that the transaction failed due to the mismatched version. It also spares the user agent from creating and executing a transaction that WILL fail. To solve these issues, I would suggest doing immediate synchronous validation of the version when changeVersion is called, throwing an exception on error, and drop that step from the preflight operations. Thank you.
[web databases] about rowids
Hi everyone. 1) Currently, SqlResultSet.insertId is defined as a integer. This would prevent user agents to use an underlying database engine that does not rely on integers for rowids. For instance, both SQLite, MS Access, Informix use integers it seems, DB2 uses a transparent type 17 bytes big, Oracle uses strings, Java JDBC uses byte[]. For the sake of compatibility, it would probably be better to make insertId either a string, or in the case of lack of agreement, a implementation defined type, which is not desirable. 2) insertId only stores one row id. That's not very helpful for the case of a INSERT INTO table(...) SELECT ... dml. Considering that the query could produce an arbitrary number of rowids, the insertId field should probably be a SqlResultSetRowList, or an array. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Web Storage how to check for support?
How can one in a script check for UA support?
else if(localStorage){}
does not work for Opera**.
Hi.
This obviously does not work because you need to prefix localStorage with window
if(window.localStorage) else the script breaks because localStorage is a
undefined identifier while window.localStorage looks up a property in the window.
Different things, specific to ecmascript itself.
Re: Is localStorage read and write-able offlne?
Everything in file:// is the same origin. I think Mozilla has been experimenting with changing this, but I can't remember how they handle localStorage (if it's even different at all). No. Everything on file:// has the origin defined by the origin serialization algorithm. http://dev.w3.org/html5/spec/Overview.html#origin The spec tells If scheme is file, then the user agent may return a UA-specific value. In Opera's case we use file://machine/ where machine can be localhost, an ip, or a remote computer with a shared folder. If you're on a local network which cannot be fully trusted, accessing a page at file://peer/ that manages to access your local harddrive is as serious as a cross-domain attack, or even more. So saying that everything on file has origin file:// is a misconception of the problem origin tries to solve.
[webdatabase] SQLError codes
Hi.
The IDL for SQLError defines a code property with the values described at
http://dev.w3.org/html5/webdatabase/#errors-and-exceptions
Currently, the table with those values only has numbers (error codes) and
textual descriptionss.
It would be nice if those errors were enumerated in the SQLError interface, and
be given a persistent name, like with DOMException.
interface SQLError {
readonly attribute unsigned long code;
readonly attribute DOMString message;
static const unsigned long TRANSACTION_FAILED = 0;
static const unsigned long DATABASE_ERROR = 1;
};
Thank you.
About initStorageEvent and initStorageEventNS
Hi. The interface for StorageEvent defines initStorageEvent() and initStorageEventNS(). For these functions to be of any use, there must be a way to create new event objects, and that way is using document.createEvent. However, there is no reference to document.createEvent in the entire webstorage spec. Should document.createEvent be extended ? Thanks. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
[webstorage] deleting a database
Hi! The webstorage specification needs an API to delete a database, because there's no such way to do it currently. Something like deleteDatabase(name) would be good. And after calling it, all open transactions would be marked as invalid. The user agent could then delete the data on disk and do all the necessary clean up. Thank you. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Mutation events replacement
These are *not* DOM-Event listeners. No DOM Events are created, there are no capture phases or bubbling phases. Instead you register a listener on the node you are interested in being notified about, and will get a call after a mutation takes place. The listeners are called as follows: I find this behavior limiting in some regards and makes mutation events less useful. You specify some functions which add listeners for sub tree modifications though. Why not keeping the DOM events model for sub tree modification cases, and optimize single node mutation listeners with the API you propose? Another possible way would be to extend DOM events to tell that one only wants a listener for the AT_TARGET phase. Currently, if the 3rd parameter is true then it's capturing phase, else if it's false it's at_target and bubbling. Why not extend this argument with another possible value, or overloading the function with an enumeration on the 3rd parameter ? 'AttributeChanged': Called when an attribute on the node is changed. This can be either a attribute addition, removal, or change in value. If setAttribute is called the 'AttributeChanged' listener is always called, even if the attribute is given the same value as it already had. This is because it may be expensive to compare if the old and new value was the same, if the value is internally stored in a parsed form. The overhead of comparing the previous with the new value inside the engine is a fragment of the overhead of calling an ecmascript callback and doing the same comparison in ecmascript. Doing so will also prevent the callback from being called way too many times. So I think it should only be called when the value actually changes. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [DOM3Events] Use cases for Mutation Events
Other thoughts: 1) If I am the author to the scripts that modify document, then I am indeed aware of what gets changed. If I am not the author, I shall then not have been notified on the change. The use cases such as debugger do not count here - it would be possible to offer required APIs (such as DOM Mutation Events) to them only, without needing the API to populate on the page. And this is not a sucrifice to run page 50% slower caused by the Mutation Events turned on on behalf of a debugger, right? Use cases: - user triggered input, like when using contentEditable/designMode - 3rd party libraries which want to know if the document mutates out of their context - 3rd party scripts (like ad scripts, or link to social networking or sharing sites) that change the document and the document wants to keep some sanity in it -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [DOM3Events] Use cases for Mutation Events
Use cases: - user triggered input, like when using contentEditable/designMode We should fix this by adding better events for user input into contentEditable/designMode. Using mutation events for this is both unnecessarily hard to use (I'd imagine), as well as unperformant (for sure). I agree 100% that we need better events for user input in this regard, but we don't have them currently and Gecko and Webkit dispatch mutation events for user input on editable documents, and I know of a few high profile project that use them (although I can't disclose which). Can you explain these more in detail? Whether there are libraries that use them or not, I honestly can't tell. However there are scenarios where 3rd party libraries like jQuery or prototype might require to know if the document has mutated to update their internal data structures. For the 3rd party scripts, it's quite common for sites to deploy 3rd party scripts that embed links to social networking sites, bookmarking services, embedding ads, embedding videos, etc. If somehow the script breaks the main page's tree, a mutation event could help, although in these cases, probably the load events would be good enough.
Re: WebStorage feedback
How is this different from making two mutations per mutation event, or calling postMessage() twice for each invokation of the 'message' event, or loading two new iframes every time an iframe's 'load' event fires? It's quite different because in those cases, the events or actions are all limited to one single runtime, which means all these actions are queued. A sane user agent can share a part of its cpu time between all the active runtimes, and keeping the other documents usable while one fork bombs itself with events, being the leftover problem the amount of memory needed. With storage events, the user agent must send events to unrelated runtimes, which can escalate immensely, therefore filling all the other runtimes' event queues with the superfluous events. If the user agent has no protection against this, then the user will be forced to close the whole browser, and not just the webpage that is misbehaving.
Re: [DOML3Events] ACTION-267 Proposal for event iterator
On Tue, 28 Apr 2009 21:57:10 +0200, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 28, 2009 at 12:50 PM, Travis Leithead travis.leith...@microsoft.com wrote: I think this was dropped because it would allow general web apps to inspect (and remove?) event handlers that were registered by code running in extensions or by the browser itself. In general, this is a great idea for debugging or extensions, but not so great in web app deployment scenarios. Folks can feel free to correct me if I'm way off base. That is the initial problem that we in firefox would have with this. The other problem is a lack of use cases. All the ones I have heard so far has been to implement various aspects of accessibility technology. However this can be done using internal interfaces in the UA. No need to expose anything to web pages. / Jonas Also, this would obviously conflict with client side user scripts which I would not like to see :), because then a webpage would clear all the local script listeners, while it should really be the user to say how the site should behave ultimatelly.
Re: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]
On , Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations] http://www.w3.org/2008/webapps/track/issues/85 Raised by: Charles McCathieNevile On product: Clipboard Operations What are the common security restrictions and considerations that should be listed in the clipboard apis spec? I have thought thoroughly about this issue. There are the following bad use cases, that I can remember currently: - the user wants to copy/paste content from a webpage but the webpage is constantly setting the text on the clipboard as empty. Unfortunately, this already happens with pages using 3rd party plugins. - a webpage that silently sniffs the clipboard to try to find sensitive data, like something that could resemble an email or a credit card number. When I refer to system clipboard, I mean the clipboard that's shared between all applications and the user agent. To cope with these cases I thought of having 3 levels of security regarding clipboard access: - no access - webpage cannot set nor get data from clipboard. This fixes most malicious use cases. - write-only access - webpage can write to system clipboard but can't read from it. Incidentally, the UA should store a secondary clipboard to which data is written and read freely by the webpage, but only write operations pass on to the system clipboard. This is good enough for applications that preprocess data and store it in the clipboard, while still giving the user full privacy over his system clipboard. - full-access - webpage has full access to system clipboard. I don't think that the read-only case is feasible. If the user does not trust a page to write data, much less will he/she trust it to read. It would be up to user agents to actually provide an UI to allow users to control this. Cheers.
Re: [selectors-api] Names of querySelector() and querySelectorAll() methods
Search the archives. There were long debates about naming. In the end, the ones you see where choosen. On , Gavin Kistner [EMAIL PROTECTED] wrote: On Nov 18, 2008, at 9:32 PM, Gavin Kistner wrote: I find these names rather cumbersome and not very self-explanatory. Though it may be far too late for this suggestion, I would suggest that they should be something such as: findNode()/findNodes() or findNode()/findAllNodes() selectNode()/selectNodes() or selectNode()/selectAllNodes() findBySelector()/findAllBySelector() Er, please replace all instances of Node with Element in the above. Dunno what I was smoking. And 2 more: elementFromSelector()/elementsFromSelector()
Re: [selectors-api] Investigating NSResolver Alternatives
Unfortunately I don't think we can change how XPath parses things since there is already code out there that might rely on the current behavior. Might be worth looking into though. I don't want to worry about xpath, although that misfeautre bite me hard :) Chaging the behavior how I suggested would be harmless because currently, the use cases I wanted to fix either had the behavior unspecified or exceptions were expected to be thrown. My concearn currently is with the selectors-api. I don't want to see the same errors repeated. Bye.
Re: [selectors-api] Investigating NSResolver Alternatives
Hi ! I vote for having a new light weight object to completely replace the current NSResolver, and then apply it to other DOM specs namely the XPath DOM. I had some of the problems we're discussing with the XPath DOM API, and obviously the same apply here. I exposed my problems at the dom mailing list, but my comments were dismissed completely http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html The problems I outlineed with NSResolver are summarized to the following: - a element with no prefix is assumed to be in the namespace with null uri. You can't change this behavior. - a element with a prefix MUST be in a namespace with non null namespace uri, else returning empty string from lookupNamespaceURI results in NAMESPACE_ERR being thrown I proposed the following changes: - a element with no prefix would result in lookupNamespaceURI being called with the empty string, and the resolver could return a default namespace, or return null (or empty string) to imply the null namespace - a element with prefix would result in lookupNamespaceURI being called with the prefix and the function could either return null (or empty string) to imply the null namespace, or it could return a fully qualified uri. These changes fitted well with the specification because these cases were either undefined or expected implementations to simply throw exceptions. I ask you not to make the same mistakes that were done with the xpath dom api, because nsresolver currently is fairly broken, and not that much useful. Again, I vote for a new lightweight object, and to allow mixing both elements with or without prefixies with null or non null namespace uris. Thank you.
Re: Element Traversal comment
Hi ! Since most people agree that these features would be useful, and because you have a deadline, you can leave it for a 1.1 version. I think the issue is not whether is useful or not, but rather specifiying the details. I have no problem with waiting (as long as it's not that much :) ). And currently I have no other comment on the specification, so its fine by me. Good job. Bye. On , Doug Schepers [EMAIL PROTECTED] wrote: Hi, João- João Eiras wrote (on 7/29/08 7:10 PM): The Element Traversal WD define childElementCount on the Element interface. Personally I see little use for such property by itself. It would make much more sense to have childElements (similar to childNodes on Node), and therefore we could use childElements.length to get the same value as childElementCount. childElements would also be a live NodeList. Most use cases for Element only transversal require looping NodeLists, and if the author still has to filter nodes from these NodeLists by their nodeType, then that beats the entire purpouse of this specification. Thanks for your comment. Last Call for this specification is over, but I appreciate your review nonetheless. This issue has been discussed at great length (see this thread [1], among others), and a resolution has been reached. Justification for the childElementCount attribute, including a concrete use case, in included in the specification, and the attribute has already been implemented in multiple user agents. While many uses of Element Traversal do not require this attribute, I speak from personal developer experience when I confirm that it is useful. So, no change to the specification will be made at this late stage. [1] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0226.html Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Re: [selectors-api] What DOM feature Selectors API belongs to?
Is there really any demand from implementers of other languages to have a feature sting defined for hasFeature()? Is there any evidence that people make use of existing feature strings in their programs, using any implementation? You provide a feature, then others use it, not the other way around. Ecmascript (javascript) programmers go directly for object detection because it's simpler. Still, the entire DOM spec has Java bindings, and one never knows, but in the future we can have other programming languages with DOM bindings, which can be used either in a browser or another kind of program that renders html/xml. Supporting hasFeature is about being forwards compatible. Else you're locking the Selectors API only to bindings that support object detection. (...)
