[XHR] XMLHttpRequest name

2009-06-23 Thread Glen
Hi, Why are XML and Http capitalized differently? Shouldn't it be XmlHttpRequest? Glen.

Re: [XHR] XMLHttpRequest name

2009-06-23 Thread Glen
Yeah, that's what's unfortunate. I just hope that future naming follows a standard. Anne van Kesteren wrote: On Tue, 23 Jun 2009 14:46:35 +0200, Glen lonedesign...@yahoo.com wrote: Why are XML and Http capitalized differently? Shouldn't it be XmlHttpRequest? All I know for sure is that we

Re: [XHR] XMLHttpRequest name

2009-06-23 Thread Glen
That's surprising. If there are no guidelines, then it won't likely be avoided in future. We'll end up with all sorts of variations. Anne van Kesteren wrote: On Tue, 23 Jun 2009 16:17:39 +0200, Glen lonedesign...@yahoo.com wrote: Yeah, that's what's unfortunate. I just hope that future

Are web components *seriously* not namespaced?

2015-02-04 Thread Glen
, etc. I really do hope that it's not too late to make such a change. Regards, Glen.

Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Glen
It doesn't really matter whether or not it's based on (or at least resembles) XML, as long as there is some way to specify (and redefine) the prefix of custom elements. G. On 2015/02/04 23:39, Glenn Adams wrote: On Wed, Feb 4, 2015 at 2:31 PM, Glen glen...@gmail.com mailto:glen

Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Glen
Can either of you provide an example in layman's terms? I don't quite understand what this will look like. G. On 2015/02/05 00:29, William Edney wrote: Glen - Glenn has the answer. So we're going to come up with yet-another-registry rather than use one that already exists and guarantees

Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Glen
namespaces] have a number of terrible affordances + Most of them don't commit the same mistakes that XML namespaces did Such as? G. On 2015/02/05 00:58, Tab Atkins Jr. wrote: On Thu, Feb 5, 2015 at 8:31 AM, Glen glen...@gmail.com wrote: I know I'm rather late to the party, but I've been doing

Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Glen
~element a href=xxx x~controller=xxx G. On 2015/02/05 16:51, Melvin Carvalho wrote: On 4 February 2015 at 22:31, Glen glen...@gmail.com mailto:glen...@gmail.com wrote: I know I'm rather late to the party, but I've been doing a lot of reading lately about web components and related

Re: Are web components *seriously* not namespaced?

2015-02-06 Thread Glen
their minds? I really think that this is important. G. On 2015/02/05 21:55, Tab Atkins Jr. wrote: On Fri, Feb 6, 2015 at 12:48 AM, Glen glen...@gmail.com wrote: So in other words it *is* a case of it's good enough. Web components are quite possibly the future of the web, and yet we're implementing

Re: HTML Speech XG Completes, seeks feedback for eventual standardization

