Re: Pre-fetch rough draft
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 header and/or meta/ tags. On Tue, Oct 30, 2012 at 11:22 AM, Charles McCathieNevile cha...@myopera.com wrote: Hi, I mentioned this and it's somethign we are working on. Basic idea: site provides list of resources that it uses and can be cached for general improvements on the whole site. (We're seeing load-time improvement from 50% - 300% in our testing. We are using it on sites - mail.yandex.ru/prefetch.txt has an example). The draft spec here is still very rough, but it shows what we've implemented and some of what we think it is good for. This is meant as input to the appcache/packaging/etc discussion, and may or may not be something this group takes on. cheers -- Charles McCathie Nevile - private mail account
Re: IndexedDB and RegEx search
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* but simply a search feature.
Though I'm unfamiliar with specific implementations, I gather that
filtering records in native code would save (possibly lots of) redundant JS
object construction (time and memory = money :)), and doing so with a
pre-compiled regex might improve over certain JS implementation or
non-optimizable practices, e.g.
function search(field, s) {
someCallToIndexedDb(function filter(record) {
var re = new RegExp(s);
return !re.test(record[field]);
}
}
Plus it saves some code jumbling for a rather common practice.
Re: [UndoManager] Re-introduce DOMTransaction interface?
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 that.
In other words, I think it's more important to focus on what makes a
good API, than what is consistent with other DOM APIs.
Consistency has its value. Even if some is lacking, fixing it in some
places and not in others might cause a jumble. Which is my feeling actually
about the IndexedDB API. Adding more syntactical variations can lead to
hectic code.
However, I agree that it's not the primary concern.
Something that I really liked about the old API was the fact that
using it created very intuitive code. Basically you just write a class
the way you normally would write a class, and then pass in your
object:
x = {
someState: 0,
apply: function() { this.someState++; this.modifyDOM(); },
unapply: function() { this.subState--; this.modifyDOMOtherWay(); },
...
};
undoManager.transact(x);
You can even do things like
undoManager.transact(createParagraphTransaction(params));
How's that different from:
function createParagrahTransaction(params) {
x = new DOMTransaction(Create paragraph);
x.apply = function() { ... use params... };
x.onundo = function() { ... use params ... };
return x;
}
Also, in your example, I think that in the JS-object proposal you won't be
able to reference the original object's properties -- it will be lost, and
'this' is window.
The fact that we have to choose between creating APIs that feel like
DOM APIs or JS APIs I think is an indication that DOM APIs are
doing things wrong. There should be no difference between DOM APIs
and JS APIs.
It is a problem. But WebIDL and JS aren't two of the same.
Re: [UndoManager] Re-introduce DOMTransaction interface?
'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 execut function? My whole point has been that we should not keep the actual object. on which, by the way, I also have to say: one of the nice things about the web is that the most interesting things sprout out of things being used out of context and beyond their purpose (am I quoting Einstein when I say that a problem cannot be solved using the same terms that were used to define it?). In this specific case, access to the object allows for context in the execute() call. This supports the notion, which you may discard of, of a module for actions that is separate from the UndoManager. Re using actions for several times, intuitively, an UndoManager can either throw an exception when an action is performed twice, or --the more elegant approach imo-- let an action be executed multiple times, and whatever would have applied to the single action (undo/redo behaviour) applies to each transaction. And if the author chooses to meddle with the undo/redo behaviour after execution, it's her responsibility. What applies to the operation is what is defined at the time the undo/redo occurs. Keep it simple. Yuval
Re: [UndoManager] Re-introduce DOMTransaction interface?
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 there is no difference between something like {foo:true} and
{foo:function(){}}. Insisting that there should be a difference in DOM APIs
because of low-level implementation concerns is doing a disservice to web
authors by increasing the impedence mismatch between the DOM and javascript.
I read the conversation but still feel I'm stepping into other people's
business; I'll still pitch in my author point-of-view:
A. Are there any other APIs where a JS object representing an atomic piece
of data is passed as an interface-less object to a DOM function? I don't
think this includes options-objects, which are meant to, imo, alleviate the
pain of optional arguments.
It seems helper functions with position-based arguments are more common:
addEventListener, createElement, createObjectURL, and more notably
pushState/replaceState (in history, which also have to do with saving
atomic records, and historical ones to that).
B. On the other hand, are there APIs where objects with interfaces are
created explicitly using the interface name?
Sifting through the webapps docs, I found several sporadic examples of
DOM-defined objects which are explicitly instantiated:
- Image, Audio, Option,
- MediaController, TextTrackCue,
- DrawingStyle, Path,
- Worker, SharedWorker, MessageChannel, XMLHttpRequest, EventSource,
WebSocket.
Of these, the closest semantic relative is TextTrackCue, and it uses
positional syntax similar to what was suggested.
Also worth mentioning is IndexedDB which is loaded with new interfaces, but
not one is instantiated by authors (might be very well be wrong, just
afaik).
To sum up, as an author I vote for--
var t = undoManager.transact(foo);
t.onundo = function() { ... };
OR t.setUndo(function() { });
Re: [UndoManager] Re-introduce DOMTransaction interface?
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 this function.
My preliminary thought is that transactions should be automatic unless
otherwise stated. Following that rationale, perhaps
var t;
// performs automatic transaction, no undo or redo needs specifying
t = undoManager.transact(foo, function() { ... });
t.execute();
t = undoManager.transact(bar, function() { ... });
t.onundo = function() { /* custom undo */ };
t.execute();
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 without an undo? A freak?
Some more ideas -- besides the other more verbose solutions (having
executeAutomatic(), a special property e.g. isAutomatic), you might extend
the vocabulary of UndoManager: either offer an additional argument for
transact (e.g. transact(foo, function() { ... }, true) ), or better imho,
have transact() specify a custom transaction and introduce record() (just
to avoid autoTransact()) which will specify an automatic transaction, thus
having:
t = undoManager.transact(lala, function() { });
t.execute(); // error, transact() with no undo()
t = undoManager.record(baba, function() {});
t.onundo = function() { }; // will be ignored/error thrown, since we're on
record()
t.execute();
Re: [UndoManager] Re-introduce DOMTransaction interface?
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 without an undo? A freak?
Also, the interface you proposed behaves somewhat oddly when the undo
manager from which the transaction was created is disconnected since
execute() will fail in such a case.
What I find appealing in this example is that the transaction is an
operation which is indeed disconnected from the UndoManager. Perhaps I'm
missing something here, but what do we gain by having UndoManager being the
place of both creation and execution of the DOMTransaction object? If I may
take the notion further, it might as well originate elsewhere, and connect
to an UndoManager only on execute(), e.g.
t = document.transaction(foo, function() { }); // or new
DOMTransaction(), actually
t.onundo = function() { };
undoManager.execute(t);
I realize as I'm writing that this is a hybrid suggestion between new
DOMTransaction() and the event handler version. It gives reason for
introduction of the DOMTransaction() standalone instantiation.
Perhaps I'm going to far. It just seems logical.
It encapsulates the action as well as the reverse action. I find this to be
explicit and simple enough to write without confusion. Every idea is
specified once and in a clear place - (a) what to do, (b) how to undo and
(c) execute. More specific than this would be verbose imho.
Another approach will be to make the second argument optional and treat
all transactions created without a callback function as manual transactions
since there's no need for manual transaction's execute to be a callback.
I fear that changing placement of the execute function in different
circumstances will cause confusion and that it is indeed too implicit.
Re: [webcomponents] HTML Parsing and the template element
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. Re the use as mixins - template/s put together two different ideas. On on hand, it looks like a content-generating/replicating scheme, such as a CSS content:, or the proprietary CSS -moz-element:[3] properties. In that sense, template/ seems to take these a step further. From the spec[1]: One reason for creating a document fragment is to clone it multiple times to create repeating items that vary in some content, but have common basic structure of across all instances. I see the content as being the DOM, and the common basic structure as the functional *design* around it. If repeated data was to be a semantic part of content, I would imagine it would have been incorporated in the tree. On the other hand, it seems template/s are trying to answer the same need as XML: giving an alternative for semantic structuring of the document without loosing the ability to add functionality. Again from the spec: something that allows developers declare arbitrary DOM subtrees *in* the document markup. I realized as I'm writing this that template/s come from XBL so I shouldn't be surprised. So I think these points still need some thought: - should functional design detail be embedded in the document? It looks like this might be subset of HTML targeting solely user-interactive web-apps. If it is, it should either be left to another mechanism to solve than the DOM, or we might encourage attaching these template/s as external files (there is no mention of a template src=/ attribute) - existing techniques have DOM fragments hidden with style=display:none; and then replicating them programmatically. What benefits do template/s present? That the fragment is inert, and the declarative nature of insert points and such. If these are the advantages, then we can add an inert= or template= attribute that any div/. Enriching HTML with useful elements is good, but creating a new subset for the purpose of inert content and insert points brings a lot of logic to the browser-side. I think HTML 5 is more about being simple and direct. - how does this answer the need to separate functional design/layout from semantic structure? This seems to replace techniques the such as XML+XSLT or XBL to render content as you wish. From the XBL spec [2]: XSLT operates on a static DOM, permanently replacing that DOM for rendering. XBL, on the other hand, transparently transforms the DOM for rendering while leaving the underlying structure intact, and dynamically reflects changes to the underlying DOM in the transformed rendering. In light of what I wrote about, why should this functionality be replicated to the HTML realm (as the specs say) and not used by it? The specs are missing this motivation. XBL may be used alongside CSS and scripts, instead of merging them inside HTML. Since I'm joining this discussion after a lot of specs have been written I might be missing some key points, but if for nothing else - then let these be for the sake of pointing these questions out and answering them more clearly in the specs for the sake of future developers. Yuval [1]: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html [2]: http://dev.w3.org/2006/xbl2/ [3]: https://developer.mozilla.org/en/CSS/-moz-element On Thu, Apr 26, 2012 at 3:15 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Apr 25, 2012 at 4:33 PM, Brian Kardell bkard...@gmail.com wrote: Tab, are you saying: a) fixing that in script apis for document fragment or something is an ok solution to this, or that b) this means text templates should use template or c) it should be the goal to kill string templates altogether? I just talked with Ojan in person, because we were talking past each other with the terms we were using. I now understand what he was saying! When we say string-based templating, we're really saying I want to embed an arbitrary foreign language into HTML. That language happens to be a templating language, but the exact purpose you're putting it to is irrelevant for our purposes here. For this, script type=foo is not only a satisfactory existing solution to this, but it's the *correct* solution to this - that's precisely what script is designed to do. I was confusing this term with the idea of programmatic DOM creation that doesn't suck. Right now, the right way to create a fragment of HTML is to use a lot of document.createElement() and el.appendChild(). This sucks. Instead, everyone wants to just write a string containing HTML and parse it, like what innerHTML and jQuery do. For this, Raf's proposal works great - it lets you use the innerHTML API without having to employ hacks like jQuery uses to ensure
Re: [webcomponents] HTML Parsing and the template element
Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. I would recommend adding a mime type specifier to the template. Choosing text/html as a content type may hint that contents should be parsed. Alternatively or additionally an attribute indicating that the contents should be parsed as DOM may be specified, e.g. template html/ or template dom/. On Apr 24, 2012 6:25 AM, Rafael Weinstein rafa...@google.com wrote: Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal 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 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 explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments
Re: [webcomponents] HTML Parsing and the template element
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 explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.comwrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. :DG
Suggestions for IDBKeyRange, IDBEnvironment and IDBFactory
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 list of non-sequential keys This allows for several records to be fetched at once, saving lots of loops on IDB interfaces calls for many uses. Specifically for use with indices, it can save effort for consumer to figure out which records are referenced by multiple index entries. - *feature*: IDBEnvironment( Sync) should specify a DOMStringList databaseNames getter Similar to IDBDatabase.objectStoreNames, IDBObjectStore.indexNames, it's important to allow proper discovery. It was discussed [here](http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1528.html) but never promoted, it seems. Personally I would really like it for building development tools for IDB. - *clarification*: IDBFactory.open() should mention that the IDBOpenDBRequest.transaction property holds the transaction It took me a long time to figure this out, as it's explained [here](http://www.w3.org/TR/2011/WD-IndexedDB-20111206/#version_change-transaction-steps) (in step 9.2), especially as it is mentioned as an exception [here](http://www.w3.org/TR/2011/WD-IndexedDB-20111206/#widl-IDBRequest-transaction). I think that if [IDBFactory.open()](http://www.w3.org/TR/2011/WD-IndexedDB-20111206/#widl-IDBFactory-open-IDBOpenDBRequest-DOMString-name-unsigned-long-long-version) will mention it, it will be easier for readers to understand and use. - *name change*: IDBKeyRange.lowerOpen and IDBKeyRange.upperOpen should be changed to something along the lines of IDBKeyRange.excludeLower and IDBKeyRange.excludeUpper The term 'open' is rather math-oriented, and might intuitively mean other things when viewed from a programming perspective. Yuval
