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
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
@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 =
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
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
. 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
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
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
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
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
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?
, 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
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
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
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
...@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
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
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
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
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
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
```
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
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
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
~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
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
, etc.
I really do hope that it's not too late to make such a change.
Regards,
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
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
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
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
, 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
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
...@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
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
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
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
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
, 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
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
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
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
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
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
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
://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
/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
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
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
-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
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
Hi,
Why are XML and Http capitalized differently? Shouldn't it be
XmlHttpRequest?
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
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
54 matches
Mail list logo