2011-12-13 Thread Glen Shires
portions we believe are relevant to WebApps, with links back to the Incubator Report as appropriate. Bjorn Bringert Satish Sampath Glen Shires [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ On Tue, Dec 13, 2011 at 5:32 AM, Dan Burnett dburn...@voxeo.com wrote: Thanks for the info, Art

Re: HTML Speech XG Completes, seeks feedback for eventual standardization

2011-12-22 Thread Glen Shires
-20111206/#introductory, the Speech Web API is not dependent on the Speech Protocol and a Default Speech service can be used for local or remote speech recognition and synthesis. Glen Shires On Thu, Dec 22, 2011 at 10:32 AM, Young, Milan milan.yo...@nuance.comwrote: Hello Glen

Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization

2012-01-04 Thread Glen Shires
Bringert Satish Sampath Glen Shires On Thu, Dec 22, 2011 at 11:38 AM, Glen Shires gshi...@google.com wrote: Milan, The IDLs contained in both documents are in the same format and order, so it's relatively easy to compare the two sidehttp://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech

Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization

2012-01-10 Thread Glen Shires
Art, Per #2 Editor commitment(s): we confirm that Bjorn Bringert, Satish Sampath and Glen Shires volunteer as editors. If others would like to help, we welcome them. Per #4 Testing commitment(s): can you elaborate on what you would like to see at this point? Also, what is the next step? On Mon

Re: CfC: to add Speech API to Charter; deadline January 24

2012-01-20 Thread Glen Shires
/htmlspeech/XGR-htmlspeech/ [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Bjorn Bringert Satish Sampath Glen Shires On Fri, Jan 20, 2012 at 3:58 AM, Arthur Barstow art.bars...@nokia.comwrote: The deadline for comments is extended to January *24*. On 1

Re: CfC: to add Speech API to Charter; deadline January 24

2012-01-24 Thread Glen Shires
://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0067.html Bjorn Bringert Satish Sampath Glen Shires On Tue, Jan 24, 2012 at 9:49 AM, Adrian Bateman adria...@microsoft.comwrote: Microsoft is open to adding this to the WebApps charter. We certainly want to see work on a speech API

CG for Speech JavaScript API

2012-01-31 Thread Glen Shires
stated support for the similar WebApps CfC. [4] Bjorn Bringert Satish Sampath Glen Shires [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html [2] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [3] http://lists.w3.org/Archives/Public/public-webapps

Speech API Community Group

2012-04-03 Thread Glen Shires
to supply an implementation and a test suite for this specification, and will commit to serve as editor. We hope that others will support this CG as they had stated support for the similar WebApps CfC. [2] Bjorn Bringert Satish Sampath Glen Shires [1] http://www.w3.org/community/groups/proposed

Re: Speech API Community Group

2012-04-04 Thread Glen Shires
encourage cc'ing additional lists such as public-xg-htmlspe...@w3.org and/or public-webapps@w3.org as appropriate. When doing so, please prefix your email subject line with [speech-api] /Glen Shires On Tue, Apr 3, 2012 at 8:12 AM, Glen Shires gshi...@google.com wrote: We at Google have proposed

Re: Speech API Community Group

2012-04-04 Thread Glen Shires
is referenced by the Speech JavaScript API. In any case, a comprehensive solution, including security and privacy, is complex, so this CG should start with a realistic goal for the first specification and iterate in future specifications. /Glen Shires FPR7. Web apps should be able to request speech

[IndexedDB] When is an error event dispatched at a transcation?

2015-02-05 Thread Glen Huang
The IDBTransaction interface exposes an onerror event handler. I wonder when that handler gets called? The algorithm of Steps for aborting a transaction” dispatches error events at requests of the transaction, but never at the transaction itself, only an abort event is dispatched, if I

Re: [IndexedDB] When is an error event dispatched at a transcation?

2015-02-05 Thread Glen Huang
Darn it, I forgot they bubble. Thank you for the detailed explanation. On Feb 6, 2015, at 1:59 AM, Joshua Bell jsb...@google.com wrote: On Thu, Feb 5, 2015 at 12:58 PM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: The IDBTransaction interface exposes an onerror event

Re: oldNode.replaceWith(...collection) edge case

2015-01-20 Thread Glen Huang
be a problem with the native DOM. On Jan 20, 2015, at 6:39 PM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jan 18, 2015 at 4:40 AM, Glen Huang curvedm...@gmail.com wrote: To generalize the use case, when you have a bunch of nodes, some of which need to be inserted before a node

Re: oldNode.replaceWith(...collection) edge case

2015-01-20 Thread Glen Huang
...@annevk.nl wrote: On Tue, Jan 20, 2015 at 2:22 PM, Glen Huang curvedm...@gmail.com wrote: jQuery doesn’t support that out of performance and code size reasons: http://bugs.jquery.com/ticket/14380 https://github.com/jquery/jquery/pull/1276#issuecomment-24526014 Both reasons shouldn’t

Re: oldNode.replaceWith(...collection) edge case

2015-01-20 Thread Glen Huang
as an argument along with other nodes, just use before() and after() to insert these other nodes? And even insert them one by one is fine? On Jan 20, 2015, at 11:57 PM, Simon Pieters sim...@opera.com wrote: On Tue, 20 Jan 2015 15:00:41 +0100, Glen Huang curvedm...@gmail.com wrote: I wonder what

Re: oldNode.replaceWith(...collection) edge case

2015-01-21 Thread Glen Huang
before the context node set prevInserted to node This algorithm shouldn’t slow normal operations down, and I wonder if the spec could use an algorithm like this and not using document fragment. On Jan 21, 2015, at 5:50 PM, Glen Huang curvedm...@gmail.com wrote: @Boris @Simon

Re: oldNode.replaceWith(...collection) edge case

2015-01-17 Thread Glen Huang
Oh crap. Just realized saving index won’t work if context node’s previous siblings are passed as arguments. Looks like inserting transient node is still the best way. On Jan 18, 2015, at 11:40 AM, Glen Huang curvedm...@gmail.com wrote: To generalize the use case, when you have a bunch

Re: oldNode.replaceWith(...collection) edge case

2015-01-17 Thread Glen Huang
the context node’s index and its parent, and after running it, pre-insert node into parent before parent’s index’th child (could be null). No transient node involved and no recursive finding. Hope you can reconsider if this edge case should be accepted. On Jan 16, 2015, at 5:04 PM, Glen Huang curvedm

oldNode.replaceWith(...collection) edge case

2015-01-15 Thread Glen Huang
Currently, for `oldNode.replaceWith(…collection)`, if `collection` is array of multiple nodes, and `oldNode` is in `collection`, after the mutation method macro, `oldNode` lives in a doc frag. So in the replace algorithm, `parent` is the doc frag, `node` is also the doc frag, an

Re: oldNode.replaceWith(...collection) edge case

2015-01-15 Thread Glen Huang
Another way to do this is that in mutation method macro, prevent `oldNode` from being added to the doc frag, and after that, insert the doc frag before `oldNode`, finally remove `oldNode`. No recursive finding of next sibling is needed this way. On Jan 16, 2015, at 1:37 PM, Glen Huang curvedm

Re: oldNode.replaceWith(...collection) edge case

2015-01-16 Thread Glen Huang
at 8:47 AM, Glen Huang curvedm...@gmail.com wrote: Another way to do this is that in mutation method macro, prevent `oldNode` from being added to the doc frag, and after that, insert the doc frag before `oldNode`, finally remove `oldNode`. No recursive finding of next sibling is needed

Re: oldNode.replaceWith(...collection) edge case

2015-01-16 Thread Glen Huang
, 2015 at 8:47 AM, Glen Huang curvedm...@gmail.com wrote: Another way to do this is that in mutation method macro, prevent `oldNode` from being added to the doc frag, and after that, insert the doc frag before `oldNode`, finally remove `oldNode`. No recursive finding of next sibling is needed

Re: oldNode.replaceWith(...collection) edge case

2015-01-21 Thread Glen Huang
, Simon Pieters sim...@opera.com wrote: On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang curvedm...@gmail.com wrote: Ah, thank you for letting me know. I vaguely remember document fragment is introduced just to reduce reflows. Looks like this best practice is obsolete now? (I remember myself

Re: oldNode.replaceWith(...collection) edge case

2015-01-27 Thread Glen Huang
before/after/replaceWith behave the same in this case is just a side effect of DOM trying to be less surprising and more symmetrical for the curious ones. I doubt most people would even aware they behave the same in this case. Whenever the user cases come, I believe most people will just use

Re: JSON imports?

2015-04-21 Thread Glen Huang
with prefetch that we'd keep the data around in the memory cache waiting for the request. On Apr 18, 2015 7:07 AM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: Didn't know about this trick. Thanks. But I guess you have to make sure the file being prefetched must have a long

Re: Why is querySelector much slower?

2015-04-28 Thread Glen Huang
Ww, this is pure gold. Thank you so much for such thorough explanation, any even took the trouble to actually implement optimizations to make sure the numbers are right. I'm so grateful for the work you put into this just to answer my question. How do I accept your answer here? ;) So what

Why is querySelector much slower?

2015-04-27 Thread Glen Huang
Intuitively, querySelector('.class') only needs to find the first matching node, whereas getElementsByClassName('.class')[0] needs to find all matching nodes and then return the first. The former should be a lot quicker than the latter. Why that's not the case? See

Re: Why is querySelector much slower?

2015-04-27 Thread Glen Huang
it? On Apr 27, 2015, at 9:51 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/27/15 4:57 AM, Glen Huang wrote: Intuitively, querySelector('.class') only needs to find the first matching node, whereas getElementsByClassName('.class')[0] needs to find all matching nodes Not true; see below

Re: Why is querySelector much slower?

2015-04-27 Thread Glen Huang
...@sicking.cc wrote: On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang curvedm...@gmail.com wrote: Intuitively, querySelector('.class') only needs to find the first matching node, whereas getElementsByClassName('.class')[0] needs to find all matching nodes and then return the first. The former should

Re: Why is querySelector much slower?

2015-04-28 Thread Glen Huang
Wow, it's now super clear. Thanks for the detailed explanation. Just a quick follow up question to quench my curiosity: if I do list[1] and no one has ever asked the list for any element, Gecko will find the first two matching elements, and store them in the list, if I then immediately do

Re: Why is querySelector much slower?

2015-04-28 Thread Glen Huang
querySelector with an id selector does in fact benefit from the id hashtable Looking at the microbenchmark again, for Gecko, getElementById is around 300x faster than querySelector('#id'), and even getElementsByClassName is faster than it. It doesn't look like it benefits much from an eagerly

Re: Why is querySelector much slower?

2015-04-28 Thread Glen Huang
Live node lists make all dom mutation slower Haven't thought about this before. Thank you for pointing it out. So if I use, for example, lots of getElementsByClass() in the code, I'm actually slowing down all DOM mutating APIs?

Re: Why is querySelector much slower?

2015-04-28 Thread Glen Huang
, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: On second thought, if the list returned by getElementsByClass() is lazy populated as Boris says, it shouldn't be a problem. The list is only updated when you access that list again. The invalidation is what makes your code

Re: Why is querySelector much slower?

2015-04-28 Thread Glen Huang
On second thought, if the list returned by getElementsByClass() is lazy populated as Boris says, it shouldn't be a problem. The list is only updated when you access that list again. On Apr 28, 2015, at 2:08 PM, Glen Huang curvedm...@gmail.com wrote: Live node lists make all dom mutation

JSON imports?

2015-04-16 Thread Glen Huang
Inspired by HTML imports, can we add JSON imports too? ```html script type=application/json src=foo.json id=foo/script script type=application/json id=bar { foo: bar } /script ``` ```js document.getElementById(foo).json // or whatever document.getElementById(bar).json ```

Re: JSON imports?

2015-04-17 Thread Glen Huang
extensible web :) On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com mailto:matthewwr...@gmail.com wrote: I like the idea of this. It reminds me of polymer's core-ajax component. On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote

Re: JSON imports?

2015-04-18 Thread Glen Huang
18, 2015, at 10:12 AM, Elliott Sprehn espr...@chromium.org wrote: link rel=prefetch does that for you. On Apr 17, 2015 7:08 PM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: One benefit is that browsers can start downloading it asap, instead of waiting util the fetch

Re: JSON imports?

2015-04-17 Thread Glen Huang
One benefit is that browsers can start downloading it asap, instead of waiting util the fetch code is executed (which could itself be in a separate file). On Apr 18, 2015, at 8:41 AM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm

Re: Is polyfilling future web APIs a good idea?

2015-08-11 Thread Glen Huang
10, 2015, at 9:33 PM, Brian Kardell bkard...@gmail.com wrote: On Aug 6, 2015 11:05 PM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: This assumes you'll match That's a good point. I agree for most APIs it's probably better to simply use polyfill code for all

Re: Is polyfilling future web APIs a good idea?

2015-08-03 Thread Glen Huang
. They have to promise they will never design an API that starts with the prefix we used. Let's say we write a prollyfills for the node.replace API. So our lib exposes node._replace On Aug 3, 2015, at 10:16 AM, Brian Kardell bkard...@gmail.com wrote: On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang

Is polyfilling future web APIs a good idea?

2015-08-02 Thread Glen Huang
I'm pretty obsessed with all kinds of web specs, and invest heavily in tools based on future specs. I was discussing with Tab the other day about whether he thinks using a css preprocessor that desugars future css is a good idea. His answer was surprisingly (at least to me) negative, and

Re: Is polyfilling future web APIs a good idea?

2015-08-05 Thread Glen Huang
Thanks for the detailed explanation. The only thing I'm not sure I understand is the pattern you described: ``` HTMLElement.prototype.foo = HTMLElement.prototype._foo; ``` I had this pattern in mind when you talked about prollyfills: ``` HTMLElement.prototype._foo = function() { if

Re: Is polyfilling future web APIs a good idea?

2015-08-06 Thread Glen Huang
at 6:50 PM, Glen Huang curvedm...@gmail.com wrote: @William @Matthew Ah, thanks. Now I think prollyfill is prolly a good name. :) @Brian Actually, I had this pattern in mind: When no browsers ship the API: ``` if (HTMLElement.prototype.foo) { HTMLElement.prototype._foo

Re: Is polyfilling future web APIs a good idea?

2015-08-04 Thread Glen Huang
On second thought, what's the difference between prollyfills and libraries exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing APIs doesn't seem to be that different from using custom APIs? You

Re: Is polyfilling future web APIs a good idea?

2015-08-06 Thread Glen Huang
@William @Matthew Ah, thanks. Now I think prollyfill is prolly a good name. :) @Brian Actually, I had this pattern in mind: When no browsers ship the API: ``` if (HTMLElement.prototype.foo) { HTMLElement.prototype._foo = HTMLElement.prototype.foo; } else { HTMLElement.prototype._foo =