Adding another well-known location may cause (yet another) 404 error for
sites lacking this file, similar to favicon.ico. Plus it takes up URL
space.
I suggest that if such a file is used, it should not be in a well-known
location but a site specific location that can be specified by an HTTP
On Tue, Aug 7, 2012 at 8:36 PM, Alec Flett alecfl...@google.com wrote:
FWIW it's fairly hard to for a database to index arbitrary content for
regexes, to the point where it's going to be hard to do MUCH better than
simply filtering based on regex.
Perhaps it shouldn't be a full-text *index*
I think we need to realize that a lot of the APIs that have been
designed in the past aren't terribly good APIs.
The IndexedDB API is rather new, and the manner in which it consistently
uses event handlers on returned objects is rather innovative. The
DOMTransaction object is more similar to
'this' would be the object, not window when callback object is used.
I was talking about what Ojan wrote:
I was specifically talking about WebIDL Dictionaries. In which case,
this.undo would set the undo property on the window. Why would you want to
be able to set the undo function from the
Passing in objects containing one or more non-callback properties is also
an increaingly common pattern, and we are trying to replace legacy APIs
that took lots of positional arguments with options-object based
replacements (e.g. init*Event). From the point of view of a javascript
author
To sum up, as an author I vote for--
var t = undoManager.transact(foo);
t.onundo = function() { ... };
OR t.setUndo(function() { });
How do you envision it should work with an automatic transaction?
We need some mechanism to tell the UA record DOM mutations while I'm
calling
t = undoManager.transact(foobar, function() { ... });
t.onredo = function() { /* custom redo */ };
t.execute();
Whether onundo/onredo are assigned upon execute() is well defined, so
basing behavior on that is clear enough for me. Plus, I wonder - what is a
non-automatic transaction
I totally misread the purpose of templates beforehand -- template/s act
more like a mixin rather than a fill-in. It also reflects in what Tab wrote
that it's still vague how the two notions - that of text templates and that
of mixins for building components - are to be mixed together, if at all.
feature of templating systems and needs to be well supported.
On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
Why don't we just use script elements for that then?
On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com
wrote:
You musn't forget what we're
You musn't forget what we're not planning for. Templates can be great for
so many applications - generating code (JSON, Javascript), generating
plain-text or otherwise formatted (markdown, restructured text, etc.)
content and much more. I don't think templates should be parsed by DOM
unless
Hey. Here are some suggestions I accumulated while working with IDB.
I'd be very happy to expand on each and specify the specific changes,
if you think they are worthy to work on.
feature: IDBKeyRange should also allow a list of non-sequential keys
- *feature*: IDBKeyRange should also allow a
11 matches
Mail list logo
