Re: Is polyfilling future web APIs a good idea?
Awesome. Now I think I understand the full picture you described. When trying to offer a feature that is still being specced, prefix the specced APIs, and once the spec is stable, for browsers that don't ship these APIs, alias the prefixed ones by dropping the prefix. Is that correct? > On Aug 10, 2015, at 9:33 PM, Brian Kardell wrote: > > On Aug 6, 2015 11:05 PM, "Glen Huang" <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 browsers. But some APIs have some extra benefits > > that might not be polyfillable. For example, the native version of web > > animations happen in a compositor thread, so google's web animations > > polyfill use native APIs when they exist and only provide polyfill when > > they don't. > > > Right, and if "ABC Co." shipped software a few years ago before that was > available they probably used jQuery animations and if they haven't touched > their site since then it still works - in fact, it very likely works much > better because the trend for performance is always improving. If they came > back later and used the animations polyfill it takes advantage of some > additional stuff on the compositor thread in some browsers. If this is > really a polyfill because it is a settled standard then as browsers implement > they should automatically get the same boosts because we can ensure future > interop - no harm no foul. You couldn't though have a mix of all of those > worlds - we couldn't have old jQuery code, reinvent how it's > expressed/capable of on the way to standards and somehow automatically fill > the old code - the best you can do there is improve general performance. If > there are underlying tools in some browsers that help you solve a prolyfill > better, you can use them in the same way - but you can't really prognosticate > that that's exactly how it's going to come out the other end when the > standard ships. > > > > But it's not deprecated in browsers that don't support it > > > > Probably I still don't quite understand how prollyfill works. > > > > I don't feel like there are standard best practices worked out here - I'm > giving you my own perspective as someone who has spent an inordinate amount > of time thinking about this, I am not speaking for anyone else here - your > mileage may vary - but I'm advocating it's worth developing some. > > > > Let's say the prollyfill offered node._foo(), one browser shiped > > experimental node.foo(), users ignored that, and used our polyfilled > > version. Everyone was happy. Then other browsers are on board, this API > > becomes stable. Now, what should the prollyfill do? > > > > Should it still ship node._foo() and expect users to use that when most > > browsers ship node.foo() and this API has a precise definition? > > > Or it should deprecate node._foo(), polyfill node.foo() for browsers still > > don't support it and encourage users to switch to node.foo()? > > Of course when it is a standard, released and interop - it's a polyfill... > For the polyfill maker I expect at that point they would simply lose the > underscore and, perhaps to make it easy for authors they could just make _foo > an alias of .foo (which was my example one liner)... It's entirely up to > authors whether they will even go back and update their code and imports and > how they will do so -- their old code will continue to work just fine. But a > lot of authors will be happy to gain perf if there is no rewrite involved > (ie, if they happened to use a version that is ultimately compatible with the > final standard) and there's not really a penalty in using an aliased name > for a method, so that's the approach I would likely use or at least document. > > > > Or it should do something else? > > > > I don't quite understand the oneliner you gave: > > > > HTMLElement.prototype.foo = HTMLElement.prototype._foo; > > > > Why would you want to overwrite a native API with polyfill? How does that > > work for users? Users can choose either native API or prollyfill's prefixed > > version and they will both use the polyfill? > > You wouldn't want to overwrite a native API, I'm not suggesting that -- I'm > suggesting that if you have a prollyfill implementation already which happens > to match the final spec interoperably you can both keep your existing uses >
Re: Is polyfilling future web APIs a good idea?
> 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 browsers. But some APIs have some extra benefits that
might not be polyfillable. For example, the native version of web animations
happen in a compositor thread, so google's web animations polyfill use native
APIs when they exist and only provide polyfill when they don't.
> But it's not deprecated in browsers that don't support it
Probably I still don't quite understand how prollyfill works.
Let's say the prollyfill offered node._foo(), one browser shiped experimental
node.foo(), users ignored that, and used our polyfilled version. Everyone was
happy. Then other browsers are on board, this API becomes stable. Now, what
should the prollyfill do?
Should it still ship node._foo() and expect users to use that when most
browsers ship node.foo() and this API has a precise definition?
Or it should deprecate node._foo(), polyfill node.foo() for browsers still
don't support it and encourage users to switch to node.foo()?
Or it should do something else?
I don't quite understand the oneliner you gave:
HTMLElement.prototype.foo = HTMLElement.prototype._foo;
Why would you want to overwrite a native API with polyfill? How does that work
for users? Users can choose either native API or prollyfill's prefixed version
and they will both use the polyfill?
> On Aug 7, 2015, at 7:07 AM, Brian Kardell wrote:
>
> On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang 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 = HTMLElement.prototype.foo;
>> } else {
>> HTMLElement.prototype._foo = polyfill;
>> };
>> ```
>
> This assumes you'll match, which - again depending on how far you are
> might be a big bet... Personally, I wouldn't use that myself if
> writing something -- Seems a lot like when people simply provided N
> versions of the same prefixed properties instead of just one, it has
> potential to go awry... No one can actually vary because they've done
> the equivalent of shipping the unprefixed thing inadvertently
> intending it to be an experiment, but it wasnt.
>
>>
>> When at least two browsers ship this API:
>>
>> ```
>> if (!HTMLElement.prototype.foo) {
>> HTMLElement.prototype.foo = polyfill;
>> }
>> HTMLElement.prototype._foo = function() {
>> console.warn("deprecated");
>> return this.foo();
>> };
>> ```
>
> But it's not deprecated in browsers that don't support it, it's a
> polyfill at that point and aside from the console.warn (which again,
> in this case seems incorrect in the message at least) it should be
> generally be identical to the oneliner I gave before - the prototype
> for _foo is the polyfill version.
>
>
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
Re: Is polyfilling future web APIs a good idea?
@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 = polyfill;
};
```
When at least two browsers ship this API:
```
if (!HTMLElement.prototype.foo) {
HTMLElement.prototype.foo = polyfill;
}
HTMLElement.prototype._foo = function() {
console.warn("deprecated");
return this.foo();
};
```
Re: Is polyfilling future web APIs a good idea?
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 (HTMLElement.prototype.foo) return this.foo();
return polyfill();
};
```
And users are expected to use it like html._foo() My concern was that when most
browsers ship HTMLElement.prototype.foo, users might want to change html._foo()
to html.foo() so they can use the native version, and the prollyfill is expect
to release a new version with
```
if (!HTMLElement.prototype.foo) {
HTMLElement.prototype.foo = function() {
return polyfill();
};
}
```
I was saying changing html._foo() to html.foo() aren't that different from
changing foo(html) to html.foo();
Where does HTMLElement.prototype.foo = HTMLElement.prototype._foo fit in the
picture?
BTW, just curious, how do you come up with the name "prollyfill" :) ? Why
adding a R there?
Re: Is polyfilling future web APIs a good idea?
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 might say the prefixing approach resembles native APIs more closely, but when changing your code to use native APIs, modifying one character or several doesn't really make much difference (they are the same if you find & replace), as long as you have to modify the code.
Re: Is polyfilling future web APIs a good idea?
Brian, prollyfills seems pragmatic. But what about when the logic of an API changes, but not the name? The node.replaceWith() API for example is about to be revamped to cover some edge cases. If the prollyfills exposed node._replaceWith(), what should it do when the new node.replaceWith() comes? Expose node._replaceWith2()? This doesn't seem to scale. But I do see the benefit of prefixing in prollyfills. node.replaceWith() used to be node.replace(). If we exposed _replace() earlier, we can swap the underlying function with node.replaceWith() when we release a new version, and old code immediately benefit from the new API. But over time, prollyfills are going to accumulate a lot obsolete APIs. Do you think we should use semver to introduce breaking changes? Or these obsolete APIs should always be there? And if we are going this route, I think we need blessing from the WG. 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 wrote: > > On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang wrote: >> 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 recommended sass. >> His arguments were that >> >> 1. the gramma is in flux and can change >> 2. css might never offer some constructs used in sass, at least with very >> low priority. >> >> I think these are good points, and it reduced my enthusiasm for future spec >> based css preprocessors. But this got me thinking about polyfills for future >> web APIs. Are they equally not recommended? Likewise, the APIs might change, >> and for DOM operations we should rely on React because the native DOM might >> never offer such declarative APIs, at least with very low priority. Do >> polyfills like WebReflection's DOM4 look promising? For new projects, should >> I stick with polyfills that only offers compatibilities for older browser, >> and for future spec features, only use libraries that offer similar features >> but invent their own APIs, or should I track future specs and use these >> "unstable" polyfills? >> >> I'm torn on this subject. Would like to be enlightened. > [snip] > > TL;DR: Yes, I think they are good - really good actually, with some > best practices. > > CSS is a slightly different beast at the moment because it is not > (yet) extensible, but let's pretend for a moment that it is so that a > uniform answer works ok... > > This was why I and others advocated defining the idea of/using the > term "prollyfill" as opposed to a polyfill. With a polyfill you are > filling in gaps and cracks in browser support for an established > standard, with a prollyfill you might be charting some new waters. In > a sense, you're taking a guess. If history is any indicator then the > chances that it will ultimately ship that way without change is very > small until it really ships in two interoperable browsers that way. > There's more to it than slight semantics too I think: Polyfill was > originally defined as above and now for many developers the > expectation is that this is what it's doing. In other words, it's > just providing a fill for something which will ultimately be native, > therefore won't change. Except, as we are discussing, this might not > be so. Personally, I think this matters in a big way because so much > depends on people understanding things: If users had understood and > respected vendor-prefixed CSS for use as intended, for example, they > wouldn't have been much of a problem -- but they were. Users didn't > understand that and things shipped natively, so vendors had to adjust > - things got messy. > > Debates about this took up a lot of email space in early extensible > web cg lists - my own take remains unchanged, mileage may vary: > > It is my opinion that when possible, we should 'prefix' prollyfilled > APIs - this could be something as simple as an underscore in DOM APIs > or a "--property" in CSS, etc. Hopefully this makes it obvious that > it is not native and is subject to change, but that isn't the reason > to do it. The reason to do it is the one above: it *may* actually > change so you shouldn't mislead people to think otherwise - it > potentially affects a lot. For example, if something gets very > popular masquera
Is polyfilling future web APIs a good idea?
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 recommended sass. His arguments were that 1. the gramma is in flux and can change 2. css might never offer some constructs used in sass, at least with very low priority. I think these are good points, and it reduced my enthusiasm for future spec based css preprocessors. But this got me thinking about polyfills for future web APIs. Are they equally not recommended? Likewise, the APIs might change, and for DOM operations we should rely on React because the native DOM might never offer such declarative APIs, at least with very low priority. Do polyfills like WebReflection's DOM4 look promising? For new projects, should I stick with polyfills that only offers compatibilities for older browser, and for future spec features, only use libraries that offer similar features but invent their own APIs, or should I track future specs and use these "unstable" polyfills? I'm torn on this subject. Would like to be enlightened. My obsession with future specs based tools doesn't come out of nowhere. Coffeescript used to offer sugars for es5. But then es2015 catches up, and it looks obsolete, since its user base is likely migrating to es over time. The same goes for GSAP vs Web Animations. So I have this sense of feeling that technologies without the blessing of specs/browser vendors are likely to be abandoned eventually. So instead of investing on custom designed APIs, I feel it's more sustainable to bet on spec APIs. What's your take on this topic? P.S. I called out some projects. I, by no means, slight these projects and their authors in any way. The projects usually offer some useful higher abstractions and the authors are all extremely talented and I respect them a lot. This is more from users point of view, and about how they should choose which technologies to use.
Re: Why is querySelector much slower?
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 you're seeing is that the benchmark claims the operation is performed > in 1-2 clock cycles I never thought about relating ops/sec numbers to clock cycles. Thanks for the tip. > So what this getElementById benchmark measures is how fast a loop counter can > be decremented from some starting value to 0. This makes so much sense now. > because of the proxy machinery involved on the JS engine side Do you mean the cost introduced by passing a C++ object into ecmascript world? > In this case, those all seem to have about the same cost; I now see why querySelector has some extract work to do. > But for real-life testcases algorithmic complexity can often be much more > important. Yes. But I suddenly find microbenchmarks to be a wonderful conversation starter. ;) Thanks again for all the explanations, I'm motivated by them to actually dig into the engine source code to discover things myself next time (probably not easy, but should be rewarding). :)
Re: Why is querySelector much slower?
> 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 populated hash
table?
P.S it's very interesting to see Gecko is around 100x faster than others when
it comes to the performance of getElementById. It probably does something
unusual?
Re: Why is querySelector much slower?
But If I do getElementsByClass()[0], and LiveNodeList is immediately garbage collectable, then if I change the DOM, Blink won't traverse ancestors, thus no penalty for DOM mutation? > On Apr 28, 2015, at 2:28 PM, Elliott Sprehn wrote: > > > > On Mon, Apr 27, 2015 at 11:13 PM, Glen Huang <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 slower. Specifically any time you > mutate the tree, and you have live node lists, we traverse ancestors to mark > them as needing to be updated. > > Blink (and likely other browsers) will eventually garbage collect the > LiveNodeList and then your DOM mutations will get faster again. > > >> On Apr 28, 2015, at 2:08 PM, Glen Huang > <mailto:curvedm...@gmail.com>> wrote: >> >>> 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?
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 wrote: > >> 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?
> 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?
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
"list[0]", the first element is returned without walking the DOM (assuming
there are at least two matching elements)?
> querySelector("foo") and getElementsByTagName("foo")[0] can return different
> nodes
Still a bit confused regarding this. If the premise is the selector only
contains characters allowed in a tag name, how can they return different nodes,
maybe I missed something? Unless you mean querySelector(":foo") and
getElementsByTagName(":foo")[0] can return different results, which is obvious.
If by parsing the passed selector (or lookup the cached parsed selectors) you
know it only contains a tag name, why it is a bit harder to optimize? You just
look up the (tagname, root) hash table, no?
> In practice this hasn't come up as a bottleneck in anything we've profiled so
> far
I'm probably prematurely optimizing my code. But nevertheless learned something
quite valuable by asking. Thanks for answering it. :)
Re: Why is querySelector much slower?
I wonder why querySelector can't get the same optimization: If the passed
selector is a simple selector like ".class", do exactly as
getElementsByClassName('class')[0] does?
> On Apr 28, 2015, at 10:51 AM, Ryosuke Niwa wrote:
>
>
>> On Apr 27, 2015, at 7:04 PM, Jonas Sicking wrote:
>>
>> On Mon, Apr 27, 2015 at 1: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 and then return the first. The former should be a lot quicker than the
>>> latter. Why that's not the case?
>>
>> I can't speak for other browsers, but Gecko-based browsers only search
>> the DOM until the first hit for getElementsByClassName('class')[0].
>> I'm not sure why you say that it must scan for all hits.
>
> WebKit (and, AFAIK, Blink) has the same optimization. It's a very important
> optimization.
>
> - R. Niwa
>
Re: Why is querySelector much slower?
Thank you for the sample code. It's very helpful.
When you say "var node = list[0];" walks the DOM until the first item is found,
do you mean it only happens under the condition that some previous code has
changed the DOM structure? If not, the returned list object will be marked as
up-to-day, and accessing the first element is very cheap? I ask because in the
first paragraph you said the returned list and returned first element is
probably precomputed.
Also, this is my mental model after reading your explanation, I wonder if
that's correct:
After UA has parsed html, it caches a hash table of elements with class names
(also all element with ids, all elements with tag names, etc in different hash
tables), keyed under the class names. When getElementsByClassName() is called,
and the DOM hasn't been modified, it simply creates a list of elements with
that class name from the hash table. When the first element is accessed from
that list, and the DOM still isn't modified, the element is returned directly.
The hash table is kept in sync with the DOM when it's modified. And if the DOM
is changed after the list is returned but before it's accessed, the list will
be masked as dirty, and accessing its element will walk the DOM (and mark the
list as partially updated after that).
Is this description correct?
And the final question:
Why can't querySelector benefit from these hash tables? I currently feel the
urge to optimize it myself by overriding it with a custom function which will
parse the passed selector, and if it's a simple selector like "div", ".class",
"#id", call the corresponding getElement*() function instead. Why can't UAs
perform this for us?
If my mental model is correct, it's simpler than getElement*() from an UA's
point of view. It simply needs to lookup the first matching element from the
hash table and return it, no need to return a list and mark it as clean or
dirty any more. The only price it pays is parsing the selector.
Is it because authors don't use querySelector often enough that UAs aren't
interested in optimizing it?
> On Apr 27, 2015, at 9:51 PM, Boris Zbarsky 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.
>
>> and then return the first. The former should be a lot
>> quicker than the latter. Why that's not the case?
>>
>> See http://jsperf.com/queryselectorall-vs-getelementsbytagname/119 for
>> the test
>
> All getElementsByClassName(".foo") has to do in a microbenchmark like this is
> look up a cached list (probably a single hashtable lookup) and return its
> first element (likewise precomputed, unless you're modifying the DOM in ways
> that would affect the list). It doesn't have to walk the tree at all.
>
> querySelector(".foo"), on the other hand, probably walks the tree at the
> moment in implementations.
>
> Also, back to the "not true" above: since the list returned by getElementsBy*
> is live and periodically needs to be recomputed anyway, and since grabbing
> just its first element is a common usage pattern, Gecko's implementation is
> actually lazy (see https://bugzilla.mozilla.org/show_bug.cgi?id=104603#c0 for
> the motivation): it will only walk as much of the DOM as needed to reply to
> the query being made. So for example:
>
> // Creates a list object, doesn't do any walking of the DOM, marks
> // object as dirty and returns it.
> var list = document.getElementsByClassName(".foo");
>
> // Walks the DOM until it finds the first element of the list, marks
> // the list as "partially updated", and returns that first element.
> var node = list[0];
>
> // Marks the list as dirty again, since the set of nodes it matches
> // has changed
> document.documentElement.className = "foo";
>
> I can't speak for what other UAs here, but the assumption that
> getElementsByClassName('.class')[0] needs to find all matching nodes is just
> not true in Gecko.
>
> -Boris
Why is querySelector much slower?
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 http://jsperf.com/queryselectorall-vs-getelementsbytagname/119
for the test
I know querySelectorAll is slow because of the static nature of returned
NodeList, but this shouldn't be an issue for querySelector.
Re: JSON imports?
I just checked the html living standard, all it says about prefetch is
> The prefetch keyword indicates that preemptively fetching and caching the
> specified resource is likely to be beneficial
This is pretty vague, and I sense the caching mechanism used by one vendor is
not guaranteed to be the same for another.
This is very easy to understand how it works, and much succinct comparing to
prefetch and then refetch the same url (all you want is to load the json file
asap, but you need to spread the logic in two places). Why not support it
directly? The only downside I can see is that it should probably honor CORS
headers, thus making it work a bit differently than a vanilla script, but
that's something should be easy to grasp too.
> On Apr 19, 2015, at 5:15 PM, Elliott Sprehn wrote:
>
> I'd hope 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" <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
> cache time set in the http header? Otherwise when it's fetched, the file is
> going to be downloaded again?
>
> What if you don't have control over the json file's http header?
>
>> On Apr 18, 2015, at 10:12 AM, Elliott Sprehn > <mailto:espr...@chromium.org>> wrote:
>>
>> does that for you.
>>
>> On Apr 17, 2015 7:08 PM, "Glen Huang" > <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 >> <mailto:espr...@chromium.org>> wrote:
>>>
>>>
>>>
>>> On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang >> <mailto:curvedm...@gmail.com>> wrote:
>>> Basic feature like this shouldn't rely on a custom solution. However, it
>>> does mean that if browsers implement this, it's easily polyfillable.
>>>
>>> What does this get you over fetch() ? Imports run scripts and enforce
>>> ordering an deduplication. Importing JSON doesn't really make much sense.
>>>
>>>
>>>> On Apr 17, 2015, at 9:23 PM, Wilson Page >>> <mailto:wilsonp...@me.com>> wrote:
>>>>
>>>> Sounds like something you could write yourself with a custom-elements. Yay
>>>> extensible web :)
>>>>
>>>> On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb >>> <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" >>> <mailto:curvedm...@gmail.com>> wrote:
>>>> Inspired by HTML imports, can we add JSON imports too?
>>>>
>>>> ```html
>>>>
>>>>
>>>> { "foo": "bar" }
>>>>
>>>> ```
>>>>
>>>> ```js
>>>> document.getElementById("foo").json // or whatever
>>>> document.getElementById("bar").json
>>>> ```
>>>>
>>>>
>>>
>>>
>>
>
Re: JSON imports?
Didn't know about this trick. Thanks.
But I guess you have to make sure the file being prefetched must have a long
cache time set in the http header? Otherwise when it's fetched, the file is
going to be downloaded again?
What if you don't have control over the json file's http header?
> On Apr 18, 2015, at 10:12 AM, Elliott Sprehn wrote:
>
> does that for you.
>
> On Apr 17, 2015 7:08 PM, "Glen Huang" <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 > <mailto:espr...@chromium.org>> wrote:
>>
>>
>>
>> On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang > <mailto:curvedm...@gmail.com>> wrote:
>> Basic feature like this shouldn't rely on a custom solution. However, it
>> does mean that if browsers implement this, it's easily polyfillable.
>>
>> What does this get you over fetch() ? Imports run scripts and enforce
>> ordering an deduplication. Importing JSON doesn't really make much sense.
>>
>>
>>> On Apr 17, 2015, at 9:23 PM, Wilson Page >> <mailto:wilsonp...@me.com>> wrote:
>>>
>>> Sounds like something you could write yourself with a custom-elements. Yay
>>> extensible web :)
>>>
>>> On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb >> <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" >> <mailto:curvedm...@gmail.com>> wrote:
>>> Inspired by HTML imports, can we add JSON imports too?
>>>
>>> ```html
>>>
>>>
>>> { "foo": "bar" }
>>>
>>> ```
>>>
>>> ```js
>>> document.getElementById("foo").json // or whatever
>>> document.getElementById("bar").json
>>> ```
>>>
>>>
>>
>>
>
Re: JSON imports?
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 wrote:
>
>
>
> On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang <mailto:curvedm...@gmail.com>> wrote:
> Basic feature like this shouldn't rely on a custom solution. However, it does
> mean that if browsers implement this, it's easily polyfillable.
>
> What does this get you over fetch() ? Imports run scripts and enforce
> ordering an deduplication. Importing JSON doesn't really make much sense.
>
>
>> On Apr 17, 2015, at 9:23 PM, Wilson Page > <mailto:wilsonp...@me.com>> wrote:
>>
>> Sounds like something you could write yourself with a custom-elements. Yay
>> extensible web :)
>>
>> On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb > <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" > <mailto:curvedm...@gmail.com>> wrote:
>> Inspired by HTML imports, can we add JSON imports too?
>>
>> ```html
>>
>>
>> { "foo": "bar" }
>>
>> ```
>>
>> ```js
>> document.getElementById("foo").json // or whatever
>> document.getElementById("bar").json
>> ```
>>
>>
>
>
Re: JSON imports?
Basic feature like this shouldn't rely on a custom solution. However, it does
mean that if browsers implement this, it's easily polyfillable.
> On Apr 17, 2015, at 9:23 PM, Wilson Page wrote:
>
> Sounds like something you could write yourself with a custom-elements. Yay
> extensible web :)
>
> On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb <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" <mailto:curvedm...@gmail.com>> wrote:
> Inspired by HTML imports, can we add JSON imports too?
>
> ```html
>
>
> { "foo": "bar" }
>
> ```
>
> ```js
> document.getElementById("foo").json // or whatever
> document.getElementById("bar").json
> ```
>
>
JSON imports?
Inspired by HTML imports, can we add JSON imports too?
```html
{ "foo": "bar" }
```
```js
document.getElementById("foo").json // or whatever
document.getElementById("bar").json
```
Re: Are web components *seriously* not namespaced?
Web Components are also JS. Any renaming you do in JS, you can do just as easily in HTML. + No functionality is enabled by namespaces that can't be done without them just as easily but with a little more verbosity. So I can import a custom element and rename it even after it has been registered? Also, how do I get information about a custom element in my IDE of choice? You don't need to fear future conflicts. Googling for a name is often sufficient. You can change later if there is a conflict. Seriously? And then I break all the code of users who depend on my element? So they rename it to the new name, and for them it conflicts with yet another element? Most people who mention namespaces on the web are referring to XML Namespaces, so I assumed you were as well. The only thing that was similar was the use of a URL, and I made it clear that this was just an example. Regarding the use of URLs: - You can just as easily misspell (or screw up a copy/paste) if you were using a URN or arbitrary string. Since the NS wouldn't match the one defined with the element, the element would fail to "run". - "You can't actually fetch namespace urls" -- It would be made clear that the URLs should return certain metadata, if they don't then it's just a poorly maintained element. - "URLs contain a bunch of extra typing baggage" -- Who types namespaces? Copy/paste. - "Domain names don't mean much" -- that's why you can open the URL in a browser and find information about the element(s). - "The ability to redefine namespaces at various points in the tree make generic processing far more complicated than it should be" -- This is an implementation detail that I cannot comment on, but it may be sufficient to just support declarations in the . I just thought that this would be useful in cases where you have less control of certain areas within your page (AJAX-loaded content, etc.). - "The ns prefix is actually significant ..." -- Same as above. All a namespace needs is to be of reasonable length so that it's probably unique I agree, but "reasonable length" will be too long in the case of HTML elements. Go to "http://customelements.io"; and search for "x-". For example, "x-gif" has no identity. We can Google x-gif and get 5 x-gif elements, so now I have to search through my code to find the definition, and hope that there are comments etc. pointing to more information about the element. There are any number of non-insane ways to do that ... Good. So: 1. Are you thinking of using something like a URN? If so, will there be an endpoint that allows you to register your element and provide metadata that IDEs can query? It's a single point of failure, but it's better than nothing at all. (I think that arbitrary strings would probably be a bad idea) 2. Can you, or anyone else, agree with me that namespaces should be implemented sooner rather than later? Has this already been put to a vote? If so, have any of the vendors changed 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 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 them to be "good enough" in "90%" of use cases? jQuery is JavaScript which means that it's different for various reasons: 1. It's less important to keep the names short. 2. It's possible to rename a plug-in if there is a conflict (e.g. @ http://stackoverflow.com/questions/11898992/conflict-between-two-jquery-plugins-with-same-function-name) 3. It's a library, not something built into the browser, which means that if jQuery decides to add some form of namespacing, it doesn't require a major specification and implementation by 5+ major browsers, etc. Web Components are also JS. Any renaming you do in JS, you can do just as easily in HTML. Complicating things further simply isn't all that necessary. Complicating it for the developer, or the implementers? I can't speak for the latter, but for developers, this would be an *optional* feature. If you don't have conflicts you don't *have* to alter an element's NS prefix, but specifying the prefix in your HTML would provide rich IDE functionality, so I don't see why anyone would *not* want to do this. Again, namespaces are nothing more than an indirection mechanism for prefixes, so you can write a long and more-likely-unique prefix as a shorter prefix that you know is unique for your page. No functionality is enabled by namespaces that can't be done without them just as easily but with a little more verbosity. It's something that can be added organically as necessa
Re: [IndexedDB] When is an error event dispatched at a transcation?
Darn it, I forgot they bubble. Thank you for the detailed explanation. > On Feb 6, 2015, at 1:59 AM, Joshua Bell wrote: > > On Thu, Feb 5, 2015 at 12:58 PM, Glen Huang <mailto:curvedm...@gmail.com>> wrote: > 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 understand the > spec correctly. > > If that is true, why exposing the onerror event handler on the IDBTransaction > interface? > > > In the steps 3.3.12 Fire an error event, "The event bubbles and is > cancelable. The propagation path for the event is the transaction's > connection, then transaction and finally request." Which is to say: if > cancelBubble() is not called, the event will bubble from the request to the > transaction to the connection. > > A common use case is to attach an error handler on the transaction or > database connection to e.g. log errors back to the server, rather than having > to attach such a handler to every request. >
Re: Are web components *seriously* not namespaced?
I like the look of a colon, however it would quite probably conflict
with XML/XHTML so it's probably best to avoid it (although I am not an
expert).
A hyphen or maybe even a tilde (~) would likely be the better option.
G.
On 2015/02/05 16:51, Melvin Carvalho wrote:
On 4 February 2015 at 22:31, Glen <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 technologies, and
the one thing that confounds me is the fact that web components
appear not to have any "real" namespacing.
Can someone explain why this is so, and what the justification is?
Or is it just a case of "it was too complicated, this is good enough"?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before has been defined by
1,000,000 people (slight exaggeration), and you have no idea what
it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so you
call your element (you work for Monkey Solutions LLC),
but then someone else on the team is importing from
Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://monkey-solutions.com/namespace"">https://monkey-solutions.com/namespace"</a>;
});
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://microsoft.com/namespace"">https://microsoft.com/namespace"</a>;
});
https://microsoft.com/namespace";
prefix="msft" />
You could also assign a prefix to all elements within a namespace
like this:
https://microsoft.com/namespace";
prefix="msft" />
You can override the prefix multiple times and the closest
definition is used.
Please note that the above syntax is just an example of what could
be used.
Another BIG pro here is that IDEs can pull in information about
the elements by sending an HTTP request to the namespace URI so
that a tooltip could be displayed with an element description,
author, sample usage, etc.
I really do hope that it's not too late to make such a change.
+1 to everything
Could a colon perhaps be saved as a special character so in future you
can have and and the user agent would be able
to work out which code to use?
Regards,
Glen.
Re: Are web components *seriously* not namespaced?
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 them to be "good enough" in "90%" of use cases? jQuery is JavaScript which means that it's different for various reasons: 1. It's less important to keep the names short. 2. It's possible to rename a plug-in if there is a conflict (e.g. @ http://stackoverflow.com/questions/11898992/conflict-between-two-jquery-plugins-with-same-function-name) 3. It's a library, not something built into the browser, which means that if jQuery decides to add some form of namespacing, it doesn't require a major specification and implementation by 5+ major browsers, etc. > Complicating things further simply isn't all that necessary. Complicating it for the developer, or the implementers? I can't speak for the latter, but for developers, this would be an *optional* feature. If you don't have conflicts you don't *have* to alter an element's NS prefix, but specifying the prefix in your HTML would provide rich IDE functionality, so I don't see why anyone would *not* want to do this. > It's something that can be added organically as necessary. Anne has already made a point about this, but also consider the fact that without real namespacing, we're forced to name based on *potential* conflicts. For example, in the ms- case, ms- may either already exist, or *potentially* exist and be useful, so I name my element mks- instead. Therefore I'm not able to give something the name that I want it to have, for fear of future conflicts. Even just being able to optionally shorten a custom element's NS prefix can be useful. For example, if a vendor uses , we can just change that to and things will be easier to type, cleaner, etc. Regarding XML, I never even mentioned XML in my initial post, so I'm not sure what all the fuss is about. This can be implemented in a way that supports both HTML *and* XHTML/XML, yet doesn't look at all like XML namespacing. The only important part is the use of URIs, I can see no better way of providing both a unique namespace, as well as an endpoint for gathering human- & machine-readable data about a set of custom elements. Is there something inherently wrong with this? Or is this just about people being too lazy to type a closing tag, because that can remain optional. > They [XML 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 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 technologies, and the one thing that confounds me is the fact that web components appear not to have any "real" namespacing. Prefix-based informal namespacing appears to be more than sufficient for 90%+ of use-cases. It works fine, for example, for the huge collection of jQuery widgets/extensions. Complicating things further simply isn't all that necessary. We do plan to help solve it at some point, as Dimitri says, as there are some cases where real namespacing is useful. In particular, if you have a name that you can assume is globally unique with high confidence, you can actually share custom elements across documents. Within a single page, however, prefix-based informal namespaces are nearly always sufficient. XML Namespaces are a pox on the platform, however, and they'll definitely not get reproduced in custom elements. They have a number of terrible affordances. ~TJ
[IndexedDB] When is an error event dispatched at a transcation?
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 understand the spec correctly. If that is true, why exposing the onerror event handler on the IDBTransaction interface?
Re: Are web components *seriously* not namespaced?
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 (at least as far can be
guaranteed) uniqueness: DNS.
The ramifications of not making HTML5 be XHTML5 will be with us for a
very long time indeed.
Cheers,
- Bill
On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov <mailto:dglaz...@google.com>> wrote:
The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
The registry API hasn't been spec'd yet.
:DG<
On Wed, Feb 4, 2015 at 1:31 PM, Glen 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
technologies, and the one thing that confounds me is the fact
that web components appear not to have any "real" namespacing.
Can someone explain why this is so, and what the justification
is? Or is it just a case of "it was too complicated, this is
good enough"?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before has been defined by
1,000,000 people (slight exaggeration), and you have no idea
what it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so
you call your element (you work for Monkey
Solutions LLC), but then someone else on the team is importing
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://monkey-solutions.com/namespace"">https://monkey-solutions.com/namespace"</a>;
});
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://microsoft.com/namespace"">https://microsoft.com/namespace"</a>;
});
https://microsoft.com/namespace"; prefix="msft" />
You could also assign a prefix to all elements within a
namespace like this:
https://microsoft.com/namespace";
prefix="msft" />
You can override the prefix multiple times and the closest
definition is used.
Please note that the above syntax is just an example of what
could be used.
Another BIG pro here is that IDEs can pull in information
about the elements by sending an HTTP request to the namespace
URI so that a tooltip could be displayed with an element
description, author, sample usage, 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?
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 <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 technologies, and
the one thing that confounds me is the fact that web components
appear not to have any "real" namespacing.
There is a serious antipathy towards XML in some quarters. So I
believe the vocabulary was designed for non-XML namespace aware
parsers. Others can verify my understanding (or not).
Can someone explain why this is so, and what the justification is?
Or is it just a case of "it was too complicated, this is good enough"?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before has been defined by
1,000,000 people (slight exaggeration), and you have no idea what
it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so you
call your element (you work for Monkey Solutions LLC),
but then someone else on the team is importing from
Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://monkey-solutions.com/namespace"">https://monkey-solutions.com/namespace"</a>;
});
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://microsoft.com/namespace"">https://microsoft.com/namespace"</a>;
});
https://microsoft.com/namespace";
prefix="msft" />
You could also assign a prefix to all elements within a namespace
like this:
https://microsoft.com/namespace";
prefix="msft" />
You can override the prefix multiple times and the closest
definition is used.
Please note that the above syntax is just an example of what could
be used.
Another BIG pro here is that IDEs can pull in information about
the elements by sending an HTTP request to the namespace URI so
that a tooltip could be displayed with an element description,
author, sample usage, etc.
I really do hope that it's not too late to make such a change.
Regards,
Glen.
Are web components *seriously* not namespaced?
I know I'm rather late to the party, but I've been doing a lot of
reading lately about web components and related technologies, and the
one thing that confounds me is the fact that web components appear not
to have any "real" namespacing.
Can someone explain why this is so, and what the justification is? Or is
it just a case of "it was too complicated, this is good enough"?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before has been defined by 1,000,000
people (slight exaggeration), and you have no idea what it is or where
it came from without looking through imports/scripts etc. Also you want
to keep things short, so you call your element (you work for
Monkey Solutions LLC), but then someone else on the team is importing
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://monkey-solutions.com/namespace"">https://monkey-solutions.com/namespace"</a>;
});
var panel = document.registerElement("panel", {
namespace: "ms <a rel="nofollow" href="https://microsoft.com/namespace"">https://microsoft.com/namespace"</a>;
});
https://microsoft.com/namespace";
prefix="msft" />
You could also assign a prefix to all elements within a namespace like this:
https://microsoft.com/namespace";
prefix="msft" />
You can override the prefix multiple times and the closest
definition is used.
Please note that the above syntax is just an example of what could be used.
Another BIG pro here is that IDEs can pull in information about the
elements by sending an HTTP request to the namespace URI so that a
tooltip could be displayed with an element description, author, sample
usage, etc.
I really do hope that it's not too late to make such a change.
Regards,
Glen.
Re: oldNode.replaceWith(...collection) edge case
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 replaceWith. > On Jan 27, 2015, at 8:51 PM, Anne van Kesteren wrote: > > On Thu, Jan 22, 2015 at 11:43 AM, Jonas Sicking wrote: >> In general I agree that it feels unintuitive that you can't replace a node >> with a collection which includes the node itself. So the extra line or two >> of code seems worth it. > > You don't think it's weird that before/after/replaceWith all end up > doing the same for that scenario? Perhaps it's okay... > > > -- > https://annevankesteren.nl/
Re: oldNode.replaceWith(...collection) edge case
I have two more things to add. 1. One more reason why context node should be allowed as an argument. These work as intended: node.before(node) node.after(node) node.replaceWith(node) By passing an additional argument, they suddenly fail: node.before(node, another) node.after(node, another) node.replaceWith(node, another) This doesn’t feel right. 2. Algorithm performance The performance hit is based on the assumption that an implementation will follow the spec algorithm closely and use a document fragment when multiple arguments are passed. In reality, I believe an implementation can totally get away from that and insert arguments directly, as long as it can make sure the final DOM structure is correct, mutation records are queued, ranges are modified, etc. Nothing in the algorithm dictates the using of a document fragment. For example, for the before() method, I can imagine it could be implemented it like this (in pseudo code, ignoring mutation records and range, etc): ensure context node validity set prevInserted to null for node from last argument to first argument, if the argument is a document fragment, from its last child to first child if node is the context node if prevInserted is not null insert node before it set prevInserted to node else set prevInserted to node continue else insert node 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 wrote: > > @Boris @Simon > > From the jsperf, looks like Blink is indeed making document fragment > obsolete. Run the tests in webkit, although still way faster with document > fragment, I believe the gap will narrow in the future. (I really think > authors shouldn’t have to rely on it to get good performance). > > Thank you for debunking the myth for me. :) > > Now, let’s go back to the original topic. I brought up document fragment > because I wanted to argue that by disallowing passing the context node as an > argument, authors would be unable find an equally performant solution. You > guys tell me that’s not the case. I agree, and I will drop that. > > But I still don’t feel disallowing that is the right way to go, for two > reasons: > > 1. Passing context node as an argument does have a meaningful result, and > practical use cases. > 2. Although the use cases might not come as often, these are native DOM > methods, everybody is expected to use them. Given the huge user base, the use > cases might not come as rare also. > > I see the argument against it is probably that it may slow down normal > operations too. But is that really true? The key here is to find the correct > insertion point after the macro action. Although in the spec algorithm, using > a transient node seems to be the most performant way (and it slows down > normal operations), I doubt it’s impossible for an actual implementation to > optimize that. > > This isn't some feature that can be disallowed now and allowed in the future. > And by disallowing it, I think it qualifies as a gotcha when you do need it. > > But that’s just my personal feelings. If it turns out it’s really not that > cheap to implement. I’d be happy to correctly use before() and after() and > not root for something that will slow everybody down. :) > >> On Jan 21, 2015, at 4:52 PM, Simon Pieters wrote: >> >> On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang 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 wondering >>> why bowsers couldn’t optimize that back then.) Many people still suggest it >>> though, including google >>> (https://developers.google.com/speed/articles/javascript-dom >>> <https://developers.google.com/speed/articles/javascript-dom> the >>> "DocumentFragment DOM Generation” section), and you can find more by >>> googling “why use document fragment". >> >> I think that article is a bit misguided. Changing a class does trigger a >> reflow, but it doesn't force a reflow while the script is running (maybe it >> does in old browsers). Asking for layout information does force a reflow. >> >> I think documentfragment has been faster in several browsers and maybe still >> is, but in Blink at least it appears that the different methods are getting &g
Re: oldNode.replaceWith(...collection) edge case
@Boris @Simon From the jsperf, looks like Blink is indeed making document fragment obsolete. Run the tests in webkit, although still way faster with document fragment, I believe the gap will narrow in the future. (I really think authors shouldn’t have to rely on it to get good performance). Thank you for debunking the myth for me. :) Now, let’s go back to the original topic. I brought up document fragment because I wanted to argue that by disallowing passing the context node as an argument, authors would be unable find an equally performant solution. You guys tell me that’s not the case. I agree, and I will drop that. But I still don’t feel disallowing that is the right way to go, for two reasons: 1. Passing context node as an argument does have a meaningful result, and practical use cases. 2. Although the use cases might not come as often, these are native DOM methods, everybody is expected to use them. Given the huge user base, the use cases might not come as rare also. I see the argument against it is probably that it may slow down normal operations too. But is that really true? The key here is to find the correct insertion point after the macro action. Although in the spec algorithm, using a transient node seems to be the most performant way (and it slows down normal operations), I doubt it’s impossible for an actual implementation to optimize that. This isn't some feature that can be disallowed now and allowed in the future. And by disallowing it, I think it qualifies as a gotcha when you do need it. But that’s just my personal feelings. If it turns out it’s really not that cheap to implement. I’d be happy to correctly use before() and after() and not root for something that will slow everybody down. :) > On Jan 21, 2015, at 4:52 PM, Simon Pieters wrote: > > On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang 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 wondering >> why bowsers couldn’t optimize that back then.) Many people still suggest it >> though, including google >> (https://developers.google.com/speed/articles/javascript-dom >> <https://developers.google.com/speed/articles/javascript-dom> the >> "DocumentFragment DOM Generation” section), and you can find more by >> googling “why use document fragment". > > I think that article is a bit misguided. Changing a class does trigger a > reflow, but it doesn't force a reflow while the script is running (maybe it > does in old browsers). Asking for layout information does force a reflow. > > I think documentfragment has been faster in several browsers and maybe still > is, but in Blink at least it appears that the different methods are getting > about equally fast. It probably depends on how you do it, though. This jsperf > might be interesting: > > http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81 > >> So to recap, when you have the need to pass the context node 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? > > Yeah. > > -- > Simon Pieters > Opera Software
Re: oldNode.replaceWith(...collection) edge case
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 wondering why bowsers couldn’t optimize that back then.) Many people still suggest it though, including google (https://developers.google.com/speed/articles/javascript-dom <https://developers.google.com/speed/articles/javascript-dom> the "DocumentFragment DOM Generation” section), and you can find more by googling “why use document fragment". So to recap, when you have the need to pass the context node 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 wrote: > > On Tue, 20 Jan 2015 15:00:41 +0100, Glen Huang wrote: > >> I wonder what the correct method should be? For the example I gave in the >> previous mail, it looks like I have to either create two fragments (and >> compute which nodes go to which fragment) and insert them before or after >> the node (two reflows), or implement the transient node algorithm myself >> (but with no suppressing observer ability, also three reflows (insert fake >> node, pull out context node, insert fragment), i guess if browsers implement >> it natively, they can reduce it to just one reflow?). Both doesn’t sound >> very optimal. > > In all cases it would be just one reflow after the script has finished, > unless you force a reflow by asking for layout information (e.g. offsetTop) > between the mutations. > > -- > Simon Pieters > Opera Software
Re: oldNode.replaceWith(...collection) edge case
I wonder what the correct method should be? For the example I gave in the previous mail, it looks like I have to either create two fragments (and compute which nodes go to which fragment) and insert them before or after the node (two reflows), or implement the transient node algorithm myself (but with no suppressing observer ability, also three reflows (insert fake node, pull out context node, insert fragment), i guess if browsers implement it natively, they can reduce it to just one reflow?). Both doesn’t sound very optimal. > On Jan 20, 2015, at 9:34 PM, Anne van Kesteren wrote: > > On Tue, Jan 20, 2015 at 2:22 PM, Glen Huang 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 be a problem with the native DOM. > > They are. I also realized that if we did this we would have to make > before(), after(), and replaceWith() identical when passed the context > object. Not allowing the context object and requiring usage of the > correct method seems simpler. > > > -- > https://annevankesteren.nl/
Re: oldNode.replaceWith(...collection) edge case
jQuery doesn’t support that out of performance and code size reasons:
http://bugs.jquery.com/ticket/14380 <http://bugs.jquery.com/ticket/14380>
https://github.com/jquery/jquery/pull/1276#issuecomment-24526014
<https://github.com/jquery/jquery/pull/1276#issuecomment-24526014>
Both reasons shouldn’t be a problem with the native DOM.
> On Jan 20, 2015, at 6:39 PM, Anne van Kesteren wrote:
>
> On Sun, Jan 18, 2015 at 4:40 AM, Glen Huang wrote:
>> To generalize the use case, when you have a bunch of nodes, some of which
>> need to be inserted before a node, and some of which after it, you are
>> likely to want `replaceWith` could accept the context node as an argument.
>
> This sound somewhat reasonable but I haven't been able to reproduce
> this in existing libraries. E.g. in Jquery
>
> $("div").replaceWith([$("div"), "test"])
>
> ends up as just test...
>
>
> --
> https://annevankesteren.nl/
Re: oldNode.replaceWith(...collection) edge case
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 wrote: > > To generalize the use case, when you have a bunch of nodes, some of which > need to be inserted before a node, and some of which after it, you are likely > to want `replaceWith` could accept the context node as an argument. > > I just realized another algorithm: Before running the macro, save 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 wrote: >> >> Oh, right. Trying to be smart and it just proved otherwise. :P >> >>> I don't really see a good reason to complicate the algorithm for this >>> scenario, personally. >> >> This edge case may seem absurd at first sight. Let me provide a use case: >> >> Imagine you have this simple site >> >> ``` >> >> Blog >> About >> Contact >> >> About page content >> ``` >> >> You are currently at the about page. What you are trying to do is that when >> the user clicks a nav link, the corresponding page is fetched via ajax, and >> inserted before or after the current main element, depending on whether the >> clicked nav link exists before or after the current nav link. >> >> So when the page is first loaded, you first loop over the nav links to >> create empty mains for placeholder purposes. >> >> ``` >> >> Blog >> About >> Contact >> >> >> About page content >> >> ``` >> >> How do you do that? Well, ideally, you should be able to just do (in pseudo >> code): >> >> ``` >> currentMain = get the main element >> links = get all a elements >> mains = [] >> >> for i, link in links >> if link is current link >> mains[i] = currentMain >> else >> mains[i] = clone currentMain shallowly >> >> currentMain.replaceWith(…mains) >> ``` >> >> This way you are inserting nodes in batch, and not having to deal with >> choosing insertBefore or appendChild. >> >> Without `replaceWith` supporting it, in order to do batch insertions (nav >> links could be a large list, imagining a very long TOC links), you are >> forced to manually do the steps I mentioned in the first mail. >> >>> On Jan 16, 2015, at 4:22 PM, Anne van Kesteren wrote: >>> >>> On Fri, Jan 16, 2015 at 8:47 AM, Glen Huang 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 this way. >>> >>> But then d2 would no longer be present? >>> >>> I don't really see a good reason to complicate the algorithm for this >>> scenario, personally. >>> >>> >>> -- >>> https://annevankesteren.nl/ >> >
Re: oldNode.replaceWith(...collection) edge case
To generalize the use case, when you have a bunch of nodes, some of which need to be inserted before a node, and some of which after it, you are likely to want `replaceWith` could accept the context node as an argument. I just realized another algorithm: Before running the macro, save 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 wrote: > > Oh, right. Trying to be smart and it just proved otherwise. :P > >> I don't really see a good reason to complicate the algorithm for this >> scenario, personally. > > This edge case may seem absurd at first sight. Let me provide a use case: > > Imagine you have this simple site > > ``` > > Blog > About > Contact > > About page content > ``` > > You are currently at the about page. What you are trying to do is that when > the user clicks a nav link, the corresponding page is fetched via ajax, and > inserted before or after the current main element, depending on whether the > clicked nav link exists before or after the current nav link. > > So when the page is first loaded, you first loop over the nav links to create > empty mains for placeholder purposes. > > ``` > > Blog > About > Contact > > > About page content > > ``` > > How do you do that? Well, ideally, you should be able to just do (in pseudo > code): > > ``` > currentMain = get the main element > links = get all a elements > mains = [] > > for i, link in links > if link is current link > mains[i] = currentMain > else > mains[i] = clone currentMain shallowly > > currentMain.replaceWith(…mains) > ``` > > This way you are inserting nodes in batch, and not having to deal with > choosing insertBefore or appendChild. > > Without `replaceWith` supporting it, in order to do batch insertions (nav > links could be a large list, imagining a very long TOC links), you are forced > to manually do the steps I mentioned in the first mail. > >> On Jan 16, 2015, at 4:22 PM, Anne van Kesteren wrote: >> >> On Fri, Jan 16, 2015 at 8:47 AM, Glen Huang 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 this way. >> >> But then d2 would no longer be present? >> >> I don't really see a good reason to complicate the algorithm for this >> scenario, personally. >> >> >> -- >> https://annevankesteren.nl/ >
Re: oldNode.replaceWith(...collection) edge case
Here is another try: How about before executing the mutation method macro, we insert a transient node after `oldNode`, suppressing observers. Then run the mutation method macro, pre-insert `node` before the transient node and finally remove the transient node, suppressing observers. Idea comes from Andrea’s DOM4 library: https://github.com/WebReflection/dom4/commit/ffc8cbdf88fa98627dd82cf11084a0660b9bbfc0 <https://github.com/WebReflection/dom4/commit/ffc8cbdf88fa98627dd82cf11084a0660b9bbfc0> > On Jan 16, 2015, at 4:22 PM, Anne van Kesteren wrote: > > On Fri, Jan 16, 2015 at 8:47 AM, Glen Huang 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 this way. > > But then d2 would no longer be present? > > I don't really see a good reason to complicate the algorithm for this > scenario, personally. > > > -- > https://annevankesteren.nl/
Re: oldNode.replaceWith(...collection) edge case
Oh, right. Trying to be smart and it just proved otherwise. :P > I don't really see a good reason to complicate the algorithm for this > scenario, personally. This edge case may seem absurd at first sight. Let me provide a use case: Imagine you have this simple site ``` Blog About Contact About page content ``` You are currently at the about page. What you are trying to do is that when the user clicks a nav link, the corresponding page is fetched via ajax, and inserted before or after the current main element, depending on whether the clicked nav link exists before or after the current nav link. So when the page is first loaded, you first loop over the nav links to create empty mains for placeholder purposes. ``` Blog About Contact About page content ``` How do you do that? Well, ideally, you should be able to just do (in pseudo code): ``` currentMain = get the main element links = get all a elements mains = [] for i, link in links if link is current link mains[i] = currentMain else mains[i] = clone currentMain shallowly currentMain.replaceWith(…mains) ``` This way you are inserting nodes in batch, and not having to deal with choosing insertBefore or appendChild. Without `replaceWith` supporting it, in order to do batch insertions (nav links could be a large list, imagining a very long TOC links), you are forced to manually do the steps I mentioned in the first mail. > On Jan 16, 2015, at 4:22 PM, Anne van Kesteren wrote: > > On Fri, Jan 16, 2015 at 8:47 AM, Glen Huang 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 this way. > > But then d2 would no longer be present? > > I don't really see a good reason to complicate the algorithm for this > scenario, personally. > > > -- > https://annevankesteren.nl/
Re: oldNode.replaceWith(...collection) edge case
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 wrote: > > 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 > `HierarchyRequestError` is thrown. > > I wonder if an error really should be thrown in this case? Intuitively, > `collection` should be inserted before `oldNode`’s original next sibling. > > For example: > > ``` > > > > > ``` > > Imagine `oldNode` is #d2, `collection` is [#d1,#d2,#d4], executing > `oldNode.replaceWith(…collection)` should give > > ``` > > > > > ``` > > Instead of throwing an error. > > To make it this work, before executing the mutation method macro, `oldNode`’s > parent should be saved. It’s next sibling should also be saved, but the next > sibling need to be found recursively if it happens to be in `collection` too. > > So, If I’m not wrong, this edge case could work in principle. I’m not sure if > there is any interest to allow this?
oldNode.replaceWith(...collection) edge case
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 `HierarchyRequestError` is thrown. I wonder if an error really should be thrown in this case? Intuitively, `collection` should be inserted before `oldNode`’s original next sibling. For example: ``` ``` Imagine `oldNode` is #d2, `collection` is [#d1,#d2,#d4], executing `oldNode.replaceWith(…collection)` should give ``` ``` Instead of throwing an error. To make it this work, before executing the mutation method macro, `oldNode`’s parent should be saved. It’s next sibling should also be saved, but the next sibling need to be found recursively if it happens to be in `collection` too. So, If I’m not wrong, this edge case could work in principle. I’m not sure if there is any interest to allow this?
Re: Speech API Community Group
One of the key goals of this Speech API CG is to expedite the implementation of speech in browsers. As Olli outlined [1], web APIs tend to evolve, beginning with a first iteration specification and adding additional features later. I believe that a web-author-facing JavaScript API for specifying network speech services (FPR7 and FPR12) are within the scope of this CG, and can be included in the first iteration of this specification, so long as they do not delay completing it. For example, a serviceUri [2] method can provide a JavaScript API for specifying such resources. Parameters in that Uri string could be used for resource selection. As Jerry wrote [3] the challenge is "to define what characteristics may be specified for resource selection or, alternatively, to determine that such definition is external to the immediate API: for instance, there might be a separate spec which 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 service different from default. FPR12. Speech services that can be specified by web apps must include network speech services. [1] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2012Jan/0009.html [2] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#dfn-uri [3] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2012Apr/0008.html On Tue, Apr 3, 2012 at 2:08 PM, Young, Milan wrote: > The problem is that the community group has an ambiguous “charter”, and > at least some folks would like this clarified before joining. Being that > Speech-XG and Webapps are the two most relevant lists, I don’t know where > else the discussion would take place. > > ** ** > > I believe that all of this could be cleared up by a simple statement from > the CG chair (Glen Shires) that FPR7 and FPR12 are in scope. There is > “STRONG” interest in this domain and an editor has already volunteered (Jim > Barnett). Seems like a simple decision. > > ** ** > > Thanks > > ** ** > > ** ** > > *From:* Charles Pritchard [mailto:ch...@jumis.com] > *Sent:* Tuesday, April 03, 2012 1:29 PM > *To:* Michael Bodell > *Cc:* Jerry Carter; Raj (Openstream); Young, Milan; Jim; Glen Shires; > public-xg-htmlspe...@w3.org; public-webapps@w3.org > > *Subject:* Re: Speech API Community Group > > ** ** > > I'd like to encourage everyone interested in the Speech API to join the > mailing list: > http://lists.w3.org/Archives/Public/public-speech-api/ > > For those interested in more hands-on interaction, there's the CG: > http://www.w3.org/community/speech-api/ > > For some archived mailing list discussion, browse the old XG list: > http://lists.w3.org/Archives/Public/public-xg-htmlspeech/ > > It seems like we can move this chatter over to public-speech-api and off > of the webapps list. > > -Charles > > > On 4/3/2012 1:08 PM, Michael Bodell wrote: > > A little bit of historical context and resource references might be > helpful for some on the email thread. > > > > While this is still an early stage for a community group, if one will > happen, it actually isn’t early for the community as a group to talk about > this. In many ways we’ve already done the initial incubation and community > discussion and investigation for this space in the HTML Speech XG. This > lead to the XG’s use case and requirements document: > > http://www.w3.org/2005/Incubator/htmlspeech/live/requirements.html > > > > which were then refined to a prioritized requirement list after soliciting > community input: > > > http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#prioritized > > > > > As I read it, Milan and Jim and Raj’s requirements discussed are part of > FPR7 [Web apps should be able to request speech service different from > default] and FPR12 [Speech services that can be specified by web apps must > include network speech services], both of which were voted to have “Strong > Interest” by the community. > > > > Further work from these requirements led to the community coming up with a > proposal, which is ready now to be taken to a standards track process, that > was published in the XG final report: > > http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/ > > > > Hopefully we can all properly leverage the work the community has already > done. > > > > Michael Bodell > > Co-chair HTML Speech XG > > > > **
Re: Speech API Community Group
The Speech API Community Group is now up and running, please join us at http://www.w3.org/community/speech-api/ We plan to hold discussions and contribute to and review JavaScript Speech API specifications using the public-speech-api-cont...@w3.org mailing list. For topics of broad interest, we 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 wrote: > We at Google have proposed the formation of a new "Speech API Community > Group" to pursue a JavaScript Speech API. We encourage you to join and > support this effort. [1] > > We believe that forming a Community Group has the following advantages: > > - It’s quick, efficient and minimizes unnecessary process overhead. > > - We believe it will allow us, as a group, to reach consensus in > an efficient manner. > > - We hope it will expedite interoperable implementations in > multiple browsers. (A good example is the Web Media Text Tracks CG, where > multiple implementations are happening quickly.) > > Google plans 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/#speech-api > [2] > http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0315.html > -- Thanks! Glen Shires
Speech API Community Group
We at Google have proposed the formation of a new "Speech API Community Group" to pursue a JavaScript Speech API. We encourage you to join and support this effort. [1] We believe that forming a Community Group has the following advantages: - It’s quick, efficient and minimizes unnecessary process overhead. - We believe it will allow us, as a group, to reach consensus in an efficient manner. - We hope it will expedite interoperable implementations in multiple browsers. (A good example is the Web Media Text Tracks CG, where multiple implementations are happening quickly.) Google plans 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/#speech-api [2] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0315.html
CG for Speech JavaScript API
We at Google propose the formation of a new Community Group to pursue a JavaScript Speech API. Specifically, we are proposing this Javascript API [1], which enables web developers to incorporate speech recognition and synthesis into their web pages, and supports the majority of use-cases in the Speech Incubator Group's Final Report [2]. This API enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. For this first specification, we believe this simplified subset API will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. However, in the spirit of consensus, we are willing to broaden this subset API to include additional Javascript API features in the Speech Incubator Final Report. We believe that forming a Community Group has the following advantages: - It’s quick, efficient and minimizes unnecessary process overhead. - We believe it will allow us, as a group, to reach consensus in an efficient manner. - We hope it will expedite interoperable implementations in multiple browsers. (A good example is the Web Media Text Tracks CG, where multiple implementations are happening quickly.) - We propose the CG will use the public-webapps@w3.org as its mailing list to provide visibility to a wider audience, with a balanced web-centric view for new JavaScript APIs. This arrangement has worked well for the HTML Editing API CG [3]. Contributions to the specification produced by the Speech API CG will be governed by the Community Group CLA and the CG is responsible for ensuring that all Contributions come from participants that have agreed to the CG CLA. We believe the response to the CfC [4] has shown substantial interest and support by WebApps members. - A CG provides an IPR environment that simplifies future transition to standards track. Google plans 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. [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/2011JulSep/1402.html [4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0315.html
Re: CfC: to add Speech API to Charter; deadline January 24
Art, Charles, We are very pleased to see the positive responses to the CfC. In particular, we believe this meets all the criteria that Art suggested in [1]. 1. Relatively clear scope of the feature(s) The scope is well-defined and bounded. [1] [2] 2. Editor commitment(s) Google and Nuance have committed to serve as editors, and we welcome additional editors. [3] [4] 3. Implementation commitments from at least two WG members Google and Microsoft plan implementations, and Mozilla has shown strong interest. [5] [6] In addition, Nuance plans an implementation of the "network speech services" to support the user-agent. [4] 4. Testing commitment(s) Google will provide a test suite, and we welcome additional contributors. [3] What is the next step for adding this to the charter"? [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0065.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0235.html [3] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0074.html [4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0113.html [5] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0281.html [6] http://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 wrote: > Microsoft is open to adding this to the WebApps charter. > > We certainly want to see work on a speech API for user agents proceed at > W3C. Our priorities for the API are 1) a procedural (JavaScript) API and 2) > a declarative syntax for speech recognition and text-to-speech in HTML. We > think WebApps would be a good venue to bring speech to the attention of > members who wouldn't normally participate in this area. On the other hand > we recognise that there may be some members who are interested in moving > speech forward but who might not be willing to make IPR commitments for > other specifications that WebApps works on. If that is the case then we'd > rather have them involved in a separate working group than not benefit from > their contributions. > > Cheers, > > Adrian. > > On Friday, January 20, 2012 12:58 PM, Arthur Barstow wrote: > > The deadline for comments is extended to January *24*. > > > > On 1/20/12 6:55 AM, ext Arthur Barstow wrote: > > > The deadline for comments is extended to January. > > > > > > Andrian, Maciej - I would appreciate it you would please provide some > > > feedback on this CfC. > > > > > > On 1/12/12 7:31 AM, ext Arthur Barstow wrote: > > >> Glen Shires and some others at Google proposed [1] that WebApps add > > >> Speech API to WebApps' charter and they put forward the Speech > > >> Javascript API Specification [2] as as a starting point. Members of > > >> Mozilla and Nuance have voiced various levels of support for this > > >> proposal. As such, this is a Call for Consensus to add Speech API to > > >> WebApps' charter. > > >> > > >> Positive response to this CfC is preferred and encouraged and silence > > >> will be considered as agreeing with the proposal. The deadline for > > >> comments is January 19 and all comments should be sent to > > >> public-webapps at w3.org. > > >> > > >> -AB > > >> > > >> [1] > > >> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.ht > > >> ml > > >> [2] > > >> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-169 > > >> 6/speechapi.html > > >> > > > > > > >
Re: CfC: to add Speech API to Charter; deadline January 24
Some of the reasons we believe that the JavaScript Speech API is best suited for WebApps, instead of it's own working group, include: 1. Speech is likely to become a core API, like other WebApps deliverables such as File API. It is important that it be compatible and consistent with, and interact well with other JavaScript API components. In particular, speech provides a new method for accepting user input, producing user output and interacting with the features, and controlling the flow, of other JavaScript API components. 2. WebApps provides a balanced web-centric view for new JavaScript APIs. The XG group consisted of a large number of speech experts, but only a few with broad web API expertise. We believe the formation of a new WG would have a similar imbalance, whereas the WebApps WG can provide valuable, balanced guidance and feedback. 3. The scope of this effort is well-defined and bounded. All that have responded to this CfC have agreed that JavaScript API portions of the XG Final Report are relevant to WebApps, and that the wire protocol portions of the XG Final Report are not relevant to WebApps (and should be pursued in another group, such as IETF). The differing opinions seem only about the specific starting point of this effort, whether to base it on the full JavaScript API in the XG's Final Report [1] or a subset of that JavaScript API, which supports the majority of use cases, as proposed by Google [2]. For this first recommendation-track document, we believe a subset will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. However, in the spirit of consensus, we are willing to broaden this subset to include additional API features in the XG Final Report. [1] http://www.w3.org/2005/Incubator/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 wrote: > The deadline for comments is extended to January *24*. > > > On 1/20/12 6:55 AM, ext Arthur Barstow wrote: > >> The deadline for comments is extended to January. >> >> Andrian, Maciej - I would appreciate it you would please provide some >> feedback on this CfC. >> >> On 1/12/12 7:31 AM, ext Arthur Barstow wrote: >> >>> Glen Shires and some others at Google proposed [1] that WebApps add >>> Speech API to WebApps' charter and they put forward the Speech Javascript >>> API Specification [2] as as a starting point. Members of Mozilla and Nuance >>> have voiced various levels of support for this proposal. As such, this is a >>> Call for Consensus to add Speech API to WebApps' charter. >>> >>> Positive response to this CfC is preferred and encouraged and silence >>> will be considered as agreeing with the proposal. The deadline for comments >>> is January 19 and all comments should be sent to public-webapps at >>> w3.org. >>> >>> -AB >>> >>> [1] http://lists.w3.org/Archives/**Public/public-webapps/** >>> 2011OctDec/1696.html<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html> >>> [2] http://lists.w3.org/Archives/**Public/public-webapps/** >>> 2011OctDec/att-1696/speechapi.**html<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html> >>> >>> >> >
Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
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, Jan 9, 2012 at 8:12 AM, Olli Pettay wrote: > On 01/09/2012 04:59 PM, Arthur Barstow wrote: > >> Hi All, >> >> As I indicated in [1], WebApps already has a relatively large number of >> specs in progress and the group has agreed to add some new specs. As >> such, to review any new charter addition proposals, I think we need at >> least the following: >> >> 1. Relatively clear scope of the feature(s). (This information should be >> detailed enough for WG members with relevant IP to be able to make an IP >> assessment.) >> >> 2. Editor commitment(s) >> >> 3. Implementation commitments from at least two WG members >> > Is this really requirement nowadays? > Is there for example commitment to implement > File System API? > http://dev.w3.org/2009/dap/**file-system/file-dir-sys.html<http://dev.w3.org/2009/dap/file-system/file-dir-sys.html> > > But anyway, I'm interested to implement the speech API, > and as far as I know, also other people involved with Mozilla > have shown interest. > > > > >> 4. Testing commitment(s) >> >> Re the APIs in this thread -> I think Glen's API proposal [2] adequately >> addresses #1 above and his previous responses imply support for #2 but >> it would be good for Glen, et al. to confirm. Re #3, other than Google, >> I don't believe any other implementor has voiced their support for >> WebApps adding these APIs. As such, I think we we need additional input >> on implementation support (e.g. Apple, Microsoft, Mozilla, Opera, etc.). >> > > It doesn't matter too much to me in which group the API will be developed > (except that I'm against doing it in HTML WG). > WebApps is reasonably good place (if there won't be any IP issues.) > > > > > -Olli > > > > >> Re the markup question -> WebAppsdoes have some precedence for defining >> markup (e.g. XBL2, Widget XML config). I don't have a strong opinion on >> whether or not WebApps should include the type of markup in the XG >> Report. I think the next step here is for WG members to submit comments >> on this question. In particular, proponents of including markup in >> WebApps' charter should respond to #1-4 above. >> >> -AB >> >> [1] http://lists.w3.org/Archives/**Public/public-webapps/** >> 2011OctDec/1474.html<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1474.html> >> [2] >> http://lists.w3.org/Archives/**Public/public-webapps/** >> 2011OctDec/att-1696/speechapi.**html<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html> >> >> >> >> On 1/5/12 6:49 AM, ext Satish S wrote: >> >>> >>> 2) How does the draft incorporate with the existing >>> API[1]? It seems to me as if it'd be best to define both the attribute >>> as the DOM APIs in a single specification, also because they share >>> several events (yet don't seem to be interchangeable) and the >>> attribute already has an implementation. >>> >>> >>> The API proposal was implemented as >> x-webkit-speech> in Chromium a while ago. A lot of the developer >>> feedback we received was about finer grained control including a >>> javascript API and letting the web application decide how to present >>> the user interface rather than tying it to the element. >>> >>> The HTML Speech Incubator Group's final report [1] includes a >>> element which addresses both these concerns and provides automatic >>> binding of speech recognition results to existing HTML elements. We >>> are not sure if the WebApps WG is a good place to work on >>> standardising such markup elements, hence did not include in the >>> simplified Javascript API [2]. If there is sufficient interest and >>> scope in the WebApps WG charter for the Javascript API and markup, we >>> are happy to combine them both in the proposal. >>> >>> [1] >>> http://www.w3.org/2005/**Incubator/htmlspeech/XGR-**htmlspeech/<http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/> >>> [2] >>> http://lists.w3.org/Archives/**Public/public-webapps/** >>> 2011OctDec/att-1696/speechapi.**html<http://lists.w3.org/Archives/Public/public-webapps/
Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
As Dan Burnett wrote below: The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as an aid to developing full standards in this space. Because that work was so broad, Art Barstow asked (below) for a relatively specific proposal. We at Google are proposing that a subset of it be accepted as a work item by the Web Applications WG. Specifically, we are proposing this Javascript API [3], which enables web developers to incorporate speech recognition and synthesis into their web pages. This simplified subset enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control, and it supports the majority of use-cases in the Incubator Group's Final Report. We welcome your feedback and ask that the Web Applications WG consider accepting this Javascript API [3] as a work item. [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter [2] report: http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [3] API: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Bjorn Bringert Satish Sampath Glen Shires On Thu, Dec 22, 2011 at 11:38 AM, Glen Shires wrote: > Milan, > The IDLs contained in both documents are in the same format and order, so > it's relatively easy to compare the two > side<http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#speechreco-section> > -by-side<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html#api_description>. > The semantics of the attributes, methods and events have not changed, and > both IDLs link directly to the definitions contained in the Speech XG Final > Report. > > As you mention, we agree that the protocol portions of the Speech XG Final > Report are most appropriate for consideration by a group such as IETF, and > believe such work can proceed independently, particularly because the > Speech XG Final Report has provided a roadmap for these to remain > compatible. Also, as shown in the Speech XG Final Report - > Overview<http://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 wrote: > >> Hello Glen, >> >> ** ** >> >> The proposal says that it contains a “simplified subset of the JavaScript >> API”. Could you please clarify which elements of the HTMLSpeech >> recommendation’s JavaScript API were omitted? I think this would be the >> most efficient way for those of us familiar with the XG recommendation to >> evaluate the new proposal. >> >> ** ** >> >> I’d also appreciate clarification on how you see the protocol being >> handled. In the HTMLSpeech group we were thinking about this as a >> hand-in-hand relationship between W3C and IETF like WebSockets. Is this >> still your (and Google’s) vision? >> >> ** ** >> >> Thanks >> >> ** ** >> >> ** ** >> >> *From:* Glen Shires [mailto:gshi...@google.com] >> *Sent:* Thursday, December 22, 2011 11:14 AM >> *To:* public-webapps@w3.org; Arthur Barstow >> *Cc:* public-xg-htmlspe...@w3.org; Dan Burnett >> >> *Subject:* Re: HTML Speech XG Completes, seeks feedback for eventual >> standardization >> >> ** ** >> >> We at Google believe that a scripting-only (Javascript) subset of the API >> defined in the Speech XG Incubator Group Final Report is of appropriate >> scope for consideration by the WebApps WG. >> >> ** ** >> >> The enclosed scripting-only subset supports the majority of the use-cases >> and samples in the XG proposal. Specifically, it enables web-pages to >> generate speech output and to use speech recognition as an input for forms, >> continuous dictation and control. The Javascript API will allow web pages >> to control activation and timing and to handle results and alternatives.* >> *** >> >> ** ** >> >> We welcome your feedback and ask that the Web Applications WG consider >> accepting this as a work item. >> >> ** **
Re: HTML Speech XG Completes, seeks feedback for eventual standardization
Milan, The IDLs contained in both documents are in the same format and order, so it's relatively easy to compare the two side<http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#speechreco-section> -by-side<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html#api_description>. The semantics of the attributes, methods and events have not changed, and both IDLs link directly to the definitions contained in the Speech XG Final Report. As you mention, we agree that the protocol portions of the Speech XG Final Report are most appropriate for consideration by a group such as IETF, and believe such work can proceed independently, particularly because the Speech XG Final Report has provided a roadmap for these to remain compatible. Also, as shown in the Speech XG Final Report - Overview<http://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 wrote: > Hello Glen, > > ** ** > > The proposal says that it contains a “simplified subset of the JavaScript > API”. Could you please clarify which elements of the HTMLSpeech > recommendation’s JavaScript API were omitted? I think this would be the > most efficient way for those of us familiar with the XG recommendation to > evaluate the new proposal. > > ** ** > > I’d also appreciate clarification on how you see the protocol being > handled. In the HTMLSpeech group we were thinking about this as a > hand-in-hand relationship between W3C and IETF like WebSockets. Is this > still your (and Google’s) vision? > > ** ** > > Thanks > > ** ** > > ** ** > > *From:* Glen Shires [mailto:gshi...@google.com] > *Sent:* Thursday, December 22, 2011 11:14 AM > *To:* public-webapps@w3.org; Arthur Barstow > *Cc:* public-xg-htmlspe...@w3.org; Dan Burnett > > *Subject:* Re: HTML Speech XG Completes, seeks feedback for eventual > standardization > > ** ** > > We at Google believe that a scripting-only (Javascript) subset of the API > defined in the Speech XG Incubator Group Final Report is of appropriate > scope for consideration by the WebApps WG. > > ** ** > > The enclosed scripting-only subset supports the majority of the use-cases > and samples in the XG proposal. Specifically, it enables web-pages to > generate speech output and to use speech recognition as an input for forms, > continuous dictation and control. The Javascript API will allow web pages > to control activation and timing and to handle results and alternatives.** > ** > > ** ** > > We welcome your feedback and ask that the Web Applications WG consider > accepting this as a work item. > > ** ** > > Bjorn Bringert > > Satish Sampath > > Glen Shires > > ** ** > > On Tue, Dec 13, 2011 at 11:39 AM, Glen Shires wrote:* > *** > > We at Google believe that a scripting-only (Javascript) subset of the API > defined in the Speech XG Incubator Group Final Report [1] is of appropriate > scope for consideration by the WebApps WG. > > ** ** > > A scripting-only subset supports the majority of the use-cases and samples > in the XG proposal. Specifically, it enables web-pages to generate speech > output and to use speech recognition as an input for forms, continuous > dictation and control. The Javascript API will allow web pages to control > activation and timing and to handle results and alternatives > > ** ** > > As Dan points out above, we envision that different portions of the > Incubator Group Final Report are applicable to different working groups "in > W3C and/or other standards development organizations such as the IETF". > This scripting API subset does not preclude other groups from pursuing > standardization of relevant HTML markup or underlying transport protocols, > and indeed the Incubator Group Final Report defines a potential roadmap > such that such additions can be compatible. > > ** ** > > To make this more concrete, Google will provide to this mailing list a > specific proposal extracted from the Incubator Group Final Report, that > includes only those 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 wrote:**
Re: HTML Speech XG Completes, seeks feedback for eventual standardization
We at Google believe that a scripting-only (Javascript) subset of the API defined in the Speech XG Incubator Group Final Report [1] is of appropriate scope for consideration by the WebApps WG. A scripting-only subset supports the majority of the use-cases and samples in the XG proposal. Specifically, it enables web-pages to generate speech output and to use speech recognition as an input for forms, continuous dictation and control. The Javascript API will allow web pages to control activation and timing and to handle results and alternatives As Dan points out above, we envision that different portions of the Incubator Group Final Report are applicable to different working groups "in W3C and/or other standards development organizations such as the IETF". This scripting API subset does not preclude other groups from pursuing standardization of relevant HTML markup or underlying transport protocols, and indeed the Incubator Group Final Report defines a potential roadmap such that such additions can be compatible. To make this more concrete, Google will provide to this mailing list a specific proposal extracted from the Incubator Group Final Report, that includes only those 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 wrote: > Thanks for the info, Art. To be clear, I personally am *NOT* proposing > adding any specs to WebApps, although others might. My email below as a > Chair of the group is merely to inform people of this work and ask for > feedback. > I expect that your information will be useful for others who might wish > for some of this work to continue in WebApps. > > -- dan > > > On Dec 13, 2011, at 7:06 AM, Arthur Barstow wrote: > > > Hi Dan, > > > > WebApps already has a relatively large number of specs in progress (see > [PubStatus]) and the group has agreed to add some additional specs (see > [CharterChanges]). As such, please provide a relatively specific proposal > about the features/specs you and other proponents would like to add to > WebApps. > > > > Regarding the level of detail for your proposal, I think a reasonable > precedence is something like the Gamepad and Pointer/MouseLock proposals > (see [CharterChanges]). (Perhaps this could be achieved by identifying > specific sections in the XG's Final Report?) > > > > -Art Barstow > > > > [PubStatus] > http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications > > [CharterChanges] > http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed > > > > On 12/12/11 5:25 PM, ext Dan Burnett wrote: > >> Dear WebApps people, > >> > >> The HTML Speech Incubator Group [1] has recently wrapped up its work on > use cases, requirements, and proposals for adding automatic speech > recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work > of the group is documented in the group's Final Report. [2] > >> > >> The members of the group intend this work to be input to one or more > working groups, in W3C and/or other standards development organizations > such as the IETF, as an aid to developing full standards in this space. > >> Whether the W3C work happens in a new Working Group or an existing one, > we are interested in collecting feedback on the Incubator Group's work. We > are specifically interested in input from the members of the WebApps > Working Group. > >> > >> If you have any feedback to share, please send it to, or cc, the > group's mailing list (public-xg-htmlspe...@w3.org). This will allow > comments to be archived in one consistent location for use by whatever > group takes up this work. > >> > >> > >> Dan Burnett, Co-Chair > >> HTML Speech Incubator Group > >> > >> > >> [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter > >> [2] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ > >> > >> p.s. This feedback request is being sent to the following groups: > WebApps, HTML, Audio, DAP, Voice Browser, Multimodal Interaction > > >
Re: [XHR] XMLHttpRequest name
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 wrote: > >> Yeah, that's what's unfortunate. I just hope that future naming follows >> a standard. >> > > I'm afraid there's no standard for naming, but it would be nice to avoid > names like XMLHttpRequest in the future, yes. > > >
Re: [XHR] XMLHttpRequest name
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 wrote: >> Why are XML and Http capitalized differently? Shouldn't it be >> XmlHttpRequest? > > All I know for sure is that we cannot change this. (I.e. it has been > widely deployed and implemented with the current name for nearly a > decade.) > >
[XHR] XMLHttpRequest name
Hi, Why are XML and Http capitalized differently? Shouldn't it be XmlHttpRequest? Glen.
